Effective Working Mechanism on Dive Deep and Bias on Action

Effective Working Mechanism on Dive Deep and Bias on Action

·

4 min read

As you might know, I currently work at Amazon. In Amazon, there are number of leadership principles (LPs). Among those valuable principles, I personally regard some of them as core principles that every engineer should have them as core materials on engineering mental model. The reason why I think they are crucial to engineer is that those rules align what most engineers should equip as mental model.

Luckily, I worked with talented engineer mates in my team. No matter what job level they are, there are plenty of stuffs to learn from my side. In this article, the contents I would like to write down in here are also what I learn from my team’s junior engineer (SDE1). I also agree that we, engineer, must learn from anyone if there are something that I can grow from them. It does not matter whether how old they are, how long their YoE (year of experience) is, or how I personally favor them or not.

This guy is doing very well in Dive deep and Bias on Action. What does it mean is that if there is something new he faced, then he gathering information until he understand fully the context, and come up with a solution to tackle the issue and do it.

1. Starting from the Issue (Dive Deep)

If you are currently employed, you may face some of weird implementation or ad-hoc solutions to meet specific your environment. There might be wiki or documentation in somewhere describing why those not-understandable code happened. If you read that, you will be convinced. That is the moment you need to feel `”This is odds”`.

For AWS specifically, there is well-structured and best-fit industry examples in blogs and documentations. Because AWS orgs target general situations where the product can perform in best manner. Of course, the example is not always the answer to fit all problems. However, it is starting point of having thinking mechanism to debate by yourself. Maybe when the hacky way is introduced, those new features/industrial examples were not yet discovered. If any reason you think current way is not right, then it would be a good opportunity you can contribute and have low-hanging fruit.

2. Identify what are Blockers to achieve the Goal (Working Backward)

If you find something which you can optimize or enhance, you should start from the problem. Let’s say you faced an issue like one of the query is running about 3 hours. However, the official documentation promises the normal execution time is less than 30 minutes and the promised query size is more bigger. Then, you might want to see what are difference between example environment configuration and your configuration. Maybe the database cluster does not have enough resource or the query is not optimized or maybe too many queries are running concurrently.

For example, external dependency is involved in this situation and it is identified as bottleneck. You need to collect as many data point as possible to build consolidate argument. The possible path forward can be contributing external dependency as away team model or you can build your own solution even more cooler way.

3. Drive the solution and Getting rid of the Bottleneck!

Yes! this is the most interesting stage. Almost all engineer will feel productive when they start to build something new. You convinced and allocated resources to put your efforts developing new stuffs. Keep it mind that the data points you collected in section #2 should be improved after your solution replaces existing one. Also you need to influence other mates to let them help you if you drive the project with multiple people.

The new solution would be your new child and you will love it because the solution was built based on your research from official documentation. It means you built new solution fitting the nature of solution is proposed. It definitely works fantastically.

Working Mechanism

So remember that

  1. Find the issue if you feel it is weird based on your industrial example understanding, blogs articles. It does not matter you collect that information or just your god feeling.
  2. Start from the issue. Research what is the recommended approach in similar situation. How do they accomplish the work ? Comparing your situation and what the standard is.
  3. Identify blockers that makes you not be able to reach the standard stage.
  4. Getting rid of those blockers and enjoying the moment where you build something cool!

Did you find this article valuable?

Support Juno Dev Lab by becoming a sponsor. Any amount is appreciated!