Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
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?
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.
