If you get paid and if there is space to do that. There is often the ‘yeah yeah let’s add the rest of the features first the do docs’. I agree with you but this often goes wrong, especially at startups.

adding docs meanwhile isnt always working either as the feature product might change heavily, this is a hard discipline since you need to balance when to doc what.

A company should demand the documentation they need to understand things when the feature is under-development or shortly afterwards.

Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti code.

They never asked for documentation and instead pushed for more development faster.

I don’t think he is saying that a developer is in no way responsible for documentation, that is a pretty uncharitable interpretation of the comment.

I think they’re saying it is not up to the developer to make sure it happening writ large/that there is a system in place. That’s pretty much why we have managers and processes in place that everyone follows beforehand (ideally). If a company doesn’t implement systems, it’s not really up to me to do it. Often I will because it makes my life easier and I’m not a rigid “not my department” personality, but I’m not going to feel personally responsible when they drop the ball and wanted to plow ahead without putting the systems in place upfront. Especially because this often happens despite folks bringing up the need in the first place.

> self-reading code

I always strive to make my code simple and readable, but there's a saying that "one person organization is another hot mess".

Right or wrong, docs and tests are often given the lowest priority. Everything is good in moderation: you want some docs (especially for external APIs), some tests (integration > unit in many cases), but don't go overboard. You don't need 1000 unit tests for a little CRUD app. Documentation is subject to drift. For internal APIs, you're better off looking at the code.

It was a bank with high security, so the code actually had 100% coverage in tests.

I was working 100 hour weeks and not given any time for documentation or knowledge transfer. The code was certainly self-reading but it was a very complex system, especially security wise as it was a bank. Their other developers were juniors and couldn't understand it so they threw it out and started from scratch.

I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.