I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
Most recent customer sent me a laptop to VPN in with. It arrived in the post, I unloaded it and fired it up and I'm like "where's my login information? This thing's bound to your domain and my credentials aren't cached on it".
Had to send it back so they could put it on the network so I could Citrix into it to get my credentials cached. Once that was done, they had to post it back to me.
Did the unbox-and-login dance and discovered, "this has no software on it, I have no access to repositories and, even if I did, I don't have sufficient privs to install any". Called support desk and was told "you'll need to request the software you want and we'll remotely install it". They send me a link to the request system: had to make 15 discrete requests to get each of the packages installed that I sorta just assumed would have been pre-installed to it. Oh... And "remote install" was "guy sends an email, asking for contact info, arranges a time to temp-delegate admin privileges so he can RDP to the laptop over the VPN and install the software via desktop-sharing". Bonus, because each software was its own ticket, did remote install dance 15 different times (more if you count the "uh... what you installed doesn't actually work: fixitplz".
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
I should probably note that my primary duties are helping customers automate. So, when I hop on a project, there's either no automation in place or the automation that's in place needs a crap-ton of work. So, a big part of that six months is solving the various bootstrap-problems endemic to their organizations.
Python programmer, Django developer and SQL slayer. I have been programming for over 10 years; each one of those years has included a bug or 2.
Engineering manager and SRE for Envelop Risk
Python programmer, Django developer and SQL slayer. I have been programming for over 10 years; each one of those years has included a bug or 2.
Engineering manager and SRE for Envelop Risk
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
I completely agree - one of the reasons I've been writing articles like this and this on DEV is that at Alcumus we need some core (and perhaps less usual) principles to be understood before looking at the real code. I felt I might as well document those things as principles and then share them more widely.
Been using UNIX since the late 80s; Linux since the mid-90s; virtualization since the early 2000s and spent the past few years working in the cloud space.
Location
Alexandria, VA, USA
Education
B.S. Psychology from Pennsylvania State University
If we look from the experienced professional(6+ years of Exp) point of view, it doesn't take more then 1 month to be productive and start contributing.
But there are other factors as well, the individual will not be very comfortable with the processes and practices as well as the design of the system. I believe it takes almost 6 months to comfortable and start adopting to new environment.
I'd say 2-6 weeks before they're "positive" contributors (i.e. they are contributing more than they take in getting help from others)
But probably 2-6 months before they're at "full speed" (as much of a contributor as they are going to be; excluding personal growth which can make this hard and useless to measure)
I've been in the new position for six months. The first three included Thanksgiving, Christmas, New Years', and the associated away-time, it was all remote, and I really felt alone.
The current plague forced the issue of creating a home hacking shrine and made some changes with the organization as a whole, so I can say it was 4-5 months before I felt productive here.
I think I felt it earlier in my past jobs but I honestly don't remember.
It depends, another perspective is with a terrible client.
I met a client that likes to slot in extra tasks in the middle of a sprint, the productivity definitely affected from time to time. One of the funny examples is he blamed me for a malfunction feature on the brownfield project without any evidence and expected the guilty will bring more productivity. Obviously he didn't know that previously I have taught my superior how to use git blame when a colleague blames on me.
My first job was a result of me contributing to the company's OSS projects for about a year, so I was already productive.
I had a very brief stint at a startup where I spent little over a week and got nothing done, because I could never get comfortable with the codebase.
At my current job at Navana Tech, I inherited a working-but-also-broken codebase from someone who was no longer an employee, and hadn't done a particularly good job at making it easy to onboard new people. This cost me 4 days of picking apart things to get a sense of what I am building and how to go about it. Been breezy ever since!
I think it takes about 2 to 3 months. getting to know the code just like getting to know the people that you work with can take time. Especially if nobody explains anything to you. Or too busy to take time out to spend it with you.
Hi i'm an avid web and app developer in search for creativity and always going after new ideas.
Developer of Atomics Digital, Invoice Me and Reactor JS
For me I've been a freelancer for the majority of my web dev career, but the one time i worked for a firm, it took about 1 week to become productive and get a feel of what the company needs and its goals.
I feel like you can only become productive once you understand their needs and goals, otherwise you're working aimlessly.
I think this depends on a lot of factors. For a developer, these are a few factors I can think of:
The complexity of the product/codebase
Documentation/tests that are available
Mentorship availability
Maturity of tooling that have been set up
Personal experience level with coding generally
The third point is quite important for products that are quite complex, and can really slow you down if you have to figure out most of the context yourself as opposed to being given guidance on where to start etc.
I find good tooling can help eliminate a lot of mistakes and give you more mental capacity to focus on learning about the codebase, rather than having to worry about potentially shipping code with your changes that might break things.
To answer the main question, from personal experience, I'd say somewhere between a month to six months π
When I started, I made my first contribution to production within a week. My manager liked that so much that he tasked my team and me to steamline the onboarding process so every new team member could be productive within a week.
It depends on what it is but I would say first 3 months are cluster f... so somewhere between 6-9 months is usually onboarding part where people get comfy with the infrastructure, coworkers and the whole vibe at work.
Top comments (51)
It depends on when you receive your laptop!
Can't tell if you're joking, but it took me a month to get my laptop when I worked at McAfee. Air coding lol.
Took me nearly a week at my first job! π€·
Current job is the only place I've had a brand new machine... I love it π
Or when you get your local environment finally set up
Cannot agree more.
Most recent customer sent me a laptop to VPN in with. It arrived in the post, I unloaded it and fired it up and I'm like "where's my login information? This thing's bound to your domain and my credentials aren't cached on it".
Had to send it back so they could put it on the network so I could Citrix into it to get my credentials cached. Once that was done, they had to post it back to me.
Did the unbox-and-login dance and discovered, "this has no software on it, I have no access to repositories and, even if I did, I don't have sufficient privs to install any". Called support desk and was told "you'll need to request the software you want and we'll remotely install it". They send me a link to the request system: had to make 15 discrete requests to get each of the packages installed that I sorta just assumed would have been pre-installed to it. Oh... And "remote install" was "guy sends an email, asking for contact info, arranges a time to temp-delegate admin privileges so he can RDP to the laptop over the VPN and install the software via desktop-sharing". Bonus, because each software was its own ticket, did remote install dance 15 different times (more if you count the "uh... what you installed doesn't actually work: fixitplz".
I should probably note that my primary duties are helping customers automate. So, when I hop on a project, there's either no automation in place or the automation that's in place needs a crap-ton of work. So, a big part of that six months is solving the various bootstrap-problems endemic to their organizations.
This sounds like hell
In my second job I actually got fed up of waiting, went to the local pcworld and bought one, expensing it.
Lol, did you get reimbursed?
Yeah, I expensed the machine back to the company. They didn't mind doing that, they didn't have a "proper" IT function.
lol.... due to covid situation most of company failed to deliver kind of premises.
Onboarding documentation can make a huge difference. I had a discussion post about this back in 2018. Lots of good answers in there.
What is your on-boarding process at your company?
Nick Taylor (he/him) γ» Apr 22 '18 γ» 1 min read
I completely agree - one of the reasons I've been writing articles like this and this on DEV is that at Alcumus we need some core (and perhaps less usual) principles to be understood before looking at the real code. I felt I might as well document those things as principles and then share them more widely.
What is this "documentation" you speak of?
If the product is simple and the company is an early-stage startup, a week or two, maybe a month depending on your experience.
If the product is complex in an industry you know little about, you're going to take several months to ramp up no matter your experience level.
I'd typically say about a month. They need time to settle in, get used to the working processes, get used to the systems in place, etc.
(Unless you're like me and thrown in the deep end day 1 - haha).
If we look from the experienced professional(6+ years of Exp) point of view, it doesn't take more then 1 month to be productive and start contributing.
But there are other factors as well, the individual will not be very comfortable with the processes and practices as well as the design of the system. I believe it takes almost 6 months to comfortable and start adopting to new environment.
you know, it's depends on many factors. like your responsibility, workloads, position etc etc.
I'd say 2-6 weeks before they're "positive" contributors (i.e. they are contributing more than they take in getting help from others)
But probably 2-6 months before they're at "full speed" (as much of a contributor as they are going to be; excluding personal growth which can make this hard and useless to measure)
I've been in the new position for six months. The first three included Thanksgiving, Christmas, New Years', and the associated away-time, it was all remote, and I really felt alone.
The current plague forced the issue of creating a home hacking shrine and made some changes with the organization as a whole, so I can say it was 4-5 months before I felt productive here.
I think I felt it earlier in my past jobs but I honestly don't remember.
It depends, another perspective is with a terrible client.
I met a client that likes to slot in extra tasks in the middle of a sprint, the productivity definitely affected from time to time. One of the funny examples is he blamed me for a malfunction feature on the brownfield project without any evidence and expected the guilty will bring more productivity. Obviously he didn't know that previously I have taught my superior how to use
git blame
when a colleague blames on me.I've found it to vary greatly.
My first job was a result of me contributing to the company's OSS projects for about a year, so I was already productive.
I had a very brief stint at a startup where I spent little over a week and got nothing done, because I could never get comfortable with the codebase.
At my current job at Navana Tech, I inherited a working-but-also-broken codebase from someone who was no longer an employee, and hadn't done a particularly good job at making it easy to onboard new people. This cost me 4 days of picking apart things to get a sense of what I am building and how to go about it. Been breezy ever since!
I think it takes about 2 to 3 months. getting to know the code just like getting to know the people that you work with can take time. Especially if nobody explains anything to you. Or too busy to take time out to spend it with you.
For me I've been a freelancer for the majority of my web dev career, but the one time i worked for a firm, it took about 1 week to become productive and get a feel of what the company needs and its goals.
I feel like you can only become productive once you understand their needs and goals, otherwise you're working aimlessly.
I think this depends on a lot of factors. For a developer, these are a few factors I can think of:
The third point is quite important for products that are quite complex, and can really slow you down if you have to figure out most of the context yourself as opposed to being given guidance on where to start etc.
I find good tooling can help eliminate a lot of mistakes and give you more mental capacity to focus on learning about the codebase, rather than having to worry about potentially shipping code with your changes that might break things.
To answer the main question, from personal experience, I'd say somewhere between a month to six months π
When I started, I made my first contribution to production within a week. My manager liked that so much that he tasked my team and me to steamline the onboarding process so every new team member could be productive within a week.
It depends on what it is but I would say first 3 months are cluster f... so somewhere between 6-9 months is usually onboarding part where people get comfy with the infrastructure, coworkers and the whole vibe at work.