Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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,


migrated from Dec 27 '10 at 18:32

This question came from our site for professional and enthusiast programmers.

locked by Yannis Mar 13 '12 at 20:34

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Spend less time on SO at work, if you do so. – San Jacinto Sep 11 '09 at 15:16
If you are reading this, it's already too late – OMG Ponies Sep 11 '09 at 16:28
I read "How to become a fatter programmer". Made me laught – marcgg Sep 11 '09 at 16:39
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
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

Some ideas...

  • Avoid gold plating - do only what is asked of you (in terms of requirements)
  • Understand business requirements and do it right the first time
  • Thoroughly understand your environment and tools
  • Become a fantastic typist, use keyboard shortcuts instead of the mouse
  • Take an iterative approach and build in sanity checks to ensure you are on the right path
  • Don't reinvent the wheel, consider reusing past work and the work of others
  • Eliminate distractions, don't keep checking email, looking outside, talking to coworkers, etc.
  • Don't overwork yourself - recognize when you need to take breaks
+1 for not reinventing the wheel. Learn to produce reusable code, that can bu plugged in another code and work with none to small re-write. (ex.: functions with parameters, instead of hard-coding) – Jay Sep 11 '09 at 16:04
+1 for "avoid gold plating" -- this has been the cause of me missing way too many deadlines because of my perfectionist/anal-retentive tendencies. – Dinah Sep 11 '09 at 17:05
Typing - important point. Always amazed at the number of coders I meet who haven't learned to type... – Paddy Sep 11 '09 at 17:21
+1 eliminating distractions. As I see it, they are the major time eaters. – Umer Azaz Sep 12 '09 at 11:28
+1 for the tips to micro-improve (instead of macro-improvements in terms of planning projects). – MP24 Sep 30 '09 at 8:30

I do it tomorrow.

Getting Things Done is also immensely helpful.

I have a short attention span anyway, so these books help me keep my foc... what was I doing again?


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.

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

Avoid polishing your code to the perfection, just make it work. That's what the business expects.

But often, increasing speed implies sacrificing quality.

I would suggest "making it work" and if time permits getting around to perfecting it ! – Preets Sep 11 '09 at 15:04
-1: There is no reason to sacrifice quality. You can always sacrifice features. – S.Lott Sep 11 '09 at 15:06
I've seen it happen repeatedly. Developers get hung up on the last 1% of a given feature and then play catch-up and fall behind when attempting to complete the remaining features. Complete what is expected of you first, then go back and polish it. – Mayo Sep 11 '09 at 15:06
Often, increasing quality implies increasing speed. If you take a little time to get it right in the first place, you might save more time in testing and debugging. – David Thornley Sep 11 '09 at 17:14
If you're stuck at one feature, work on something different. – mrueg Sep 11 '09 at 21:07

Turn off the computer. Grab a pencil and some paper. Sketch out your design. Review it with your peers. Then write the code.

OR you could keep your computer on, and open i.e. MS Visio – sshow Sep 11 '09 at 15:02
Pencil and paper or a whiteboard is faster than most applications that I've used. – Thomas Owens Sep 11 '09 at 15:03
Doing it on paper focuses the mind. – pjc50 Sep 11 '09 at 15:10
why can't i downvote the visio comment? Not using visio is a certain way of speeding up development! – darasd Sep 11 '09 at 15:32
Ugh.... Visio. Every time I'm asked to "use Visio in your design document", I first sketch it out on paper, then spend the next two days fighting to get all the lines in Visio correct. – Robert Fraser Sep 11 '09 at 21:03

Re-use - I try to factor out any clever bits from previous projects, so I can use them again in future ventures. It's always worth asking yourself "could I use this again someday?"

+1: Beware though, I've caught myself generalizing and abstracting something so that I could use it again another day... and missed that day's deadline or doubled the time the bug should have taken to fix... so that I could "maybe" save time later on. – Steve Evers Sep 15 '09 at 5:30
Having a "bag of tricks" is key. If this is becoming a job issue for you, it would be worth putting some of your own time into developing reusable pieces (assuming the domain you work in is amenable to code reuse). – Larry Lustig Oct 9 '09 at 22:06

Practice and hard work.

You need to put the time and effort in. As you become more comfortable and confident with whatever tools your using, speed and creativity should follow.

If you want to improve any particular skill, it may also help to design exercises which will let you work specifically on that. If your slowness is in the design phase, try to find design problems to work on online. Redoing the same exercise will let you complete it faster and practice speed. I personally like TopCoder's algorithm exercises for practising sheer programming speed. They have design challenges too, but I have not tried them.


Really, really learn your editor. If you use an IDE make sure you're using all the features it offers. Get a cheat sheet to learn the keyboard shortcuts for your editor of choice. If you're using a shell set up shortcuts for commonly used directories

This can indeed sometimes increase productivity drastically – sshow Sep 11 '09 at 15:05
Writing actual code is just part of a dev's work. Spending time to learn the IDE to perfection is a point optimization; and you know what they say about optimizations, don't you? - "Measure first and then optimize the bottlenecks". – Franci Penov Sep 11 '09 at 20:35
I don't see this at all. If I knock 50% off my typing time, how much time is that going to save me in a day? In my experience, I'm spending most of time thinkingabout/testing/evaluating/slightlymodifying/etc code, as compared to actually writing it, I think this would end up being not much of a win at all. – Beska Sep 11 '09 at 20:52
It makes navigating the IDE something you do without thought. Anything that requires any concious effort, like moving to the little grey button marked something or other next to all the other little grey buttons slows you down by interrupting your thinking. Having ctrl-n under my fingertips without any motion is a major net win. – Paul McMillan Sep 11 '09 at 21:08
Along same lines: learn general 'hot' keys. E.g., in many Windows programs... Copy: Ctrl + c Cut: Ctrl + x (the 'x' looks like an open pair of scissors) Paste: Ctrl + v (right next to 'c' and 'x' above) Go to start of line: Home Go to End of line: End Move cursor by word (not character): [Shift] + Ctrl + left or right Go to top of doc: Ctrl + Home Go to end of doc: Ctrl + End etc. – steamer25 Sep 11 '09 at 22:01

Knowing your IDE and framework well. Having to turn to Google for every little thing takes time.


Keep it simple.

If you use TDD, you should follow "red, green, refactor":

  1. Write a failing test (red). (Often for functionality your code does not yet have.)
  2. Commit horrible coding crimes to get your tests to pass (green). Hardcode if necessary.
  3. Refactor, probably breaking tests for a short while, but overall improving the design.
When doing TDD, you have a test runner that produces a red/green report per test to indicate if they pass. – Frank Schwieterman Sep 11 '09 at 16:22
@Konstantin: Writing some code using TDD might take take 20% longer, but it also yields better code and in the long run, when the system grows, the speed of making changes stays about the same. TDD helps you to avoid technical debt which slows you down. – Esko Luontola Sep 12 '09 at 18:51
Typing has never been the slow part of programming. Even though you need to type more with TDD, it does not slow you down. It might even speed you up, because writing a test first helps you to focus on what is needed before thinking about how to implement it. – Esko Luontola Sep 12 '09 at 18:53
If the management does not understand some key concept, you should explain it to them. For example – Esko Luontola Sep 12 '09 at 18:54
@Konstantin, if you consider "development" to be the act of writing the code statement, I would agree with you. However, if you consider "development" to include packaging, preparing build notes, deploying, testing, producing defect reports, reviewing and prioritizing defects, task assignment, investigation, debugging and fixing and starting the process over again -- then the 15 minutes to write the unit test outweighs the days and loss of customer confidence 1000x over. – bryanbcook Sep 12 '09 at 19:07

Learn your development IDE in and out. Learn the shortcut keys. Learn to use the mouse less. I find that this saves much time for me.


Do it right, the best way, first time. If that means you have to stop and think about it for a while before you start, then do it. Works 90% of the time.

+1 This is so true. It doesn't mean you have to be "perfect"; all of us will make mistakes. But if we do things the best way possible the first time, the consequence of those mistakes will be much smaller. – James Schek Sep 11 '09 at 16:21

The technique that I use is evolutionary prototyping

You can google for more info - but if the need is to produce something quickly, it's about the only way to go. Plus, it has the benefit that when the users says that he likes it, your'e done (... and can start doing the documentation).


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

Many, many people strive for "ultimate" quality at the expense of something that is (a) simple, (b) reliable and (c) correct.

The most important way to speed up your development is to simplify what you are doing so that it is absolutely as simple as possible.

Most folks that have problems with delivering on time are delivering way, way too much. And the reasons given are often silly. They're often just perceived requirements, not actual requirements.

I've heard a lot of people tell me what the customer "expects". This is a bad policy.

Build the simplest possible thing. If the customer requires more, build more. But build the simplest possible thing first.

Yup... this means premature abstraction, too. If something is only going to have one implementation, don't make it an interface. – Robert Fraser Sep 11 '09 at 21:09
One of my favorite quotes is appropriate in this situation "make something as simple as possible, but no simpler" ~ paraphrase, Albert Einstein – Nemi Sep 16 '09 at 14:00

Notice when you have been reading Stack Overflow for too long. The "Compiling" excuse only works for so long. :)

Depends on how fast your compiler is. So maybe the "solution" is to find slower compiler and run it on Pentium 2 w/ 128MB memory? :-) – Franci Penov Sep 11 '09 at 16:26

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.


Are you slower than your colleagues, or are your estimates more overoptimistic?


To produce software faster, I've found the best thing to do is to learn your runtime API as best as possible. Don't type out list logic when a LINQ extension will do; don't build a bunch of event listeners when binding will work, etc.

As far as estimation, that comes with experience. You can make use of estimation software out there to help you figure out better estimates.

Personally, I found with junior level developers, take whatever their initial estimate is and multiply it by 2, then double it. This will account for all of the learning, meetings, wasted time, etc. The more senior level developers tend to work at a factor of 2 over their estimates.

Often times, the question is not if your estimate was wrong. It's did your estimate account for all the right things? Are you giving your estimates and timelines in terms of coding effort or in terms of calendar time? Think about all the time in your day and how much of it is actual, productive coding vs. meetings, learning, debugging, etc.

"...multiply it by 2, then double it." Since you're interested in saving time, I've got a math tip for you that you might be able to use... – Beska Sep 11 '09 at 17:31

Two things that might be implied, but I haven't seen among the answers here yet that increases productivity are:

  • Use some sort of build and deployment scripts. Compiling, deploying, restarting app-server and such musn't suck up either time or focus, it should be a one-click kind of thing.

  • Have some sort of version control. Having to code without being able to roll back a change is like trying to walk on eggs


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 :)


A couple of ideas come to mind:

  1. Get other opinions on your estimates - Are there other developers that you could ask something like "Hey, do you think you can get this kind of feature done in this timeframe?" The idea being that other people's input may help with accuracy in some cases as someone may note a bunch of things you missed in making the estimate.

  2. Hone your estimation skill - Start tracking how off you are on the estimates and why you are off: Are other work items causing deadlines to not be met? Are you consistently underestimating how complicated something is? Are you giving an entire timeline when it isn't practical,e.g. what is asked is vague enough that merely getting a prototype up will take weeks and then there should be a re-evaluation of what else is to be done? Doing this may help the most in building that skill so that if you say something will take x hours, you can have confidence in that because you have done it over and over and over again. An alternative way to state this is merely practice, practice, practice.

Granted you probably already considered these, but I just thought it worthwhile to state this for those others out there that may not have considered these ideas.


Learn to touch-type as quickly as possible.

This is a nice bonus...but I don't think it will have much impact overall. Typing code is probably the least time consuming part. (Yes, I followed and read the link. I just don't agree with him.) – Beska Sep 11 '09 at 20:56

Download all your languages/libraries documentation locally to your computer, then unplug your network cable/turn off Wi-Fi.

Not trying to be funny here. This really helps me!

  1. Know the technology inside and out.
  2. Stop! Think! Go!
  3. Architect for whatever may arise, but implement only what is really asked for.
  4. KISS - Keep It Simple Stupid
  5. If it is getting too complex, probably, it is not well thought. (Go back to 2 and 4)
  6. Don't get stuck in 5. It often pays to start from scratch (Go back to 2 and 4)
  7. Go back to 1.

Avoid switching tasks too often. Distractions and task switching can kill a day, even if you use tools like Mylyn to manage your tasks.

Figure out a granularity (e.g., 30 minutes) and only work on things related to the task at hand. Anything else (new bug reports, emails about other issues, procedural matters that are unrelated) is delayed at least until the "next checkpoint". Make sure to disable popping up email notifications so you won't get sucked in.

It's especially effective if you have a buddy on your team who will let you know if things really melt down and require your immediate attention.


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.


Learn about The Zone, learn how to get yourself into it, and learn how to recognize when you aren't in it.

Once I am "in the zone" I am extremely productive and code just flows out of me, often I can get 2 or 3 days coding done in 1 day. But I find that often its hard to get to that place, I find myself procrastinating, getting distracted by other things (Stack Overflow for example).

Quote from what-tricks-do-you-use-to-get-yourself-in-the-zone


Your desire to be a "faster" programmer by itself is laudable. However, not delivering on time does not mean you are slow, it means the project was planned poorly. Being a "faster" programmer will not help; it just means you'll whoosh past the deadline faster.

You (and your team) are doing one of the following mistakes (or all of them):

  • underestimating the work that needs to be done;
  • missing a big requirement or architecture piece during planning;
  • confusing work estimates with calendar estimates and not accounting for things like meetings/phone/other overhead;

There are multiple ways you can address any of the three above. But before you can improve on any of them, you need to know why things are going the way they are. Do a postmortem on the last two or three projects estimates vs. actual time taken and figure out where the extra time went.

I'll repeat it again - being slow at writing code won't cause missing the deadline, if you've planned it properly to account for that fact.

Some devs really are too slow though. It can be a problem. – Brian MacKay Sep 11 '09 at 19:57
Yes, this can be a problem, but it's a personal problem. It should never become a project or a team problem. In other words, it can impact one's carreer, but it should never impact the project schedule. – Franci Penov Sep 11 '09 at 20:31
'not delivering on time does not mean you are slow, it means the project was planned poorly' - that's a textbox description of an invalid argument. there are many other reasons why you mightn't deliver on time, one of which may well be because you are slow. – flesh Sep 11 '09 at 21:30
@flesh - if you know you are slow, why wouldn't you plan your schedule to account for that fact? In other words, if you know you can't run as fast as Usain Bolt, would you plan to run 100m in 9.7s? – Franci Penov Sep 11 '09 at 22:46
@Kibbee - in this situation you cut features. you can't promise to do certain work in certain time when you know it can't be done and hope for a miracle. – Franci Penov Sep 13 '09 at 3:16

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.


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