Editor guide

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.


lol.... due to covid situation most of company failed to deliver kind of premises.


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.


Onboarding documentation can make a huge difference. I had a discussion post about this back in 2018. Lots of good answers in there.


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.


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)


you know, it's depends on many factors. like your responsibility, workloads, position etc etc.


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 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.


This one is tricky because it depends on a few things.

  1. Can existing team members able to answer your questions
  2. Are there any SME still around to use as a reference
  3. How good is the company onboarding
  4. Has the company provided everything you need to get up and running

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.


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 !!


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!


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.


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.


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.


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.


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 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.


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.


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 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 πŸ˜…


I think you can start adding value as soon as you get your machine setup. Being really productive could take a lot longer depending on the size of the code base and your understanding of the existing stack and frameworks used.


IMO it's not a switch that gets flipped and suddenly you're productive. It's more like you slowly get more accustomed to a codebase (assuming it's not all greenfield), and it's highly dependent on the complexity of the system. In my experience, boring business automation: 3~ months; Quantum computer control system: no. Jokes aside, it took about 6 months for me to feel comfortable with the super complex, extremely specialized system that I've been working on.


Too many variables


Going to start a new Ruby developer position in a couple of days. Will come back when I have more data 😁


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


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.