Reading Notes

Content up to Chapter 3, which is about halfway through

First, let me write about what I’ve learned:

• Trial and error is bad; ask others early

• Take time to understand

• Create documentation first

• Outcome supremacy hinders improvement

To be honest, there wasn’t much new content so far.

On the other hand, when asked “Are you actually practicing this?” - there are many points I’m not.

What’s common among the areas I’m particularly weak in is that they’re caused by “perfectionism.”

I can’t ask others because I worry they’ll think “Can’t you even do this?”

Since AI can shape things to a certain extent, I end up doing a lot of ad-hoc trial and error, and so on.

This book also mentions that you should handle tasks that match your capacity, an amount you can manage right now.

Also, if you really want to improve, it’s important to properly invest time in areas that require it.

So, how should I apply this to myself?

Towards Self-Integration

First, avoid trial and error.

Once I clarify where I’m stuck and what I don’t understand, I’ll quickly throw it to my mentor.

This aligns better with my goal this year of increasing my failure count, and as a result, I’ll likely become an engineer who can contribute to the team faster.

Furthermore, when I’m taught a solution, I’ll always dig deeper on the spot and not leave it for later.

For parts I don’t understand about team specifications, I’ll properly ask my mentor.

Then, if I didn’t know the technology, I’ll use AI and books to take time for self-integration.

This way, even if I get stuck next time, it should be a specification-related issue.

Think carefully about how to use mentors, AI, and books.

Next, stop outcome supremacy.

Outcomes have become really easy with AI.

Auto-generation AI is increasing, and we’ve entered an era where they can write programs to a certain extent.

Let’s change how we use them.

For the parts that achieve 80% of the results, I’ll trial and design myself.

Leave the remaining 20% to AI.

I’ll make expanding my Level 1 domain - areas I can implement without documentation - my KPI, thoroughly mastering parts that will repeatedly come up in the future.

Furthermore, create documentation first.

In the case of data scientists, this might be different - it might be reports.

However, if I don’t clarify upfront what analysis I’m seeking, I often get lost in the data and lose sight of my surroundings.

If I prepare what to report first, testing and analysis should become clearer.

Finally, take time to understand.

Going forward, I’ll use this blog to share content where I got stuck.

Come to think of it, I hardly talk about technology, so I should properly update that!

Summary

If you want to grow as an engineer, execute the 20% of tasks that deliver value.

These tasks may change in the future, so always be conscious of the market.

Also, consider that you can’t start your growth story without failures.

There’s no protagonist in any manga who never loses!

If you’re a man, don’t run away. Don’t be ashamed of losing. Laugh at the end.