Building a Career in Software

Review

Solid collection of practical advice, tips, and strategies for working in software development. It feels funny to be reading a book about how to write an email, but also there are a lot of random useful things to know about the workforce that someone has to teach you! (I actually used his "introductions" email template shortly after finishing the book and it was very helpful.) I thought that parts two and three — day to day life in the office and communication — were the most applicable to me.

Notes

Part 1 — Career

Own your own career — no on else will guide you.

Engineering is about building things and solving problems

Skills used to accomplish this:

• Coding
• Project management
• Communication
• Personal organization and time management
• Architecture
• Leadership and mentorship
• Emotional skills

10 Principles

1. Reason about business value
2. Unblock yourself
3. Take initiative
4. Improve your writing
5. Own your project management
6. Own your education
7. Master your tools
8. Communicate proactively
9. Find opportunities to collaborate
10. Be professional and reliable

Resume section order: experience, skills, education

CS fundamentals: linked lists, hash tables, trees, sorting, Bio O analysis of all

Career goal: solve the biggest problems your abilities allow, constantly challenging yourself and nurturing your technical and people skills

Technical study — should be learning technical content every weekday

For mentorship:

• Explain your goals
• Come prepared with 2 recent challenges and notes, advice you want, etc.
• Maintain a shared agenda
• Do your readings and return with questions

If you need to write a self review — construct a narrative that emphasizes your productivity, leadership, autonomy, and impact

Should expect 6 months of struggle when starting a new job, and then reevaluate your situation every 6 months

Choosing projects involves optimizing for learning, resume/advancement, and satisfaction

Part 2 — Day to Day At the Office

Essential methods to project management:

1. What needs to be done — list
2. How much can be done — dependency graph

Give weekly updates about timeline, what's done, what's not done, implications

Always pad estimates by 2x!

Keep two documents: an infinite scrolling document for every trick and a text file with your most recent commands

Easiest way to identify an effective engineer — they Just Do Something ("bias to action")

Keep track of what you do

Qualities of an effective meeting: owned by someone, has a clear agenda and goal, focused on conclusion, notes afterwards

Dimensions for hiring: coding, architecture, communication, domain knowledge, organized thinking, and attitude (passion and collaboration)

2 Principles of Giving Feedback

1. Give people the benefit of the doubt
2. Give feedback in the most positive way you can

3 Principles for Receiving Feedback

1. Seek it out often
2. Receive it with an open mind
3. Express appreciation whether you agree or not

To build a good reputation: do good work and treat people right

Enthusiastically help your colleagues when they need it

Reliability is important to your reputation, so:

• do what you say you'll do (don't overpromise), and
• be on time and be available

Know your limits and try to categorize assertions based on your level of confidence (direct observations, beliefs, and suspicions)

5 Dimensions of Technical Leadership

1. Vision — choose something valuable, craft a story about it
2. QA — high quality work
3. Project management
4. Harmony
5. Mentorship

When assigning work, pick "what they can do, plus epsilon" and give them context (will help them do their job better and believe in it more)

5 Components of Mentorship

1. Teaching — sharing tools, practices, and insights
2. Support and comfort
3. Evaluation — assessing strengths and weaknesses
4. Tactical problem-solving — helping them navigate specific situations
5. Goal setting

Need a model of your mentee — what are their goals? skills?

   Ask them to come to the meeting with their 2 most pressing problems

Dealing with difficult people: warmth, kindness, and assertiveness

Don't complain too much, don't gossip, don't date or get drunk with your coworkers

Part 3 — Communication

Listening is a social and an attention exercise

Main goal is to understand what they mean and why; secondary is to build relationships and make others feel understood

When communicating, keep in mind: relevance, context, clarity, efficiency, sensitivity

   What does this person need to get done and what information from me helps?

3 qualities when determining a medium: synchronousness, bandwidth, and formality

The 8 Foundational Principles of Technical Writing

1. Be concise
2. Emphasize conclusions
3. Put yourself in your readers' place
4. Use clear structure
5. Use simple language
6. Provide ample context
7. Lead with most important points
8. Edit for precision

Start emails with tl;dr for people who don't have time to read every word

Always be respectful and calm in an email — they live forever

When giving an update on a project, break it into subareas and cover background, progress, impact, and schedule

Principles for asking questions:

1. Try a reasonable amount to help yourself before taking others' time
2. Provide ample context (intentions and observations)
3. Express your question precisely

Part 4 — Technical Skills

When staring with a new language, read a book about it and consult a style guide

Objectives of good naming: explicitness, brevity, and consistency

Comments are useful for describing motivation, design, assumptions or invariants, and anything not obvious

High quality code needs tests, preferably with 100% coverage

Cleverness — I'm opposed to it. Favor explicitness and simplicity over cleverness whenever possible. (200)

Be cautious about dependencies (especially open source)

Inject dependencies for better decoupling

Priorities for codebase: correctness, maintainability, development cost, performance

   Can use these as a guideline for code reviews as well

Debugging involves refining a mental model of the system using data

2 methods for experiments — make a runbook and record everything

Reliability: what could happen and how will we be ready?

2 major failure resilience techniques — redundancy and graceful degradation

Build observability into your system

Master the command line — it keeps you fast and makes you look like a pro