HN Explorer

Ask HN: How do I become a faster programmer?

53 points by hoodoof ↗ HN
I want to be a faster programmer, to increase my coding speed.

How can I do that? Is it even possible?

At the moment I feel like I have no choice but to go at the pace that my mind allows me to operate at.

70 comments

[ 15.1 ms ] story [ 137 ms ] thread
roma1n
To gain speed, I'd say get extremely familiar with whatever standard library your language/platform of choice uses.

Disclaimer: I am not a fast programmer.

s_kilk
Agreed. one of the biggest speed boosts you can have is not needing to look up the documentation for your tools every thirty seconds.

So, either get more familiar with the tools, or use simpler, more effective tools, or both.

gamesbrainiac
Build a network, and ask for help whenever you are trying to do something unfamiliar. The problem is never how fast you write code, but how quickly you can add new features.

Having a large and supportive network allows you to quickly overcome obstacles and piggy back off of other people's expertise while developing your own.

hoppi
Anything brand new will be taxing on the brain, once you have solved a similar problem though it will be easier and faster. Just another case of learning and utilising what you've already learnt.

Everyone has their own pace, some may just be naturally faster and that is ok. They also might make more mistakes (bugs).

As other posts have mentioned, learning the language and libraries will help you massively.

polskibus
You are faster when you solve a given problem for the second time in your life.

By solving a problem I mean not just decomposing it mentally but also executing the solution with chosen technical framework.

Practice a lot, pick a framework or two and understand its inner workings very well - that's my advice.

DrJokepu
Try to solve problems with less and less code. It will be quicker to write and you'll have a smaller number of bugs to fix.
woah
Actually cranking it out faster might be possible, but is probably not useful. You will see the biggest gains in speed by learning how to code in such a way that saves you labor in the long run. Expressing your ideas concisely will allow you to accomplish more with the same amount of code. Expressing them clearly will allow you to spend less time puzzling about it later. Tooling and library selection is also big. Know what will save you time and know how to use it effectively. Lastly, it's also important to know when to stop trying to abstract and perfect, and just write dumb code to get things done. You've got to have a good balance of smart and dumb.
QuantumRoar
You can't program (correctly) faster than you can think. However, you can practice the translation from thought to code by understanding your language really well and by getting a lot of experience with the kinds of things you do.

For example, the first time you code a linked list, it's going to take some time to get used to how it works and to program it correctly. The second time, you might still need to look something up. However, once you got used to the abstraction, you can simply type it down as fast as your fingers allow.

This has nothing to do with what your actual goal is but rather it's the process of translating your thoughts to a particular abstraction that you can directly write down in code in a particular framework (the programming language). This abstraction layer varies for different programming languages and you simply need to get used to it and gather experience.

I think of it as trying to speak a foreign language, e.g. English for myself. I'll never get faster than in German at saying what I want to say (albeit, there might be cases where English is way more efficient). The entire process is simply limited by how well I'm able to translate thought into the abstraction layer of speech. As everybody will tell you, this skill is greatly enhanced by actually using the language in various contexts until it becomes intuitive.

flyinglizard
By first becoming a slower programmer. I know it sounds very zen-like, but when you give it some thought, you'd discover that most of your time is spent bug fixing. Worse for us embedded guys, as it's really easy to get into the build-download-run cycles and each takes much more time than a typical run cycle on a .NET environment, for example.

Just realize that actual coding is the easy part, and concentrate on slowly and properly designing what you're going to build and reviewing what you just wrote. If I'm building something complicated, I'd take a day, maybe more, just to think about it slowly. You can't rush a thought process. I'd implement it, and I'd review it multiple times before even running it. Makes for the fastest development, unless you're just thoughtlessly hacking on something inconsequential.

tormeh
I guess it depends on the seriousness of what you're doing. In programming normal, non-critical code, Python and exploratory programming will speed you up quite a bit.

But if most of your time is spent debugging, then taking your time is probably worth it. And use tools that makes a lot of bugs impossible: Use a memory-safe language with strong typing and concurrency abstractions that prevent data races etc.

If you're making a big system where remembering where everything is is half the job, a good IDE with solid auto-complete might help. I'm a big fan of MS Visual Studio, though it has limited programming language support. I've heard good things about Intellij too.

If most of the code will be written by someone else then you want an opinionated programming language that enforces a certain style, like Ada or Go.

Finally, if your problem has already been solved, don't solve it again. Use Erlang for distributed systems, Ada for critical systems, Esterel for extra-critical systems that can afford to be slow, etc.

jameskilton
Very much this. Software development is not a race to write down text to a file. The majority of what we do is thinking, the coding part is the final result. What does the user need to do? What can go wrong? How does this fit into the overarching system? Does the design need to change to accommodate this feature? and so on.

> At the moment I feel like I have no choice but to go at the pace that my mind allows me to operate at.

This is perfectly fine and exactly where you should be. If you force yourself to work through problems faster than what your brain wants you to do, you will make mistakes and spend more time cleaning up after yourself.

Following from that, to be a faster features developer, I have one simple solution: write less code. It's taken me 10 years to understand the wisdom in this but I assure you it's true. You will move faster, you will write better code, and you will stop hating your past self so much.

As much as some people argue against this, software development is a creative process. Creativity takes time. There are times where you are writing rote, boring code, and for that you can speed up with editor tools (IDE stuff as another commentor said) and learning to type faster, but make sure you recognize when you need to slow down, and you'll find yourself becoming much more productive.

brudgers
The analogy I like is cornering a race car. The fastest way through a turn is a combination of velocity, distance, and traction. If the speed is too great, the line is too long. If the line is too tight, exit speed is too low.

Or the race car spins out.

falcolas
As a corollary to this, increase the size of your toolkit. The more tools you have available to you, the more likely you are to have a tool which solves the current problem in a way which is correct, clear, and concise. You'll also be better able to determine when to, and when not to, re-invent the wheel.

By toolkit, I mean:

- Programming paradigms

- Patterns (and Anti-Patterns)

- Metaprogramming

- Knowing when to mutate, and when to not mutate

- Algorithms

- Data Theory

- Knowing the value of stepping away from your code

techjuice
The first step is to insure that you have increased your regular typing speed (wpm or words per minute) by doing the regular keyboard speed tests. Keep doing these until your average speed is in the 200 range or higher.

By doing this you will also increase your reading speed which also helps increases your programming speed. Your mind is the fastest thing you have, it is the translating of what you are thinking or seeing to typing that slows one down. This is why there has been work on trying to use your brain waves as an output device so you can bypass having to type what you are thinking or reading.

Erwyn
I assume you were speaking of CPM (characters per minute) and not WPM (words per minute). Otherwise, I will really would like see you typing on a keyboard that must be a hell of a show :p
johannesboyne
It is a difficult question, and actually not quite clear in what context you want to gain speed. Is it the pure coding or is it the development of solutions? I'll go for the later ;)

Structure your work and try to develop a strategy. So think about (w)hat, (w)hy, ho(w), (w)here, (w)hen. - What: What is the core problem to solve? - Why: If it is a 'problem', why is it a problem, is there an existing solution? If not, why is the feature important - empathize with the feature request. - How: What is your strategy, how do you want to conquer this task? - Where: Where does the solution has to be implemented to fit best? - When: Programming is a process (a timely and logical sequence of activities which are required), thus define what step has to be done before the next. Example: one should not start with the development of a "user scores database" if the main objective is to build a jump-and-run game.

These steps are helping myself to be more productive.

[deleted]
(comment deleted)
chrisxcross
Don't google every error and use the top answer on stackoverflow to fix ist. Read the docs and try to understand why your solution didn't work in the first place. Basically this results in getting familiar with stdlibs and/or frameworks.
lwh
Sit in a quiet room, alone
eemax
Learn to use your tools (e.g. your text editor, shell, window manager, etc.) like a pro. Learn keyboard shortcuts and the advanced features, and customize them to make them your own.
M8
Forget about maintainability and pick a language that hides errors: Python is good, JavaScript is even better.
fsk
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.
azam3d
Tips to be competitive programmer

0. Type code faster

1. Quickly Identify Problem Types

2. Do Algorithm Analysis

3. Master Programming Languages

4. Master the Art of Testing Code

5. Practice and More Practice

Read more about competitive programming free PDF book here. The tips are on Chapter 1.2

http://www.comp.nus.edu.sg/~stevenha/myteaching/competitive_...

keyle
1- Learn your tools inside out.

Find out which shortcuts would give you the best keystroke / time earned ratio.

2- Sharpen your skills inside out.

Truth is, to be very fast at something, you must have done it many times before. I don't believe one can be fast at problem solving if it's the first time.

Once you get the usual patterns squared, you can get quite fast at implementing them.

3- Write in a more functional fashion

This has a strong tendencies to reduce bugs and that's where massive time wasted can go.

4- Improve your understanding

Often slow speed is due to a lack of full understanding. Draw and redraw a problem on paper until you have a good grasp of the problem. Mix it with other concepts of real life (ie. arrays and stacks of dishes)

I think we were all slow before we were fast. Still there are many devs faster than me. That said, I think creatively faster than them. I think we all have our advantages/disadvantages based on the way that our brain is wired.

keenerd
It is just like optimizing any piece of code. Log everything, identify hotspots and improve them.

1) Time yourself. Keep a little text file with timestamps and brief fragments of what is going on. Do this every time you have a mental context switch, start a new sub-goal, accomplish something or give up on an attempt. Usually I find myself logging something every 5-15 minutes.

1B) Documentation lookups should not be manually logged. Instead flush your browser history for the day before starting and then save out a copy of that when you are done programming.

2) Once finished, identify and eliminate time sinks. If you spent 15 minutes writing boilerplate, refactor that out for the next time you need it. If you spent 15 minutes looking for correct bit of previously refactored boilerplate, organize your archived code. Look at what parts of the documentation you visited the most and study them.

3) Always be trying new tools. There is no such thing as a silver bullet, but there are some pretty impressive special purpose alloys. While tedious, it is worth running previously-solved challenges though the new tools. (Subtract out the time spent just thinking during the old run to correct for the additional experience on re-running it.)

4) Practice! Find the smallest "unit of delivery" and deliver that as often as possible. For example if you do games, do game jams.

By following these I am now 60x faster for one subset of competitive programming (Mystery Hunt style puzzles).

hoodoof
This is the answer I was looking for. Especially point 1.

Wish I could give multiple upvotes.

Organized optimization!

falcolas
I particularly agree with point 3. We're programmers who routinely automate other's tasks, we should spend some time each week automating our routines.
sairamkunala
If you want to write code faster - I have 3 letters for you - I D E. Learn your IDE, be it vim, textmate, IntelliJ or emacs.

I used to use textmate (w/ default plugins) for HTML, CSS, Javascript and Ruby. Now I discovered IntelliJ does stuff really fast and works.

IDEs/Editors have macros help you perform repeating work fast.

TextMate allows you to run shell commands inside the editor which is pretty useful. There are few for Ruby if you want to see output of an execution as a comment (see Avdi's screencasts).

There are shortcuts for performing tasks. In case your IDE does not provide, use the ones which your operating system supports. Example for Mac OS X - you can use Apple Scripts, Alfred, Keyboard Maestro etc.,).

Take time reading your IDE manual or help. Graphical UIs show tips and suggestions. console based provide tutorials when you open without arguments. With vi, use :help and follow the article. It takes months or even years to understand and learn your IDE.

Talking about downsides, once you start using your IDE a lot, you will learn about the downsides like 'pinky finger problem on emacs' (Google for this), and then you'll realize you have to customize your IDE. Note: These are good to have problems because you realize you are advancing.

For HTML, ZenCoding as a plugin came out 3-4 years ago where you can use div.container>div.hello+div.details>span>a*3 (on tab) will expand and give you html.

StackOverflow has lots of answers and details on discovery of productivity tools.

coldnebo
I would also add: get to know your debugging tools really well. I'm constantly surprised how many developers still use print logging to debug issues with data structures. Sometimes it's hard to visualize what's going on in your mind or with the code, why not let the computer "play computer" and actually see what it's doing step by step.

We may not have the real time integration that Bret Victor demos, but a call stack, watch list and breakpoints are a beautiful thing when you know how to use them.

A REPL like Ruby's pry is also invaluable for exploring return data and playing with data access syntax right in the console without long tedious trial by error sessions. (I know this annoys the purists who think you should know the data structures beforehand -- they are right; if you know what you are doing, of course you'll be fast -- but sometimes even the smartest of us don't know a service api changed without popping the hood.

Use all the tools you can to understand what your code is really doing, not just what you think it's doing.

[dead] sairamkunala
Faster writing code. I have 3 letters for you - I D E. Learn your IDE, be it vim, textmate, IntelliJ or emacs.

I used to use textmate (w/ default plugins) for HTML, CSS, Javascript and Ruby. Now I discovered IntelliJ does stuff really fast and works.

IDEs/Editors have macros help you perform repeating work fast.

TextMate allows you to run shell commands inside the editor which is pretty useful. There are few for Ruby if you want to see output of an execution as a comment (see Avdi's screencasts).

louwrentius
The programmers who get the fastest results are the ones who sit down and think/design first before they write a single line of code.
anthonyby
@flyinglizard already mention zen-like style. So, stop using stackoverflow programming and do really deep digging about every aspect.