27

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?

gnat
  • 21,442
  • 29
  • 112
  • 288
iAteABug_And_iLiked_it
  • 545
  • 2
  • 5
  • 13
  • 5
    Code complexity and experience matter. Up to a year. – Rig Sep 02 '13 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! – James McLeod Sep 03 '13 at 01: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. – Robert Harvey Sep 03 '13 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. – GrandmasterB Sep 03 '13 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 :) – iAteABug_And_iLiked_it Sep 03 '13 at 21:36
  • 2 years later after asking this question, I've now been contracting at £400/day for 5 months working on a project which actually IS big ( 8x bigger than this one I mentioned)- and I can confirm it took me "three" days to be productive ,i.e. to pick items off the task board and do them) I wish I could go back in time and tell myself this before asking this question ! – iAteABug_And_iLiked_it Jan 24 '16 at 21:57
  • The formula is: `your skill level * codebase quality * complexity of the change`. Measured in units of "the question is locked, I cannot elaborate". – Vorac Sep 04 '20 at 01:03

4 Answers4

26

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.

TheDevOpsGuru
  • 809
  • 2
  • 8
  • 12
  • 1
    You provided no concrete answers. May I suggest an edit? – tjons Sep 02 '13 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! – TheDevOpsGuru Sep 03 '13 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 Sep 03 '13 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 Sep 03 '13 at 13:10
  • @Jubbat I have added this to my 3rd point. Thanks for the suggestion. As for your second comment, I hope that I can still venture to say that this really is a subjective topic that would require a more scientfic answer, but one real-world experience doesn't fit the answer for this question. – TheDevOpsGuru Sep 03 '13 at 16:08
  • 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 Sep 03 '13 at 16:08
  • @AndHeCodedIt thanks, but I don't quite agree that this question is totally subjective. A "general" idea is what I actually said in the post. Anyone who has seen a few developers in the hiring process can come up with a ballpark figure. – iAteABug_And_iLiked_it Sep 03 '13 at 21:34
  • I still stand by my answer. Giving a "ballpark" estimate is subjective IMHO. – TheDevOpsGuru Sep 04 '13 at 11:31
22

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.

Stephen
  • 8,800
  • 3
  • 30
  • 43
  • +1 What about the business knowledge / domain knowledge? How did you know what changes were needed in the code? – MarkJ Sep 03 '13 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 Sep 03 '13 at 23:37
19

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!

tjons
  • 422
  • 3
  • 14
  • 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 – iAteABug_And_iLiked_it Sep 02 '13 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 Sep 02 '13 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 – TheDevOpsGuru Sep 02 '13 at 21:55
  • 3
    Some bugs take days and even weeks to fix even when you already know the codebase! – whatsisname Sep 03 '13 at 02: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 Sep 04 '13 at 21:40
3

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.

Vladimir Kocjancic
  • 179
  • 5
  • 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 – iAteABug_And_iLiked_it Sep 02 '13 at 21:42
  • 2
    Yes, you are... Slow and steady wins the race – tjons Sep 02 '13 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. – Vladimir Kocjancic Sep 02 '13 at 21:49
  • The only way to learn how to swim is to get in the water.... – David Cowden Sep 04 '13 at 21:31