[alocasia-1]

No, I think you're spot on.

If you can point to the requirements you were given, the technical clarifications you sought, etc. and show how you fulfilled them, then you as a SWE did your job. If you happen to have the domain knowledge to challenge the whole thing on principle, that's great - but that's something that should happen before it hits your desk.

I recently got a haircut. It was exactly what I asked for, but it doesn't suit me at all. I tipped my hairdresser (who is great, and I should have paid attention when she said "really?") well, as usual, because it's not her fault I asked for something stupid. Could she have pushed back harder? Sure, but that's not really her job and it would be unfair to blame her for not doing so.

[bradwood]

The point is not to just say: "Hey man, I did my job and built what you wanted. It's on you if you asked me to build the wrong shit". While this technically might be 100% correct, in terms of roles and responsibilities in the firm; it is ultimately (a) unhelpful to the business's agenda and (b) not really focused on adding real customer value. Yeah, you did your job, great! But we're still fucked.

If you were wanting to add true value you should, IMHO, be saying "Hold on a moment there, buddy, you are asking me to build the wrong shit -- have you thought about this? what about if we do that? surely this is a better/safer/more effective way?"

All good business/product people I know love it when engineering comes forward with this kinda stuff. It's what separates the good from the great. If you are working in an environment where the CxO, PO, sales guy tells you to "fuck off and just code what you've been told to" the you are so in the wrong job and you need to get a new one. Fast.

My $0.02 on the matter.

[rrgok]

Why we are moving the goal post? The problem was not building something right or wrong. The problem is building/producing/delivering something of value. A lot fo wrong things have immense value, and the opposite is also true. How should I know if the thing I'm building has any value in the target market and it aligns with vision of the company? Is it my job to do market research or to build the thing asked for?

To make the point clear, I'm gonna make an extreme example.

If some one asked me to build the next social media to a poor country, where the immediate problem for 80% of the population is to find stable source of food and a shelter, and I'm payed to do so. What should I do? If I don't have the knowledge, as software engineer (which is almost always the case, i.e. not knowing a lot of the business decisions), about the target market, what should I do? Now, as software engineer, should I also do market research? How, I'm gonna know all the business decision about a product? Maybe the people commissioning me the engineer side of the business have already some client ready to buy? How am I supposed to know the business strategy? This is absurd. This is again putting everything on the shoulder of software engineers.

It is unhelpful, as you correctly say it. I don't denied that. But you should not deny that finding product that have any value for business agenda, is a role a market researcher should do, or someone else more competent in that area.

The fact the reality is how you say it is, it is sad story. But that doesn't make any less unfair. I did a B.Sc in Computer Science and nobody thought me anything about business, product, market research, pricing techniques. I don't how to do it properly nor I can guarantee that the product I'm building for you have any value in whichever market you are going to sell it. And I'm not comfortable taking that kind of responsibility. It is unfair and dishonest for both the buisiness and me.

[computerdork]

In my opinion, we're kind of just going in circles. Yes, we as engineers don't have a full understanding the "overall" and "high-level" value of the work we do. 100% true. But, our value is at a smaller level. Is the feature we created going to meet the project's (and the company's) goals or not? (as we understand them)

Requirements gathering has always been apart of software engineering, and actually, we're usually a necessary part of creating that spec. As we all know, a business person has a vague idea of what they want and they work with a technical person to see if this possible or even a good idea). We try to create the right solution given our understanding of the goals of the project and feature. The value again is smaller.

...Although, I do see your point, it can be easy as the technical expert to start giving opinions on things that aren't your responsibility (like marketing strategy). Maybe you've gotten hit by this before? (this is always touchy subject, but I've definitely been scapegoated for problems in the past, never fun). But still, typically, tend to find that the business person is ultimately in charge of the business decisions and I'm responsible for the technical ones.

[computerdork]

.. oh, and just to add one more thing, seems like the higher you go, the more of a business person you become anyways. Because for most decisions, the technical and business aspects go hand in hand - should we implement a new payment system in Europe? If we do, how long do we think it will take? Or is it even feasible? If we it is, will it work in all European countries? Will it be easy to maintain? The business person often has little idea on any technical estimates, but these are crucial to making an informed decision. We work together with them to come up with our best belief on whether the idea is worthwhile.

And agreed, it is a lot of responsibility, but again, it's only when an engineer rises in their company.

[rrgok]

Nice example, thank you. Worst when the hairdresser change the style throughout the process because they think something else is better for my head. Maybe at the end I go home sad and frustrated, because (a) I didn't get the style I asked for (b) the one I got does'n fit my face and worsen my value and (c) I had to pay too.