Ask HN: How long does it take for you to become productive in a new job?
By that I mean, understand the current system / requirements for new system in such a way that you effectively work alone, if you need.
And in general, how is the on boarding process? Do you normally have a mentor/guide to ask questions, or do you just learn by doing? Do you do pair coding in the first few weeks?
6 comments
[ 640 ms ] story [ 1640 ms ] threadI work in healthcare and before I was hired I was told it would take me about 6 months to become productive (understand the system, the jargon,..).
The first month I had a mentor that I did some pair programming with, in which I was mostly watching at first and then being the programmer. I also had courses on how to use the software and was taken to many meetings to get 'context' of what we worked on.
All in all I became productive around 4-5 months (developing new features without bothering colleagues too much and leading some own projects)
--
At a job before the current one I was not really guided at all, but they had written tutorials about how to work with their software. And in the tutorial you build a 'new' feature as you went along using more and more complex features of their framework.
No pair programming and actually felt more like a university course (as you kind of got graded via code reviews and had to retake a tutorial step if you failed).
I would actually recommend the first approach.
> If the product involves 50+ engineering team members, then 2-4 months takes you to onboard, and post that you learn new things and feel involved in day to day.
For starters:
1. What the nature of the work is.
2. What the culture of the company is, and if you have adequate help from other folks you work with.
3. How quickly you learn.
That makes it a challenging question to answer, as it seems like a moving target.
Learning the domain takes longer of course, but you don't need domain knowledge to fix bugs or put buttons on a page.
I've also found that it takes about 6 months to start understanding the system without hand holding from a manager or senior developer.
To get up to speed, I'd recommend starting with the smallest projects first: simple bug fixes, pair programming, and doing some support work. That will get you seeing how the software is used and which lines of code correspond to the different pieces of software. You can move on to bigger projects once you get your feet under you.
I wrote more about getting up to speed at a new job on my blog: https://www.climbuptheladder.com/how-to-succeed-in-a-new-job....