Skip to main content

I Code Sooooo Slowly!

One thing I've learned over and over is that a programmer's skill with his preferred editor is no indication of his skill as a programmer. One of the best programmers I know stuck with Pico for years! Certainly many of the programmers mentioned in "Coders at Work" use Emacs without even trying to learn it well.

If you've been reading my blog for a while, you know that I'm obsessed with productivity, especially when it comes to editors. There's a reason why. I'm slow...really slow!

When I was at PyCon, I participated in a coding challenge. The grand prize was a MacBook Air, and there were only 8 participants. I figured I stood a good chance at winning the MacBook Air which I needed since I was leaving Twilio.

The challenge used SingPath:
SingPath is the most FUN way to practice software languages! SingPath provides a platform to those that want to test their programming skills in a competitive and fun environment.
(By the way, did you notice that it's spelled Singpath in the title and SingPath in the introductory paragraph?)

Anyway, the challenge consisted of 10 questions that you have to write Python code to solve. I finished 6th out of 8! I was the slowest programmer among the professional programmers. It gets worse ;) The guy who won the competition was a Russian guy (I think). He finished all 10 problems in 10 minutes. I only finished 8 problems after 30 minutes. I would have finished the others, but I ran out of time.

It was definitely humbling to realize just how slow I am. What's ironic, though, is that I'm really fast at manipulating text in an editor. (Sometimes I use Vim and sometimes I use NetBeans with the jVi plugin so that it feels like Vim.) I can make text fly, but that doesn't translate into coding faster.

Fortunately, I have other assets as a programmer. For instance, my code is well known for being extremely clean, and I rarely have very many bugs. Nonetheless, it's frustrating that I'm so slow, and I really wish there was something I could do to improve my speed.

Having spent so much time futzing with my editor, I think it's clear that that isn't the problem. I think the problem is that my mind is constantly in "proof mode". I double check everything, code review my own code multiple times, think about all the edge cases, etc. Trying to code fast just doesn't work for me. When I did the programming competition, I was coding as fast as I possibly could. If I had taken my time like normal, I probably would have taken 2-3 times as long (but the code would have had really nice documentation and tests too).

Does anyone have any realistic advice for how I can increase my speed without sacrificing quality?


cool-RR said…
Dude, don't worry about it. "Slow and deep" is better in many situations than "fast and shallow."
Alex Conrad said…
I am pretty slow compared to other coders I know. But my code is pep8, docstrings, tests, ... I asked myself the same question "why am I so slow?", but it turns out that most of the bugs I fix are against code I did not necessarily write. My code usually tends to be pretty stable and thought throughout.
casey said…
I'm easily the slowest programmer I know. I consider this an asset. A lot of folks I know have a "throw away" mentality to their code. I know my code is not permanent, but I like to not be embarrassed by it. Not being embarrassed takes time for me. 8^)

And for every extra minute I spend thinking, and re-reading my code, I like to think I saved several later on down the road. I've written a lot of things that have run untouched for years, which makes me feel justified in being meticulous.
sagara said…
I wouldn't worry too much about it honestly... I assume the questions you had to code for were smaller things, which you may not be used to tackling; you can try doing more programming contents/etc where time is a factor. This'll let you practice thinking quicker about working on smaller throwaway stuff. Most of these lack the need for deep design decisions you're used to making.

When doing my own projects, I take things slower, spend more time pondering design/etc. If I have a timer over my head my tactics change somewhat. Generally tackling larger projects more often cause you to spend more time on design, compared to when you're just writing a throwaway script or small app.
Anonymous said…
Slow programmer here. I rely on Emacs to do most of my work (my .emacs is very long, about 400 lines).

The biggest thing that helped me was learning to touch type. If you don't know how, get gtypist and practice it right now.

As for being in proof-mode... not a bad thing. As long as your fingers move fast when they're moving, you're fine. Time spent upfront thinking and testing is time not spent later with a debugger or the issue tracker.

Captcha, interestingly enough, is emaus, which is one letter off from my most used program.
jjinux said…
Thanks guys. I feel a bit better. I know Alex and Casey; if they say they're slow, then maybe being slow isn't such a bad thing ;)

(Anonymous, yes, I do touch type.)
James said…
Yeah I concur. I'm pretty slow myself too. I think quality over quantity is a far better asset to have! Realistic advice? Practise solving problems...
Anonymous said…
I'd like to know a sample problem... like these people said, long-view good code is better, but I am curious as to the nature of the problems. And, can you ask the Russian winner? I'm curious how he did so well so fast...
Robert said…
I am slow coder as well. I went to work for a Perl shop. i didn't last long because they wanted "speed speed speed". I write good code. Just not fast.
Leon Atkinson said…
From a business perspective, the total effort spent on software is what matters. The old rule of thumb is 33% of time spent is in development and 66% in maintenance. I suspect many people shift the ratio towards the development time because it feels more predictable.

It's a right-tool-for-the-job situation. Some people are slower but produce fewer defects. Some are fast but spend a bunch of time dealing with bugs. Some people know how to do different speeds. But it's OK if you've only got one gear. It's just a problem of management.

Of course, if you're slow and you spend a bunch of time fixing your own bugs, you're not in the right profession.
markolopa said…
Things the have helped me:

- As you code, have always pylint or equivalent running in background. I am at least 2x more productive this way.

- From time to time, monitor everything you do in a day. Enumerate the tasks beforehand, make estimations, measure the time spent. This can give you good insights.

- If you procrastinate read the book by Burka and Yuen (a must). The key point is to understand that our activity is ruled by unconscious emotions. We have to learn how to deal with them. Distraction, procrastination, lack of focus, perfectionism, leisure, guiltyness, ambition, frustration are elements to master. For me mastering emotions is by far the most important element to improve productivity.

- Accept you limitations and don't feel guilty but don't say to yourself that there is nothing to be done. Accept expending time reading on the subject, asking for help, and experimenting new techniques.
Jaime said…
The competition reminds me of Pictionary. Haven't you find that, when playing pictionary usually the worst ones are the ones that knows actually how to draw?
They try to, well, DRAW a house, not make a box with a chimney. And they are slower.

Let's face it, the real work of a developer is most of the time to fix bugs (with some luck, your own bugs). If you're able to produce code with a reduced number of bugs, I think that's great news.

About using editors, I think the key point is to be confortable with the one you use, not feeling that the editor gets into your way when you have to do something. I try to improve my touch type and shortcuts knowledge a little each day, but without being obsessed. I really couldn't be one of those guys that each few minutes stops, curse and start again, just because the typos...
jjinux said…
> I'd like to know a sample problem... like these people said, long-view good code is better, but I am curious as to the nature of the problems. And, can you ask the Russian winner? I'm curious how he did so well so fast...

The problems were things like, "Write a function that given a sentence, returns the 5 most common letters."

I did ask the Russian winner. He said he used iPython to write and test his code. He also said that he mostly writes it perfectly the first time he types it in. Obviously, he really is talented.
Heikki Toivonen said…
I am another slow coder. However, like you, I tend to pride myself on writing it correct, including all the possible edge cases I can think of, the first time around with tests and docs. I know some people who write code much, much faster than myself with almost as good error rates as myself. I wish I was like them ;)

Sometimes, if I don't understand the problem well, my very first version only covers the most common use case(s) and no error checking, which I then expand. I find this helps me understand the problem better. The risk is that whenever I notice working this way the code tends to have more bugs than otherwise.

I use an ipython shell to try out things as I code and copy from there to my editor.

I Use Eclipse with the PyDev plugin and pylint enabled to catch typos and other common errors as I type.
Unknown said…
seems to me you should forget this quest. it doesn't seem valuable to me at all. clean code is really valuable:
* maintainability
* testing
* extensibility
* right algorithms
...golly! seems like every other comment pretty much agrees.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p