- see a feature request that sounds weird.

- ask what problem they are trying to solve

- come up with a less weird / more useful solution.

As engineers we have information and skills that designers and pms often lack. You can just build what you're asked to build and you'll be fine, but understanding the value that's added will make sure you build it better.

I have the opposite view, I think it matters a lot. As an engineer, I understand things better when I can see the "why". Being aware of the "why" means that I will follow more easily the spirit of the spec instead of just the word. It means I will be more aligned with the users, the business. All of these avoid the classic trap of having a dev team disconnected from the business, which usually leads to a bad atmosphere, late/failed projets.

It also allows you to use your experience and expertise to tell the writer of the spec that they have written a pile of junk and that what they are asking for is not what they need. Sometimes when I have done that I have also discovered that it was not what they wanted either but simply what they thought was practicable. Together we were able to thrash out a better spec that achieved the ends that were necessary.

I wish that people would remember that the vast majority of people writing code are doing it inside the same company or even department that will be using the final program. It is often the case that at least some of the software developers in such teams have as much or more expertise in the domain as the customers commissioning the software; it would be a dereliction of duty to fail to question a specification that seemed pointless, inconsistent, or inadequate to the problem it was purported to solve.

That surely depends upon both the individual’s role and the culture in the organisation, but I tend to agree with the original author. As a developer, I can often provide better results if I’m aware of the context and not operating in isolation. As a manager, I get better results from the people working for me if we’re communicating openly and often enough to address any questions or problems quickly, and this applies to software developers as much as any other field.

Of course this matters more as you get more senior as a developer or perhaps start to take on hybrid roles like tech lead or software architect. However, in my experience the principle works very widely, except maybe for juniors who have enough to learn already and new starters who are still finding their way around.

No doubt there are some projects where for legitimate security reasons there is a culture of need-to-know and compartmentalisation of information, but I suspect that across the industry as a whole, variations of wilful ignorance among developers do far more harm than good. It happens at large scale, like pigeonholing developers into narrow roles and trying to make everything possible into someone else’s problem. It happens at smaller scales, like being too dogmatic about pretending we have no idea what we’re going to be working on a few days or even a few hours later and stubbornly refusing to make any allowance for it in code we’re currently writing.

That kind of culture can become toxic and unproductive, but it can often be fixed by sharing information more freely with those who might find it useful and then having those people take the extra context into account when making their own plans and decisions. A lot of the points in the article here could be specific examples of that general idea, and IMHO those are all sensible advice.

I think I agree with a lot of your post, but I do still disagree that everybody needs to be aware of the end goal.

This can work, and often seems to work well enough, but it also can fail spectacularly. See the recent Ask HN discussion on Google's 50 billion messaging clients.

If so, ok, your work will become much better if you ask those questions, but the party paying you does not care about it at all. You are just expected to deliver this feature.

But if you have any amount of goal alignment with the people that will get the software (as little as wanting them to perceive your work is useful), you will get much better results by having a picture of what your software is supposed to do. If you do not have access to this information, it's relevant to be aware that you are not receiving all the tools you need to succeed.

On the other side I like seeing metrics/feedback of something I made get used. Always sad when a venture dies/nothing happens to it.