First questions is your personal experience, how long did you feel it took you before you are ramped up. (Since for most of us, we join a company with often large existing code base, of course, some product, the code base is simple, but some can be highly complex.)
Also what are your expectations for when you hire software developers/engineers? How quickly do you expect them to be ramped up? For junior vs senior developers.
Top comments (19)
Ah man, I remember I started this job as a .Net/C# Developer after being a Java Developer for close to 5 years. I specifically told them in the interview that I only had basic knowledge of .Net but I was willing to learn. Little that I knew, I was the only .Net resource on site to support this project (they purchased a product from a company located in another state with no support).
It felt like the lowest point in my career because it took me so long to get up to speed on how to contribute efficiently. I had to quickly learn Visual Studio/C#, SSRS, SSIS, TSQL, IIS practically all at once. The hardest thing that took long for me to grasp was lamba expressions, since Java didnt have this at the time.
But after a year of working there, I was finally comfortable and making consistent contributions, I learned a hell of a lot and it has helped me succeed in my role today.
100% agree with Nick!
I would also say about 3 months. Within that time I am able to get comfortable enough with the code base that I can select tickets on my own to work on and am able to grasp their scope quickly. That is also the point where I am comfortable enough with the workflow that I don't have to think about it, it just comes naturally as I complete work.
PS what year were you at MIT?! I'm 2010 😊
I've had different experiences, ranging from a couple of weeks to a couple of months. Here's what I've noticed makes a big difference:
#1 by far is having an onboarding process. Companies that had a strategy and a method for onboarding employees get people working productively 2-3x times faster.
The other factor I've seen is amount and complexity of domain knowledge. I don't need that much documentation on your code base, I need it on the domain knowledge. I can wrap my head around React components and Ruby POROs, what I struggle with is the jargon and intricacies of your particular industry. Who knew that college housing departments could be so complicated?
Another factor that I've noticed has an effect is my personal familiarity with the tech stack. The more experience I have with the tools and frameworks, the quicker I can hit the ground running. This one is also the easiest to overcome in my experience. The company may have undocumented internal knowledge I can only learn via talking to coworkers, but React tutorials are a dime a dozen.
Lastly, I would say is the complexity of the application. Even in a complex application, you can usually focus on one small part, or find parts that are siloed away and easier to grasp.
The big takeaway I have after thinking about it is that the codebase is the least important factor when it comes to getting acclimated in a new environment. The process of how internal domain knowledge is transferred is much more important.
2 months in at my new place, I'd say I'm now only starting to feel comfortable navigating the project on my own, It is quite large and complex. I bolded starting because I still have a long way to go.
That depends on the size and complexity of the code base. I've been places where 3-6 months was all it took and I've been places where 1 year wasn't enough. One suggestion I have is to learn the product as a user. It gives you the ability to see where the problems are.
I agree! Especially, if you are stepping into a role where the core software branches out and uses different technologies for integrated pieces. I don't think there is a one-size-fits-all answer. Every code base is different.
I've been at places where I was able to start contributing right away, while others I contributed after a few months and other places where I didn't feel like I made hardcore contributions until about 9 months in. Like you said Michael, getting familiar with the product is an essential piece in understanding the code base.
I think it depends entirely on what you're stepping into on a job.
We have a huge custom product at work that was started 20+ years ago (classic asp) with on going development and I still don't feel very productive doing any coding on it even after 10 years. It's not that I don't know the language, it's just too complicated and too big of a product. We primarily let one guy do most of it because no one can learn it.. and now that it's being sunsetted we rejoice!
On the other hand I turned out my first soup to nuts product in about 2 months when I started. In retrospect it's a total piece of junk since it was dev'd in a "trial by fire" setting in a language I had to learn on the fly, but it's still in use these 10 years later.
agree with Nick，3 months is needed, I think the most challenge is the workflow. Transform from another comfortable is hard than imagination. The next is codr project or unfamiliar languagr or framework. the last is teamwork, to be believed by your teammate is a challenge.
My last job, as a lead dev, it took me just about 6 weeks, working mostly on my own, before I was comfortable checking in code. About 6 months before everything was well ingrained.
I just started a new job last week. This company has a strong onboarding process, and is 100% behind pairing. It’s a complicated code base and domain, though, and is a full stack role (vs previous backend roles). I imagine it will take the better part of 3 months or more before I’m picking tickets on my own and leading a pair.
I reckon there was no point at where I suddenly felt productive, more so that there was a point where I was absolutely aware, retrospectively, that I actually was contributing.
I reckon, if I had to put a timescale to that, I was probably contributing after a couple weeks, but only contributing with great benefit after 3-4 months or so?
Interestingly, this is only based off my experience with my first software role. I'm about to start my second, so it'll be interesting to see how quickly I feel I get settled in and contributing.
It depends as much on the place you are going as on you
The last place I worked their systems were a tangled complex mess and we figured it would take about 3 months before a perm member of staff could confidently deal with everyday problems
However, we used to occasionally hire contractors. They can't be training for 3 months. So we'd try and scope things so that they could be immediately productive: and on the whole this worked
Speaking more generally, in the ideal world new hires could be inducted in such a way that their early jobs are an education for the ways that a business does things