4 ms·

I think I can see where you're coming from (we engineers are implementers, and not in charge of the vision for the product, which is mostly true). But yeah, I s

I think I can see where you're coming from (we engineers are implementers, and not in charge of the vision for the product, which is mostly true). But yeah, I still disagree with your point overall. In my humble opinion, as engineers, it is still our responsibility to deliver value to the CTO/CEO and the company overall. Because engineers have the best understanding of the system, and often are the best counterpart to the business people. We guide them on what is and isn't possible, and even more than that, we often understand the business domain nearly as well as they do (from a more technical aspect). Just off the top of my head, I worked at a US eCommerce company that was trying to open their site to new markets in Europe. The business people designed a flawed payment system because they had a poor understanding of how payments worked. A coworker of mine realized what they had done was wrong and would cost the company hundred's of thousands if it was used, and worked with the business people to rework it (see below for more info). He didn't simply follow what tasks he was given, he saw that he needed to step in and help them pick a better solution. In the end, the goal of the job is to do work that improves the system and benefits the company. You could just focus on just being a great implementer (the ultimate hammer), but to me, this is not how a true software engineer thinks, but maybe how a lower level dev might work. ... And, the problem my coworker worked on was this: the business people decided if anything went wrong with payments in a foreign currency, the system would default to US dollars. This is a bad idea, because this will create enormous accounting headaches and greatly complicate the system. The best solution is surprisingly to let it fail. Yeah, if there is an error in a payment's currency, something is seriously wrong and we need to know about it.

rrgok 4y ago
I don't know. Something must be wrong with the way I think. In your eCommerce example, what is the product/service? The payment system? Is the payment system A? Or payment is B? All these answers are wrong. The product/service is "make the eCommerce for Europe". That service should have value, how is that "bringing to Europe" value a software engineer's responsibility? In order to materialize the "eCommerce Europe" we need a payment system. Now comes the role of the software engineer: design, propose payments systems. A payment system has nothing to do with the value of the product. My responsibility is to provide a correct, within the specs, payment system. In your example, the first solution is not acceptable (I don't even consider it a solution). Now suppose you shipped the "eCommerce Europe" with correct payment system. But the product/service "eCommerce Europe" didn't take off as in US. Didn't the Software Engineer produce value? It doesn't make sense to me. The Software Engineer produced the value: designed, developed, tested and shipped the payment system. Thats the value of a software engineer.
- alocasia-1 4y ago
  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 4y ago
    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 4y ago
      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.

rrgok 4y ago

I don't know. Something must be wrong with the way I think. In your eCommerce example, what is the product/service? The payment system? Is the payment system A? Or payment is B? All these answers are wrong. The product/service is "make the eCommerce for Europe". That service should have value, how is that "bringing to Europe" value a software engineer's responsibility? In order to materialize the "eCommerce Europe" we need a payment system. Now comes the role of the software engineer: design, propose payments systems. A payment system has nothing to do with the value of the product. My responsibility is to provide a correct, within the specs, payment system. In your example, the first solution is not acceptable (I don't even consider it a solution). Now suppose you shipped the "eCommerce Europe" with correct payment system. But the product/service "eCommerce Europe" didn't take off as in US. Didn't the Software Engineer produce value? It doesn't make sense to me. The Software Engineer produced the value: designed, developed, tested and shipped the payment system. Thats the value of a software engineer.

alocasia-1 4y ago
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 4y ago
  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 4y ago
    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.