First 90 Days - Software Engineer Version
Aditya Ankur, asked me:
I know that there is a book for the first 90 days as an executive. Is there something similar for programmers?
I don’t quite know of a book/essay which covers this yet sticks to the question. So I am writing one for him.
The First 90 Days for a New Engineer
I expect each step to take roughly between 10 and 30 days, depending on the pace of your project + size of the team. Do them in order i.e. 1 before 2, and 2 before 3.
1. Study the Ecosystem
Get a very nuanced understanding of what the team considers as high quality in that context. Sometimes it’s scale, sometimes it’s speed or something else altogether. There are usually at most 1-2 things which every engineering team does to their best.
Get seen by your senior engineering teammates. Not only your manager.
Get super comfy with all docs, codebases, APIs and people who work on those projects.
For every repo/codebase that you study: Add comments, docstrings, setup instructions, make small improvements e.g. unit tests.
Write notes for every meeting and share with the right people. Setup Zoom coffees at the very least.
Shadow and track 2-3 recent support tickets to see how the on-call system works. And then, if possible, shadow someone for a week of on-call. Could be formal or volunteer to help.
Schedule a recurring 1-1 with your manager. Ask them to write down/describe explicit expectations from you. If they don’t write, you write it down and email it to them – and then follow up 90 days later.
Note that you need to know the team’s perspective on their strengths and not just the manager’s. There can be some gap between the two.
These are the things and people who’ll be able to help when you get stuck in a technical problem later. They’ll know that you are not an incompetent prick, and have done your homework. This trust is cheap to earn and surprisingly sticky when done early – but hard to earn after first 90 days.
2. Quick Loud Win
This is more for early career folk and less for senior folk. Do something which is a big, tricky, much talked about the project and then do it fast. Doing it perfect is kind of less important. Why? Because no one expects early-career people to get it perfectly right anyway.
My hack for this has been to pick a project with some well understood technical risk. But! But! Pick where expectations are clear. For instance, towards the tail end of a big project which needs a small feature to be complete and closed.
If you can, pick a task which is closer to your technical strengths. E.g. I’ve done enough text classification in my short career that I can prototype one in 6-8 hours.
The point of a quick “loud” win(s) is to ensure that you get a steady stream of projects to pick from – forever.
Good projects should chase you, instead of vice versa. A loud project, well done, will make you attractive to other project owners. Not just quick: Quick loud win.
I hope these help when you join a new gig as an engineer.
All the Best,
Natkhat Nirant
PS: For more senior people on the Engineering Management track, I recommend reading this instead: https://lethain.com/first-ninety-days-cto-vpe/