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

OR you could keep your computer on, and open i.e. MS Visio
–
sshowSep 11 '09 at 15:02

208

Pencil and paper or a whiteboard is faster than most applications that I've used.
–
Thomas Owens♦Sep 11 '09 at 15:03

24

Doing it on paper focuses the mind.
–
pjc50Sep 11 '09 at 15:10

100

why can't i downvote the visio comment? Not using visio is a certain way of speeding up development!
–
darasdSep 11 '09 at 15:32

52

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 FraserSep 11 '09 at 21:03

+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)
–
JaySep 11 '09 at 16:04

34

+1 for "avoid gold plating" -- this has been the cause of me missing way too many deadlines because of my perfectionist/anal-retentive tendencies.
–
DinahSep 11 '09 at 17:05

7

Typing - important point. Always amazed at the number of coders I meet who haven't learned to type...
–
PaddySep 11 '09 at 17:21

2

+1 eliminating distractions. As I see it, they are the major time eaters.
–
Umer AzazSep 12 '09 at 11:28

2

+1 for the tips to micro-improve (instead of macro-improvements in terms of planning projects).
–
MP24Sep 30 '09 at 8:30

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

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

underestimating the work that needs to be done;

missing a big requirement or architecture piece during planning;

confusing work estimates with calendar estimates and not accounting for things like meetings/phone/other overhead;

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

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

Some devs really are too slow though. It can be a problem.
–
Brian MacKaySep 11 '09 at 19:57

12

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 PenovSep 11 '09 at 20:31

12

'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.
–
fleshSep 11 '09 at 21:30

15

@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 PenovSep 11 '09 at 22:46

5

@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 PenovSep 13 '09 at 3:16

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

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 PenovSep 11 '09 at 20:35

1

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.
–
BeskaSep 11 '09 at 20:52

4

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 McMillanSep 11 '09 at 21:08

5

Along same lines: learn general 'hot' keys. E.g., in many Windows programs... Copy: Ctrl + c Cut: Ctrl + x (the 'x' looks like an open pair of scissors) Paste: Ctrl + v (right next to 'c' and 'x' above) Go to start of line: Home Go to End of line: End Move cursor by word (not character): [Shift] + Ctrl + left or right Go to top of doc: Ctrl + Home Go to end of doc: Ctrl + End etc.
–
steamer25Sep 11 '09 at 22:01

I would suggest "making it work" and if time permits getting around to perfecting it !
–
PreetsSep 11 '09 at 15:04

28

-1: There is no reason to sacrifice quality. You can always sacrifice features.
–
S.LottSep 11 '09 at 15:06

6

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

3

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 ThornleySep 11 '09 at 17:14

2

If you're stuck at one feature, work on something different.
–
mruegSep 11 '09 at 21:07

+1: Beware though, I've caught myself generalizing and abstracting something so that I could use it again another day... and missed that day's deadline or doubled the time the bug should have taken to fix... so that I could "maybe" save time later on.
–
Steve EversSep 15 '09 at 5:30

2

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 LustigOct 9 '09 at 22:06

When doing TDD, you have a test runner that produces a red/green report per test to indicate if they pass.
–
Frank SchwietermanSep 11 '09 at 16:22

2

@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 LuontolaSep 12 '09 at 18:51

3

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 LuontolaSep 12 '09 at 18:53

@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.
–
bryanbcookSep 12 '09 at 19:07

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.

+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 SchekSep 11 '09 at 16:21

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.)
–
BeskaSep 11 '09 at 20:56

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.

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

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.

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.

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.

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.

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.

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.

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?

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