[taklimakan]

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]

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.

[jeanlou]

You need to be a product-minded engineer.

[hyperadvanced]

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

[rswail]

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]

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.

[cm2012]

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

[mangamadaiyan]

Tell us you've never worked in a faang without telling us.

[cm2012]

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]

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?

[ilaksh]

Construction worker is a spectacularly bad analogy for software engineer.

The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.

Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.

And then from the specification, decide how to implement it, which is not decided at all ahead of time.

Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.

There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.

[rswail]

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]

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]

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.

[qwertytyyuu]

If upvoting doesn’t require justification neither should downvoting.

But let me try to express why people disagree. Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.

The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.

Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.

[anhner]

I appreciate the reply.

> If upvoting doesn’t require justification neither should downvoting.

I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread.

Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.