Not every job needs this, but when your company has a lot of code, it helps as a newcomer to spend time writing documentation. Those who “level up” in this skil

Not every job needs this, but when your company has a lot of code, it helps as a newcomer to spend time writing documentation. Those who “level up” in this skill can write documentation everyone understands, not just other programmers. For instance RML instead of UML: https://seilevel.com/business-analyst-resources/rml-book/ https://seilevel.com/business-analyst-resources/rml-book/ Now, if you have BA resources on your team, or designers/UX folks, then use them. There are teams where other people do the business-understandable diagrams and you’re doing technical ones. But... if your team is smaller, or the code is already written, then it’s just as helpful for you, as the developer, to also be the one communicating how things work to the business and stakeholders. It will help everyone use the same terminology—simplify decision-making—and since you made the documentation while looking at the code or existing APIs, you can assure folks it is relatively complete and accurate. https://www.youtube.com/playlist?list=PL2miG2CzrxakbZswQH-O43G5VnJ0_CB8C&feature=share https://www.youtube.com/playlist?list=PL2miG2CzrxakbZswQH-O4... has some videos on business-friendly documentation and SeiLevel folks also contributed to two Microsoft Press books on software requirements and visual models. I’ve found that mapping out the business domain, or explaining complexity, is at least half my job sometimes. Advocating for SRE best practices seems to be the other half. ;-) For very large systems, DSMs are interesting. https://mitpress.mit.edu/books/design-structure-matrix-methods-and-applications https://mitpress.mit.edu/books/design-structure-matrix-metho... But generally extremely technical and useful only to those creating the DSM. Oh— also ASTs. Kind of a form of code documentation, but knowing how to use AST Explorer to read and modify a call graph or source code is incredibly liberating. It’s great to suggest we can make breaking changes and fix them in client code using an AST transformation, etc. Finally, “A Philosophy of Software Design” was a nice quick read that I still get value from, but it doesn’t address how tests and ASTs could help; it covers the evergreen basics though.