My manager has talked with me and says that the quality of my work is excellent, but I need to step up the quantity of how much I crank out. I've only been working for a couple of years, so I still feel like I have a lot to learn. Which route do I take (or is there another?):

Quantity: If they want crap, I can give them lots of it.

Quality: Ignore the request, and hope that my productivity will increase with experience.

  • 1
    Making better quality code helps me to do MORE code, not less. Your question assume a false dichotomy.
    – deadalnix
    Aug 22, 2011 at 17:56
  • see also: Does craftsmanship pay off?
    – gnat
    Jun 19, 2015 at 23:41
  • presumably the manager gets his view of expected quantity from other members of the team. Are they cutting out things you dont. Or are they just faster at typing it in?
    – Ewan
    Jun 27, 2015 at 17:49

7 Answers 7


As other stated in their answers, quality is very important from a technical point of view.

But quality is also very important for motivation. If your boss asks you to make shit, on the long run, it will destruct you. Imagine yourself in a drink answering the question "what do you do?" you won't answer "I write shit for a insane manager" isn't it? But you will think it loudly...

I think that the key in organization is making its employees proud of what they make.

That said, quality can be one of the four factor that you would reduce in order to get to the market. Four factors are resources, time, scope, and quality.

I've once worked on a project where resources was limited, scope vital and deadline fixed to tbe first if january by a contract that would have make that company loose millions every minutes of late.

The decision has been made to do our best but withou considering quality over time & scope.

The application generated enought profit on its first hour of run to paid back past development AND the complete rewrite that was planned afterwards.

Conclusion: quality IS very important, but sometimes, business priorities requires you to reduce it for the well being of the whole organisation.

  • This is helpful! I think i am getting lost in the creative aspect of my work instead of the business. $$ is what speaks the truth.
    – Adamizer
    Oct 26, 2010 at 13:15
  • I would write "in the long run it will destroy you" instead. 'Destruct' is usually taken literally and applies to destructible objects (real life or oop ones).
    – Job
    Aug 22, 2011 at 18:00

Remember that you need to actually ship software for it to be useful: there's no point in writing the most awesome code in the world if it isn't available when it's needed.

It's one of many requirements that you need to balance. Assuming your manager is competent I'd be listening to them: they're more likely to know the quality/speed ratio required for the project than you (as a fairly new dev) are.

Or to use a common phrase: the perfect is the enemy of the good.

  • @Adamizer shouldn't sacrifice quantity for quality, but he can see if there are ways he can go faster without sacrificing actual quality. Are there places he's gold-plating, adding quality where it's not needed? Is he spending too long thinking about what to do before doing something? Maybe not, but he can look at it. Oct 26, 2010 at 12:27

Quality code will, in the long run, cost you less time to maintain. Also, in theory, you should be reducing the time your QA team needs to test your code because there will be less bugs for them to document. Finding ways to reuse components you've already coded or are in the process of coding will speed up your apparent quantity.

I would stick with quality if given the choice. I'd rather be known for high quality code then for being able to spew out a lot of junk.

  • 1
    Best answer here IMO. Sacrificing quality is never a good idea and will always screw you at some point down the road. If you have to sacrifice quality, chances are something else is flawed for you to even consider that as a viable option. Aug 22, 2011 at 18:32

Start thinking of projects more generically, start building your own frameworks for things and as time progresses your toolkit will grow to such a degree that you will start to be able to snap together old projects to create new ones, that is when the quantity will grow whilst maintaining quality.


If you are currently writing good code, I guarantee you that you will get faster and faster as you get more experience.

If you are currently writing code quickly, there is absolutely no guarantee that you will ever write higher quality code.

So I would say that you are on the right track.


It is a matter of how you define quantity?

  • Number of lines? -- Bad metric
  • Use cases addressed -- Good Metric

To me it is a matter of perspective. If I write 10k lines of code to solve a problem and another needs merely 200 lines of code along with an open source library which is more productive? A matter of opinion.

However, when it comes down to it your manager is the one making these opinions so you need to understand how he places metrics of developers productivity and how does he explicitly quantify quantity for you to better understand.


When is the last time you went out to a restaurant? Did you go to 5 star because it has the best quality? Probably not, there is a cost trade off. Programmers are expensive and clients dont often want or need top quality. If the bare minimum gets the job done to the customers satisfaction there isn't any point over engineering it.

  • 1
    Can't agree with this (but can't downvote either because the points are valid). If you write garbage code it will come back to bite you when you have to maintain it or add new features as time passes. I have personally seen this attitude cause a company to go bankrupt after 10+ years in business because they never were able to see past the perceived "waste of time" in writing good code, and finally their system simply collapsed in on itself from hacks upon hacks upon hacks upon shoddy design. Aug 22, 2011 at 18:33

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