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,

+12  A: 

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?

Matthew Jones
+1 lol...
+2  A: 

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.

Randolph Potter
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.
Nice point. +1 for you.
Randolph Potter
@Godeke: Nice point. Resharper *can* be a time sink as well.
Jim G.
+24  A: 

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

But often, increasing speed implies sacrificing quality.

Developer Art
I would suggest "making it work" and if time permits getting around to perfecting it !
-1: There is no reason to sacrifice quality. You can always sacrifice features.
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.
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
If you're stuck at one feature, work on something different.
+1 Very good remark! Writing "good enough software" is something I have learned over the years.
Dimitri C.
-1 I'd say that this is exactly what causes maintenance nightmares and horrible delays down the road.
hasen j
This is a real tricky one. For, me it's a 0 - +1 for avoiding perfection but -1 for "just make it work". Just making code work generally results in a mess - which will come back to haunt a project.
Use Test Driven Development to document exactly what your code CAN do.
Thorbjørn Ravn Andersen
+154  A: 

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
Pencil and paper or a whiteboard is faster than most applications that I've used.
Thomas Owens
Thing i like the most
@Thomas Trying to get the programmer away from the computer could again be slower
Doing it on paper focuses the mind.
I'm surprised at all the votes this idea's getting, I'm going to have to give this idea another go!
Nick Gotch
I used to be paper user, and have become a huge fan of Freemind. Check that out.
why can't i downvote the visio comment? Not using visio is a certain way of speeding up development!
I think through some of my toughest design decisions while doing mundane tasks: gutting the grass, waiting in line, standing in the shower, etc.
There is nothing faster than sweep the whiteboard with a eraser. Of course, the whiteboard don't implements Redo
I will concede that "whiteboard" is indeed faster than "pencil and paper"; however I find it less portable. :)
Then get the people who sign your paycheck to quit changing the requirements, or actually write some good ones to begin with.
That still does not guarantee that the code will be delivered on time...
Franci Penov
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
Visio is fine, assuming that you are not a perfectionist and will spend hours tweaking the design into some kind of 'optimal' layout - which is what I always end up doing!
Fiona Holder
I type it out in Notepad, but the principle is the same: when I think through all the steps to do something before I start coding, it helps me go a lot faster and make fewer mistakes. When I get sidetracked on a bug, then fix it, I know right where to pick back up.
Nathan Long
If you're scetching UI then there are good reasons to stay away from Visio etc and keep with rougher diagrams, either paper or electronic - see (not related, just like the product)
For me, the Visio design drawings usually are helpful in design reviews and documentation.
This can help with using viso,
"Weeks of coding can save you hours of progamming." -Source Unknown
whoever said... use Visio... has never used Visio. lol.
Anonymous Type
+29  A: 

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?"

Phil Jenkins
Perfect mind state for faster programming in the long run, although at first it might take more time.
+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.
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
+11  A: 

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.

Practice is often underestimated in programming. This should have been one of the top 5 answers.
Jørgen Fogh
+80  A: 

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
shortcut keys save so much time.
if you're not using a good IDE, get a better one. If you get proficient at a "real" editor like vim or emacs, you'll be able to code circles around people who use Visual Studio (for example). The only exception is refactoring support built into the IDE.
I comctrl+space with you, espctrl+space helps Mectrl+1 a lot. In fact I refer myself as an "IDE programmer", not because I code parts to some IDE but because I just love the shortcuts and do indeed utilize almost all of the hundred and two buttons on my keyboard. sysout, ctrl+space, home, left_arrow, left_arrow,ctrl+shift+left_arrow,ctrl+x, home, ctrl+v.
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
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.
It's a lot more than saving typing. Automatic refactoring can help squash bugs, etc. Plus, if there's a long compile time, having Eclipse/ReSharper style error-as-you-type can save you a LOT of hassle. And reformatting to fit strict source analysis guidelines? I'd say thyat's a big win.
Robert Fraser
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
Having Eclipse catch your errors as you type encourages you to become a lazy (java) programmer who doesn't actually understand WHY what he types works.
Paul McMillan
Along same lines: learn general 'hot' keys. E.g., in many Windows programs...Copy: Ctrl + cCut: 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: HomeGo to End of line: EndMove cursor by word (not character): [Shift] + Ctrl + left or rightGo to top of doc: Ctrl + HomeGo to end of doc: Ctrl + Endetc.
More pro maneuvers include:--Learn to search and replace using regular expressions--Use spreadsheets and/or languages with array/list and object/dict literals to massage temp data/strings.E.g.,1) copy HTML table from web page2) paste into Excel3) move name and value columns together4) copy that into text editor5) replace tab (\t) with colon, space :_6) replace newlines with comma, space ,_7) add open and close curlys to the start and end of the line8) process NV pairs as a JSON object.
+1 for this. I've improved my speed a lot by just trying to learn a new keyboard shortcut every week or so (this mostly applies to Vim, but Visual Studio too).
Adam Neal
@Paul, having Eclipse catch the errors saves time when you HAVE become proficient.
Thorbjørn Ravn Andersen
May I add: Try to avoid using your mouse. Map your keys so that you don't have to change your hands' position too often.And yeah, I love Emacs ^^!
Helper Method
+9  A: 

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

Mike Hall
But also realizing when you do need to Google and being able to do it quickly is important.
+22  A: 

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.
Can you define "Go green" for those of us who have no idea what you're talking about? :-)
Graeme Perrow
I believe this is either using a tool like Resharper that can verify coding standards or running automated tests that if any fail, that's red and if none fail then it is a "green" result similar to how cars go on a green light and stop on a red light.
JB King
When doing TDD, you have a test runner that produces a red/green report per test to indicate if they pass.
Frank Schwieterman
TDD is much slower than dirty coding when you need to make a quick fix. Often you have to write 5 lines of code to test 1 line fix. Bad thing is management usually needs fast solution and rare understands concept of coding and architectural debts.
Konstantin Spirin
@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
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
If the management does not understand some key concept, you should explain it to them. For example
Esko Luontola
@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.
Tests are good because they help you *keep* problems fixed.
Donal Fellows
+6  A: 

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.

+13  A: 

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
+1 - I seem to recall reading somewhere that the difference between good programmers and bad programmers isn't in speed. The difference is that good programmers will keep more of their code.
Jason Baker
That's my motto, do it the right way, the first time. Don't get in the habit of having to always go back and fix your code, because you didn't do it correctly according to specs.
+123  A: 

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 interative 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)
+1 for "avoid gold plating" -- this has been the cause of me missing way too many deadlines because of my perfectionist/anal-retentive tendencies.
Typing - important point. Always amazed at the number of coders I meet who haven't learned to type...
+1 for gold plating. One boss required me to burn a day writing a factory to dynamically load and instantiate objects from assemblies for a program that needed to create one object. "Just in case we ever need to change to something else later". What a joke
+1 for gold plating. More often than not, all those extra features that you thought were so cool lead to extended timelines in QA. and sometimes they actually interfere in other parts of a large system you might not have been aware of. Code to the requirements and the design, not beyond them.
typing speed and overworking are really good points you covered.
Ketan Khairnar
+1 eliminating distractions. As I see it, they are the major time eaters.
Umer Azaz
Great advice. A good way to get practice with many of these points is to play the XP game.
Sean Reilly
+1 for the tips to micro-improve (instead of macro-improvements in terms of planning projects).
+4  A: 

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

+35  A: 

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

"Many, many people strive for "ultimate" quality at the expense of something that is (a) simple, (b) reliable and (c) correct." You could have left it at that and I would have voted for it.
"Simplify, simplify." ~ Henry David Thoreau
Gordon Potter
Yup... this means premature abstraction, too. If something is only going to have one implementation, don't make it an interface.
Robert Fraser
One of my favorite quotes is appropriate in this situation "make something as simple as possible, but no simpler" ~ paraphrase, Albert Einstein
Keep it simple is what even many programmers do not get properly: they fall into the "premature optimization is the root of all evil" trap to easily. Normally the simplest program is the fastest or the one of highest quality.
Am I the only one who doesn't understand the "but no simpler" part?
hasen j
@hasen j: too simple == incomplete. The rule is this: remove any single thing and it now fails to do the minimally acceptable job. Every piece is absolutely essential or it doesn't work. No "convenience features"; no "syntactic sugar"; nothing surplus of any kind from anyone's point of view.
+3  A: 

Think before what to do !!!

Design the Program in your mind or better with pencil and paper . Then your experience and Practice will provide the rest of things :)

+16  A: 

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

Matthew Jones
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
+4  A: 

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.

Rob Wells
+4  A: 

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.

+6  A: 

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

+7  A: 

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.

James Schek
"...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...
LOL--I know what you're saying. But you'll be amazed by often this slips by unnoticed, as opposed to saying "multiply by 4".
James Schek
+6  A: 

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

+2  A: 

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

Aggelos Mpimpoudis
+6  A: 

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.

JB King
+12  A: 

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.)
If the limiting factor of your coding is how fast you type stuff in, you're probably working at the wrong level of abstraction.
Pete Kirkham
+1. A great link, a great article for those who read it to the end ;) I was typing well, but it inspired me to switch to Programmer Dvorak keyboard layout (but I switched the '" and -_ keys with Microsoft Keyboard Layout Creator), and I'm sure that soon I'll be typing much faster :) See also:
Roman Boiko
+21  A: 

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!

I do the same.
Online documentation and troubleshooting searches are so overrated anyway.
Install a firewall and configure it to block nearly all web access (I have exceptions for a few domains, e.g. MSDN)
I'm really considering doing this (the fact that I leave this comment proofs enough)
And lose SO? hell no
+6  A: 
  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.
Rui Craveiro
+17  A: 

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.

This won't work if you have a boss who expects responses to e-mails within 10 minutes.
+1  A: 

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.
+9  A: 

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

Dustin Getz
And skip lunch if you're in the zone... or stay late... MMMmm the Zone. *drool*
+113  A: 

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.

Franci Penov
Some devs really are too slow though. It can be a problem.
Brian MacKay
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
'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 - 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
But you can't just set a deadline by how long you know it will take. Sometimes there are business concerns, and the project has to be done in x days, regardless of how good you are, so you look at the project, and figure out how to get it done in the time allotted. Sometimes you really are too slow to get it done by the time allotted.
There were so many great suggestions it was hard to select just one but I'm going with this one because of everything said I think this one hits directly on the nose my exact situation. Thanks to all!!
Nick Gotch
@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
+1 The summary remark - "being slow at writing code won't cause missing the deadline" - is counterintuitive but very true.
Dimitri C.
If one dev on your team is "slow," perhaps it is because they have been assigned too much work to do for their skill level.
Barry Brown
@Barry - exactly my point. in a properly managed project, the work assigned should reflect the level of the programmer. the project delivery on schedule should not be affected by that. (whether the dev needs to be replaced for the next project because of lack of skills is a separate topic :-))
Franci Penov
You've never worked with a developer that tinkers with something "until it's perfect", well past he post of good enough for the other developers to happily maintain?
Dean J
+3  A: 

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.

Jon Galloway
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?

Use code generators whenever it's possible. Sometimes even Microsoft Excel (or OpenOffice Calc) turns out to be a powerful code generator tool.

Code generators aren't always bad, but they *can* lead to maintainence headaches down the road.
Jim G.
+1  A: 

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

+3  A: 

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 !!!!

Simply put, White board -> break down into testable requirements into tasks (I've used Team Foundation to keep track of each task and how long it should take.)

Use testing to ensure that you are getting what is required done, nothing more nothing less. (Don't worry about performance yet.)

Go from requirement to requirement and test after each is done. After each task is completed you should have an accurate estimate of the time remaining.

When all requirements are done go back and "polish" it.

Doing the leg work first forces one to iron out all the requirements which saves time by doing things right the first time.

If done properly this should allow more time to be spent on Stack Overflow :)

Good luck

+5  A: 

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.

David Thornley
Nice. An answer that describes how to fix the problem for the asker, not how the answerer fixed the problem for himself.
+1  A: 

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.

Brett Ryan
+3  A: 
  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 :)
+1  A: 

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.

... 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
Perhaps you could avoid the e-mail entirely and just organize a standup meeting.
Jim G.
@Jim - argh NO that's even MORE disruptive.
Peter Wone
@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
+3  A: 

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!
+2  A: 

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.

Jeff O
+1  A: 

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.

Mike Dunlavey
I really like the first sentence.
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.
@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
... 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
... 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

There are a bunch of great ideas here. To help me get in the 'zone' I use a timer set at 27 minute intervals. I find once I'm in work mode it's easy to work well beyond the buzzer and working with flow is painless. Getting there is hard though.


There's only one way to do this.

Type faster!

I refer you to Atwood's We Are Typists First, Programmers Second.

I can talk faster than I type, but I can't solve problems faster than I type.
+3  A: 

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 ;).

+8  A: 

Before you start developing:

  • Log out of your mailbox
  • Turn off any IM clients
  • Politely ask peers to give you time to concentrate
  • Of course, stop surfing the Internet

Every time you're interrupted, you'll slow down as it takes your mind time to get back on track with its thoughts. I've heard figures that for each interruption, it takes the human mind 5-10 minutes to reset back to the thought process it had before the interruption. With that much time per interruption, it doesn't take much to waste the whole day.

People in our company have actually taken to blocking off time in their calendars and then moving to an empty conference room for a couple of hours each day.

+2  A: 

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!
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).
+6  A: 

I think they key word here is "timeliness". They didn't say you were too slow, rather that you were not timely.

In project management, it is important for the manager to be able to estimate when your work items will be complete with accuracy. I suspect that the main reason why your efforts were not deemed to be timely is that you frequently had items that were not delivered on schedule, and were delivered much later than scheduled.

To improve your timeliness, you might want to spend more time understanding how long it will take you to complete a particular work item given your skills, experience, and the domain. This will allow you to give better estimates to your project manager. The key here is "better" ... you could deliver on time more frequently by padding everything with a fudge factor, but what you really want to strive for is a more accurate estimate.

I would discuss this with your manager to see if this is actually the issue. Otherwise, you might end up programming twice as fast, promising things in half the time you used to, and still getting criticized for your timeliness because your estimates will still have the same error factor.

Larry Watanabe
"...Spend more time understanding how long it will take you to complete a particular work item given your skills, experience, and the domain." -> Right, and this will also help you to trim scope and save you even more time.
Jim G.
It will also help your manager look good to those around them - It also allows supporting materials such as marketing to be completed in sync with your project.
Tom Leys

The one thing that I have noticed affecting my speed the most is motivation and having fun. This may seem Fuzzy, but when I'm motivated and doing something that I find fun I can be extremely effective. On the other hand when I'm neither it really feels like I have to push every single line of code out of me.

Find your sweet spots, what really motivates you and what kind of tasks do you really enjoy doing? And can you affect your planning so that you can do this? For me it's when I get to solve problems and design issues, and when I feel that I have a part of the project.

A few months ago we had a small project that our small team was assigned to do and it was a really important and very unrealistic deadline to it. However we were all very motivated and had great fun doing it and got it done in time, with a happy customer. The reason for my motivation was that we were very involved in the project and had to come up with creative ideas for it. I also got to do the parts that I really enjoy.

However recently I have been involved in a project where I'm basically being a code monkey, just doing mind numbing and frustrating tasks, or just having quick-fixing stuff the fastest way possible which I know will come back and bite me hard sometime in a near future, and it has been painfully slow.

So what is your sweet spots?

+1  A: 

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

+1  A: 

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.

+3  A: 

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.

Adnan Memon
Use this link for wallpaper if above is not working:
Adnan Memon
+6  A: 

Pretty much all the answers have been said to death in numerous places here and elsewhere. Or, at least I've heard it to death. Learn your IDE, learn to type faster, use frameworks, use code generation, etc., etc. Yes of course these things will help and I doubt there are many programmers who are masters of them all. But being the type of programmer that asks these questions and frequents sites like Stack Overflow you knew these things already. Did you merely want to here them repeated or did you just want to vent a little?

But what if we were able to get to that state? I mean master all these suggestions? What would happen then? Well. I'd guess that time-lines will be reduced even further. And again, we'll revert to a perception of quality. I mean, our craft has definitely progressed and become more and more productive over the decades. But has quality increased during this time (excluding the very early years of course)?

My answer is simple: quality software takes time! You can only trade one for the other (quality/speed). But yes we all know that however we're not honest about the degree to which that trade-off often ends up on the speed end of the scale. And we are even greater liars early on in projects!

I say that you are not at fault here. The problem is the perception people have of how long quality software should take. We fool ourselves in believing we are capable of creating quality software with the types of time-lines our managers or even we guesstimate. We do not make quality software. We write software that works but sometimes with flashes of quality in certain corners of an application.

So what can we do about this? We can't just convince our bosses that we need to double or triple the investment in each of our projects. I say lead by example. Create a truly great piece of software as a side project. Put your own time into it and do not compromise. All the while pay attention to how you progress. Make note of the apparently unrelated tasks you've had to put an unexpected amount of time in and see if you can justify it. Contrast this with all the other projects you've worked. Be brutally honest with yourself and all aspects of this analysis. Can the extra things you did with your quality software be neglected in "real" projects at work? But maybe your attempt failed. What was the reason? Did you get bored and just rushed to get the core features done? I've yet to do something like this myself which is why I end off this thought with some doubt - but I intend to give it a real go. I'll keep you posted :).

Finally, I think most (if not all) performance evaluations are twisted and extraordinarily manipulative. You can't throttle quality and speed at 100%. Your boss should be scoring you against a standard that is set by the organization. The organization's standard on the trade-off between quality and speed. Lets imagine that OrangeSoft Inc. expects 33% quality and 66% speed. So if you're writing code that has maybe a third of the unit tests it should but making it up with speed and reduced delivery time you should score near 100% on your review! (These are pretty rough analogies but you get the point). But instead, what happens is that Bob writes code extremely fast but which is notoriously buggy. So on his performance review he'll score 3/5 for quality and 5/5 for speed. Carol on the other hand writes code much slower but produces significantly less bugs. She scores 5/5 for quality but 3/5 for speed. Either way Bob and Carol get docked on their raise. Is it possible for any employee to get a perfect score? Is this fair?

+2  A: 

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.

+2  A: 

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.

Type faster. LOL :D

+1  A: 

Become intimately familiar with your IDE.

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

Jim G.
  1. Know what you want to do and have an interest in it
  2. Spend a few hours researching code on how to do it
  3. Copy and paste code to achieve the end result
  4. Work on a basic gui to get the job done, DO NOT SPEND TIME TO MAKE IT LOOK PRETTY
  5. Test and debug
  6. Work on a pretty gui
Matt S.
6. Get someone else to work on a pretty gui :)
+1  A: 
  • learn Design patterns. They help you understand problems, make you a better programmer -> will let you program a lot faster since you have already solutions for several problems prepared in mind
  • extract repetitive parts in your program. If there is some logic which repeats throughout several programs you write, consider generalizing them and extracting them to some class library which you can then reuse on new applications you write. Standardize things: invest some time into finding out how certain repetitive tasks are done best. Document the steps for achieving. Next time you will exactly know how to solve/apply them.
  • KISS principle
  • Code generation will be useful (once a useful tool is available). Generators start to gain popularity, recently.

Note: Just making things work is worse!! As some mention just to hack in things till they work will make you faster just for the moment. Bugs will come in however which somehow count also in terms of how fast you program. If I have to write some piece of functionality and I invest in writing it good, having a good design, possibly well tested (with Unit tests) and say I'll need half a day. But assume that was it and your feature works and you don't have to touch it again. Another programmer, just focused on a fast achievement of his goal, will make (possibly) a bad design, due to missing testing he'll not consider (be aware of) boundary, exceptional cases. He'll need 2 hours (let's say). Bugs will come in, he'll again have to touch the code, fix it, possibly extend it (hours will be invested again). Code will be hard to maintain etc...resumé: at the end he'll spend much ore time and frustration will be higher.


"Timeliness" is not the same thing as "fast". If that was the problem your evaluation should have just said "slow". So be before you take the path you propose, make sure you know what is expected of you.

It could mean anything; it might even mean that you don't get into the office until 20 minutes after your colleagues, or that you have poor time management. That may be nothing to do with your 'programming speed'.

I probably spend most time designing and planning; it is easier to plan tasks from a good analysis and design, and you will then give better estimates that will be believed. Moreover from a good design, coding becomes a lot simpler and more directed process. It also makes it possible to divide up a task and distribute it amongst other developers.

+5  A: 


Please edit this so I can upvote it, it is currently "too old".
+3  A: 

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.

I've practically tripled my C coding speed with VIM.

Liran Orevi

CodeRush! Get it! Love it!

Bobby Ortiz
Duplicate of
Ruben Bartelink
+1  A: 

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.

Dave Sherohman
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.
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
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

Choose fast editor, fast compiler, and write software with fast execution time. This way you can make ten times as many mistakes as normal programmer and still become better than others. That's probably one the reasons google applications are so popular. Web development is filled with nasty bugs, and writing more software on buggy platform is pain the ass. But the response time between editing code and seeing outcome is so fast that it's still easier to make that mountain of garbage work than extending c++ programs. :)


Spend more time putting things together in your mind than in front of the IDE. When you have a plan, you already have most of the work already done. Implementing is just the other 20%. If you get stuck while writing code due to platform-specific problems, stick to the plan, and keep on implementing and testing the rest. In the end, tackle all the spots you've left behind, solving them one by one - it's possible that some will be related, and solving a few might be enough to figure out the rest. I usually use workarounds for such problems, adding "//TO CHANGE" comments at the particular places in code, and rewrite the ones that have the most impact on quality and performance in the end, if I don't have time to resolve all of them by the deadline.

+1  A: 

Use an ergonomically optimized keyboard layout. Some are even aimed at programmers, through very accessible special chars.


Build your own code library

Every time you code a new feature try to keep it generic as possible, but not too generic. In the short term this will be a little slower, but in the long term as your code libary gets bigger, each new project will be completed faster as a lot of business applications have similar needs (not always) but close enough that a lot of code can be reused.


Faster doesn't mean better. If you manage to be a faster and better programmer. It all comes down to balance. How long you can do that ? Thinking, patience and planning always pay off. Sometimes "fast" in developement world could bring worst results.


Deconstruct. Break whatever you're building into smaller features that you can implement in stages. Then, whenever you have any of those smaller pieces done and you've tested to confirm it doesn't break anything, deploy it and show it to the Powers That Be.

Using small iterations will often help you finish the larger project faster and better, because you're getting feedback as you go and you won't need to backtrack and redo as much. But even if it doesn't, you're showing constant progress, which has a solid psychological benefit and restores your manager or client's confidence.

Test-driven development also helps a lot with this approach. At first it may seem like writing tests first slows things down -- but it gains that time back in bugs you'll avoid, and depending on how you write them, the tests themselves could be a deliverable you can show to the Powers That Be and confirm the app's behavior even before you write it all.


If you are programming in C then learning bit hacks is a must for becoming a faster programmer. Also read coding practices by top rankers at Their code is very small and efficient.

+6  A: 

Get stable, stay stable.

Build something that implements a small bit of the functionality, and make sure it works, end-to-end. Then, keep it working as you add new bits of functionality. Yeah, this is partly a TDD practice, but it makes sense even if you don't do TDD.

The rationale is that every time I've seen someone with 2 weeks of code that had never been stable, it always takes another 2 weeks to get it stable.

If you stay stable, you remove that uncertainty, and also give yourself a way to scope down near the deadline if necessary.

The obvious counter-argument is that doing this will take more time than just writing it once, as you will do extra work be stabilizing non-final code. I don't buy this for a second. When you have code that works, you change 5 lines, and something breaks, you know exactly where the break must have happened.

If you have 10,000 lines of code that never worked, and you have to find a break, you have a ton of code to search through.

Small, incremental changes on a system that is consistently stable FTW. Go slow to go fast.

+3  A: 

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.

Jonathan Swift
+1  A: 

Work from home. When I have a tough deadline and I need to focus completely on a problem, I tell my boss that I am working from home. This lets me set up my environment optimally, reduces interruptions, and lets me focus like a laser beam on the problem.

Pedro Estrada

Become a faster programmer by slowing down when you are designing and coding.

  • Think about what you are doing.
  • Consider the implications of your design.
  • Get it right the first time (test your own code vigorously).

It might feel slower, but your throughput will be faster than those code jockeys who turn an iteration in 4 hours, and then need 6 rounds of QA before their code passes.

+1  A: 

You'll get faster with experience and memorize the API a lot more.

My days of searching the web for fragments of code are a lot shorter now that I've learnt to code better.

Oh, you may also want to try using functional programming concepts and lamda to cut down your code :)

+1 Like Joshua Bloch said "Know and use the libraries".
Helper Method

Slow down. Stop and thinking rather than just coding.

Garry Shutler

Re: How to estimate and stick to it:

When estimating, remember Hofstadter's law as well as this quip: "Everything takes longer than it does". Take a reasonable guess as to how long something should take, then double or triple it before it comes out your mouth. There will be complications, setbacks, distractions, things you forget, etc. Better to under-promise and over-deliver than vice-versa.

On sticking to estimations, do your best to complete your work efficiently. When problems come up, communicate the delays early. This gives everybody time to adjust their expectations. If your explanation is reasonable, you may be given more time or assistance or have distractions (like a noisy neighbor) removed from your path.


The following practices are well known but often neglected for various reasons, often due to tight deadlines, so they deserve mentioning here (in effect, these are mechanism for spending time in advance to avoid spending more time later):

  • Do test-driven development; it'll help you write only the amount of code that is actually required and, will help you avoid the introduction of bugs when adding features or refactoring

  • Write comments, but only where the code is complex enough to warrant it

  • Refactor and simplify your code often

  • Use decent source control software (like Git or Mercurial) -if your employer uses something else, use your own locally-

  • Commit code changes often: for every feature or refactoring, do a commit, as reverting will be less costly to you if something goes awry

  • Don't be afraid to branch; Git especially has a very fast and "safe" branching mechanism (for instance, in comparison to Subversion)

Nick Toumpelis

If you fire all the "net negative contributors" to your codebase things will begin to improve ;-)

If you're on a team where you're outnumbered by people writing bad code, just getting them to stop coding will improve your productivity - because you'll have less tricky, broken code to fix and less overly complicated mechanisms to think around.


I personally think its all about code re-usability. Unless your doing fully custom things every single time, you should have a library of common use functions you can turn to. I have a utils.php in which i have a whole "junkyard" of functions that i have used on previous projects. Saves a TON of time when i have to do something similar.

Good luck and don't get discouraged. I think we've all felt slow or "dumb" at times. I know i have!

Code Monkey

Use static analysis tools.

They help you find more bugs at compile-time you would otherwise had to track down at runtime.

Especially when building multithreaded applications they are a REAL help.

Helper Method
+7  A: 

For me, getting good productivity is having a clear idea about what you are trying to achieve, and how you will get there.

My 30-minute cycle ride to work through the Norwegian countryside is also pretty good at clearing the mind and getting the creative processes going.
+1  A: 

Being excited about what you're doing is a great way to increase efficiency. Make sure it's fun!

+2  A: 

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.

+2  A: 
  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
I agree completely. Thanks!
+2  A: 

Juggling while having a break


+2  A: 

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: / /
+1  A: 

I think that sketching out your idea on paper, remember that stuff, is a great way to flesh out some ideas. As programmers, whether professional or hobbyists, we spend soooo much time staring at the screen, that having another outlet on which to put your ideas is good. I find that scratching things out, drawing hasty lines linking ideas, circling things, underlining, etc. all add to the emphasis on an idea and can really help you sort out an idea much faster than attempting to structure it right off the bat or in some computer-aided form.

Another thing that helps is prototyping small parts. Listened to a TED audio podcast last night where the speaker was discussing building small structures out of spaghetti sticks and marshmallow, apparently this is a pretty widely-used study to test social construction abilities of small groups...anyway, the groups that always did better, besides architects who understood reinforcement and building construction were children because they used a stream of constant feedback to get results. I think you can also throw this into a programming idea where you see that doing little things and getting results is not only more productive but a lot more fun and useful than building some giant construct and then spending days debugging it....that's killed some of my "fun" ideas in the past for sure.

+1  A: 

When I'm at the office and I need to maintain my focus, I close my e-mail client. Nothing destroys efficiency for me faster than the constant temptation to "take a quick look" at whatever message just arrived. I've also been toying with the Pomodoro Technique for managing disruptions and maintaining focus.

Tim Trout
+1, because very often happens this "taking a quick look" to me. That really kills a lot of my time.
+4  A: 

Not looking at Stack Overflow - damn, I just did it! :)

+1 for reducing distractions, this is great productivity killer...

These are all good suggestions. I would add my own productivity technique which is to know how to get things done not only with minimal code but with minimal redundancy code.

Generally this means the less data structure the better.

To make code with minimal redundancy requires creativity and willingness to do things in ways that might impose a learning curve. That's the price of the productivity. Here's one example.

Mike Dunlavey