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.

96

Spend less time on SO at work, if you do so.
–
San JacintoSep 11 '09 at 15:16

52

If you are reading this, it's already too late
–
OMG PoniesSep 11 '09 at 16:28

32

I read "How to become a fatter programmer". Made me laught
–
marcggSep 11 '09 at 16:39

13

I would ask you a follow-up question. Is your desire to be a "faster programmer" a result of your own poor performance (AKA, you need to hone your skills, you need to focus and eliminate distractions (such as SO), etc), or is poor planning from a development standpoint (AKA, you were given 1 week to do something that any sane person would have known would take 1 month). Each item has very different solutions.
–
JasCavSep 11 '09 at 20:21

3

There's no single right answer possible, so make it into a community wiki question or have the question closed on you.
–
Donal FellowsMay 30 '10 at 15:42

87 Answers
87

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

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

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

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

Edit:

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.

Break your work down into small tasks which are (1) defined in scope (2) short - e.g. 2 hours.

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.

Work your list, crossing items off as you go.

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.

If possible, structure your work so that you're publicly committing to these timeframes - entering estimates in bug tracking, etc.

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.

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.

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.

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

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.

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.
–
GodekeSep 11 '09 at 15:00

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.

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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.

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

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

... 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 DunlaveySep 11 '09 at 23:11

1

Perhaps you could avoid the e-mail entirely and just organize a standup meeting.
–
Jim G.Sep 12 '09 at 15:44

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.