Precious Learning Materials for 3 Years Being a Nakama
I had my wonderful time working at Tokopedia for three years starting at 2017 until 2020. Started as a Software Engineer, then Senior SE, and ended up as a Software Engineer Lead taught me a lot of lesson and experience. I met with a lot of great people, friends, and great leaders that directly or indirectly shaped me of who I am right now. As I’m currently starting new Journey in different place and culture, here are some precious highlight that I learned in Tokopedia as an Engineer.
Don’t be ashamed to learn, ask, or even make a mistake
Since this was my first job after I graduated from college, I must be able to keep up with the running tech stack at that time. Golang, ReactJS framework, Redis, Elasticsearch are part of the things that I need to learn since the first second I joined the team. Fortunately, my team and even more the whole engineering team helped me a lot by their guidance and willingness to answer even the silliest questions I had back then. The engineers always ready to help each other when you need them.
Talking about mistakes, one thing that i love the most is that there is no blaming culture when you’re making a mistake. The focus will always be on:
- What is the mistake
- How it can happen
- How to solve it
- What can we improve so it won’t be happening again in the future
This doesn’t mean that everyone can make mistakes freely, still we’re as Engineers need to do our work with caution by doing unit testing, collaborate with Test Engineers to do integration and regression test, doing monitoring and stuffs. But those values are safety net that we’re in the same goal, we’re working on the same products, if there is something goes wrong, let’s focus on solving it rather than blaming the person who makes the mistake.
Designing and implementing high performance solution is a must
Software Engineers in Tokopedia are expected to deliver not only just a solution that works, it’s pretty important for us also to think about the performance and scalability. Making your solution work is one thing while having it stable and reliable on heavy load traffic must also be put in mind while designing the solution. Simple SQL query that doesn’t hit proper index, not implementing caching on very frequent or expensive calculation data, are some example of the things that might seems fine on daily traffic but can be problematic as the traffic goes high (flash sale, big campaign, etc). Therefore, caching, designing good performance query, implementing bulk process are several among many processes that can be taken for achieving high performance solution which of course may be different from time to time based on the problem domain.
I would like to also paraphrase some of key notes from one Tokopedia Engineering Leaders that I remember back then:
Slow query is a time bomb, it can explode during high load traffic. We have to be aware of our system health, performance, and scalability. At the end of the day, we’re engineers, we’re the one who wake up in the middle of the night if things go wrong or things go south, so it must be reliable, scalable, and high performing system.
That is not the exact words, but more or less that is the point.
Your team soft skill are as important as their technical skill
When I began to learn about managing not only your works but also your team, the quality and speed of your team works not only rely on their technical skill. It does matter to be expert technically on what you do, but it’s required more than that to be on the higher level. I’ve seen that some people are high performing on their works due to their good communication skill, very high ownership with their project, willingness to give the best of their ability to help others, etc. These kind of things that doesn’t directly help them to do code (as an Engineer), but play indirect part of boosting their bigger picture of achieving more than just one work itself. As an example, someone that is having high ownership on their projects tends to do more than what being asked within the project, therefore delivering more value and initiative to the end result.
Set high standard rather than putting it low and easy to achieve
Talking about target, usually the common options that we have will be among these two:
- Setting up high target that is hard to achieve / even looks impossible to achieve
- Setting up low target that we confidently able to achieve
I’ve been inspired by Gilang () my manager at that time (currently he is already Head of Engineer 😁), when we’re being a leader, it’s important to set high standard / goals for our team. When we set our goal high, we will have to try our best to reach them by thinking our plan to break those goals into smaller ones that lead to achieving the primary goal. When we set the target high, of course we will be sweating for running to get it.
“If we’re growing, we’re always going to be out of our comfort zone.”
— John C. Maxwell
Usually, there are two things that can happen when we set the goal high:
- We achieve the goal
- We don’t achieve but the result is still better than the low standard that we had in mind
There are a few real examples on our team that seems like very hard achieving goal at first but we made it in the end. Reaching 95%++ unit test code coverage on our services and having our services availability by about 99%++. Those are two among many things that we achieved by using this method.
Maintaining good relationship with people is good investment
I’m a type of person that usually like to talk with people not just about work, but also another things outside work, or anything we have in common to talk about. On the first hand, these things are not likely to be playing any part on my career, but I was wrong. After several years of working with many people, knowing them more than just work related, having more casual relationship beside the professional relationship, actually does make a difference. Some of the function that I closely related with during my works were DBA and Devops team. I was close with several people within those two teams and I can say that during some hard times when our team needed them, they helped us faster than ever. Of course that they also help another team in need, but when you maintain good relationship, you can get their help more easily since at the end of the day, we’re all working with human beings.
Closing Statement
Long story short, those are some valuable keys that I got during my time as a Nakama, I hope some of it can be useful for you in some way.
