Notes on Coding Career Handbook

Published Monday, October 03, 2022

I joined a new bookclub that’s reading “The Coding Career Handbook” by Shawn Wang (@swyx). We’ll be jumping around chapters a bit, since the book wasn’t intended to be read in order, per the author’s advice. Here’s my notes on each chapter we’ve covered.

Chapter 5: From Junior to Senior

“A senior title with the pay is meaningless!” 👏 👏 👏
“The Difficulty Anchor” by Mekka Okereke
- Research shows most marginalized groups will leave their job frustrated with rate of promotion or perception of being evaluated unfairly
- Don’t listen to people who say “don’t worry about performance reviews”. Those folks are probably in a more privileged position.
- “Just do good work” isn’t going to be enough
- Typical sequence of events:
  
  1) People think that you are not that good. 🤬 2) You do good work, and accomplish something impressive! You showed them! 😃 3) But peers retroactively downgrade the value of that accomplishment! 😮
- Post-fact devaluing: “For your peer, the shortest mental path back to consistency is often to devalue your work.”
- How to counter this?
  1. Before project starts, find a Very Smart Person with strong organizational credibility. Explain your plan to them in great detail.
  2. During project: do great work and keep detailed notes.
  3. After project: publically celebrate your work and make sure your Very Smart Person chimes in to validate you and squash all the haters.
Comparisons:
- “Juniors get code working. Seniors keep code working.”
- “Seniors create tooling to preclude bugs.”
- “Juniors learn to find the right answers. Seniors learn to ask the right questions.”
- “Juniors should say “Yes” often. Seniors should say “No” more.”

Chapter 6: Senior Developer

“Done is better than perfect”
“Good enough is better than best”
Prudent vs Reckless technical debt
- Prudent
  - Outdated
  - Makes money
- Reckless
  - Taking shortcuts, cutting corners
  - Meant to speed up development, but eventually slows you down
  - Results in loss of predictability
  - Adding resources increases risk
Sell tech debt as risk instead when talking to LT

Group discussion

Linked blog posts
- “Tech debt” isn’t a good parallel to financial debt, because you’re not really paying it down or anything like that
- Better to reframe it as risk
Rewriting
- Decision to rewrite in new language, framework etc is tricky
- If you go with greenfield rewrite, how long do you live maintaining two systems? What about bugs in the old one?
Mentorship, Sponsorship, Allyship
- People might not welcome an offer of mentorship, but no one turns down sponsorship
- Antipattern: taking all the good work yourself, so everyone else is stuck with no opportunities to grow
- Invite juniors into meetings/conversations with more experienced folks so they can “be in the room”
Business impact
- Foolproof way to show biz impact
  - Find someone who uses your product
  - Ask them to speak up about something they want added/fixed
  - Add/fix it
- Recommendation: Dream Machines by Ted Nelson

Chapter 18: Write, A Lot

Write more docs, discussions, ADRs etc than code
“Adjacent” skill to engineering
Writing as a “cache” of yourself
Helps you scale infinitely
Other adjacent skills
- Drawing good diagrams
  - mermaid.live
- Project management
- “Demos, not memos”
- Networking (internally, too)
Google technical writing course
Good writing is minimum bar for senior, but “hustle culture” writing for external audiences isn’t necessary
Communicating to manager/skip level
- Project board
- Track things in issues
- Keep running brag doc

Chapter 23: Specialist or Generalist

You can be very successful as either
“T Shaped” vs “Pi Shaped” vs “Comb Shaped”
When in doubt, specialize
Specialist in public, generalist in private

Kate Travers