How to Code Faster (Without Sacrificing Quality) [closed]

Question

I've been a professional coder for a several years. The comments about my code have generally been the same: writes great code, well-tested, but could be faster.

So how do I become a faster coder, without sacrificing quality? For the sake of this question, I'm going to limit the scope to C#, since that's primarily what I code (for fun) -- or Java, which is similar enough in many ways that matter.

Things that I'm already doing:

• Write the minimal solution that will get the job done
• Write a slew of automated tests (prevents regressions)
• Write (and use) reusable libraries for all kinds of things
• Use well-known technologies where they work well (eg. Hibernate)
• Use design patterns where they fit into place (eg. Singleton)

These are all great, but I don't feel like my speed is increasing over time. I do care, because if I can do something to increase my productivity (even by 10%), that's 10% faster than my competitors. (Not that I have any.)

Besides which, I've consistently gotten this feeback from my managers -- whether it was small-scale Flash development or enterprise Java/C++ development.

Edit: There seem to be a lot of questions about what I mean by fast, and how I know I'm slow. Let me clarify with some more details.

I worked in small and medium-sized teams (5-50 people) in various companies over various projects and various technologies (Flash, ASP.NET, Java, C++). The observation of my managers (which they told me directly) is that I'm "slow."

Part of this is because a significant number of my peers sacrificed quality for speed; they wrote code that was buggy, hard to read, hard to maintain, and difficult to write automated tests for. My code generally is well-documented, readable, and testable.

At Oracle, I would consistently solve bugs slower than other team-members. I know this, because I would get comments to that effect; this means that other (yes, more senior and experienced) developers could do my work in less time than it took me, at nearly the same quality (readability, maintainability, and testability).

Why? What am I missing? How can I get better at this?

My end goal is simple: if I can make product X in 40 hours today, and I can improve myself somehow so that I can create the same product at 20, 30, or even 38 hours tomorrow, that's what I want to know -- how do I get there? What process can I use to continually improve? I had thought it was about reusing code, but that's not enough, it seems.

Answer 1

I like Jeff Atwood's approach to this which can be found here http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html.

Basically in the article he references a passage from the book Art & Fear by David Bayles and Ted Orland. The passage goes:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Essentially getting your hands dirty faster and more often improves your skills better, than spending your time studying and theorizing about the "perfect" way to do it. My advice, keep practicing, keep up with technology, and study design.

Answer 2

One possibility that no one else seems to have mentioned is that you're doing just fine and your managers aren't very good. How are they measuring productivity? Can they give you specific examples or is it just a general perception? Have they taken into account the amount of time spent fixing other peoples' work compared to yours?

I've seen plenty of people get credit for getting stuff done, while the rest of their team fixes up the mess they've left behind.

Answer 3

Most of what people think is important is not important. Typing speed is not important. Faster machines or tools are not important. We are not typists or machine operators. We are thought workers. We are decision makers.

What is important is using feedback to continually improve your decision making process. The only way to do this, like acquiring any other skill, is through experience, purposeful practice, and continuous feedback.

• Work on side projects.
• Work on open source projects.
• Work with developers who are better than you. Pair program!
• Expose yourself to new tools and techniques. Keep what works.
• Do programming exercises designed to train your decision making apparatus*.
• Monitor your improvement based on objective metrics like defect rate and velocity, and subjective metrics like code quality and fitness.

Finally: remember that speed without quality is useless, and vice versa. To maximize your utility, find a balance between these tensions.

* http://codekata.pragprog.com/

Answer 4

It's quite possible that actually, you are being asked to sacrifice some quality, for greater speed.

In some development environments¹, it is simply not worth the extra time to produce something polished, when "just good enough" will do.

---

^{1 - I'm thinking of "internal toolsmith" in particular, but there are probably others.}

Answer 5

It sounds like you are doing all the good things - that in the medium term will make you faster, so it is not obvious if you are actually slow. Only you really know that. ( but it is a very real possibility - PeopleWare claims an up to 10X productivty difference between developers for the same task ).

So I have some suggestions for you :

1. Time is a relative thing, so perhaps the issue is not your actual speed but rather the perception of time you are giving. You might imply it will take a week, but end up spending two weeks, where others might spend 3 weeks... but you just look 1 week slow.

2. Since you are getting this feedback often, perhaps time to talk to your manager and peers to see what they say - there must be much to learn from them.

3. Do some pair programming with a "fast quality" developer to see if you can spot the difference.

Answer 6

Effectively, what it boils down to is experience. To be faster at what you do is like driving a car, initially you're scared since others are fast (or drunk) drivers (or both) and you want to reach safely home (in software terms, you want to make sure your code works as developed and it works well).

Over the years/months, once you get the hang in of driving and the freeways, you learn few tricks along the way that makes your driving fun. That's what we call experience. Those "tricks" (which I call traits) is what helps.

In my case, I've learned the real use of design patterns by coding (even @ home) and learning the uses of some. Thus, when I encounter a problem that requires a design pattern, I use past experience to see which ones worked and why would it work/not work for my situation.

In summary:

• Experience creates traits which boost confidence and better software.

PS: Experience also comes from learning from others. E.g. Help from SO, Pair Programming, Peer Reviews, etc. You can't have an experience if you cannot look back and learn from mistakes (or if someone never challenges your effort).

Answer 7

Question is if you are less expensive when looking at the long term total cost.

In other words, is your carefully crafted bug fixes of such high quality (including test cases and documentation) that it outweighs the costs of having to maintain the bug fixes done by your faster co-workers?

If yes, then you need to make your superiors aware of this fact. It may be hard to argue for if they do not measure and have the necessary data to confirm your assessment.

If no, then you strongly have to consider why this is the case:

• Are you too inexperienced?
• Do you spend much to much time doing things not requested which you believe should be there?
• Do you have a hard time determining when the fix is finished?
• Is your code of a lower quality after all than you think it is?
• Should you approach code development in a different way because it takes you too long to get up to speed the way you do it now?
• Do you spent too much time on things like this site?

Think it over and edit your question with your findings.

Answer 8

All the questioning people have done of whether or not you are truly slow is silly. Becoming a faster programmer without sacrificing quality is always a good goal no matter how slow or fast you already are. This is my number 1 goal as a programmer and I will never be done. I am always trying to get faster without sacrificing quality, I am obsessed with it. Here is what has worked for me so far in the order of helpfullness, along with some experimental ideas at the end:

1) Never stop learning: Learn everything you can about programming and using computers in general. Find areas you are weak in and learn them. Even if it seems completely unrelated to your work and C#, I guarantee that if you are looking for it, you will often find ways to apply it to what you do. Learning is also about experience, so don't just read stuff but try it out and expand your skills. If you are used to using Windows, try out Unix or vice versa. If you normally like to use IDE's try command line tools and text editors or vice versa. If you hear of a tool or technology you have not heard of before or don't know much about, don't give in to the temptation to move on. Look it up! Don't be afraid to think outside the box and learn experimental new technologies that others say are unpractical; We are just beginning to scratch the surface of how to program productively.

2) Break up projects: Try to break up your projects into mini projects. Try to do a new release every day or once every few days at the most. Ask yourself "What is the minimum amount of functionality I can release, and still release something that is useful to the user." This is a skill you will learn by doing it. You may need to convince your managers to let you do this, but they will usually be happy with the results quite quickly. By doing this you will start to notice that things that you thought were essential to your feature are actually additional features that can be developed later. This allows you and your managers to prioritize only the most important features instead of all the features related to the one you are working on. This allows you to think faster by keeping your mind clear and focused. You will in turn legitimately program faster. Your managers or at least your manager's managers are also likely to perceive that you are now programming even faster than you really are because you are getting more releases out. Another huge benefit of this is that you will be much better at estimating how long releases will take to complete, and your managers will love you for this. Since you are already doing lots of automated testing, you should have no problems doing frequent releases that are stable. You may need to beef up your automated build system though. I highly recommend reading the book Continuous Delivery in the Martin Fowler series. It's a hard read and because it's extremely repetitive, but still very helpful.

3) Use the pomodoro technique and adapt/change what does not work for you. If you combine this with number 2 on this list, you will get a HUGE productivity boost.

4) Learn Vim. Even if you end up using these commands within Visual Studio via ViEmu, or a from within Eclipse via a plugin, or from within Emacs, you will gain productivity. The best way to learn Vim is to start using it and force yourself never to (disable it/go back to your old tools) until you have mastered it. It is painful at first, but you will never want to back, and even cringe when you have to work without it. Some would say this will not increase your speed by much. But faster is faster, especially when reading and modifying code is WHAT WE DO, and I have found myself saving lots of time with this on occasion.

5) This last one is not necessarily recommended as I am not sure it is a good idea, and it may actually decrease your productivity, but I will through it out there anyway. You might try doing more acceptance tests and less unit tests, or perhaps at least make sure you do some acceptance testing. I have had success with SpecFlow, but I suspect there is something better out there. Even writing the specs can be pretty technical, so you may want to just have your manager/customer write a rough draft version first that you change significantly, or you may write the entire thing yourself and just have them read and OK it. This will help you with number 2 from this list. Also acceptance tests can be more practical and require less code than unit tests. This is not to say they replace them, different tools for different things. But you might be able to get away with less unit testing if you do a lot of acceptance testing.

6) This one is even more experimental and controversial. I have not actually done this myself so I can't exactly recommend it. Learn and use the Meta Programming System from JetBrains. Use it to create tools that your manager/customer uses to create the desired software themselves. You might even be able to stop doing unit and acceptance tests if you can use this to make tools that your manager/customer uses to specify the behavior in a very straightforward and non-convoluted way. The idea is not to get rid of the programmer. The programmers would still need to add new features to these tools used by the customer/manager whenever they (the people, not the tools) can't easily create some desired functionality. I do believe that either MPS or other tools similar to it are the way of the future.

Answer 9

Use your brain more and do less testing. To be honest, testing has its place, but it is expensive.

Also, read The Art of Unix Programming (free online, book worth the price)

Finally, you may not be in the right place. Round peg in square job, etc.

Ultimately it's like school: "Output what the teacher wants" becomes "output what management asks and pays for".

Answer 10

If you take a largish, finished project and get the number of "final" lines of code per man hour you will find that programers code MUCH slower than you could have imagined.

We're talking just a few lines of code a day. The rest of the time you spend debugging, re-writing and doing general programmer stuff.

You may have heard the old saying--if you catch an error while you are typing it, it will save you 10x the time over if you caught it at build time, which is 10x better than catching it during QA, which is 10x better than catching it after release..

So how do you speed it up? I would not concentrate on any form of typing speed--reducing errors and improving other "future interactions" with your code should be a much better investment of your time.

Readable, clear code is critical. You write your code once, but it will be read dozens of times. Writing for readability will save you LOTS of trouble down the line (which will also save a lot of time). If you EVER go back and read your code and have to think about it for even a second then you're doing it wrong.

Pair programming can reduce QA time and, if you consider one programmer produces just a few lines a day, if two can code at the same rate as one but with less errors then you're WAY ahead.

Coding defensively (for instance, parameter checking) can reduce problems... If you have a really good analyst/architect on your team then you can save some time with a good starting design.

Otherwise just keep improving your design skills. As you gain experience you will find yourself more able to recognize patterns that won't work and avoiding them, you'll be able to identify time sinks earlier, etc.

Answer 11

Have you considered doing a detailed audit of yourself as you work? Either pen and paper tracking of how you are spending your time or use something like Rescue Time to track yourself.

Once you are more aware of exactly HOW you spend your time you can get a better idea of what needs improving and focus your efforts there.

Ideally you can challenge some of your coworkers to do this too, compare your results, and get ideas from each other. You probably have some strengths they could benefit from too.

Maybe you find out that you are spending too much time on a part of your process that could be automated or just that you have many distractions during a certain part of day and another part of the day is quiet, then you can plan your tasks around that, etc.

Or maybe you find out that testing is taking more time than you thought and you have to rethink your perception that it is making you faster.

If nothing else it gives you some benchmarks you can work against.

Answer 12

From your list you're doing fine.

If your colleagues are making code with a higher CRAP number, they will go faster. CRAP is a comically named metric combining cyclomatic complexity and Test coverage.

Don't write code that is more CRAP than you have to. ;)

My only change to suggest for you is to use libraries, don't write them unless:

1. Your company sells libraries
2. You have refactored recurring code into a library

You're reading and doing and that's great. But you might be stuck thinking about procuedural or OO code, Have you exposed yourself to Functional programming (say Haskell?) and Prolog ?

To sharpen your OO programming technique, have you played with Smalltalk/Squeak ?

And finally, theory. Do you have at least a rudimentary understanding of graph theory ? (Some programs work with trees, DAGs or just plain graphs at some point. Networks are graphs)

Answer 13

I'm going to quote Uncle Bob:

The only way to go fast is to go well.

Every time you yeild to the temptation to trade quality for speed, you slow down. Every time.

--"Vehement Mediocrity", Robert C. Martin

Answer 14

As far as I know it's:

1. good
2. fast
3. cheap

As a manager, you can pick any 2.

Don't worry about the comments you've been getting on speed. As a fellow coder I would rather maintain code that's well thought out and well written than something that was slapped together.

Answer 15

The main things I can think of are as follows

• Increase your typing speed.
• Use tools that provide productivity gains. For example ReSharper.
• Faster machines or tools. Like more RAM or a solid state drive.

I'm sure there are some things you can do in the coding skill area as well but it sounds like you are all over those kinds of things. The things I listed above are typically overlooked by developers.

Answer 16

You could take a speed-typing course. I don't know if typing faster is problem but "coding too slowly" could be caused by simply slow typing speeds.

What about code generators? Sometimes code gets repetitive. Refactoring can remove some of it, but even then you may have repetitive calls to the same refactored function. Depending on the data and code you work with, code generators (written in Excel, Perl, Java, whatever...) might save a lot of time. And using code generating tools for UI development is usually a no-brainer.

And finally, maybe the metrics are wrong. Have you considered that you're coding at the fasteset possible speed given everything else, and that the timelines are too short, making you appear to be a slow coder?

---

Based on the edits in your question, it seems like you could either take the route of some of your co-workers and hack together the quickest solution that will work - and documentation and QA be damned!

Or... get more experience and practice in a specific area so that you know the codebase and API so well you could code the solutions in your sleep. This can be done but requires more time. If the other developers that are faster than you are known to be more senior and more experienced then there is only one thing to do - you must become more senior and experienced!

Answer 17

I have an objection to OP's "sacrificed quality for speed" view.

Professional coders(programmers) need to satisfy 3 objects:
1) Code should run as intended
2) Delivery should be in time
3) Have good quality, documentation, etc.
4) Other etc.

I think, OP was blamed as slow probably because OP didn't done in time.

Answer 18

This is a catch 22 that is hard to get around. Though you may still lack experience and some amount of knowledge in many aspects already are faster than most, the catch is that it is harder to measure.

Personally the best you can do at this point is to measure yourself. Provide yourself feedback on how you work, perhaps simple changes in your work habits can make you more productive.

I found mails were eating away much more than I thought simply because of the interruption. Now I only answer mails twice a day and gained almost 1 hour of productivity some days. Try methods like pomodoro, I used it as a measure means. At regular intervals (15 mins) I would note down what I was doing at that time. This allowed me to see how my days were structured and what I could do to maximize efficiency.

Answer 19

Squeak's advantage for fast coding goes far beyond just "honing one's OOP skills." There's a reason why modern GUIs, as well as IDEs, were invented on Smalltalk, not to mention JUNIT was a port of SUNIT to Java, the term "OOP" was invented to describe Smalltalk, etc., etc.

One must always use the language and environment best suited for whatever one hopes to accomplish, but for general prototyping, at least, I'd match squeak against anything, with the possible exception of HyperCard, and even that would require benchmarking to see which was actually faster given that there are hypercard-like facilities built into Squeak.