I have just landed a role as a C#/Asp.Net developer at a large software house. I have previously worked at a much smaller software house for about two years but it was a varied/mixed role there, and here the asp.net applications we have are a factor of 10 or so larger.

As seems to be the norm, I have been given the task of fixing bugs. At the moment I am just trying to understand the system. How long , in your experience , does it "roughly" take ( and is generally acceptable) for a new developer to get up to speed? It of course varies from company to company but as a general rule, when you have hired someone/have worked with someone new, how many days/weeks would it have been normal for them to get to grips with the system?

  • 5
    Code complexity and experience matter. Up to a year.
    – Rig
    Commented Sep 2, 2013 at 23:41
  • 2
    Hah - I'm a little slow, but at my previous year, it took about 30 months, and one big mistake, to get up to speed, and about five years to feel I was competent. It really depends heavily on the complexity of the domain. Bottom line is - don't worry! Commented Sep 3, 2013 at 1:48
  • 2
    If a recruiter or hiring person has done their job, it should really take no more than six months to a year to get fully up to speed, unless the company has a specific goal of hiring inexperienced developers (to save money; it's a false economy, but that's a topic for another discussion) and giving them all the time they need to learn the ropes. Commented Sep 3, 2013 at 16:21
  • 1
    What does 'up to speed' mean? Is it just 'able to fix routine bugs', or 'complete understanding of the domain'? If the latter, you might be talking quite a few years depending on the project. Commented Sep 3, 2013 at 18:59
  • @GrandmasterB , yes being able to fix routine bugs is fine . that'd be up to speed, as you are being productive to some level :) Commented Sep 3, 2013 at 21:36

4 Answers 4


It depends. But IMHO, it should take about a month to know your way around, and up to six months to be normally productive.

An interesting exercise, if you have time, etc: Take a part of the application, and reprogram it in another language, if you know any. Or, try reading all of the source code that you can, and write down what it does. That should help you get up to speed!

  • up to six months? I have been studying the system and i was beating myself for having spent a whole day and not fixed a single bug from the bug tracking system Commented Sep 2, 2013 at 21:43
  • 1
    Yep. To become completely familiar with it, like you wrote it yourself, should be at least 6 months. But a few weeks to be pretty comfortable fixing bugs.
    – tjons
    Commented Sep 2, 2013 at 21:47
  • 3
    As I said to the first answer: This answer tries to box the question into an objective nature, IMO this is not an objective problem to solve or answer Commented Sep 2, 2013 at 21:55
  • 3
    Some bugs take days and even weeks to fix even when you already know the codebase! Commented Sep 3, 2013 at 2:52
  • I work largely in agile environments where pairing is the norm and you can be productive on day one! We had a new dev start yesterday and they are already productive with the both their insights and the their code. In fact the they would have been more productive if they hadn't had to go through all the usual induction/meet n greet that one has to do on first days:)
    – Chris Lee
    Commented Sep 4, 2013 at 21:40

The answer to this question is completely subjective. The length of time it takes a developer to come up to speed can depend on:

  1. the developer's level of knowledge and professional experience
  2. the level of complexity of the application(s) or the level of documentation for the same
  3. the ability of current application "experts" to onboard new developers. By "experts" I mean application experts or those that have domain knowledge that would help a new developer become more familiar with the application.
  4. your software methodology (yes I said it). My take is that new developers in an Agile environment will get up to speed faster or fail faster.

I don't choose to give a time because I hope that I have given enough proof that this is too subjective to offer an exact answer on how long it will take someone to come up to speed.

  • 1
    You provided no concrete answers. May I suggest an edit?
    – tjons
    Commented Sep 2, 2013 at 22:33
  • 5
    No edit is needed. I provided suggestions for the questioner to make his or her best guess since this is a SUBJECTIVE topic! Commented Sep 3, 2013 at 10:23
  • 1
    I'd add "domain knowledge" to that. If documentation is scarce, a good knowledge of the industry/domain can help to ask the right questions and make the right guesses.
    – DPM
    Commented Sep 3, 2013 at 13:02
  • 2
    Strictly speaking it is not subjective. Only difficult to answer in a "scientific" way ie. plotting some measure of coding effectiveness against different variables. This is not a bad answer but I can see the value of presenting a real experience too to give op a rough idea.
    – DPM
    Commented Sep 3, 2013 at 13:10
  • 2
    I agree with @AndHeCodedIt. Any attempt to provide a concrete answer to a question like this will invariably be wrong. The only possible concrete answer would be a range, and depending on all of the variables involved, it would probably be anywhere from 'a couple of hours' to 'a year or more'.
    – Eric King
    Commented Sep 3, 2013 at 16:08

At my current job I am the sole developer and when I started nobody had any knowledge of the code. I was given a codebase with 200k lines of code and told to implement new functionality against this codebase from day 1. It probably took a week before I was writing useful code and three months before I understood the codebase well enough to track down most bugs on the spot and give confident technical answers when questions were asked.

That being said, I came to the job with 8+ years experience in coding .NET applications, so I know the basics of C# really well (so I am fairly fast at brain compiling code). The time that it should take to hit peak coding efficiency in a new job is mostly a function of language experience, the size of the codebase, the available knowledge within the company, how well coded the product is and time.

  • +1 What about the business knowledge / domain knowledge? How did you know what changes were needed in the code?
    – MarkJ
    Commented Sep 3, 2013 at 20:30
  • 1
    Good question about domain knowledge. As with everything else, "it depends". In this job I had access to people with good domain knowledge to answer my questions. For most domains, I've found you don't actually need a whole lot of domain knowledge to be productive (I've worked in POS, electricity, mining and radiation modelling) if you have people who can answer your questions. I've found that domain learning is best treated as an agile experience - learning just what you need as you need it seems to work best.
    – Stephen
    Commented Sep 3, 2013 at 23:37

Depends. At my first job, all I got was two weeks and then I was thrown into the pool. I swam. I am not proud of my code back then, and I sure wish that someone would either give me more time or took some time to actually help me swim. But, as years went by, I apparently only got better and better.

Just to be clear, I do not condone dropping in the pool policy.

  • 1
    i spent atleast day looking at the source code for a visual studio solution with about 24 projects, and i was expecting myself to be able to start fixing things right away...maybe i am asking too much of myself Commented Sep 2, 2013 at 21:42
  • 2
    Yes, you are... Slow and steady wins the race
    – tjons
    Commented Sep 2, 2013 at 21:48
  • 2
    What TJonS said... My advice would be to start looking at the code and just ask loads of questions. Otherwise, you will lose a lot of details about how this project is structured and why. Commented Sep 2, 2013 at 21:49
  • The only way to learn how to swim is to get in the water.... Commented Sep 4, 2013 at 21:31

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