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

This, most of all. Substitute native language if not English; the important thing is that the project be defined and developed in both a human language and a computer language, so that mismatches can be identified and resolved.

  * Start by describing what you are trying to do.
    * Specifically.
    * Not 'build a web business to enable users to achieve their
      potential', not 'create another library for X but simpler'
      but *specifically what the software will do* and, most
      importantly, the priorities of scope increase (it'll happen
      anyway; just get the priorities and their order down in
      text ASAP).
    * Put it in a readme.txt or something.

  * For any given subsystem of the code (meaning: any section
    which can sort-of stand on its own) write another such file,
    in more detail.

  * Let these files guide your tests too.

  * Keep them up to date. If priorities change, *start* by
    updating the readmes. The code isn't immutable; nor is the 
    plan. But the plan comes first.

  * When unsure how a new subsystem or feature is going to work,
    write out your ideas and thought processes in text. Don't
    start coding at all for a day or two after you sketch out the
    basics. *Append* to this file instead of replacing large
    parts.

[edit] Wasn't intended to quote that part (sorry to mobile users) but I can never remember how to get bulleted lists on this site...

I agree. I’ve been using IntelliJ ultimate for a few months now and I don’t see myself going back to sublime or emacs. I do work mostly with ruby, typescript, golang and occasionally clojure. I recently found out that with the Ultimate version, you can install all the language plugins and won’t need the other IDE like Goland, rubymine, webstorm etc... They’re just plugins. So all your settings can live in one place

Resharper (and now all the various Jetbrains tools) - from the early days, this tool allowed you to aggressively and automatically refactor code. Before that, in the C# world ( and many other languages ), there was very little in the way of automatic refactoring tools. Not to mention it's automatic suggestions on code transformations or more efficient use of the language are super useful.

Vim Bindings - While I often don't use Vim, I use Vim binding in most any environment I use. I don't know if it really made me a better programmer, but it improves the experience of programming.

Unit Testing tools - making code testable makes code modular.

Visual Studios Debugger, fantastic debugging tool from years and years ago. While I don't use it as much anymore, it's been a useful tool in understanding code.

Google Search, transformed the way to get information, coding information was hard to come by a few decades ago, now it is prolific.

Yes it is - France has colonised part of vietnam

Not sure if this is what antirez had in mind, but when I'm working on stuff, I whiteboard (if I'm at home--and who isn't these days) or write in a notebook.

First thing I figure out is how I want to interact with a thing. Whether that's a program or a class or a function. How do I want to call it? What parameters do I want to pass? What do I want it to return? How do I want to use what it returns? So, basically, write the interface first.

If I'm building something with multiple parts rather than a single class or function, I'll map out how these things all work together. A loose graph of interactions. Invoke A and have it return X; invoke B and pass X to it and it returns Y; etc.

Then I'll consider failure modes and think about what should happen if something doesn't work out quite right. Is it possible to route failures to a centralized cluster of error handlers so I don't have to implement error handling at every level?

Finally, I'll think about whether I can map behaviors to defined data structures instead of controlling flow with if/else patterns.

Once I have all that written down or mapped out, then I'll start implementing from the outside in. Stub the object, methods and return dummy data structures that fit until I have a complete system that's interacting the way I want. Then I go in and implement the actual functionality I need.

The last part--implementing functionality--often implies modifications to my initial thought process. But it's easier to understand what those changes affect if you've already mapped your design. So you might think B can produce Y with I parameter. Maybe it turns out you can't. So now you need to add a new param. Where is that going to come from? Well, you don't have to invent that out of nowhere because you've already mapped out what is happening. You know that you need to either add another node to the call graph or change the return value somewhere else.

By the end of the process, you have a working program, and you've also done a lot of your documentation work as well.

Again, I have no idea if this is what anyone else is talking about here. But this is how I personally work. It annoys the hell out of some people. But it works for me and helps me create sane software with interfaces people can remember over time.