My last job evaluation included just one weak point: timeliness. I'm already aware of some things I can do to improve this but what I'm looking for are some more.

Does anyone have tips or advice on what they do to increase the speed of their output without sacrificing its quality?

How do you estimate timelines and stick to them? What do you do to get more done in shorter time periods?

Any feedback is greatly appreciated, thanks,

  • 96
    Spend less time on SO at work, if you do so. – San Jacinto Sep 11 '09 at 15:16
  • 52
    If you are reading this, it's already too late – OMG Ponies Sep 11 '09 at 16:28
  • 32
    I read "How to become a fatter programmer". Made me laught – marcgg Sep 11 '09 at 16:39
  • 13
    I would ask you a follow-up question. Is your desire to be a "faster programmer" a result of your own poor performance (AKA, you need to hone your skills, you need to focus and eliminate distractions (such as SO), etc), or is poor planning from a development standpoint (AKA, you were given 1 week to do something that any sane person would have known would take 1 month). Each item has very different solutions. – JasCav Sep 11 '09 at 20:21
  • 3
    There's no single right answer possible, so make it into a community wiki question or have the question closed on you. – Donal Fellows May 30 '10 at 15:42

87 Answers 87


What are your time bottlenecks? I find that thinking is my usual bottleneck, so improving my typing speed (already good) would do approximately nothing. On the other hand, if typing is not fast and natural to you, it may well be slowing you up.

Are you trying to do more than is required? Usually, a business will want lots of good work out of you rather than less but more polished work, and adding features that aren't going to be used wastes time and money with no business return.

Are you being too hasty? Under time pressure, people frequently skimp on up-front design and planning, hoping that it'll work out anyway. It frequently doesn't.

Are you handling time properly? Development requires chunks of uninterrupted thinking time, or you'll be inefficient, and hence slow.

  • Nice. An answer that describes how to fix the problem for the asker, not how the answerer fixed the problem for himself. – Beska Sep 11 '09 at 17:33

Read Neal Ford's excellent book The Productive Programmer.

It's full of lots of useful tips.


And, as mentioned elsewhere, read the docs for your tools. I'm always learning new things for Vim by reading Vim wikis. Similarly, just reading through the man page for bash or zsh always gives new tricks to use.


I read something a long time ago about optimization that really stuck with me. I don't remember the source or the exact words, but the gist of it was, "The only way to make a program run faster is to make it do less. Any other plan is just that." The same goes for humans. The army also has a saying, "Haste makes waste." Doing the same things we do now, but faster, will only create problems. There are many different plans for becoming more productive out there, and I'm not saying they aren't effective, but they won't be tailored to your needs. You're better off looking at what you do and finding the things you do that aren't productive, and cutting those out. Any other plan is just a watered-down version of that.


Here's what works for me:

  1. Break your work down into small tasks which are (1) defined in scope (2) short - e.g. 2 hours.
  2. Start the day by writing them down on a paper, in order. Draw some lines through - stuff you expect to get done before lunch, stuff you'll get done by end of day, etc.
  3. Work your list, crossing items off as you go.
  4. Time box things - if something's starting to drag, give yourself a time limit to research before you ask for help, or solve in a simpler manner.
  5. If possible, structure your work so that you're publicly committing to these timeframes - entering estimates in bug tracking, etc.
  6. If you catch yourself killing time researching, reading, etc., then invert the order - for example, allow yourself a 10 minute reward if you successfully complete a 1 hour task on schedule.

I've seen several comments that you should spend less time on Stack Overflow. If you're using it right, Stack Overflow should make you more efficient, not less. Steer clear of discussions and focus on using it to get work done.

  • Time boxing is a good suggestion. It has interesting side effects: when you force yourself to stop working on the problem (read: banging your head against something that you can't yet grasp), your subconciousness kicks in and you often see the problem in a new light. I just realized that I haven't read too much about time boxing as a work methodology. Does anyone now if there's any good books about it? – tequilatango Sep 12 '09 at 9:03

Don't Repeat Yourself

Re-use old projects assets.

Take a day to learn your IDE. If it doesn't provide tools like snipets, code auto-completion... consider getting a new one.

Put shortcuts to everything in key places so you can access things faster.

Get a second screen if that's not already the case.

Don't check your emails too often.

Try focusing on only one task at a time. If this is not possible, keep close track of what you're doing and don't get lost between 15 unrelated tasks.

Use paper. When I work I always have a printed version of my tasks on which I can take notes, cross off and so on. It's way faster than going on a different screen to read something or write something. At the end of the day I take 10 minutes to copy everything into the system. I realized it saved me some time every day.

  • Huge - one task at a time !!!! – Brad8118 Sep 11 '09 at 17:04
  1. Develop yourself more and more as a programmer, every day... Learn design patterns !
  2. Use TDD, but in a proper way, the bugs you can have in your code is the single-most time-consuming thing.
  3. Use ReSharper :)

Since many of the other answers talk about doing designwork, I'll just stick to the pure mechanical aspect of coding faster. Most of this is probably obvious, but I'll say it anyway since I notice that many of my co-workers don't do some of these things.

Remap your IDE keyboard shortcuts so you can do most of them with your left hand. This frees up your mouse-hand for fast and furious code outlining/refactoring.

Learn how to navigate your cursor and select text using a combination of Ctrl, Shift, arrow-keys, Home and End.

Below is my C++ setup ( Visual Studio with Visual Assist X ). I have a Norwegian keyboard, so please bear with me:

Alt-Z : Change between .h and .cpp

Ctrl-Shift-< : Context sensitive jumping through references. (< for me is the key left of Z, you english guys don't have one of those. Map it to Ctrl-Shift-Z then. )

Alt-| : Implement method. By writing the header first and just hitting Alt-| all the time you can make the whole class outline in a few seconds.(| for me is the key beneath escape.) This is especially true if you place the cpp and header files next to each other in the text editor so the header doesn't get obscured every time you perform the action.

Alt-R : Renames symbol under my caret.

Alt-D : Adds a documentation template for the selected function.

This, in addition to lightning fast code completion, makes left hand refactoring possible.

  • And, use and abuse code completion! – scottm Sep 11 '09 at 20:52

Code snippets, experience and never ceasing enthusiasm. Always read stuff: programmer blogs, books, literature, other peoples' bad code. You'll get faster if you get a wider view on stuff. If you can imagine all kinds of complex background processes involved, and you really know the whole complexity of the target system.

The Pragmatic Programmer's Handbook is kind of awesome: it's about best practices and major pitfalls of many different aspects of software development. Rubber ducking and stuff sounds blatantly nerdy and stupid. However the nature of most programming problems is that we tend to think much too complex. I'm a great fan of simple and easy solutions: no great tricks, no super-elegant hacks: just using the simplest solutions.

If your team is good you can try to work collaboratively: Bespin and some other frameworks nowadays allow editing one file together. That's awesome if you're really into it and see your coworker doing the magic ;).


Try checking your emails with longer intervals and stop using online social tools like Twitter, facebook etc.

Use this wallpaper.

Try to work with open front view. I usually use conference room when its free, it helps me focus!

Try to work with other programers around you.


The trick is not to write code faster, but to write working code faster.

The sooner your spot a bug, the less effort it is to fix it - this is the primary thing which affects programmer performance.

It's not about how fast you type, or how fast your compiler is, it's about the speed at which you can identify bugs and fix them as you go.

Therefore, I'd suggest pair programming as a way to be faster - it really does avoid bugs. That and test-driven-development. Having two pairs of eyes makes it more than twice as hard for bugs to slip through (I think anyway).

Other tips would be

  • Try to reduce your code-test turnaround time to a minimum - this obviously depends on your platform an tools. If you're working on a silly embedded system with lame tools, turnaround time could be quite signifcant (for example if you need to rebuild a system image and re-netboot the device), VMs or simulators can help here.
  • If not pair programming, ask others for informal code reviews occasionally, but only at logical breaks in your (and hopefully their) flow. Do this in addition to your formal code review process you doubtless have.
  • Keep it simple - don't over engineer. You ain't going to need it.

Write your own productivity tools. They may take time initially to write, but the pay off can be big over time.

Some tools that I've written that I use all the time:

  • An SQL formatter.
  • An automatic SQL generator: just select the tables.
  • A simple task prioritiser, so I can see all my tasks in one go.
  • A task reminder that nags me periodically.
  • An app that takes delimited text and allows you to treat it like a spreadsheet and like text.
  • A PHP/Javascript/HTML page formatter. A godsend when working with others' code.

I've written lots of other small tools in my time that have fallen by the wayside, but it was still worth the effort.

  1. I really enjoy listening to music while I program because I feel like it relaxes me and I can focus.

  2. A comfortable chair. I don't ever use my school's computer labs to program because the office chairs are incredibly uncomfortable.

  3. Eat something beforehand because nothing kills my motivation like nagging hunger.

  • ++ If I could expand on the chair - you need to sit upright, have good lumbar support, have your keyboard / mouse down low, and your monitor up high so you are looking straight at it. The chair should support your forearms and not your elbows. Ideally it should give good ventilation to carry away perspiration. – Mike Dunlavey May 30 '10 at 15:41

Practice. That, and getting your hands on productivity tools that allow you to go faster.

For example (you didn't mention the platform on which you work), in the .NET environment, there's Resharper.

  • 4
    Be aware that tools like Resharper work both ways: they are great for cleaning up old code or refactoring to a better design... but you can also get sucked into pointless cleanup that soaks time that could otherwise be producing functionality. I would say that the productivity increase probably offsets the cleanup and in the long run you have better code... but it isn't a silver bullet to being more productive by any stretch. – Godeke Sep 11 '09 at 15:00
  • Nice point. +1 for you. – user2039 Sep 12 '09 at 11:55
  • @Godeke: Nice point. Resharper can be a time sink as well. – Jim G. Sep 12 '09 at 15:50

Re-negotiate the estimates and timescales. Make sure you are the one who says how long something will take, and don't succumb to any "well, we need it done sooner" or "how about a stretch-target" suggestions.

Read Joel Spolsky's article on estimates, which basically advocates breaking the piece of work into small chunks, and estimate each one. If any of them are counted in days, break them down further until you have everything estimated in hours.

  • "If any of them are counted in days, break them down further until you have everything estimated in hours." -> No - Your estimates should never be more granular than "half days". Compiling estimates that are more granular would be a waste of your time. – Jim G. Sep 12 '09 at 15:49

You and your boss/evaluator need to determine how much time you actually have to program. Take out the meetings, emails, documentation, testing, other interuptions from the time you are expected to work and see what is left.

Try to monitor your time to get a benchmark of how long certain tasks take. There will be productive times (for me early in the day or any stretch of time I get at work without interuptions) and unproductive times. Find an average.

You may determine that a given task takes 8 hours to program, but I doubt you will get that done in one day.

I would also try to compare yourself to others. The corporate culture may be to put in a lot of hours.


Well, I think I'm not slow, but the work I'm given tends to fill the available time.

Regardless, I oftentimes hear "Gee, you did that quick", but it's not from being a fast coder, it's from coding less.

I think the main way to code less is to think like a DSL. If you can't get the code generated for you by a preprocessor, then write a code generator. It doesn't have to be fancy. The objective is, if you are given a single stand-alone requirement, to minimize the number of source code differences needed to implement that requirement. Ideally, that number is 1. If you can get it down around 3-6 on average, that's pretty good. (It's not just that you're writing less. The smaller this number is, the smaller is the number of bugs you're putting in, and that really saves time.)

To do this, I recommend doing performance tuning, because then you will find out what coding practices lead to the greatest slowdowns, and they also lead to bloated code. In particular, excessive data structure and event/notification-style programming. Those things alone contribute massively to code volume.

Much code volume these days is due to the user-interface, especially if it is dynamically flexible. I stumbled on a way to do that part, called Dynamic Dialogs, which has a tough learning curve but shrinks the UI code by roughly an order of magnitude.

You'll have to find your own way on this, I'm afraid, but best of luck.

  • I really like the first sentence. – Beska Sep 11 '09 at 21:00
  • An excessive preoccupation with performance tuning will lead to premature optimization and will slow you down. // Also, many times, performance tuning and premature optimization leads to unmaintainable code which will rob you of your precious time. – Jim G. Sep 12 '09 at 15:40
  • @Jim: Certainly you want to avoid the premature optimization part, because that is another form of guessing. What I've found, though, is if you take a big program, and do performance tuning on it, you find out that what makes it slow is also what makes it big. That experience leads to designing things better in the future, so they are simpler, faster, and smaller. But without the tuning experience, you don't learn that lesson. – Mike Dunlavey Sep 12 '09 at 21:33
  • ... I know it's counterintuitive, but that's my experience. The link I gave above is a pretty good small example of how by tuning a "pretty good" program you can make it both faster and smaller, and learn from the experience. – Mike Dunlavey Sep 12 '09 at 21:37
  • ... and the idea that performance works against maintainability is also another common idea that many people believe, but isn't necessarily so. This field has a lot of those beliefs. – Mike Dunlavey Sep 12 '09 at 21:40

Keep your personal life in order. Get lots of sleep, eat healthy, and take vitamins - especially if you have an iron deficiency. Stay away from "the drink" - if you know what I mean. And remember, "Both Wine and Women can lead a wise man astray."

Also, create templates of your code and a "code generator" that works using regular expression patterns. IF you find yourself copying and pasting, then searching and replacing similar classes, automate this process. I did this for my PHP projects, in which I can create a CRUD application, complete with all the basic MVC components, based off my data tables - the data models all look the same except for the data tables they represent, so these are setup in templates and used to generate my initial code. Saves hours of typing.

Finally, tell all people involved with the project that the code is going to take 1/4 to 1/2 times longer than YOU think. Negotiate more breathing room for yourself, early on. "Late" is a relative term. When changes occur in the project, mid-stream, let everyone know up front that 8 more hours of work has been added. A tracking system, such as one offered in "FogBugz" might be helpful to yourself and managers to anticipate how long its going to take to get something done, based on previous experiences. I try to take the tact, "It wasn't late - I used the proper amount of time it takes to complete this function - it merely took longer than we expected."

Another programmer may say, "Well I could have done it faster..." Maybe, maybe not, that's not a point worth debating or beating yourself up about - there's always going to be some "smart" guy trying to push that button. He'll slow you down if you think about it! Its always a bad situation when its your boss, though. At that point, I'd consider looking for another job, cause that sort of boss is an arrogant JERK, in my book.

  • I'm not sure I think the suggested solution to copy and paste programming is really a solution. You shouldn't fix a problem of redundant code by making the redundancies easier to manage, you should eliminate them by refactoring them mercilessly! – SingleNegationElimination Sep 12 '09 at 15:51
  • Well, I was referring to creating templates of data models, to be more specific. Of course, individual data models would extend the functionality of an object data model that already exists, but the individual ones would be based on your database. You can automate the creation of these - its helpful if you have several tables and several fields to work with. Thus, I typically design the database first and run my automated process to create the initial code, afterwards - which uses templates of my data objects, and creates generic views (forms and tables for data entry/viewing data). – JasonMichael Sep 20 '09 at 19:13

Q:What do you do to get more done in shorter time periods?

A: Everyday come to office and write what all you would want to finish on that in (sticky notes) outlook notes. Start working on that order of the items. Believe me at the end of the day you would feel you have done what you had planned and thats a great feeling.


Pair program -- this has all sorts of benefits:

  • forces you to articulate/clarify your thinking
  • gives you insight into how someone else works, many ideas which you can adopt/try
  • learn new technologies directly from someone else who knows them
  • pick up little productivity tips from others. You always see someone use a menu command you didn't understand before, or some useful Unix command.

Write less code.

Banish Not-Invented-Here and make good use of existing libraries/frameworks/toolkits to provide common (and generally non-defining) functionality so that you only need to write what's new. For the parts that you do need to write yourself, build them with re-use in mind so that you won't have to write them again for the next project.

Even if you don't increase the number of lines of working code you produce per day, you can still get more done in less time by making each line do more.

  • Took a moment to find this answer, anyway I would've started this by writing "By doing less." and carry that over as an analogy to the actual code you write. – Esko Jan 9 '10 at 15:23
  • Not-invented-here also means not-understood-here and that can have a big time cost. Unknown features and unknown bugs. Big risk. – Peter Wone Jan 9 '10 at 15:56
  • Potentially, yes, but I'm making the assumption that, if you're going to use an "existing library/framework/toolkit", then you're going to choose one that's already been used widely enough to have been thoroughly stress-tested in other applications. Good point on not-understood-here, though - you definitely need to be able to identify when learning to use someone else's wheel will take longer than building your own. – Dave Sherohman Jan 9 '10 at 22:09

The only clear thing I've found that works is to be free of distraction. Which, in some environments, is impossible. But being able to focus on the specific task and ONLY on that task will likely outweigh anything else. Those context switches are really big time sinks.


Juggling while having a break



Drinkng Yerba Mate instead of Coffee

Yerba Mate

  • +1 for Mate. And in case you're too lazy to heat water, drink Terere, the cold water version of Mate tea. Some shops: mate-tee.de / mymateworld.com / mate-tea.ch – danilo May 30 '10 at 15:29

It's always the same sole decision, fast development vs. quality, readability, extensibility. Drag and drop of controls and infinite code-behind files (quick and dirty) or modularity, patterns and practices (long term investment)?

In my honest opinion, everyone must invest in the long term way of coding. As time passes, the fast development is going to be of great quality as well.

However in case I didn't understand your inquiry, and you are seeking answers in terms of practical aspects of fast development, like tooling, code generators and other stuff, my opinion is to start using Resharper and learn as much you can about your IDE :)


USE FRAMEWORKS!! Don't bother yourself with hardcoding!


First of all, you shouldn't be designing a system based on a few meetings with end users. In fact you shouldn't be involved with the requirements phase of a project, that's for the business analysts and end users to work out.

Second phase should be your technical requirements, this is where you will start to work with the business analysts to come up with a solution to the requested specification.

Now is the important part. Make sure you understand both the end user requirements and the functional requirements, there's no use you starting out something only to find it didn't meet users expectations. Speak up if you don't understand something.

Now, time to hit the editor. But my approach is to never write real code, always write an absolute stack of comments first, do it in pseudo code if that's easy for you, whatever it doesn't matter, as long as it's clear and easy to read/understand.

Once you've done your comments you can start either a) writing your test cases b) writing the implementation.

Depending on your environment you would be best starting with (a) but sadly most start with (b) and then try force the tests to meet the implementation. Frankly speaking though, if you were part of a large company there would be a department writing the test cases for you before you even start doing anything.


Everyone says 'checking email' but consider the time you spend writing highly technical email. I can easily spend an hour writing a single email. To fix it, I could either 1) not write as much, or 2) put off the technical stuff (and the stuff that requires me to read code to answer) until it is absolutely necessary.

  • 1
    ... and it's not only the time you spend writing the email, but the time it takes to get your head back into the code from where you left off. For me, that's the daunting part. – Mike Dunlavey Sep 11 '09 at 23:11
  • 1
    Perhaps you could avoid the e-mail entirely and just organize a standup meeting. – Jim G. Sep 12 '09 at 15:44
  • @Jim - argh NO that's even MORE disruptive. – Peter Wone Jan 9 '10 at 15:50
  • @Mike - it's not just email, it's phone calls and loud colleagues etc. Once upon a time I had an office - ironically, this was when I was a junior programmer. An office with a door, and no phone. It made all the difference. – Peter Wone Jan 9 '10 at 15:53

When actually writing code, CodeRush helps quite a bit especially when you've mastered its shortcuts. Plus it's free :D


I spend a little bit of time each week just looking for new creative ways to do things that may or may not be directly related to what I'm currently working on. Often I'll find new tricks or tools I was never aware of that speeds up my workflow.


Become intimately familiar with your IDE.

If your IDE is Visual Studio, then I highly recommend Sara Ford's book.

Not the answer you're looking for? Browse other questions tagged or ask your own question.