Tuesday, April 05, 2011

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?

15 comments:

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.

Shannon -jj Behrens 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...

Shannon -jj Behrens 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.

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