157

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.

yannis
  • 39,547
  • 40
  • 183
  • 216
ashes999
  • 1,129
  • 5
  • 12
  • 22
  • The comment "could be faster", is that in regards to writing the code, or how your code performs? Also, is this comment from someone with reasonable experience to know fast when they see it? – Berin Loritsch Apr 06 '11 at 19:38
  • 4
    Do others code faster than you at the same quality? If not, point to your maintainence records and bug reports to indicate that speed isn't an issue. – Michael K Apr 06 '11 at 19:38
  • An idea of what metric is used would help as I wonder if you even are working slow. Are there others who code along side you? Does the company you work for have multiple developers? Have they had developers before you? Is software their business? – Tim Apr 06 '11 at 19:42
  • How do you quantify coding speed and quality? – JeffO Apr 06 '11 at 19:42
  • @Berin Loritsch By coding faster, I refer to development time (eg. implemented bug fix in 2 days instead of 4 days) -- NOT performance. – ashes999 Apr 06 '11 at 19:44
  • @Michael my general observation is that some people who code faster do so at a significantly reduced code quality (readability, maintainability, and testability) -- but not always. A significant number can do the same work I do, much faster. – ashes999 Apr 06 '11 at 19:45
  • @Tim when I was at Oracle, there were other team-members who performed the same work that I did, faster. – ashes999 Apr 06 '11 at 19:45
  • @Jeff O quality is primarily readability, maintainability, and testability for the purposes of this question. – ashes999 Apr 06 '11 at 19:45
  • The next question then, is are the others doing something differently than you? For example, are they producing the unit tests to prove the quality of their code? Do they simply have a _better_ idea of how to solve the problem before they begin? It might be just a difference in experience in solving certain types of problems. It's really hard to say when I don't know you or your faster coworkers. – Berin Loritsch Apr 06 '11 at 19:49
  • @Berlin Loritsch I don't know why. I chalk up a lot of it to experience and familiarity with the systems -- when you've spent 10 years fixing bugs in X system, the new guy with 2-3 years can't do it as well as you. But I'm hoping there's more to it than that. – ashes999 Apr 06 '11 at 19:50
  • @ashes999: That is relatively normal, especially for larger systems. Don't panic to much about it. Once you've been there for 10 years, the new guys will look up to you as "The Fastest Coder". – FrustratedWithFormsDesigner Apr 06 '11 at 19:52
  • @FrustratedWithFormsDesigner I'm worried that it's been consistent; and I hope that there's more to it -- that I can, on my own solo projects, churn them out faster somehow. Hence my question. – ashes999 Apr 06 '11 at 19:54
  • are you working at a single company or working from contract to contract? – agradl Apr 06 '11 at 20:27
  • 3
    Possible duplicate: http://programmers.stackexchange.com/questions/55692/how-to-write-efficient-code-despite-heavy-deadlines – Corbin March Apr 06 '11 at 20:31
  • @shiznit123 I work as a hobby game developer; professionally, I've worked in around 5 different companies (full-time, all). – ashes999 Apr 06 '11 at 22:48
  • 1
    To try to win the race, some will choose their fastest horses and beat them to go faster. Any questions? – Paul Apr 06 '11 at 23:42
  • 27
    I don't have an answer for you but I do have something that may make you feel better. However slow you may be as a programmer, however inefficient you might feel, *your manager* is much, much worse. What kind of idiot says, "Hey Bob, you're too slow" without helping you to improve? Might as well tell you you're too short. That's not leadership, it's just heckling. I guess I do have a suggestion: find a job with a competent manager, one who will work with you to overcome your shortcomings. – Michael Lorton Apr 06 '11 at 23:51
  • That's why he's not my manager anymore. :) – ashes999 Apr 09 '11 at 21:30
  • I just want to say, I am in the same boat. I produce top quality code, minimal bugs, well documented, easy to read and navigate, follow OOP practices and the likes. My work is beautiful and a reflection of myself.. but I know I am slower. Now management is telling me speed > quality... and i cannot swallow writing crappy code. sigh. – Tony Nov 14 '14 at 19:52
  • @Tony might be a good idea to start looking for a new job. In my experience, you always have to deal with that tradeoff though. Telling developers "you're slow" is not like telling developers "please cut corners and go fast now because the release schedule is more important right now." – ashes999 Nov 14 '14 at 20:45
  • @ashes999, yeah and if you knew the context i got told i need to code faster.. it was during a meeting when i was bringing up concern about another devs extremely poor code quality :O! code quality was one of the reasons i left my last job. they all want it fast no matter the cost, i want it right so we don't have to go back and pay those costs 10 fold. saw a recommendation for vim, gonna see if i can pick it up and at least increase the speed a little more. i use R# hot keys like a mad man so hopefully vim will come a little more natural. – Tony Nov 14 '14 at 20:52
  • 1
    All the answers make me unhappy. If you just want the step noob->mediocre then maybe doing one thing is alright. But mediocre->expert always requires to learn everything. You need to learn your VCS, your editor, your programming language and your frameworks in depth. You need to repeat tough and interesting steps that you can do them without thinking. And then you need to find a way to apply context, like the difference between customer needs and your coworker's needs, how your daily mood influences your ability to code/design/discuss. If you want 1 thing do this: learn everything. – erikbstack Feb 10 '15 at 10:38

19 Answers19

173

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.

chrisw
  • 817
  • 2
  • 7
  • 14
  • How do you recommend I study designs? Where can I go and review code from smarter people that I can learn from? – ashes999 Apr 06 '11 at 19:52
  • Personally, I tried to get involved with a few open source projects and pick up from there. There's also a really good book on design patterns which you can pick up here: http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/ref=sr_1_1?ie=UTF8&qid=1302119675&sr=8-1. That book helped me out a lot. – chrisw Apr 06 '11 at 19:54
  • 19
    Does this analogy not imply that the potters produced a pile of garbage pots before producing the quality ones though? Could you do that in a professional environment, in all conscience? And what about those who studied and theorised and then got the job done before the deadline? – pdr Apr 06 '11 at 21:14
  • If you are spending a lot of time adding features and debugging those features, it's not really any different from building a lot of pots, is it? – user21007 Apr 06 '11 at 21:42
  • 1
    I like the story and I get what it's saying, but what if it's giving permission to people to just zerg things without thinking at all? "If we add 20 programmers to this project, we can't fail! I read an article about it on the Internet!" – Mark Canlas Apr 06 '11 at 22:00
  • 4
    I'm OK with 20 garbage pots for hobby programming experience. That helps me with my professional programming experience, too; besides, gotta start somewhere. – ashes999 Apr 06 '11 at 22:49
  • 28
    I just choose to look at this for surface value, "practice makes perfect." Don't look too deep into it ;) – chrisw Apr 06 '11 at 23:20
  • 7
    I dislike this answer because it can be too easily taken the wrong way, just like "throwaway prototypes" never really seem to be thrown away. –  Mar 10 '15 at 16:12
  • Is this story true or just a thought experiment? Unless it is tested I wouldn't buy it as example. – Ski Mar 13 '15 at 19:56
  • I find this answer verbose and incomplete. Yes coding more will make you better. But well planed code will be shorter, less bug prone and easier to extend. so. 1. Code a lot but always look back at old code for better ways to do things. 2. Know design patterns and use them. 3. Learn as many shortcuts as you can. 4. Take time to setup a fast testing environment, if its backend, good shell scrips can save time... 5. Get feedback from peers and learn. 6. Work on technically complex projects. – Andres Canella Dec 16 '15 at 15:34
  • 3
    I find it strange that so many people have a problem with this. It's almost a perfect analogy for the iterative development process. You build something fast to meet the requirements, fix bugs and refactor until it's correct and good enough. If you aren't building software this way, you really need to try it. Rumination and navel-staring are far less effective than getting something done and letting people bang on it. – JimmyJames Jan 11 '17 at 22:36
  • In my experience the group who is graded for quantity will not produce better products over time, they generally never see quality and can't improve, just keep making variations of the original forever. It's unrealistic to think the quality group only made one and never attempted to make various attempts only to just deliver their best one. If the quantity group is best spending their time making products then when could they have time to learn from those who may know better? – Michael Ozeryansky Jan 10 '20 at 04:26
  • I think that says more about statistics than about the quality of the potters. Even if the pots were completely random and there was no difference in potter quality, the odds of the best pot being in found in the group of 50 is much higher than the group of 1. – steventrouble Jul 13 '21 at 02:10
72

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • 2
    This is probably a large part of the problem. Looking at it in retrospect, it seems too concidental that I'm always compared to people who are working in my company years longer than I have. Hmm ... – ashes999 Apr 06 '11 at 20:21
  • If that is the case, my advice is to ask the first two of my questions directly and see what response you get, take it from there – pdr Apr 06 '11 at 20:23
  • 17
    how very true, so often have I encountered managers stating I was incompetent when the projects I output in production systematically generate one or two order magnitude less support calls than equivalent work from other teams. Many simply fails to see the bigger picture. Metrics helps about as much as it is a nuisance. Usually such manager will attempt to game the system such that their stats look good. – Newtopian Apr 07 '11 at 05:22
  • This is more a comment than an answer. Personally I always want to become faster and more efficient as a coder, regardless of what others think. There is definitely a lot to discuss on the topic. – Andres Canella Dec 16 '15 at 15:40
  • @AndresCanella Every answer in this question is basically a long comment. You're right, there's a lot to discuss. This really isn't a good format for discussion (nor is it intended to be). But it was a good question to start with, which is why it's closed and marked as Community Wiki -- for which no one gets reputation points -- rather than deleted. – pdr Dec 17 '15 at 12:00
40

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/

Rein Henrichs
  • 13,112
  • 42
  • 66
  • Can you suggest other sites / terms to google? I think tackling one weird challenge a week might get my brain moving in different dimensions. – ashes999 Apr 07 '11 at 01:10
  • A recent favorite of mine is http://pragprog.com/titles/btlang/seven-languages-in-seven-weeks – Rein Henrichs Apr 07 '11 at 04:53
  • 1
    The part at the very beginning makes no sense. Anything that makes you faster makes you faster. If at least some of your time is spent typing, then improving your typing speed will make you faster. If at least some of your time is spent waiting for the computer, then a faster computer will make you faster. When you are on a quest to become as fast as possible and constantly improve, nothing should be overlooked. – still_dreaming_1 Jan 27 '15 at 16:36
  • 16
    The small things like typing and computer speed make a big difference. This is because of the unexpected side effects. When you have to wait for your computer, most people become frustrated and some even become distracted. The combination of frustration and distraction are huge productivity killers. Something similar applies to typing. If you are fast at typing, that probably means you have gotten really good at touch typing, and you probably don't put much thought into typing. This frees up your eyes and brain to focus on the task at hand, a huge productivity booster. – still_dreaming_1 Jan 27 '15 at 16:39
  • @INTPnerd I agree. If you spend time thinking about how the word "throw" gets on your screen ("I need to move the mouse there, then click, then I need to find the 't' on my keyboard") your brain also has no time to consider the actual decisions. – erikbstack Feb 03 '15 at 13:13
  • It definitely depends on the situation, I think one (i.e. still_dreaming_1's comment) gives way to the other (answer). if you're being bottlenecked in productivity by something like a slow computer, that definitely is your problem, but the second that is solved (recently got a computer upgrade), you end up getting your work done faster. I find that creating my to-do list is more time consuming than doing the to-do list these days. – Shelby115 Mar 25 '20 at 23:59
25

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

In some development environments1, 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.

Jens Bannmann
  • 525
  • 3
  • 12
Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
  • 6
    That's what I concluded from my early jobs -- others were writing significantly lower quality, at the cost of great speed. That's my achilles heel; I find it very hard to write bad code that I know will bite me later. – ashes999 Apr 06 '11 at 19:58
  • That's an easy problem to solve. you need to change your software environment. You need to work in an environment where getting it right is valued more than getting it done quickly. There are jobs out there where it does matter. – Michael Shaw Apr 06 '11 at 20:16
  • Having worked in environments where both are equally valued, among all those who get it right -- those who get it right *faster* are beating those who get it right slower. And I think I'm in the latter group. – ashes999 Apr 06 '11 at 20:17
  • 3
    okay, in that case, its probably down to the strategies you use to write, test and debug code. ask if you can pair program with a "fast" programmer and see how they organise their thought processes? – Michael Shaw Apr 06 '11 at 20:20
  • 1
    @ashes999: With practice and experience and patience you will move from the latter group to the former group. There's no magic pill to take that will transition you overnight. – FrustratedWithFormsDesigner Apr 06 '11 at 20:22
13

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.

Stephen Bailey
  • 2,236
  • 14
  • 14
8

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

Buhake Sindi
  • 830
  • 9
  • 16
  • I really hope this is not the right answer; I already spend a lot of my free time coding, and I hope there's something else I'm missing that will give me a significant edge. – ashes999 Apr 06 '11 at 20:00
  • @ashes999, ok! with free time coding, do you review your work? My point is, there must be time to work on optimisation of code and get the hang of it. We can all code, but how many times do we give ourselves time for optimisation? – Buhake Sindi Apr 06 '11 at 20:03
  • @TEG I review it between projects; eg. if I coded something in a certain way on project #1, on a similar project #2, I might reflect on the design flaws and refactor a lot. – ashes999 Apr 06 '11 at 20:06
  • @ashes - "refactor a lot" means you have a time sink right there because your initial design wasn't optimal. If your boss doesn't know you have a problem explaining where the hours went. If the boss does know, you have a problem explaining why you did not have your design reviewed by an experienced coworker in the first place. –  Apr 06 '11 at 20:32
  • @TRA sorry, I should've specified -- on *hobby* projects I refactor a lot. At work, I refactor lightly, or create visible tasks so that my manager knows I'm refactoring. – ashes999 Apr 07 '11 at 01:01
8

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.

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.

still_dreaming_1
  • 261
  • 1
  • 13
5

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

Christopher Mahan
  • 3,404
  • 19
  • 22
  • 3
    Testing makes me faster, not slower. Less testing means more regressions go unspotted for longer and are harder to fix, because you can't take big leaps in code for fear of "something might break." – ashes999 Apr 06 '11 at 20:27
  • automated testing for me is code smell. It means the code was not simple enough. – Christopher Mahan Apr 06 '11 at 20:33
  • 7
    If your code is so simple that it doesn't need tests then it doesn't do anything interesting. – Rein Henrichs Apr 06 '11 at 20:41
  • How do you know, exactly? Oh, assuming again... I'll refer you to Rule of Modularity: Write simple parts connected by clean interfaces. (from The Art of Unix Programming) – Christopher Mahan Apr 06 '11 at 20:55
  • I think you may have something, there, Christopher. It is here where ashes99 is spending a lot of time, e.g. "slew". Too much of anything is a bad thing. In this case, unless you are righting code for flight control systems, you may want to re-think the amount of testing you do. Or go into that sort of field. – user21007 Apr 06 '11 at 21:56
  • @ashes999 Do those who get it equally "right" do significantly less testing than you? If so, you may have found your problem. I know it's uncool to rain on the parade of automated testing, but sometimes there can be too much of a bad thing. For something simple, I write some code (e.g. a function), test the output including some edge cases, and then move on. I save the automated stuff for medium to big things. – user21007 Apr 06 '11 at 21:59
  • I consider myself an intermediate tester. Most people don't right enough tests, and those that they do write are brittle and unreadable. People who don't believe fully in automated testing find it hard to understand that you spend 80% of your time writing and maintaining tests (thus spotting regressions immediately), and 20% of the time writing "new" code. – ashes999 Apr 06 '11 at 22:53
  • I'm going to quote Doug McIlroy, quoted in "The Art of Unix Programming". He said "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features." – Christopher Mahan Apr 06 '11 at 23:13
  • @Christopher Mahan some systems, like 2D tile-based game engines, need time to build up. Right now, I've been transferring source and *not* binaries from game to game; this means I can cut out features, etc. from the source, and not worry about backward compatibility. It works well. – ashes999 Apr 07 '11 at 01:02
5

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.

Bill K
  • 2,699
  • 18
  • 18
3

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.

Community
  • 1
DKnight
  • 3,897
  • 1
  • 22
  • 31
3

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)

Tim Williscroft
  • 3,563
  • 1
  • 21
  • 26
  • Lots of great points here. I need libraries because I need a feature for game X (eg. Silverlight storage across multiple sessions of my game), and I can tell that they will we needed later -- or they're just abstract code (like path-finding) that have nothing specifically to do with my game. I have a comp-sci background, so I've done procedural, OO, functional, and the other one (Prolog). Graph theory, yeah; depth-first graph recursion I've used very often, weirdly enough. – ashes999 Apr 07 '11 at 01:05
3

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

Community
  • 1
johnsyweb
  • 399
  • 2
  • 10
3

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.

Community
  • 1
Nico
  • 99
  • 3
2

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.

mpenrow
  • 1,653
  • 13
  • 16
  • I'm at a level playing field with my co-workers regarding these things (maybe I have an edge in typing speed); they're still faster, somehow. Experience, maybe? – ashes999 Apr 06 '11 at 19:53
  • 1
    Above a certain minimal "hunt and peck" minimum, typing speed isn't the limiting factor. –  Apr 06 '11 at 20:31
  • 2
    You might be level with them in *having* the tools (e.g., Resharper), but do you know how to use them effectively? I've seen a lot of people install Resharper and then not learn how to use 80% of the features. For that matter, make sure you understand all of the refactoring and shortcut features of Visual Studio. I get an easy 2-3% edge over anyone else at my office just from keeping my hands on the keyboard all day. Mice are slow :) – E.Z. Hart Apr 06 '11 at 20:37
  • @E.Z. Hart: Very good point. Some modern IDEs (I'm thinking of Eclipse, off the top of my head) have very powerful tools for refactoring, searching for code references (such as where is a class or method referenced, not simply where does the text "myMethod" appear). For some of these "advanced" features, it's worth spending 5 minutes to learn it to be able to manage the code base much more efficiently. – FrustratedWithFormsDesigner Apr 06 '11 at 20:45
  • We're all level. None of us have the tools :) – ashes999 Apr 06 '11 at 22:51
2

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!

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • It's not timelines; other co-workers can do the same work faster. Maybe it's experience. +1 for typing speed; I can type around 100WPM, so that's not it either. – ashes999 Apr 06 '11 at 19:51
  • @ashes999: and if the people who can do the same work faster are more experienced, then you would probably benefit the most from more experience with the systems in question. Experience requires time... – FrustratedWithFormsDesigner Apr 06 '11 at 19:53
  • code generators are a mixed blessing. They may save you time, but if you have to spend too much time on the generated code the saving may turn to an unmanageable loss. –  Apr 06 '11 at 20:34
2

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.

9dan
  • 220
  • 1
  • 3
2

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.

Newtopian
  • 7,201
  • 3
  • 35
  • 52
  • So you are saying you kind os sample-profiled yourself? Interesting. :) – sum1stolemyname Apr 07 '11 at 06:00
  • actually it was a side effect of a time tracking method I tried for a while (http://davidseah.com/tools/ett/alpha/). Turned out some interesting and unexpected data trends when I started to look at it beyond the time tracker part. It is after I learned about pomodoro, GTD and such. – Newtopian Apr 07 '11 at 08:09
0

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.