[rualca]

> Express this dismay to them, in a honest open conversation. Discover what holds them back.

Been there, done that.

The popular answer was that projects change too fast and he doesn not have time to maintain docs.

However, I firmly believe it all boils down to internal competition, and a refusal to give away to team members the knowledge they had to build up with their work.

Knowledge is power, and not disclosing how things work and why they worked is the key attain and preserve value within the team. You are a big shot if the things you do are hard and no one else can pull them off, and you achieve that by not giving away the information that allows others to easily do what you do.

[pdpi]

There’s the occasional engineer who works this way, but I find it exceedingly rare.

A much more common pattern (though still not that common) is the mentality that they’re focused on high impact work, and documentation isn’t it. Selfish, maybe, but not outright malicious.

An even more common scenario (that covers the vast majority of cases in my experience) is an internal culture that values shipping above all else, and makes engineers feel harried. Even if documentation would reduce busywork and improve productivity long term, management is too focused on the short term challenges to see it.

[xupybd]

That's it extremely tight deadlines and no time given to document anything.

[splittingTimes]

As a team lead I would not except this kind of toxic gate keeper mentality. A single person with such a bus factor is a huge problem to a teams/projects (or God forbid departments) success. Discuss and frame it in terms of worries for business continuity with your line manager. If that does not click, consider it a red flag.

[dangerface]

> The popular answer was that projects change too fast and he doesn not have time to maintain docs.

This is the problem I have clients will change their mind on core functionality from day to day with no understanding or consideration for how this constantly changing spec creates development hell.

I try talking to the client management but they also have no understanding of development. When I explain it to them and try to educate them they use their lack of understanding as an excuse to not try to understand.

Eventually they get the point but then just argue that its difficult to explain that to the customer and manage the customers expectations. I think yea no shit its difficult to explain to some one who doesn't understand but it is possible I just demonstrated that, now go do your job.

If they don't want to do their job they wont and no amount of polite talking to them will change their mind on that. If I eventually call them out on it, the hour I spent patiently explaining and reasoning with them is just ignored and I get called out for having a bad attitude.

At the end of the day the client management's only accountability is to the client so they just say yes to anything the client says, if that causes developer hell forever then thats the developers problem not theirs.

[Quekid5]

> The popular answer was that projects change too fast and he doesn not have time to maintain docs.

I sort of agree with this, but rather from the perspective that often the effort required to maintain documentation isn't in proportion to the payoff.

Naturally details differ among projects, but I find that the 20-80 rule applies to documentation, i.e. that 20% of the documentation provides 80% of the value. I find that focusing on stable architecture/properties of the system is a good approximation to the 'important' 20%.

If the system also has any especially tricky parts (e.g. a transaction coordinator) warrants documentation, but that also probably falls under the 'not subject to rapid change' 20%.

I'm assuming project internal documentation here. If you're documenting things for customers, then you'll want to document everything very thoroughly, but one would hope that people figure that out eventually when support tickets keep coming in...

EDIT: Clearer phrasing