so it’s natural to think something is odd here.

I glanced over a few other blog posts from the blog. The guy is describes himself as a troublemaker and has a whole blog post on how it is hard to be nice to people.

And the guy has a track record of posting highly racist comments to boot.

This is from the last half a dozen blog posts.

Perhaps the guy is going through a mental breakdown. Perhaps not. But I’d be hard pressed to pick this guy over any other candidate.

But you will not have learned much, if anything, by copy/pasting the answer.

Your ignorance is showing. The whole point of using SO to help troubleshoot problems is avoiding the troubleshooting stage and all the iterative work of cross-checking docs with parametric tests. The main deliverable of SO is not a magical code snippet but a root cause analysis on a particular failure. You end up with a nice summary of someone else’s prior work troubleshooting the same issue, and a clear indication that X causes Y because of Foo.

And you do not get that by reading official docs documenting the happy flow. You’d know that if you had any relevant experience developing software.

Your comment shows some ignorance mixed with lack of experience. Errors do happen due to many reasons, and there is no project on earth that is nearly as documented as you pretend them all to be. This is one of the reasons why googling for error messages ended up being a very basic and mundane technique in software engineering.

What makes your comment stand out is the fact that you are completely unaware that some projects even use Stack Overflow to help users troubleshoot issues, with project maintainers taking the lead in providing answers. But here you are, pretending that reading docs is a silver bullet

I (and other actually competent devs I’ve talked to about it) have always gone straight to official documentation first.

This is silly posturing. Anyone that is troubleshooting a problem tends to start by googling the error message, and more often than not Google will return SO hits, not official documentation.

No left at the company even knows how to work the erp properly. Because the person who set it up and customized it didn’t document or train anyone and then left…

That’s not technical debt. That isn’t even the definition of legacy code. That’s a mess and a whole set of problems, but technical debt ain’t one of it.

Is it really unethical if it benefits the organization? Even if that’s not really the goal.

The blogger acknowledge that the use of the word “unethical” as a hyperbole ton drive engagement.

The real-world issue is that we need to get stakeholders on board with the idea of having to do extra work that is not required to deliver a feature. If you tell a manager that you need to spend a month rewriting a system that was just launched, they will laugh at you.

Technical debt is very real and can complete fuck companies.

Even though the situation you described is unfortunate, I don’t think it has any relationship with the concept of technical debt.

The term “technical debt” conveys the idea that a resource is invested in a way that requires to be repaid later. The whole concept revolves around the idea that taking shortcuts doesn’t eliminate the need to actually do the work to make things then right way. Rushing to a deliverable can leave a mess in your wake, but cleaning up that mess is also work that needs to be done and doesn’t magically go away.

Does anyone have any good sources or suggestions on how I could look to try and begin to improve documentation within my team?

Documentation in software projecte, more often than not, is a huge waste of time and resources.

If you expect your docs to go too much into detail, they will quickly become obsolete and dissociated from the actual project. You will need to waste a lot of work keeping them in sync with the project, with little to no benefit at all.

If you expect your docs to stick with high-level descriptions and overviews, they quickly lose relevance and become useless after you onboard to a project.

If you expect your docs to document usecases, you’re doing it wrong. That’s the job of automated test suites.

The hard truth is that the only people who think they benefit from documentation are junior devs just starting out their career. Their need for docs is a proxy for the challenges they face reading the source code and understanding how the technology is being used and how things work and are expected to work. Once they go through onboarding, documentation quickly vanishes from their concerns.

Nowadays software is self-documenting with combination of three tools: the software projects themselves, version control systems, and ticketing systems. A PR shows you what code changes were involved in implementing a feature/fixing a bug, the commit logs touching some component tells you how that component can and does change, and ticketing shows you the motivation and the context for some changes. Automated test suites track the conditions the software must meet and which the development team feels must be ensured in order for the software to work. The higher you are in the testing pyramid, the closer you are to document usecases.

If you care about improving your team’s ability to document their work, you focus on ticketing, commit etiquette, automated tests, and writing clean code.