Is that really your concern? That surely depends upon both the individual’s role and the culture in the organisation, but I tend to agree with the original aut

Is that really your concern? 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.