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.

  • 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
    Commented Apr 6, 2011 at 19:38
  • 3
    Possible duplicate: programmers.stackexchange.com/questions/55692/… Commented Apr 6, 2011 at 20:31
  • 1
    To try to win the race, some will choose their fastest horses and beat them to go faster. Any questions?
    – Paul
    Commented Apr 6, 2011 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. Commented Apr 6, 2011 at 23:51
  • 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
    Commented Feb 10, 2015 at 10:38

19 Answers 19


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.

  • 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
    Commented Apr 6, 2011 at 21:14
  • 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
    Commented Apr 6, 2011 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
    Commented Apr 6, 2011 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.
    – user7433
    Commented Mar 10, 2015 at 16:12
  • 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
    Commented Jan 11, 2017 at 22:36

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.

  • 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
    Commented Apr 6, 2011 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
    Commented Apr 6, 2011 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
    Commented Apr 7, 2011 at 5: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. Commented Dec 16, 2015 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
    Commented Dec 17, 2015 at 12:00

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/

  • 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
    Commented Apr 7, 2011 at 1:10
  • A recent favorite of mine is pragprog.com/titles/btlang/seven-languages-in-seven-weeks Commented Apr 7, 2011 at 4: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. Commented Jan 27, 2015 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. Commented Jan 27, 2015 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
    Commented Feb 3, 2015 at 13:13

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.

  • 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
    Commented Apr 6, 2011 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. Commented Apr 6, 2011 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
    Commented Apr 6, 2011 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? Commented Apr 6, 2011 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. Commented Apr 6, 2011 at 20:22

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.


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

  • 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
    Commented Apr 6, 2011 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? Commented Apr 6, 2011 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
    Commented Apr 6, 2011 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.
    – user1249
    Commented Apr 6, 2011 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
    Commented Apr 7, 2011 at 1:01

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.


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.


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

  • 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
    Commented Apr 6, 2011 at 20:27
  • automated testing for me is code smell. It means the code was not simple enough. Commented Apr 6, 2011 at 20:33
  • 7
    If your code is so simple that it doesn't need tests then it doesn't do anything interesting. Commented Apr 6, 2011 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) Commented Apr 6, 2011 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
    Commented Apr 6, 2011 at 21:56

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.


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.


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)

  • 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
    Commented Apr 7, 2011 at 1:05

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


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.


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.

  • 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
    Commented Apr 6, 2011 at 19:53
  • 1
    Above a certain minimal "hunt and peck" minimum, typing speed isn't the limiting factor.
    – user1249
    Commented Apr 6, 2011 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
    Commented Apr 6, 2011 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. Commented Apr 6, 2011 at 20:45
  • We're all level. None of us have the tools :)
    – ashes999
    Commented Apr 6, 2011 at 22:51

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!

  • 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
    Commented Apr 6, 2011 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... Commented Apr 6, 2011 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.
    – user1249
    Commented Apr 6, 2011 at 20:34

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.


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.

  • So you are saying you kind os sample-profiled yourself? Interesting. :) Commented Apr 7, 2011 at 6:00
  • actually it was a side effect of a time tracking method I tried for a while (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
    Commented Apr 7, 2011 at 8:09

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.