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.
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.
I'd say it depends on your work experience. When I had just graduated from university, it took a while for me to adapt to the work environment and be productive. After I changed my job, it didn't take long to become productive. Over time, I learned that using task management software can help me get more organized. I haven't tried a lot of tools but definitely check out Todoist, Wrike, and Quire.
I think it depends on how you are measuring right?
Coming off of a year leave it wasn't until a couple months in that I felt ready to be integrated into our sprints. However during those couple months I was reviewing code and team practices and providing value by asking questions about things and understanding how things work. The outsider-looking-in portion of on-boarding brings immense value to a team in terms of identifying blind spots or ways that weren't considered initially if the on-boarding is done thoughtfully and intentionally.
Controversial opinion; I think anyone can be "productive" on day one by finding and fixing holes in the setup documentation, the wiki, the install scripts.
Productive doesn't mean writing code. You're adding value by following setup steps and bringing them up to date, and new hires are the best placed people to update docs that don't make sense!
I'm a passionate learner and sharer. I always try to give back to the developer community. I create mobile and Web applications by day. Not Batman by night, in case you wondered :)
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
It's very dependent on the job, the company, and the individual.
At my current job for example it was only about 24-48 hours for me, but I also had been working on the same project as an open-source contributor for about 2 years prior to joining the company and we have a rather efficient on-boarding process.
In contrast, i've got friends who didn't get to the point of being truly productive until multiple months into their new job as a result of either a bad on-boarding process or them needing to learn a lot of new things for the job.
with a new framework I've never learned... at least 3 months. And that's multiple jobs I've been on now.
Six months and I'm finally getting certain tickets done on my own.
If I already know something, probably 2 months. I'm the totally average dev here
--For developers --
If we're going to work on the existing project it's totally based on the previous developer's code if he has coded will it would be easy . I believe the toughest thing in a developer's life is to understand one's code and debug it . I always expect the new project to start with in a new company helps me to show my productivity !!
It depends on the job. In my previous one I was productive after a week ...in my current one it took nearly 3 months, but that is because you need to have an understanding of telco, which not everyone has knowledge of.
Java Web Developer with a passion for Spring and cloud computing. Know a thing or two about AWS. Trying to learn NodeJS lately with the help of TypeScript.
It depends on the job and the company. If the company has a product with a big architecture, for example, you will not get really productive before you learn minimally how things get together. There is a period of some weeks or even months to get the hang of it, sometimes. You may know a lot about the tools, languages and technology in general that the company uses, but you have to learn how they use them and they way things work, basically. So, no matter your level, I think there is a time before becoming productive for anybody.
I am a professional DevOps Engineer with a demonstrated history of working in the internet industry. I am an avid Linux lover and supporter of the open-source movement philosophy.
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
Seems to take about 6 months to start having enough institutional knowledge to make meaningful headway (or, at least, as much headway as a given org's peculiarities will allow for).
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 blamewhen 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.
I'd say it depends on your work experience. When I had just graduated from university, it took a while for me to adapt to the work environment and be productive. After I changed my job, it didn't take long to become productive. Over time, I learned that using task management software can help me get more organized. I haven't tried a lot of tools but definitely check out Todoist, Wrike, and Quire.
I think it depends on how you are measuring right?
Coming off of a year leave it wasn't until a couple months in that I felt ready to be integrated into our sprints. However during those couple months I was reviewing code and team practices and providing value by asking questions about things and understanding how things work. The outsider-looking-in portion of on-boarding brings immense value to a team in terms of identifying blind spots or ways that weren't considered initially if the on-boarding is done thoughtfully and intentionally.
Controversial opinion; I think anyone can be "productive" on day one by finding and fixing holes in the setup documentation, the wiki, the install scripts.
Productive doesn't mean writing code. You're adding value by following setup steps and bringing them up to date, and new hires are the best placed people to update docs that don't make sense!
This one is tricky because it depends on a few things.
But I'd say if you are not being productive after two weeks (depending on the role) then there is a problem somewhere that needs addressing.
It's very dependent on the job, the company, and the individual.
At my current job for example it was only about 24-48 hours for me, but I also had been working on the same project as an open-source contributor for about 2 years prior to joining the company and we have a rather efficient on-boarding process.
In contrast, i've got friends who didn't get to the point of being truly productive until multiple months into their new job as a result of either a bad on-boarding process or them needing to learn a lot of new things for the job.
with a new framework I've never learned... at least 3 months. And that's multiple jobs I've been on now.
Six months and I'm finally getting certain tickets done on my own.
If I already know something, probably 2 months. I'm the totally average dev here
--For developers --
If we're going to work on the existing project it's totally based on the previous developer's code if he has coded will it would be easy . I believe the toughest thing in a developer's life is to understand one's code and debug it . I always expect the new project to start with in a new company helps me to show my productivity !!
For my first dev job, it took me about 2-3 months to feel like I was contributing substantially.
My second (and current) dev job? I think about 2-3 weeks π
(my teammates may disagree though, which I welcome of course π)
It depends on the job. In my previous one I was productive after a week ...in my current one it took nearly 3 months, but that is because you need to have an understanding of telco, which not everyone has knowledge of.
It depends on the job and the company. If the company has a product with a big architecture, for example, you will not get really productive before you learn minimally how things get together. There is a period of some weeks or even months to get the hang of it, sometimes. You may know a lot about the tools, languages and technology in general that the company uses, but you have to learn how they use them and they way things work, basically. So, no matter your level, I think there is a time before becoming productive for anybody.
Impossible to generally answer. It depends on the scope of the task and the product. For some it is a few weeks. Others a few months
Too many variables
Going to start a new Ruby developer position in a couple of days. Will come back when I have more data π
I try to be productive on day one. I do this by asking constructive questions of my team mates as I learn from them.
Depends how good your co-workers are, and do they really want you in the team π.
Depends on if there's a codebase to weed through or not
I committed a fix in my first week on the job. Small, well defined problems made it possible.
Usually takes a Month to get up to speed.
I think that 3 to 6 months depending on the project and the company.
Seems to take about 6 months to start having enough institutional knowledge to make meaningful headway (or, at least, as much headway as a given org's peculiarities will allow for).
I would think full productivity would take about a month. BUTTTTT this is all so dependent on maturity of the new code base and how large it is.