Originally published on my personal blog.
I've always maintained that it takes around 3 months, minimum, to begin to feel like you're really acing it in a new job. I'm speaking from the point of view of a software engineer, but perhaps it also holds true for any kind of more complex knowledge work, especially work that requires acquiring domain knowledge and close collaborative teamwork to do well.
The figure of 3 months came from my own experiences, and from talking to many others. I admit, this figure is probably more biased towards people at the start of their careers, since I've worked with lots of people who've been getting their first, second or third jobs in tech and listened to their experiences. Maybe with more experience, in more leadership-style roles, you can expect to feel like you're doing your best work sooner. Maybe a consultant, brought in to help with a specific problem or help with their particular area of expertise, has a different experience. I'd really be interested to know.
But for me, the figure of 3 months based mainly on:
The need to learn the problem domain. Unless you jump from one place to a competitor, solving a similar problem in a similar space, there will be a whole load of domain knowledge you need to pick up. For example, when I worked in analytics, I needed to learn about how digital marketing worked. Now I build a product for charities, I'm learning about how the charity sector works.
Figuring out the team dynamics. Software engineering is so collaborative, you can't do your best job until you know how to best work with your team. You need to figure out who is good at what, who takes responsibility for various areas, how to get the best out of various people and just generally how to fit in. I've never joined a company where all this stuff is completely obvious, or documented in some workflow system - it always seems to require a mix of intuition, attention, experience to absorb.
Learning the codebase. Depending on the kind of work you need to do, the kind of tickets you get to work on, and the size of the project (or your area of it) this might be more or less challenging, but it's definitely still something that takes time. You can get a lot done in a codebase you don't fully understand but it won't be your best work. Even when you ask about things you don't understand, there will be a whole load of unknown unknowns, such as what trade-offs were made at certain times, the fact that there is a component tucked away in an obscure project which does exactly what you're about to build, the fact that the tech lead has a handy bash script saved to parse those logs if you need it. You only pick these things up with time.
Learning new tools or technologies. It's unlikely you'll jump from one place to another which uses the exact same tech stack in the exact same way, with the exact same tooling thrown in. So there's likely to be some ramp-up as you pick up these new things.
Feeling confident in new responsibilities. If you took a new role partly for career progression, then your responsibilities and job role might have changed, and then of course you might be partly learning on the fly how to do a whole new job!
I always found the figure of 3 months helpful, especially when talking to entry level developers, because I think it sets realistic expectations about how productive and useful you might feel at the beginning, and how much each role itself is different to other roles, and requires its own up-front learning before it can be done well.
I'm not saying that after 3 months, you should feel like you can do the job with your eyes closed. But by that point, I think people are often beginning to feel more confident that they are valuable to their employer, know what they are capable of, are more aware of the areas they are less experienced in and might need help with, and are able to work more effectively with their team.
I've changed jobs a few times during my career as as a software developer and only once did I feel like I could already do the job well on my first day. In retrospect, that was great for my employer and great for my self confidence, but not great for my personal/career growth.
On the other hand, I've moved into roles where I very acutely felt that sense of "omg they're gonna fire me before I even hit the 3 month mark", which was challenging for my self-confidence but amazingly I never got fired, and grew a tonne instead.
What you can do
I think on the whole, companies understand that there is a ramp-up period involved in on-boarding any employee, at any level of seniority. It would be expected that a more senior developer needs less support to get started, as they will have seen more patterns by which they can make sense of this particular project, and this particular way of doing things, worked with more different teams and hopefully be pretty good at picking up new tech. However, even so, all the above points still apply and you still won't be doing your best work immediately.
On the other hand, I hear from a lot of developers earlier in their careers (and I include myself in this, 4 years in!) who find starting new jobs challenging, and beat themselves up over all the things they don't know straight away. That's why I find the 3-month rule helpful. If you keep the 3-month rule in your head, try to defer judgement on whether you're doing a good job or not until you pass that threshold. Then look back and ask yourself:
- What did I learn in the last 3 months?
- Am I doing a better job now, than 3 months ago?
- What do I want to get better at over the next 3 months?
- What was something that was really challenging 3 months ago? How much better/faster could I do that task now?
- What tickets have I closed/features have I worked on/successes have I had so far?
You still might be feeling out of your depth, but hopefully reflecting on how far you have already come, and knowing that it's totally normal and expected to feel like this, can help.
And in another 3 months time, you can expect to ask yourself the same questions, and once again see that compared to 3 months ago, you've come leaps and bounds.
You should also remember that we're not paid to just come in and bash out code. We're paid to solve the business problem, and that involves asking questions, being inquisitive, and thinking. The period we spend learning about a new company/problem/product is part of the job. We're also paid to keep up to date in our industry and make sure we're using the tools/technologies that can best solve the business problem, so it's totally normal that we're paid to be learning.
What employers can do
Obviously employers have a lot to answer to here as well, in terms of developing a positive onboarding experience that helps new hires do the best work they can do, at that point in time, and supports them in their ramp-up period.
Larger companies might be able to provide specific training programmes for new employees, whereas smaller companies are more likely to implement pair programming as one of the principal methods of knowledge transfer.
But it's also important to make sure that the work given to team members is suitable for someone who is learning a new codebase. Sometimes this work isn't the most valuable work but the net overall effect of easing someone into a new codebase/project in a sensible way is still greater than dumping a complicated, important problem on them.
I'd love to hear examples around really positive onboarding experiences, as I'm lacking in anecdotal experience here 😂
Isn't this all a bit negative?
Sometimes I feel like this 3-month rule can come across as a bit negative. Shouldn't we all be preaching positivity and a can-do attitude? You won't be awesome until you believe it yourself, right?
But I think the alternative is more harmful, especially for people early in their careers or making career changes. There are enough reasons to second-guess yourself already, without unrealistic expectations about how quickly you can be doing your best work being thrown into the mix. If you're lucky and get a super supportive team who take great care to curate your work for you so that you're always pushed exactly the right amount, and make you feel valuable from day 1, then you're one of the lucky ones. You can carry on feeling unexpectedly competent and confident and no harm done.
But if you're like most people, working in an imperfect team in an imperfect world, you're likely to feel out of your depth at first, and if you're not prepared it can be a real challenge. You might think you're just not cut out for this work, or that you don't belong here, when actually you're just experiencing something totally normal.
I'd really love to hear other experiences around this - especially from people who've never had this feeling, or people at other points in their career on whether a similar timeframe still holds true, and how you navigate it.
Top comments (7)
It's a bit different to full time roles, but as a freelance/contract dev I've often had the problem of a slow start because the project onboarding was broken.
More than a couple of times the project install docs have been out of date and wrong, leading to delays debugging the setup just to get going. It's frustrating because both parties are uneasy about that unproductive time.
It's not always fun to keep that process up to date, but if you ever onboard new people to a project it's worth it.
I can imagine! What would you consider a "slow start"? How soon into a new contract do you feel like you're really doing the best work that you can? Do you tend to take on projects that stretch you well outside your skillset or are you often working in areas where you already have a lot of expertise?
I'd want to be pretty confident quickly. It does depend on the size of the code base and how long the engagement might be.
Normally people want to see some results quickly, so doing things well outside my skillset isn't normally viable in that situation.
I completely agree that you should allow yourself time to learn and absorb everything in your new job and not to stress too much.
Personally, I like to write down a few bullets each day as a record of what I was working on. It's nice to look back at my notes to see how much my work has changed and everything I've learned in a company.
I agree, that's a great idea. I try and do the same! Even when things are super overwhelming and you feel like you've got so much to learn, if you can manage to write down the things you did figure out today (even if it's something that feels really small, like "I now know why this particular package is used in the project") you'll feel a little bit better.
Spot on. You seem to have covered it all regarding changing jobs. For me personally, in my experience, I always keep an open mind to learn about the business problems to team dynamics, technologies used and code base health.
However, it is also vital to keep an eye on balancing between being exceptionally good at the job in a short period and challenging yourself to learning new things and apply it while on the job.
I think the 3 months rule is fair but for more experienced software engineers it might be shorter simply on the basis of expectations of employers/team members and experience he/she has garnered so far.
Thank you for this! I started my first developer job about a month ago and felt totally overwhelmed by everything.