I graduated from school for computer science. In school, I would code, and it was horrible. Then I would rewrite my code, and it was better, but still not great. Then I would rewrite it a third time, and it would be acceptable.

I now have a job as a software developer, where time is money. Is it better to pump out some low quality (yet fully functional) code quickly? Or to follow my academic strategy, and to take 3 times as long, but finish with work of a higher quality?

  • First thing first, I think you might want to have a small discussion with your boss. If that fixes his expectation, then it's all good. If that doesn't work out (there are many reasons, e.g. boss is non-technical and doesn't want to change his expectation, no funding to pay your salary, ...), you don't have much option. You can only make the code the highest quality possible within the time frame given. You can take it as a challenge to improve your coding speed while maintaining a good style.
    – nhahtdh
    Commented Jan 23, 2015 at 3:05
  • Get a time estimate from your boss as to how long your project should take. The time available will determine the option that you can take. Your coding strategy is extremely inefficient, by the way - Tou definitely need to overhaul it. Commented Jan 23, 2015 at 4:15
  • 1
    This depends on the person. I have had clients that want things fast and don’t care about the consequences. I have others that want quality. In general you should focus on quality and if somehow your boss/client is resistant, then maybe it’s time to consider a career move? Commented Jan 23, 2015 at 4:21
  • Quality can mean a lot of things. "Functionally correct" is essential. "High performance" is important but only measurable in the context of the application around it. Then there's "Well documented", "easy to read", "easy to extend", and "gets to market on time". You need to determine the relative merits of each, and every project will have a different balance. And practice, practice, practice until some of these start to come instinctively - there is no other way. Commented Jan 23, 2015 at 13:11
  • In school, your goal was strictly to learn. At work, there are other concerns at play and it is up to you how to balance all those concerns. It might be a good idea to simply ask your boss, but I am afraid that in many cases the boss may NOT be capable of providing usable guidance. You have to use your judgement and gauge yourself against what others are doing and the demands of the environment.
    – teego1967
    Commented Jan 23, 2015 at 17:32

3 Answers 3


The normal path at a good development place is: You write the code, it gets reviewed, you fix problems that turn up during the review, the code gets tested, bugs are found, bugs are fixed. If reviews are not done, you should at least make sure that the code would pass a review if it was done.

When you initially are given a task, you don't know yet what's the best way to handle it. After you wrote the code, you know how it should be done (but your code might not be done that way, because it is a learning process). At that stage, changing things to do everything in the best possible way should be something that can be done very quickly. And the time spent will be more than recovered when you have to fix fewer bugs later.

Obviously discuss this with your manager. And if you estimate that some task will take you two weeks, that mustn't mean "two weeks to write a bad version and 3 days to turn it into acceptable quality", it should be "1 1/2 weeks to write a bad version and 2 1/2 days to turn it into acceptable quality".

BTW. It might be a good idea to think about how to solve a task, write it down, and go to an experienced developer to take five minutes to look at your plan and tell you if it is any good. These five minutes can save you an enormous amount of unneccessary work if your initial plan was no good.


You can not generalize this because it depends on the needs of the business.

Sometimes it can be more important to get a product to market fast then getting a product to market good.

In the long run, putting in a bit more work and creating a clean, solid, flexible and well-documented base for a product can save work when you later need to do maintainance and feature additions to it.

On the other hand, getting a working product quick can sometimes be of utmost importance, for example when you need to solve an urgent problem, beat a competitor to bring your product to market first, in the (rare) situation that it is a one-time job for a program which will never be used again or when you are just understaffed and swamped and need to get things off the table.

We can not tell you in which situation you are. Ask your manager if she would prefer you to create a sustainable product even when it takes longer or aim for maximum productivity and churn out programs which just get the job done. It's the managers job to set your priorities.


My general advice is to focus on quality when starting. Code is generally used longer than expected. Bug fixing can be more costly in time and resources than writing the original code, particularly if done by someone different to the author. As you write better quality code, your speed will improve.

A quality focus forces you to think critically about your code. If you are open to improvement, your code quality will improve and this could include ways of doing it better and faster. Trying to get code written as fast as possible may have the opposite effect.

That said, I would time box tasks. For example, give yourself a day for small a task and go with whatever you have at the end of the day. People will accept a beginner or junior developer taking a bit longer but they will not accept you taking a week. Talk to other developers, particularly your peers and team mates, to work out how long is acceptable for each task.

The quality versus speed focus may shift from task to task. For example, prototypes will generally be "build it as fast as you can" compared to long lived production code, which will generally by "build as good quality as you can". You may be given a simple but critical bug that needs to be fixed ASAP. Be aware of the requirements and context. If you find that difficult now, do not worry. It will come over time.

As for your boss expecting code to be produced quickly, of course your boss is going to want code written faster - time is money with software development. However, it ultimately costs more to write lots of poor quality code that contains bugs, is slow or hard to maintain. Non-technical managers may have difficulty explaining that.

Also remember that software development is a team exercise, not an individual one like you had in academia. Have a go yourself but discuss your solution with other developers. Read other developer's code to and understand why they made the decisions they did. You will produce better quality code and produce it faster this way.

  • I totally agree, quality. Creating quality does initially have have a steep time curve but eventually the gap between quality and time will narrow quite a bit. It is one of the things that differentiates that 10 years of experience person from the person with 1 year of experience 10 times. When I have a new grad on my team, I have them focus on learning to do things right. It usually means that I get little productivity out of them on my current project, but I more than make up for that on future projects when they know what "good enough" means and can do so with confidence and speed.
    – Dunk
    Commented Jan 23, 2015 at 21:35

Not the answer you're looking for? Browse other questions tagged .