5 ms·

Overall nice post. But the point 5, irks me the wrong way. Every time I read something along the lines of that paragraphs, something inside of me dies. At expe

by rrgok 4y ago

Overall nice post. But the point 5, irks me the wrong way. Every time I read something along the lines of that paragraphs, something inside of me dies. At expense of being downvoted to hell. I'm gonna say it in caps to emphasize, not to shout: IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE. This doesn't apply to all Software Engineers (like the one who sells the product is also the Software Engineer, or writing open source libs to other developers, some freelancer,...). It makes me sad to see how many Software Engineer are brainwashed to put up with the stress of producing value. When people like PG, DDH or you name another CEO/Cofounder, say: ultimately we should produce value. They are not talking as a Software Engineer, they are talking as people who owns and sell products/service, who happen to be the Software Engineer of the product/service. I, as employee Software Engineer who produce software that other people use and a sell, must not be concerned about the value of the product/service. My only concern is to design and implement what they ask for. Whether what they ask for as any value, it is not my responsibility. It is their money, they should find value in what they asking from me. Why? Ask yourself if you are ultimately participating or have any say in the pricing of the product/service? Or do I sell the product/service myself? If you answered to No to both, then it is not your job to produce value. I hope in the coming years we reduce the stress we put on Software Engineer. In the last years, I keep seeing this trend of making Software Engineer to everything.

hbrn 4y ago
> IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE. Says who? Is there a law that forbids it? If companies where SEs are focusing on value are more successful, then naturally it becomes SE responsibility. > My only concern is to design and implement what they ask for What they ask for changes over time. The hardest part of SE is not building first version of the software, it's evolving it. If you don't understand where the value is coming from, you will always make wrong predictions. Given freedom, you will always choose to focus on things that matter to you (performance, scalability, fancy tech, etc) instead of things that matter for the business (growth, UX, features).
- rrgok 4y ago
  > Says who? Is there a law that forbids it? Forgive me, but this is a non-sensical question. I can ask you the same. Who says I should deliver product that has value? Is there a law for that? Between (performance, scalability, fancy tech, etc) and (growth, UX, features), which one is Software Engineering and which one isn not? Why we have UI Designer an UX Designer? Shouldn't we call them all just Software Engineering? You clearly see which metric matters to a software engineers (performance, scalability...) and yet you say the software engineer should not do that and just do something else (UX, growth...) ? And who should think about performance, scalability...? The UI Designer, I think, right? And the value of a product is combination/unification of all these things (performance, scalability, ux, ui...) and who should think/plan about that? I guess only the software engineers should worry about that, on top making architectural decision. And the CEO who runs and has vision for the product, what should they do?
  - hbrn 4y ago
    > Who says I should deliver product that has value? Whoever hired you? "Not my responsibility/problem" is a terrible attitude, nobody wants employ those people. They can be useful as contractors. But if you are hired as an FTE, it's strange to complain about not being treated as a contractor, don't you think? > Between (performance, scalability, fancy tech, etc) and (growth, UX, features), which one is Software Engineering and which one isn not? It's a false dichotomy, all of those are Software Engineering. Some of those are not Computer Science, but could still be strongly tied to it (e.g. UX is often a synonym for HCI). > You clearly see which metric matters to a software engineers (performance, scalability...) No, I see this is a metric that matters for bad software engineers. > And the value of a product is combination/unification of all these things (performance, scalability, ux, ui...) and who should think/plan about that? Few people should be responsible, but everyone should think, plan and provide feedback. What you need to recognize is that engineers are in unique position: they can understand 80% of business domain, while business folks can understand 5% of engineering domain. You'd be an idiot not to involve engineers in delivering value.
    - rrgok 4y ago
travisgriggs 4y ago
I’m torn. I want to agree with you. My problem though, is that 95% of the time, the people doing the asking aren’t competent to do the asking. It’s not just about bad market directions: “You wanted a plaid Cadillac, I painted you a plaid Cadillac.” Often, the people doing the high level directing are there because of the Peter principle. Now it’s a bit more like being a pilot or a train engineer, you’re doing the hands on implementing, but the charted course is not just inefficient, it does lasting damage to the viability of the vehicle. And when it’s all bolloxed, it’s you, your peers, and your profession that take the blunt of the blame. The very thing that got you collectively into the mess—their inability to really understand what they’re doing—is the thing that saves them. So in an idealized world, I totally agree with you. When I have the pleasure of being healthily remunerated to craft solutions under someone else who has respectable experience and wisdom about software choices, and owns both their success and their failure and insulates me from that, I will happily move past tue sense of responsibility that inevitably works it’s way into what I do.
- rrgok 4y ago
  I understand and I agree with you. Mine is an idealized world, I know it. By the way, spot on with Peter principle, that's one of the main reason, all this producing value makes me go crazy.
bradwood 4y ago
I'm sorry. As a former software engineer and now CTO I have to disagree completely. Adding value is everyone's responsibility and the product/business/pricing ideas that come from engineering can be as valuable and influential to a business strategy as those from the CEO or PO. If you want to write software that isn't rooted in building business value you should be an academic or hobbyist but in any well run business that depends upon or sells software /SaaS services, engineering should be a critical influence on the business's strategy. If an engineer is just a cog in the machine and doesn't get or care about what they are building, who it's for, and how it changes experience and increases shareholder value then how can they take a wider appreciation of their work and its impact on the real world?
- rrgok 4y ago
  I never said we should not be adding value. I, as Software Engineer, add value. I write the software ultimately. Whether that software has value for you CTO, CEO or whoever own the software, cannot be my responsibility right? My problem is that seeing value in a software product/service is dictated by the vision of the company and the market. The vision for a product is not a cog's responsibility. To make an example. If all the engineers of Tesla were asked to build a car, not from Elon, but someone else who didn't see value in EV. What would've happened? I don't think the engineers would come up with an EV. The value is create by you CEO, CTO and owners of the product. If Tesla with Elon had failed, is the engineers responsibility to not have produced value? The vision was wrong, simple. Heck, how many Apple/Microsoft products didn't take off and don't tell me they were badly engineered, that can't be the only reason, or the engineer didn't produce value. Wether I write software rooted in business value or has an impact in real world is a moral decision, right? And I think we can both agree that morality has nothing to do with value of a product/service. Example, military weapons. I would not morally do it, but there is value in it right? Who dictates the value of it? If a shareholder invest money in something, it is because they see value in it, right? Or they invest blindly and expect engineers to create value?
  - bradwood 4y ago
    > I, as Software Engineer, add value. I write the software ultimately. Yeah, but if you wrote the wrong software (maybe because the PO specified the wrong thing and it wasn't your fault) -- did you still add value? No, you burned story points for no upside at all.
CobrastanJorji 4y ago
> My only concern is to design and implement what they ask for. Whether what they ask for has any value, it is not my responsibility. You're describing a compiler. You are not a compiler; you are a software engineer. You will, especially as you get more senior, be asked for things that are wrong. You will be asked for things in the form of a fuzzy problem statement with no direct guidance on what to change, with the understanding that you will talk to relevant people and figure out what needs doing, and then you'll build that. One day, your job will be to figure out, with no prompting whatsoever, what things need to be built, and you'll build those things. Your job isn't "to create value," but it's not "build the thing as described without questioning it" either. That's a compiler.

by rrgok 4y ago

hbrn 4y ago

> IT IS NOT THE RESPONSIBILITY NOR THE JOB OF THE SOFTWARE ENGINEER TO DELIVER OR PRODUCE VALUE. Says who? Is there a law that forbids it? If companies where SEs are focusing on value are more successful, then naturally it becomes SE responsibility. > My only concern is to design and implement what they ask for What they ask for changes over time. The hardest part of SE is not building first version of the software, it's evolving it. If you don't understand where the value is coming from, you will always make wrong predictions. Given freedom, you will always choose to focus on things that matter to you (performance, scalability, fancy tech, etc) instead of things that matter for the business (growth, UX, features).

rrgok 4y ago
> Says who? Is there a law that forbids it? Forgive me, but this is a non-sensical question. I can ask you the same. Who says I should deliver product that has value? Is there a law for that? Between (performance, scalability, fancy tech, etc) and (growth, UX, features), which one is Software Engineering and which one isn not? Why we have UI Designer an UX Designer? Shouldn't we call them all just Software Engineering? You clearly see which metric matters to a software engineers (performance, scalability...) and yet you say the software engineer should not do that and just do something else (UX, growth...) ? And who should think about performance, scalability...? The UI Designer, I think, right? And the value of a product is combination/unification of all these things (performance, scalability, ux, ui...) and who should think/plan about that? I guess only the software engineers should worry about that, on top making architectural decision. And the CEO who runs and has vision for the product, what should they do?
- hbrn 4y ago
  > Who says I should deliver product that has value? Whoever hired you? "Not my responsibility/problem" is a terrible attitude, nobody wants employ those people. They can be useful as contractors. But if you are hired as an FTE, it's strange to complain about not being treated as a contractor, don't you think? > Between (performance, scalability, fancy tech, etc) and (growth, UX, features), which one is Software Engineering and which one isn not? It's a false dichotomy, all of those are Software Engineering. Some of those are not Computer Science, but could still be strongly tied to it (e.g. UX is often a synonym for HCI). > You clearly see which metric matters to a software engineers (performance, scalability...) No, I see this is a metric that matters for bad software engineers. > And the value of a product is combination/unification of all these things (performance, scalability, ux, ui...) and who should think/plan about that? Few people should be responsible, but everyone should think, plan and provide feedback. What you need to recognize is that engineers are in unique position: they can understand 80% of business domain, while business folks can understand 5% of engineering domain. You'd be an idiot not to involve engineers in delivering value.
  - rrgok 4y ago

travisgriggs 4y ago

I’m torn. I want to agree with you. My problem though, is that 95% of the time, the people doing the asking aren’t competent to do the asking. It’s not just about bad market directions: “You wanted a plaid Cadillac, I painted you a plaid Cadillac.” Often, the people doing the high level directing are there because of the Peter principle. Now it’s a bit more like being a pilot or a train engineer, you’re doing the hands on implementing, but the charted course is not just inefficient, it does lasting damage to the viability of the vehicle. And when it’s all bolloxed, it’s you, your peers, and your profession that take the blunt of the blame. The very thing that got you collectively into the mess—their inability to really understand what they’re doing—is the thing that saves them. So in an idealized world, I totally agree with you. When I have the pleasure of being healthily remunerated to craft solutions under someone else who has respectable experience and wisdom about software choices, and owns both their success and their failure and insulates me from that, I will happily move past tue sense of responsibility that inevitably works it’s way into what I do.

rrgok 4y ago
I understand and I agree with you. Mine is an idealized world, I know it. By the way, spot on with Peter principle, that's one of the main reason, all this producing value makes me go crazy.

bradwood 4y ago

I'm sorry. As a former software engineer and now CTO I have to disagree completely. Adding value is everyone's responsibility and the product/business/pricing ideas that come from engineering can be as valuable and influential to a business strategy as those from the CEO or PO. If you want to write software that isn't rooted in building business value you should be an academic or hobbyist but in any well run business that depends upon or sells software /SaaS services, engineering should be a critical influence on the business's strategy. If an engineer is just a cog in the machine and doesn't get or care about what they are building, who it's for, and how it changes experience and increases shareholder value then how can they take a wider appreciation of their work and its impact on the real world?

rrgok 4y ago
I never said we should not be adding value. I, as Software Engineer, add value. I write the software ultimately. Whether that software has value for you CTO, CEO or whoever own the software, cannot be my responsibility right? My problem is that seeing value in a software product/service is dictated by the vision of the company and the market. The vision for a product is not a cog's responsibility. To make an example. If all the engineers of Tesla were asked to build a car, not from Elon, but someone else who didn't see value in EV. What would've happened? I don't think the engineers would come up with an EV. The value is create by you CEO, CTO and owners of the product. If Tesla with Elon had failed, is the engineers responsibility to not have produced value? The vision was wrong, simple. Heck, how many Apple/Microsoft products didn't take off and don't tell me they were badly engineered, that can't be the only reason, or the engineer didn't produce value. Wether I write software rooted in business value or has an impact in real world is a moral decision, right? And I think we can both agree that morality has nothing to do with value of a product/service. Example, military weapons. I would not morally do it, but there is value in it right? Who dictates the value of it? If a shareholder invest money in something, it is because they see value in it, right? Or they invest blindly and expect engineers to create value?
- bradwood 4y ago
  > I, as Software Engineer, add value. I write the software ultimately. Yeah, but if you wrote the wrong software (maybe because the PO specified the wrong thing and it wasn't your fault) -- did you still add value? No, you burned story points for no upside at all.

CobrastanJorji 4y ago

> My only concern is to design and implement what they ask for. Whether what they ask for has any value, it is not my responsibility. You're describing a compiler. You are not a compiler; you are a software engineer. You will, especially as you get more senior, be asked for things that are wrong. You will be asked for things in the form of a fuzzy problem statement with no direct guidance on what to change, with the understanding that you will talk to relevant people and figure out what needs doing, and then you'll build that. One day, your job will be to figure out, with no prompting whatsoever, what things need to be built, and you'll build those things. Your job isn't "to create value," but it's not "build the thing as described without questioning it" either. That's a compiler.