Nicely put together. I would also add that, shadow someone who does these skills really well. 

Software Engineer @ Verily

Bikram Kashyap

This is the way I would think about it.

- Learn the jargon. ChatGPT can help a lot in this. Else ask for resources
  - 10% of the jargon will have a complicated or ambiguous meaning. Example from an old project, in healthcare, there is an open source ODM data model. We had a hard time rationalizing what a Visit is, as online visits were becoming a thing.
- Look at the test cases. They can be living documentation of whats going on. P.S., see if you can arrange the tests in go's table test style, that makes understanding a lot easier.
- Add input output logs to a percentage of requests in dev.
- See if you can create a log with all the places the code went to. Use a threadlocal accumulator if a single request is single threaded. 

<https://www.youtube.com/watch?v=ZtZmEs74ReI>

<https://www.youtube.com/watch?v=sC1B3d9C_sI>

<https://www.youtube.com/watch?v=4fFDFbi3toc>

Basically, you run the situation where order of operations are determined by random chance, where if you know the seed, you can replay the order of operations. 

So, some of the strategies that I have seen work well

- Unit tests, at an interface level. Mock interfaces used by the implementation. Only public methods are called by the tests.
- End to end test/integration test. They can also serve as canaries if run frequently. 

Other caveats

- If you have a long rolling deploy, you will have a state where some nodes are having a new version of the code, some older. That can have some issues. Having an env where there is always a new and the previous deployed code version running is useful. 
- If you have a critical distributed system, look at deterministic simulation testing.

One thing I am having success with is looking for making a tradeoff decisions with technologies I am not familiar with. For example, trying to [evaluate](https://x.com/i/grok/share/nwHuiDGk9v92MnyR2oLIxwVqq) react redux. Or tradeoff decisions between [different types of rendering](https://x.com/i/grok/share/1gBcJofZEESpmrotoQx1fJlmo).  

The way I see it, you need to define the scope and get it finalized with stakeholders. At Amazon and Google/Verily, in the design doc review, a lot of these issues are caught. 

Also think of Agile, not Agile(TM) as your friend. Test out the product as a user iteratively. 

Also, make sure to communicate that all edge cases cannot be seen immediately. So you will need skaffolds to detect edge cases that a user encounters. Look at fuzzy testing also. 

Once done make tasks. 

Look at the tasks to see what is the progress. Also make tasks for all launch approvals and stuff. 

The big trap is thinking that the MVP is the project. The initial MVP should be about 20% of the project. Think of it this way, you made the initial bot in 3 days. That means anyone can compete with you in 3 days. The rest of the 80% is what is actually competitive. Lines of code is not actual productivity. Meeting customer needs and giving that a good experience is.

risedesk ergo chair and autonomus chair. 

Ikea dining chair is also not bad :D

Mid-Level Software Engineer at Other

I would personally go with project Hero, but with a few caveats/prework. 

- Have a good conflict resolution mechanism. Make sure all decisions are data driven, disagree and commit where not enough data, but call out all the risks. 
- Figure out how not to get into crunch mode for more than a month. This can involve setting up mechanisms to speed up the team's work. 
- Read books/learn what is needed. Look at it from a learner perspective, and make sure the team also learns fast. 
- Ensure management has visibility into all your contributions.  

Look at google's internal mentorship platform too.

### TLDR Version

Find some guiding principles and how to balance them.

Also remember, the more experience you get the more you can think of simplifying the process.

### Slightly longer version

Something that can help for small wins are:

1. Learn your style guide
2. Use linters and other code analyzers, they will catch a lot of issues.

For more in-depth:

1. Find ways to reduce code complexity and coupling.
2. Read some books like pragmatic programmer and see how you can use the tips in your development.

In this #taro-bookclub discussion, we'll go over ["The Pragmatic Programmer"](https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X) by Andrew Hund & David Thomas

Here's the agenda:

- Design by Contract
- Dead Programs Tell No Lies
- Assertive Programming
- How to Balance Resources
- Don't Outrun Your Headlights

Please send your questions ahead of time to [Bikram Kashyap](https://www.linkedin.com/in/kashyapbikram/) in the [**Taro Premium**](https://www.jointaro.com/membership/) Slack, so that they can be included in the discussion. *If you don't have the book or want more details on how this all works, check out the #taro-bookclub channel in the Taro Premium Slack as well!*

Get ready for another engaging and informative session!