Its not the engineer's responsibility to figure out if you're building the right thing. That's the job of the managers and product owners.
Its not the engineer's responsibility to figure out if you're building the right thing. That's the job of the managers and product owners.
I’ll claim the ones in the end that will have that responsibility will be engineers. LLMs add the ability for engineered to build quickly enough that there’ll be enough of them to morph into product roles as well. I trust us/them much more than product owners who use models to code.
Much easier to engineers to move to product than product to move to engineers. Or at least the minimum amount needed to fill all product roles. I’m seeing we can do that now and it’s _much_ more efficient to not have to have back and forth communication as in the past with that communication being by far the slowest part of build processes.
> I’ll claim the ones in the end that will have that responsibility [to figure out if you're building the right thing] will be engineers.
One can have this stance. But in practice, programmers who have strong opinions on this topic that is not aligned to the management wishes will commonly become personae non gratae in the company, and are thus commonly on the brink of getting fired.
So, in the end, the incentives that exist in most companies are strongly biased towards the position that figuring out if you're building the right thing is the job of the managers and product owners. :-(
I can agree with this as well. But I'll do a follow along for who says management has the best and correctly decided plans for the company? What if in the future, engineers become product, and those then become management because who's to say that's more difficult?
For the way orgs are currently set up, yes, conflict between engineers and management can cause issues. I'd put somewhat of a bet that those types of org setups won't be the way in the future.
And how do you think many of those managers come up with the ideas nowadays?:) There's no human in the loop anywhere at FAANGs. I see it first hand. LLM ideas, LLM docs, LLM coding, LLM launch announcements...
In theory sure, but in practice an engineer who can steer managers and product owners can have a massive impact on the outcome.
Tell me you're a bad engineer without telling me.
If you don't understand what you are building, chances are you'll take suboptimal decisions or even come up with a solution that completely misses the point.
To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
> To properly understand what you are going to build, it's not enough to read specifications from some manager as gospel. You need to ask questions, and challenge the requirements sometimes, to make them your own.
Many managers don't like being challenged. :-(
Eh.
If the engineer is told to build a bridge that is virtually guaranteed to collapse, then it a reasonable person ( ideally, same person as engineer ) would note that particular risk.
It may not be engineer's responsibility to build the exact right thing, but it sure is their responsibility to build it right without having the bridge to collapse the moment someone stands on it.
Otherwise, the person building the bridge is not an engineer.
> Otherwise, the person building the bridge is not an engineer.
One is likely not an engineer if one does not notice the risk. But in practice, managers commonly desire docile subordinates, so the only thing an engineer can do in such a situation is to ensure that a paper trail gets generated that will be capable of breaking the manager's neck once the disaster has occurred. :-(
[dead]