Ask HN: How do you become productive in a new project as a senior developer?

Mistake 1 - Was too focused on committing code and getting my first PR merged. I wanted to prove I could commit code quickly, and that PR is missing a lot of things and had to be patched later.

Mistake 2 - Not asking for (enough) help. I did a short pairing session that got me up to speed, I should have asked for a few more. I also should have asked "What's important in this code?" I had to learn that the hard way.

Mistake 3 - Ignoring the full release lifecycle. On day 1 you should first learn how issue management works, and then how the software is released to production. Releases caught me by surprise, and I ended up having to put hotfixes in.

Mistake 4 - I let QA become a second class citizen. Find out who and how your code will be QA'd, and try and be active in that process.

Mistake 5 - Ignoring important "sub-systems" as they didn't seem to directly pertain to my work. For instance, I knew we had a feature toggle system, and I was told I didn't need to use it for my work, but looking back, it would have been nice to know and use. I also was told to ignore end-to-end tests since my work was so small. Well guess what held up release because my code broke it? Yep, end-to-end tests.

Mistake 6 - Modifying code without reading tests and understanding the underlying data. A lot of people have mentioned this, and it can't be emphasized enough. A lot of tests have mock data at the top, why ignore that, it tells you what the code is working with. 'Describe' blocks tell you exactly what methods are supposed to do and what's important about them.

So, I made a lot of mistakes it seems, but the most important thing I did right was this:

Whenever I realized a mistake, I fixed it and I moved on. I didn't let it get me down, and I won't make that mistake again. That's ultimately what a good dev is, someone who can red/green/refactor their mistakes with minimal oversight.

proceeds to describe idiocy

1. First thing is to come up with a ramp-up plan. Before you touch any code, before you fix bugs, make sure you have a 30- and 90- day plan for where you need to be and what you need to know. That plan should include with coming up with questions for people and meeting with them to ask them, understanding the company's strategy at a sufficient level, and, yes, understanding the code base and development procedures.

2. As a Senior Developer, it's good to know where the project is now, but people are looking to you to know where the project will be in 6-9 months. So, while fixing bugs is good, don't get bogged down in that - after some initial familiarization, take up tasks that let you focus on big picture architectural and process issues.

3. Take time to get to know your colleagues. Have lunch with them. Have non-work conversations. Start to learn what interests them. Without explicitly asking, pay attention to clues about career goals and what they find challenging. As a senior developer, demonstrating that you are genuinely interested in your colleagues goes a long way towards earning trust and getting embedded into the team faster.

3a. Get a sense of the team's culture. Are there cultural norms you're not used to? Are these norms good/bad/indifferent?

4. Given that you are a Senior Developer, you should make sure your team is hitting a lot of basics. Are there feedback loops, both business-wise and process-wise to your team? If not, you should work on getting these in place (or at least making sure that it happens). Business feedback loops should include some kind of KPI report, adoption report, etc. Process feedback loops usually include regular, honest and constructive retrospectives. Usually if you're hired as a senior developer on a team, most of your teammates will have limited experience in these.

5. Whenever possible, share your perspective. One of the big differences between a senior developer and non-senior developers is that you've seen a few projects, and you've probably seen pitfalls along the way. That's probably a big reason why you were hired. A great way to add value to a team when you still don't know the nitty-gritty is being able to say "It sounds like we're doing X. I was on a team once that did X, and A, B and C happened." Of course, always do it from a point of view of humility - there might be new constraints that you didn't know about.

Beyond that, a lot of it will depend. If you're joining a large company, you should spend some time doing "company networking," i.e. , meeting other senior developers, project managers your team works with, understanding not just your project but other projects near you in the org. If you're joining a start-up, chances are there is a deadline in a few months, so the emphasis will be much more on delivering something immediately. Writing documentation can sometimes be helpful, but if you're at a startup that now has hired its full allotment of engineers, writing a ton of documentation about how to get up to speed is of limited use. Fixing bugs can sometimes be a good approach, but sometimes for teams that didn't have a senior developer before, the proper fix involves a design change. Is there someone else who is also interested in raising the bar for engineering practices, but doesn't know where to begin? Work with that person, since you have the experience as a senior developer, and that person understands the specifics of the team.