Writing system software: code comments
When I interview for jobs, one of the questions I ask is where the team and engineering org stand on code comments and what state of documentation do they have for legacy code. It&#x27;s a good question because people will use excuses like IP protection to avoid talking about the ugly truth of the state of their actual code, but if you&#x27;re just asking about comments and documentation, there&#x27;s no reasonable way they can deflect the question. If they won&#x27;t answer it, well, you&#x27;ve got your answer.<p>Any place that takes an attitude of &quot;code should be self-documenting&quot; I just walk away from. That is a type of dysfunction you&#x27;re not gonna be able to solve. Also places that say, &quot;we&#x27;re always evaluating new ways to improve documentation practices...&quot; begs further questions to get the specifics out of them.<p>For most jobs, I know I&#x27;m going to have to deal with bad legacy code. But if there is also a culture of not documenting things, arguing against comments or formatted API and function documentation, and it results in documentation spaghetti of Google docs, Markdown files, spreadsheets, emails, confluence pages, etc., then there&#x27;s no point. I can&#x27;t help you.