I joined AWS around 4.5 years ago and had the good fortune to be a founding member of a brand-new service. It was tough and interesting to build it from the ground up, and it put me in an excellent position to know practically everything about the requirements, architecture, different design decisions, reasons for those decisions, and what known issues (and their workarounds) we have and keep dragging with us as technical debt.

Recently, I decided to move on and joined a startup. The company already had a team working on the product for many months, and I had to step in and pick things up quickly. Furthermore, the product is written in a programming language that I never worked with, so the question is how do I set myself up for success?

Any change can be scary, especially if it takes you far outside your comfort zone, but if you adhere to a few general guidelines, I truly believe you can succeed and hit the ground running.

1. Get a basic understanding of the problem we are solving, the current product and the short-term (and possibly long-term) roadmap.
2. Understand the current architecture and high-level design, and most importantly – the reasons behind it. For example:
   • Why do we need micro-service X ?
   • Looks like this micro-service is a bottle-neck and a single point of failure. Are we planning to change it? How ?
   • This flow is part of the API path and might cause high latency. Why didn’t we build some of it as a background service ?

   Note: Sometimes there is not much documentation of the current design. In that case, I would strongly recommend building one. Talk with team members, write down notes, and then draw an architecture diagram with all the services, their responsibilities and input/output objects. You will gain three things: 1/ You will have it in front of you for future reference. 2/ Other people can review it and correct you in case you didn’t capture something right. 3/ New folks who are joining the company will benefit from it.

3. Get to know the existing processes in the company, and how things are done. How do we review the code? How do we merge to production? How do we test locally?
4. Spend some time reading about the new programming language and the tools that are used. There are plenty of books and online resources on everything. Watch some videos on advanced topics, and most importantly play with them. Consuming information is great, but you need to go, write some code, and make sure you understand what you learned.
5. Take on simple tasks that require you to read a bunch of code and make small changes. You will start making connections between what you have learned from others (about the product, architecture, and design) and by making changes, you will see things break. Spending time reviewing and fixing unit tests, running the application locally, accessing APIs and observing the results can help you test your comprehension, boost your confidence, and eventually allow you to start taking on more complex tasks.
6. Don’t be afraid to ask questions! When I don’t know something, I don’t have any problem admitting it. Trying to position yourself as a know-it-all will cause you to lose “points” in the long run, as people will stop trusting the information you give them. Instead, be confident in yourself and in your skills to learn whatever you need – by asking questions, and following up by looking at online resources. As a bonus, by asking “basic” questions other people might catch things that were missed 🙂
7. If you work remotely, there is no way to meet face-to-face with everyone and go for a coffee or a beer. Instead, I would recommend setting up 30 minutes with other folks on the team, turning on your cameras, getting some coffee and talking with each other. Building personal relationships is the key to success. Don’t be hesitant to say hello and introduce yourself.
8. When participating in meetings, don’t hesitate to express your thoughts. Everyone brings a different perspective to the table, and everyone has a different prior experience that is valuable. Always remember that you were hired not only for your coding skills, but also for your thought process, experience, and many other skills.

Have any other recommendations?
Please drop a comment and share your thoughts!

– Alexander

Please leave this field empty

Oh hi there 👋
It’s nice to meet you.

Sign up to receive a notification when new posts are published!

We don’t spam!

Check your inbox or spam folder to confirm your subscription.