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.
I'm currently working as a contractor for a massive corporation. Although as a contractor you're expected to be fully up and running within days, it still took me a good 3 weeks to get confortable with the project I was assigned on.
Since the codebase was quite old, too many decisions were undocumented or even forgotten; the people who took them having left the company or not remembering why they took them anymore.
Even now, after about 4 months, I still can't feel fully confortable with our project because there's too many forgotten decisions.
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
In my first job as a Junior Dev it took me almost a year because we had 3 different very large products and they had an extremely niche user base so I had to become familiar with those processes. As others have said if you can understand the user experience it makes it a lot simpler to understand the code. Since becoming a consultant I've had a wide range of experiences. Some times it takes as little as a few days to understand the code, sometimes you never do because the guy who wrote it is gone and there's no documentation and the users can't explain how they use it.