To some extent, I'm finding very difficult to work on something with no understanding of who is going to use it, how it's going to be used, and why it's needed. It makes engineering decisions very difficult, maintenance work horrible since you don't know the impact, and new features difficult to 'bound' (do I really need to handle all these extra corner cases, or can I just say it's not supported?). Basically, understanding context is key to high impact work in many cases.
So, while I agree with OP about the qualities of 'product-minded engineers' (they're good qualities), I believe they should be part of the default skillset of any senior engineer, and especially so since 'product' can be a library shipped internally, and doesn't have to be the final product shipped to clients outside the company.
Ugh. If I have to do all of that, in addition to all of the development work, then what purpose do all the other managers, designers, PMs, POs, etc. serve? Again, devs have to do everyone else's jobs including their own. In the same sense they should rely on me for technical things, I rely on them for the non-technical things.
Why so negative? You don't _have_ to do all of that, but as a software engineer you are in the unique position in which you're able to do a bit of all of that _if you want to_. It's like saying: why should I do operations work when I'm a developer. But then DevOps became a thing and every developer was suddenly also an operations guy. Being able to pick up different roles is an extremely valuable skill, and you're limiting yourself if you're drawing an imaginary boundary between technical and non-technical things.
So-called "DevOps" falls into this as well. Not enough Ops staff? Just put the devs on call, too. They can still do all of their normal work in addition to all the ops stuff.
I look forward to when DevOps stops being "a thing".
This is the point I was hoping for. Your job probably isn’t “write code”. It’s probably something like “build the payment processor “. Code is just an incredibly enjoyable implementation detail.
I think this is YMMV. I've had a few jobs where I was very product-minded and a few jobs where I wasn't. The product-minded jobs were way more enjoyable to me. I really like the empowerment, autonomy, and sense of ownership that comes with being product-minded. I feel like I am allowed to thrive, and that my contributions produce much more value.
Maybe this is possible in a non-product-minded role, but I think you would need really great support roles (PM, PO, etc) and great communication.
Depends on the size of your organization. For example in smaller shops the whole manager/PM/PO is rolled into one individual, if that person even exists. At the shop I worked at we didn't have PMs, so for each client one developer was declared the "Product-minded SE" for that project who had the extra level of organizational responsibility for that project.
A lot of big tech companies do compensate amazingly well according to this author (in other articles he wrote). Big tech companies expect SWEs to be problem solvers and to utilize their leverage.
Just paraphrasing/summarizing his perspective.
Assuming that to be true, I think you do get compensated relatively fairly.
Exactly this. Also applies to team leads and management.
If I'm going to go remove bottlenecks, mentor, keep the team culture going, solve gnarly technical and people issues, create project docs, maintain relationships across teams so our team is not perceived as useless, what exactly does management do?
I fail to understand that how ownership is thrown at devs without recognition, promotions or higher pay.
At it's core, I fail to see the value management brings to the table if they cannot unblock projects, instead asking devs to do all of it.
Not enough blog posts have been written about this. "Ownership" is all too often weaponized in subtle ways that reduce an individual contributor's political leverage.
You get "blamed" for not taking enough ownership when shit goes south, but if things are going well the managers and product owners take all the credit.
The article mentioned a very nice point that I find is true for my experience: you can make product trade-off in favour of engineering if you know your product well.
Being able to explain business people why a certain feature is crap made my day job a lot easier than it could have been.
Gergely Orosz with a blog post that I'm going to use as a reference when people ask me for advice on "how can I increase my impact as an employee?". Whether your customers are internal or external, we all want to build useful products/tools that are being used and provide real value. Share it with other engineers in your organization and have a discussion. Who's doing it exceptionally well today? Are you investing enough time with them to see how they do it?
It would be nice if Firefox provided an API that only exposed the static HTML of sites you're visiting. I don't care if an extension wants that data, it's nowhere near as sensitive.
I guess this doesn't solve injection, but there must be other ways to solve "display some additional data."
So, while I agree with OP about the qualities of 'product-minded engineers' (they're good qualities), I believe they should be part of the default skillset of any senior engineer, and especially so since 'product' can be a library shipped internally, and doesn't have to be the final product shipped to clients outside the company.