Ask HN: How do I become a faster programmer?

I agree with this, but learning how to use your tools will provide the initial boost, and let your tools get out of the way of your thinking.

I'm going to disagree with most of the comments here which say that you can't become faster, as I have become notably faster over the past couple of years (perhaps 1.5-2x faster!!).

Basically, it was a fairly major coding style change that happened after working with others in my industry (game development) and seeing their prolific output of high quality code.

My process for writing code used to be:

- Identify problem. - Identify the abstractions that fit the problem - Implement those abstractions - Write code to solve problem using those abstractions.

Now it is

- Identify problem. - Write code to solve problem, pulling abstractions out if and only if they make sense and would actually be used.

Honestly, I feel this leads to much better, cleaner and more understandable code, however, it tends not to mesh well with what some people consider best practices.

The resulting code tends to not be particularly object oriented, tends to have large functions, and tends to perform very well due to having a very small distance from what the code says to what actually needs to be executed by the processor.

For more on this approach, see

[0]: http://number-none.com/blow/john_carmack_on_inlined_code.htm... [1]: http://mollyrocket.com/casey/stream_0019.html [2]: https://www.youtube.com/watch?v=rX0ItVEVjHc

This is the wrong mentality, or is phrased poorly.

What you want is to become a better problem solver - solving problems better means you can then waste less time with stray thoughts and spend minimal time coding unnecessarily. For this, I highly recommend trying some elementary math proof-based texts in number theory, abstract algebra, or real analysis. With math, you learn how to structure your thoughts in a coherent fashion, then logically rule out deadend/inefficient lines of approach. Speaking personally, it has helped me immensely at figuring out the true source of bugs, and creating the optimal fix for them at an impressive speed - most of this work is without writing a single line of code.

When it comes to actually writing code, I have found it to just be an exercise in repetition. As you write more code, you become more familiar with what you can do, and with the right critical thinking skills, you can then become much faster.

Or pick a strongly-typed language, so you can find errors at compile-time instead of a couple months later when some weird hard-to-reproduce bug shows up.

I would recommend employing the Agile approach to development. Create and test a wholly working prototype of whatever you're working on, be it a new feature or extending a function. The key is that the prototype should not by any means be the final product, instead aim to create something that is working and accurate to a small step of the problem; an iterative approach to development. This way, your tests grow with the functionality of your code and if your code is well tested, it should function properly at every step of the way. Thus, by the end, you have a fully implemented whatever that has solid tests and should "Just Work". If this seems too slow or tedious, you can take the move fast and break things approach, in which you simply create a rough prototype of how you think the code should look, and work through the bugs until it does what you want. You should still write tests, especially to help determine when you've properly fixed the implementation. Keep in mind this involves a stronger sense of underlying problems in bugs and needs good debugging skills to be effective. It can take more time though if your initial prototype is too far off.