5 ms·

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely t

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.

jaredsohn 9mo ago
Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things. If you just implement product tickets you'll probably get replaced by LLMs.
- hyperadvanced 9mo ago
  It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago
- jeanlou 9mo ago
  You need to be a product-minded engineer.
cm2012 9mo ago
I have never seen a pure ticket based / zero ownership approach ever work.
- mangamadaiyan 9mo ago
  Tell us you've never worked in a faang without telling us.
  - cm2012 9mo ago
    It doesnt work in faang either, which is why they are wildly slow to produce software. They can just print money when running at 10% efficiency.
anhner 9mo ago
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end? Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?
- rswail 9mo ago
  They should have a general idea of what they are building and why, in exactly the same way as a construction worker. That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction. Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.
  - anhner 9mo ago
    Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized. And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).
- rswail 9mo ago
  The other argument about this is whether or not an SWE is a fungible resource. When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another. We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.
rswail 9mo ago
Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements. The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers. It's up to the developers and designers to understand those constraints and make sure they are communicated back.
- diydsp 9mo ago
  Ive observed a modern trend of little to no QA. Managers and CTOs insist developers can test their own systems. Maybe this makes more sense in the early phases of product development where I find myself lately? Seems to capture a lot of dev's time.

jaredsohn 9mo ago

Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things. If you just implement product tickets you'll probably get replaced by LLMs.

hyperadvanced 9mo ago
It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago
jeanlou 9mo ago
You need to be a product-minded engineer.

cm2012 9mo ago

I have never seen a pure ticket based / zero ownership approach ever work.

mangamadaiyan 9mo ago
Tell us you've never worked in a faang without telling us.
- cm2012 9mo ago
  It doesnt work in faang either, which is why they are wildly slow to produce software. They can just print money when running at 10% efficiency.

anhner 9mo ago

It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day. Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end? Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?

rswail 9mo ago
They should have a general idea of what they are building and why, in exactly the same way as a construction worker. That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction. Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.
- anhner 9mo ago
  Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized. And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).
rswail 9mo ago
The other argument about this is whether or not an SWE is a fungible resource. When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another. We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.

rswail 9mo ago

Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements. The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers. It's up to the developers and designers to understand those constraints and make sure they are communicated back.

diydsp 9mo ago
Ive observed a modern trend of little to no QA. Managers and CTOs insist developers can test their own systems. Maybe this makes more sense in the early phases of product development where I find myself lately? Seems to capture a lot of dev's time.