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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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!