Senior mindset book takeaways

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the collaboration category.

Last Updated: 2024-03-02

Book by Swizec Teller


Realize that even senior engineers destroy production constantly with bugs

This is the nature of programming. Chill and don't freak out.

Be self-managing

Basically: Can you carry a project from start to finish without your manager's input? Asking other people for assistance, testing, documenting, doing QA and working with QA team, deploying, etc.

Make it a priority to unblock your team

Ultimately this saves the company money by force-multiplying.

Every day, proactively ping your manager with status updates

That certainty that stuff is happening and that when stuff stops happening they’ll know immediately means the world to your manager. When you come to them and say “Yep gonna be done tomorrow” or you say “Nope won’t be done, here’s why”. It relieves anxiety like you wouldn’t believe.

Work on your career


Think about the company's productivity

Start doing things (and initiating things) that improve things overall for the company and makes the team more efficient.

No-one gives a shit how hard you work

They care about results - focus here.

Don't think about how much time or effort it takes to do something. Consider instead how much value it provides.

This is how to feel good (and justified) in asking for high rates.

Use leverage to negotiate rates/salary more aggressively

If you have savings/lots of options, then you are able to push harder about earning more because you can walk away.

Companies care about the systems and tools you put in place to make the whole engineering team run better, do more, and make bank.

Stand out from the crowd

Make companies want you - not just a code monkey

Ask every client for a testimonial

Client testimonials trump all. Collect those.

Ask clients for referrals to new clients

Work with the duck-tape shitty code

How well must you engineer something you're throwing away 3 days after deploy because customers hate it?

You don't know if you (or the company) will be alive in 6 months. Work around the issues for the most past. Figure out the duck-tape charade.

Fix things when they hurt or break.

Fight back on perfection constraints from business stake-holders

When the business people say best they often mean good enough When they say guaranteed, they often mean unlikely.

Levels of being a great boss

Terrible: Ask how can I use team to get more done?

Good: How can I help team get more done?

Great: How can I create systemic changes that remove crap my team have to deal with?

Amazing: How can I build tools that help team?

Phrasing for emailing like a boss

Best Skill: Ownership

If you grab a project, it will get done. No matter what.

Software engineering skills

How will this code adapt to changes in how this task evolves? What does this code encourage others to do? How does this code encourage other programmers to use it? How will I understand this code in 5 months? How will a busy team member jumping around grok this? When will this code stop being good enough? How does it scale? How does it generalize? What hidden dependencies are there?

Google recommends fakes over mocks

A fake is a simplified implementation of the real thing, maintained by the same team for API parity

Google recommends updating dependencies often

Going from 2.8.1 to 2.8.2 is easy. From 2.8 to 2.9 harder. From 2.8 to 4.0, much harder.