Ask HN: Which tools have made you a much better programmer?

Using an actual, proper IDE instead of text editors with plugins that have so-so language support.

Learning how to operate a computer efficiently. Use keyboard shortcuts. Set up scripts for commonly used tasks. Configure our environment and operating system so it's less annoying.

Being efficient at using a computer also makes you annoyed at poor UIs, and as a result, better at building great apps.

The ability to write things down, and finding joy in writing documentation. I'm continously surprised at how many people will have a 3 hour meeting and just not write anything down, or never make any comments or READMEs in their projects.

Understanding to use the right tool for the job. You don't need to use the latest and greatest container orchestration, library, or whatever.

Not caring about non-business effecting minutiae, like spending time doing code-style nitpicks in pull request comments (when automated tools can do the job), has made me more efficient and less tolerating of the tendency programmers have to focus on non-important things.

Foreman

https://github.com/ddollar/foreman

When I learned Ruby a while back. I know it doesn’t sound like much, but it was the first tool I’d used in development that showed me how I develop is critically important.

It’s just a simple tool to start and stop several tools in the background, streaming the logs to all of them in one place. At the time, I’d never seen anything like that and felt like I’d been doing it wrong for years.

Well, it's certainly not tools that let me add lines of code.

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/ 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-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-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.

Still no mention of clipboard manager?