The Coding Career Handbook

Guides, Principles, Strategies, and Tactics –

from Code Newbie to Senior Dev
swyx

Foreword by Quincy Larson

In 2012, I left behind my career as a school director. I sat down at my kitchen
table with some programming books from the library. And I slowly started
learning to code.

It was a lonely, ambiguous process. But I stuck with it.

Within 6 months, I won a hackathon. Within 9 months, I got a job as a software

engineer at a local tech startup. And within 4 years, I started freeCodeCamp.org
to help other people get into software development, too.

Along the way, I met developers who’d entered the field from a lot of different
backgrounds. Accountants. Nurses. Soldiers. Fire fighters. But I never met
anyone quite like Shawn Wang. The guy was full of surprises.

For example, I interviewed Shawn for a podcast last year. And I discovered that
before he learned to code, he had worked as a financial analyst on Wall Street.
He left his $350,000 salary behind and started over at the bottom of a new field
as a junior developer.

And this week, I discovered something else about Shawn: he can write a 500-
page book that summarizes an entire profession, all in just a few months of
deliberate effort.

How does Shawn do it? Through a combination of “learning in public”, starting

from “first principles”, and never accepting a “zero day”.
If you’ve never heard those terms before, you’re not alone. But in the next few
pages, you will. You’ll learn all about these approaches to creative thinking and
productive doing. And you’ll learn something else, too: the tacit knowledge that
so many experienced developers carry around in their heads.

Nobody had written all this down in one place. That is, until Shawn turned his
indomitable will toward this task, sat down at his computer, and grinded it out.

In many ways, a book like this could only be written by someone with Shawn’s
combination of Wall Street pragmatism, Silicon Valley ambition, and a lively
Singaporean upbringing.

Even though I’ve worked as a software engineer for several years – and run a
technology education nonprofit – I still learned quite a few new things from
Shawn’s book.

I recommend this book for anyone who is thinking of getting into the field of
software development. And I also recommend it as a reference for experienced
developers. Shawn has structured this book in a way that you can easily come
back to it and fill in the gaps in your knowledge.

This book is stuffed to the gills with landmark studies and insightful quotes from
developers at the top of their field. Make time to absorb the many articles and
tech talks Shawn links to throughout. Sure, you’ll encounter many of these
canonical works sooner or later in your developer career. But the sooner you
grok their teachings, the longer their insights will compound for you.

Rome wasn’t built in a day. Likewise, it will take you years to build out your
developer career and reach your final form.

This book will help you work smart. How hard you’re able to work is ultimately
up to you. As Shawn is quick to point out, this is a marathon, not a sprint. So
pace yourself.

And remember to slow down once in a while and take in the thrill of creation
that comes with coding something new.

- Quincy Larson
The teacher who founded freeCodeCamp.org

Preface: Real Talk

The code will always be the easiest part of a coding career.

The more I talked to my friends about their careers, and the more I progressed in
my own career, I increasingly realized that the non-code part of coding was both
a hugely important, and under-discussed, topic. It is under-discussed because
nobody else is as invested in your career as you are.

And so the idea for this book was born.

There are a lot of books teaching you specifics of frameworks and languages.
There are a lot of books on quitting your job to do your own thing. There are a
lot of books on becoming an engineering manager. This book is none of those.
This is a book about getting coding jobs, and doing well at coding jobs.

That is an ambitious goal, which presents its own problems. It’s scary writing a
career advice book - I’m just one person, and I haven’t made a career of
coaching developers. I can’t guarantee success, and you can’t verify that
everything I tell you is right. All I have is hundreds of hours of listening to
people’s stories, and living my own. I have biases that make my situation
different from yours - I am a US-based, Asian male web developer, seeing
decent success after career change at age 30.

But I think the bar is very low. I’ve met with developer career success advisors
and read conventional career advice. You deserve a more intelligent discussion
than fits in a 15 minute YouTube video or yet another Medium blog post. That’s
why this is NOT going to be a conventional career advice book.

This is a linear discussion of Career Guides, followed by a nonlinear collection

of Principles, Strategies, and Tactics - independent essays of ideas that you
may or may not agree with, but are worth considering anyway. Please skim and
skip. This book is a buffet, not a five course meal. You will see some repeated
ideas, because the ideas are strongly interlinked. Unfortunately we can’t
normalize this; this book isn’t a relational database!
I have designed this book to last. A typical Code Newbie to Senior Developer
journey might take 4-8 years. I want you to discover the full context of
everything I’ve researched, with me as a guide rather than omniscient narrator.
I’ve embraced the digital format, and made heavy use of links to original
sources. Feel free to pause at any chapter, go down those rabbit holes I lay out
for you, and see for yourself. Don’t try to read this book in one sitting.

My job here isn’t to tell you things others already do. I will cover important
points, but if other people do it better, I will simply link to them rather than
regurgitate. My job is to introduce you to things you might take years to
learn, and to honestly discuss this industry like an older brother who is just a
few years ahead of you, acknowledging that what works for me might not work
for you but giving advice anyway.

This book is a conversation starter, not a conversation ender. I am not an

expert, this is not the final word on How to Make It in Tech. There are multiple
ways to succeed at a coding career, and I cannot possibly cover them all.
Consider me simply another companion on your own career journey.

With all that disclaimed, it’s time to have some Real Talk about your Coding
Career.

TL;DR ToC v1.0.0

The autogenerated Table of Contents is a bit too long, so here are the chapters
broken into the four parts of the book!

Chapter 1: Careers
A linear series of career guides of the three early career roles covered in this
book (Code Newbie, Junior Dev, Senior Dev), and the three major
transitions after each stage.

Chapter 2: Code Newbies

Chapter 3: Job Hunt
Chapter 4: Junior Dev
Chapter 5: Junior to Senior
Chapter 6: Senior Dev
 Chapter 7: Beyond your Coding Career

Chapter 8: Principles
A non-linear list of essays discussing ideas for Always-On Principles that
you can use to supercharge your career.

Chapter 9: Learn in Public

Chapter 10: Clone Open Source Apps
Chapter 11: Know Your Tools
Chapter 12: Specialize in the New
Chapter 13: Open Source Your Knowledge
Chapter 14: Spark Joy
Chapter 15: The Platinum Rule
Chapter 16: Good Enough is Better than Best
Chapter 17: First Principles Thinking
Chapter 18: Write, A Lot
Chapter 19: Pick Up What They Put Down

Chapter 20: Strategies

A non-linear list of introductions to Learning Strategy, Career Strategy, and
Tech Strategy for the ambitious developer making big, one-off decisions.
A comprehensive overview of the business of software and betting on
technology, and where you fit in the bigger picture.

Chapter 21: Intro to Strategy

Chapter 22: Learning Gears
Chapter 23: Specialist vs Generalist
Chapter 24: Betting on Technologies
Chapter 25: Profit Center vs Cost Center
Chapter 26: Engineering Career Ladders
Chapter 27: Intro to Tech Strategy
Chapter 28: Strategic Awareness
Chapter 29: Megatrends

Chapter 30: Tactics

A non-linear list of tactical advice for the ambitious developer making
small, repeated actions that advance their skills and grow their network.
 Chapter 31: Negotiating
Chapter 32: Learning in Private
Chapter 33: Design for Developers in a Hurry
Chapter 34: Lampshading
Chapter 35: Conference CFPs
Chapter 36: Mise en Place Writing
Chapter 37: Side Projects
Chapter 38: Developer’s Guide to Twitter
Chapter 39: Marketing Yourself

Chapter 40: The Operating System of You

Contents
Foreword by Quincy Larson
Preface: Real Talk
TL;DR ToC v1.0.0
Chapter 1 Part I: Your Coding Career

1.1 Principles over Titles

1.2 Company Types
1.3 Career Layers
1.4 Diversity
1.5 The Five Career Stages
Chapter 2 Code Newbies
Chapter 3 The (First) Job Hunt

3.1 Do the Math

3.2 Do the Work
3.3 Staying Motivated While You Search
3.4 Getting the Interview
3.5 Types of Interviews
3.6 Outside the Interview
Chapter 4 Junior Developer

4.1 Finding Your Groove

4.2 Making Mistakes
4.3 Adding Value
4.4 Growing Your Knowledge
Chapter 5 From Junior to Senior

5.1 Acting For the Job You Want

5.1.1 Technical Expertise

5.1.2 Career Strategy

5.2 Marketing Yourself as a Senior Engineer

5.3 Junior Engineer, Senior Engineer

5.3.1 Code
5.3.2 Learning
5.3.3 Behavior
5.3.4 Team

5.4 To Stay or To Go
Chapter 6 Senior Developer

6.1 Solutions vs Patterns

6.2 Velocity vs Maintainability
6.3 Technical Debt

6.3.1 Prudent Debt

6.3.2 Reckless Debt

6.4 Mentorship, Allyship & Sponsorship

6.5 Business Impact
6.6 Recommended Reading
Chapter 7 Beyond your Coding Career

7.1 Engineering Management

7.2 Product Management
7.3 Developer Relations
7.4 Developer Education
7.5 Entrepreneurship
Chapter 8 Part II: Principles
Chapter 9 Learn in Public

9.1 Private vs Public

9.2 Getting Started
9.3 But I’m Scared
9.4 Teach to Learn
9.5 Mentors, Mentees, and Becoming an Expert
9.6 Appendix: Why It Works
9.7 Appendix: Intellectual History
Chapter 10 Clone Open Source Apps
Chapter 11 Know Your Tools

11.1 Avoid FOMO

11.2 Beyond the Tool
Chapter 12 Specialize in the New

12.1 Technology Complements

12.2 Lindy Compounding
Chapter 13 Open Source Your Knowledge

13.1 Open Knowledge

13.2 Open Source Knowledge
13.3 Personal Anecdote
13.4 Why Open Source YOUR Knowledge
13.5 Tips
Chapter 14 Spark Joy

14.1 What is Sparking Joy?

14.2 Why It Works
14.3 Examples

14.3.1 Sparking Joy in Code

14.3.2 Sparking Joy in PRs and Issues
14.3.3 Sparking Joy in Docs
14.3.4 Sparking Joy in Demos and Products

14.4 The Extra Mile

Chapter 15 The Platinum Rule

15.1 The Platinum Rule

15.2 The Silver Rule
Chapter 16 Good Enough is Better than Best

16.1 Why It Matters

16.2 The Problem with Seeking “The Best”
16.3 False Confidence: Accuracy vs Precision
Chapter 17 First Principles Thinking

17.1 Logic
17.2 Epistemology
17.3 Applications
17.4 Systems Thinking
17.5 Further Reading
Chapter 18 Write, A Lot

18.1 Why Developers Write

18.1.1 Documentation
18.1.2 Career Capital

18.2 What Writing Does for You

18.2.1 Scale
18.2.2 Structure
18.2.3 Power

18.3 How to become a Good Public Writer

18.3.1 Getting Started

18.3.2 Going Public
18.3.3 The DIY PhD

18.4 Committing to Writing

Chapter 19 Pick Up What They Put Down

19.1 Pick Up What They Put Down

19.2 What happens when you do this?
19.3 Why does this work on them?
19.4 Why does this work on -you-?
19.5 Your call to action
Chapter 20 Part III: Strategy
Chapter 21 Intro to Strategy

21.1 What is Strategy?

21.1.1 How Do I Use Strategy?

21.1.2 Don’t Stress Too Much
Chapter 22 Learning Gears

22.1 Explorer
22.2 Settler
22.3 Connector
22.4 Miner
22.5 Why “Gears”?
22.6 What do I do now?
Chapter 23 Specialist or Generalist?

23.1 Leverage vs Self Sufficiency

23.2 The “Full Stack” Developer
23.3 “T Shaped” and “Pi Shaped”
23.4 Look Inside, Not Out
23.5 When In Doubt, Specialize
23.6 Specialist in Public, Generalist in Private?
Chapter 24 Betting on Technologies

24.1 Never Betting On Anything

24.2 Data Driven Investing
24.3 How To Be Early

24.3.1 Managing Risk

24.3.2 Know What’s Missing
24.3.3 Evaluation
24.3.4 Don’t Surf Every Wave
24.3.5 People

24.4 The Value of Values

Chapter 25 Profit Centers vs Cost Centers

25.1 A Disclaimer
25.2 Definitions
25.3 “Close to The Money”
25.4 Profit Center, Cost Center
25.5 The Developer’s Choice
Chapter 26 Career Ladders

26.1 When and Why to Ladder

26.2 Our Approach
26.3 What Companies Want

26.3.1 Most Junior

26.3.2 Most Senior
26.3.3 Other Dimensions

26.4 Individual Company Ladders

Chapter 27 Intro to Tech Strategy

27.1 Tech Strategy and Your Career

27.2 Software is Eating the World
27.3 Horizontal vs Vertical
27.4 Business Models

27.4.1 Agencies
27.4.2 Advertising
27.4.3 Subscription
27.4.4 Marketplaces
27.4.5 Gaming

27.5 Platforms and Aggregators

27.5.1 Aggregators
27.5.2 Platforms vs Aggregators

27.6 Other Strategic Perspectives

Chapter 28 Strategic Awareness

28.1 Concern vs Influence

28.2 Levels of Concern
28.3 Bias to Action
28.4 Understanding Technology Adoption

28.4.1 The Rogers Curve

28.4.2 Crossing the Chasm
28.4.3 The Gartner Hype Cycle
28.4.4 The Perez Surge Cycle

28.5 Technology Value Chain

28.5.1 The Law of Complements

28.5.2 Wardley Maps

28.6 Systems Thinking

28.7 Other Strategies for Strategic Awareness
Chapter 29 Megatrends

29.1 Definitions
29.2 Examples
29.3 Building Your List of Megatrends
Chapter 30 Part IV: Tactics
Chapter 31 Negotiating

31.1 General Advice

31.2 Summaries of Experts

31.2.1 Patrick McKenzie on Salary Negotiation

31.2.2 Haseeb Qureshi on Ten Rules for Negotiating
31.2.3 Josh Doody on Fearless Salary Negotiation

31.3 Further Good Reads on General Negotiation

Chapter 32 Learning in Private

32.1 Improving What You Consume

32.2 Getting More Out of What You Consume
32.3 Go Meta
32.4 Further References
Chapter 33 Design for Developers in a Hurry

33.1 Spark Joy Repo

33.2 Frameworks
33.3 Layout
33.4 Typography
33.5 Color Palette
33.6 Backgrounds
33.7 Icons and Illustrations
33.8 Animations and Video
33.9 Easter Eggs
33.10 Learning Design
Chapter 34 Lampshading

34.1 When you’re very senior

34.2 When you’re new
34.3 Storytime!
34.4 Lampshading
34.5 The Stupid Question Safe Harbor
34.6 Advanced Lampshading
Chapter 35 Conference CFPs

35.1 Who Am I to Advise You?

35.2 Watch a lot of talks
35.3 Speak at a Meetup
35.4 Pick a Conference
35.5 Pick a Topic
35.6 Pick a Genre
35.7 Pick a Title
35.8 Write an Abstract
35.9 Building a CFP Process
35.10 Example CFPs and Peer Review
35.11 Next Steps & Recommended Reads
Chapter 36 Mise en Place Writing

36.1 Mise en Whatnow?

36.2 Writing isn’t Just Writing
36.3 Components of Pre-Writing
36.4 The Pre-Writing Workflow
36.5 The Infinite Kitchen
36.6 Writing
36.7 Improvisation is OK
36.8 Editing
Chapter 37 Side Projects

37.1 Why Side Projects?

37.2 Code-Life Balance
37.3 Project Ideas
37.4 Project Advice
37.5 Further Inspiration
Chapter 38 Developer’s Guide to Twitter

38.1 Getting Started

38.2 What Do YOU Want?
38.3 What I Want From Twitter
38.4 Your Twitter Feed
38.5 Join the Conversation
38.6 Being Helpful on the Internet
38.7 Twitter as a Second Brain
38.8 Dealing with Haters
38.9 Definitely Bad Ideas
38.10 Final thoughts
Chapter 39 Marketing Yourself (without Being a Celebrity)

39.1 When to Use This Tactic

39.2 Introduction
39.3 You Already Know What Good Personal Marketing Is
39.4 Personal Branding

39.4.1 Picking a Personal Brand

39.4.2 Personal Anecdote Time!
39.4.3 Anything But Average
39.4.4 Brand Templates
39.4.5 Brand Manifestation
39.4.6 Consistency

39.5 You Need a Domain

39.5.1 Planting Your Flag

39.5.2 Picking A Domain
39.5.3 Claiming Your Domain
39.5.4 Give Up Freedom — For Now
39.5.5 Blogging

39.6 Marketing Your Business Value vs Your Coding Skills

39.6.1 Business Value

39.6.2 Coding Skills
39.6.3 Portfolios vs Proof of Work

39.7 Marketing Yourself in Public

39.8 Marketing Yourself at Work
39.9 Things That DO NOT MATTER
39.10 Recap
39.11 Bonus: Marketing Hacks
Chapter 40 The Operating System of You

40.1 Your “Applications”

40.2 Coding Career Habits

40.2.1 Your “Firmware”

40.2.2 Your “External Devices”
40.2.3 Your “Scheduler”
40.2.4 Your “Kernel”
40.2.5 Recap

40.3 The Emotional Journey of your Coding Career

Chapter 1
Part I: Your Coding Career
Congrats on choosing a coding career! Demand for software engineers has never
been greater, and it can be a very rewarding and lucrative journey.

While there are many resources on how to code, from beginner to advanced,
there aren’t enough covering everything else. This book is dedicated to solving
that. It will give you principles, strategies, and tactics for the five stages of your
early coding career:

Code Newbie: Just learning to code - via a bootcamp, college, online

course, or self-teaching.
Job Hunter: Landing that first developer job!
Junior Developer: Surviving and thriving in your new job.
Junior to Senior: Getting promoted or hired as a Senior Developer.
Senior Developer: Growing into your own as a Senior in the industry.
and we will end with some insight into things people do Beyond their
Coding Career.

Note: we use “Developer” and “Engineer” interchangeably in this

book. Some studies suggest that you would make about 20% more
money with an “Engineer” title. I suggest that shallow minds fixate on
shallow causes. This book is not for shallow minds.

For most people, this covers the first 4-8 years of their career as a developer.
There are, of course, many titles and stages beyond that, but that is out of scope
for this book. Our primary objective is simply to give you as good a start as
possible, with the expectation that it will compound later into your journey.

We also focus on the coding career. The part of your career where you are
primarily expected to write code as an “Individual Contributor”. Sometimes,
coding careers end as developers move up into management, entrepreneurship,
and other “code-adjacent” roles (Chapter 7).

1.1 Principles over Titles

The first recommendation is that you don’t take titles too seriously.

Welcome to tech, where the roles are made up and titles don’t matter.
- Kelly Vaughn

Everyone is junior at some things, and senior at others. You don’t magically stop
needing to learn new things once you’re a Senior Developer, and even Code
Newbies can practice all of the tactics available to the professionals.

Which is why this is the only part of the book that is linear - offering point-in-
time advice for each career stage - while the rest of the book lets you skim and
jump and revisit it over the next X years of your coding career.

Titles do matter - mainly because that’s how salary and responsibility get
assigned. Companies establish career ladders with specific expectations you
must meet to reach each level (not always true, especially for early stage
startups). But the point remains that you ought to keep working on your
principles, strategies, and tactics throughout your entire coding career.

1.2 Company Types

As you progress from Code Newbie to Senior Developer, you will also have the
opportunity to explore careers with different types of company and employment
situations. It’s impossible to account for all the types that you might encounter,
but here’s a quick list together with some things you should know:
 Startups (Especially before Series C): You’ll have high autonomy and
responsibility, but get ready for things to change on a dime. It’s rare for
startup stock options to actually turn into a life-changing amount of money.
The career capital you’ll gain from doing great work at a high-growth
startup is more bankable. Process is minimal, which is either a pro or a con
depending on what you need to do your best work. Bootstrapped Startups
and Indie Hacking are increasingly popular alternatives to VC-backed
startups, emphasizing profitability over growth.
Agencies: You’ll learn a lot by working on a diversity of projects, often
with a handoff date. This affords you a lot of room for experimentation,
especially since many projects will be greenfield. You’ll gain experience
with project/client management, but sometimes at the cost of long hours
and high stress. Work can also be sensitive to economic cycles. Starting
pay can be very low (and rates differ a lot by country – see this agency
survey), until you start landing high-profile clients, winning industry
awards, and building a reputation that can get you 5x to 10x the average.
Freelancing and Consulting are similar to this, on an individual scale.
BigCos: You’ll have high pay and high impact (often impacting millions of
users). You’ll encounter unique problems that show up only at massive
scale. People often talk about FAANG, but of course there are thousands of
great tech employers that are no longer startups. Some BigCo/enterprise
tech work involves working with older technology, which is also why it
pays well. You’ll learn to evolve legacy code to clear technical debt, while
still maintaining a great experience for users throughout. BigCos can be
great for juniors as they offer more support and structure. Some people
thrive with the scale; others dread being a cog in the wheel.

Whenever you change jobs you will have a chance to jump between one of these
types of companies (of course, there are more types than I listed). It’s important
to learn what kind of environment you thrive in - finding your best fit is going
to be more rewarding for your career in the long-term than chasing pay or
prestige in the short-term.

Tip: See the Intro to Tech Strategy Chapter (Chapter 27) for a deeper
discussion of tech business models and how that translates to what you
work on.
1.3 Career Layers
The third dimension you will want to explore is where in the stack you want to
work.

Here we can explore a mental model inspired by the OSI Model. The OSI
Model provides a mental framework for how different technologies like HTTP,
TCP, IP, and 802.11 come together, each solving their assigned problems, and
(for the most part) seamlessly interoperating (with the help of some Narrow
Waists).

You can divvy up the universe of software jobs along the same lines. I always
think of how the value chain for humans is kind of similar to our underlying
tech. From the folks who write firmware that provides raw Hardware capability,
all the way up to End Users who create software with software, and all the
interesting software jobs in between.

So without further ado:

My focus here is on people who are primarily expected to code for their jobs. If
you’re a founder or a PM or a developer advocate, you might code every so
often, but during that time you’ll be acting in a coding role rather than doing it as
your main job.

Because I primarily work at the App layer, you may see some bias due to my
lack of knowledge. For example, there are other guides to careers in Data
Science and Cybersecurity. I’ve reviewed many and the advice in this book
represents what stuck.
Descriptively, I see the primary axis of software jobs as adding value from
Machines all the way to End Users:

At the lowest level, we have people who work with Hardware. They still
code, but their task is to design the chips, firmware, and operating systems
to expose raw Capability for us hungry, hungry software devs to eat up.
Then, we have the Cloud/Datacenter people, who are technically not
required but a practical reality these days. Their main job is Availability,
often with Distributed Systems, which also helps offer easy Scalability.
They basically fight CAP theorem for a living. Arguably you could view
them and other Cloud Distros as providing distributed “virtual hardware”
for the rest of us devs to run on.
Next, we have people who make Runtimes. This includes Browser Devs,
Language Designers, and Framework, Tooling, or Infrastructure Devs that
are basically responsible for all the Developer Experience we enjoy.

The three layers we just covered I call Platform development. They

don’t have anything specific to do with the Products that the next
three layers create, but they do make it all possible.

Backend developers create internal/private/non-user-facing Services that

encode the secure Business Logic of the apps. I’ve taken a rather
expansive definition here, including Machine Learning, Research, Process
Automation, Security, Compliance, and Billing. The idea is that UX isn’t
their focus - it’s more about the functionality.
Then, we have developers who work on Applications of all the prior
layers. This is everyone else who codes - from Game Devs to Plugin Devs,
to Sales/Support engineers and Mobile/Web Devs. They are uniquely
responsible for creating a great user experience.
Lastly, we have end users who create software with the software we give
them. End User Computing lets users create software, but without
traditional coding. This includes everyone else from Business Analysts
working in Excel to productivity geeks setting up #NoCode automation.

The assertion is that these jobs get more numerous as we get closer to users, who
are more diverse and therefore require more customization. Work is also
“further away from the metal.” When we code at higher layers, we’re
increasingly encouraged to pretend that the resource constraints of the below
layers don’t exist (for developer experience). This is, of course, a leaky
abstraction – but it works a lot of the time.

Some parts of the software industry are so self-contained that they don’t match
this model at all. For example, with gaming you’re often working with game AI,
procedural generation, physics engines, and massively multiplayer realtime
backends – none of which are common tasks in any other stack. At the end of
the day, software jobs appear whenever there is money to be made writing
software. And they don’t have to conform to any layer model – think of this as
an illustration rather than a precise map.

1.4 Diversity
Often the only people who ignore diversity issues in a career discussion are
cishet white men. For everyone else, it colors every job, every interaction, every
moment of self-doubt. Regardless of your political persuasion, you should
recognize that tech objectively does a worse job at diversity than any other well
paid white collar industry. This isn’t mere perception – it is greatly statistically
significant by any measure.
Today only 17% of Computer Science majors are women. We do worse than
medicine, law, and the hard sciences! This effect worsens once you get into the
industry - industry surveys of programmers regularly come in around 8-12%
non-male. This means there is 40% average attrition of non-male coders
relative to male ones, which is indicative of problems in the industry and a
problem in itself for diversity in senior ranks. You will see this happen in your
own career journey.

It wasn’t always like this. You can see in the chart we used to have twice as
many women in the college pipeline in the 1980’s. The first professional
programmers in the 1940s were female. The first compiler was created by Rear
Admiral Grace Hopper. Before Charles Babbage’s Analytical Engine even
existed, Ada Lovelace was programming for it.
Programming ability isn’t limited by gender or race or sexual orientation or age.
It is far more likely to be human factors – the non-code parts of coding careers –
that systematically alienate our fellow humans from this lucrative, powerful
field.

If you are not part of the underrepresented minority in tech, have the compassion
and empathy to recognize that this problem is an inescapable fact of life for
those who are. First, do no harm: Recognize when you are contributing to the
problem and stop. Then be an ally by calling it out in others and lending your
privilege.

If you are part of the underrepresented minority, know that you are desperately
needed and if your current company doesn’t value you, there are lots of other
inclusive companies that would love to work with you. There are also extensive
support networks by your peers, from dedicated industry groups like Women in
Games International to language groups like PyLadies to framework groups like
Front-End Foxes to more generalist networking and mentorship groups like
BlacksInTechnology, Latina Geeks, and Lesbians Who Tech. You can even find
others with the same background as you like MotherCoders and VetsinTech.
These aren’t mere toothless social groups – before you join a company or
collaborate with someone, it can be very helpful to do a quick reference check,
or you might hear about a perfect job opportunity before anyone else because the
hiring manager values reaching out to communities like yours, or you can just
ask for help from people who’ve been in your exact shoes.

Tech’s diversity problem is the world’s diversity problem. Because so much of

our world is now run and intermediated by software, it is increasingly important
that the people who design and code that software have a visceral empathy with
their users. It starts with making sure representative voices are heard.

1.5 The Five Career Stages

So now that we know about company types, career layers, diversity, and not to
take titles too seriously… Let’s talk about titles.
Here I will introduce you to each of the stages we target in this book. I will offer
tips on things you can try, and bold Principles, Strategies and Tactics that you
should check out depending on which stage you are at.

Code Newbies (Chapter 2)

Job Hunt (Chapter 3)
Junior Dev (Chapter 4)
Junior to Senior (Chapter 5)
Senior Dev (Chapter 6)
Beyond your Coding Career (Chapter 7)
Chapter 2
Code Newbies
As a Code Newbie, your chief job is building your raw skills. You can be
taking a college course, or a paid course online, or a paid bootcamp (like I did),
or using great free resources like FreeCodeCamp, FrontendMasters, TreeHouse,
The Odin Project, Codecademy, or the “University of YouTube” (like I also did).

Coding careers are very diverse; you don’t have to do web development, there
are other career paths like Data Science, Cybersecurity, Cloud, Dev Ops or
Mobile Dev. That said, web development is by far the most popular, and you’ll
probably have to learn a bit of it no matter what you do.

The primary artifact you will produce is your portfolio, or as I call it in the
Marketing Yourself chapter (Chapter 39), “Proof of Work” (which can include
a blog). You basically want to demonstrate passion and engagement with your
chosen skill, and Build Cool Shit.

But there’s a lot else you can do on your way there:

Learn the Lingo: You are the average of the five people you spend the
most time with - so spend your time with other developers by plugging into
talks and podcasts! I keep a list of awesome developer podcasts you can
use, or of course you can find your own. Don’t like podcasts? Be a fly on
the wall on Twitter! You can watch senior devs talk amongst themselves
for free, and catch up by googling and asking for clarifications. This will
serve you well in interviews too - talking the talk helps you walk the walk.
Laurie Barth calls this Talk like an Engineer! Immersion is great but be
careful not to confuse surface familiarity of things with real knowledge of
them - this is just step 1 on a long journey toward mastery.
Make up Levels for Yourself: When you are learning on your own
(especially after your formal learning phase), it can feel a little directionless
since there is an infinite number of things you could be learning. The
counter for this is gamifying learning - when I was learning JavaScript, I
set goals for myself to make a clone of jQuery, then to get good with React
and Redux, then to be able to make a Hacker News clone. You can do the
same for whatever you’re focusing on! Some learning platforms even
award you points and trophies for completing challenges and streaks. Yes,
it’s a little corny. But lean into it!
Explore Paid Learning: Because there is so much free content available, it
can be tempting to learn entirely free. However, in my experience, the level
of curation and quality of paid content is just so much better that it is worth
it. If you can afford it, look into the (reputable!) paid learning courses in
your community. For example Egghead, Frontend Masters, Codecademy,
ACloudGuru and Pluralsight. As for Udemy - just be aware that Udemy
has a very mixed reputation. Stick to the top most reviewed instructors.
Make a Public Commitment: Having a public commitment helps you
build your own team of cheerleaders and community. This helps give you
the feedback you need to not feel alone in your journey, and it forces you to
keep going when you might otherwise have given up on yourself.
Alexander Kallaway’s 100 Days of Code is a popular commitment, while
No Zero Days is what worked for me. If you’re uncomfortable in public,
you can also keep a private learning journal – anything outside yourself
works, so long as it keeps you accountable.
Find a Community: You don’t have to make commitments to get
community - CodeNewbies, FreeCodeCamp, DEV, CareerKarma and
CodingBlocks are great, welcoming communities that keep you company as
you learn. A bootcamp can be a great community, and you can even find
free meetups like Codebar to learn in person, or virtual mentors via Emma
Bostian’s CodingCoach. If you belong to an underrepresented minority in
tech, don’t forget that there are communities and organizations formed
specifically to help people like you, often with local chapters that can give
you the mentors and friends you need to find your place in tech (yes, you
belong here, and don’t let anyone tell you otherwise).
Teach To Learn: If you can find a group of peers, pick a topic and offer to
teach it to them. You only find out all the things you didn’t know about a
topic when you start preparing to teach it, and then have to answer all the
questions you didn’t think to ask. I did this very early on with React, and it
was stressful but highly beneficial for me!
Cover Your Bases: Developer jobs aren’t 100% about coding new features
all the time. Some might say they’re not even about coding the majority of
 the time! There are a lot of coding-adjacent things that developers do that
you’ll want to learn about. You should be familiar with (or at least have an
opinion on) everything in the Joel test, which includes source control, code
review, and testing. Have some familiarity with the Testing Trophy or
Testing Honeycomb and understand how to implement it in your language’s
tools. While asking “What happens when you type Google.com into the
browser?” is now a little dated, you should still know it in some detail
because it demonstrates that you know how the Internet works. This
“metacoding” skillset is so important that MIT has even started teaching
this as “the Missing Semester.” In JavaScript, for example, you’ll want to
have some basic familiarity with tools like Webpack, ESLint, PostCSS, and
Prettier. While you’re mostly learning to code by yourself, most developers
work in teams. One way to gain “team” experience for free is to contribute
to open source!
Start Contributing to Open Source: Many open source projects are very
beginner friendly, and you don’t even have to start off contributing code. In
fact, it may not be the best idea to start by contributing code to large
projects like Node or React, despite the bragging rights that might entail. It
might be better to start with a smaller library you use, or to help improve
docs. This gets you involved with the basic mechanics of open source
without needing you to catch up on a lot of context you may be missing.
Since most open source projects are in dire need of good contributors,
you’ll be welcomed with open arms if you show a positive attitude and an
understanding of what they’re looking for. Check out First Timers Only for
projects that specifically reserve issues for first timers!

There are a lot of roadmaps like these that people write to chart out what’s
available, but they can often feed impostor syndrome more than help.
Remember that very few technologies are actually mandatory, and even the
authors of the roadmaps don’t know everything they list on them. They’re just
maps; you don’t have to visit every point on them.

If you are self-teaching, some folks take the “hard” mode and insist on covering
a full computer science curriculum. You can find good paths for these at
TeachYourSelfCS, Open Source Society University and Scott Young’s MIT
Challenge. However, note that this covers a lot of theory that is rarely (if at all)
used on the job for the majority of product developers (If you recall our Coding
Career Layers from Chapter 1, we distinguish between product and platform
developers. It stands to reason that different developer types require different
knowledge!). You do have the choice to get a great developer job without
knowing a lot of academic computer science knowledge, and then fill in your
gaps while you work.

If you’re stressed out by the sheer number of technologies you feel like you have
to learn, you’re not alone. For frontend developers, there’s How it feels to learn
JavaScript, while backend developers have Docker: It’s the Future. Every now
and then you’ll read something in the Why we at $FAMOUS_COMPANY
Switched to $HYPED_TECHNOLOGY genre and feel the fear of missing out.
This is completely normal. It’s good to stay informed, but when it comes to
learning, focus on what you need to make the things you want to make, and to
get the jobs you want.
Chapter 3
The (First) Job Hunt
There are plenty of advice articles (and workshops) out there about landing your
first developer job. I don’t want to repeat them - you can easily google an
endless supply of them for free. But I also cannot ignore that this is the most
critical part of your initial journey.

If I don’t help you get past this stage, there is no coding career!

So I’ll assume you’ve read the common advice out there. My task is tell you
what they don’t.

In general, you should focus on systems (what you are doing to get the job)
rather than goals (getting the job). The former is within your control, the latter is
not. By overly focusing on goals, you might get a developer job, but it may be
the wrong job for you.

3.1 Do the Math

Recognize that the job search is highly random. There really is not that much
separating you from an average Google programmer - as Steve Yegge has noted,
there is a very high false negative rate at interviews at BigCos, mainly because
we are just very bad at interviewing.

But the great thing about jobs is you only need one.

The probability of getting 1 job is higher if you apply to more things. I know
this sounds obvious but when you get discouraged (and I have felt it - in my
initial job search, I spent a whole week not doing any applications because I
didn’t feel motivated) you have to remember to Keep. Things. Moving.
The common framing of this is that it’s a “numbers game”. But people don’t
quantify how much just doing more applications does for you - this is actually an
applied form of Birthday Problem, which is GREAT for you!

If I told you that you have a 4% chance of getting an offer from any
application, that might seem dishearteningly low. But mathematically
that means that 50 such applications will give you an 87% chance of
getting at least one job offer. - Haseeb Qureshi

3.2 Do the Work

However spamming 50 applications a week is also not great. Beyond the
demotivating, soul sucking aspect of this, blindly taking the first job that comes
along can be harmful. Your first dev job will help you build expertise and
reputation for your next job. If you end up hating your first job you may find it a
lot harder to get onto a different career track. This is called path dependence – if
you’re trying to change careers, you have likely already felt this pain.

Instead, try to figure out the intersection of what you like, what you can be good
at, and what the world values (Preferably, the world is -increasingly- valuing this
thing so you have a tailwind behind you - see the Strategy section of this book).
You are most likely to get hired, be valued, and love your work when you find
the company(ies) that closest match those three things.

The obvious problem with this generic advice when you have no experience is:
you don’t really know what you like or are good at.

So: Talk.

Talk to alums of your school or bootcamp. Talk to friends. Ask for intros, then
Talk to friends of friends. Ask for more intros, then Talk to friends of friends of
friends. Talk to people at meetups and coffee chats. Listen to podcasts (here is a
list of awesome dev podcasts). Chat on Reddit, Slack communities, Twitter.
THIS is why you network. Not with the sole intention of “Hey can you put me
in as a referral if I buy you a coffee?”. Rather, you truly want to find out what
people really do, what people think of the industry and their company, and where
in the Coding Career Layers you could fit. People like to talk about
themselves. Don’t ask for a job, or a referral (unless they bring it up) - if you are
genuinely curious they’ll bring it up themselves and it will be their idea.

Your goal is to have fewer companies to apply to, but to have REALLY
FREAKING GOOD reasons for each company because you’ve done your
homework. This way, when you are asked “Why do you want the job?”, you
have a reason. (Lacking a good answer for this has ended presidential
campaigns in the past!) When you need to write a cover letter, the words flow
from you instead of being forced. When you meet your interviewer (and future
boss) face to face, you won’t need to fake interest.

To give you my personal math, in my initial job search I only applied to nine
companies, got to final interviews at three, got two offers, and took the highest
one. Others applied between 200 to 300 times! Everyone’s story is different,
though, you will have to decide what strategy fits you.

3.3 Staying Motivated While You

Search
Use social pressure to keep you motivated even when you lose motivation. Do a
weekly standup with a small group of friends. Go around and say what you did
that week and what results you’ve had, then your plans for next week. Humans
are social animals. Exploit your instinct to live up to what you said you would
do by saying what you will do to people you like. Bonus if they’re going
through the same thing at the same time.

Listening to podcast interviews of how people broke into tech can be hugely
motivational. It helps you realize there are thousands of people going through
what you are going through right now. The backlogs of CodeNewbie,
FreeCodeCamp and Breaking Into Startups podcasts were particularly helpful
for me going through this journey.
Time Splits are important. You don’t need to spend 100% of your job hunt
literally hunting for jobs. Here’s a quick breakdown of what worked for me:

2-3 hours of Algorithm practice (arguably, algo questions are going away
for job screens, but at some companies they are a rite of passage and you
don’t want to lose a great opportunity just because you didn’t cover your
bases)
1-2 hours of Job Opp finding and emailing. There are two main sources
of job opportunities – either you find something on a job board, or you hear
about an opportunity from your personal and social network. Many sites
have Job Boards, from Hacker News to CodePen to StackOverflow. If you
belong to an underrepresented minority, don’t forget dedicated boards like
POCIT Jobs, Include.io, Wallbreakers, Ada’s List, Hire Tech Ladies,
Diversify Tech Co, YSYS, and Tech Talent Charter. Put everything into a
tracker like Asana or Trello. Keep juggling those balls. Don’t rely on your
own memory for deadlines. Track them, set alerts.
2-3 hours of structured learning - e.g. through video courses or reading
technical books from cover to cover.
Rest of your time: Build a Side Project. Set a reasonable deadline (1 week
or 1 month) and then just build your idea as best as you can by that
deadline. Resist the urge to perfect it. Just get it to launch, then get
feedback. Build fun stuff, or explorations, or clones (see Chapter 10 for
why Cloning Open Source Apps is a great way to learn). Still don’t know
what to build? Try JavaScript 30 or Just-Build-Websites. We discuss side
projects in greater detail in Chapter 37.
Optionally, Teach. Livestream yourself on Twitch or do a meetup talk. In
particular, try to get practice talking while you code. This is great practice
for technical interviews.

3.4 Getting the Interview

Recruiters. Recruitment agencies vary wildly in quality, and their usefulness
varies from location to location. Keep in mind that you are a product to them –
their business model is to throw as many viable bodies at their client as
acceptable in the hope one sticks. If they have a special deal to source
candidates for an employer, this might be a good thing, but often you will have
recruiters that do cold pitches with you as the material. In some locations, tech
recruiters are the norm for how you land your first job. In others, they are total
wastes of time. Ask around to figure out how your local tech scene works.

Portfolios. You don’t need an all singing, all dancing portfolio page. You don’t
need a verdant green commit history. People barely look at that. They don’t
have time. You just have to demonstrate that you’ve Done Cool Shit and,
optionally, Covered Your Bases. If your work is less visual in nature, just have
an active blog. It’s more about instantly verifiable Proof of Work. (More in
Marketing Yourself, Chapter 39) One exception - Design/UX positions strongly
benefit from great portfolios.

For folks worried about their contributions… No one cares! You can
impress most hiring managers with only 3 contribs: 1) Something
simple, built flawlessly. Seriously. Like 1 class, or a single js file. 2)
Something complete. A small app / site / lib. Tests. Docs. 3)
Something with a story (my fave!) Could be a single line of code. -
Mekka Okereke

Resumes. You do need to be able to talk well about whatever you put on your
resume so make sure that everything on there is legit. Keep it one page, use this
template for ideas. Use Canva Resume templates to make it visually interesting.
For whatever reason, interviewers often print out your resume and bring it to the
interview and then stare at it instead of talking to you like a normal human
being. Have 2–3 different versions of your resume prepared to tell the story that
you want to tell. Ditto your cold email draft, or self intro, or cover letter. Learn
from modern internet advertising: MORE TARGETING IS ALWAYS GOOD.

Cover Letters. A cover letter shows that you know what the job is about and
have taken the time to personalize your pitch. A good cover letter makes
reviewers sit up and pay attention – sometimes this calls for creative measures.
Cover letters can be componentized:

Write three different forms of self introduction

Write a middle part that directly responds to line items in the job ad
 Write a few boilerplatey endings
Play mix and match for each company, matching tone and relevance of your
background to the job in question.

If you find yourself writing too many custom cover letters, this is a hint that you
may be casting your net too wide and you may not be very sure what you want.
(It’s also exhausting!)

Industry Certifications. The harder it is to get a certification, the more

valuable it is. Kelsey Hightower attributes his big break to the CompTIA A+
certification, which takes at least a year of study/experience. Cisco’s CCNA
takes a month and is well recognized for sysadmin/network engineers. The
Cybersecurity field has equivalent certifications with CompTIA, EC-Council
and GSEC. The AWS Cloud Practitioner certificate takes up to two months, but
it is enough for people to recommend you based on it. It demonstrates
dedication, and serves as a talking point and understood base of knowledge.
Note that no equivalent certificate exists for frontend development.

Networking. Don’t be shy – Everybody should know that you are job hunting!
Friends LOVE helping their friends get jobs! Especially if drinks are on you.
Head to meetups and conferences – you might run into someone who can give
you a referral, or even hiring managers who specifically go to these events to
find people like you! Put the fact that you are looking on your site, LinkedIn,
and Twitter bio. In particular, people are very supportive on Twitter, and I’ve
seen junior developers get jobs with a single “I’m Looking! Here’s What I Do!”
tweet. Use what already works and have a good tweet-sized pitch of yourself –
see threads like this for inspiration. Social Media can be great for introverts,
because you don’t need to rely on face-to-face realtime conversation to start your
jobseeking.

For my first job I applied to two jobs, and got one offer. The one I got
the offer for I had a recommendation straight to the CEO from a friend
as well as connections with several employees over twitter, and I made
a custom website for that company specifically for them, as well as a
video of a skateboarding guinea pig. It was enough to stand out and
get me to the top of the interview list. - Jeff Escalante
Mock Interviews. You can get over a lot of nerves by just having a few friends
(or a professional) put you through some mock interviews. You can even find
some videos and podcasts that coach you through a mock interview. Remember
that they’re not merely assessing whether you can come up with the right
solution, they’re also looking for your communication skills, eagerness to learn,
and problem solving process. Some hiring managers are so open that you can
even find out the kind of questions they like to ask, based on their own tweets
and media appearances. Research them and practice answering them.

3.5 Types of Interviews

System Design Interviews. You won’t get a ton of this as a junior, and
especially not for frontend roles. But it will still be rewarding to read through
HiredInTech’s guide, High Scalability’s top posts and checking out the System
Design repo. You’re more likely to actually need this information when you get
to a Senior level.

Algorithms. You don’t have to be an Algorithms God, but you should know the
basics - have passing familiarity with the main ideas in Gayle McDowell’s
Cracking the Coding Interview or Emma Bostian’s De-Coding the Technical
Interview Process, memorize and be able to derive the Big O’s of sorting
algorithms, and so on. Even a Google technical interview is at most 45 minutes
of coding; that is not enough time to write a self-balancing red-black tree, and
barely enough to code up a heap sort from scratch. Just know the basics - Byte
by Byte’s list of 50 Questions is indicative of the difficulty level of algorithm
questions. Paid sites like Leetcode and Algoexpert can help you practice.

“Pro tip: Interviewers generally want you to succeed, so they will

often give hints. Use their hints. Failure to come up with some
insight during a coding interview isn’t always a dealbreaker. But
ignoring an intentional tip or having poor communication skills
usually is.” - Dan Abramov
Algorithm Interviews make the most sense for people doing “low level” or
“systems” programming. Data engineering and game development in particular
have a strong focus on graph algorithms, whereas operating system and
framework developers might need to be more familiar with data structures and
dynamic programming. However, the higher up in the Coding Career Layers
you are, the less algorithm interviews matter, because you are less CPU or
memory constrained. For most App developers, the failure of algorithm
interviews to match actual work settings is well known. So Technical Interviews
have broadened a lot to assess other forms of technical knowledge.

Technical Interviews. This topic is well covered by others, and is very domain
specific, so is out of scope for this book, but definitely check out the Mega
Interview Guide and Coding Interview University. But the broad adage of
“Make it work, make it right, and make it fast” applies.

As you tackle the problem, it’s important to explain your thinking process. A
detailed framework you can use is the REACTO model:

Repeat the question

Come up with Examples
Outline your Approach
Code your solution
Test your Code (manually run through it if on a whiteboard)
Then, and only then, Optimize.

If you have a running environment to code in, then it may be a good idea to do
Test Driven Development for your code (flip the Testing and Coding stage). I
once specifically got an offer because I chose to do TDD while trying to
understand the question (it wasn’t a conscious decision!).

Blind Interviews. A lot of unconscious bias happens in interviewing. It’s an

unfair reality. You can’t help how you look or who you are or how they adjust
for their own biases, but just know that blind interviews exist that help mitigate
that injustice. Interviewing.io, Byteboard and Pramp even let you do practice
interviews anonymously and actually get hired from there.

Take-Home Projects. You can consider these as “enhanced technical

interviewing”. They are wonderful for the new developer. I have had two job
offers based off of successful take home projects. There is a lot of freedom in
how you complete these:

You can choose to go all out and risk being messy, showing how you would
work in a real project (including architecting for scale, as well as including
other niceties that they didn’t ask for, but would in real life), with a risk of
failure.
Or you could do a minimal, super clean project that just checks all the
required user stories and nothing more, and just make it extremely well
documented and tested.

The judgment call relies on what they are really hiring you to do. I usually go
for the risky option because it fits the jobs I seek. Note that Take-Home Projects
typically take between 4 hours to 2 days - any longer and the company should be
paying you.

Overcommunicate. Comment freely in your code, and in general, find ways to

demonstrate that you can communicate well. In one of my take home projects,
they set up a Slack channel to discuss my work with me and I just constantly
spammed my channel with status updates as I did the project. They loved
interacting with me through that and gave me the offer.

Non-technical/Fit Interviews. Arrive early. Think of the most confident person

you know and channel them just for this interview. You are on a stage. You are
not just interviewing for a role, you are playing a role. Smile. Keep eye contact.
All the advice from How to Win Friends and Influence People works here. Have
your self-intro rehearsed and in under a minute. Try to research your
interviewers beforehand. Get them to talk (Most people love talking about
themselves, and find themselves liking you more, the more they talk).

Reverse Interviews. If someone asks if you have any questions, ask a question.
This is known as a “reverse interview”. The most famous of this was the Joel
test, which is a little outdated today. You can consider this updated list instead.
Asking good questions about company culture can both make you look good
(you are serious about the job, and also know how to ask good questions) and
also help you make your final decision. So it makes sense to prepare these
questions beforehand!
 “Convince me how you can help me, and you get into a special
shortlist that almost nobody gets into.” - Daniel Vassallo

3.6 Outside the Interview

Contract Jobs. While you are waiting to land a full-time job, you can also pick
up some contract jobs to get some practice coding for money. A lot of people
got their start doing projects for friends or relatives - a site for an aunt here, an
app for the local cafe there - all of it becomes relevant experience for your
resume. There are also sites that connect you to short term jobs, like Upwork or
Toptal, but you may have a tougher go of it as a newer programmer.

Apprenticeships. Some more well known companies actively run internship

and apprenticeship programs, including programs for people from nontraditional
backgrounds. Treehouse offers apprenticeships with name-brand employers like
Airbnb and Nike. If you are eligible for college in Canada, apply for
Shopify’s Dev Degree program. Major League Hacking does fellowships with
GitHub, AWS, Facebook, and more. Many people have landed a 1 year Google
Brain fellowship after spending a year going through Fast.ai. For
underrepresented populations in tech, organizations like Outreachy,
CodePlatoon, and Code2040 can help directly. Indians have Internshala.

Open Source. The bar for getting involved in open source is hilariously low
compared to getting hired at companies that depend on the same open source.
“Open Source Hiring” is mostly just a matter of who consistently shows up. You
can quite easily become a maintainer of a core ecosystem project with a few
months of diligent contributions. This then becomes an impressive resume point
at every company that uses that project.

“Contributing meaningfully to a open source thing we use = instant

interview! That’s obviously not the only way to display value, but it’s
one of the great ones to demonstrate: aptitude in our tech, ability to
 communicate & work well with others, and love of open source!” -
Josh Goldberg

Get your foot in the door: If after all you’ve tried, you’re still not getting
anywhere, remember that you have other skills to offer apart from your coding.
It is much better to spend a year working in a tech-adjacent, nontechnical job,
then internally transfer into a technical role, than it is to spend a year sending out
resumes and getting doors slammed in your face. Plenty of companies want to
hire smart, motivated, technical people for support, documentation, project
manager, and sales support roles. Look to organizations like Digital Project
Masters, Write the Docs, and Support Drive for answers. Warning: I am not
suggesting that you should expect to waltz in. These are specialized roles and
you will have to compete with trained professionals doing these jobs. However,
your coding ability should be a plus in landing these roles.

Once you’re in, nobody will object to you doing a little extra coding on the side -
there are always some issues to pick up, always some internal tooling that could
be better. Great companies will even see the value in paying to help train you.
You can become a professional developer by sheer force of will.

You can find many of these examples of High Agency outside of tech:

Sidney Weinberg started at Goldman Sachs as a janitor’s assistant before

getting a break as a trader and rising to CEO.
Helen Gurley Brown started as a secretary at an ad agency before her
writing skills took her all the way to editor-in-chief of Cosmopolitan.
Simon Cowell started in the literal mailroom of EMI Records before
becoming the face of American Idol.

All of them started somewhere. The same is true for you. If they aren’t letting
you in the front door, go round the back.

Once the offers start coming in, you’re almost done! In my opinion, negotiation
isn’t that important at this stage. You’re trying to optimize for the employer
that will help you grow the most, not get the highest amount of money in the
short term. You can get your millions later. It’s not unheard of, but you’d be
hard pressed to instigate a bidding war over you for your first job. Just make
sure that you know your worth and get at least your market rate (see
Negotiation, Chapter 31), and don’t be afraid to ask for the things you really
need, within reason.
Chapter 4
Junior Developer
First, welcome to your new life! Ask questions! Find a work buddy
with whom you feel comfortable asking any tech question. Never let
anyone make you feel bad asking a question - there are no dumb
questions. Ask a lot. Draw diagrams. Read code. Reassert your
assumptions. Breathe. — Scott Hanselman

Barring toxic workplaces, most employers who knowingly hire junior or entry-
level developers know what they’re signing up for - giving you all the training
and support you need to succeed in your new job! In fact, a (rare) few
employers actually prefer hiring juniors, because they come without
preconceived notions and are moldable to their methodology.

4.1 Finding Your Groove

Your job as a junior developer is to build competence and ability to execute.
It’s more important that you ask good questions than that you always have
answers. Over time, you will learn to have an informed opinion that your
employers rely on.

This is your time to not know anything. Better you ask now than a year from
now. Say “I don’t know” or “Can you elaborate what you mean?” frequently.
Take “My door is open” literally. Indulge your curiosity. Ask questions the
smart way. They have to teach you - in fact, some senior developers are
evaluated on their ability to explain things simply, and to mentor juniors. Return
the favor by taking lessons to heart.
 See Lampshading (Chapter 34) for more tips on how to turn
Ignorance to Power!

A powerful and subtle way of asking for help is asking to pair program with your
mentors and peers. It may feel awkward at first, but there are always subtle tips
and tricks to pick up from closely watching how your coworkers solve problems,
and they can understand where you make mistakes and give more context than
normally available in a code review. Knowledge transfer by osmosis is
incredibly powerful and productive. This practice is so beneficial that some
companies (like Pivotal) have adopted the policy of always pair programming -
as part of an Extreme Programming practice. The top two engineers at Google -
Jeff Dean and Sanjay Ghemawat - paired all the way from their time at DEC to
creating MapReduce and TensorFlow. You don’t have to go that far, but in
general most junior developers benefit tremendously from “pairing” with
colleagues, and you should request pair sessions if your company doesn’t yet
make it a norm.

Once you have a good sense of how your coworkers think and work, you can
actually just start “emulating” them in your head. When approaching a task, you
can ask, “What would $COWORKER do?” At a prior job, we had a great code
review feedback grading system, but I found that we could even reduce the
latency of code reviews by pre-emptively reviewing my own code with concerns
that coworkers were likely to raise. If your team wants more ideas for effective
code review, Google’s Code Review guidelines are public. As you gain more
experience, you should also review your old work and think about how you
can comment, document, and design your code better for your own future
readability and extensibility.

Work on your problem solving skills, and understand that we all have
struggled like you are right now. Take some time to learn how to use a
debugger. Debuggers are quite beneficial when navigating new, undocumented
or poorly documented codebases, or to debug weird issues. Do not give up if
Stack Overflow or an issue on GitHub doesn’t have an answer. Sometimes all
you need to solve your problem is taking a short break or trying to explain it to a
rubber duck!
Understand how to help them help you. Saying “I am stuck, but I have tried
X, Y, and Z. Do you have any pointers?” to your lead is much better than saying
“This is beyond me.” When writing up an issue or bug report, help them help
you by writing a good title, providing key details upfront, including error
messages and environment/package versions without asking, providing a
minimal reproduction of your issue, and explaining what you’ve tried and what
you expected. If screenshots speak a thousand words, then recording gifs and
quick explainer videos can speak volumes. See StackOverflow’s guide on “How
do I ask a good question?” for more.

A few developers fall prey to the opposite problem - instead of lacking

confidence, they assume too much confidence. The Dunning-Kruger effect is
real - remember that you don’t know what you don’t know. It’s easy to come in
and feel like everyone before you were idiots, everything is unacceptable
technical debt, and you know how to fix everything in theory. Chesterton’s
Fence reminds us that when confronting things we don’t understand, we should
understand the reasoning behind them first. Don’t fall in love with your code,
don’t fall in love with your solutions. You might read Clean Code and want to
apply it to everything, only to find that it’s not helpful in the real world.

You will have to learn a lot from your senior colleagues, while at the same time
understanding that they can be wrong too. I once had a boss tell me “React is
object oriented because it uses classes” and realized how poorly he understood
React. You will need to develop the judgement, understanding, and persuasive
skill to navigate these confusing early days.

4.2 Making Mistakes

You will screw up, royally. It’s a matter of when, not if. It’s okay. You’ll
survive. We have all been there.

It’s not your job to never make mistakes. It’s the job of your seniors and
managers to ensure that both you and the company can recover from any
mistakes you make. One Junior Software Developer accidentally destroyed
their company’s production database on the first day of the job, and was told
by the CTO that there would be legal implications. Read the story and all the
replies from people who have caused similar incidents. They lived to tell the
tale.

A non-exhaustive list of mistakes that senior developers have made:

Instagram DDOSed itself on the day of its launch because they forgot a
favicon
Someone at Pixar ran rm -rf on Toy Story 2 and deleted 90% of the
movie (2 years and $100m worth of work)
Pentest against production at a bank faking $5M overnight against customer
instructions
Accidentally taking the iPhone off the Apple Online Store
Literally kicked all of Sierra Leone off the Internet during Ebola
Accidentally deleting the database while teaching someone how not to
accidentally delete the database
Mistakenly emailing 15k users every minute for 2 hours, then repeating the
mistake with the apology email
Every person saving their profile got it deleted instead
Word processor that formatted the hard drive every 1024 saves
Went to the wrong building, took down the network of completely unrelated
company
Steam, Windows, and iTunes deleted all user data.

It’s okay. You’ll survive.

“To err is human; to really foul things up requires a computer.” - Bill

Vaughan

4.3 Adding Value

As long as you’ve got your basic responsibilities down, you’re going to want to
say yes to whatever comes your way. If you bite off more than you can chew, it
is your manager/team’s responsibility to help you out, or to step in if things are
going south. At the same time, make sure you do good work with the stuff you
have committed to. Your personal brand is ultimately the work that you do.

You might feel intimidated at doing things beyond your comfort zone, but you’re
going to have to get good at it to grow. Fight impostor syndrome by saying
“This is what I do”.

Try to be a work sink instead of a work generator. Proactively ask managers and
product owners what you can take off their plate. Your job is to support them:
when they look good, you look good. Ryan Holiday calls this the Canvas
Strategy – Harry Truman puts it more pithily: “It is amazing what you can
accomplish if you do not care who gets the credit.” Of course, if you feel you are
being exploited, stop.

If you just wait around when you run out of things to do, you look lazy and
unmotivated. Show initiative - there are always more things to do.

It is quite often that doing the things nobody else wants to do often ends up
making you indispensable, because A) it has to be done and B) nobody else
wants to do them. If you figure out a clever way of doing it, you could even
make a career (or startup) out of it!

Important caveat: Don’t let people take advantage of you. Pick your
projects strategically if you can (see the Strategy section), and when
you have wins, Market Yourself internally and externally.

Tests are the most common example of this. In fact, a really great way to start a
new job is to volunteer to write tests:

There are never enough tests. There’s always something more to test, or
tests can be faster, or you can remove/replace unhelpful tests.
Coworkers will be grateful. Tests aren’t user facing, so they are often the
place corners get cut, yet everyone understands the value of testing.
Learn the codebase. To test the code, you’ll have to understand where to
test the code. It’s an art, not a science - If you blanket the codebase in unit
tests, you’ll have a lot of superficial code coverage, but also a lot to refactor
 when any minor detail is changed, while also duplicating a lot of
framework tests. The prevailing advice is to “Write tests. Not too many.
Mostly integration.”, after the famous Michael Pollan quote.
You can’t break anything - in fact quite the opposite - tests make code
more resilient!
You will learn things you didn’t know about how your product works.
When you interact with the product, you only see what a user like you sees.
When you look at the code, you will see all the edge cases that are
addressed, and the ugly, hacky code that made it happen!

People have used this strategy at Netflix, Ionic, PayTM and more to get great
starts at their companies, and you should too.

Your code only has value in the context of the business you work in. Understand
the product end-to-end as an end-user. Do not assume things, ask questions and
get things cleared when in doubt.

Ask for what you want. As you gain better knowledge of your company’s
strategic priorities, complemented by better self knowledge of what you prefer
and excel in, you can start to go from reactive to proactive in your project
choice. The job you have right now doesn’t have to be the career you end up
with, and it is much easier to switch focuses internally than as a job seeker.
Actively seek out cross functional exposure to understand how other developers
in your company work, and put yourself in the path of key projects that will have
major impact at your company. Here are some other career development
prompts you can use in 1-on-1’s with your manager.

4.4 Growing Your Knowledge

You don’t stop learning just because you’ve landed your first job. You should
continue with all the learning you did before but never finished! Now that you
have some financial stability, you have the luxury of time to fill in gaps in your
knowledge:

Read technical books cover to cover. In a world of tweets and content-light

blogposts, books are an oasis of expertise in the desert of serious technical
 discussion. Beware the “Tutorial Trap” - endlessly going through tutorial
after tutorial. Go deep on a few important things. If you feel like you want
to patch some holes in your CS knowledge, get The Imposter’s Handbook,
which covers everything from Compilers to Lambda Calculus, or check out
TeachYourselfCS.
Read framework/library source code. You can learn a lot by comparing
experts’ code to yours - look for the intentional differences from what is
normally taught in tutorials, and ask why they exist.
Learn more languages/frameworks. Exposure therapy works when learning
to Bet on Technologies! (Chapter 24)
Learn the intellectual history of all the tools you use - what existed before?
What led to their creation? Who created them? What are they doing now?
Know Your Tools (Chapter 11).
In fact, start following People over Projects. Trace their past and their
mentors. What are they working on today? Pick up what they put down
(Chapter 19).
Continue building Useful Side Projects (Chapter 37).

Don’t memorize everything and trust that you can keep everything in your head.
Start making cheatsheets and repos and blogposts to Open Source your
Knowledge (Chapter 13).

You really only know when you have learned anything when you can teach
what you learn. In the process of writing and speaking, you will discover things
you thought you knew but really didn’t, but also assemble a concentrated useful
resource of everything you know about a particular topic, that you can (and
will!) pull up in future.

Ways to teach what you learn:

Do talks. At work, at meetups, to your family, to your dog, to yourself on

your own YouTube channel. I don’t care that you’re an introvert. So am I.
So are 90% of developers (I don’t know the real number, it’s a lot). Do you
think you can get away from public speaking about technology for the rest
of your career? Do you think it will ever get easier? Do you think you will
learn faster if you just keep to yourself all day? Do talks. Speaking forces
you to have skin in the game. Any embarrassment that results is only
temporary - in fact it will drive you to be better. Worried that your talk will
 suck? Don’t worry - it will! Everyone has some amount of bad talks in
them. Better to get them out earlier (when it doesn’t matter) than later
(when you don’t have a choice). I challenge you to do 10 bad talks in a row
and not improve. Do talks.
Guest Writing for Industry Sites. You can start with everybody-can-post
community venues like Dev.to, but eventually you want to get yourself
published in selective, peer-reviewed industry sites. For frontend
developers, these are places like CSS Tricks, Smashing Magazine, and A
List Apart. These are not only great resume items, but the work involved in
putting together a high quality article builds your knowledge (and
subsequently, your reputation) like no other. (See ways to get paid to write
in Chapter 18!)
Blog. Blogging is the ultimate form of permissionless learning - you can
Learn in Public on your own terms, under your own domain. If you want
to build a brand or domain expertise, focus your writing on a specific topic
so that people will start to recognize your work and subscribe for updates.
Answer Questions. Believe it or not, you are limited by your interests and
your own questions. The things you don’t even know that you don’t know.
One way to get ideas for blogposts and to learn faster than you can alone, is
to answer other people’s questions. There are an unlimited number of
people looking for help on StackOverflow, Twitter, Reddit, and in GitHub
issues. If you practice answering questions, you get better at answering
questions (Save your keystrokes! Put frequent answers into a blogpost!),
but you also start finding questions you never thought to ask. Often, these
questions will come up in your future work. The other benefit of “being
helpful on the Internet” is that you will get noticed by the maintainers of
those communities, and recruited to help.

“When one teaches, two learn.” - Robert Heinlein

All of this learning in public will also help you build your network. The
benefits from your network compound over time, so you might as well start
early.
Finally, you want to stay sharp at doing interviews. This will not be your last
job. Look around and do interviews once a year. You have an upper hand in
everything from networking to company selection to negotiating when your
alternative is simply staying at the job you already have.
Chapter 5
From Junior to Senior
As you become comfortable as a Junior Developer (and, if your company has
one, an intermediate level Developer/Software Engineer), you will naturally start
looking toward the next level: Senior Developer.

What counts as a senior developer is not standardized, and everyone has strong
opinions about it. To some, it is three years at a high growth startup. Others can
take anywhere from two to eight years. Still others say they don’t care about
number of years (and may or may not mean it).

What other people think only counts so much. What really matters is what your
company (or the other companies you interview at) looks for in a Senior, and
whether they pay you commensurate with the market rate for Senior Developer.
After all, a Senior title without the pay is meaningless!

If you’re lucky, the company will have an Engineering Ladder where you can
see their requirements for a Senior. If not, you can check our discussion of
Engineering Ladders in the Strategy section (Chapter 26).

Ultimately, getting that role as a Senior Developer is a two step process:

1. Getting enough (not all) of the prerequisite skills and accomplishments

specified by the company
2. Successfully Marketing Yourself as meeting enough of those requirements
to be hired into that role

This means that you often have to act like a Senior Engineer before you
officially become one. Fortunately, this is much easier than the chicken-and-egg
problem of getting your first job - most places will be happy to let you take on
more responsibility while in your existing role!
5.1 Acting For the Job You Want
When surveyed, developers almost universally identify a few qualities that you
should develop as you prepare for the next level:

Solid technical expertise, full command of fundamentals

Impact on your team’s work
Being able to work across other teams
Seeing the “Bigger Picture”
Communication, Communication, Communication
Mentoring others

Regardless of what your Engineering Ladder says, you will want to practice,
practice, practice these skills as much as you can. They are just generally agreed
upon qualities of a Senior Engineer that will help you and those around you
throughout your career.

Note: More on this in the Senior Dev chapter, Chapter 6

5.1.1 Technical Expertise

When it comes to your technical skills, consider how you are progressing along
the Dreyfus Model of Skill Acquisition:
In your journey so far, you have likely progressed from Novice to Competent.
As you go towards Expert in your field, you will likely want to pay attention to
the meta-learning skills - focusing on first principles intuition (Chapter 17)
when it comes to learning your trade.

Much of your learning from Junior to Senior involves gaining tacit knowledge.
You can read all the programming books in the world, but, by definition, you are
still limited to things that people can write down. That is explicit knowledge,
and it is usually the tip of the iceberg when it comes to everything you need to
know:
Tacit knowledge in engineering is a real thing. Keep a look out for all the
lessons you don’t learn in classes or from books. To really make your career
explode, make a habit of writing them down for everyone else (Chapter 18 -
Write, A Lot!).

You aren’t alone in this journey – plenty of fellow developers have also written
down their learnings. You can only get so far learning from your own
experience – why not borrow the experiences of others? It’s not the same as
living through it yourself, but for example, reading through publicly published
postmortems can teach you that many outages, even by the most well regarded
companies, come down to error handling, configuration, hardware, lack of
monitoring, and processes that allow human error.

5.1.2 Career Strategy

Many people define Senior Developers as “being able to see the Bigger
Picture”. Everyone agrees it’s important, but nobody quite knows how to define
it. It has something to do with how your technical work fits in context of the
business/product, or fits in the broader architecture of the codebase, balancing
both its history and future roadmap. So try to step back from your day-to-day
work every so often and zoom out!

Before you make your big move, make sure you know what you want and take
the time to position yourself accordingly in the preceding 6-12 months. Want to
work on creating GraphQL APIs as a Senior? Better to do it as a Junior first.
The logic here is: You aren’t expected to make that much impact as a Junior, but
you certainly will as a Senior. So it can be worth it to jockey around a little bit
longer as a Junior or Intermediate Developer, just so you are in the perfect spot
for a career-making Senior Developer role you can throw yourself
wholeheartedly into. Better yet, your company can institute formal support for
employees making internal “tours of duty”, to grow you while keeping you!

It can help to make a list of what you’ve enjoyed in your current job. Among
your peers (you have been building your network, right?), make a note of things
that seem particularly exciting to you, and try to get exposure to those within
your company or projects. It’s a two way street - finding out what you like and
are good at, and then positioning so that you can do even more of that.

Note: This is the subject of the entire Strategy section of this book!

By the way - beyond just what you like to work on, you might also take note of
who you like to work with. Here’s an example from Keavy McMinn.

5.2 Marketing Yourself as a Senior

Engineer
You may feel like you’re not fully ready yet. You haven’t checked off all the
boxes for the Senior Engineer job or promotion you’re applying for. It doesn’t
hurt to try. You don’t know if it’s impostor syndrome talking, and even if you
fail the first time, you get priceless feedback and practice for the next time!

Remember the Dunning-Kruger effect between what you know and what you
know you don’t yet know:

People crossing from Junior to Senior are particularly likely to be at or just

coming out of the “Valley of Despair”. There’s no point on that curve where you
magically become irrefutably Senior. It’s all a spectrum, and perhaps the only
thing common among Seniors is having recovered from both the heights and
troughs of confidence vs ability. You can ask other people how you’re doing or
teach what you know to keep some perspective.
Devs from minority backgrounds can face systematic bias (conscious or
unconscious) in their evaluation. This is both unfair and a fact of life. A sponsor
with credibility can help you a long way – if you have trouble finding one,
Mekka Okereke has a technique he calls “The Difficulty Anchor”, which is hard
work but a great strategy to win a powerful ally.

As you start marketing yourself as a Senior Dev, you’ll want to have your
accomplishments and stories in order. Just to give you an example, the AWS
interview process involves asking you for examples of accomplishments and
interactions that demonstrate one of their 14 Leadership Principles. Most
companies may not be this formal about it, but will have some form of “Tell me
a time when you…” question. Portfolios and Proof of Work still matter, but less
so because you can choose to lean on a lot of the production work you
contributed to as a Junior. Pay particular attention to any quantitative results you
can cite – cost savings per year, Monthly Active User increases, Time To
Interactive drops, whatever metrics make you look good.

In particular, anything you do in public - blogging, speaking, podcasting, making

video tutorials, open source work - can help you grow your knowledge and your
network at the same time, opening up the possibility for inbound opportunities to
come to you. Remember to fight Impostor Syndrome every step of the way!

Note: You can find more ideas in the Marketing Yourself chapter
(Chapter 39) of the Tactics section.

5.3 Junior Engineer, Senior Engineer

For Junior Engineers who want some ideas for directions to improve, it can be
an interesting exercise to do a series of contrasting statements. I went through a
long list of Junior-to-Senior advice online, and compiled these 30 comparisons
in four categories: Code, Learning, Behavior, Team. Please note that these are
pithy opinions, not requirements! We are all junior in some way, senior in
others. You’ll find that elements of these ideas permeate the Principles, Tactics,
and Strategies throughout this book.

5.3.1 Code

Juniors collect solutions. Seniors collect patterns.

Juniors get code working. Seniors keep code working.
Juniors deliver features. Seniors deliver outcomes.
Juniors fix bugs after they create them. Seniors create tooling to preclude
bugs.
Juniors write tests because it’s required. Seniors require writing good tests
– because they’ve seen what happens when you don’t.
Juniors hate technical debt. Seniors have written code that became
technical debt (and know when to let it be and when to migrate).
Juniors love to keep code DRY. Seniors Avoid Hasty Abstractions.
Juniors try to write the best code the first time. Seniors understand code is
read, moved, copied and deleted far more than it is written.
Juniors know how to use their tools. Seniors know when not to use them.

5.3.2 Learning

Juniors make one-off side projects. Seniors use their side projects daily,
often to make themselves more productive at their day job.
Juniors learn to find the right answers. Seniors learn to ask the right
questions.
Juniors know what they need to know. Seniors know what they don’t need
to know.
Juniors should absorb best practices from others. Seniors can derive best
practices from first principles and personal pain.
Juniors get stuck without docs and tutorials. Seniors aren’t afraid to read
specs and view source.
Juniors might have strongly held beliefs. Seniors have had to change
strongly held beliefs.
Juniors question themselves when they fail. Seniors know they just need to
give themselves more time and try again.
Juniors stay on top of news. Seniors keep track of trends (especially
Megatrends – Chapter 29).
 Juniors try to avoid mistakes. Seniors have made them all – and know how
to recover.
Juniors laugh at software tropes. Seniors know there’s a grain of truth in all
of them.

5.3.3 Behavior

Juniors seek The Best. Seniors love the Good Enough (Chapter 16).
Juniors should say “Yes” often. Seniors should say “No” more.
Juniors should try to do the jobs they are given. Seniors should redesign
their jobs as needed.
Juniors complain about Open Source. Seniors understand Open Source
only works thanks to contributors, not complainers.
Juniors solve problems. Seniors identify problems before they become
problems.
Juniors start from what others say. Seniors start from what they need.
Juniors know how to build. Seniors know when to buy.
Juniors compare developer experience. Seniors look for hidden costs in
user experience and in abstraction leaks.
Juniors write as an afterthought. Seniors weigh writing as much as coding.
Juniors leave comments. Seniors provide context.

5.3.4 Team

Juniors work within their teams. Seniors know when and how to work
across teams.
Juniors grow their own output. Seniors grow their team’s output.
Juniors pair to learn best practices. Seniors pair to share expertise and see
things in a new light.
Juniors get roped in. Seniors get buy-in.
Juniors must earn trust. Seniors inspire trust.
Juniors seek out mentors. Seniors know how to learn from peers.
Juniors work on improving themselves. Seniors work on improving their
team, being a force multiplier through teaching, mentorship, and
leadership.
 Note that these are pithy, idealized comparisons just to get your
imagination going on ways to improve yourself. In no way am I
stating that any quality is unique to Juniors or Seniors, or that all
Seniors or all Juniors practice all these qualities all the time.

5.4 To Stay or To Go
Finally, there’s the question of whether to angle for promotion at your current
company or to make the Senior Developer jump at a different company. That’s a
call you’ll have to make, but you will always be better off at least interviewing
at other companies. When you have an offer in hand from another company,
you have a pretty much airtight case for promotion at your current company.

You’ve done the job hunt before; it’ll be a lot easier this time. Beside hunting
via the regular channels (online posting, networking at meetups and
conferences), you should also be aware of new opportunities available to you at
this stage. For example, recruiters of all stripes from in-house, third party, and
venture capital will be more receptive to your cold emails. You can also tap your
relationships formed online (via your writing or Twitter — you have been
working on those, right?) to find opportunities before they get advertised. A
warm intro of any sort beats applying via the front door and competing with
everyone else on a 5 second glance of your resume. Finally, a big part of selling
yourself as a Senior Developer is being able to communicate your level of
experience in an interview - storytelling becomes a surprisingly big part of any
senior hiring process.

Salary bumps are well known to be higher when you move companies - instead
of a 5-10% bump, you could get a 50-400% bump because you could join a
company with a different pay scale in a different industry at a different level in a
different city. Of course these are major life changes, but higher bumps are more
common when moving companies. There’s also the simple fact that you didn’t
have much leverage when you were a junior dev. Now, you can actually take
your time and practice some Negotiation (Chapter 31).
You may also wish to diversify your resume. If you move from junior to senior
in the same company, you have less exposure to a variety of projects,
technologies, opinions and cultures. If you’re at an agency, you may wish to
consider moving to a startup. If you’re at a startup, you may wish to consider a
BigCo. BigCo experience can net you big bucks at some forms of agency
(including freelancing). So on and so forth. The earlier you are in your career,
the easier it will be to hop around to figure out where you truly fit.

If you currently work at a place that doesn’t have a good developer brand, you
may wish to move to one that does, which will help boost your network and
personal brand. Few people question the technical ability of ex-Google
engineers.

Conversely, if you currently work at a place with a good brand, you may wish to
take more risk in your next gig for more personal growth and financial upside,
because the risk of failure is lower.
Chapter 6
Senior Developer
Congrats! You’ve made it as a Senior Developer!

I’m sure it feels a little different than you imagined, now that you’re in it.
Getting a job as a Senior Developer isn’t the same thing as excelling as a Senior
Developer.

It turns out that “Senior Developer” is a very broad title in this industry. Going
from “ok, this person is technically not entry level anymore” to “anywhere else
this person would be a Staff or Principal, but we believe in a flat hierarchy and
call everyone Senior, deal with it.” It’s a little like a “passport” title. It is
understood almost everywhere, but exactly how one title translates to another
between companies is messy and case dependent.

Because I myself am somewhere on the Senior Developer spectrum, I can’t share

from personal experience how to get to the next level. However, I can infer from
advice of others, triangulate again from Engineering Ladders, and offer some
informed opinions about how to do well. But my opinions are just that - my
own, and you should assess this chapter with more of a critical eye than others.
The further we depart from beginner territory, the more diverse and, let’s face it,
outright contradicting people’s lived experiences become.

We briefly covered a lot of the idealized qualities of a Senior Developer in the

Junior to Senior chapter (Chapter 5). This is because you should exhibit some
of these qualities before actually getting hired as a Senior. But now that you are
living the life, you really have to exemplify these qualities. If not for your own
sake, then for your team and Juniors that look up to you.

6.1 Solutions vs Patterns

You might be familiar with the industry standard set of solutions to common
problems. You know your tools well and can wield them effectively to solve
problems you or others have seen before. The challenge comes when you run
into new problems. Problems your tools were never designed for, under
constraints and at scales that invalidate convenient assumptions. When your
tools stop serving you, your knowledge of them does too.

Knowing how to use your tools is good, but knowing when not to use them is
better. If you define yourself by your tool (“I am a ${FRAMEWORK}
programmer”) - you will try to solve every problem with that tool. This
approach leads you to either fail or come up with unnecessarily convoluted
solutions (still a failure, but way more expensive).

To go past this, you need to understand the underlying design patterns that
inform your tools, and accept that nothing comes truly free. When you have a
wide toolkit of design patterns and a good understanding of what they solve and
what they trade off, you will be able to repurpose tools or build your own. This
knowledge will last regardless of language, and can be reapplied at multiple
levels of your stack. It scales incredibly well and helps you learn faster the
more you learn - one of the core drivers to a superlinear Big L. The Gang of
Four wrote the book on design patterns (see Addy Osmani’s book if you like
JavaScript). But don’t forget other foundational classics like the Dragon book on
Compilers, the Dinosaur book on Operating Systems, and Game Programming
Patterns. All your system design, algorithms and data structures knowledge are
also useful patterns - except instead of just cramming for an interview, you
actually need to use them at work!

6.2 Velocity vs Maintainability

Most people today understand both the intended spirit and unintended
consequences of “Move Fast and Break Things.” However, what is less well
understood is how tradeoffs change as project maturity changes. When you
are conducting R&D in a small startup, you should absolutely move fast - the
downside of failure is minimal, so the value of systems and processes is low.
When you are pushing a code change to a massive infrastructure system, one
tiny mistake can cause hundreds of millions of losses in seconds. The results get
even more dire when human lives are at stake.

What applies to project maturity also applies to developer maturity.

As a Junior, your velocity and impact is low. Your main task is to get code
working, with Seniors to catch you when you fall. Improving your own velocity
is a perfectly reasonable thing to prioritize - if you’ve done anything that isn’t up
to code standards, your Seniors will hold you accountable.

But this luxury goes away when you become a Senior. Now you are expected to
be able to independently ship. Part of that independence comes from trust that
you will make the right tradeoffs between velocity and maintainability. It’s less
about pushing the limits of what you can do – anyone can build systems that are
twice as complex as they can easily maintain – and more about creating systems
that last under forward assumptions.

If you don’t write maintainable software, you are just causing future problems
for yourself. So:

Instead of testing because you’re told to, you test because it’s the only way
to scale yourself. You also are much more hesitant to write fragile tests
because they cause more work than they save. They test implementation
detail and hurt migrations (more on Migrations below). You insist that
either production code be merged in together with tests for that code, or not
at all, except under specifically enumerated emergencies.
Instead of only fixing bugs after you create them, you work to avoid them
in the first place. You lean on your past scars, and use tooling and careful
choices in everything from API design to variable naming.
You document and comment your code. Not just for your future self, but
also for the people who take over the code when you move on to bigger,
better things.

Warning: If you fall in love with writing perfect code, your velocity can suffer to
unacceptable levels. Remember that done is better than perfect and Good
Enough is Better than Best (Chapter 16).
However, most organizations create incentives to optimize for velocity over
maintainability. One way to tell is whether equal effort is spent learning from
and tracking mistakes as is spent shipping features. A good first step is to
establish a culture of blameless postmortem (you can borrow AWS’ incident
postmortem template as a starting point). It’s fine to make mistakes, but it is not
fine to repeat mistakes. Critical incidents should act as brakes on velocity.
Don’t view this as a step backwards – your job isn’t just building features,
you’re also building a system to last, scale, and recover from anything. If you
make your postmortems public it can greatly increase customer trust and help
improve the industry.

6.3 Technical Debt

Ward Cunningham, co-author of the Agile Manifesto and creator of the
eponymous law, coined this term in 1992:

“Shipping first time code is like going into debt. A little debt speeds
development so long as it is paid back promptly with a rewrite… The
danger occurs when the debt is not repaid. Every minute spent on not-
quite-right code counts as interest on that debt. Entire engineering
organizations can be brought to a stand-still under the debt load of
an unconsolidated implementation.”

Goodness! Debt sounds terrible! Who on earth could want debt? Get debt free
right away!

There are two kinds of Technical Debt. Martin Fowler makes the distinction
between Prudent and Reckless Debt. Hashicorp identifies three categories of
debt: outdated, leverage, and accidental debt, but they map closely enough to
Martin’s thinking that we will stick to those for the purposes of this book.

6.3.1 Prudent Debt

Prudent Technical Debt can be considered “outdated code”. Code that doesn’t
use the latest versions of everything. Code that uses patterns that have fallen out
of favor. Code that is slow. Code that has loooooongstanding bugs. Code that is
verbose because it supports features and abstractions nobody uses anymore.

We’re programmers. Programmers are, in their hearts, architects, and

the first thing they want to do when they get to a site is to bulldoze
the place flat and build something grand. We’re not excited by
incremental renovation: tinkering, improving, planting flower beds. -
Joel Spolsky

Juniors loathe this kind of debt. It runs against everything they’ve been taught is
the best way to do things, and of course the best way is the only way.

Seniors understand that only successful codebases live long enough to become
technical debt. They understand this because they have written code that became
debt. They have also tried to replace that debt and learned the same lesson
everyone learns: That technical debt makes money. Not only does it make
money: it is probably superior to any replacement attempt. Old code has been
used. It has been tested in production and at scale. Lots of bugs have been
found, and they’ve been fixed. By definition, only the noncritical bugs remain!
Hyrum’s Law teaches us that all observable behaviors of a program, even bugs,
will be relied on by users. Imagine fixing a bug to get complaints to undo your
fix!

Sometimes you should intentionally load up debt because you don’t yet know
the problem space well. Juniors rush to keep things DRY - but this causes Hasty
Abstractions that they then regret and have to unwind later. Seniors understand
that code is copied, read, moved, and deleted, far more than it is written.
Instead of optimizing for conciseness or cleverness, it is better to optimize for
inevitable change.

Tip: For a great visualization of this, see Dan Abramov’s Deconstruct

2019 talk.
As a Senior, you’re paid to wrangle Technical Debt. That’s why some of the
highest paying jobs deal with huge legacy systems, whereas enthusiasts and
hobbyists will hack on cutting edge technology for free. But it’s not like you can
let debt build up forever. You need to be able to figure out how much is too
much, and how to pay it down while still delivering business objectives.

The Strangler or Facade Pattern is most often mentioned as part of the Technical
Debt Management toolkit. It is helpful for swapping out underlying
implementations while running-in-place. A good variant of this is the Bridge
pattern, where you abstract over all third party dependencies, instead of only
when upgrading.

One of my favorite software development practices is to wrap

dependencies into custom abstractions. I hate it when a third-party
leaks all over my code and a refactor takes hours (if not days) because
of it. - Sarah Dayan

But the core skill at hand (especially at the level of systems, not code) is running
migrations. This is especially true at high growth startups, where code becomes
outdated as a direct and frequent side effect of growing yet another order of
magnitude. Here, the playbook is to Derisk, Enable, and Finish strong.

Software migrations are a way of life at rapidly growing companies,

and increasingly I think your ability to migrate effectively is the
defining constraint for your growth. - Will Larson

When operating at scale, what might be a disadvantage can turn into an

advantage - using your production traffic to gain definitive confidence in your
code. Most big companies have avoided long lived branches, and converged on
using Feature Flags for this. Here’s Paul Biggar, founder of CircleCI and
Darklang:
 One way to reduce accidental complexity in Dark is by solving many
different problems with a single solution. Feature flags is our
workhorse: replacing local dev environments, git branches, code
deployment, and of course still providing the traditional use-case of
slow, controlled roll-out of new code.

And here’s Dan Abramov on how Facebook does migrations:

We rely extensively on feature flags to enable and disable

functionality or to switch between different implementations. So we
might have a v1 and a v2 checked in and (we have a dynamic check
that rolls v2 out to) 1% of users and then 50% of users, and we’ll see
if there are any regressions in metrics. And then when we’re confident
that the fix actually works and it doesn’t make anything worse, then
we’ll switch it over to 100% and delete the old implementation.

Feature Flags aren’t free though. Uber discovered a ton of stale flags clogging
up its codebase, making it more complex, and possibly slowing down builds and
tests. The problem was so bad they wrote an internal tool to detect and clean
them up, called Piranha. It found 6601 flags and that 17% of them weren’t used.
Your flags themselves can be Technical Debt.

6.3.2 Reckless Debt

The other kind of Technical Debt doesn’t have anything to do with age or
growth: Reckless Debt. You can think about this as debt resulting from skipped
steps. Here’s Joël Quenneville of Thoughtbot: “(Reckless) Technical Debt is
described as taking shortcuts and cutting corners in code quality in order to
speed up development.”

Identifying “Reckless” Debt is challenging in itself - nobody wants to cop to

cutting corners, but we all do it. Kent Beck exhorted us to “Make it Work, Make
it Right, then Make it Fast”, but many incentive systems encourage developers to
just “Make it Work, Make it Work, Make it Work.”

One popular, but incomplete, way to deal with this is to use automated code
quality systems that don’t let you commit code that worsens metrics beyond an
acceptable point. These tools help bring future debt into the present, and forces
you to deal with them now before you ship, rather than put things off forever
until it becomes an impossible task.

Tools that hold the line and don’t let things get worse are so
powerful. E.g. test coverage, type coverage, bundle sizes, perf
metrics, etc. Much of APIs are about how not to break something that
was once tested. Under-invested in open source and business critical
in Big Tech. - Sebastian Markbåge

You should automate detection of every code quality issue you can, including
build times, build sizes, file length, test coverage, and linting or pretty-printing
your codebase. Every hour spent in code review on automatically detectable
errors is multiple hours wasted in the back and forth between your developers.
Let the machine be the Bad Cop. Conversely, try not to hold too many
opinions that cannot be encoded in your systems, as that adds cognitive load,
invites bikeshedding, and may actively hinder your developers when they face
unanticipated problems.

The other concern with Reckless Debt comes from the mismatch of the financial
debt metaphor:

The Technical Debt analogy suggests a fungible (every debt issue is the
same), predictable increase in cost over time, which you can add
resources to deal with (aka throw people at the problem). It places blame
squarely inside the codebase.
In reality, we experience a loss of predictability (because we skip our
systems, we lose control of our systems). This creates a unique (every
codebase’s problems are unique) scenario where adding resources
increases risk (the Mythical Man Month issue), and the problem is in the
interactions between people and code.
So instead of “Technical Debt”, the better metaphor for Reckless Technical Debt
might be “Increasing Risk”. This happens to help sell the idea of fixing it a lot
better. As Rachel Stephens notes: “Your manager doesn’t care about interest
payments… but they care A LOT about RISK.”

To control the creation of Reckless Debt at the source, it can be prudent to have a
blessed set of technologies everyone at the company uses. Google maintains a
list of “Official Languages” Googlers can use, with dedicated language
infrastructure teams to support them. When you use a standardized toolset and
only allow yourself limited “innovation credits” to experiment with new
technologies or patterns, you have less of an excuse to cut corners. Everything is
familiar and you can even build your own tooling to make adhering to code
standards easier.

Even with all these systems and policies in place, Reckless Debt will no doubt
arise in your codebase. You would do well to have a policy written down
somewhere for identifying and prioritizing this. Use Hashicorp’s Technical Debt
policy if it helps. This not only serves as an approved process for you and your
team to follow, it is also a contract that you can have with management and other
stakeholders, who might be inclined to brush aside issues where they don’t feel
immediate pain.

6.4 Mentorship, Allyship &

Sponsorship
“Individual Contributor” is a misnomer when it comes to being a Senior
Developer. There’s nothing individual about it - virtually every company
expects their Senior Devs to be mentors for their Juniors and force multipliers
for their teams.

You might be the smartest person in the company. You might have the deepest
knowledge, write the best code, crush tickets faster and cleaner than anyone else
in the history of programming. It doesn’t matter if you cannot scale yourself.
If you hoard all the knowledge and don’t mentor and collaborate, you are only as
useful to the company as an external hired agency.
Listen to the true story of Rick, a genius developer who did great work but also
became a huge bottleneck and refused to accept any systematic remedy. He was
an individual contributor, alright. He contributed the company’s greatest
problems, and was fired.

The best way to be a 10x developer is to teach 10 people what you know.
Spend time making sure that engineers who are unfamiliar with the tech or
processes not only understand what they are doing, but also why they are doing
it. “Teach them to fish” is a mandatory skill as a Senior Engineer, and that
requires having both patience and a perspective of investment in the rest of the
organization. You should come to preach Apprenticeship Patterns as much as
you do design patterns. Once they are capable, have them do the same.
Encourage a knowledge sharing culture. Senior engineers lift the skills &
expertise of those around them.

Part of the way you will do this is to Write, A Lot (Chapter 18). This scales
your experience across people and time. Just like you document your own code,
you should document your own “API” (for example, by writing a personal
README) and as much context and learned experience as you can articulate.

As someone with a senior title, you have a lot of power to call out unconscious
and systematic bias toward underrepresented minorities in your company. Be an
ally – our industry has tremendous diversity debt accumulated over the past half
century and this is hurting us and society at large now. You don’t have to be
“super woke” to recognize this simple fact. Unintentional sexism and racism
happens from the big things like hiring pipeline, promotion, and project
distribution, right down to smaller things like code review and speaker
representation.

You might agree this is a problem but view this as “not my job”. This severely
underestimates your power and therefore your responsibility to effect change
within your own circle of influence. It starts with you. If we want our industry
to be better in our lifetimes, we need to play an active role, instead of waiting on
some “D&I initiative” to magically fix it for us.

A great list of five things you can do to help, from Karen Catlin of Better Allies:

Speak their name when they aren’t around

 Endorse them publicly
Invite them to high-profile meetings
Share their career goals with decision-makers
Recommend them for stretch assignments and speaking opportunities

Mentorship and Allyship is great, Sponsorship is even better. Talk is cheap -

take an active role in opening doors for underrepresented people! Lara Hogan
and Samantha Bretous have great advice on how to be a sponsor, but it is up to
each of us to live this advice. When you actively sponsor someone up to a
position of influence, the effects of that can ripple out for decades, because they
can then turn around and sponsor others.

It’s important to not let the title get to your head. You are still junior in some
things. You do still have things to learn. People junior to you can still tell you
things you don’t know. You are as liable to the same cognitive biases in software
development you spot in others. Stay humble, stay hungry, stay foolish.

“In every man there is something wherein I may learn of him, and in
that I am his pupil.” - Ralph Waldo Emerson

6.5 Business Impact

The most valuable engineers are the ones who habitually view their
work through the lens of what the business needs to succeed. Which is
a skill you have to practice and foster and cultivate, just like any
other. - Charity Majors

The final element that everyone expects out of Senior Engineers is having some
sense of the “Bigger Picture”. People are usually vague on what they mean by
that, but by and large, they mean having a sense of where your code and systems
fit into the broader context of how the company makes and spends money.
Outcomes over Features. As a Senior Engineer, you realize that it doesn’t
matter if you deliver the perfect feature if a confounding factor prevents the user
from seeing the desired outcome. Requirements that are given or agreed
upon can be wrong.

If Junior Engineers are hired to find the right answers, then Senior Engineers
should constantly be on the watch to ask the right questions. Your
communication skills, especially your writing skills, are essential here to clarify
and push back with tact. Time spent on ensuring everybody has the same
definitions of terminology, and shares the same context on desired goals, can
save 100x that amount of time down the line, when code is already written. This
concept is called Shift Left:

IBM Research also looked at the relative cost to correct bugs and
defects based on when in the software development lifecycle they
were identified and resolved. The study showed that defects identified
and resolved during the Requirements and Design phase of
development are 60-100X less expensive to fix than those discovered
and fixed after product release. (Source: Infostretch)
In fact, the strategic saying of No can be your single most valuable action.
Having made similar mistakes before, you are able to anticipate potential
problems. Contributing in this way is often even better than suggesting an
immediate solution. Sometimes, this goes as far as redesigning your own job if
you realize you are not working on the right thing. If as a Junior Dev your goal
was to fit in, as a Senior you have the power to stand out when it matters.

“I’m as proud of what we don’t do as I am of what we do.” - Steve

Jobs

Awareness of your impact does extend beyond business toward your industry
and your community. If we believe that technology is powerful, then we must
also believe that the people who wield it have a responsibility for that power.
The medical industry has the Hippocratic Oath, commonly interpreted as “First
do no harm”. The closest version we have is “the Computer Lib Pledge”
articulated by tech pioneer Ted Nelson in 1974’s Dream Machines:

The purpose of computers is human freedom.

I am going to help make people free through computers.

I will not help the computer priesthood confuse and bully the public.

I will endeavor to explain patiently what computer systems really do.

I will not give misleading answers to get people off my back, like “Because
that’s the way computers work” instead of “Because that’s the way I
designed it.”

I will stand firm against the forces of evil.

I will speak up against computer systems that are oppressive, insulting, or

unkind, and do the best I can to improve or replace them, if I cannot
prevent them from being bought or created in the first place.

I will fight injustice, complication, and any company that makes things
difficult on purpose.

I will do all I can to further human understanding, especially through the

new visualizing tools of interactive computer graphics.

I will do what I can to make systems easy to understand, interactive

wherever possible, and fun for the user.

I will try not to make fun of another user’s favorite computer language,
even if it is COBOL or BASIC.

6.6 Recommended Reading

Continuing on the Individual Contributor track beyond Senior Dev is out of
scope for this book, but I can refer you to some resources to get you started:

Yan Cui’s Breaking the Senior Developer Ceiling

Keavy McMinn: Thriving on the Technical Leadership Path
John Allspaw’s On Being a Senior Engineer
Tom Limoncelli: What makes a sysadmin a “senior sysadmin”?
Getting promoted to Staff Engineer: https://staffeng.com/stories
Hacker News on getting promoted to Architect
Chapter 7
Beyond your Coding Career
Something that goes quite unspoken in our industry is that there is a lot of
churn. That’s why you see so few extremely senior engineers who still
primarily code for a living. It’s not just that they are rare, but also they are the
only ones that are left.

Sometimes this is “bad churn”, like the many, many cases of burnout in our
industry. Please pace yourself - if you intend this career to be a long one, you
shouldn’t be running a marathon at sprint pace. Recognize symptoms of
burnout:

Working Late
Irritability
Not asking for help
Wallflowering during technical conversations
Insomnia/Code Nightmares

And look out for these in your coworkers. As technical people we monitor
software and hardware for problems, but often forget the wetware (people) that
are at the root.

Fortunately, the majority of people stop coding for a living for more positive
reasons - they find something that suits them better! If code is at the center of
your universe and this sounds impossible to you right now, consider this: why do
people who don’t code call the shots, and why do they pay you to write code?
They must get more value not coding for a living than you get coding for a
living.

Here, we will briefly discuss what a moderately informed friend (me!) might tell
you about five common paths (without having actually lived through all of them)
of good churn:
 Engineering Management
Product Management
Developer Relations
Developer Education
Entrepreneurship

We will not discuss Freelancing or Consulting - those are close enough to coding
jobs, with some solo business management tacked on top - but check out Nader
Dabit’s The Prosperous Software Consultant, Gerald Weinberg’s Secrets of
Consulting and Harry Roberts’ Questions for Consultants if you are keen to try
that.

Our discussions will try to warn you about the bad along with the good - which
is to say, it’s not 100% good. But nothing is. Don’t mistake this as “shitting on
these paths”, they are obviously great career tracks that many enjoy. The intent
is to warn you about potential downsides like any friend would, so you go in
with eyes wide open.

The goal, as in the rest of this book, is not to be 100% correct - it is just to open
your eyes to considerations you may not have thought about before, and point
you the way to learn more or form your own opinions.

Author’s note: This lengthy disclaimer is the only sane way to write a
broad-reaching chapter like this! braces for shitstorm of complaints…

7.1 Engineering Management

Probably the most common path out of a coding career is becoming an
engineering manager (EM). This isn’t always true, as we will explore later, but
in many organizations, EMs make more money, have more impact, have a more
central position in company hierarchy and information flow, and spend less time
worrying about implementation details.
You will spend most of your coding career reporting to EMs, so it might feel
natural to view that as the next step. Even more likely, you harbor the armchair
quarterback’s niggling suspicion: “I could do that job better!”

“Things would be different if I was in charge”, the belief that authority

is an all-powerful magic wand you can wave and fix things. - Mark
Roddy

Companies also naturally want to take their best coders and put them in charge
of other coders. Despite the best efforts of companies to create equivalent
Individual Contributor career tracks, the dearth of good managers mean that
most organization incentive structures encourage some form of Peter Principle.

However, heed the advice of basically everybody who has ever gone from
engineering to engineering management: it is a huge career change. You go
from developing software to working on Peopleware. If you are in the right head
space for the role, you will see this as a good thing! Humans are a part of your
systems too!

Becoming a manager is not a promotion - it’s a lateral move onto a

parallel track. You’re back at junior level in many key skills. -
Sarah Mei

As an engineering manager:

Your primary output is no longer code, it is teams (and, as you rise up,
teams of teams). Therefore you will spend a huge amount of your time
hiring and managing. The amount of time you spend in high stakes Crucial
Conversations becomes exponentially higher.
You can no longer throw a hack together to get shit done, you need to
follow process and get buy-in more than ever - progress will seem glacial
compared to what you are used to.
You help set technical standards, but must avoid micromanaging code. This
is a very fine line to draw, especially if your identity and sense of self worth
 was primarily based on your technical expertise. Nobody likes the EM who
“swoops and poops” on their work. You need to trust your engineers to
make their own judgments and their own mistakes (within reason). In order
to do that you need to hire and train people you trust more than you need to
dictate code typed by someone else. Ultimately, you will also want to help
train your own replacement to progress up.
You lose the ability to be fully open with your friends and coworkers, even
outside of work, because you sit atop a mountain of confidential
information. People look to you for confidence and leadership so you need
to be guarded about your own doubts and feelings.
Nothing is ever complete, or fully resolved, and everything is important.
As middle management, you still have bosses: while you always feel
maximum responsibility for your reports’ gripes, dreams, and careers, your
own impact and ability to change things is limited. This can be a difficult
line to balance.

Before you decide to become a manager, have a read through Charity Majors’
list of 17 Reasons NOT to Be a Manager and go through Nick Caldwell’s
“Voight Kampff test for engineering managers”. Know what you’re signing up
for.

It’s not all bad, or there’d be no managers. Sensible companies want to

balance the risks of losing great developers with the need to grow engineering
manager talent. BigCos like Facebook have the capacity to introduce temporary
or “associate” EM positions where you can trial it for two years (the minimum
tour of duty), and move back into engineering with no fault if you end up
deciding it is not a fit.

In fact, jumping between IC and EM roles is becoming more common. Seeing

things from the other side of the table for a while can make you a more effective
senior IC. Christoph Nakazawa, EM of the wildly popular Jest framework and
now React Native, notes:

I’ve transitioned from IC to EM to IC to EM and I can say that

management taught me lessons on how to be a more effective
engineering leader that are very hard to learn as just an IC.
Charity Majors calls this the Engineer/Manager Pendulum:

The best individual contributors are the ones who have done time in
management. And the best technical leaders in the world are often the
ones who do both. Back and forth. Like a pendulum.

There is a difference between how this game works for startups vs BigCos. Most
small companies often don’t need more than one truly senior-level engineer, and
they find that they have to switch to consulting or move to a BigCo to have
enough interesting projects. Conversely, at small startups, engineering managers
often double as tech leads, and spend significant amounts of time both coding
and making technical decisions. These are completely different jobs at BigCos,
and this is why you will see a wild diversity of management advice.

I cannot credibly advise you further on this track because I have not done it
myself. Fortunately, many engineering leaders take writing very seriously, so
you can go read their stuff:

Michael Lopp (VPE of Slack)’s books and blog, better known as Rands in
Repose
Charity Majors (CTO of Honeycomb) on the Organizational Leadership
Track
Will Larson (VPE of Calm) on Systems of Eng Management
Kate Matsudaira (VPE of Moz) on The New Manager Guide
Oren Ellenborgen (VPE of Forter) on Software Lead Weekly and Leading
Snowflakes
Camille Fournier (CTO of Rent the Runway) on The Manager’s Path
Gene Kim (CTO of Tripwire)’s fictional novel The Phoenix Project
James Stanier (SVPE at Brandwatch) on Become an Effective Software
Engineering Manager
Greg Skloot (VP Growth at Netpulse) on How to be a Manager
Kamil Sindi (CTO JW Player)’s Manager’s Playbook
Lara Hogan (VPE of Kickstarter) on Resilient Management
Julie Zhuo (VPD at Facebook) on The Making of a Manager
 Classic developer leadership books like Becoming a Technical Leader, the
Mythical Man-Month, and High Output Management
Traditional leadership books like Multipliers, Dare to Lead, and The Infinite
Game are also regularly recommended for managers of people.

Of course, don’t spend too much time reading :) Nothing beats lived experience.

7.2 Product Management

Another “management”-type position that engineers often move into is Product
Management (PM). Depending on who you survey, anywhere between 24% and
66% of PM’s were previously developers. Ask anyone whether PM’s need to
have technical backgrounds, and you will get 600 words of “It Depends”
dodging the question. Whatever - you can code, that certainly does not hurt -
now your task is to figure out whether Product Management is for you.

If you came into the tech world entirely via coding, PMs may seem like an odd
breed of Bullshit Job from a distance: they show up every couple weeks, tell
everyone what to do, and disappear to do god knows what, get mad when their
meticulously color coded Gantt charts run afoul of reality, and take credit for
everything when stuff is shipped.

I’m kidding. The variety of PM jobs and roles is even more diverse than EM
roles, if that is even possible. PMs are classically regarded as “mini-CEOs of the
product” - entrusted with bridging the gaps between engineering, design, and
business.
Product Management was created in 1931 at P&G, but the modern form of
Product Management in Tech owes its popularity to Marissa Mayer, pre-Yahoo,
when she was a rockstar executive at early Google. Google wanted to cultivate
“home-grown” managers who would be Googley, so the two-year Associate
Product Manager program was created. It spawned an entire generation of great
tech leaders like Bret Taylor, who co-created Google Maps, served as CTO of
Facebook, and is now President of Salesforce. Eric Schmidt has even gone on
record saying an APM alum will run Google someday (not yet true; current CEO
Sundar Pichai was a consultant before PMing for Chrome).

Given all this success, it is unsurprising that every tech company has some form
of PM function (Microsoft calls it “Program Manager”). Having worked at a
company that started with no PMs and eventually got some, it is very reassuring
to know that someone is herding all the cats and watching out for upcoming
blockers and cross-dependencies. Individual departments tend to get tunnel
vision, and tend to view their problems as more important than others. Founders
initially serve as PMs, but as the company scales, founders have other things to
do, so sooner or later they need to hire or promote product managers to “own the
product”.

For products that don’t serve developers (the vast majority of products), PMs
also tend to be the primary user advocates or domain knowledge experts.
Although UX/Design does do user research, Good PMs know everything about
the user personas, right down to what competitor products they use and what
kind of marketing channels work best for each. They will also know when to
ignore what research says - in a world of unambitious incremental
improvements, PMs can serve as “visionaries” that can galvanize a company’s
resources to create something that doesn’t yet exist.

“If I had asked people what they wanted, they would have said faster
horses.” - Henry Ford on the Model T (possibly apocryphal)

PM’s also used to write massive design specs called Product Requirements
Documents that would lay out every detail of how the product was to behave
(therefore a great amount of user research and some sense of engineering cost
was required) - in these days of Agile and Lean development, PRD’s are much
leaner and sometimes even optional. Being able to code up or mock up a quick
MVP for user testing is much more desirable these days.

PM’s being PM’s, every word of what I just wrote is hotly contested. PM’s have
all sorts of alternative Venn Diagrams to describe themselves, and have written
mountains of Medium posts on how they are Not the CEO of Anything. The
preferred framing these days is that PM’s have “All of the Responsibility, and
None of the Authority”, which makes you wonder how much sheer charm and
begging PM’s must subsist on to get shit done.

There is another type of “PM” that actually has little authority: Project
Managers. The Product Manager (sometimes called the “Product Owner”) sets
the vision for the product that needs to be built, gathers requirements, and
prioritizes them, while the Project Manager acts upon this vision and makes
sure that it is executed on time and on budget. In small companies, Product
Managers also serve as Project Managers. A poor or under-resourced “Product
Manager” will functionally regress to Project Manager, because that is the
absolute bare minimum needed to show life. However the long term value of
bumping cells on a spreadsheet or playing Calendar Tetris is not as high.

Here, a personal anecdote is relevant: I spent a year as a non-technical Product

Manager before deciding to change careers. Our startup had 60 devs, but each
time I worked with a team to produce a new product feature, I noticed that the
only people that got quality work done (and reasonably on time) were two devs.

Two out of 60.

This was evidently a highly dysfunctional dev team, of course, but the result was
any PM worth their salt would fight for time of these two devs in order to get
stuff done, and play Project Manager with the rest. When I got the job I was sold
on being a “mini-CEO” - but what I got was jockeying for position and weekly
“is it done yet?” calls. That’s the kind of PM you don’t want to be. Eventually I
had enough and decided to become a developer myself - the PM to Dev
transition is rare but I have started calling it “Team #FineI’llDoItMyself”. I
hope you DON’T join us!

The vast majority of PMs don’t also have unlimited license to “visionary” their
way to any cockamamie idea. Usually there is some direction from founders
(sometimes too much!) and major projects have to be agreed upon at the Board
level. In other words, the job does involve a lot more “get shit done” than
“visionary” in the day to day reality, at least until you earn some amount of
authority from successful projects.

Overall, PMing can still be a very rewarding post-coding career. If you have
entrepreneurial ambitions or desire even more impact than in Engineering
Management, the PM path is your best bet. PMs own product-level Objectives
and Key Results, and often have the ear of the highest levels of leadership when
critical goals are at stake. They may even own the Profit & Loss of their
product, if attributable. Products that have their own P&L also often run their
own marketing - this tends to be such a specialized skillset that paired Product
Marketing Managers and Technical Product Managers are common in BigCos.
People who are particularly good at high growth product marketing are known as
Growth Hackers, a term coined by Sean Ellis and popularized by Andrew Chen -
this is a great related discipline talented coders should explore.

Note: PM’s should care a great deal about everything we discuss in the
Strategy section of this book!

Recommended reads for those exploring the PM path:

Everything on Aha.io’s blog is great, as is MindTheProduct

Everything on Reforge’s blog is great, including Fareed Mosavat & Casey
Winters’ Crossing the Canyon
John Cutler’s blogposts, especially 12 Signs You’re Working in a Feature
Factory
Ben Horowitz’s Good Product Manager, Bad Product Manager
Brian Amstrong’s letter to new PMs at Coinbase
Dave Wascha’s 20 Years of Product Management in 25 Minutes
Kevin Lee’s PMHQ community and Merci Grace’s Women in Product
Try to have strong opinions on Product Hunt

7.3 Developer Relations

You are reading a book written by a developer relations professional - if you
follow 75% of the advice here, you will be well qualified to be a developer
relations professional. It just so happens that much of the same advice helps
coders in the non-coding aspects of their careers (which is the only reason this
book made sense to write).

So if you’ve read the book and practiced these Principles, Strategies, and Tactics,
we can assume you’re qualified and should easily get the job. Our task now is to
figure out whether you want the job.
There are many names for this job: Developer Evangelist, Developer Relations,
“Devreloper”, Developer Advocate, Developer Experience Engineer. For
convenience, we’ll just say “DevRel”, which is slightly better but not as fun as
“Developer Avocado”. As you might expect, titles aren’t standardized. They are
in theory different roles, but the reality is everyone performs some ill-defined
mix of all these roles. The best you might observe in titling trends is that
“Evangelist” is on its way out (too much of “I’m telling you to use my product”)
and “Advocate” and “Developer Experience” is on its way up (more focus on
being the user’s champion internally, or making the conversation a “two way
street”). However the shift in titles may not track closely with the actual
behaviors and incentives set up by the company.

It’s not a common job by any means - it only makes sense for developer-focused
companies to hire DevRels, and even in a “dev tools” company there might be
100 developers to 1 DevRel - but it is a very visible job (this is a very good
thing for midcareer developers). This means that even as a developer you’ll see
a lot of DevRel folks doing talks and such, and will naturally be curious about
joining their ranks.

This question cuts to the heart of DevRel - does DevRel belong in Product or
Marketing or on its own? Cynics will say Marketing, Users will hope it’s
Product, and DevRel folks want DevRel to stand alone as its own department.
What it actually is depends on how the company is actually run and how much
they walk their own talk. If you call someone a “Developer Advocate”, but they
spend functionally all their time producing content and are measured based on
user growth and have no input on product prioritization, how much are they
really “advocating” for users instead of to users? DevRel programs are
expensive, and the best way we know how to justify ROI on these things are all
Marketing metrics - which turns DevRel into Marketing despite the best
intentions of everyone concerned. What gets measured gets managed, and
DevRel is only just beginning to have an open conversation about how best to
measure DevRel (there may be no answer). Better run DevRel programs will
carefully design to prevent this, but enough DevRels are just “Very Expensive
Affiliates” or rebranded “Developer-friendly Marketing”, that it is worth a quick
warning to you.

As a potential DevRel, this is something you need to investigate at various

companies you consider, and also figure out where your own preferences lie.
There is such a thing as too much of a good thing. You have been told that
writing and speaking and Learning in Public are good for you, but it is a VERY
different proposition to have it become a full time job. Some people will love it -
being paid to raise your profile alongside the company’s, and to skill up on these
very critical skills for audience and network-building. For others, taking what
you used to do for fun and turning it into a job - with attendant metrics, quotas,
and a weekly schedule - kills all the fun and makes you a slave to the “content
grind”.

There is also the matter of perceptions - first that you are now a paid shill, and
second that you are no longer a “real developer”. Both are a little bit correct,
which is the worst kind of perception to fight. The truth is shades of gray:

To be an effective DevRel you must be advocating from a place of genuine

enthusiasm. However it is true that you are paid to plug your company’s
product, and while most employers are fine with you also talking about
other issues important to developers, all of them will constantly pressure
you to plug your company more and more. You have to balance this
pressure against your own interests and industry credibility.
To be a relatable DevRel you must be able to demonstrate that you can still
address problems real developers face. However it is true that you no
longer maintain a product in production, and you do spend a lot of your
time making tutorials that look nice in a talk or blogpost but omit a lot of
the inconvenient realities like testing, maintenance and cost (since you, of
course, also don’t pay for your own company’s products). You will have to
work hard to both demonstrate your product’s production-ready-ness (some
products don’t have this problem) and also make it approachable to
newcomers (all products have this problem). You should avoid being too
clubby with other DevRel people on the “conference circuit” to the
exclusion of “real developers” - most of whom only attend 1 conference a
year.

Travel used to be a major part of the job, and usually starts as a perk (wow I
visited 40 countries this year!) and becomes a chore (damn I spend more time in
the airport than with my kids). In the post coronavirus world, the focus has
entirely pivoted to online communities, which is great for the environment, but
also DevRel marketing budgets.
Nobody said it was easy. Couple this with the long term reality of DevRel - it
might be a dead end. It may be hard to switch from DevRel back to Engineering
or Engineering Management (although perhaps no harder than other switches,
difficult to say) and to date there is no room in the C-suite for DevRel folks,
while other tracks have clear paths to CTO or CPO.

However the job is still very rewarding - it can often feel like there is nothing
better than to be paid to talk about a tool you already use and love, and to spread
that joy and knowledge to others, who use it to make their lives and jobs better.
The audience and network you get from creating content all day will outlast your
employment - setting you up for success for anything you do next. The value of
this cannot be understated. But if I said more it’d feel like bragging.

As for the “dead end career” fear, Patrick McKenzie has this to say:

An observation: every developer evangelist I know goes into a

much better job right after they quit being an evangelist. This is not
true of other engineering jobs with checkered reputations, like e.g.
The Build Guy. Why do developer evangelists get upgrades but The
Build Guy(s) not? My bet is because evangelists literally spent years
meeting thousands of people and showing them “Hey, I’m going to
live code in front of you while also making my employers fat stacks of
money. You run a company and could use both engineers and money.
You should probably remember my name, you know, just in case.”

I unfortunately have not done this job long enough to have enough data to prove
or disprove this. It’s quite possible nobody has. It is pretty common to see
DevRels go on to other DevRel jobs, though that is neither here nor there. It
does feel like DevRel can be a close kin to Product Management for a technical
product, because of the similar focus on users.

DevRels don’t have a monopoly on speaking or writing about the company. The
less jealously they guard this, the better. In fact, the most successful DevRel
programs will be a great partner for internal engineering teams to speak out with
pride about their work and their products. This basically always works out well -
the eng teams get to brag, audiences see nontrivial work from unquestionably
“real” engineers, and customers get to peek behind the curtain of what they’re
buying. It even makes hiring much easier. Dan Luu has great thoughts on how
good corporate engineering blogs are written. At companies with very engaged
user bases, user groups and community meetups can perform this function too.
Pragmatically speaking, enabling the voices of others to be heard is the only way
to scale DevRel reach beyond a linear growth in DevRel headcount. Being able
to Build Community is therefore the ultimate skill of a DevRel.

Recommended Reads:

Kim Maida: Building Developer Communities

Keith Casey: Developer Evangelism: The Whole Story
Nader Dabit: 7 Tips for Breaking Into DevRel
Emily Freeman: Developer Relations: (More Than) The Art of Talking
Good
Get Together: a book and podcast about community builders, by community
builders.
The various DevRelCons and Summits around the world

7.4 Developer Education

Instead of a company paying you to create content for their products, why not
have your audience pay you to create content to teach them? What a novel idea!
This is the territory of the Developer-Educator, a title I just made up, because
“instructor” or “trainer” felt too bland.

You know what this job is, because you’ve probably learned from people who
are full-time educators already. It is quite similar to the DevRel job, except that
the output is usually more productized, with a heavy emphasis on product
marketing, because they quite literally live by what they make from their
courses, workshops and books.

Developer Education is DevRel on Hard Mode, with the accordant risks and
rewards. The money you make as a DevRel is constrained by your company’s
payscale. If you do an AMAZING job and 3x new users, you don’t see a
proportionate dime. This is fine, because if the inverse happens and users fail to
meet targets, you are also (somewhat) protected. One advantage of Developer
Educators over DevRel is that they can focus on foundational technologies that
everybody already uses, whereas the point of DevRel is partially to get people to
try out proprietary things they don’t yet use.

Developer Educators have a 100% stake in their ability to create quality content
and market it - you might make a pittance, or you might be a multi-millionaire,
as many good Developer Educators are. A good Developer Educator might
spend six months building a course and make 500k-1 million, and spend the
remainder of the time audience building and gathering ideas for the next course.
The problem, of course, is that those are the successful ones. The less successful
ones struggle to get attention, and spend hundreds of hours creating content, and
don’t make a dime.

Developer Educators also face the conundrum of having to create a lot of

beginner content. Being able to code well doesn’t mean you can teach it well.
Additionally, beginner content always makes a lot more money than
advanced content, because there are just mathematically more beginners, but it
can be less intellectually stimulating to produce the 9457th explanation of map
vs forEach. You might reframe your work as teaching “foundational”, rather
than “beginner”, content, but you can’t escape the need to place your own spin
on it just to keep things interesting. Your freedom to explore your intellectual
interests isn’t zero, but it does have a limit, because you do have to give the
market what it wants.

Because Developer Educators are mostly independent, they don’t have a

company brand or product behind them. They are the brand. Therefore they
need to be exceptionally good at marketing, and in fact, all the other things that
are involved in running a small solo business. Here’s a list of the multiple
disciplines from David Perell:
You don’t have to go fully-independent to be a Developer Educator. Plenty of
professional education platforms like Pluralsight, LinkedIn Learning, Treehouse,
Frontend Masters and Egghead.io help working developers produce courses and
also take care of marketing and payments, in exchange for a sizable ( 70%?)
cut of the revenues. It is a great way to try it out, as content creation is the most
difficult part of the job, and also a great way to create a stream of passive income
should you decide not to pursue doing it fulltime.

Recommended Reads:

Kent C. Dodds: I’m a full-time educator! (via Egghead)

Wes Bos: Creating & Launching your own Products (creating his own
course platform)
Troy Hunt: Hack Your Career (gaining independence via Pluralsight)
Cory House: The 7 Pillar Developer (going into fulltime training)
Adam Wathan: Nailing Your First Launch (selling ebooks)
7.5 Entrepreneurship
Finally there is the category of entrepreneurs - ranging from one-person
Developer Educator businesses, to solo “indie hackers”, to bootstrapped or indie
startups, to full-on venture-backed startups. As someone who can code, you can
create something of great, scalable value with your bare hands, and that is a
mighty power indeed.

It’s well understood that most startups fail. Bad ideas exist. You might find a
gap in the market, but there may be no market in that gap. You know that you
are supposed to make something people want, but the problem is that people
often don’t know what they want until they see it. You can’t even ask them – as
David Ogilvy once observed: “The problem with market research is that people
don’t think how they feel, they don’t say what they think and they don’t do what
they say”.

Even for those that do succeed, there are long, lean years of nothing while you
build a business. Gail Goodman famously called it the Long, Slow Ramp of
Death. Your opportunity cost - what you might otherwise earn instead as a
Senior Developer if you didn’t try to be a founder - is extremely high, possibly
in the millions. This is one of many reasons why not to start a startup (here is a
longer list, with Paul Graham’s responses). In fact it is often said that you
should not start a startup to get rich, you should do it because you feel compelled
to create something that should exist but doesn’t. Getting rich is a side effect if
you are right.

There are smart ways you can de-risk this, for example by leaving your current
company with a deal that they will become your first customer, or you can get
really desperate and sell politically themed cereal to fund your startup.

As a developer, you must acknowledge that your bias will be to try to code your
way out of any problem because that is what you are good at and enjoy doing.
However this avoids the hard parts of talking to the customer: finding out what
they want (product management), getting in front of them (marketing) and
convincing them to buy (sales). You cannot escape that Entrepreneurship folds
up all the worst of everything we have discussed in this chapter, from people
management to product management to marketing, and makes it your full time
job, on top of which you still have to code. However, the upsides are
accordingly greater.

There are some major forks in the road when it comes to entrepreneurship. The
right answer is usually somewhere between two extremes:

Product- or Engineering-Driven: Either work out people want and then

figure out a way to make it, or figure out what you can make and work out
how to make people want it.
Venture Capital vs Bootstrapped: Some people are absolutists about what
kind of entrepreneurship they pursue – either VC is evil and they will
bootstrap no matter what, or life is short and they want to go for broke.
This seems unwise. Match your funding structure to your opportunity: if
you see a land-grab, winner-takes-most opportunity with network effects,
take VC (or Venture Debt) to get there; if not, bootstrap it. Either way, the
more profitable you can be per new user, the better the economics will be
for you on any deal you make. If you belong to an underrepresented
minority, don’t forget that there are diverse funds like #ANGELS,
Backstage Capital and Astia Global that defy Silicon Valley’s pattern
matching biases. Lastly, note that there are also newer hybrid models like
Indie.vc and Earnest Capital that blend characteristics of VC and
Bootstrapping.
B2B vs B2C: Whether you sell to businesses or you sell to consumers can
make a huge difference in your economics. Businesses can afford higher
prices and can have comparatively lower churn ( 1%), but there are fewer
of them and it can cost more to reach them. Consumers are plenty and easy
to reach via performance marketing and social media, but they are very
price sensitive and 5-10% monthly churn is not uncommon. The term
“B2B2C” is often used for Marketplaces, Platforms and Aggregators
(Chapter 27). In recent years, the Developer Tools market has been gaining
steam and dedicated investment because of the realization that developers
can be marketed to like Consumers but can spend like Businesses.
Self Service vs Enterprise: B2B customers like to buy in different ways.
The traditional way of selling software, from the days of IBM, Oracle and
Salesforce, is “top-down”: Hiring very expensive salespeople in very
expensive suits to get into the right meetings with the CTO/CEO, then
rolling it out across the company after the sale was already made.
The recent history of software startups has completely reversed this:
Atlassian (makers of JIRA) is notable for bootstrapping for 13 years before
IPO using purely “bottom-up” sales – offering cheap, self-service price
plans that individual users could put on their own credit cards without
blinking. This doesn’t mean that they eschew selling to the enterprise
completely - in fact, the C-suite meeting can be a far easier sale when you
can say “half of your employees already pay out of pocket to use our
product, here are dashboards and extra features you can get if you sign right
here.”
It’s possible to take “bottom-up” too far – there are great security and
compliance reasons to extensively vet any vendor. From the founder side of
things, enterprise money is usually far stickier (less churn) and higher
margin (more profit). The good news is that “Enterprise features” are
relatively standard – everybody wants Single Sign On, On-Premises
Software, Audit Logs, Team Management, SLAs and so on – so much so
that checklists and even entire startups have been made to help you with
this.
Products vs Services: In the context of a software startup, Services mean
writing custom software tailored to the needs of each individual customer,
and Products mean writing one set of software that all customers use.
Products are more scalable, because every feature added is immediately
useful to all customers (including future ones), while Services are more
sellable, because you are directly addressing the needs of each user. A lot
of people get caught up in the idea that products are better than services,
because they want to do things that scale (and a pure Services business is
basically a consulting shop that refuses to admit it).
However, in the early days, you may want to start with products first.
Oddly enough, this is the one thing that both VC’s and Indie Hackers agree
on. In the Indie commmunity, this is widely known as the stairstep or
ladder approach. Then you can start getting into Productized Services. The
VC/YC community calls this Do Things that Don’t Scale. In short, you can
offer “Service as a Service” before you make “Software as a Service”.
Performing Services gets revenue in the door earlier, while making sure you
are hyper attuned to customer needs. Instead of being off in your own
world building product nobody wants, you can build your product internally
 to serve your needs, and then eventually let the “Services Facade” fade
away and users can use your product directly. This can take a long time and
will never quite go away: Chetan Puttagunta, a notable software startup
investor, notes that at $60m in revenue, half the revenue of software
startups are services, but even at $800m, services revenue is still at 20%.
You could frame this as Product Core, Services Shell.
Horizontal vs Vertical: You can build a “one stop shop” solution for one
specific type of customer, or one solution for many different types of
customer that “does one thing well”. It’s often easier to start with the
former, because the customer focus feels easier to develop for, but the risk
is that you end up building a crappy version of many things that already
exist. Still, Joel Spolsky argues that “vertical software is much easier to
pull off and make money with, and it’s a good choice for your first startup.”
You can be enormously successful doing either. Probably the one thing
everyone agrees on is to not try to do both in the early days.

For more on this and other aspects of Software business models,

head to Intro to Tech Strategy (Chapter 27).

The best advice on starting up comes from the Indiehackers community and
podcast. For developers, there’s no need to go anywhere else.
Chapter 8
Part II: Principles
Principles are ways of successfully dealing with reality to get what
you want out of life. - Ray Dalio

Let’s discuss the Principles that you should consider adopting throughout your
Coding Career:

Learn in Public (Chapter 9)

Clone Open Source Apps (Chapter 10)
Know Your Tools (Chapter 11)
Specialize in the New (Chapter 12)
Open Source Your Knowledge (Chapter 13)
Spark Joy (Chapter 14)
The Platinum Rule (Chapter 15)
Good Enough is Better than Best (Chapter 16)
First Principles Thinking (Chapter 17)
Write, A Lot (Chapter 18)
Pick Up What They Put Down (Chapter 19)
Chapter 9
Learn in Public
There are many principles offered in this Coding Career Handbook, but this is
chief among them: Learn in Public.

9.1 Private vs Public

You have been trained your entire life to learn in private. You go to school. You
do homework. You get grades. And you keep what you learned to yourself.
Success is doing this better than everyone else around you, over and over again.
It is a constant, lonely, zero-sum race to get the best grades. To get into the best
colleges. To get the best jobs. If you’ve had a prior career, chances are that all
your work was confidential. And of COURSE you don’t share secrets with
competitors!

Tech is a fundamentally more open industry. We blog about our outages. We

get on stage to share our technical achievements. We even give away our code in
open source. However, most developers act like tech is the same as every other
industry. Most developers bottle up everything they learn in their heads, all the
while hoping their careers grow linearly with years of experience at the right
companies working on the right projects for the right bosses. Most developers
strictly consume technical content without actually creating any themselves.

This is a perfectly fine way to build a career: 99% of developers operate like
this. Scott Hanselman calls them Dark Matter Developers — you can infer their
presence from GitHub stars and package downloads, but it’s hard to find direct
evidence of their work. Their network mainly consists of current or former
coworkers. When job hunting, they start from zero every time. They find
opportunities only from careers pages or recruiters. To get an interview, they
must serialize years of experience down into a one page resume by guessing
employers’ opaque deserialization and filtering algorithms. Then they must
convey enough in 30-60 minute interviews to get the job. Even while on the job,
picking up a new technology is a solitary struggle with docs and books and
tutorials.

There is another way. You can Learn in Public instead.

What do I mean by learning in public? You share what you learn, as you learn
it. You Open Source your Knowledge (Chapter 13). You build a public record
of your interests and progress, and along the way, you attract a community of
mentors, peers, and supporters. They will help you learn faster than you ever
could on your own. Your network could be vast, consisting of experts in every
field, unconstrained by your org chart.

When job hunting, prospective employers may have followed your work for
years, or they can pull it up on demand. Or — more likely — they may seek you
out themselves, for one of the 80% of jobs that are never published. Vice versa,
you take much less cultural risk when you and your next coworkers have known
each other’s work for years. And when picking up a new technology, you can
call on people who’ve used it in production, warts and all, or are even directly
building it. They will talk to you — because you Learn in Public.

I intentionally haven’t said a single word about “giving back to the dev
community”. Learning in Public is not altruism. It is not a luxury or a nice-to-
have. It is simply the fastest way to learn, establish your network, and build your
career. This means it is also sustainable, because you are primarily doing it for
your own good. It just so happens that, as a result, the community benefits too.
Win-win.

You never have to be 100% public. Nobody is. But try going from 0% to 5%.
Or even 10%! See what it does for your career.

Tip: Some vulnerable people have personal safety or other reasons to

not Learn in Public. These are totally valid. Since the majority of the
time, we all are still Learning in Private, it’s worth thinking about
how to do that well too. Refer to Chapter 32 for a fuller discussion.
9.2 Getting Started
Make it a habit to create “learning exhaust” as a non-negotiable and automatic
side effect of your own learning:

Write demos, blogs, tutorials and cheatsheets

Speak at meetups and conferences
Ask and answer questions on Stack Overflow or Reddit
Make YouTube videos or Twitch streams
Start a newsletter
Draw cartoons (people loooove cartoons!)

Whatever your thing is, make the thing you wish you had found when you
were learning. Document what you did and the problems you solved. Organize
what you know and then Open Source Your Knowledge.

You catch a lot of friends when you are Helpful on the Internet. It is
surprisingly easy to beat Google at its own game of organizing the world’s
information. Even curating a structured list of information is helpful. I once put
together a list of Every Web Performance Test Tool on a whim and it got
circulated for months! People reshared my list and even helped fill it out.

“But I’m not famous, nobody will read my work!” — you, probably

Don’t judge your results by retweets or stars or upvotes — just talk to yourself
from three months ago. Resist the immediate bias for attention. Your process
needs to survive regardless of attention, if it is to survive at all. Eventually,
they will come. But by far the biggest beneficiary of you helping past you, will
be future you. If (when) others benefit, that’s icing on the cake.

This is your time to suck. When you have no following and no personal brand,
you also have no expectations weighing you down. You can experiment with
different formats, different domains. You can take your time to get good. Build
the habit. Build your platform. Get comfortable with your writing/content
creation process. Ignore the peer pressure to become an “overnight success” —
even “overnight successes” went through the same thing you are.

I get it: We all need feedback. If you want guaranteed feedback, Pick Up What
Others Put Down (Chapter 19). Respond to and help your mentors on things
they want, and they’ll respond to you in turn. But sooner or later, you’ll have to
focus on your needs instead of others. Then you’re back to square one: having to
develop Intrinsic Drive instead of relying on External Motivation.

9.3 But I’m Scared

Try your best to be right, but don’t worry when you’re wrong. Keep
shipping. Before it’s perfect. If you feel uncomfortable, or like an impostor,
good. That means you’re pushing yourself. Don’t assume you know
everything. Try your best anyway and let the Internet correct you when you are
inevitably wrong. Wear your noobyness on your sleeve. Nobody can blame you
for not knowing everything. (See Lampshading, Chapter 34, for more)

People think you suck? Good. You agree. Ask them to explain, in detail, why
you suck. Do you want to feel good or do you want to be good? If you keep
your identity small and separate your pride from your work, you start turning
your biggest critics into your biggest teachers. It’s up to you to prove them
wrong. Of course, if they get abusive, block them.

You can learn so much on the Internet, for the low, low price of your Ego.
In fact, the concept of Egoless Programming extends as far back as 1971’s The
Psychology of Computer Programming. The first of its Ten Commandments is
to understand and accept that you will make mistakes. There are plenty of
other timeless takes on this idea, from Ego is a Distraction to Ego is the Enemy.

Don’t try to never be wrong in public. This will only slow your pace of learning
and output. A much better strategy is getting really good at recovering from
being wrong. This allows you to accelerate the learning process because you no
longer fear the downside!
9.4 Teach to Learn

“If you can’t explain it simply, you don’t understand it well enough.”
- Albert Einstein

Did I mention that teaching is the best way to Learn in Public? You only truly
know something when you’ve tried teaching it to others. All at once you are
forced to check your assumptions, introduce prerequisite concepts, structure
content for completeness, and answer questions you never had.

Probably the most important skill in teaching is learning to talk while you code.
It can be stressful but you can practice it like any other skill. It turns a mundane
talk into a captivating high-wire act. It makes pair programming a joy rather
than a chore. My best technical interviews have been where I ended up talking
like I teach, instead of trying to prove myself. We’re animals. We’re attracted to
confidence and can smell desperation.

9.5 Mentors, Mentees, and Becoming

an Expert
Experts notice genuine learners. They’ll want to help you. Don’t tell them, but
they just became your mentors. This is so important I’m repeating it: Pick up
what they put down. Think of them as offering up quests for you to complete.
When they say “Anyone willing to help with __ __?”, you’re that kid in the first
row with your hand already raised. These are senior engineers, some of the most
in-demand people in tech. They’ll spend time with you, one-on-one, if you help
them out (p.s. There’s always something they need help on - by definition, they
are too busy to do everything they want to do). You can’t pay for this stuff.
They’ll teach you for free. Most people miss what’s right in front of them. But
not you.

“With so many junior devs out there, why will they help me?”, you ask.
Because you Learn in Public. By teaching you they teach many. You amplify
them. You have the one thing they don’t: a beginner’s mind. See how this
works?

At some point, people will start asking you for help because of all the stuff you
put out. 99% of developers are “dark” — they don’t write or speak or participate
in public tech discourse. But you do. You must be an expert, right? Your
impostor syndrome will strike here, but ignore it. Answer as best as you can.
When you’re stuck or wrong, pass it up to your mentors.

Eventually, you will run out of mentors and will just have to keep solving
problems on your own, based on your accumulated knowledge. You’re still
putting out content though. Notice the pattern?

Learn in Public.

P.S. Eventually, they’ll want to pay for your help too. A lot more than
you’d expect.

9.6 Appendix: Why It Works

You might observe that I write more confidently here than anywhere else in the
book. This confidence is based on two things:

Empirical foundation: I have studied the careers of dozens of successful

developers, and have personally heard from hundreds of others since I
wrote the original essay.
Theoretical foundation: Everything here is reinforced by well understood
dynamics in human psychology and marketing.

We take advantage of these laws of human nature when we Learn in Public:

The 1% Rule: “Only 1% of the users of a website add content, while the
other 99% of the participants only lurk.” You stand out simply by showing
 up.
Cunningham’s Law: “The best way to get the right answer on the Internet is
not to ask a question; it’s to post the wrong answer.” Being publicly wrong
attracts teachers, as long as you don’t do it in such high quantity that people
give up on you altogether. Conversely, once you’ve gotten something
wrong in public, you never forget it.
Positive Reinforcement: Building in a social feedback mechanism to your
learning encourages more learning. As you build a track record and embark
on more ambitious projects with implicit future promise, your public
activity becomes a Commitment Device.
Availability Bias: People confuse “first to mind” with “the best”. But it
doesn’t matter — being “first to mind” on a topic means getting more
questions, which gives the inputs needed to become the best. As Nathan
Barry observed, Chris Coyier didn’t start out as a CSS expert, but by
writing CSS Tricks for a decade, he became one. This bias is self-
reinforcing because it is self-fulfilling.
Bloom’s Taxonomy is an educational psychology model which describes
modes of learning engagement — the lowest being basic recall. Learning
in Public forces you toward the higher modes of learning, including
applying, analyzing, evaluating, and creating.
Inbound Marketing: Hubspot upended the marketing world by proving you
didn’t have to go out in front of people to sell. Instead, you can draw them
to you by making clear who you are and what you do, offering valuable
content upfront and leaning on the persuasive power of Reciprocity and
Liking.
Productizing Yourself: By creating learning exhaust, you can teach people
and make friends in your sleep. This disconnects your networking, income,
and general Luck Surface Area from your time. Don’t end the week with
Nothing. This is Portable Personal Capital that compounds over time and
that you can take with you from company to company.

9.7 Appendix: Intellectual History

I didn’t invent Learn in Public. The earliest mention I’ve found is this
retrospective on how NASA Scientists do organizational Knowledge
Management. Since then, everyone from Jeff Atwood to Kelsey Hightower to
Kent C. Dodds attribute their success to some form of Learning in Public. Reid
Hoffman, who studies great tech leaders from Brian Chesky to Jeff Weiner, calls
it Explicit Learning. In fact, everyone you’ve ever heard of, dating back to Plato
and Aristotle, you’ve heard of because they wrote down and shared what they
thought they knew. Your learnings may outlive you.

I wasn’t the first to benefit from this, and I won’t be the last. The idea is now as
much yours as it is mine. Take it. Run with it. Go build an exceptional
career in public!
Chapter 10
Clone Open Source Apps
I get asked all the time “how do I level up?” My favorite thing to do is
find some OSS thing that seems a little beyond my experience to build
(…) and then try to build it, referring to the OSS source only when
you’re totally stuck. - Ryan Florence

You already know you should be making projects to learn things and potentially
add to your portfolio. You’ve read your Malcolm Gladwell, you know that you
need 10,000 hours of deliberate practice. Given you’re just starting out, I have a
slightly contentious suggestion for you: DON’T make anything new.

Your decision-making is a scarce resource. You start every day with a full tank,
and as you make decisions through the day you gradually run low. We all know
how good our late-late-night decisions are. Making a new app involves a
thousand micro decisions - from what the app does, to how it should look, and
everything in between. Decide now: Do you want to practice making technical
decisions or product decisions?

Ok so you’re coding. You know what involves making zero product decisions?
Cloning things. Resist the urge to make your special snowflake (for now). Oh
but then who would use yet another Hacker News clone? I’ve got news for you:
No one was gonna use your thing anyway. You’re practicing coding, not making
a startup. Remember?

Make the clone on your own, then check the original’s source. Now you have
TWO examples of how to implement something, so you even get to practice
something people only do after years of experience: understanding the tradeoffs
of technical choices!

You’re lucky. You live in an age where companies open source their entire apps:
 Spectrum
Codesandbox
FreeCodeCamp
Ghost
DEV
GitLab
Fathom

If those seem like waaay too big of an app for you to clone (they are huge), go
look at the side projects of your mentors. For example, for front-end devs:

Ryan Florence has Planner

Kent C. Dodds has TIL
Christopher Chedeau has Excalidraw
Daniel Vassallo has Userbase

Make a clone, then show it to them! You are virtually guaranteed to get free
feedback. It doesn’t have to be someone famous. You can even try clones of
clones:

Smoen Sanders’ Instagram clone

Muzamil Sofi’s Twitter clone
Trello Clones and JIRA Clones
Retro Windows UIs are very popular!

You don’t even have to work on apps, if you want you can build your own
clones of popular libraries and frameworks. Daniel Stefanovic’s Build Your
Own X repo is a treasure trove of tutorials for these if you need help.

“In the art/design community there’s a word for it, “copywork“…

There are a lot of nice things about copying existing stuff: you don’t
have to think through how interactions should work (just copy them),
you can focus on learning one thing at a time, and you get to choose
your own difficulty setting.” - Dave Ceddia
If you’ve picked a technology to specialize in (Chapter 12): Clone apps using
your technology and demonstrate how it is better and also make fixes where it is
worse. This sounds mundane, but Plugging Holes In The Internet is a reliable
strategy for making friends fast and making fast friends. react-router was
built by early adopters of React who missed the old router from Ember, so they
plugged that hole in the React ecosystem. It then made their reputations.

Put a time limit on it. Deadlines work wonders. Also you’re not going for a
pixel perfect clone of something that teams of people, way more experienced
than you, have made. You want to have a set amount of time, get as much of the
interesting features as possible, and then ship it. This guarantees that you will be
freed up for the next clone, and the next. Different projects let you try different
libraries and stacks, and figure out what you like there. Also you get to practice
one of the hardest software engineering skills of all: Project Estimation. You’ll
create many, many opportunities for yourself to see what you can do in a set
amount of time because you’re deliberately practicing making things on the
clock. And none of that time is taken up by product decisions!

When you’ve done enough and start feeling bored, it’s time to let your freak flag
fly. You’ve earned the right to make your app because you’ve made others. You
know what things cost and you have used your tools well enough to get there.
You’re still learning in public, though! Package up your experience into a talk.
Livestream yourself coding. Blog about your game plan, then blog some more
as you execute it. Developers who can Work in Public are in far more demand
than developers who can’t.

Note: See the Side Projects chapter (Chapter 37) for more discussion
on starting and managing side projects.
Chapter 11
Know Your Tools
You skim over a lot in your learning. This is because developer marketing is
heavily incentivized to make things look easy. Look how fast you can do X!
Look how few lines of code it takes to do Y! It works, and you benefited by
getting productive fast.

But soon enough you run into problems. Your “Hello World” stops working
when you deploy it (most tutorials neglect deployment instructions). Your code
is insecure (security makes for slow demos). You are scared to make changes to
your config because it blows up when you so much as look at it.

It’s not your fault, but it’s in your power to fix your gaps. The tutorial/bootcamp
gave you a head start, now you have to go the distance.

A poor craftsperson blames their tools. A great craftsperson knows their

tools intimately.

If you’re a frontend dev: Learn Webpack. Learn Babel. Learn what the CSSWG
and TC39 do. Heck, learn Javascript and CSS all over again. Did you know you
can use the Chrome Devtools as a profiler and an IDE? Learn bash. Learn git.
Learn CI/CD. Open node_modules. Yeah, it’s a lot, and nobody knows
everything. But take the effort to learn the tips and tricks and failure modes of
your tools.

Equally important is figuring out what is OK to miss. I have my list, if I shared

it I’d piss off a lot of people. But there are some things you will use daily in
whatever career you end up in, and some other things seem important but are
really just nice-to-have. Figure out the difference. Tech is a house of cards a
mile high, abstractions atop abstractions. Lower levels of abstraction have a
longer half-life than higher ones. Kyle Simpson says you should learn one
abstraction level below where you work.
11.1 Avoid FOMO
Your favorite thought leader says you should check out ReasonML, is Javascript
dead? Why the hell do people want to kill Redux so bad? Is CSS-in-JS literally
the devil? Vue passed React in Github stars, should you pivot to Vue? I dunno,
do you get paid in Github stars?

Fill in -your- gaps. Read technical books cover to cover. For <$100 and a few
focused days you can download world class expertise on anything.

Focus on you and your employer’s needs. There are so many opportunities in
tech that you can pretty much pick out your turf and play entirely within it AND
be completely ignorant of all the other stuff AND still do great!

Don’t get me wrong: I’m a big fan of playing the meta-game. It is possible to
make strategic blunders but it’s also impossible to avoid them altogether. Stop
trying. It’s much better to focus on the “good enough” and be directionally but
not literally correct (Chapter 16). The goal is to be accurate, not precise. Try
your best to be right, but don’t worry when you’re wrong.

11.2 Beyond the Tool

There’s more to knowing your tools than just knowing what they are. Your tools
will stop serving you well when your needs go beyond the scale and speed
assumptions they were designed for. In those cases, knowing the design
patterns that underlie those tools, and being able to look for new tools or make
your own will come in extremely helpful.

There’s also the why and the who. Who made the paradigms we live in now?
Who’s maintaining it today? Why is the API the way it is? Why did it change
from past versions? (If you’re feeling adventurous: how does the tool work
under the hood?) Let your intellectual curiosity carry you and fill in your lack of
experience with research that nobody else bothers to do.
To give you an example knowledge graph traversal with React: Many workshops
portray “Advanced React” as using some lesser known hooks or deploying
production metaframeworks like Next.js. But this omits so much:

What did the initial prototype of React look like?

How did React first find significant outside traction with the Clojurescript
community?
What are the founding principles behind React’s initial and ongoing
design?
What conventional wisdom is regretted or often misunderstood about
React?
What APIs were tried and failed, and why did they not succeed?
How do you contribute to React and how would you add a new feature?
What do people who use React’s major alternatives say about React’s
tradeoffs and drawbacks?
If you can make a tiny clone of React that does everything you normally
use React for, what else does React do that you don’t know about?

Swap React for whatever technology you are trying to learn. Knowing how to
know your tools is timeless. Be able to explain them from first principles
(Chapter 17)!

Compared to other academic pursuits, there could not be an easier subject matter
to research, this stuff is literally all online and version controlled with git, and all
the people involved are still alive and easily contactable.

And when you’ve filled something in, when you’ve found something cool in
your research, write it up. Preferably in public!
Chapter 12
Specialize in the New
You already know the value of a niche - your market value increases the more
specialized you are in anything. So what should you specialize in? There are
many schools of thought, including ones where you could be a generalist that
doesn’t specialize at all.

Note: For a deeper discussion, see the Specialist vs Generalist

chapter (Chapter 23).

I find one rule to be the simplest and most effective of all: Specialize in the
New.

Isn’t FOMO bad? Well yes, that’s an important distinction — don’t specialize in
everything new. Specializing means you have to say no to a lot of things. Just
pick something new that fascinates you, and hopefully many other people as
well. Since you’re learning in public, you’ll know when you hit on a real
nerve. Budget in the idea that you’ll fail a few times before you find Your
Thing.

Note: It doesn’t have to be the absolute newest thing. In terms of

where you are in the Rogers adoption curve, the sweet spot is just
before the transition from Early Adopter to Early Majority. But you’re
also fine betting heavily as a Megatrend goes from Early to Late
Majority. For a deeper discussion, see the Strategic Awareness
chapter (Chapter 28).

Then the other big objection: There are plenty of jobs in (fill in the blank older
technology) too! This is usually followed by some big numbers and anecdata.
“My brother’s cousin’s roommate’s friend took this COBOL job and now she’s
earning six figures on the beach in Tahiti!” And it’s true - you can probably find
a job doing PHP or Angular for the rest of your life.

If that works for you, good. I will never say there is only one path to success.
Here’s why I don’t do it. It is far easier to rise up the ranks quickly in a new
space than in an old, crowded space.

Note: I discuss a short list of people who made their careers betting
early on tech in Betting on Technologies (Chapter 24).

You know how people rant and rail against companies who hire based on years
of experience? That could go away tomorrow and you’d still have
clients/employers silently comparing your length of experience to your
competition’s. It’s human nature.

But you know where it’s impossible for someone to have five years’ experience
doing X? When X is less than five years old.

There’s a practical element to it as well - technologies accumulate a LOT of cruft

over time. Best practices form, some of which are great, but some of which are
total BS. And all are stamped by early experts as The Right Way To Do Things
because Reasons. Books are written, careers are made. If you choose to play on
their turf, you’ll eventually need to read/deal with/overcome all of that history.
Even if you work twice as hard as the average developer, you can only make up
for all the context you missed half as slowly.

When is it possible to have read everything ever written about something?

When it’s new.

12.1 Technology Complements

Focus right next to where others are investing heavily. Joel Spolsky notes
that demand for a product increases when the price of its complements
decreases.

“Complements” are an abstract idea so let me draw an example. If you brand

yourself as a Firebase consultant and Google keeps adding and bug fixing
Firebase functionality, they are in a small way working for you. When Google
invests more in Firebase, you win too.

As a developer (and not a startup) you don’t even have to make the bank shot of
finding the overlooked adjacencies next to an area of heavy investment. You can
just focus on the area directly and let the market tell you where gaps exist.
What’s broadly true is that heavy investment often leads to the cost of that thing
decreasing, as the usual plan is larger scale with lower unit cost.

Again, refer to the Strategic Awareness chapter (Chapter 28) for

more on complements and Wardley Mapping.

I have an economics background so if I lost you there, I apologize. But I wanted

to impress on you that picking the right horse in this game of “Specializing in
the New” isn’t that hard. The market is going to make it fairly obvious. More
people don’t do it because they are busy being experts of other, older things. In
this green field space, your “weakness” (not having a domain you “own”)
becomes a strength (having no prior commitments).

Plant your flag on fertile ground, and say, “this is what I do”. It will carry
you far.

12.2 Lindy Compounding

Everyone focuses on the second part of this principle (“the New”) and not
enough on the first: “Specialize”. Settle new ground, but don’t hop.

You may be familiar with the “Lindy Effect” - the idea that the future life
expectancy of a thing is proportional to its current age. This is commonly
expressed as something negative. If someone tells you their project will be late
by ten days, you can expect it to take another ten days from that, and so on. It
isn’t meant to be taken literally - since nothing lasts forever - but it does describe
the tendency of deviations to correlate rather than remain independent.

Side note: In econometrics, this is known as Autoregressive

Conditional Heteroskedasticity.

However, the idea also applies positively. Taleb notes in his book Antifragile
that if something has remained relevant for 50 years, it can be expected to
remain relevant for another 50 more.

We can also apply this concept to the way that we specialize in the new:

You can think of the typical developer’s approach to new technologies as

skeptical and/or noncommittal. They hop around from Technology A to B to C
to D. It’s easier to pick up something if you don’t intend on sticking with it for
long. The stakes are low.
Things change when you assess technologies with an intention of working with
them for a long time, and then put in the effort to do so. You start picking up
things at a slower rate, but your total productivity soars because of the lower
churn. “Fewer for longer” seems like a great policy!

Taking advantage of the Lindy Effect to compound your productivity is a force

multiplier for the finite time you have.

Note: For a deeper discussion, see Betting on Technologies

(Chapter 24).

As an aside, building your network also benefits from Lindy Compounding as

well. If you go through life with a series of short-lived work acquaintances, you
don’t build much of a network and miss the benefits of long-lasting
relationships. How you approach people at work completely changes once you
realize this important fact: Your professional relationships will outlast your
current employment. Your loyalty to great people you find on your way will
pay off far more than your loyalty to your current company.

Building a network and picking technologies both compound in the same way.
The reason is because they are basically the same thing - technologies are built
by people. Therefore: Play long term games with long term people.
Chapter 13
Open Source Your Knowledge
Open Source Code wasn’t always the norm.

The Unix operating system was created in the 1970s and freely licensed to
academic and business institutions for a decade, before Bell Labs decided to
charge for it as a proprietary product. Frustrated with this, Linus Torvalds
created and released Linux in 1991. Today, 97% of web servers run Linux.

Similarly, most software you use today is mostly open source. The expectation
is that the open source alternative to a closed source codebase will eventually
win:

PostgreSQL has superceded Oracle in every dimension from features to

developer experience, on a fraction of the budget.
Anders Hjelsberg, creator of Turbo Pascal, Delphi, J++, C# and TypeScript,
now says no language will be closed source ever again. Can you imagine
having to pay a company just to use a language today?
Even in proprietary application code, 97% of it is open source libraries and
components, according to npm.

What happened to Code is happening to Knowledge.

13.1 Open Knowledge

We can all do more to share knowledge openly. Open Knowledge is polished,
highly produced information shared in public - books, blogposts, cheatsheets,
talks, libraries, and, increasingly, data, which the Open Knowledge Foundation
promotes.
In my former Finance career, everything I did was property of my fund, and we
never shared our insights to advance the industry. This arises from a Zero-Sum
view of value creation. It’s a shame - I did some of the best work of my life in
that job, and it is trapped in some mailbox somewhere and nobody will ever see
it again. Not even me.

The Tech Industry is fundamentally more open. This is wonderful. Now we not
only share most of our secrets, we can get up on stage and tell our peers about it,
and get rewarded for it! Every company understands the value of blogging, and
we often even give away our code.

But even this is a highly choreographed, high-barrier-to-entry process. Open

Knowledge (for example, a technical book) is usually produced as a heavy lift,
by one person or group of people, and it has a finite release date after which the
released knowledge can be assumed to gradually decay in relevance over time.

13.2 Open Source Knowledge

How Open Source Knowledge differs from Open Knowledge is it’s link-rich,
collaborative nature.

Open Source Knowledge wasn’t always the norm. We used to have door-to-
door Encyclopedia salesmen, who sold us giant sets of books that contained
Everything There Was To Know on Earth. Then computers happened, and I
remember being awed that all the knowledge on Earth could fit into a single
Microsoft Encarta CD-ROM.

Of course we know what happened next - Wikipedia came along and obsoleted
all commercial encyclopedias with sheer breadth, then depth - on a shoestring,
nonprofit budget. It was released in 2001. By 2005, the prestigious journal
Nature found it comparably accurate with Encyclopædia Britannica. By 2018,
Google, Facebook and YouTube began to combat fake news by linking to
Wikipedia articles.

“Citations needed” is a fundamental requirement of Open Source

Knowledge. Wikipedia isn’t credible in and of itself - it derives credibility from
linking to credible sources. This is wonderful - it allows the reader to check their
sources, while still making information more accessible by synthesizing it for a
specific point of view. This is a fundamental innovation on the encyclopedia,
that takes advantage of the #1 feature of the Web: Hyperlinks.

Wikipedia isn’t without its problems. But it’s ability to leverage collaboration
and crowdsourced knowledge has produced great value for society - and for
authors and curators of individual articles. We should let a thousand
Wikipedias bloom.

Open Source Knowledge is spreading in software, too. This should seem

obvious - Code is just one materialization of all Knowledge. You may be
familiar with one of the Awesome repos inspired by Sindre Sorhus. Or perhaps
you’ve read great documentation via a Gitbook. And more recently, code
livestreaming via Twitch and YouTube is on the rise. You can even start a
business off of this - Nomadlist started life as a simple open source Google
Sheet.

13.3 Personal Anecdote

Open Source Knowledge has had a profound impact on my own career. I tell
you this not to promote my own work, but to give you the most genuine
endorsement of this idea that I can offer.

On the first day of my first job as a developer, my tech lead casually mentioned
that we’d be using React with TypeScript, and it wasn’t up for debate. I had
never used TypeScript before. So a forced introduction to TypeScript began. I
read through the TypeScript docs, and they ranged wildly from very basic
(assuming no ES6 knowledge) to very advanced (assuming extreme facility with
generic types), with no mention at all of accommodations needed for React. The
React docs had even less to offer.

So I started my own cheatsheet of tips and tricks, purely for React developers
who needed to add TypeScript to their repertoire, aka me.
It turned out there were a lot of people like me - the repo stands at 12k stars as of
time of writing. I definitely got lucky there - but I’ve extended this approach to
cover everything else from React Suspense to Design tricks to Node.js CLI’s and
it works for me just the same. The “README in a Git Repo” thing isn’t the
only way to do Open Source Knowledge, but it is a damn good one.

13.4 Why Open Source YOUR

Knowledge
Open Sourcing Knowledge is not an act of pure altruism. Even if not a single
soul sees it, the act of organizing your knowledge and writing it down solidifies
it in your head. But you needn’t remember everything - your repo becames a
Second Brain that can store and search infinitely more information than you can.
In this limited sense, there’s no difference whether this knowledge is private or
public - except that it’s nice to be able to punch in a few terms to Google and
find your own notes!

Of course, it is a short step to helping beginners too. Because you were recently
a beginner yourself, you can explain things at an accessible level, and arrange
topics in logical introductory order (whereas an expert might be too far away
from the basics to relate).

The unexpected benefit comes when your Open Source Knowledge starts being
useful to people who know more than you. Experts are always busy with a
million things, and get more opportunities and requests for help than they can
handle. You’re effectively building a resource they can point people to. Now
they are incentivized to help you be the best resource, for example, by fixing
mistakes and holes in your Open Source Knowledge. In this way I’ve been
taught TypeScript by experts from AirBnb, Artsy, Paypal, and the TypeScript
core team, for free.

Other reasons to open source knowledge:

It is a Friendcatcher, a great starter form of leveraging your time.

 It slowly grows your network, expertise and association with the domain -
the expectations are low, and your work is open for all to see, so you never
feel like you have to be an overnight expert. But it grows with you, so once
you do know a lot, you will have built up a wealth of credibility and the
resources to back it up.
It is living - it is never “done”, and has the advantage of always being up to
date compared to more highly produced pieces of work.
It has a Big L of L(PN), and possibly more if you spark a self-sustaining
community.
It is easy and permissionless. Anyone can livestream, or tweet, or write
markdown in a repo. Unlike speaking at a conference or publishing an
O’Reilly book, you don’t need anyone’s permission to get started.
It can be repurposed for anything. Because you’ve laid down all your
sources Mise en Place (Chapter 36) style, you can adapt that to creating a
talk, a workshop, a blogpost, a library, or anything else based on your
needs. You will find that Open Source Knowledge has a longer useful life
than any Open Source Code you write.

13.5 Tips
Some tips for doing it well:

Optimize for Copy and Paste - the most immediate value you can provide
to yourself and others is to offer copy-and-pasteable examples. Make the
examples clearly self-contained, well annotated, and made for Copy and
Paste.
Help others help their friends - when people look good by linking to your
work, you look good. So be timeless, don’t add junk like ads and random
jokes.
Add an Open License - just like you should license your code, make
explicit that people are welcome to read, contribute, and fork your
accumulated knowledge, and what attributions you require.
Look out for under-served community needs. Just like with any venture,
it is not a requirement that you be the first or only attempt to do something.
But it can help you get initial traction. The intersections of two domains are
usually under-served. This helps your effort be Tractable (don’t bite off
more than you can chew) and Resonant (do people say “Hell yeah! I wish
I’d seen this when I started!”)
Structure is as important as Content. Your role is as much organizing
information as it is providing information. Everything down to the relative
length of sections, the structure of headings, and even what not to include,
is worth paying attention to.
Ask for Specific Help. If you have known gaps in your knowledge, ask for
help there rather than ask for general help. It may or may not come, but at
least you stand a higher chance. The world punishes the vague wish and
rewards the Specific Ask.
Internal OSK. Not all information should be public. But you can still do
extremely well open sourcing knowledge internally in a company.
Chapter 14
Spark Joy
Your work should spark joy. Therefore, you should get very good at adding
sparks of joy in your work.

This may seem like a really weird principle to have in a book about coding
careers. But it can add so much value and impact to your work, disproportionate
to the amount of effort spent, that it had to be included.

14.1 What is Sparking Joy?

Marie Kondo’s 2019 Netflix series swept the zeitgeist with the idea that we
should declutter by getting rid of everything that doesn’t tokimeku, translated as
“Spark Joy”.

While we are used to this idea from the perspective of the consumer, the
principle cuts equally the other way as well. We live in an Age of Abundance,
which is also an Age of Noise. We creators, producers, and developers should
all think about how to make our work “spark joy” - lest it be “Marie Kondo”-ed
away like everything else.

“Spark Joy” is hard to define, because it is exactly as precise as the human

emotion of “Joy”. But in embracing that vagueness, we understand that people
are primarily not rational - not in what we are drawn to pay attention to, nor
what we decide to use, nor what we choose to talk about. We might have
perfectly good rationalizations of why we like something, but often the real
reason can reach deep into the subconscious.

“I’ve learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them
 feel.” - Maya Angelou

14.2 Why It Works

Look at this group of tomatoes:

Your eye went straight to the red tomato. We notice when things stand out. This
is known as the Von Restorff Isolation effect - when multiple similar objects are
present, the one that differs from the rest is most likely to be remembered. And
what we remember is what we value.

You’ve seen Von Restorff at work all over the Internet:

You can’t help it, your eye goes straight where they want it to go.

In the same way, you should want your work to stand out in the memory of
everyone from your colleagues to your potential customers. Because you’ve
given them something remarkable to hinge on, they can then become your
biggest advocates.

Sparking Joy isn’t just about standing out, though: so long as your work evokes
good vibes with people, they’ll associate you with positive emotions.

In the same way that Broken Windows can encourage further crime, having
examples of excellence in your work causes the reverse effect, which has been
called the Aesthetic Domino Effect. Putting sparks of joy in your work shows
people you care and inspires other people to do the same.

14.3 Examples
We’ll start close to home, in code, and widen out in concentric circles of
opportunities you will come across. This isn’t an exhaustive list; it is just meant
to give some inspiration for how you can Spark Joy with the things you do day-
to-day.

14.3.1 Sparking Joy in Code

Hell is not understanding my own code. - Kyle Simpson

Code is read more than it is written. If your code isn’t a joy to read, then it will
be difficult to use and dreadful to refactor. Avoid Hasty Abstractions as far as
possible. We constantly need reminders to avoid Code Complexity:

from Fred Brooks warning us about Accidental Complexity, to Rich Hickey

exhorting us to decomplect
from Bob Martin teaching us to write Clean Code to Kent Beck teaching us
to write sensible tests for them
from Sophie Alpert (former manager of React) encouraging us to facilitate
local reasoning, to Dan Abramov showing us to design code that is
Optimized for Change.

Everyone knows naming things are hard - there are many opinions here - if
something is too complicated to give a good name to it, you’re probably giving it
too much responsibility. Heed your code readability as a code smell.

Comments explain why, Code explains the how. - Jem Young

Code comments are a developer communication cheat code. They don’t have
any performance impact (usually!), and can help avoid others wasting time.
Instead of explaining what the code is doing, which is often evident from just
reading the code itself and liable to go out of date when code is changed, you
can try to note why some choices were made, or why the “obvious” approach
wasn’t chosen, or give an ASCII art diagram of how the code works. When you
anticipate what I’m going to ask as I read your code, believe me, that Sparks Joy.

According to Sarah Drasner (elaborated in talk form here), comments can serve
these other good purposes as well:

Clarifying something that is not legible by regular human beings

Break up chunks of code, like chapters of a book
Pseudocode to keep the logic straight while writing the code
Indicating TODOs or what parts of code are OK to refactor
Serving as a teaching tool to fellow teammates
Admitting where you got it from StackOverflow

I think the best written, most elegant code in the world cannot
compare even remotely to well done, natural language documentation
when it comes to communicating the intention and context of what
was built. How this thing works, why we built this thing. The code
can explain what it does and at a technical level how it does it, but it
doesn’t explain the business reasons and impact, or even some of
the other systems that might depend on it… A lot of people
underestimate the value to the doc writer of having to sit down and
write those docs… You might discover things about what you just
built and realize: “Oh wait, I missed something!” - Jared Short

Great error design sparks joy. Developers often write services and modules to
be used by other developers, even from within the same app. Most of these
interactions will be governed by some sort of contract, explicitly specified by
design documents or an OpenAPI spec or something similar. However, what is
usually underspecified is what to do when things go wrong:

A normal error message tells you an error happened somewhere.

A good error message tells you the local state that caused the error.
A great error message tells you probable causes and how to fix it.
A terrible error design doesn’t show up at all - a silent error.
The quantity of error messages also matter. Never normalize errors. Don’t cry
wolf. If you train people that they can ignore your errors, they will ignore
important errors, and you will get lazy in when and how you error. You can at
least have a hierarchy of errors - a simple info, warning, or error hierarchy
will usually do, but you can explore Syslog severity levels for something more
formally designed. Erroring too eagerly can also cause a lot of start-and-stop
debugging - instead, make your errors as lazy as possible - if the program
doesn’t absolutely have to stop, don’t. Use a notify() function that users can
configure to buffer and log these errors.

You might expect these things to be covered in code standards documents. But
Code Standards usually address the minimum required standards (for good
reason, to avoid being onerous). To Spark Joy, we look for opportunities to go
above and beyond. One way to be a developer that others enjoy working with is
to write code others enjoy reading and using.

14.3.2 Sparking Joy in PRs and Issues

Well crafted PRs and issues spark joy. Even when you are writing out of
frustration in dealing with a problem, the ability to keep your cool, provide
context and concise information, and help them help you is a boon.

StackOverflow has a good guide on How to ask a good question, but you can
also go above and beyond in easy ways:

GitHub makes it very easy to attach images and gifs to issues, so we should
use that wherever appropriate to convey information as that is very high-
bandwidth.
Use an app like Annotate or Zappy to take and annotate screenshots.
For gifs, the open source LICEcap app lets you control everything down to
the framerate and recorded screen area. This helps you isolate bugs in
motion.
Sometimes you need longer form commentary than just screenshots or gifs.
Record quick video demos or bug reports with narration and post it up to
YouTube as an unlisted video, and include the link to your report. A five
minute effort from you can help resolve a lot of back and forth with the
maintainer/potential user of the project.
A lot of GitHub collaboration is asynchronous and faceless. It’s common for
people to say they will do something - create a repro, try out a beta, work on a
fix - and then never return. Simply doing what you say you are going to do
sparks joy.

Maintainers can also do a lot to make contributors feel welcome:

The All Contributors Bot helps recognize contributions from everyone,

even non-code contributions like design, financial support, and docs
translations.
Use a feedback grading system like Netlify’s Feedback Ladder or
Conventional: Comments to give praise and indicate severity of issue
When merged PR’s are released, the semantic release bot can notify
contributors that they can now use their PR as part of the standard
distribution!

14.3.3 Sparking Joy in Docs

The most high impact way a developer can spark joy is in writing good docs. It
is the first thing every new user and team-mate reads, and shows that you care
about the project.

You don’t have to create a bells-and-whistles docs site for every little project.
For most things, a really good README is more than enough - but you can do a
lot to “sweat the README”.

Get straight to the point. Place Installation, Examples, and API docs up front
and use a Table of Contents generator to make it easy to navigate. Keep them up
to date, and write example code with the understanding that developers will copy
and paste while skimming over most of the explanations. Even where copy and
paste is not possible, for example when developer keys are concerned, you can
show the expected form of the key for people to visually verify they have the
right one, e.g. API_TOKEN= # e.g. MY_API_TOKEN_1234

Tip: In the Node.js ecosystem, dotenv-safe is helpful for

enforcing checks that environment variables are specified properly.
Licenses matter in open source. Some legal interpretations don’t allow
developers to even look at unlicensed code, much less use or contribute to it.
Learn the difference between copyright and copyleft, and pick a license that
reflects your values. More importantly, don’t use software that might
compromise your company’s intellectual property. You can use tldrlegal to
understand licenses, or rely on approved licenses from the Open Source
Initiative. If in doubt, use MIT. It takes seconds to add a license, either through a
CLI (npx license mit) or through GitHub’s UI. Make it a habit!

CI Badges are associated with quality. It’s tempting to regard docs badges as
performative “pieces of flair”, but an academic study of this phenomenon has
actually found that badges with underlying analyses, e.g. displaying build status,
issue resolution times, and code coverage are predictive of project quality.
Shields.io makes it easy to set up a selection of great badges. Correlation isn’t
causation: this probably has more to do with the kind of maintainer that adds
badges than implying that badges cause project quality. But you could be the
kind of maintainer that shows they care!

Side note: Not too many badges! 4-6 badges seems like the sweet spot
- any more and the “Christmas Tree” effect starts showing you are
“trying too hard”.

Repo Metadata should also be given proper attention. GitHub allows you to
place a description of the project at the top, as well as to place a link. Be sure to
put your best oneliner pitch in there, and to link to a live project of the demo!
That is literally the first place developers look.

READMEs are typically written in Markdown, which imposes some strict order
on your content, but you can often break that monotony by using some HTML
alignment with <div align="center">, or adding a logo or banner (either
ask for contributions or use a generator like Hipster Logo Generator, Hatchful,
or Excalidraw).
Pay attention to the structure and relative weight of your documentation.
Nobody enjoys reading big blocks of text - break it up into bullet points or tables
where possible. With GitHub-flavored Markdown, you can even hide lengthy
explanations of edge cases in HTML <details> and <summary> tags
interspersed with Markdown, which helps make your docs useful for both the
skimmer and the dev who wants to dig deeper.

Automate formatting for your docs. You can run prettier as a git hook (with
husky and pretty-quick for a fast experience), and use doctoc to keep your
Table of Contents up to date (also available as a GitHub action).

Sometimes a picture speaks a thousand words. Feature screenshots or a demo gif

if possible. For “How it Works” sections, you can also create simple ASCII
diagrams using tools like ASCII Flow and Monodraw to explain systems and
concepts. You can even use free drawing tools like Excalidraw, Draw.io (in VS
Code too!) and Miro to illustrate with color.

“I swear by the README.md svg logo. No matter how good/bad the

code is, you put a logo on there, and I’ll probably npm install it.” -
Matt Hova (somewhat joking)

There’s no end to things you can add for Great Documentation - so it is best to
match your documentation to the project maturity. Two nice features that are
always appreciated: Searchability, and a “Tradeoffs” or “When NOT to use this”
section.

Anecdote time: Great docs aren’t only important for open source marketing
and adoption. One of my best dev memories was hearing a new employee
coming across an internal repo for the first time, and finding an extensively well
explained README with diagrams to show how everything worked and even a
short explanation of project file structure. The engineer responsible for that
hadn’t even touched the repo in over a year, but the new person was able to pick
it up right away. You BET the new person was overjoyed to find such great
docs, and sang its praises all over the company’s internal chat. As for the
original engineer? She was promoted to Principal Backend Engineer not long
after.
14.3.4 Sparking Joy in Demos and Products

Demos are GREAT opportunities to spark joy, because of the relative freedom of
a non-production, non-core code app. On-brand humor can really help to sell the
intent of your project while also helping with marketing - just check out the
landing page of and social media reactions to Muzzle.

Even when you are demonstrating how to interact with an API, you can use joke
APIs like this one for “clean” jokes or this one for developer jokes or this one for
devops jokes. If you need to be more serious, check Public API Lists for
interesting APIs you can demo with.

The best demos localize for their audience. People notice when the talk they
are watching could not possibly work for any audience except for them. When
Divya Tagtachian gives a talk in Boston, she talks about local seafood joints.
The same demo switches to Deep Dish Pizza in Chicago. When she speaks in
Amsterdam, she makes funny Dutch puns and discusses GDPR. In Nigeria, a
demo using milk tea gets swapped for Jollof Rice. In your marketing pages, you
could use avatars and illustrations that reflect the colorful variety of your
intended audience. Audiences notice when you go the extra mile for them, and
this sparks joy.

Sweat the accessibility. It’s not only a good habit to do it even in non-
production demos, it truly sparks joy for keyboard and screenreader users used
to a sea of inaccessible apps. Accessibility isn’t just for those with disabilities –
it is becoming a key product differentiator among productivity and developer
tools (even for heavily visual apps like Slides.com) and apps for outdoor or
industrial use. Marcy Sutton, Lindsey Kopacz and Jen Luker offer a wealth of
talks, resources and workshops you can check out.

Storytelling can make for a compelling demo. Your visitors can get invested in
characters, whether made up or referencing pop culture. One of the most
compelling DevOps demos I have ever seen was delivered through telling the
story of a coworker named Pavel. Years later I still remember Pavel’s name and
what he went through.

Don’t forget your empty states! Empty states are common to see with demos,
especially when users create a trial account and see nothing in their dashboard
because they don’t have any data yet. Most programmers leave empty states
empty. But that blank space is free real estate to prompt the user to do the next
action! For apps like Superhuman, the empty state is not only a goal, it is a
competitive advantage. Check emptystat.es for more inspiration in real apps.

Our discussion of demos is starting to veer into the dreaded Full App Design
territory. Beautifully designed demos definitely spark joy - but does that mean
we should hire designers? Become designers?

Note: Maybe… Maybe not! Check out Design for Developers in a

Hurry (Chapter 33) for simple tips on sparking joy with design!

14.4 The Extra Mile

There is no end to the possibilities of sparking joy in your work. Here are some
more ideas that just didn’t fit in the above categories:

Quick Feedback: This is the age where “ghosting” people is common,

where people laugh off being “bad at email”. If you make the effort to be
responsive, it will get noticed. Think about how much you crave feedback
for your own work. Others want that too. You can be a feedback fountain
and people will keep coming back to you for more.
Getting great at email is simple, but not easy. Your humble author is still
working on it. But the core idea is the same as David Allen’s Getting
Things Done methodology - if something can be done in under 2 minutes,
do it right away. Most email can be deal with like that. Ditto chat, GitHub
notifications, text messages, and so on. You don’t have to be checking them
all the time, but making sure you check and respond once or twice a day
keeps you responsive to others who care about you and work with you.
This sparks joy.
Care about others: It’s not always about you. Keep watch on others’ work
and comment with encouragement as they go. I even add a star onto private
GitHub repos, which no-one else sees, just to send a little sign to my
coworkers that I am watching and they have my support.
Take minutes: Meetings happen too casually in the modern workplace.
Especially if information is scattered through a bunch of asynchronous chat
logs, it can be hard to search for and reference in future. Taking the effort
to gather up what was said, what positions were considered and what
decisions were made not only helps improve your image but it genuinely
makes team communication better! Bonus points if you are male and see
minute-taking fall disproportionately on female coworkers (it does, and
they appreciate allies calling it out).
Deep research: Doing deep background research on a podcast guest and
dropping a hint to let them know! (Example - when Rob Hope interviewed
Adam Wathan, he discovered Adam’s heavy metal preferences and asked
him about it)
Secret compliment: When someone does you a favor or does particularly
good work - send in a compliment or thanks to their manager. This will
help during their annual review!
Handwritten thank you note. Enough said. Even if the thank you is years
too late, a sincere gratitude letter can make a person’s day.
Easter Eggs: Sign bunnys and Cowsay in CLI output

Being hilariously on brand: Example - Design Pickle wearing a pickle suit

and handing out pickles made them memorable and viral
 Personal Tokens: Shirley Wu does data visualization, so she printed out
business cards that show off her work, that you can only get if you have met
her in person.
Unusual Analogies: In reviewing his friend’s book, “Exactly What To
Say”, Clay Hebert could have said that it contains “only the good stuff”,
which is on-theme with its topic. Instead, he called it the “balsamic vinegar
reduction of books”. That unusual image sticks with readers, and you can
be sure that Clay strengthened his friendship that day.

Your capacity to inspire joy is only limited by your creativity. But people
always notice when you do. Going the extra mile to delight people invokes the
principle of reciprocity, which is one of the most powerful forms of influence.

“There are no traffic jams along the extra mile.” - Roger Staubach, the
Hall-of-Fame football player

If you didn’t know about the power of sparking joy in others, now you know.
Chapter 15
The Platinum Rule
You’ve heard of the Golden Rule: Treat others as you want to be treated.

I think it’s incomplete. I think people actually operate by a higher standard. I

propose the Platinum Rule: Treat others as THEY want to be treated.

15.1 The Platinum Rule

To understand how I got here, you have to understand that I have some particular
personality traits that make the Platinum Rule relevant for me. I prefer
directness. My bar for “done” is lower than yours. I like self aware people and
humor. I prefer tough love.

This means I prefer shipping an imperfect thing and iterating rather than lining
up my ducks in a row. This means I don’t engage in compliment sandwiches.
This means I make fun of myself and anything I strongly identify with, which
can sometimes include people I work with. This means I often am too harsh on
something I care about.

Some of you are reading and nodding and don’t see what’s wrong. That’s what’s
wrong.

Suppose you ridiculously simplify human preferences down to More Particular

vs Less Particular, and human interaction down to how you treat others vs
how you want to be treated. The Golden Rule would advise More Particular
humans to treat others like they want to be treated, which is a higher standard
(however you define it) than Less Particular humans. This is fine, they just end
up very considerate. However, if the Less Particular people were to take this
advice, they would come up complete assholes to More Particular humans, who
would be unable to work with them.
Hence, the Golden Rule is broken. It was made by a More Particular person who
doesn’t realize it.

It doesn’t really even matter what the relative quantities of More Particular vs
Less Particular people are - if these people are to work together, then they must
coexist under a different social contract.

I propose the Platinum Rule to be that contract: Treat others as THEY want to
be treated.

On one hand this seems like basic human decency: Of course you should be
considerate of others’ feelings. Use their pronouns. Respect their agency and
freedom.

On the other, it can seem FAR too accommodative - what if people abuse the
system and want to be treated unreasonably well? Double standards exist
everywhere when it comes to self interest. Well, a line must be drawn
somewhere.

It’s imperfect, but probably the right balance of where you and I should operate
is somewhere in between the Golden Rule (extreme self-centered empathy) and
the Platinum Rule (extreme other-centered accommodation).

15.2 The Silver Rule

If the Platinum Rule is “better” than the Golden Rule, what would a Silver Rule
look like? (I like stretching good ideas even further than originally intended, an
idea I took from Brian Chesky).

A Silver Rule would be something that is often treated as secondary to the

others, but still important and valuable. And in the format of “Treat x as X
wants to be treated”.

Here’s my proposal for a Silver Rule: Treat yourself as you treat others. A
nice inversion of the Golden Rule.
In Gretchen Rubin’s Four Tendencies Framework, she splits people by how they
respond to inner and outer expectations, which seems very apropos to this topic.

Questioners are most in need of the Platinum Rule. But Obligers, the majority
of the population, probably need the Silver Rule most. For Obligers, self care
must not get sidelined by self sacrifice. This is something we address in
Chapter 40.
Chapter 16
Good Enough is Better than Best
In general, you move faster and feel a lot less stress once you realize: You don’t
need “the best”, you just need “good enough”.

Looking for “the best” involves:

Obsessing over benchmarks

Caring what influencers think
Keeping up with new releases

Looking for “good enough” involves:

What YOU need done

What YOU know well
What YOU enjoy

The more reversible the decision, the faster you should move.

16.1 Why It Matters

This realization was borne out of answering yet another beginner question on
what was the best library, the best course, the best framework.

The problem with being a beginner is you don’t even know that these are bad
questions.

What beginners lack is a framework for evaluating technical merit:

When you’re a beginner, “biggest is best”. You’re swayed by things with

the most followers, the most users, the most number of recommendations
 by friends. Social proof rather than proof, because we are more familiar
with people than with the technology.
Once you are a little more discerning about tradeoffs and cutting edge work,
“best is best”. You see how often “the biggest” is actually not “the best”.
Sometimes this is because the need to appeal to everyone creates a drive
toward the “lowest common denominator”. Sometimes supporting
everyone’s needs creates an unmanageable sprawl of cruft. Sometimes they
get big simply because they prioritize marketing over substance. This
happens enough that you can develop mistrust of the biggest anything. But
you still cling to the idea that there is an objective “best”, by whatever
metric, that others are missing out, and that you/your company should use
“the best” because it is the best.
As you become an expert, you realize that “the best” technology often
doesn’t “win” for valid and underappreciated reasons, that everyone has
different priorities and circumstances that make them evaluate “the best”
differently from you. So the strongest endorsement you can make becomes
“the best for me”, and you learn to respect the choices people make for
themselves even if you disagree with them. Basically the only thing that
matters is that the technology is good enough for what you are trying to use
it for.

I think we all could do a better job of framing engineering and life as satisficing
rather than maximizing operations. You can achieve more success and happiness
when you look for “good enough” and then move on, instead of constantly
looking for “best” (unless that is your entire value proposition, e.g. you are a
professional tech reviewer).

16.2 The Problem with Seeking “The

Best”
We spend a lot of time seeking “The Best” of something. The best schools. The
best jobs. The best home. The best cities. The best restaurants. The best
partner. The best framework. The best course. The best book. The best movie
with the best actors.
Who doesn’t want to have the best? Who wants to live their life settling for
“alright”?

Seeking the best has several hidden costs.

Happiness: You don’t always know that you’ve got the best. You make
your decisions under imperfect information — what reviews say, what
friends tell you, what the marketing says — and then you buy something.
Seeking the best only to find you have ended up with the second best is a
recipe for disappointment. You end up comparing long feature checklists
looking for the most amount of green. Most of which you don’t need. Even
picking something, anything, gives you anxiety because you fear missing
out.
Cooperation: Looking for the best transforms your world into a zero-sum
finite game rather than a positive-sum infinite game. It’s cancerous to your
worldview.
Efficiency: It is also ridiculously inefficient. The corollary of the Pareto
principle is that the last 20% of something is the most expensive - and that’s
what you have to sweat if you must seek “the best” all the time. It’s fine to
seek the best - just know that you’re going to incur a disproportionately
high cost.
Agency: People game “best-seekers” all the time, by defining for you what
“best” is. Who wants to be Mayor on Foursquare? Who can compete to get
the most subscribers on YouTube? Which wait-service staff will be
Employee of the Month? Games to give fake status to people who live in
the system, by people who profit off the system. If you seek “good
enough”, you reclaim your own agency.

“Good Enough” is, well, good enough. Learn to define that for yourself, and to
be happy when you get it, and you will be more reliably happy, cooperative,
productive, and independent than you ever were.

Author’s Note: There is historically an even more aggressive framing

of this principle – “Worse is Better”. This was first coined by
Richard Gabriel originally to describe the idea that software quality (in
terms of practical usability) does not necessarily increase with
functionality (the full text of the essay is here). However I feel the
 oxymoronic nature of this phrasing implies that “worse” is desirable in
all situations. It isn’t. Therefore I have opted not to use it, in favor of
“Good Enough”.

16.3 False Confidence: Accuracy vs

Precision
A close cognate of seeking “The Best” is being impressed by more precision
instead of accuracy. Having more precision gives you more confidence, but
doesn’t actually make you more right. Only accuracy measures how right you
are.

Remember the difference:

Seek to be approximately correct vs being precisely wrong.

The seductive lure of precision can come in several forms - decimal places, high
frequency updates, one-axis comparisons of complex things, the majority
consensus, the highly credentialed expert.

Every time you see:

 Financial news media quoting stock price changes down to two decimal
places (caring more about appearing precise than providing insight)
Founders deciding the success or failure of output based on daily or even
hourly metrics (especially when long term/probabilistic results are
concerned)
Single-metric benchmarks (“My framework is 100x faster than
$POPULAR_FRAMEWORK!”)
Decisionmakers relying on “the wisdom of the crowds” as a proxy for
objective truth (too often, the crowds are mostly reflections of the opinions
or shared facts of a small group of elites)
People assert more than 3 letters after their name (relying on credentials to
turn off your brain rather than facts and strength of argument to turn it back
on)

Be very wary. It’s not that precise people are always wrong. It’s literally that
being more precise has little to do with whether you are more accurate. It is
always easier to be more precise than it is to be more accurate. One
produces more confidence. The other produces more results. Choose wisely.

The easier that data can be obtained, the less valuable it generally is – not
because of the relative surplus, but because nobody guards worthless facts. This
is good news for humans: In a world of Big-Data-driven everything, there will
forever be a place for judgment, insight, and fundamental, First Principles
Thinking (Chapter 17). However, humans also have a built-in aversion to
ambiguity and uncertainty, known as the Ellsberg paradox, so we end up
clinging on to whatever data we do get, no matter what it is worth.

False Precision is not just misleading, it is actively harmful, because it leads to

False Confidence. Here it is best to simply recount a story told by Adam
Robinson in Tribe of Mentors:

“In 1974, Paul Slovic — a world-class psychologist, and a peer of Nobel

laureate Daniel Kahneman — decided to evaluate the effect of information on
decision-making. This study should be taught at every business school in the
country. Slovic gathered eight professional horse handicappers and announced,
“I want to see how well you predict the winners of horse races.” Now, these
handicappers were all seasoned professionals who made their livings solely on
their gambling skills.
Slovic told them the test would consist of predicting 40 horse races in four
consecutive rounds. In the first round, each gambler would be given the five
pieces of information he wanted on each horse, which would vary from
handicapper to handicapper. One handicapper might want the years of
experience the jockey had as one of his top five variables, while another might
not care about that at all but want the fastest speed any given horse had achieved
in the past year, or whatever.

Finally, in addition to asking the handicappers to predict the winner of each race,
he asked each one also to state how confident he was in his prediction. Now, as
it turns out, there were an average of ten horses in each race, so we would expect
by blind chance — random guessing — each handicapper would be right 10
percent of the time, and that their confidence with a blind guess to be 10 percent.

So in round one, with just five pieces of information, the handicappers were 17
percent accurate, which is pretty good, 70 percent better than the 10 percent
chance they started with when given zero pieces of information. And
interestingly, their confidence was 19 percent — almost exactly as confident as
they should have been. They were 17 percent accurate and 19 percent confident
in their predictions.

In round two, they were given ten pieces of information. In round three, 20
pieces of information. And in the fourth and final round, 40 pieces of
information. That’s a whole lot more than the five pieces of information they
started with. Surprisingly, their accuracy had flatlined at 17 percent; they
were no more accurate with the additional 35 pieces of information.
Unfortunately, their confidence nearly doubled — to 34 percent! So the
additional information made them no more accurate but a whole lot more
confident. Which would have led them to increase the size of their bets and
lose money as a result.

Beyond a certain minimum amount, additional information only feeds — leaving

aside the considerable cost of and delay occasioned in acquiring it — what
psychologists call “confirmation bias.” The information we gain that conflicts
with our original assessment or conclusion, we conveniently ignore or dismiss,
while the information that confirms our original decision makes us increasingly
certain that our conclusion was correct.”
The overall moral of the story is the same as we began with: Seek “Good
Enough” information, and have the appropriate confidence when you Bet on
Technologies (Chapter 24), companies, and people.

Author’s Note: The naming of this Principle is definitely influced by

the inventor of the Lithium-Ion battery, to whom we owe so much of
our modern day electronic conveniences: the appropriately named
John B. Goodenough.
Chapter 17
First Principles Thinking
First Principles Thinking (FPT) is starting from unequivocal base facts and
building up toward some vision or explanation of reality. It involves reasoning
by deduction, rather than by analogy or appeal to authority. It’s been called the
Dumbest Thing Smart People Do.

Big O Notation is many developers’ first brush with FPT. As a developer,

learning to reason from first principles makes you see the bigger picture behind
all the engineering work you do, from project estimation to technology
evaluation. As you get comfortable with your tools, you should start to look
beyond them toward their underlying patterns and limitations. This is one of the
key transitions you will make in the transition from Junior to Senior (Chapter 5).

Push yourself to think beyond labels. Questions like “is it production ready?” or
“does it scale?” or “is it blazing fast?” have very little meaning absent your own
context. For a hilarious take on this, check out this parody video discussing the
technical merits of Node.js between two developers. It’s funny because it is
true. So many beginner developers, and too many senior developers, think and
talk with labels and never go past that. Learn to break down how things work
and derive your own answers based on first principles.

When you are told that something cannot be done, First Principles will help you
ask “Why Not?” Conversely, if you are being tasked to do something
impossible, First Principles will help you quickly demonstrate nonviability by
breaking down the problem to a set of base facts.

Jeff Dean was known to circulate a short list of Latency Numbers Every
Programmer Should Know at Google, reminding developers of the total
futility of trying to do transatlantic roundtrips faster than 150ms because it
is limited by the speed of light.
John Carmack, working on gesture interfaces, points out that the speed of
thought is only 110m/s, placing 9ms of latency in your arm. This is hugely
 sobering for his field of human-computer interfaces.
You can keep your own list of base facts for performing Napkin Math in
your own domain.

Having a good grounding in inviolable truths helps you dispel myths. If you
break apart a bundle, whether it is a system or product or library or belief, and its
constraints aren’t demanded by the sum of its parts and Amdahl’s law, there is
probably opportunity.

Ironically, plenty of explainers (1, 2, 3) on FPT immediately appeal to authority

like Naval Ravikant or Charlie Munger or Elon Musk. Elon probably has done
the most to popularize it in recent memory, but if you must be sold on basis of
authority then you haven’t really got the point of FPT.

To embrace FPT, you need to understand the philosophy of logic and

epistemology.

17.1 Logic

Logic is the analysis and appraisal of arguments.

I first encountered this via a philosophy lecturer I had in junior college, Lionel
Barnard (who was actually supposed to teach Economics, but preferred to turn
our class into a little PPE program for our intellectual gratification). In particular
I have always favored the format of Syllogism, which takes a form like this:

1: All men are mortal.

2: All Greeks are men.
Therefore: all Greeks are mortal.

“Therefore” denotes a logical and inevitable-to-the-point-of-truism consequence

of the first two propositions. This underlies a lot of how proofs are done in
Math, and the other basic sciences - take N facts, put them together, derive a
new, more useful fact that is as real as those other facts because it is built on top
of them.

You can’t get very far if you only rely on facts, though, because there are many
more unknowns and indeterminate or stochastic processes than there are facts.
So you can supplant your syllogisms with Axioms - assumptions that you take to
be true. You don’t HAVE to prove them true, but you can show by deduction
that given an acknowledged set of assumptions, you can arrive at a logically
sound conclusion. This is FANTASTIC, because it lets you enumerate your
beliefs. It also allows you to change your mind instantly if your assumptions are
proven wrong (especially handy because you can’t prove a negative).

So that’s great - who would argue against Logic?

It turns out that logical deduction has limits, and in fact takes a lot more effort
(in corralling facts - sometimes what you believe to be true isn’t true, as in the
reproducability crisis in the social sciences - and validating the integrity of the
logical chain of arguments), and by far the more prevalent method we operate on
is Induction. We study this in Epistemology.

17.2 Epistemology

The study of the nature of knowledge, justification, and the rationality

of belief.

Epistemology addresses the question of how do we know what we think we

know.

There are many approaches to the study of Certainty so I will blithely ignore
most of them and contrast two: Induction vs Deduction.

I have already presented deductive reasoning above - given a base set of

general facts, we build up as high as we can to useful general conclusions.
Inductive reasoning is the opposite - taking specific real world observations and
generalizing them to general truths. This is problematic in SO many ways, and
we have known about the problem of induction for hundreds of years. Yet this is
how most of us conduct our businesses, lives, and core belief systems.

Induction is insidiously persuasive: You may laugh at someone taking a single

anecdote and generalizing it to everybody. But this is philosophically only
slightly worse than taking a population survey and generalizing, which is again
only slightly worse than looking outward and seeing what else exists and
inferring that that is all that can exist (the proverbial frog in the well).

We do this every day. We dress it up in statistics and numbers to make it feel

more truthy. We call ourselves things like empirical or data-driven. We look at
someone’s resume for assessing capability to do a job - unobjectionable at first
glance, until you see how much people’s opinion changes when “A went to
Harvard” or “B was the guy who took X from 10-100m in ARR”, implicitly
projecting that that transfers. When hiring for a thing (say, a job in React) we
overweight people who have done the thing (a previous job in React) over
people who could do the thing (anyone with extensive experience in
JavaScript/webdev). We keep up on news and trends and competitors and
neighbors and peers and celebrities and friends and family and that represents
our reality. And rarely question its nature and limits.

Induction and Deduction are not on equal footing. As a rule, induction

datapoints are far more readily available, while deductive facts are far more
timeless, but costly to pin down. Only logicians, mathematicians and theoretical
physicists have the luxury of starting entirely from the basis of First Principles.
Everyone else must make do with some axioms accepted on faith to have a hope
of getting somewhere useful. The problem arises when we go too far and
construct our entire worldview out of axioms and received, untested wisdom.
Humans are GREAT at backfitting/rationalizing from present datapoints, but
terrible at examining the basis of their beliefs.

“1500 years ago, everybody ‘knew’ that the earth was the center of the
universe. 500 years ago, everybody ‘knew’ that the earth was flat.
And 15 minutes ago, you ‘knew’ that humans were alone on this
planet. Imagine what you’ll ‘know’ tomorrow.” - Men in Black
Addressing your Epistemology head-on is very important for decision-making -
because if you don’t know how you know what you know, then how do you have
any faith in the decisions you make, based on that knowledge?

Acknowledging Epistemology is also important for building mental models -

because you can either fill your explanations with a bunch of incidental junk
complexity with the redeeming quality of being real, or you can start from a
bunch of irrefutable base facts and build up to something theoretically possible.

17.3 Applications
My talk on Getting Closure on Hooks was cited as a “First Principles” talk, as is
the followup on Concurrent React. I think all talks and blogposts in the From
Scratch genre, like this on React Router or this on Redux or this on the
hardware-software interface is great First Principles fodder. There’s even an
entire repo on GitHub for Build Your Own X projects!

But of course, First Principles can be applied far beyond code. The Drake
Equation is a well known first principles decomposition of the number of alien
civilizations in our galaxy. You can explain everything from Music to
Computing (to Coding Careers!) with First Principles.

17.4 Systems Thinking

More generally, a quantifiable set of first principles for any system is now in
vogue as Systems Thinking, quoting Donella Meadows:

PLACES TO INTERVENE IN A SYSTEM (in increasing order of

effectiveness):

12. Constants, parameters, numbers.

11. The sizes of buffers and other stabilizing stocks, relative to thei
 r flows.
10. The structure of material stocks and flows.
9. The lengths of delays, relative to the rate of system change.
8. The strength of negative feedback loops.
7. The gain around driving positive feedback loops.
6. The structure of information flows.
5. The rules of the system.
4. The power to add, change, evolve, or self-organize system structure.
3. The goals of the system.
2. The mindset or paradigm out of which the system arises.
1. The power to transcend paradigms.

When you are trying to change a system and it feels too hard, a reliable trick is to
find out where you are in Donella’s list and work your way downwards.

I have in my head a set of other questions I also like asking:

What do people really want? Usually it is something simple, but not

easy. For businesses, this involves identifying Jobs to Be Done. For
people, Maslow’s Hierarchy is a good reference, as is the list of Things You
Can’t Buy: Happiness, Freedom, Time, Health, Wealth, Family, Purpose,
and so on.
What are the physical limits? For example, the speed of light, but also
you can do thought experiments on the limits of Moore’s Law vs Wirth’s
Law or use Big O notation to model scaling factors of Personal Growth
What are the units of output? Related to systems thinking, but this is a
reductive method that has been very helpful in taking the hype out of tech
startups and reducing Uber and AirBnb to driver miles and room nights.
What is your success metric? How do you know if you succeeded?
Starting with the End in Mind is a good habit for productivity but Christine
Yen likes to ask this to help guide what Honeycomb.io does.
Who cares? Don Valentine’s cryptic two word test on who the end
customer really is and how much they care.
What are the rules of the game, and how are they changing? When you
play any game, you first find out the current rules for winning, but you must
also find out how the rules are changing in order to win in future. This is
also called Game vs Metagame.

In the software domain, Will Larson is a leading voice on how to apply systems
thinking to engineering management.
17.5 Further Reading
Napkin Math
Boring Technology
Wait But Why on Elon Musk
Neil Kakkar on First Principles Thinking
Donella Meadows on Leverage Points
Li Haoyi on First Principles
Chapter 18
Write, A Lot
“What many people underestimate is that being a good writer, whether
that is through emails or through documents, allows you to be more
impactful. I see many engineers ignore that skill. You might be proud
about your code. You should also be equally proud of the craft of
writing… Writing is a highly underestimated skill for engineers.” -
Urs Hölzle, Google’s first VP of Engineering

If you are serious about making an impact in your coding career, you should get
good at writing words as well as code. Developers write in a ton of scenarios
both at work and for their own careers, and there are a host of attributes that
make writing down your knowledge particularly rewarding for a knowledge
worker like you.

My ultimate recommendation is to build a high output writing habit,

eventually earning a “Do-It-Yourself PhD.”

18.1 Why Developers Write

The most straightforward reason why developers write is because they have to
for work:

Writing emails, code reviews, issues and pull requests.

Developers have to write proposals for projects they want to work on.
They also have to explain blockers and outages when things go wrong. Shit
Happens - If you can write a great explanation demonstrating you
understand root cause and how to fix, that can add a silver lining to any
mistake.
 They certainly have to write self assessments for promotions, and peer
reviews for their teammates!
Senior developers are expected to write design docs before any
implementation takes place.
Some companies even evaluate developer impact based on ability to
communicate effectively with internal and external partners.
60-70% of communication is nonverbal. Remote work replaces body
language with writing. And the only way to scale remote work -
according to Matt Mullenweg, who runs Automattic (owner of Wordpress),
one of the largest remote companies on Earth - is to go asynchronous -
replacing facetime with even more writing. Therefore writing becomes a
remote work superpower.

Some developers write more words than code for their jobs, and have more
impact than someone who only codes. This reality only increases as you go
beyond your coding career, whether you are managing people as an engineering
manager, or raising funds as a founder. Your writing style can differ drastically,
as is clear when you study internal memos from leaders like Steve Jobs, Bill
Gates, and Mark Zuckerberg. But they all agree on the criticality of writing to
scaling themselves. If you have the ability, encourage a culture of written
communication to scale the benefits of writing across your entire organization.

“By writing well, you can scale your ability to communicate

efficiently to multiple teams, to an organisation or across the
company. And the ability to communicate and influence beyond your
immediate team is the essential skill for engineers growing in seniority
- from senior engineer to what organizations might call lead, principal,
staff or distinguished engineer.” - Gergely Orosz

If you prefer a more technical metaphor, think of writing as caching yourself:

“The database is like the universal source of truth, it is where all the
data lives about your users and customers… Over time, as you grow,
the database can’t respond to all the requests, so you add a cache. This
is how most web applications scale. Writing is the cache.
 Documentation is the cache. Code is the cache. The people in the
company - me - I’m the database.” - Sahil Lavingia

You can also do it for the sheer joy of sharing what you’ve learned. That can be
enough. In the words of one of the most prolific developer-writers I know:

Ultimately, I really like sharing stuff that I’ve learned. It’s some
combination of “being informative”, “passing it on”, “helping”,
“teaching”, “not repeating myself”, and “showing off / bragging”. I
write because I have stuff to say, because I know that I’m helping
people, and because I really can’t not write. - Mark Erikson

18.1.1 Documentation

I place Documentation in a special category because it is work writing that is

meant to last. You might be required to write docs for your app or service, or
onboarding docs for future hires.

Some companies go as far as to follow Documentation Driven Development - no

code is written until the docs for that code are agreed on first. Jeff Bezos is
famous for introducing “Six Pager” Narrative Memos, which are briefings
stuctured like mock press releases to go through the exercise of envisioning what
the project will look like on launch day, and working backwards. These are
required before any major project is started at Amazon.

Writing great technical documentation is also critical for Developer Tools

companies, remote companies and Open Source:

John Resig attributes the success of jQuery to Documentation: “On the very
first day it was released, I had documentation written. I sat down and went
through every method and documented it and how it worked and provided
little examples…(in 2006) jQuery was the only JavaScript library with
documentation!”
 Taylor Otwell makes eight figures running Laravel as an (almost) solo
developer, and is even more blunt: “Whoever writes the best documentation
wins!”
GitLab’s handbook begins: “A handbook-first approach to documentation is
sneakily vital to a well-run business. While it feels skippable — inefficient,
even — the outsized benefits of intentionally writing down and organizing
process, culture, and solutions are staggering. Conversely, avoiding
structured documentation is the best way to instill a low-level sense of
chaos and confusion that hampers growth across the board.”

Technical writing is a deep discipline with a lot more specialized knowledge

than I have space to cover. Google has a great course on it you can check out,
however be aware that you don’t have to write like Professional Technical
Writers do in order for it to count as good technical writing.

18.1.2 Career Capital

Most developers don’t write in public - a lot of their writing just sits on company
servers. Smart developers write so that they Don’t Go Home with Nothing.
They understand that the vast majority of developer careers outlast their tenure at
their current firm, and the easiest way to establish expertise and build a
reputation in the industry is to write under their own names.

A good way to write for your own career is to publish under top industry blogs
and forums - anyone that pays you to write will have rigorous editing standards,
and you can practice your technical writing while making money and gaining an
audience:

Twilio Voices pays $500 per technical post, and usage of Twilio isn’t
required!
Digital Ocean and Linode pay $300 to write about Python, JS, or Linux
WonderProxy pays $500 for content on testing
ClubHouse pays $500 for content for senior devs/eng managers
Smashing Magazine, CSS Tricks, A List Apart, and LogRocket pay $250
for front-end posts
FloydHub pay $150 for Data Science/AI/ML
Stack Overflow pay $500 for general programming content
You can find more on WhoPaysTechnicalWriters.com. Some other platforms
may pay for writing on a case by case basis - almost all the video course sites
like Treehouse, Lynda, Pluralsight, and Egghead have some form of published
writing component.

Two caveats to note when writing for other platforms - you lose your copyright
(they paid for it after all, but this is usually fine because getting your name out
there is more important in the early days) and you have to go through the editing
process (this is a good thing! You want this!).

Not everything has to be for money - it is often easiest to get started just by
writing great answers on established platforms. Jon Skeet rose to fame by
answering prolifically on StackOverflow until he was the top contributor of all
time.

Personal Technical Blogs are a permissionless form of writing that you own.
Mattt Thompson created NSHipster, “a journal of the overlooked bits in
Objective-C, Swift, and Cocoa, updated weekly”, and made a reputation as an
expert in iOS and Swift. Jeff Atwood and Joel Spolsky only met through their
blogs, going on to create StackOverflow.

You’ve also seen from the other principles in this book that you can Open
Source your Knowledge and create Friendcatchers while you Learn in Public
- if you own the domain, you don’t need anyone’s permission to publish and you
can build a brand on distribution that you own.

Even when you code the next great Open Source project, you will still have to
market it. Here’s Dan Abramov on creating a successful Open Source project:
“It also means writing blog posts, making tutorials, sending pull requests to
popular open source project examples to use your tool, talking to the users on
social media platforms to learn what they want, preparing promotional materials
(like tweets), reaching out to influencers, etc. Open source is a lot of work, and
having a project is not enough.”

18.2 What Writing Does for You

 “Writing doesn’t just communicate ideas; it generates them. If you’re
bad at writing and don’t like to do it, you’ll miss out on most of the
ideas writing would have generated.” - Paul Graham

Writing forces you to create rather than consume, and gives you scale,
structure, and power when you do it.

18.2.1 Scale

Writing scales infinitely. We used to write on stone tablets, and then on

parchment, replicating copies manually. Modern civilization began with the
invention of the Gutenberg Press, which made mass reproduction of writing
possible, and gave immortality to the best writers. Computers digitized that
process, and made it even cheaper to copy text. The Internet made it trivial to
spread great writing worldwide in seconds. For the first time in human history,
great writing can now go viral. Other forms of media exist, with higher
engagement and information density, but writing will never be beaten in raw
reach. When you write, you scale your ideas, your brand, and your self
infinitely.

“Having a command of communication, in spoken form and in written

form, provides you with an Archimedes lever for whatever other skills
you have.” - Tim Ferriss

Writing is searchable, and writing lives forever. Search and storage are things
that human brains are particularly bad at - we should offload that to computers as
much as possible. It just so happens that the most indexable and durable format
for storing this information is in writing. Do you remember what you worked on
five years ago on May 10th? No, but your journal does.

“When you write, you become a resource for your future self. It’ll
save you time (pulling up your own blog post is a lot quicker than a
 fresh Google search), you’ll get all the credit (instead of some Stack
Overflow post), and it’ll make all that writing feel even more
worthwhile.” - Alex MacArthur

A quick note on Search: Writing controls your narrative. For people who
don’t know you, your online presence is solely what they find on Google. Most
people’s “Personal SEO” is terrible. They probably don’t have negative stories
published online, but also there’s usually a lot of random junk from their digital
footprint. Writing fills that empty space. If I googled you and found excellent
writing, I have a much better opinion of you before I ever meet you. (And
everyone googles you before an interview! It’s not “fair” but it is fact.)

“If you’re not writing stuff on the Web, then when people search for
you they’re going to find stuff that you don’t control.” - Joel Spolsky

18.2.2 Structure

“Writing is a tool for thinking. If you can’t build up a thought

structure over time and continually go back and rethink and revise it,
you’re limited to just what you can hold in your head.” - Conor White
Sullivan

The other thing brains are bad at is giving structure to a fuzzy cloud of loosely
related ideas. Writing organizes your thoughts. Steven Sinofsky, who led the
development of Office 95 and Windows 8, is more to the point: Writing is
Thinking. When you write, you are forced to a definite sequential order - even
unordered lists have implicit order. As we write, we give weight to key ideas
and emphasize word choice and phrasing. Links are the best addition of the web
to writing - You can hyperlink to original sources, so readers can follow up if
they wish, but still keep on topic with what you are saying.
 “Writing is a linear process that forces a tangle of loose connections in
your brain through a narrow aperture exposing them to much greater
scrutiny.” - Andrew Bosworth

Writing is meditation for the busy mind. It forces an internal monologue on

what you prioritize, and what abstractions and groupings describe your world.
You could say that writing defragments your brain and keeps you honest.
When you write down all your attempts to solve a problem, you engage in
rubber duck debugging that forces you to doublecheck whether what you’ve
tried is logical, and create a “save point” for you to check back on in future.
Software that is the final output of thoughtful writing is often far better designed
than software where writing is an afterthought.

“Writing things down helped me codify what I actually cared about,

and helped keep us true to our principles as we grew.” - Charity
Majors

“Writing things down is a medium for self-discipline.” - Andy Grove

Writing makes others perceive you as smarter. An organized mind will seem
instantly smarter than a disorganized one every time. Because our brains lack
structure, we crave structure. My best talks start off with writing an outline,
because a written outline is the minimum viable talk. Just by having gone
through the exercise of organizing your thoughts, writing even helps you sound
smarter when speaking unprepared, whether to a large crowd or to a single
coworker. You know those moments when a speaker says something profound
and everyone rushes to write it down? That phrase was probably written down
somewhere first before it was ever uttered. The other way to frame this: writing
makes how smart you actually are shine through.
 “I almost never say anything in public that I haven’t written down
before.” - Neil DeGrasse Tyson on how he communicates so well

18.2.3 Power

Writing lets you explore ideas cheaply: It’s easy to pivot an essay halfway,
reorganize by cutting and pasting, and test out different words and structures
before committing. This is because writing is cheap - you can sketch out an
entire architecture or business plan in just a few paragraphs, without
implementing it! But the cheapness of writing extends beyond experimentation -
you can also map out hypotheticals and consider edge cases without actually
accounting for them right away.

“Writing is my way of expressing – and thereby eliminating – all the

various ways we can be wrong-headed.” – Zadie Smith

Writing is abstract. You can convey feelings, systems, concepts, and stories
that don’t yet exist. Writing is the ultimate friend of the creator because it isn’t
limited by inconvenient things like reality. Yet, writing is also constrained -
you aren’t allowed to pick colors, worry about audio, futz with screen resolution
or take a million other little design decisions that perfectionists mess with
instead of creating. So you eliminate the paradox of choice and just get going
with transferring your ideas and learning to the printed page and digital
document.

Writing buffers your inputs until you are ready. Ideas, information, and
learning happen spontaneously in a continuous fashion. They don’t respect your
personal schedule. However your time for creating is limited. You need to
serendipity and focus to coexist. Writing things down as they come to you
helps you “save your mental state” and defer creating until the time is right and
you have enough for something truly great. Writing turns push to pull.
 Note: This is related to Mise en Place Writing (Chapter 36).

Writing is permissionless. People with authority have more immediate

credibility, but ideally, great ideas can come from anywhere once they are
written down. Paul Graham says it best:

“Anyone can publish an essay on the Web, and it gets judged, as any
writing should, by what it says, not who wrote it. Who are you to write
about x? You are whatever you wrote… The Web may well make this
the golden age of the essay.”

The Internet isn’t a strict meritocracy by any stretch, but it is probably more so
than any comparable real world institution.

18.3 How to become a Good Public

Writer
You should write a lot.

Notice that I did not make this section about how to be a “Great” writer. That is
because I am not one. But the point is also that you don’t have to be a “Great”
writer to do well in your coding career. You just have to be Good Enough
(Chapter 16).

18.3.1 Getting Started

People who don’t write regularly are understandably cautious when asked to
start being a public writer. You can get started with three simple steps:

Have a place to write: For some this is an old-school paper notebook, for
others, Emacs Org mode might work. I write in OneNote or Notion because
 searchability and cross platform capability is important to me.
Find time to write: Eliminate distractions. You waste a ton of time in
distractions. Use writing to fill those holes of boredom in your routine. Use
airplane mode when you write. You probably spend a lot of time
reading/watching/listening to developer content - take some of that and
write down what you learned - otherwise, 99% of it will be gone from your
memory and you might as well not have consumed that content anyway.
You can also sacrifice a vice, like TV or social media time, to find more
time to write.
When in doubt, don’t publish: I will always encourage you to publish
your work, but if you’re not sure if you should, then keep it private. It’s
more important to establish the habit of writing - you can publish what you
wrote later when you find your style.

Many people don’t publish their writing because of impostor syndrome. I’m
certainly not going to be the first or last to tell you that you don’t have to be an
expert to write about something. If you must, put a big disclaimer saying what
research you’ve done into the topic, and let people correct you if you are wrong.
This is how experts become experts.

Another objection is that you still don’t have time to write. Don’t forget that
you can write with the explicit intent of saving yourself time. When you
summarize things you have read, you not only solidify it in your memory, you
save time for your future self when you run across it again or need to quote it.
And when answering questions - rather than explaining the same thing over and
over - you write your explanation once, publish it, and you’re done. From then
on you can just point people to it. As Scott Hanselman notes: Do they deserve
the gift of your keystrokes?

Some people feel like they lack ideas for what to write. Easy! I have four
categories for you to get started writing:

Write summaries of things you learned (talks, podcasts, blogposts, books).

Bloom’s Taxonomy teaches us that remembering is only the start of
learning; we have to understand, apply, analyze, evaluate, and create in
our own words before it becomes a part of us.
Write down your standard process for How You Work, like this “How I
Write Backends” post
 Write down interesting war stories of outages, nasty bugs, and performance
improvements
Look for questions other people are asking (e.g. on Twitter, Reddit,
StackOverflow, etc.) and answer them in your own words

It can be tempting to write about news (e.g. “This Week in X”), but that has a
very short half-life. Where possible, prefer evergreen content – topics that will
still be relevant in 5-10 years – in order to benefit from Lindy Compounding
(discussed in Chapter 12).

Write down what’s obvious to you. Derek Sivers is fond of saying that What’s
Obvious to you is Amazing to Others:

First you can start with What topics: “What is Kubernetes?” “What is
Agile?” (Julia Evans’ free zines are great examples of these, but yours can
be just text of course)
Then you progress to How: “How do I do X in Y?” (Josh Branchaud has
gathered a huge audience posting just tiny bitesized TIL’s for years)
Then get introspective with Why: Why Do We Write super(props)?
for underexamined commonplace things
Then get more historical and introspective with When and Who topics.
Careful not to disclose confidential information!

Pay particular attention to questions that you ask. When you figure out your
answer, don’t just carry on with your day - WRITE IT DOWN!. As Chris
Coyier says, “Write the article you wish you found when you googled
something”. You have no idea how often you’ll be referring to your own work
when the need comes up again, or when others have the same issue.

18.3.2 Going Public

You should eventually try to publish your writing, not least because having other
people read your writing, correct your mistakes, and become fans of your work
is half the benefit of writing at all! Andrej Karpathy, the Stanford superstar
responsible for Tesla Autopilot, notes that he goes “the extra mile knowing
others may scrutinize [his] published work… [so he works] harder to make
things correct and consistent”.
 “By writing on a blogpost I was held to higher account than I ever
would be internally.” - Troy Hunt

You may be the sort of person that craves feedback for your work if you put it
out there (most of us are). Make peace with the fact that everybody wanders
around in the wilderness a long while before finding an audience. David Perell
calls this the Four Months of Quiet, where you might put out a blogpost a week
for 15 straight weeks and only get noticed on the 16th. For me it was about a
year. For Troy Hunt, it took years of blogging about everything under the sun
before finding his niche as the Security Guy. Think about the community you
serve as well. Focus on a single platform rather than scatter your shots – every
platform has quirks and nuances that make certain types of content perform
better on it than anywhere else. Bootstrap your readership on that platform and
then transfer it to a domain you control.

Note: More on “owning a domain” in Marketing Yourself

(Chapter 39)

Bottom line: be patient, hone your writing. You’ll find your groove eventually.
Endure long enough to get noticed – you will be noticed, because people who’ve
done it notice others who are doing it. Game recognizes game.

What you write is strongly influenced by what you read. Read and do
interesting things. Dive down rabbit holes. Go back in time. If you just read
the same stuff everyone else does, don’t be puzzled why nobody reads what you
write.

Write down what “everyone” knows but doesn’t write down. Address the two
questions everyone wants to know: “So What?” and “Now What?” Explain
complex things simply. It’s a guarantee that there will be people that will be
eternally grateful. Every tribe needs a scribe. Not everything can be written
down – Polanyi’s paradox teaches us that there are many things we cannot – but
plenty of knowledge isn’t written down simply because nobody bothered to.
This book consolidates tacit knowledge learned from years of personal and
collective experience, but anyone could have written it if they were determined
enough.

If you want to do well in SEO, you can try doing TDD: Title Driven
Development. Use keyword research like KeySearch to find keywords you can
rank for. Then pick a standard title format that you know works because you’ve
read dozens of these before (these ideas are from Monica Lent’s free blogging
course):

React Router with TypeScript: The Complete Guide

How to use React Router with TypeScript
Step-by-step: How to use React Router with TypeScript
Use React Router with TypeScript (2020 Guide)

Alternatively, if you want to offer more context, a popular template for writing
has 4 steps:

Telling a compelling story

Relating it to your personal experience
Proposing a solution
Ending with Practical How-To Tips.

This format is popular for everything from self-help to recipe blogs because it
works.

That said, sometimes readers just want the deep dive – write the most
comprehensive, ultimate resource possible on your topic! This is known as the
Skyscraper technique in the content marketing world. Corbett Barr calls this
Write Epic Shit – the Internet disproportionately rewards high effort, high
quality content. This can be about anything from A Complete Guide to CSS
Grid to Falsehoods Programmers Believe About Names. However, this can be
exhausting if you try to do it all the time, so don’t feel like you have to hold
everything to you do to an impossibly high standard. See also Flavio’s SEO
learnings from blogging every day.

Don’t be afraid to remix your writing. It’s almost certain that nobody will read
everything you write. The last part of David Perell’s Five Pillars of Writing is
repackaging existing work. If the ideas connect, link back to them, or copy them
over, or throw them out and rewrite it better. You will seem enormously
productive, and your work will seem of incredibly high quality, to people who
don’t know you are remixing prior work. For example: 10 chapters in this
book were previously blog posts, which helped get this book done faster, though
all have been extensively reworked.

If you want feedback fast, there is a way to almost guarantee it - Pick Up What
They Put Down (Chapter 19). In the words of Dale Carnegie: “To be
interesting, be interested (in others)”. Build relationships one by one instead of
spraying your writing to an uncaring Internet and praying it works.

My advice to people to unlock creativity is really just go put things

out into the world. Any old things - not impressive things - just
anything. You can go imitate things, like a musician who does cover
songs… Creativity is just doing stuff, it’s just putting stuff out there, it
doesn’t have to be shockingly original. - Derek Sivers

18.3.3 The DIY PhD

You can become a very good, well regarded writer by earning a “Do-It-Yourself
PhD”:

Look for a Nexus of Interest, the most interesting topic to you that is also
interesting to others
Write a million words to deliberately improve from where you are, to
becoming the world’s foremost expert on that topic

The first part is straightforward. Most life advice converges on some form of
Ikigai, the idea that you should do the intersection of what you love, what you
are good at, what the world needs, and what you can be paid for:
However this is unattainable if you don’t yet know any of these. Writing is the
way to get there. So we can make two simplifying assumptions:

Instead of the hackneyed advice of “do what you love”, we assume that you
will learn to love what you do well. This is the more realistic truth and it
better explains why people unironically love, and are great at, all sorts of
things from tax code optimization to designing high availability systems for
multibillion dollar corporations.
 Whatever the world needs, you can be paid for it. As Naval Ravikant
has often noted: “The internet has massively broadened the possible space
of careers. Most people haven’t figured this out yet.” Global reach has
freed every niche from geographical constraints, and global payment
systems have enabled everyone to create viable businesses serving every
niche.

With that, we collapse the four parts of the Ikigai concept into just two: Find
something that is most interesting to you, that is also interesting to others. That
is the raw essence of Ikigai, and that is what I call your Nexus of Interest.

The second part is less obvious – writing a milion words as a means to both find,
and grow into, the predominant expert in your Nexus of Interest.

Why a million words?

It’s not about the precise number, it’s about the order of magnitude of effort that
will turn you into a world class authority. You’ve already written a million
words once, probably twice in your life. Sum up everything you ever wrote from
your first word to your last high school exam (or whatever is equivalent in your
life path). That was about a million words to get you from illiterate to highly
literate. Then, if you went to college, especially a liberal arts one, you wrote
another million-ish words to get your degree, across your essays, senior thesis,
class projects, extracurricular activities, and so on.

You achieved so much just by writing what people assigned you to write. Now,
as an adult, imagine what happens when you write a million words to find,
research, and share what you assign to yourself. You don’t need any admissions
committee to give you permission. You don’t need a supervising professor to
sponsor your work (though mentors can help!). You don’t need a pre-existing
field with departments and grants and endowments. You just need to find your
Nexus of Interest and write and publish more work than anyone else on earth
towards it.

THAT is the DIY PhD.

Take any pace you want. I like the symmetry of 1000 words a day for 1000
days. Absent weekends and days off, there are 250 days in a year, so that
works out to four 250 word pages of notes, ideas, blogposts, documentation, and
code comments for four years.

So how do you learn to write (anything) well? There’s only one

answer: you’ll learn to write well if you write. A lot. - Jacob
Kaplan-Moss, on the Django Docs

Among writing experts, it is almost universally agreed that quantity begets

quality (but it doesn’t “just happen”, you have to deliberately improve):

Jeff Atwood’s How To Achieve Ultimate Blog Success In One Easy Step
has one step: “Pick a schedule you can live with, and stick to it… If you
can demonstrate a willingness to write, and a desire to keep continually
improving your writing, you will eventually be successful.”
Tim Ferriss, the bestselling author, uses this rule: Write two crappy pages
per day. He keeps the expectations low enough that he is not so
intimidated that he never gets started.
Julia Cameron starts her day with three pages of longhand, stream of
consciousness writing and calls it her Morning Pages - Brian Koppelman
does this to override negativity and jumpstart his own creativity to write
great shows enjoyed by billions.
It happens that 2 pages at 500 words each adds up to 1000 words a
day. That’s exactly what Nathan Barry committed to in 2012 before he
published his first book, built a following, and eventually created a 9-figure
email marketing business. He committed to writing 1000 words a day and
even made an app to track it. His realization: “Slow, consistent progress is
the only way to make big things happen”.

You’re probably thinking it can’t be that simple. There are a million other things
that go into making great writing, and we’re not addressing any of that in this
simple goal. Yes, that’s a future chapter of this book, but I’m banking on you to
figure that out as you go along. But you don’t get there if you don’t, at a
minimum, write more.

The truth is: It almost doesn’t matter how well you write. Some of the best
regarded developer-writers, like Steve Yegge, Patrick McKenzie, and Dan Luu
don’t obey any traditional patterns of Good Writing. Run-on sentences, long
paragraphs of unstructured rants, obscure jargony references, none of it matters.
What matters is that they know what they like to talk about and what captures
their readers’ interests.

The traditional writing advice we get in school is very bad because it

doesn’t focus on what’s important in writing. Grammar, style,
structure, none of that matter. You know what matters? Entertain
your reader or inform your reader. -Nick Maggiuli, Of Dollars and
Data

1000 words a day is a significant commitment - anywhere from 2-5 hours of

writing, depending on your process and purpose. Remember that it doesn’t have
to be good - it just has to be useful to your future self. You can get there with:

500 words of notes on everything you read and learn and watch and listen
to
250 words journaling your state of mind and your goals (journaling is a
great way to time travel)
250 words of actual writing meant for others to read - documentation,
blogposts, etc.

That doesn’t look so bad, does it? Of course, tweak it however you like. The
way you count words is really up to you. When Nathan Barry committed to
1000 words a day, significant acts of creation - like recording a YouTube video
or podcast - counted towards his quota. For me, tweets and code do not count.
Brain dumping a list of ideas, like I did before I wrote this essay, counts.
Writing summaries of articles and private journal entries count. You might hold
yourself to different standards. Your life, your rules.

If the 1000 a day pace is too much given your existing commitments, take it
slower for longer. 800 words a day for five years. 666 words a day for six
years. 400 for ten. Adjust to taste! It’s a marathon, not a sprint.

When you commit to writing a million words, a few things happen:

You will be more selective about what you consume. Writing notes and
summarizing takes time. If you consume content with the intention of
writing down what you learn, you will have less time and therefore have to
be more picky. When you switch from consume-to-consume to consume-to-
create, you naturally spend less time being a passive consumer and more of
an active remixer and creator.
You will want to get more out of what you write. You will want to use
your writing to help you work through or learn things that will help you in
your day job. Quoting Addy Osmani: “Write about what you learn. It
pushes you to understand topics better. Sometimes the gaps in your
knowledge only become clear when you try explaining things to others. It’s
OK if no one reads what you write. You get a lot out of just doing it for
you.” Over time, you may want to try writing long, concentrated repos of
information that build over time (Chapter 13), instead of a disconnected
series of one-offs.
You will want to share it. Since you spent the time to write it, you want to
increase the return on investment by making sure it reaches the widest
appropriate audience. Most developer writing dies in chat and private
email. You should aim to compound your impact by increasing reach and
longevity. (To be clear: you shouldn’t publish everything you write!)
You will quote yourself. Since you have so much writing capacity, over
time you will have written down your position and definitive list of
resources on any particular topic. Your writing becomes your own Second
Brain. (Others will quote you too!)
You won’t be afraid to write. When you are called upon to write for
something at work that really matters, others might flinch, but you will have
been practicing at high volume for much longer at a much higher standard
than anyone else.
You will want to invest in writing better. Since you’re committed, you
might as well get good. One way is to have a writing system, separating
pre-writing from writing (see: Mise en Place Writing, Chapter 36), or even
getting professional coaching or training. The investment makes sense
because you’ve committed to writing for the very long run.
You will get better at writing. Just from having tried out every form of
writing about every topic under every life scenario. Other people will look
at your work and wonder how you got there. You’ll tell them - like I’m
 telling you now - but they won’t believe you. There must be a secret.
There isn’t.

All that, from a simple commitment of writing a million words, on the most
interesting things to you that are also interesting to others. It’s simple, not easy.
You may encounter many personal obstacles to completing this. But if you can
overcome them, I really don’t see how you cannot succeed.

18.4 Committing to Writing

I am not a parent, but I liken it to what I’ve heard about that first day you come
home with your first child. You’re afraid, you don’t know if you’re the person to
do this, you don’t know what you don’t know. But you’ve just signed up to raise
this child for the next 2 decades. For the next 10 million minutes of your
life you will be a parent. So: you read up, try things out, learn from your
mistakes, and you “parent” every day. Every year millions of people commit,
and end up more or less figuring out how to be great parents their kids love.

It’s the same with your writing, your personal brand, your career. It’s your
baby. You’ll figure out how to parent it once you realize it’s yours and you have
no choice but to do it every day.

It can help to find a community of people going through the same thing as you
are. A bunch of writing commitment platforms exist: 750 Words, Diary Email,
WriteNext, Commit, Reddit’s No Zero Days, and Writing Prompts, or this book’s
own community. You can even write in a Git repo and use GitHub’s streak
tracker as a commitment device. Whatever floats your boat!

This chapter isn’t writing advice. This is advice to write. I have writing advice,
but you can only get there once you write like you breathe.

“I write because I’m scared of writing, but I’m more scared of not
writing.” – Gloria E. Anzaldúa
Chapter 19
Pick Up What They Put Down
Let’s say you’re sold on the idea of Learning In Public (Chapter 9). You want
to start right away but are feeling intimidated at all the advice out there:

“Just start a blog for the past you!” but you’ve done that before - and no
one read it - and you lost interest.
“Ask people what they want to read!” but you don’t have people to ask,
and people always say yes to free content anyway. Which you write and
they then don’t read. So you lose interest.
“Don’t worry it takes a while to get an audience!” but all the people
telling you that are unrelatable because they’re already successful in your
eyes, so you lose interest.

You’re not alone.

In the past two years I’ve talked to a couple hundred people at various stages of
their #LearnInPublic journey, and of course I went thru it myself. It’s still too
hard to start, no matter how many well-intentioned voices tell you what they do
and how they did it.

I think, like any new habit or diet, the best plan for you is the plan you can
stick to.

After doing a lot of thinking, I have a hack for you. It is six words long:

19.1 Pick Up What They Put Down

Who’s “they”? Anyone you look up to, anyone who knows more than you in
the thing you’re trying to learn. If that’s still too broad for you: Look for the
maintainers of libraries and languages you use, or the people who put out
YouTube videos, podcasts, books, blogposts and courses.

What do you mean by “put down”? Any new library, demo, video, podcast,
book, blogpost, or course that they put out. It is important that it be new. By
virtue of it being new, it is simultaneously at the top of their minds, and also the
most likely to lack genuine feedback.

(Psst… This is where you come in!)

How do I pick “it” up? Here is a nonexhaustive smattering of ideas for you:

If it’s a new library, go try it out. Report bugs, ask questions about ANY
confusing documentation, make a demo using the library, then blog about
it!
If it’s a new demo, go read the source code! Then write a walkthrough of
the source code explaining everything in your own words.
If it’s a new video/talk/podcast/book/blogpost, summarize it in your own
words.
If it’s a new course, go through it, highlight the top three things you
learned.
Sketch notes for literally anything are always LOVED.
Tan Li Hau literally became a Svelte maintainer by picking up TODO’s in
the Svelte codebase
Come up with your own ideas, I’m not the boss of you!

The BIG requirement about any of the above is that you MUST genuinely
love/be excited about the thing you’re picking up. If you don’t love it, move
on quietly. You don’t want to build a brand of shitting on things people put out.

You must also close the loop - when you have produced anything (e.g. a
blogpost) based on their work, tag the creator in social media. Twitter is
inherently designed for this, but you can also reply in a comment or email it to
them with a nice note.

19.2 What happens when you do this?

There is a VERY high chance that you will get feedback on your blogpost or
demo or tweet or whatever, directly from them. A retweet and/or follow back is
common, especially on repeated interaction where you prove yourself an eager,
earnest learner.

If you try your very best to understand the topic, AND you still get something
wrong, you will be corrected. If you keep your ego small, you will handle it. In
fact, being wrong in public will be your biggest source of personal growth.

19.3 Why does this work on them?

Simple: not enough people do it. That’s why this is a hack.

Activity on the Internet has an insane Zipf’s law distribution. This is sometimes
called the “one percent rule” - 90% of people passively view content, 9%
comment on content, 1% create. I would endorse this but for the fact that it’s not
extreme enough:

I help moderate a subreddit with 300k monthly unique visitors -

charitably, about 2k of them actually comment, and say 100 people
consistently submit content.
I get 2-3m tweet impressions a month, but only about 1-2k
mentions/replies.
Pick any YouTube video you care about. Look at the view count, and look
at the number of comments.

Basically, the correct number of passive consumption is closer to 99%, and less
than 1% even comment on newly created content. I’m not exaggerating in the
least.

Anecdote: Cesar Kuriyama, creator of 1 Second Everyday, randomly

tweeted at Jon Favreau about a script he wrote that didn’t get picked
up. This piqued Jon’s interest as most fans didn’t talk about his
failures, causing Jon to look into Cesar’s bio. Jon ended up writing
Cesar’s app into his classic movie, Chef.
In short, people are lazy. This also means you can get ahead via strategic
nonlaziness.

What’s the strategy? Say it with me: PICK UP WHAT THEY PUT DOWN.

There is a dire lack of feedback everywhere. Yes, there are industry superstars
with inboxes too hot to respond to. You will get ignored. But even they go out
of their way to respond to some feedback. And we already established there
aren’t too much of those.

On Twitter in particular, people can be shy promoting their own work. But if
someone else on the Internet says nice things about their work, well, shit, they
can RT that all day long.

19.4 Why does this work on -you-?

Feedback, feedback, feedback. You lose interest when you get no feedback.
What we all crave to keep going is feedback that we’re doing something wrong,
or right, anything to prime the next action we take. The fact that we don’t know
what the feedback will be makes it a “variable reward” - which is human catnip
for forming a new habit.

Read Nir Eyal’s Hooked model for more explanation, but basically we are
setting up:

Trigger: Something new was created

Action: “Pick it up” a.k.a you create some piece of content based on the
new thing
Variable Reward: You get feedback or endorsement or criticism from the
creator
Investment: You respond to, or internalize, the feedback so you get better
the next time around. (aka “learning”)
19.5 Your call to action
In the next month, dozens of cool new libraries and demos and talks and
podcasts and courses will be released, on things that you want to learn.

Pick three that interest you and “pick up” on them.

I virtually guarantee you get feedback on at least one. If you don’t aim too high,
you will go three for three.

Do this 12 times.

You will end the year having learned a good deal and having made many new
friends along the way. Including me… if you (ahem) tag me.
Chapter 20
Part III: Strategy
Strategy applies anytime you make major irreversible decisions, in the face
of uncertainty. Let’s discuss the major Strategic decisions that you will
encounter in your Coding Career:

Intro to Strategy (Chapter 21)

Learning Strategy:

Learning Gears (Chapter 22)

Specialist vs Generalist (Chapter 23)
Betting on Technologies (Chapter 24)

Career Strategy:

Profit Center vs Cost Center (Chapter 25)

Engineering Career Ladders (Chapter 26)

Business Strategy:

Intro to Tech Strategy (Chapter 27)

Strategic Awareness (Chapter 28)
Megatrends (Chapter 29)
Chapter 21
Intro to Strategy
Most people are more familiar with Strategy Games than they are with Strategy.
They bear superficial similarity - the need to plan ahead - but the differences are
critical.

I’ll use the language of James P. Carse’s Finite and Infinite Games:

Strategy in Games offer you infinite runs of a Finite Game, where you
have almost perfect information and the rules don’t change.
Strategy in Life gives you one run of an Infinite Game, where
misinformation outnumbers information, and the rules are constantly in
flux.

How is Real Life Strategy relevant to your coding career?

Working on the right problem dominates speed of execution on a

problem. The “10x engineer” is a popular term - widely debunked, but
large variations in engineer impact do exist. Yet if you look at code metrics,
high impact engineers don’t stand out by lines of code or number of
commits. In the words of one Googler:

For those who work inside Google, it’s well worth it to look at
Jeff (Dean, head of Google Brain) & Sanjay (Ghemawat,
cocreator of MapReduce) ‘s commit history and code review
dashboard. They aren’t actually all that much more productive in
terms of code written than a decent SWE3 who knows his
codebase. The reason they have a reputation as rockstars is that
they can apply this productivity to things that really matter;
they’re able to pick out the really important parts of the problem
and then focus their efforts there, so that the end result ends up
being much more impactful than what the SWE3 wrote.
 Engineering Leaders can make disastrous decisions. This sounds
obvious in the abstract, but in the workplace it is common to accept the
HIPPO (Highest Paid Person’s Opinion) with no critical thought. This has
direct implications for your career - you clearly want to work on projects
that will be successful. Imagine working under Vic Gundotra on Google
Plus. Or on Digg’s v4 rewrite following a Google algorithm update. Or the
thousands of other less dramatic failures that get swept under the rug in
tech. You need to understand the larger context your coding lives in; to
push back when appropriate (tactful pushback is a GREAT career skill); and
to ask for reassignment when you are being pushed into unsalvageable
failure.
Agency. You own your career when you start being aware of what’s around
you and taking control of what you work on. Agency = Resourcefulness +
Initiative. A decent programmer used to be able to work at IBM for 30
years, with the expectation that IBM would take care their career if you just
stick with them long enough. Those days are long gone. Jobs today are
bifurcated - you either tell a machine what to do (you live above the API) or
a machine tells you what to do (you live below the API). You can choose to
take control, or be controlled. Act, or be acted upon. A good manager will
be your ally in your personal journey, while a bad manager will only see
you as a tool to accomplish their goals. But even with a good manager you
bear ultimate responsibility for your career. Never them.

21.1 What is Strategy?

There are a lot of definitions of Strategy out there and only some of them are
good. We are in Corporate Business Speak territory, after all! Let me quote a
few:

Strategy is the problem of choosing problems.

Strategy answers: “What should we be doing?”
Strategy defines where to play and how to win.

There are four aspects of Strategy:

 A mental model of present Reality - where you, your competitors, and the
larger technological landscape are and are going
A Vision of the future - where you want to go
A Plan for getting from here to there
A Policy - choosing what to do and what not to do with clear rationale and
understanding of tradeoffs

This was first formulated by Henry Mintzberg as Plan, Pattern, Position, and
Perspective - because business types love alliteration - with a 5th P for “Ploy”
added for decoy/fakeout plays. I have redefined these elements so as to be more
applicable for Tech Strategy and your personal career strategy.

It helps to know what is Good and Bad Strategy. Fortunately, there’s a book for
just that.

Good Strategy:

Is Simple and Obvious - it says No to complexity

Has a theory or Diagnosis on the key challenge to overcome
Includes guiding policies and actions to take to overcome the challenge
Is Coherent - all actions reinforce and support each other rather than
compete

Bad Strategy:

Has a bunch of Fluff - corporate business speak

Fails to face the challenge - the central problem the company faces
Mistakes goals for strategy - statements of desire rather than concrete
plans (we will get it if just we want it hard enough)
Has objectives which fail to address critical issues (because they are
inconvenient)

21.1.1 How Do I Use Strategy?

Everything I have described may feel a bit out of reach. You aren’t a general or
a founder. You aren’t even a senior engineering leader yet. I get it.
But strategy applies anytime you make major irreversible decisions, in the
face of uncertainty. This makes intuitive sense. If some decision was
reversible, you’d just try it and “see what works.” And if you had no
uncertainty, your decision would be obvious. As with all decision making, “no
strategy” is also a strategy - it is you trusting your fate to the strategic choices of
someone else. If you hope to grow professionally, nondecision will be
increasingly less valid.

This section will help you think through major strategic aspects of a coding
career: how to bet on technologies, whether you should be a specialist or
generalist, technology business models, and everything in between.

You should also try to develop a mental framework for understanding reality.
Yes, that felt as absurd to type as it was to read. Tech is immensely complex and
noisy, yet there are clear supercycles and winners that you need to stay on top
of. You need a way to filter and organize information about information
technology. We will touch on Systems Thinking, Ecosystem Awareness, and
Megatrends.

Because you should understand the economics of what you work on, I will also
introduce the basics of Tech Strategy. Advertising vs SaaS vs Marketplace
business models. Horizontal vs Vertical. And other ABC’s of the Business of
Software.

Teaching Strategy is an ambitious task. I’m not an expert. I don’t know your
specific situation, and the experiences of me and my friends may not be
representative. My hope is to teach you to think about Strategy, rather than do
the thinking for you.

21.1.2 Don’t Stress Too Much

It takes a rare genius to understand Strategy. I certainly don’t. But I know to

spot people who do, really listen to what they say, and translate it to my context.
I hope to open your eyes to this as well.

I also want to caution against getting too swallowed up in Strategy. Analysis

paralysis helps nobody. You will make missteps. Don’t try to undo them –
what’s done is done, reassess without sentimental attachment to sunk cost.

As a software person, your skills are transferable, so you are less locked in than
people in other professions. Finally, on a long enough time horizon, most
decisions become reversible. If you feel stressed out, take a longer view. This,
too, shall pass.

A final thought: Peter Drucker is famous for saying that “Culture eats Strategy
for breakfast”. Whatever fancy strategy you or your leadership adopt, remember
that people are always at the heart of your work, and great people can overcome
bad strategy when united by a strong culture.
Chapter 22
Learning Gears
I can think of four gears of Learning In Public.

22.1 Explorer
Your Explorer gear is your high speed, low power gear. You’re just trying to
cover as much ground as possible, in many directions.

The main problem to solve is that you don’t know what you don’t know.
The creative exhaust you make are mainly notes to self, possibly in terms
only you understand, possibly noting problems only you have. This is
mostly in gists and blogposts and tweets and (good) StackOverflow
questions, because text is cheap to produce, although Twitch streams are
also on the rise. You are often laying out literally your entire state of
knowledge for a metaphorical rubber duck, looking for holes and
documenting for the future.
Your public output is episodic - there is no unifying theme - you are just a
field correspondent reporting from whatever foreign land you find yourself
in. This is still useful, because you can’t connect the dots until much later
in life.
The public commitment level is low, usually doable in one day sprints, so
this is a great way to get started Learning In Public and also finding what
resonates so you can switch gears. It is easy to fall off the wagon though,
because no one’s really expecting anything from you, because you haven’t
committed that much.

22.2 Settler
Your Settler gear is a high speed, high power gear. You’ve found good, fertile
ground, and there is an established playbook you can follow.

The main problem to solve is one of pure learning. You know what you
don’t know, and your sole job is to learn what everyone else already
knows.
The creative exhaust you make are still notes to self, just like with the
Explorer gear. Your task is to move up Bloom’s Taxonomy (discussed in
Chapter 9, Learn in Public) as quickly as you can, and to explore the
knowledge graph of your technology (discussed in Chapter 11, Know Your
Tools).
Your public output is less essential - a lot of what you are learning will
already be stated very well elsewhere. However now you can have a
unifying theme, because you are focusing on something! A great thing you
can do here is to keep a cheatsheet and list of links to what you have found
helpful in your journey (a great form of Open Source Knowledge –
Chapter 13).
The public commitment can be a bit higher, for example by reporting your
progress on social media and doing daily streaks like 100 Days of Code.
This can be helpful in providing motivation and external reinforcement for
your progress – note that people can be very helpful and forgiving
especially when you note you are just learning in public rather than being
an expert.

22.3 Connector
Most people should aim for your Connector gear to be their default. This is a
powerful, yet nimble gear. You connect people and ideas.

The main problem to solve is that you know things others don’t know.
Hence you should share that and they need to hear you. That takes a little
extra effort.
The creative exhaust you make is explicitly meant for others. This
means some effort is required that isn’t just about your learning, but more
about making things easy to digest. Here are the talks, tutorials, cartoons,
 cheatsheets, books, etc - Higher effort, higher usefulness, longer lasting.
You usually arent sharing everything you know, though, so it can feel like
you’re learning less. However, this is the best way to master fundamentals
because you are forced to cover your bases and be able to answer questions
you haven’t thought to ask.
You don’t have a grand overarching theme to your work, that one thing you
are known for, but usually you are juggling multiple themes, and also
learning and teaching about their intersections.
The public commitment is moderate - usually for a few weeks or months -
and often involves active exercise of soft skills that you may feel ill
equipped for. Check your ego at the door and learn that too. You are
“putting yourself out there”. But also remember Learning In Public is an
art, not a science: always rely on and refine your taste rather than
objectively trying to please everyone. Find your people, lean on strengths
you always thought were irrelevant for coding. You are presenting yourself
as an expert here, so make sure you cover your bases responsibly so as not
to mislead beginners.

Examples:

Samantha Ming with her JavaScript tips

Hiro Nishimura with her AWS Newbies community
Julia Evans with her Zines
Lin Clark with Web Assembly

See also: Pick Up What They Put Down (Chapter 19)

22.4 Miner
Reserve the Miner gear for when you’ve struck gold. Something that resonates
with people, that you are also abnormally fascinated by. When you strike gold,
you’ll know. Stop and plant your flag – this is where you should definitely
choose to become a Specialist over a Generalist (Chapter 23). Then dig in for
years – this is a low speed, high power gear.

The main problem to solve is that something important is too hard, or the
world knows too little about something this important. Therefore you dive
deep into something nobody else does.
The creative exhaust you make is very specialized - you do research and
build community and infrastructure. Miners are also Builders – they
build whatever is necessary to achieve that ultimate end goal. What you do
is meant to last. Before you, the thing was very hard, or impossible. After
you, the thing becomes much easier. The world will thank you.
You now have one theme that not just unifies your work, but that you
become synonymous with. Every person in the world who has the problem
you solve, will eventually find you, because that is how the Internet works.
(Coincidentally, you no longer need to “put yourself out there”, people will
come to you.) This might feel boring since you’re just about one thing all
the time, but what seems like one topic to you today (e.g. Machine
Learning) will eventually subdivide into different disciplines when you go
deep enough (e.g. Supervised Learning, Unsupervised Learning,
Reinforcement Learning).
The public commitment is very high - on the order of years and careers.
You’re digging a mine and spending energy far more than any other sane
person is doing - it helps if the area you’ve chosen has a good chance of
widening and deepening at the same time you’re mining. So have some
form of macro thesis for why this field in general will be increasingly
important. (More in Chapter 24, Betting on Technologies and Chapter 28,
Strategic Awareness)

Examples:

Tobias Koppers with Webpack

Jen Simmons with CSS
Lea Verou with CSS
Evan You with Vue
Ryan Dahl with Node, then Deno
22.5 Why “Gears”?
These are “gears” and not “levels” or “modes” because you can step in and out
of any gear depending on what kind of terrain you’re on and how fast and deep
you need to go. Just like with biking, one gear isn’t necessarily better or worse
than another, it just depends what you are trying to do.

22.6 What do I do now?

If you’re just starting to #LearnInPublic, start as an Explorer. Map out whatever
you’re learning, whatever tickles your fancy. Go as fast as you like, an inch deep
and a mile wide.

When you know where you want to settle and focus, become a Settler. Learn
how to learn, and learn what everyone else already knows about the topic.

When you have a good sense of the terrain and see other Explorers you can help,
start being a Connector. Link people and ideas, use your full creative talents.
Go back and cover gaps in your knowledge.

If you find yourself tripping over gold, start Mining. Dig into what people don’t
know, talk about what people don’t know they don’t know, build infrastructure
and communities to make it all easier. If it turns out a dud, switch gears, no
shame in moving on.

Four gears of learning, all in Public. Get started!

Chapter 23
Specialist or Generalist?
Let’s get this out of the way first - you can be extremely successful as either a
specialist or a generalist. It just happens that different situations call for different
types of developers.

It is hard to discuss this topic intelligently when people cannot even agree on
definitions. Someone who looks like a generalist in certain circles, looks like a
specialist to everyone else standing outside that circle. Specialization is in the
eye of the beholder.

Consider Michael Phelps. In the 2008 Olympics he won 8 gold medals. Eight.
(The guy is so ridiculous that he set a record for setting records.) To most
mortals, he looks like a swimming specialist - you wouldn’t put him in a
basketball lineup, for example. To swimmers, he looks like an untouchable
generalist - setting solo and relay world records in freestyle, butterfly, and
medley categories at multiple distances in the span of seven days.

Everything is concentric circles. Just as you feel like you’ve specialized in

something, you realize the array of subfields that fan out with people well ahead
of you in each. If you’re trying to generalize, there’s always one more level up,
down, or sideways to go.

As it turns out - this is a useful fractal you can exploit.

23.1 Leverage vs Self Sufficiency

We have acknowledged that the definition of specialists and generalists are ill-
defined. The debate is often muddled further with whether or not non-technical
skills are included (usually a strawman depending on whether one is arguing for
or against generalising).
Yet, we can still try to make some useful observations.

Specialising and Generalising thrive under different conditions.

For example, when you specialize in maintaining five nines of database

reliability with single millisecond latency and strongly consistent transactions
across five global regions, there are perhaps less than 100 companies in the
world that would need your services. But you would have a tremendous impact
on them and they would pay through the roof for you. This is because
Specialists benefit from Leverage.

You don’t have to be at a BigCo to do this - A lot of Xooglers (ex-Googlers) set

up shop outside Google and basically offer Google-infrastructure-inspired tech
for the masses.

Generalists thrive when Self Sufficiency comes at a premium. If you can

design and code, you can build a creaky MVP that lasts just long enough to
prove out demand. This then justifies hiring real specialists to fix your janky
prototype and build to scale. Or you can learn as you go, allowing you to do it
yourself.

You don’t have to be at a scrappy startup to do this. Generalists can get things
done inside BigCos by being able to work better with counterparts, and/or
sidestepping the formal process and doing it themselves when politics and
prioritization get in the way.

23.2 The “Full Stack” Developer

Many generalists just aren’t. We all specialize in something, because it is
impossible to know everything. For a long while, the term “Full Stack
Developer” was in vogue. This trended because it was a useful fiction:

it helped employers justify expensive hires as pluripotent deals (“Two in

One!”)
it helped developers market themselves as capable of doing more
 it helped educators/bootcamps sell the idea that you need full stack
education

The truth, of course, is that “full stack” developers tended to be backend

developers that learned a bit of JavaScript:

With some specialised Platform as a Service services like Firebase and Amplify,
frontend devs could also get in on the game:
Of course, this is a tired meme now, and more enlightened takes - like hiring
“full stack teams” - have emerged.

It is also understood that marketing yourself as a generalist is more difficult,

because people don’t know what box to place you in. It can be a recipe for
overpromising and under delivering when it actually comes to working with you.

However there are clear benefits to being generally capable. If you are on a
small startup team, you will generalize and handle things that you’ve never
trained for - which makes you a GREAT generalist hire for future teams. Even
in a large company, being able to speak the language of your counterparts can
help you get what you need more effectively. And nobody said that being a
“generalist” has to mean exactly equal competence on all dimensions.

23.3 “T Shaped” and “Pi Shaped”

As an industry, we will not stop trying to have our cake and eat it too. With
“Full Stack” in disgrace, the current iteration of this is the “T Shaped” engineer.
This was first defined by Valve in their Employee Handbook:

This combination of breadth and depth is, of course, appealing, but convenient in
its avoidance of acknowledging any real tradeoffs. The straw man argument
here is that by this definition, virtually everyone who is considered a specialist
can be considered T shaped, because what person doesn’t try to develop other
basic skills in order to function?

Of course, if tradeoffs don’t exist, why not go further? Scott Adams says we
should become very good at two or more things. Be a “Pi Shaped” person!
Thanks Scott!
And while we’re making things up, why stop there? You should be a Comb
Shaped person instead!!
I’m throwing shade not because people like this don’t exist. They do. It’s just
not helpful general advice, because these discussions conveniently leave out
having to give up anything of consequence in order to get these advantages, or
act like what shape you are is more choice than chance. <sarcasm> The
downsides are always small, the upside is always huge. Great. Nice Medium
article. Life changing. </sarcasm>

Probably the best take I’ve seen is Jeff Scott’s reply to me:

From my experience most developers are pear shaped!

23.4 Look Inside, Not Out
At our core, we are all dealing with our own insecurities and philosophies of
success. Do we do better by capitalizing on our strengths, or covering gaps in
our weaknesses? Go faster and do one thing well or go slower and be more
adaptable?

Malcolm Gladwell’s Outliers popularized the “10,000 Hour Rule”, arguing for
extreme specialization. Then David Epstein’s Range made the case for the total
opposite.

The world will never stop coming up with ways to tell you that you are not good
enough, that you are missing out, that you should do the opposite of what you’re
doing. It is difficult to read (and write!) advice that fundamentally accepts that
there are multiple paths to success. The real debate is less an outward facing one
of What The World Wants, and more an inward facing one of What Do I
Want.

Only you can answer that. I’m confident that once you figure it out, you’ll find a
way to be successful at it, whether as a generalist, specialist, or comb. Shape
your world to fit you, rather than twist yourself into what you think the world
wants.

23.5 When In Doubt, Specialize

I do have a prescriptive suggestion though, in case you wanted one. When in
doubt, specialize. There are a few reasons for this:

Most people have a wide range of interests anyway; in other words, the
natural tendency is to be a generalist and to learn Just in Case. So you need
to lean against the bias in order to achieve the right mix.
You will seldom be forced to specialize, but you will be forced to
generalize. Since specialization thrives with leverage, you will mostly
choose to be in those positions where you increase your specialization.
 However, when you are thrust into situations of needing to be self-
sufficient, e.g. in a small startup, you will be forced to generalize anyway.
Learning how to be an Expert is a skill in itself. When you start a lot of
things you just get good at being a starter. This is a fairly mundane process
of doing the things everybody knows you should do to get started - reading
docs, going through tutorials, making toy projects. When you become an
expert in something, you also learn how to be an expert. You know what
it’s like to push past the first Dunning Kruger peak, feel the depths of the
ignorant intermediate, and to see things through to become advanced in a
domain. This makes all subsequent expertise gain easier.
Specialization is Fractal. Because you lack domain knowledge, what
looks like specialization to you now may not look like it the more you learn
about the domain and the deeper you go. Experts thrive on narrowness.
When PhD students write their theses, they don’t address all of politics, the
stock market, or the human body, they study narrow things like the political
landscape of a particular year, the valuation vs momentum debate, or how
sleep affects productivity. Mastery needs a boundary.

To paraphrase Tim Ferris, probably all of the developer heroes you look up to
are walking flaws who’ve maximized one or two strengths. Here’s Dan
Abramov’s list of Things He Doesn’t Know - that he knows he doesn’t know.

23.6 Specialist in Public, Generalist in

Private?
Here’s a final thought related to marketing yourself as a generalist or specialist.
You don’t have to put your full self on display at all times. It can help
tremendously to be publicly known for a specific set of skills, while privately
you maintain active interests in other capabilities.

Cory House saw a 15x increase in consulting enquiries when he decided to

specialize in transitioning to React instead of offering general consulting.

Same dev. Different pitch. 15x opportunities.

Chapter 24
Betting on Technologies
Now that you have a good idea of tech business models and tech adoption
theory, it’s time to talk about how you adopt tech yourself.

24.1 Never Betting On Anything

“You are not superior just because you see the world in an odious
light.” - François-René de Chateaubriand

First we should discuss the gloomy specter of the pessimists. A great way to
limit downside risk is to simply never take any risks. You hear this a lot from
jaded developers, who are often right about certain technologies being overrated,
but are also very keen on making sure everyone knows how much they don’t
care.

This is, of course, not a great personal brand, but more importantly, I always
think about the adage that “a broken clock is right twice a day”. Yes, tech
trends are cyclical, and often what’s old is new again, but it is objectively untrue
that technology never progresses.

Pessimists view technology as a swinging pendulum, endlessly tick-ing and

tock-ing while going nowhere. The reality is more like a climber’s journey up a
mountain, tacking left and turning right in a series of switchbacks, sometimes
slipping and running into dead ends, but always trying to climb upwards.
To paraphrase George Bernard Shaw:

The cynical dev thinks technology never changes. The optimistic dev
persists in trying to change technology. Therefore all progress
depends on the optimistic dev.

It is everyone’s prerogative to be conservative with their tech choices. But

people who judge with the benefit of hindsight should never denigrate the efforts
of people who are trying to build the future - because they might actually
succeed in discouraging efforts.
We also don’t learn anything by retroactively explaining success after it is
obvious. Humans are good, too good, at back-fitting causality ex post - it is too
easy to draw the wrong lessons, to confirm existing biases, to take the absence of
evidence as evidence of absence. The scientific method of learning the true
underlying rules of the world is to form hypotheses ex ante (without the benefit
of hindsight), and then to test those theories.

A more constructive approach - still without betting on new tech - is to simply

offer up lessons from the past. It is true that people who don’t learn from history
are doomed to repeat it.

24.2 Data Driven Investing

The other way to avoid taking risks is to suspend judgment and try to base our
betting decisions on objective data instead. There are plenty of empty metrics in
development - GitHub stars, npm downloads, Hacker News upvotes, Twitter
mentions. There are even great automated tools that track these - the Changelog
and Mikeal Rogers’ daily newsletter are two examples in general open source.
Programmer Surveys are another source of high level trend data, for example the
Tiobe Index, GitHub Octoverse, and StackOverflow surveys for languages, and
then ecosystem specific ones like the npm and State of JavaScript surveys.

These are fine, but they are all imperfect proxies for things we actually care
about - how useful the technology is for our needs. As a rule, the easier to
obtain the data is, the less value it has. We care about popularity to the extent
that it de-risks your choices - bugs are more likely to be caught, documentation
is likely to be complete, and third party libraries are available to fill any gaps.
For the really big technologies, jobs are likely to be available. But as we grow in
our dev capabilities and preferences, what other people like is increasingly less
relevant to us.

Note: see Good Enough is better than Best (Chapter 16) for a deeper
discussion!
24.3 How To Be Early
As a technologist, you will frequently find yourself on either side of Geoffrey
Moore’s “chasm”, either as an Early Adopter or as part of the Early or Late
Majority (see Chapter 28, Strategic Awareness for an in-depth explanation).
The career upside, and risk, of betting on tech early is well understood, but it is
worth discussing how early to be and where in the stack to take risks.

24.3.1 Managing Risk

Your primary job is to manage your overall technology risk. Technology is a

means to an end. You should try to avoid making bets that could jeopardize your
ultimate end goal. If your goal is getting a job, then your risk appetite is fairly
low - just aim to gain expertise in what your target companies already use. If
you have job security, or already have a stack that you are comfortable with, then
you have a higher risk appetite for expanding your toolkit. If you’re trying to do
something truly cutting edge, then you should absolutely be trying out all sorts
of new and unproven approaches.

Thoughtbot and Echobind have a good approach that I liken to “Innovation

Credits”. The rule is basically that when picking a stack for a client project,
you’re only allowed to pick one or two new technologies to use, and everything
else should be familiar tech. They go so far as to allocate 1 day a week as
“investment time”, and budget in delays to their estimates for things to go
wrong. You don’t have to go to the same extent, but allocating some exploration
time is a great idea.

24.3.2 Know What’s Missing

As you build things and grow comfortable with your stack, you should be
mindful of where your productivity isn’t as great as it could be. Some of the best
developers you’ve heard of made their names because they have a “low bullshit
tolerance” - leading them to create the tools, libraries, and languages that they
then become famous for. It turns out that a lot of developers share the same
frustrations as you do - but don’t do anything about it, because they can’t
imagine a better way, or don’t mind working around the technology’s limitations.

One way to inoculate yourself against acquiring “bullshit tolerance” is to

occasionally look across the bow to other developer ecosystems. If you’re in
Full-stack JavaScript, check out Rails. If you’re in Rails, check out Laravel. If
you’re in React Native, check out Flutter. And so on. You’ll see a lot of things
that are the same or worse, but every now and then you’ll find something that
that community takes for granted, but you find absolutely mind-blowing. That’s
an idea you should steal, or a standard you should start demanding of your own
stack.

I call this “Exposure Therapy”. It’s like a neat inverse to Second System
Syndrome. You’re not evaluating things in order to switch - you’re opening your
mind to what’s possible out there, so that you don’t get too comfortable with the
status quo. Conferences and YouTube channels are very good ways of exposing
yourself to alternative ecosystems, because you can try to understand ideas and
observe effectiveness at a high level without getting lost in the details.

Keep a list of the problems you constantly run into again and again. Here’s a list
for UI Engineering. Solutions come and go, problems always remain.

When you know what you’re looking for, it’s easier to sift through the noise
and evaluate new solutions. Having built a sense of what’s missing in your
world, it’s much easier to go through the constant stream of new projects and
launches, and pattern match against how the new technology could fit in your
workflow.

24.3.3 Evaluation

Be careful not to only judge the project based on how it is today. If you’re early,
there will almost always be problems with it. It may have lousy docs, be full of
bugs or have missing functionality. This will make it look inferior to alternatives
that exist today. That’s not what you’re looking for. You’re looking for the core
idea, the thing it does differently, and, assuming everything else is fixable (it is),
how game changing that would be to your world.
Ben Horowitz, of Andreesen Horowitz, is fond of explaining it this way - New
technology is usually inferior to existing alternatives in every way but one.
He applies it most to crypto, but we could easily argue this for NoSQL or React
or any other major new wave in tech. In Thomas Kuhn’s The Structure of
Scientific Revolutions, he shows how almost every significant scientific
breakthrough is first a break with tradition, old ways of thinking, and old
paradigms. This is why we sometimes call them paradigm shifts.

You should also be aware that the technically superior project often does not
“win”. Often this is because the superior qualities require too much change,
whereas the “less superior” project compromises technical merit for
compatibility. Economics rewards evolution over revolution. This happens
again and again in tech history, from VHS vs Betamax, to React + Redux +
TypeScript vs Elm. Of course, in personal projects, you shouldn’t need to care
who “wins” (as we discussed in Chapter 16), but that changes when you are
literally trying to bet on a winner for career or investment purposes.

24.3.4 Don’t Surf Every Wave

Even after careful risk management, selection, and evaluation, there are still
many people who try to keep up on every new thing. Unless this is literally your
sole job, don’t do this. It is a fast track to burnout. Try to have an investment
thesis for how the technology fits into a longer lasting Megatrend
(Chapter 29)that makes your investment worth it.

Dave Rupert of the Shop Talk Show had a great analogy for this:

“When you surf, if you paddle for every wave, you just get
destroyed… You hurt and out of breath and it’s dangerous, to be
honest, because you could literally drown. You see the good surfers.
They just effortlessly paddle out. They figured out how to do that.
They sit out there until a big wave comes. They know how to find a
big wave. Then they say, ‘Yeah, I’ll ride that big wave because that
big wave is worth my time.’ They don’t waste energy. All energy is
put towards good surfing.”
24.3.5 People

The other factor to weigh heavily is the people behind the project. If the
project maintainers have a track record of running high quality projects, that
should be an immediate upgrade in terms of your interest level. Of course,
famous maintainers will already have this halo effect surrounding all their work.
But you should be paying attention to the lesser known ones as well, who aren’t
as much in the limelight but who steadfastly put out quality open source and
tooling that you rely on.

When it comes to People involved early in a new project, you have an ace in
your hand. You. When you choose to become actively involved as a
maintainer/contributor, instead of just as a passive user, you gain the power to
affect the direction and potential upside of the technology. Being Early is the
best time you can tie your career to a technology and grow as it grows. You
basically buy a career call option on the tech, which is even better than owning
equity. If it works out, your career benefits from your involvement and
contributions. Jessie Frazelle’s career rose with Docker, Charity Majors with
MongoDB, Ryan Florence with React, Kelsey Hightower with Kubernetes.
None were project originators, all just decided to join while still early and reaped
the rewards of the contributions.

“The best way to predict the future is to to create it.” - Dennis Gabor

It shouldn’t come as a surprise that when betting on technology, it isn’t just

about the technology itself. Technology happens as the result of superhuman
efforts by very human people, and betting on tech is almost the same as betting
on the people.

It is with this framing that we come to the topic of project values.

24.4 The Value of Values

Values are destiny.
I was first exposed to this idea via Bryan Cantrill, CTO of Joyent (and elaborated
in this talk). Here is a sampling of software platform values:

Resiliency
Velocity
Interoperability
Simplicity
Security
Maintainability
Performance
Compatibility
Availability

Building technology involves making tradeoff after tradeoff. As much as these

are all desirable values, and we of course want to achieve all of these qualities,
our decisions reveal what we actually value when we have to sacrifice one for
the other. For example, “Internet Architecture” values availability and simplicity
over security and performance. It isn’t good enough to have stated values; what
truly matters is the values that are evidenced by repeated action. The people
who run the software project vote for the values espoused by the project with
every decision.

Sometimes you get lucky, and the community leaders actually write down their
values on a document. The published Goals and priorities for C++ list just six
goals and four non-goals. Even then, proclaimed values are only half the story -
actions tell the other 99%.

If you fundamentally disagree the values of the community, you will

increasingly disagree with decisions made, actions taken, and even the way
public communication is done. These things can matter even more than the
underlying tech. When you go to industry events or get clients and customers,
you will eventually have to deal with people in your community, and you will
enjoy this a lot more if you share the same values. The more critical the
technology is to your workflow, the more you must align in values, because it
impacts everything from future development right down to the gritty details of
test suite quality and semantic versioning (Versioning is subjective because what
is considered a bug is subjective).
This is why you see things like TJ Holowaychuk leaving Node.js and Guido van
Rossum laying down his Python leadership. Values conflict is the ultimate
reason why a technology will fail to work out for you, as it is the hardest to fix.
So when betting on a technology, you would do well to get as much clarity as
possible on what it values, and to contribute to shaping positive values as you
get involved.
Chapter 25
Profit Centers vs Cost Centers
As an employee, you should be aware of whether you work in a “profit center”,
a “cost center”, or a “investment center”. This is a somewhat artificial, and
arguably toxic, classification, but it can predict company behavior, so it is worth
discussing.

25.1 A Disclaimer
If you see people acting one way while vehemently denying its very existence,
you may have hit on some fundamental, inconvenient, truth. That is how I
warily, carefully, approach this loaded topic. It is extremely loaded because it
concerns the relative worth of employees, which is not at all polite conversation.

My only goal here is to offer you first exposure to the received wisdom on this
topic for those who haven’t even heard of this, and then to leave you to come to
your own conclusions. I don’t even know how to feel about it myself, apart from
the fact that I very definitely have mixed feelings on the topic.

25.2 Definitions
Alright, I’ve covered my ass. Here goes:

Profit centers bring in money to the company. There is no limit to how

much they can bring in, however their outcomes are not always within their
control (e.g. due to the economy and competitive landscape).
Cost centers spend the company’s money as efficiently as possible. The
maximum possible savings is 100%, however controlling spending is more
predictable (as it is tied to things within company control).
 Investment centers hemorrhage the company’s money today in hopes of
profit tomorrow. This can take the form of conducting R&D, or creating
loss leaders that draw future customers.

Now, as a developer in a dev team: Which are you in? Which do you want to
be in?

The problem is that these concepts don’t exist in formal accounting. They are a
matter of perception, and therefore sometimes the subject of intense politics and
spin:

An out of control cost center might justify itself as an investment center

based on promising future benefit that never arrives.
A desparate or greedy profit center might find a loophole that lets them
book profit upfront and misattribute the true cost to a cost center.
Investment centers get set up when business is going well, waste money for
years with no accountability, and get shut down at the first sign of trouble.

These shenanigans aren’t theoretical, they happen all the time.

25.3 “Close to The Money”

Time for a quick anecdote to help you understand how real this is outside of
tech.

When I was in investment banking, we not only directly acknowledged the profit
center/cost center divide, we formalized it in department group names:

“Sales and Trading” and Corporate Finance directly dealt with clients,
closed deals, and booked revenues, hence they were the Front Office.
Risk and Compliance reviewed deals for regulatory, market, and
counterparty exposure limits, therefore they were the Middle Office.
Accounting, Logistics, and Operations did the dirty jobs of confirming and
clearing trades with their counterparts at other institutions, the final step of
any trade or deal, hence they were the Back Office.
The bewildering array of departments in the bank was originally hard to
remember, until a trader pulled me over and explained, “Look, it’s simple. You
make more money the closer you are to The Money.” (In a bank, “The Money”
meant either the clients, who had the money, or having executive decision on
deals, where the bank made money.)

It was true. Front Office people could make millions as a cut of the revenue they
brought in. Sharp suits, flashy smiles, corner offices, busy busy. Middle Office
people mostly consisted of retired Front Office people or model quants (people
who measure risk rather than take it). Back Office was generally the lowest paid
and had the worst literal office space and budget. Dim lighting, TPS reports.
Promotions went one way (from Back to Middle to Front) but never the other.

Can you spot the profit center and the cost centers? Look, I pass no judgment on
whether this is the right way to run a business and treat employees. I merely
observe that this is a thing that happens.

It isn’t about power - if you screwed up something, the social structure inverted.
Middle Office’s sole job is to rein in Front Office people when they overstep,
and Back Office can make Front Office’s lives a living hell pretty much on
command, as there is always something they screwed up.

We had no “investment centers” - banks aren’t in the business of innovation or

rapid customer acquisition. I’d say they’re pretty rare in most companies, but
tech companies may have them because they understand the importance of
playing long term games. This is one of the responsibilities of the CTO
compared to the VP of Engineering.

If you are interested in doing research and doing cutting edge work, get an
Investment Center job, free from the shackles of financial accountability.
You’ve probably heard of the amazing advancements that came out of Xerox
PARC and today Microsoft Research and Google X are probably its spiritual
successor. However it is true that there are much fewer corporate research labs
today than before.

25.4 Profit Center, Cost Center

Profit Center “budgets” are “revenue budgets” - i.e. how much they are on hook
to make according to that year’s plan. Profit Centers think about growth, and
what could go right. Cost Center budgets are what we normal human beings call
budgets - an amount of money set aside that you are cleared to spend. Cost
Centers think about efficiency, and what could go wrong.

Profit Center headcount is based on external opportunity - if someone with a

great network can be brought in that will boost revenues, or a new market
opportunity opens up that requires more hires, objections are few and far
between. Cost Center headcount is based on internal efficiency - you look for
credentials, stability, track record, and you win by doing more with less.
Headcount increases go through heavy vetting and political horsetrading (not
always true; a company in hypergrowth may actually need to grow Cost Centers
faster than any other department).

When the company isn’t doing well, the company is loath to let go of top Profit
Center people, because they have to do the math around the loss in revenue vs
the money saved. Cost Center people are net money burners though, so it is
easier to let some go and ask those who remain to do more. This isn’t always
true; when the economy is tanking or the competitive landscape has shifted,
there might be not enough market opportunity to keep around Profit Center
people. If your company has salespeople, talk to them about how they break
down sales pipelines for more information.

Profit Centers and Cost Centers can’t live without each other. They are partners
more than competitors. Profit Centers don’t deserve 100% credit for all the
profit they make, because Cost Centers make it possible for them to get that
revenue. Cost Centers aren’t to blame for 100% of the money they spend,
because they to a large part spend it on behalf of Profit Centers. And yet
companies sometimes forget.

If you personally have been through some of this - I’m sorry for bringing it up -
but also we should consider where the developer sits in all of this.

25.5 The Developer’s Choice

Where does the developer sit? There’s a take going around that developers are
treated like profit centers but are just highly paid cost centers. I don’t know that
it’s always true. It is all a matter of framing.

On one hand, developer efficiency is a point of pride. The company does want
you to get more done with less. Developers don’t have direct revenue
attribution, and dev teams sure do spend a lot of money. When you design
scalable systems, you are “doing more with less” - hopefully the cost to maintain
the system grows sub-linearly relative to the number of users of the system, for
example. Arguably you are a high-performing cost center.

On the other, developers are highly paid, highly in demand, have great offices,
and when a new market opportunity opens up, more developers are needed to
write the code to go after that opportunity. When you create a feature used by
millions, like Snapchat Stories or Facebook’s Newsfeed, that then drives billions
of market value to the company, you are most definitely a profit center.

You can make a good case for either side, even for the exact same job! Consider
the Billing Engineer - their job is to make sure bills go out, and payments get
processed, with discounts, dunning, and upgrades applied appropriately. Seems
like a reliability/stability/efficiency issue. But if they make even a 1%
improvement in recovery rates, that’s real money. You literally cannot get closer
to The Money than the Billing Engineer.

I think what you are depends on how you are perceived by management. If you
sit on a product team that is going gangbusters, you are now a profit center,
because you helped make that. If you work on a project that doesn’t make
revenue yet, you work on an investment center. If your company/team/manager
fails to translate your work into business results, you are a very expensive cost
center. Regardless of what you are, it is possible to do well in any of these
roles by beating expectations. Just understand how beating your quarterly goals
might not translate to long term reward from the company if you’re simply in the
wrong strategic place at the wrong time.

The entire Strategy section of this book is dedicated to helping you select
projects and companies where you will be a profit center, and if you aren’t in
one, to understand how to potentially turn or pitch your work into something that
is a profit center. But regardless of where you sit, do always acknowledge the
contributions of the people who helped you along the way.
Chapter 26
Career Ladders
“What will it take to get to the next level?”

This is a very open ended question, but it can be nice to set some guidelines
around your company’s expectations. As an individual contributor, career
ladders tell us what the company ostensibly values (and, by omission, what it
doesn’t value). Because they are formally endorsed systems, you should plan
your strategic choices around your company’s ladder. However, you should try
to value doing the right thing and being a good teammate, over mercenary
optimization to check boxes on an assessment rubric.

26.1 When and Why to Ladder

Some companies don’t have formal ladders at all; they may be too small to
justify the formality. However, it is still helpful for you to have a clear
discussion with your managers about what is expected for you to succeed in your
role. They should want you to earn more responsibility, increase compensation,
and have some long term plan to keep you growing and engaged for the next 5-
10 years. If they don’t seem to care about giving you a fulfilling long term
career, this is a big red flag.

Companies generally start introducing formal ladders once engineering gets past
40-50 people. Given a standard ratio of 1 manager to 6-8 engineers, that means
between 5-8 engineering teams - just about the breaking point where a VP of
Engineering stops being able to equitably manage the career progressions of
everyone on a case by case basis. If you see an opportunity to ask for formal
laddering, go for it. Your leadership in the matter will give you a voice in setting
up the system you work in.
Many engineers feel the need to go into engineering management to reach the
next level. However, the demands of managing people instead of code are
wildly different (as discussed in (Chapter 7)). This can burn out the employee
and cost the company a great engineer, in a perverse form of Peter Principle.
Companies combat this by establishing an equivalent technical leadership track
alongside the natural managerial tracks that form, in the hopes of creating viable
career paths for excellent engineers who don’t want to manage people. This
“Technical Leadership” or “Individual Contributor” track is what we will focus
on for this chapter.

Ladders also serve as a way to normalize experience between companies. Your

title matters when and if you need to get your next job. Without an industry
recognizable level, recruiters can easily “underlevel” you just to fill a spot,
setting your career and compensation back by years. Counterintuitively, you
also don’t want to have a title well ahead of your experience level. Title inflation
reflects badly on your employer, which then reflects badly on you.

Some companies want to be flatter organizations, and actually stop at the Senior
Software Engineer title - roles and responsibilities then start taking more
precedence than title. Others, like Netflix, only start at Senior Software
Engineer. Is it clear that there’s no industrywide pattern? Sorry.

26.2 Our Approach

For the first part of this book, we mainly focused on getting you from Junior to
Senior Engineer. We cover this in its own dedicated chapter in the Careers
section (Chapter 5).

The rest of this chapter is focused on giving you a general intuition for career
strategy throughout your coding career. This is difficult not least because every
company and every situation is different - however we do have a lot of hard data
collected from public engineering ladders (see below). We can combine that
with intuition and anecdata from shared experiences to arrive at some probably
good ideas.
26.3 What Companies Want
There is some consensus on what to call each experience level. If we had to
condense each:

Junior: Learning best practices, executing under guidance. “Intermediate”

developers also fall into this bucket by virtue of being not-senior.
Senior: Independent execution, mentorship of Juniors.
Staff: Team lead, defining best practices, architecture, improving
productivity.
Principal: Industry accomplishments, owning technology/roadmap.
Large companies also have “Architect”, “Distinguished” and “Fellow” titles
to reflect various degrees of super-seniority.

This loosely maps to the five-stage Dreyfus model of Directed Skill Acquisition:

Novice: Rigid adherence to rules or plans. Little situational perception. No

(or limited) discretionary judgment.
Advanced Beginner: Guidelines for action based on attributes and aspects,
which are all equal and separate. Limited situational perception.
Competent: Conscious deliberate planning. Standardized and routine
procedures.
Proficient: Sees situations holistically rather than as aspects. Perceives
deviations from normal patterns. Uses maxims for guidance, whose
meanings are contextual.
Expert: No longer relies on rules, guidelines or maxims. Intuitive grasp of
situations. Analytic approach used only in novel situations.

All companies track progression on multiple dimensions - here is an amalgam of

how the extreme ends of the experience spectrum look like so you can place
yourself and find a direction to improve.

26.3.1 Most Junior

Technical Competence

Learning best practices and the codebase

 Can work on scoped problems with some guidance
Write clean code and tests
Participate in code reviews and technical design

Execution

Commits to & completes tasks within expected time frame, holding

themselves accountable.
Building estimation skills.
Asks for help to get unblocked when necessary.
Learning tools and resources.

Communication

Learning to work collaboratively on a team and communicate in meetings.

Effectively communicates work status to teammates and manager.
Proactively asks questions and reaches out for help when stuck.
Voices concerns or need for clarification to their manager.
Accepts feedback graciously and learns from experience.

Influence

Has project/team-level impact.

Pairs to gain knowledge.
Represents their team well to others in the company.
May participate in hiring.

26.3.2 Most Senior

Technical Competence

Technical leadership for their domain

Independently designing solutions for scale and reliability
Primary expert across multiple areas
Focused on highest impact, most critical, future-facing decisions and
guidance, advancing company technically and affecting business success.

Execution
 Able to plan & execute large, complex projects with interdependencies
across teams and systems, spanning months to years.
Looked to as a model for balancing product and engineering concerns.
Trusted with any critical project or initiative.
Owns capacity and growth of technical systems across multiple domains,
defining key metrics.
Creates a compelling technical vision with company-level impact,
anticipating future needs.

Communication

Comfortably communicates complex issues to diverse audiences inside &

outside the company.
Proactively identifies and remedies communication gaps and issues.

Influence

Routinely has org- to industry-level impact.

May work with exec team on high level technical guidance.
Has obvious impact on company’s technical trajectory.
Influences company goals and strategy, identifying new business growth
opportunities.
Expert on company’s platform, architecture, and workflow.
Builds leaders.
Educates across the org.
Defines and models engineering brand, patterns, and practices.
External ambassador, drawing engineers to the company.
Recognized leader within company and possibly in broader technical
community.
Leads complex initiatives with long-term, strategic value.

26.3.3 Other Dimensions

Many ladders evaluate employees based on how they demonstrate Company

Values as well, covering themes from teamwork, disagree and commit, growth
mindset, ability to give and act upon feedback, and degree of trust. If you are in
a position to influence your company ladder, consider advocating for including
sponsorship of underrepresented minorities directly into your company ladder
(discussed in Chapter 6). The best way to show you really care about making a
dent in tech’s diversity problem is to make it a part of your formal evaluation
and promotion criteria.

26.4 Individual Company Ladders

Quite a few companies publicly share their engineering ladders. Here, we will
take a brief look at each, but of course feel free to dive into each to appreciate
fuller details.

Fog Creek: from 2009, but obviously Joel’s thinking has been very
influential. Focus is on growing ownership, ability to write production code
independently, shipping experience, and at senior levels,
design/planning/architecture. Teamwork, self study, mentorship, and
impact are all key, as well as the Joel Test.
Rent the Runway (spreadsheet): from 2015. Takes a fun D&D inspired
Dex/Str/Wis/Cha stats based evaluation, corresponding to technical skill,
productivity, impact, and communication/leadership. Management track is
also included, with more focus on architecture, hiring, organizational skills,
and leadership/salesmanship.
Artsy: inspired by Rent the Runway
CapGemini UK: also inspired by Rent the Runway
Basecamp: Pretty minimal, just like the rest of the company’s ethos.
Thumbtack (spreadsheet): from 2019. Breaks down technical skills into
code quality/testing, debugging, and scoping/project design, and
nontechnical factors to collaboration, citizenship, leadership, and
impact. Leadership is interestingly broken down into Autonomy,
Judgement, Initiative, and Consensus Building.
CircleCI (spreadsheet): one of the most well known ladders, detailed but
not overwhelming. Notably, one of the values assessed is Security.
Envoy: pretty simple ladder list, by a hot company.
Financial Times (webapp). Even has an API! Only four areas across
Technical, Leadership, Delivery, and Communication are assessed. Feels
manageable.
Patreon: focuses on five dimensions of Technical, Execution,
Communication, Influence, and Maturity
Meetup: splits roles into Makers and Managers.

Makers focus on Architecture & framework & software development,

Best practices & architecture & code reviews, Technical skills
evaluation & mentoring, Introduce new engineering tools & mentor
adoption, and Recommend process improvements & support adoption.
Managers focus on Performance evaluation, Career growth, Recruiting
& resourcing, Rollout process improvements & adoption of
engineering tools and Organization & administrative.

Socialbakers: seems pretty similar to Meetup’s ladder

Medium (gist): has tracks for Mobile, Servers, Foundations, Web client,
Project Management, Communication, Craft, Initiative, Org design,
Accomplishment, Wellbeing, Career development, Evangelism,
Community, Recruiting, and Mentorship! Phew!
Starling Software: Uses Big O notation to denote levels, which is a fun
shibboleth. Skills are broken out to Computer Science, Software
Engineering, Programming, Experience, and Knowledge. This one has a
long record on Hacker News but is a good map of things that we can work
on.
Kickstarter: basically a bunch of job descriptions, including Data careers
and CTO.
Brandwatch: explains levels at a high level, and then breaks it out for IC’s
and Management in this spreadsheet. A total of 15 attributes to work on!
Spotify: famous for its “Squad/Tribe” structure - emphasizes “Steps”, with
a simple list of five sets of behaviors they want:

Values team success over individual success

Continuously improves themselves and team
Holds themselves and others accountable
Thinks about the business impact of their work
Demonstrates mastery of their discipline

Chuck Groom - this is unusual - personal thoughts on a Job Ladder, though

the author is a senior engineering leader at VTS. Good discussions on how
 having ladders helps, as well as descriptions of Anti-patterns. The Principal
Engineer “antipatterns” are notable:

Over-emphasis on scaling or high availability far beyond

business needs. Spends too much time chasing the newest
“shiny” technology. Doesn’t collaborate or ask questions.
Condescending. Has “pet” agenda. Pisses off senior leadership.

Khan Academy (doc)

Monzo: A clear, simple ladder
Square (spreadsheet):
More: https://www.cnblogs.com/dhcn/p/10729002.html

More ladders (non engineering) are available at Progression.fyi, which can help
give further grounding for companywide leveling. See also the Holloway guide
to Job Titles and Levels.
Chapter 27
Intro to Tech Strategy
This is a very high level overview of tech strategy. That is, the business of
software rather than the art and science of creating software itself.

It goes without saying that your coding does not have independent value. It must
be applied usefully on some economic problem to have sustainable real world
impact.

27.1 Tech Strategy and Your Career

Perhaps more pertinent to your career: your coding ability will be associated
with the success of your company. We infer better ability in someone who was
an early engineer at Uber, despite having no knowledge of their actual
contributions, compared to someone at an unknown startup who may have
accomplished far more interesting things.

Even if you don’t care about that, and never intend to be a founder, your
understanding of the business you’re in allows you to offer suggestions and
prioritize work in alignment with economic opportunity. It may not feel like
much, but as the person closest to the code, you have a tremendous amount of
autonomy to the final experience delivered:

You make delivery estimations, and give advance warning of serious

technical blockers
You make technical tradeoffs between the “quick and dirty” way and the
“right” way
You pick abstractions for scale and pluggability vs rejecting premature
abstraction
You evaluate commercial solutions compared to the cost of a custom
solution - the infamous “build vs buy” decision
 You can defensively code for every probable system failure, or understand
where failures are more acceptable than their cure
You sweat the fine details of Accessibility, UI/UX, Uptime and Response
time because it matters to users
You can find the easy-to-implement “low hanging fruit” ideas offered by
your data models and pre-existing frameworks (and plugins), and can
suggest them to your product owners.

As you advance in autonomy, you will get to pick the projects you work on, and
even pitch new initiatives that you eventually own (this is a GREAT career
move).

If you read the story of how Google Maps’ Satellite view was almost named
“Bird Mode” due to a CEO decision, but was ignored by the product team, you
will understand how your broad-ranging powers even go as far as naming
products, which is in no developer’s job description. When the chips are down,
Developers are designers and product managers of last resort.

As you increase in seniority, you will also have to grow in your business
judgment. In fact, taking a glance over any Engineering Career Ladder
(Chapter 26) will tell you how important your business impact is to your career
advancement.

Finally - the technologies that you work with are also strongly influenced by
their economic incentives. “Free and Open Source” does not mean “Free of any
commercial considerations.” Nor does it mean “Open Direction decided by
Direct Democracy.” The platforms you run on , whether it is the browsers,
public clouds, databases, payment/fulfilment platforms, or even language
distributions, all have massive investments. Well above 10 figures in some
cases!

27.2 Software is Eating the World

In 2011, Marc Andreesen wrote “Why Software is Eating the World” which set
out the foundational thesis of his venture capital firm. I am assigning this to
you as required reading. It foretold the rise of massive software businesses in
the decade since, and made the case for why every industry is now in the
business of software. Marc has since updated this with takes on healthcare,
biotech and crypto.

This is now widely understood in the software industry, and you should at least
be aware of it even if you disagree with it. (Though it does make the software
engineer the center of the new world, so you will probably like it a little bit!)

27.3 Horizontal vs Vertical

The basic split in tech strategy is Horizontal vs Vertical businesses.

If you work on infrastructure you might be familiar with “Horizontal vs Vertical

scaling”. This is different. Here we are talking with respect to your customers:

If your business is designed from the ground up to serve a single industry or

customer profile, you are a Vertical business. Vertical businesses typically
grow by offering more and more capabilities to serve the customers they
have, despite these features existing as standalone offerings elsewhere. The
goal is to be a “One Stop Shop”. User experience can be mindblowing
when it is vertically integrated - but frustrating when limitations arise.
If your business can be used by customers across any industry, you are a
Horizontal business. Horizontal businesses typically grow by reaching
more and more kinds of customers, building any integrations required or
adding knobs and configs to accommodate their use case. The goal is to
“Do One Thing Well” and be the best in the world at it. Many “API
Economy” developer tooling platforms are Horizontal: Stripe, Auth0, Okta,
Twilio.

The battle between Horizontal and Vertical is timeless in the history of

computing. Here is how Andy Grove, former CEO of Intel, described the shift
in the computing industry over his career:
New technology categories usually start vertical, because nobody else makes all
the components needed. Eventually the individual roles become well-defined
enough that horizontal specialists make sense. Clayton Christensen described
this as a movement from “interdependent architectures to modular ones”. This
usually becomes an uncoordinated mess, so then a counterbalancing movement
happens and we arrive at an uneasy equilibrium with both horizontal and vertical
players in the same industry.

There are two other analogies typically offered to describe this divide:

Apple (Vertical) vs Android (Horizontal): Apple is 100% vertically

integrated for the high end smartphone market. From Apple Pay, iMessage,
iCloud, macOS, all the way down to making its own processors. Android is
a free open source operating system and it is used by all sorts of phone,
watch, car, home, camera, TV, even refrigerator manufacturers.
Bundling (Vertical) vs Unbundling (Horizontal): a reference to this
famous Jim Barksdale/Marc Andreesen quote: “There are two ways to
make money in software - bundling and unbundling.” Depending on who
you ask, we are in the middle or tail end of a Great Unbundling in business
software - exchanging the Microsoft Office suite for Airtable, Zoom,
 Notion, and Slack - before we get tired of jumping between dozens of
subscriptions and demand an integrated experience once again.

The maturation of technology is usually rife for a “Cambrian Explosion” of

unbundling, which is exactly what happened to Craigslist, Excel, and the chip
design industry. Less mature unbundling movements that have only recently
begun are Cable TV (splitting up into individual subscriptions like Disney+ and
HBO Go), universities (splitting into online courses), radio (splitting into
podcasts) and newspapers (though newspapers have already been decimated by
social media, top journalists are now leaving and simply starting their own
newsletters). There are cases to be made for unbundling everything else from
LinkedIn to banks as well. These are all promising areas for startups.

None but the most disciplined of businesses are 100% horizontal or vertical.
There is usually a healthy debate within the company as to which direction to
pursue, as both are valid ways to grow. But pursuing both can signal a lack of
vision and inability to accept tradeoffs and will lead to problems in resourcing,
product development and sales/marketing.

You’ll also hear this idea applied to other aspects of business - Horizontal vs
Vertical Integration, Horizontal vs Vertical Acquisition, and Horizontal vs
Vertical Strategy. They are all variants of business expansion along one of these
lines.

27.4 Business Models

The next dimension you should be aware of is business models. Quite simply,
this answers the question of “who pays?”, “what directly makes revenue go
up?”, and (not often enough) “what must the company spend money on?”

The most common ones you should be aware of are Agencies, Advertising,
Subscriptions, and Marketplaces. Most other companies that employ software
engineers have aspects of these embedded within them. I cannot do justice to
them in the space I have here, but I will at least introduce them and try to give
you enough to learn more.
27.4.1 Agencies

The Agency model is the most common one for small teams. I don’t have
numbers for this, but my guess is it is responsible for most tech jobs as well.

With an agency model, you have one or more clients and you are paid for
your time.
If you are a dev team within a bigger, non-tech company, you are basically
an in-house agency with one client.
If you are a consultant or freelancer, you are a one-person agency.
There are a thousand small ways to tweak dev setups and payment terms,
but broadly, as the amount of dev-hours grows, so does the amount of
money flowing into the agency.

Ideally, you should be trying to get the most done per hour, but cynically, bad
incentive systems can lead to just booking more hours. The common thread is
that your income isn’t fully pinned to the success of your client’s business,
which is sometimes a feature and often a bug of the Principal-Agent Problem.
Despite the flaws, agencies are still so popular because of the sheer amount of
work that needs to be done, and the specialized talent needed for certain types of
high skill work.

27.4.2 Advertising

The Advertising (or Media) model is next most common. Here you make
money by increasing the traffic to your site or usage of your product and then
selling advertiser spots.

Sometimes the advertising is display ads (paying for Cost Per Milles - aka
ears and eyeballs - just to be present and build brand awareness).
But most advertisers these days prefer performance based marketing -
paying for directly measurable user actions e.g. Cost per Click.

Most social networks and news/opinion sites run this way, though there is an
absolutely massive assortment of marketing technology to help ad buyers find
the best ad inventory. Because end users pay nothing and advertisers pay for
access, the derisive view is that “Users are the Product.” However this may not
always be a negative - the Wirecutter and the Points Guy are both well-regarded
high quality content sites that make their money from affiliate marketing, which
is a variant of performance based marketing (pay-on-purchase rather than pay-
per-click).

Social Media and Digital Media differ in one important way - digital media
companies have to hire journalists and editors to create the content that draws
people, whereas social media companies get User-Generated Content for free.

Social media is a unique intersection of tech and society, where we trade our
information and attention for news and social status. On paper you might be an
ads business, but as far as humans are concerned, you offer Status as a Service.
People literally compete to give you their best content for free. This sounds
like a wildly attractive proposition, and at first it was. You can see Reid
Hoffman’s Series B pitch deck for LinkedIn to appreciate just how compelling it
is. But in recent years the hidden “cost” of running a social media company has
emerged in the need for content moderation. You might start out a technologist
and end up spending all your time debating the fine points of 47 U.S.C. § 230
and having complex debates about deplatforming and misinformation.

With digital media companies, including podcasts, the trend has been toward
realizing that ads aren’t the only way to make money - you can charge your
audience directly! That leads us to subscriptions.

Tip: The reality of most media companies today is to tend toward

some sort of hybrid Advertising (for free users) and Subscription
model (for highly engaged users), so it isn’t an either-or proposition.

27.4.3 Subscription

The next most common type of business model is Subscriptions:

If you sell usage of your software, this is known as Software as a Service

(SaaS), which is an investment category all its own. The common
 characteristic of the IaaS/PaaS/SaaS models is they transform Fixed Cost to
Variable Cost which provides immediate value for customers.
Content subscriptions are the other major category. This includes audio
(e.g. Spotify), video (e.g. Netflix), news (e.g. the New York Times),
blogging (e.g. Stratechery), data (e.g. Crunchbase) or membership to a
professional group/community. All of which require software to support
them.

Since users pay directly for the software/content/membership, and can walk
away at any time, the incentive alignment is clear - use subscription revenue to
make a better offering, which helps drive more subscriptions, which helps
finance a better offering, and so on. Since digital content can be replicated
infinitely, the gross margin and therefore cash flow of these kinds of business is
high. To grow, the business has to expand its marketing funnel, increase
conversion rates, keep a lid on cost of content (e.g. revenue sharing with content
creators), and decrease churn.

Most subscription businesses are a buffet - pay your subscription and it’s all-
you-can-eat. This has an inherent flaw - some people just eat a whole lot more
than most. This is expensive to support and the lighter users subsidize those who
“abuse” the platform (by bringing down average usage). Therefore all
subscription business eventually start charging per-seat, and then find their way
toward some form of metered billing (using some form of value metrics). Doing
this too eagerly can have the perverse effect of punishing your most engaged
users.

Fun fact: Marc Benioff is widely credited with inventing SaaS, and
ironically introduced it with the famous “No Software” campaign in
1999.

27.4.4 Marketplaces

Marketplaces are the hardest software businesses to build, and therefore there are
fewer of them than other kinds of business. However, once established, they
exhibit gobsmacking double-sided network effects, which makes them very
valuable (Bill Gurley describes marketplaces as creating “money out of
nowhere”). Developers both use and work for marketplaces every day without
realizing it - ranging from Airbnb and Uber to Cameo and Udemy (see this list
for more).

Marketplaces match buyer and seller, just like their offline counterparts. The
marketplace gives both sides an assurance of:

liquidity (buyers will be able to find what they want, sellers will be able to
sell what they have, and both can do it faster than anywhere else)
and quality (buyers are good customers whose checks don’t bounce, and
sellers must not sell fake or defective products, or they get kicked off the
platform).

In exchange, it takes a fee from either the buyer or seller or both. Because the
fee typically is a percentage of the money that changes hands, this is called a
take rate and marketplaces want to grow the Gross Merchandise Volume it is
based on. Take rates range wildly based on platform power - Gumroad charges
3.5% while Apple and Google’s app stores take 30%.

This model sounds simple, but there are a lot of ways to make additional
revenue. For example, suppliers often pay certification or listing fees, or they
could instead be paid to join. It also turns out that a marketplace’s own site is
prime ad space and that customers will pay for better service. So as your
marketplace grows up the Hierarchy of Marketplaces, you can build both an
entire advertising business AND an entire subscription business INSIDE a
marketplace business, which is what Amazon has done.

In a way, this is the business model to end all business models, because you
essentially now run your own economy.

Most platforms eventually add marketplaces, sometimes called App Stores. Fun
fact: Steve Jobs gave Marc Benioff the idea for Salesforce AppExchange, the
first “App Store” in 2005.

Two final, major advantages you need to know:

 Marketplaces don’t own inventory, since suppliers are the ones to bring
their inventory to market. This makes them asset light, which means they
can scale enormously with little investment. Airbnb offers more room
nights than any hotel chain in the world, without owning any hotels. Uber
and Lyft transport more passengers than any taxi company, without owning
a car.
Large enough marketplaces drive both seller and buyer to optimize for
each other - buyers want high ratings (especially when buying repeat
services) and sellers want great reviews. The slightest nuances of the
platform - everything from picture dimensions to product offered - will be
exploited to exactly meet the marketplace’s needs. This not only means that
buyers and sellers are optimizing for each other for free, it also makes
starting a competitor marketplace extremely difficult since investments
have been made and reputations gained. In other words, great marketplaces
have positive virtuous cycles.

These benefits aren’t free - marketplaces are hard to build for a few reasons:

Fakes and Disputes: Marketplaces offer an implicit or explicit guarantee of

quality, which means they need a way to handle what happens when things
go wrong.

If goods are sold, you must handle the issue of fakes, lemons, and
returns. This might not seem fun, but Zappos made great return policy
a competitive advantage.
If services are sold, you must handle the billion things that can go
wrong when humans work for humans, and you’re not around to verify
what actually happened. Airbnb had to roll out a Million Dollar
Liability Insurance Program to reassure hosts, whereas Uber uses its
rating system to keep drivers in line.
The art of maintaining marketplace quality is an entire discipline of its
own. Underlying the entire discussion is the fundamental problem of
how to create trust between strangers. The best place to learn more
is Lenny Rachitsky’s research.

Cutting out the Middleman: Every strong supplier eventually chafes at

paying the take rate. At stake is not only more revenue, but also a more
direct, long term relationship with the customer, free of any unfavorable
 changes the marketplace may make in future. For service marketplaces,
buyers and sellers who like each other enough can simply take their
relationship “offline”. This means that buyer and seller churn (also known
as platform leakage) is a huge problem for marketplaces, and it must
provide a compelling reason for both sides to stay on even after they have
found each other. Two natural reasons to stay are polar opposites: either
infrequent, large transactions where reputation matters (Airbnb) or frequent,
small ones where you don’t care who does it in a form of perfect
competition (Uber).
The Chicken-and-Egg Issue (alternatively, the “cold start” problem): If
there aren’t enough buyers, it is not compelling for suppliers to join the
platform. If there aren’t enough suppliers, buyers won’t even come by. A
marketplace can toggle back and forth between being demand or supply
constrained a few times in its life. As many as 40% of marketplaces remain
supply constrained throughout their entire life, which is why having an
encyclopedia of ways to grow marketplace supply is a hot topic.
Political Risk: Successful marketplaces are very disruptive to the
livelihoods of many legacy sellers because they commoditize their offering.
There is almost always political backlash because of the tremendous power
shift. If lobbying is successful, your marketplace could be destroyed by
legislative fiat.

One way to get past many of these issues is to be your own supplier - so that you
only grow the demand side of the market. This is sometimes called “single
player mode”. If your “marketplace” has value without any network effects,
then it has a reasonably good chance of attracting enough people to get network
effects (Often referred to as “come for the tool, stay for the network”). You
could view all ecommerce businesses as “one-sided marketplaces”, although the
trendy term for this is Direct to Consumer or “D2C”.

27.4.5 Gaming

In reviewing this section, Julian Garamendy pointed out one other business
model that wasn’t quite accounted for: Gaming. Given that gaming is a huge
megatrend (we discuss megatrends in more detail in Chapter 29), I feel I must
discuss this somewhat. Some games, like World of Warcraft, are subscription
businesses. Others, console and PC games like Zelda and Red Dead
Redemption, are one-off purchases, akin to D2C ecommerce with entirely virtual
goods.

But there is a massive genre of games which consist of microtransactions and

real money auction houses - games like Fortnite, Candy Crush, Star Wars
Battlefront and Diablo 3. These rely on “whales” getting hooked, and are more
akin to casinos. They may not be the most beneficial software humanity makes,
but they generate enough money that they must be acknowledged.

27.5 Platforms and Aggregators

I’ve used the word “Platform” a couple times without definition. The word is
horrendously overloaded, so that you can never be sure what is meant without
more context. When it comes to the business of software, though, you can do a
lot worse than listen to Chamath Palihapitiya quoting Bill Gates:

I was in charge of Facebook Platform. We trumpeted it out like it was

some hot shit big deal. And I remember when we raised money from
Bill Gates, 3 or 4 months after — like our funding history was $5M,
$83M, $500M, and then $15B. When that $15B happened a few
months after Facebook Platform(…) Gates said something along the
lines of, “That’s a crock of shit. This isn’t a platform. A platform is
when the economic value of everybody that uses it, exceeds the
value of the company that creates it. Then it’s a platform.

He’s right. The Bill Gates Line defines Platforms as serving an ecosystem that
exists because of them, but is also much bigger than them. And because
Platforms are such tremendous economic centers of gravity, we need to
differentiate them from your average, run-of-the-mill marketplaces (which, I
hope I have established, are powerful economic engines already).

The three most important platforms of all time are Windows, iOS and Android.
Per Ben Thompson, it’s no coincidence that all are operating systems:
 Windows was the OS for the Desktop Age: Developers made apps to run
on Windows and manufacturers made hardware to run Windows, which
made Windows more attractive for both sides. Quoting Ben:

The end result was one of the most perfect business models ever:
commoditized hardware vendors competed to make Windows
computers faster and cheaper, while software developers
simultaneously made those same Windows computers more
capable and harder to leave.

iOS and Android are the OS for the Mobile Age: Developers make apps
for iOS and Android, and users are trained to find everything via the
Google and Apple Play Stores, which makes iOS and Android more
attractive for both sides.

Note: Ben originally called Google Search a platform, but

changed his mind as he developed his theory further.

Because of its unprecedented success as the main cross-platform platform for

gaming, Epic Games’ Unreal Engine must also be considered in the same
league. As with all things Gaming-related, see Matthew Ball’s epic Epic Games
primer for more details.

Platforms exist on a higher level than business models - for Windows it was
licensing, while for Google it is ads. Yet the two-sided nature of a Platform
makes it seem like a Marketplace, and Bill Gates’ definition seems comparable
to GMV.

But Platforms don’t play the transaction volume game - their M.O. is to look at
the most critical use cases and to build them out as subsequent products.
Windows built out Office (Word, Excel, Outlook, etc), and then Windows
Server. Google built GSuite (Docs, Sheets, Gmail, etc), and acquired YouTube.
I mentioned that the usage of the term “Platform” is quite overloaded. Hugh
Durkin identifies three traits:

serving multiple different types of consumers

facilitating efficient value exchange through building and operating a
marketplace
building a shared set of common standards through standardised
internal and external facing APIs

Search around and you’ll find more definitions. Everyone tries to put their own
spin on it, which mainly serves to show that it’s an important thing to be.

Not all Platforms are economic powerhouses. If the market is not a natural
monopoly, then there may be a lot of competitors, and a race to the bottom in
terms of pricing. This happens in many industries from publishing to
semiconductors. In fact there is often a phenomenon where platforms become
the least value-adding part of the supply chain, with relative power flowing to
creators and distributors. Stan Shih, founder of Acer, famously called this the
Smiling Curve, and the concept has been extended to everything from self-
driving cars to Taylor Swift (aka the music industry).

For platforms to do well, they have to constantly add value or achieve

unbeatable network effect. Some financiers have seen great success reducing
competition by rolling up a group of platforms.

A contrasting economic model to Platforms are known as Aggregators.

27.5.1 Aggregators

Aggregators are the main characters of Aggregation Theory, defined by Ben

Thompson.

Note: If this seems strangely focused on the theories of one person, it’s
because Ben has shaped the entire zeitgeist of tech with this theory, to
the point of being quoted at Apple keynotes - so I feel compelled to
introduce it to you.

Aggregators must have three characteristics:

Direct relationship with users (payments, accounts, regular usage)

Zero Marginal Costs for serving users
Demand-driven Multi-sided Networks with Decreasing Acquisition Costs
(aka a very specific type of the two-sided network effect we have
discussed)

Aggregators take advantage of a fundamental shift in power enabled by the

Internet and the digital economy. Because the marginal cost of digital goods is
zero, the ability to generate profits has shifted from companies that control the
distribution of scarce resources (Suppliers) to those that control demand for
abundant ones (Aggregators).

If you aggregate users, you call the shots. This means great user experience is
paramount, and explains the tremendous amount of investment in web and
mobile clients over the past ten years. (One answer to why React developers are
in such demand.)

Levels of Aggregators:

1. Supply Acquisition - they have a great user relationship, but buy their
supply, e.g. Netflix and Spotify. Content cost is a concern.
2. Supply Transaction Costs - they don’t buy their supply, but pay some
marginal costs to bring suppliers onboard, e.g. Uber and Airbnb.
 3. Zero Supply Costs - they don’t buy their supply, and incur no supplier
acquisition cost, e.g. Amazon.
4. Super-Aggregators - they have at least three sides - users, suppliers,
advertisers, and have zero marginal costs on all of them. E.g. Facebook
(with Instagram), Snapchat and Google.

27.5.2 Platforms vs Aggregators

It can help to situate these two models by contrasting them. I’ll point you to
Ben’s writeup on his site:

Platforms (e.g. Windows) are critical for their suppliers (e.g. Windows apps) to
function, Aggregators (e.g. Google) aren’t critical for their suppliers (e.g.
websites) to function.

Platforms facilitate a relationship between users and 3rd-party developers, while

Aggregators intermediate the relationship between users and 3rd-party
developers.

Platforms help people do things (aka Bicycles for the mind), Aggregators do
things for people.

To find more information, you can read Ben Thompson’s body of work - be
aware, his definitions changed between 2015 to 2019. Also, the commonly
accepted usage of the word “Platforms” also encompasses Aggregators.

One final point is relevant for us - Both Platforms and Aggregators make it so
much easier for suppliers to reach customers that it enables new types of
businesses to be created atop them. Apple, Microsoft, YouTube, Amazon,
Teachable and others have all minted millionaires, and developers can make a
great living working on them or for them.

27.6 Other Strategic Perspectives

As you might see, the analysis of what drives the rise and fall of tech companies
can get very nuanced indeed. Though tech giants get all the limelight, good
ideas are fractal, and you can apply them in smaller contexts within your
professional network, language ecosystem, and internal company politics.

I haven’t any room left but want to share a few more interesting dynamics you
can investigate on your own:

The funding of Open Source is always a point of contention - Open Core

models are increasingly viable and benefit the developer ecosystem while
also being great employers. However, if your core is open, anyone can
compete with you on hosting your core, so this has caused the Great
Relicensing.
Land Grab vs Organic Growth: some business opportunities must grow
rapidly due to a Winner-Takes-Most network effect, and so should raise
VC. Others will always be one of many so profit and unit economics should
be a core focus for bootstrapped growth. Joel Spolsky has a good
introduction to this idea.
Categorical Imperatives: I have a suspicion that software has intrinsic
desires, expressed by inevitable and unimaginative customer and product
manager feature requests. If you anthropomorphize the codebase you are
working on and treat it as a living, breathing thing, you can think about
what IT “wants”. You can therefore predict what features you are going to
have to build. Examples:

Every collaboration app wants email

Every data analysis app wants the power of Excel
Every marketplace wants to be two-sided
Every social app wants chat
Every User Generated Content app wants Snapchat’s Stories format
Every B2B app wants a dashboard
Every site author eventually wants a CMS
Chapter 28
Strategic Awareness
Strategic Awareness = Focus + Technology Adoption + Value Chain +
Systems Thinking

As discussed in Intro to Strategy (Chapter 21), The basic starting block for
Strategy is having a mental model of present reality. This is not only important
for making future plans (getting from here to there), but also for sifting through
the deluge of information coming at us from every angle.

This chapter is dedicated to giving you some basic ideas for where to start.

I really, really hesitated to call this “Strategic Awareness”. The term is

associated with some rather stuffy business management education material. But
the term is right - be aware of what’s around you, focusing on things that matter
to you, for the purpose of forming some information consumption, technology
choice and career strategy for yourself.

28.1 Concern vs Influence

In Stephen Covey’s 7 Habits of Highly Effective People, he makes a distrinction
between proactive people - who focus on what they can do and influence - and
reactive people - who focus their energy on things beyond their control. He
visualizes it with two concentric circles:

A larger Circle of Concern: including everything you care about, from

personal concerns (health, relationships, etc) to global concerns (climate,
pandemic, etc).
 A smaller Circle of Influence: including the things we have the power to
affect. Some authors define a third zone of Control which separates direct
control from indirect influence.

The idea is that people are happier, and more effective, when their Circle of
Influence covers a large percentage of their Circle of Concern. The converse, a
person whose Concern far exceeds their Influence, is one who spends their time
impotently raging and fretting. With the Circle of Concern, information is
pushed to you, and you are unknowingly manipulated by news cycles and
marketing calendars. When operating in the Circle of Influence, you have the
power to pull the information you need, and you gain back personal agency.

The real trick to these Circles, of course, is that they exist entirely within your
mind. You have the power to both contract your Circle of Concern (aka Focus)
and expand your Circle of Influence (aka Competence, Power, Network). The
rest of this book deals with your Circle of Influence, so here we shall concern
ourselves with helping you focus.

Ways to shrink your Circle of Concern as a developer:

Have a primary domain that you concern yourself with - projects, news, and
discussions in this always take priority over everything else.
Don’t spend too much time on Hacker News, or on email news recap
newsletters.
Trim your unrelated follow list on Twitter (it is never personal, you can
refollow in future).
Learn Just in Time instead of Just in Case.
Prefer grooming relationships with people who know things you don’t
know, and resist the urge to learn everything yourself.
Get comfortable lampshading ignorance (Chapter 34). Having better
things to do than know everything is always a valid defense.

“Stop caring so much” is very persuasive, of course - but in tech, things move
fast, and sometimes you do have to keep tabs on things you don’t yet use. So we
need something more nuanced than a binary Concern/Ignore model.
28.2 Levels of Concern
For Enterprises, Thoughtworks has split out Circles of Concern into four levels,
called a Technology Radar:

Adopt: A strong recommendation for adoption

Trial: Try this out on projects with risk tolerance
Assess: Explore to understand how it might affect you
Hold: Don’t bother

If you are a participant in the ecosystems that Thoughtworks surveys, you’ll

understand that as an Enterprise communication tool, their radars are necessarily
behind the cutting edge. But having gradations of concerns seems right.

For example, as a frontend/serverless developer, I have strongly adopted React,

whereas Svelte is worth trialing on projects. I think Machine Learning will
change our lives, but it doesnt impact me professionally yet, so I am assessing
it. I have decided to hold off looking at everything to do with Blockchain and
Kubernetes.

Each level can warrant a different level of engagement. For Assess, it can be
sufficient to just listen to one regular “overview” podcast, like This Week in
Machine Learning. Trial technologies are worth looking through docs and
demos and trying on new projects. Adopt technologies don’t have to be things
you actively use in production, but as a professional in your field, you should be
familiar with and have opinions about (eg by going through talks, source code,
or following GitHub issues, Twitter threads, or email newsletters).

28.3 Bias to Action

Richard Feynman was fond of giving the following advice on how to

be a genius: You have to keep a dozen of your favorite problems
constantly present in your mind, although by and large they will lay
in a dormant state. Every time you hear or read a new trick or a new
 result, test it against each of your twelve problems to see whether it
helps. Every once in a while there will be a hit, and people will say:
“How did he do it? He must be a genius!” - Gian-Carlo Rota

Quantity doesn’t beat quality when it comes to Strategic Awareness. Have in

mind a small list of problems that you are particularly looking to answer.
Richard Feynman had 12, you can probably make do with that. Everything else
can be let go, or is just akin to entertainment. As Adam Robinson is fond of
noting - beyond a certain point, you don’t get smarter the more pieces of
information you have, you only feel smarter.

Richard Hamming, in his famous “You and Your Research” lecture,

put it more bluntly: “If you are not thinking about important
questions, then you are not going to do anything important. “
Keep a short list!

Know What You Want, and Know What People Want. You don’t have to be
interested in everything - knowing what you want can help you only look out for
projects that will be helpful to you, and knowing what people want can help you
pick projects that will be well received.

Your information inflow should be managed to help you create action. Not
quantity of consumption. People brag about how many books they read in a
year, or obsessively keep up with headlines (because of Fear of Missing
Information). Or you could clip and organize and summarize everything and
have gorgeous notes everyone fawns over. Great — if your goal is pretty notes.
Optimize for action, not consumption.

“Point of view” is that quintessentially human solution to information

overload, an intuitive process of reducing things to an essential
relevant and manageable minimum… In a world of hyper abundant
content, point of view will become the scarcest of resources. - Paul
Saffo
28.4 Understanding Technology
Adoption
Not everyone adopts technology at the same rate. The key to your
effectiveness comes from understanding what stage a given technology is in,
which stage you want to be at, and (optionally) how to move technologies to the
next stage.

28.4.1 The Rogers Curve

In 1957, Joe M. Bohlen, George M. Beal and Everett M. Rogers first proposed a
bell curve-like distribution of technology adoption, now known as the Rogers
curve:

This gave a simple visualization to an intuitive idea - that technology comes to

life by diffusing from an core set of Innovators, has crucial usecases proven out
by Early Adopters, then put into widespread use by the optimistic Early
Majority and conservative Late Majority, followed by reluctant Laggards.
These stages do not just reflect the personality of people adopting a static
technology - they also match with the technology itself improving and maturing
over time. For example, you might expect a technology at the Early Adopter
stage to be full of bugs, and not have a clear killer usecase yet. Whereas a Late
Majority technology not only is stable, it has great docs and a lot of already
successful case studies of others putting that tech in production.

The risk profiles of adopting a technology at earlier stages are commensurate

with career rewards. Here I’ll simply quote Charity Majors, CTO of
Honeycomb:

It’s much easier and faster to become an expert in a subject still young
and evolving, and people are actively looking for new voices to listen
to.

However, of course there’s always a fear that the technology fails, and you will
have wasted a bunch of your time tearing your hair out over tech that nobody
really cared about. This is not quite true for a few reasons:

technology rarely fails, it just… sputters out quietly

you will have gained a DEEP appreciation for the actual problem area,
which gives you a leg up for the next wave of innovation
the people you work with will also go on to do other things, and you will
have a camaraderie borne out of shared pain that nobody else can match
(e.g.: the MooTools mafia)

28.4.2 Crossing the Chasm

It turns out that not all the transitions between stages are equal. Geoffrey Moore
nailed this dynamic in his seminal book: Crossing the Chasm.

The “Chasm” thus named refers to the extraordinarily difficult jump between
Early Adopter and Early Majority. Early Adopters can be very forgiving and
imaginative, while Early Majority need a lot of the documentation and usecases
paved for them before they will jump aboard.
Marketing to and building for these two audiences are very different
propositions, hence the argument of the book is that the company or
technologist’s strategy must change drastically between every stage, especially
across the Chasm.

If you are keeping tabs on technologies, it can be very rewarding to watch for
technologies that are just teetering on the brink of Crossing the Chasm, and to
jump on just before, or help it cross.

If you are creating technology, whether at a startup or working on open source,

you probably want to pay attention to the remaining obstacles for your tech
Crossing the Chasm, and to systematically dismantle them.

28.4.3 The Gartner Hype Cycle

Of course, in tech, expectations can run ahead of or behind reality. As social

animals, we can sense heightened expectations much more intuitively than
reality. Just like financial cycles, tech expectations anticipate more future
progress the faster real progress is made, guaranteeing that hype runs ahead of
reality, which also causes subsequent disillusionment:
To defend against this:

understand sources of inflated expectations (Journalists - including citizen

journalists like newsletter editors and podcasters - who don’t work hands-
on with the tech, people whose paychecks depend on the tech’s adoption)
have a process for reality checks (befriending the people involved, testing
the tech out, understanding physical limitations and foundational first
principles)
remember that the best time to build is often in the Trough of
Disillusionment, as it is not as noisy as the Hype Peak, while
simultaneously, the Hype Peak often causes a great deal of infrastructure
investment that makes it cheaper to build during the Trough.

You can look through Gartner’s writings over time for many, many, examples of
Hype cycle applied to different industries - I will not list them here.
A technology will go through multiple hype cycles over time. By some counts
there have been at least eight AI Winters. Yet the builders keep building, and if
you zoom out, these cycles smooth out over time. And that is what we will now
do.

28.4.4 The Perez Surge Cycle

Not to get all Calculus 101 on you, but if you took an integral to the Rogers
curve, you end up with an S curve going from 0% of the population to 100% of
the population.

The history of technology is full of S-curves:

And the spread of information technology also means technology spreads faster
over time.

Carlota Perez has made a career of studying this:

You can see the imprints of Moore’s Chasm here. The Installation Age has a
slow build-up, then something happens, and a turning point is reached, and all of
a sudden the technology has crossed the chasm, and we are now in the mature
Deployment Age.

If you lived through the Coronavirus Pandemic of 2020, you saw Zoom zoom
through this turning point - a video conferencing tool mostly used by techies,
suddenly became a household name for both students and retirees, with
unsponsored shoutouts by major television shows like SNL. Accordingly, new
problems arose - Zoom-bombing, more scrutiny on security practices, and the
need to manage massive thousand person events.

The Deployment phase can look very different from the previous - you go from
building the tech, to building on and around the tech. To give you an example
closer to home, I applied this to explain the rise of React metaframeworks:
If you are looking to build tech, understand where your tech is in the adoption
cycle through these mental models, and build what is needed.

28.5 Technology Value Chain

Technologies don’t exist in a vacuum.

In order to deliver apps, you chain tech components together (in a “value chain”)
to build them. Some of these, like electricity, are commoditized - cheap, and
highly available. Others, like cloud services, are productized - cheaper than
building yourself, and not core to your value prosposition. Still others, like a
proprietary compression algorithm, is “secret sauce” and must be coded by you.

28.5.1 The Law of Complements

One of the most fundamental laws of technology microeconomics is that
increases in supply of one technology drops the unit price of that technology,
which then causes the value of related technologies to increase. That’s a lot of
words, so let me give some examples:

One of the most salient driving forces in technology has been Moore’s law -
computer chip performance (loosely defined) doubling every 18 months for
50 years. Yet the person to make the most wealth from this trend has been
Bill Gates, who wrote the software that runs on this hardware - even if it got
worse at a commensurate rate. In fact a popular variant of Wirth’s Law is
christened Gates’ law: “The speed of software halves every 18 months.”
This is akin to the legendary founding story of Levi’s Jeans - during a gold
rush, sell shovels.
In much the same way, Larry Page and Sergey Brin made the most wealth
from the world going online, not the ISPs that helped make it happen.

Joel Spolsky (and later Gwern Branwen) wrote about this strategy as
“Commoditize Your Complement”. This assumes a great deal of agency on your
part, which you may not have since you aren’t Google or IBM. But you see the
influence of this law in every huge and aspiring-to-be-huge tech platform - it
puts itself at the center of its world, and commoditizes all the adjacent
technologies that it works with (often you hear this as “framework agnostic” or
“language agnostic” or “You can use ${THING EVERYONE USES} or
${DISTANT SECOND FEW PEOPLE USE} or ${THIRD THING NOBODY
USES} with us!”). Fill in the blanks with your favorite platform - If I named
names, I’d piss someone off!

The overall lesson is this: Look out for things which are rapidly becoming
cheaper/easier because adjacent things will become a lot more valuable as a
result. As a supplier and creator of technology, you want to be next to the hype.

28.5.2 Wardley Maps

We have established that it is valuable to understand when adjacent parts of a

value chain are commoditizing. This happens to closely map to Technology
Adoption Curves - the more widely adopted something is, the more
commoditized it is.
What if we went two dimensional? What if we plotted commoditization on an X
axis, and closeness to the customer on the Y axis?

We have just invented Wardley Maps:

At first glance these can feel like mumbo jumbo, overly complex charts, but it
actually makes an intuitive model for mapping out an entire ecosystem in
context of all its moving parts. Simon Wardley reframes tech maturity into four
stages: Genesis, Custom, Productized, and Commoditized, and then vertically
arranges tech components by visibility to the end user.

I didn’t get it at first - it took watching a few talks (1, 2, 3 and more) for it to
actually sink in - but hopefully by introducing Wardley Maps in context of
Technology Adoption Curves and Commoditizing Complements, I have made
the connections for you to understand the value of mapping an ecosystem.

You can maintain a mental map or actually go through the exercise of drawing
out the ecosystem you work in - but the implications are clear - you should
want to help technology commoditize, and then you should want to work
right next to that technology.

28.6 Systems Thinking

The ultimate, abstract form of everything discussed in this chapter is known as
Systems Thinking. This is a very deep, very meta field, and staying on topic with
self proclaimed Systems Thinkers can be a challenge. But it is the über-mental
model for understanding complex systems, and so deserves a short introduction.

The field of systems thinking traces its origins to Donella Meadows, who
worked with the Club of Rome to lead the influential 1972 Limits to Growth
report, laying out scenarios for global growth for the next 100 years. The basic
understanding of systems was spelled out in a seminal essay, the Twelve
Leverage Points (subsequently a book).

Tip: See First Principles Thinking (Chapter 17) for more on Systems
Thinking.

While Technology Adoption Curves and Wardley Maps deal with fixed
paradigms and vague models, the Systems Thinking movement offers some
insight both for quantifying the “leverage points” in a system (read: bottlenecks
where you will be most effective) and for quickly traversing up paradigms to
higher perspectives, spawning more insightful questions.

Will Larson, CTO at Calm, has some good writing applying systems thinking to
engineering management, and of course as an engineer, designing and running
systems is a core architectural skill, as much as you also work within a larger
system. Teaching you to apply this is beyond the scope of this book; I just hope
to introduce it to you here and invite you to explore further.

28.7 Other Strategies for Strategic

Awareness
Congrats on reading all the way through! This was one of the most abstract,
challenging chapters in the book, and a lot of work remains for you to apply
these raw ideas to your specific situation. I did my best; but each of these things
are books unto themselves, so I merely gave you the Grand Tour.

A few final tips for keeping tabs on your ecosystem, staying focused while
keeping up to date:

Keep a reference counter for technologies: Every time you hear about a
technology and think “I should check it out!” - keep a mental or literal
tally. Only actually check it out once your counter hits five - enough that it
isn’t a flash in the pan, but also not too late that you’re ignoring something
that could be amazing.
Debounce your Information: Whenever you run into something new, ask:
Do I need to know now? Does this information have an expiry date? A
nice trick to force yourself to do this is to put everything on time delay - for
example, all new blogposts and articles must be stored in a Read Later app
like Instapaper, and new YouTube talks relegated to the Watch Later list. If,
in a week, you look at it and are no longer as interested, delete without
guilt. You have just gained back hours of your life by denying the
dopamine hit of checking out new things. (Note: Exception for this is when
you are trying to Pick Up What They Put Down.)
Understand the value of Information: As a knowledge worker, you need
to establish a very strong sense as a curator of knowledge. Here’s a
preference order to get you started: - Value private information over
publicly known things - Value timeless information over novel information
- Value subtle nuances over sensational headlines - Value digesting high
quality pieces over consuming sheer quantity
Make it easy to try things out: Having no place to try things out is a
barrier to trying things out. You need to lower activation energy for trying
things out. Fortunately most documentation comes with good demos, but
also you can build expertise with some quick-start services to trying things
out - CodePen, Glitch, CodeSandbox, Netlify, Render.com for web
developers. On my laptop, I always have a “testbeds” folder for throwaway
stuff, and I can jump to it easily with rupa/z - just knowing that everything
in the folder is disposable gives me great peace of mind. Having a
Breakable Toy also lets you swap out technologies in production, freeing
you from endless tutorial hell of trivial Hello World examples.
Pay attention to Narrative Violations. The term is somewhat debated, but
basically when smart people do something quite uncharacteristic, or trends
make a sudden reversal, it is a sign you might not understand it fully, and
there may be a deeper underlying reason to be discovered. I liken it to Neo
noticing the duplicate cat, indicating a Glitch in the Matrix. Pay. Attention.
Most people are too content to only see things that confirm their prior
worldview. Actively seek out things that don’t fit, because that is where
you have more to learn.
Keep Tabs on Megatrends: Some trends are clearly massive, slow-
moving, yet inevitable. You can position for the future by living in the
future. In fact, this is what we will discuss in the very next chapter!
Chapter 29
Megatrends
It can sometimes feel like we have reached a “steady state” in tech. This is
known as the End of History illusion: the temptation to conclude that what you
have today is the best possible outcome. This is often due to lack of imagination
and sense of place in history, but also some deserved cynicism from seeing
major failures and overhyped disappointments.

The first thing to realize is that the tech “everybody” uses isn’t that old. The first
web site was published in 1990. Git was released in 2005. Both iPhone and
Android were launched in 2007. Both the modern serverless and container
paradigms began in 2014. It is highly likely that someone is working on
something right now, that will change the world not just in your lifetime, but in
less than a decade from today.

You don’t have to be super early to benefit from Megatrends. Sometimes you
can just surf the wave of something much, much bigger than yourself. If it is just
“obvious” (perhaps a loaded term) that something is a Big Deal, but on its way
to be absolutely huge, you can gain a significant advantage by simply “living in
the future”, as Paul Graham puts it, and building what’s missing. Developers
and consumers, as a population, are much slower moving than you can be. Even
“obvious” evolutions don’t happen overnight.

Developers interact with Megatrends in two ways:

They fuel and profit from Megatrends by working on companies and

products that reach the broader non-developer market. This has primarily
financial benefits for the developer.
They are influenced by and contribute to Megatrends within the developer
ecosystem itself. This has primarily career benefits for the developer.

The trick, of course, is identifying what is or is not going to be a Megatrend.

29.1 Definitions
Blackrock defines Megatrends as “structural shifts that are longer term in nature
and have irreversible consequences for the world around us.” If you visualize
tech history as a series of S curves, as we have previously discussed, you can
easily identify these Megatrends after the fact. Our task is to identify and act
upon Megatrends while we are still in the middle of their evolution.

The first and easiest feature to notice is that Megatrends are measured on the
order of magnitude of population percentages. Smaller projects may use
absolute numbers of downloads or signups or active users, their monthly or
annual percentage growth, or some other vanity metric. Most startups’
projections of Total Addressable Market are complete pie in the sky - but it starts
being real when complete strangers also start talking about adoption in terms of
percentage TAM capture.

Momentum of population capture is important. If you see the adoption go from

1% to 3% to 5% to 7% to 8%, it isn’t the end of things, but the trend is obviously
in danger of petering out. Trends have been known to experience revival after a
momentary pause; Eugene Wei has a great essay on this, calling them Invisible
Asymptotes, but identifying and breaking Invisible Asymptotes is out of scope
of this book. For our purposes, we play in the kiddie pool of identifying
Megatrends: my advice is to look for double digit growth in population
adoption from year to year (viral megatrends), or look for trends that have gone
on for double digit years (generational shifts). Population-scale movements are
more like ocean liners than tugboats - once they commit to changing direction,
they will probably keep moving in that direction for a long while. Long enough
for you to jump on, get ahead, and invest at least part of your effort and career.

I’ve mentioned the term “vanity metric”. That’s a slightly derogatory term - all
metrics are imperfect, and the better framing is more that there is a hierarchy of
metrics that matter. It’s easier to get signups than it is to get active users, and
easier to get active users than paying users. But one thing more valuable than
money is time. If your technology measures engagement in hours per day rather
than monthly active usage (i.e. someone who uses it five minutes a month
counts), then you have established a habit that is sticking, and is therefore more
likely to be worth investing in. A popular way users self-describe this effect is
that they are “living in” the tool.

Megatrends are often tied to generational shifts. A newer generation will often
opt to choose a slightly different way of doing the same thing that has existed
before, and for some reason the later iteration will be the breakout technology
instead. This will seem very puzzling to the older generation, who gripe and
grumble that they were on to the hot new thing “before it was cool”. Newer
generations do this partially to distance themselves from the past, but often also
because platform shifts or new technologies enable things that just couldn’t be
done before. For example:

the smartphone enabled location-aware apps like Uber

the Internet enabled infinite shelf space like Amazon
virtualization enabled cloud computing like AWS and Azure
the personal computer enabled spreadsheet applications like Excel

This is why there is always oversize interest in future potential platform shifts
like cryptocurrency, virtual reality, quantum supremacy and deep learning.

The absence of any prior baggage also allows for skeuomorphisms (intentionally
crafting the new thing to look like the analog of the old thing, to help intuition
when transferring platforms) to eventually be abandoned in favor of “native”
assumptions (throwing away all semblance of the old thing and leveraging the
full capabilities of the new platform).

Megatrends don’t just spread across time, but space as well. As William Gibson
observed, “the future is here, it’s just not evenly distributed yet.” Because so
many startups start and prove themselves out in the US, and yet take many years
before going abroad, the Samwer Brothers have made a career starting clones of
successful American startups in Europe and Asia. Chinese students in America
have returned home as Hai Gui, setting up the “YouTube of China”, the “Google
of China”, the “Amazon of China”, the “Expedia of China”, the “Uber of
China”, and so on. The Indian Institutes of Technology have an even closer
bond with American institutions. The founders of two generations of
semiconductor titans, Morris Chang of TSMC and Jensen Huang of Nvidia,
graduated from MIT and Stanford, had successful careers in the US, and
returned home to Taiwan to start their empires. Even within a country there can
be an advantage in import the future - Governments, VC firms and investment
banks are known for organizing inspiration trips from Silicon Valley to New
York and back, and from every other city to tech hubs.

As far as Developer Megatrends go, one pretty reliable metric is seeing large
companies announce that they have adopted a certain technology. When you
see Airbnb announce that they have adopted TypeScript or Shopify moving to
React Native, these are the end results of months, often years, of careful
evaluation, and the investment of the equivalent of millions of dollars in
developer hours. Even the announcements have to be carefully vetted by
marketing and legal teams, considering the credibility impact of potentially
reversing a very public decision. As much as your needs may not be the same as
BigCos, endorsements from them do carry more weight as it means that the
technology has been vetted for scale, they will contribute open source support,
and the technology has formally become a job differentiator both on the
recruiting and the prospective employee sides.

29.2 Examples
An example here might help. TypeScript is an example of a very clear developer
Megatrend in the JavaScript ecosystem. You might personally dislike
TypeScript, but if you make tools for developers, this audience is increasingly
difficult to ignore. Piecing together survey results, usage of TypeScript rose
from 21% to 34% to 47% to 62% of all JavaScript developers from 2016-2019.
Want to bet if it keeps rising in 2020 and beyond?

I don’t know the developer ecosystem you work with as well as you do, so it is
hard for me to give more examples that might connect. We can draw up similar
numbers for Docker or Kubernetes or GitHub or StackOverflow.

As an investor, former product manager, and prospective entrepreneur, I keep a

list of more Megatrend examples in the consumer world, all software enabled:

Gaming is capturing a LOT more revenue and time than movies, music,
TV, and literally any other form of entertainment. The definitive essay on
this is Matthew Ball’s 7 Reasons Why Video Gaming Will Take Over - I’ll
just refer you to it rather than rehash his points.

The Creator Economy is enabling more people to make a living becoming

teachers and content creators by building the payment rails and storefronts
for all kinds of creators. It might have started with Patreon and Kickstarter,
but now dedicated platforms are rising up for everything from podcasts to
newsletters to video courses to adult content to, yes, ebooks like the one
you’re reading now :) By cutting out the gatekeepers (universities, tv
networks, book publishers, etc), a lot more diverse, niche interests can find
an audience, and consumers can directly support creators without a large
chunk of money going to middlemen just because.
The No Code/Robotic Process Automation trend is helping non-
developers create commodity software. The fact is the world’s demand for
software and automation (100% of the population) greatly exceeds the
available supply of developers (0.4% of the population), and a lot of these
needs don’t actually require custom, handcrafted code. So both No Code
players and RPA providers are finding a great deal of traction by making it a
 lot easier to bypass hiring a developer to create standard sites, apps and
workflows.
Remote Work - this was already a Megatrend before Covid-19, but of
course all software that supports Remote Work is in extreme demand. In
particular, real-time collaboration is now a table-stakes feature of most B2B
software.
Privacy is increasingly a differentiating feature all on its own. European
GDPR requirements aside, startups like Fathom, Fastmail, and Hey can
now credibly compete with the likes of Facebook and Google by simply
promising not to compromise on user privacy. Snapchat, of course, got its
initial traction thanks to ephemeral posting. DuckDuckGo is growing 50%
annually, and is at 1.5% of Google search traffic. What does a more
privacy conscious internet look like 20 years from now?

Software isn’t everything; there are a good deal more interesting “hard”
technology trends like the renewed Space Race, Quantum Computing, Carbon
Capture, and Plant Based Meat. But, as a rule, bytes are easier to manipulate
than atoms, and the majority of developers are better served staying in the
software domain, especially in their early career.

29.3 Building Your List of Megatrends

It matters more that you build the habit of looking out for Megatrends, than
agreeing on my specific list of Megatrends (here are some others, by the way -
your list needs to involve your filter on the world, or it just grows out of
control). You also don’t have to go from 0% to 100% right away - approach this
like you would a scientific hypothesis. Be on the lookout for the next big thing,
put out some feelers, and if you see some success, spend more time on it, repeat.
The beauty of Megatrends is that you do have time to test and observe, so long
as you are committed to moving fast once you’re sure.

Any time you can think of something that is possible this year and
wasn’t possible last year, you should pay attention. You may have the
seed of a great startup idea. This is especially true if next year will be
too late. When you can say “I am sure this is going to happen, I’m
 just not sure if we’ll be the ones to do it”, that’s a good sign. - Sam
Altman on Idea Generation

One final observation. Even trend watchers often underestimate the sheer scale
and magnitude of Megatrends. It is very common to feel like you already missed
the boat, because you are more attuned to developments than the general
population:

When Tim Sweeney started Epic Games in 1991, he “had a sinking feeling
it was too late” to start a game dev company. Today, Unreal Engine and
Fortnite are undisputed kings of the game dev world.
When Marc Andreesen moved to Silicon Valley in 1994, he felt like he’d
already missed the tech boom, but ended up founding Netscape.
When Kevin Systrom and Mike Krieger started out, their original app was
one of a throng of trendy social, location sensitive, mobile apps including
GoWalla, Foursquare and Groupon, with Yelp an already established player,
when they eventually landed on Instagram.
When Chad Hurley and Steve Chen made their own video sharing site, they
faced a crowd of existing media sharing apps including Dailymotion,
Vimeo, Flickr, Webshots, Ofoto, Shutterfly, Snapfish, Ebaumsworld, etc,
but of course YouTube eventually won out.

The lesson is clear: it is normal to feel “late” to a Megatrend. Just looking out
for Megatrends at all puts you ahead of the vast majority of the population who
do not reflect on their place in history. Further, while first movers have an
advantage, it is always more important to be the last mover in a MegaTrend -
those are the ones that end up counting.
Chapter 30
Part IV: Tactics
Finally, let’s discuss the common Tactical skills that will help you in your
Coding Career:

Negotiating (Chapter 31)

Learning in Private (Chapter 32)
Design for Developers in a Hurry (Chapter 33)
Lampshading (Chapter 34)
Conference CFPs (Chapter 35)
Mise en Place Writing (Chapter 36)
Side Projects (Chapter 37)
Developer’s Guide to Twitter (Chapter 38)
Marketing Yourself (Chapter 39)
Chapter 31
Negotiating
I can personally attest to the value of negotiation. I was recently able to
negotiate an additional $50k/year in cash + RSUs at a BigCo. All it took was
three phone/email conversations over two weeks. Prior to that, I got an
improvement of $10k/year in options with a single email. It has nothing to do
with code, or my ability to contribute, but negotiating is one of the highest ROI
activities I have ever done, despite objectively sucking at it!

Aside: If you’re new to this topic, it means that this is probably going
to be the highest value chapter in the book. Which is sobering to
realize as an author!

Negotiating is one of those areas that is well-covered by existing content. I am

tempted to just provide links to the definitive resources. However, I feel I can
still add value by offering a summary with my own commentary.

31.1 General Advice

But before that, some tips of my own:

Don’t accept right away! Always negotiate. Nobody is going to take

away your offer because you tried to negotiate.
Never lie. This industry leaks like a sieve. Especially among recruiters and
hiring managers. But where you aren’t ready to disclose them, strategic
omission of facts is fine.
Get a coach? You can hire coaches like Josh Doody (author of Fearless
Salary Negotiation) to help you. It makes economic sense to pay a sizable
% of your salary increase for this, because you get to keep benefiting in
perpetuity. I personally have not yet done so, as I wanted to try it myself.
Know your worth. Glassdoor and Levels.fyi are good for getting salary
data, but Team Blind is also good for advice and comp package review.
Subreddits like /r/cscareerquestions and others in your niche will also run
salary surveys. These will help you figure out what you’re worth. Also be
hyperaware of things you’ve done which make you stand out from others in
your experience band. And make sure They know it.
Transparency cuts both ways. Some companies have strict bands, and
even publish their salary calculations. Like Buffer, Krit and GitLab. You
can use these to triangulate your own market value, but if you’re
interviewing at such a company, you may have to find non-cash negotiation
points. They are likely to be inflexible due to their unusual transparency,
though everyone makes exceptions.
Don’t let short-term greed compromise your long-term career. A high-
paying job you hate isn’t better than a moderately well-paying job you
love. You can also make a judgment call on accepting less money for more
learning/professional growth in the direction you want. But don’t let them
talk you into taking less money for more responsibility.
Offers and Negotiations have a massive gender bias. Whether
consciously or unconsciously, tech companies repeatedly end up in
situations where they pay women 20% less than their male counterparts
and employ all sorts of negotiation and silencing tactics to make you accept
it. This is grossly unfair but it is real; learn to recognize the excuses
companies make and make clear that you know how this game is played too
(because you have read everything in this chapter). Remember also that
good companies and well intentioned people make these mistakes too –
work with them and help them be better if you can.
No amount of negotiation will overcome being underleveled. Every
company has salary bands, but most positions are flexible in terms of which
band they hire at. Especially for the right person, aka you! If you should be
at an L6 level but somehow fall into the L5 track in your conversation with
recruiters, find out fast and make sure that you’re being considered for the
most senior band possible. This helps way before talking specific numbers.
No amount of negotiation will overcome not having a good alternative.
This is known as a Best Alternative to a Negotiated Agreement in
negotiation lingo. Remember that simply staying at your existing job is a
 strong BATNA, as is striking out on your own as a freelancer/entrepreneur
given your existing audience or network. If the economy is good and
you’re interviewing at a BigCo with a competing offer from another BigCo,
previously stated obstacles (“That’s as high as we go for this band, I’m
sorry”) can magically disappear (“I talked to our director and we’re going
to make an exception for you”). This is worth $100k+ in some cases.
Think win-win. Negotiation is best done without a Zero-Sum mindset:
“I’m negotiating with you. I win. You lose.” Instead, try a Positive-Sum
attitude: “I want the best situation to do great work for you, but I have
options. You have room to go higher. Let’s find something that works for
both of us.”

31.2 Summaries of Experts

There are three people who dominate the discussion on Developer Salary
Negotiation right now: Patrick McKenzie, Haseeb Qureshi (especially for early
careers), and Josh Doody. Here are each of their main talking points, with
commentary from me:

31.2.1 Patrick McKenzie on Salary Negotiation

Patrick McKenzie’s thoughts on Salary Negotiation:

A five minute conversation can lead to $5-15k a year more in salary.

Taking in 401k contributions and future salary compounding, this can add
up to an extra $100k over ten years.
Negotiation is not haggling or greed. It is what rich, successful, in-demand
people do.
Your client/company/recruiter has far more information than you do, and
feels very differently about negotiation than you do. It is NOT an even
playing field.

They know what every employee makes

They know what everyone at peer companies make, especially those
they have to make counter offers for
 They know how much budget they have
They have negotiated more times than you have, by multiple orders of
magnitude
They may think less of you if you don’t negotiate

Everyone in this discussion is a businessperson. You will not be

blackballed for negotiating. Remember, it’s usually not their money. They
have a budget, and a concession from them means a lot more to you than it
does to them.
Your negotiation started before you applied. If you apply through regular
channels, you get priced as a commodity. If hiring managers seek you out
for your expertise, you have a much stronger position. Conversations like
these end with resumes as a formality, instead of beginning with them as a
way to get interest.
Only negotiate salary after you have agreement in principle from someone
with hiring authority that, if a mutually acceptable compensation can be
agreed upon, you will be hired. “Yes - If we agree on terms”, not “No - But
we might hire you if you’re cheap.” This ensures they have invested
sufficient time to hire you and increases their stakes. It also ensures that, at
worst, the offer you arrive at is the one they initially give.
Never Give a Number First. This “rule” is almost always the right move.
Many recruiters will try all sorts of tricks to get you to disclose your prior
salary (it is illegal to require this) or discuss your salary expectations. This
puts an immediate upper limit on what they will offer you. Patrick suggests
some talk scripts to help avoid giving a number, including what to say if
you have exhausted every option and they insist on wanting a number from
you. (A talk script is a pre-planned list of responses to various scenarios,
often used by salespeople to guide customers down a favorable path (see
example). This is better than improvising where you can make silly
mistakes. Professional recruiters, like these at Google and Facebook, are
using these when they talk to you. You can choose to arm yourself in
return.)
Listen To What People Tell You. Repeat It Back To Them. People are
most persuaded by their own words and behaviors. This is related to the
idea of Mirroring in negotiations. Make a note of everything that matters to
them that helps you make your case. Look for mutually beneficial
 movements - what “We” and “You” need, instead of what “I” need. Phrase
things positively rather than score debating points.
Research the Company. Speak with ex-employees, customers and current
employees. Look for what they value, what success looks like internally,
what the culture is like, what is easier for them to budge on.
New Information is Valuable - offering new information on your skill set,
life story and potential value-creation helps them justify your negotiation to
their bosses. e.g. “I increased sales by 3% at $PREVIOUS_COMPANY.
That is worth millions to you. Getting me that extra $5k would make this a
much easier decision.”
Non-Cash Dimensions - Cash is only one part of total compensation, and
total comp is only one part of the whole job. Salaries are often constrained
by salary bands and it can be easier to offer RSUs/Options. The higher up
you go in level, the more stock dominates your compensation. See The
Open Guide to Equity Compensation for more information. You can also
find more room on signing bonuses, vacations, work-from-home benefits,
travel opportunities, titles and project assignments.

31.2.2 Haseeb Qureshi on Ten Rules for Negotiating

Haseeb Qureshi negotiated a $250k offer from Airbnb coming out of his
bootcamp. Here are his Ten Rules:

1. Get everything in writing: Any information they provide you is helpful

both when negotiating and when making your final decision.
2. Always keep the door open: Never give up your negotiating power until
you’re absolutely ready to make an informed, deliberate final decision.
Protect your information!
3. Information is power: This includes telling them what you used to make,
and telling them at what point you will sign. Given an offer, don’t ask for
more money or equity or anything of the sort. Don’t comment on any
specific details of the offer except to clarify them.
4. Always be positive: Your excitement is one of your most valuable assets in
a negotiation. The most convincing way to signal this is to reiterate that
you love the mission, the team, or the problem they’re working on, and
really want to see things work out.
 5. Don’t be the decision maker: By mentioning mentors/family, you’re no
longer the only person the recruiter needs to win over. There’s no point in
them trying to bully and intimidate you; the “true decision-maker” is
beyond their reach.
6. Have alternatives: If you’re already in the pipeline with other companies
(which you should be if you’re doing it right), you should proactively reach
out and let them know that you’ve just received an offer. Demand breeds
demand. Reject exploding offers.
7. Proclaim reasons for everything: Most people recoil from negotiating,
except when they have to. Just stating a reason — any reason — makes
your request feel human and important. It’s not you being greedy, it’s you
trying to fulfill your goals. State a reason for everything, and you’ll find
recruiters more willing to become your advocate. Emphasize your unique
value alongside your ask. Good thing you wrote everything down!
8. Be motivated by more than just money: How much training you get, what
your first project will be, which team you join, or even who your mentor
will be — these are all things you can and should negotiate.
9. Understand what they value: Salary is the hardest for them to give.
Stock/Signing Bonuses/Relocation/Training expenses are much easier. But
be careful not to let fictional stock valuations sway you!
10. Be winnable: Give any company you’re talking to a clear path on how to
win you. Don’t BS them or play stupid games. Be clear and unequivocal
with your preferences and timeline.
11. Making the Final Decision: Assert your deadline, clearly and continually.
Use your final decision as your trump card, and “If you can improve the
salary by 10k a year, then I’ll be ready to sign” as the final move.

31.2.3 Josh Doody on Fearless Salary Negotiation

Josh Doody (author of Fearless Salary Negotiation):

You should negotiate your job offer even if it already seems pretty
good. The best way to begin the salary negotiation is by sending a counter
offer email. Eventually, the negotiation will move to the phone. But it’s
best to negotiate over email as long as you can because it’s easier to manage
the process and avoid mistakes.
 The first thing you should do when you get a job offer is ask for some time
to think it over.
Do not disclose your salary history or salary requirements. This can be
uncomfortable, but it’s your first opportunity to negotiate a much higher
salary.
Typically, your counter offer will be 10–20% more than their offer, and
you’ll focus on your base salary at first.
Josh provides a “detailed counter offer email template” to help!

31.3 Further Good Reads on General

Negotiation
Never Split the Difference by Chris Voss. Learn negotiation from a former
FBI hostage negotiator!
Bargaining for Advantage: Negotiation Strategies for Reasonable People by
G. Richard Shell. I had the good fortune of auditing his classes during my
time in business school. He is a sublime teacher and this is one of the
foundational texts in negotiation in American business.
Getting to Yes: Negotiating Agreement Without Giving In by Fisher, Ury
and Patton. Another business school classic on Negotiation, with a very
pragmatic followup in Getting Past No.
Chapter 32
Learning in Private
I am known for my advice on Learning in Public. You could easily assume that I
think you should do everything in public, or else you are Doing Life Wrong.

But no, of course I don’t think that everything should be public. I don’t even
think everyone should Learn In Public, as I have taken great pains to explain in
every talk and podcast I do.

The more realistic phrasing of “Learn In Public” is “Learn More In Public”, by

which I’m saying most people would benefit from going a little more public than
0%, which is the default for the vast majority of people. In practice, this only
means going from 0% to maybe 1% or 5% or 30% public. The majority of the
time, you are still learning in private.

So here are some thoughts on how to Learn In Private well.

32.1 Improving What You Consume

People over Content: Follow people over content sources. When you come
across a quality blog, podcast, or talk, notice the person behind it and follow
what else they do. A lot of how content works these days is through aggregators,
like Reddit or Hacker News, or an industry blog or podcast or conference. The
quality may vary quite a lot despite the best curation efforts. Titles and upvotes
may be gamed for SEO. But a quality person is likely to be quality for life. You
already know you are the average of the X people you spend time with - so
curate those people. RSS feeds help here.

The expanded form of this is Following the Graph - not only following people,
but following the people they follow (the best way to get in their heads). Tracing
back work histories and tracing forward new workstreams. Most things are
made by only a small set of prime movers and they are usually (by definition)
not hard to find.

Read Good Books Cover To Cover: Authors spend a lot of time nailing down
details in books because of how permanent it is. They also spend a lot of time
organizing the structure and relative weight of the content with some educational
goal in mind. If you come across a highly recommended book (or just one that
starts off well), do it the justice of going cover-to-cover. You may get bad
chapters or sections, but you won’t know til you plow through it. Particularly
pay attention to endings, since people often don’t make it to the end but many
authors put The Good Stuff at the end (ahem!). Usually this is the
“unimportant details” that they didn’t want to clutter the introduction with. This
is especially relevant if you are Intermediate at whatever you’re doing. Think
about it: Beginners need tutorials as they give the shortest path to success,
Experts just need to tinker and keep up to date, but Intermediates need context
and clear explanation of details.

Read Source Code: People often treat the open source movement as “code that I
can use for free”, forgetting the premise that it’s also “code that you can freely
fork for your needs”. But we are so spoiled that we even forget that it is “code
that you can read to learn from masters”. As Ryan Florence has noted: “I get
asked all the time ‘how do I level up?’ Read code. Read lots of code.” It’s
simple, but not easy. One of Paul Irish’s early hits was 10 Things I Learned from
the jQuery Source (followed by 11 more things) - granted, this was a public talk,
but it could easily be private learning. I curate the list of open source React
Project Ideas on /r/reactjs for this reason.

Subscribe to Repos and Issues: Just like there is a metalanguage behind the
language, behind the code, there is metacode - discussions and attempts on
Github Repos and Issues by collaborators, all in the open. If Reading Source
Code is reading code-frozen-in-time, then subscribing to repos and issues is
reading code-in-motion. Since a developer’s job is to put code-in-motion,
learning how to do this by watching others is a great idea.

32.2 Getting More Out of What You

Consume
Have a Goal: You will go further if you put more effort into learning one thing
rather than a random assortment, thus diffusing your efforts. You also gain the
superpower of having the permission to ignore things if they’re not on-goal for
now - you can always come back later if your goals change.

I do believe that Systems are more important than Goals. This whole thing
you’re reading is a proto-System. But Systems can be focused by Goals.
Sometimes you can stuff a system into a goal - Ultralearning seems to have
caught some fire recently as a form of super intense, immersive learning. Joe
Previte summarizes it as such: “Set a goal to experiment say with a new
technology for 31 days. Check it out. See what you think. Write down what you
learn.” Note that I’m not saying you have to have a goal at all times.
Sometimes undirected learning is fun and leads to serendipity.

Take Notes: A syllogism:

There’s no point learning anything if you can’t recall it - or rather, the more
you can recall, the more you actually learned.
There is a natural limit on how much you can recall at any time.
So to learn more than your brain can hold, you must take notes.

This is currently in vogue as Building a Second Brain, but it should be no

surprise that “Personal Knowledge Management” is a key life habit for
knowledge workers. It’s not a fad. It’s something professionals have always
learned in order to get good.

I have a bias toward digital notes because search is a superpower. But search is
no substitute for organization, which at its simplest is a tagging system, but at
its best is a “minimum spanning taxonomy” of the subject matter.

For the same amount of content stored, an organized mind will always
outperform a disorganized one.

Spaced Repetition: Another tactic is just trying to increase how much you can
recall. Michael Nielsen is famous for making bombastic claims about the
capacity of Long Term Memory, but the basic principle is sound: use spaced
repetition learning. Anki is the leader here. I’ll be honest, I don’t do this much.
In a way, having a daily habit of pursuing the same topic, and making sure to
take searchable notes leads you toward spaced repetition anyway. But of course,
I could always do a better job of this because I often have to recall things on the
spot in interviews and workshops.

Deliberate Practice: A lot has been made of Gladwell’s popularization of the

10,000 hour rule, but it is undisputed that you grow the most when you practice
at the edge of your abilities. Don’t be surprised if you spend 10,000 hours
staying within your comfort zone and don’t get any better. You have to
deliberately push your limits when you practice, or your limits will never move.
Enough said? Enough said. But I do want to highlight two ways to home in on
the exact limits of your ability:

Pick Up What They Put Down: I have called this “the Ultimate Hack for
Learning in Public” (Chapter 19), but of course you can also do it in
private. Follow up on anything and everything your unknowing mentor
says is good, or is yet to be done, or straight up just replicate their work.
Which leads to…
The Ben Franklin Method: I’ve read this before, but was recently
reminded by Mike White. The “Ben Franklin” method is shorthand for a
Dissect and Reconstruct process for training yourself to notice differences
in quality between your output and your input. This is why you think your
work sucks - your tastes have zoomed far ahead of your abilities. Ira Glass
calls this The Gap. The Ben Franklin method is a feedback loop for closing
The Gap.

The Feynman technique is a similar framing of this, which is more

self oriented rather than focused on replicating techniques of others.

32.3 Go Meta
Active over Reactive: Active Learning is Pull-based - You try to do something,
find gaps, and then go seek out what you need to get it done. Most learning
starts out Reactive - you see something new, you learn it. Push-based. The
problem is that the content industry has swung waaaay too far towards drowning
you under a deluge of content. Additionally, Reactive Learning doesn’t serve
your goals - it serves someone else’s. Part of learning is learning what to learn,
and Serendipity is a wonderful thing, but Just-In-Case learning is not
productive long-term. The right mix of learning will include more Just-in-Time
Active Learning than is natural or feels comfortable.

I confess I don’t do this well at all and would welcome ideas for how to make
Active Learning more of a habit.

Compare and Contrast Multiple Perspectives: I find a shocking number of

devs cannot objectively hold competing ideas in their head at the same time.
They just state their point of view over and over and over again and attack the
weakest argument of their opponents. This is unacceptable to me. The Fifth of
the Seven Habits is Seek First to Understand, then To Be Understood. You are
more effective if you can summarize the best arguments of all major parties in a
way that THEY agree with. This is a non judgmental “schools of thought” mode
of learning that I wish more people adopted.

As a bonus, once you can do this well, you also become more persuasive to
people who disagree with you. Because you took the time to understand them.
This is sometimes called Steel-manning (more from Andrew Chen), as opposed
to Straw-man arguments.

Distinguish Game vs Metagame: Much of learning is focused on how to do

better at the Game you’re playing, whatever the game is. But the best players
recognize that the rules of the game are changing even while it is being played.
If they are smart, or passionate, they are also actively involved in changing the
rules of the game while they are playing it. If you don’t want to keep “fighting
the last war,” and arriving at the top of your game only to have the game change
on you, you must also pay attention to how the game is changing. Often, this
takes the form of realizing that there’s a bigger game out there than the one you
once thought was your whole world.

See Also: Big L Notation (expanding on why “Learn In Public” is the

fastest way to learn)
32.4 Further References
Sarah Drasner: Learning to Learn
The Ladybug Podcast: Learning to Learn
Cory House: Programming Your Brain: The Art of Learning in Three Steps
Chapter 33
Design for Developers in a Hurry
You don’t need to have a designer to spark joy in your work. But it is important
- rationally or not, people simply pay more attention to demos with nicer designs
than demos that don’t. That’s the idea of Sparking Joy - adding lightweight
touches to delight users!

“I don’t consider myself a designer. I consider myself a developer

who can design… I create designs so that people are interested in
my code.” - Sarah Drasner

This may just be a nice-to-have for a backend developer, but if you do any
frontend work at all, it is surely an advantage to show that you can add some
design flair, without direction from a card-carrying Designer.

33.1 Spark Joy Repo

You can find a full, maintained, curated directory of everything below at its
dedicated repo: https://github.com/sw-yx/spark-joy. The intent of this section is
primarily to give you a high level overview of elements you can rather than
comprehensively listing every resource. If you find something not mentioned,
swing by to contribute!

33.2 Frameworks
The easiest way to get an instant design lift is to use a premade design
framework. There are a lot of these, so you should curate a short list of
frameworks you like - your “toolkit” of sparking joy.

You should use different frameworks based on your usecase. I split them into
“heavy”, “drop-in”, and CSS resets. Here are a short list of them for you to
check out:

Heavy (offering a lot of components, requiring a steeper learning curve):

Bootstrap (popular but overused), Foundation, Blaze UI, PatternFly, UIKit,
Weightless. These often have framework-specific ports, including
ReactStrap and Material-UI
Drop-in CSS (CSS only, “light” and often “fun” frameworks).

Serious: Spectre.css, PureCSS, LitCSS, ScreenCSS, MVPCSS, and a

lot more in the Drop-in Minimal CSS repo
Fun: PaperCSS (handwriting-like css), TerminalCSS, NES.css, 98.css

Resets (the lightest of all, just resetting default user agent styles to
something just not-ugly): Nanoreset, Destyle, Andy Bell, Normalize.css

If you’re doing a Demo, the Fun frameworks can be really easy wins. The
popularity of handwriting styles have led to XKCD-inspired charting and
Graphics. Who doesn’t smile when looking at a demo like this!
Many vendors like Creative Tim and Tailwind UI offer free and premium custom
styled components that you can explore as well.

33.3 Layout
If you need more control than the frameworks give you, you will need to learn
some basics of design.

The most immediate impact you can have here is to add more spacing -
developers as a rule tend to like information crammed together, so we need to
space things out a little more than we are comfortable for general audience
reading. Also consider standardizing the vertical “rhythm” in your site. For
example, you can restrict yourself to a small set of css variables that are 0.5x,
0.75x, 1x, 2x, and 3x a given base size (say 1em or 16px). Because margin
collapsing can be hard to manage, use single-direction margin declarations to
simplify your rulesets.

Next, you should be familiar with the simple CSS incantations that make
common layout paradigms - CSSLayout and Every Layout are the definitive
resources you can use. In particular, the Holy Grail layout is so named because
it is so common for apps and sites.

When you have laid out all your images and elements, consider the number of
“lines” that are created in your design. You should try to make elements across
your page line up as much as possible. This is a lot easier to do if you set box-
sizing: border-box to make your layout include padding and border.

For a deeper discussion of alignment, symmetry, anchoring, and other great

layout techniques to draw the eye, check Sarah Drasner’s Design for Developers
workshop.

33.4 Typography
The standard advice is to use either the System Font Stack - built-in device fonts
that are faster because no download is needed - or a maximum of two custom
fonts - one for headers and one for body text. Canva’s Font Combinations app
and Google Fonts can suggest pairings for you.

Font selection is a rabbit hole and a discipline unto itself - just remember that the
high level goal is to pick based on the personality you are trying to convey:
 Elegant/Classic: serif like Freight Text
Playful: rounded sans serif like Proxima Soft or a Handwritten font
Plain/Safe: neutral sans serif like Freight Sans

Don’t forget that you can also make your fonts responsive, using the font-
size: calc(1rem + 2px + ((100vw - 550px) / 250)) trick.

33.5 Color Palette

Having a constrained color palette can help you keep a consistent brand identity
and instil personality too.

Pick a primary “accent” or “highlight” color to match your personality:

Blue: safe, familiar

Gold: expensive, sophisticated
Pink: fun, not so serious

You can blend that color with a grey for secondary content, and lighter grey for
tertiary content.

Don’t use system defaults for colors, they tend to be too harsh. An example Blue
palette:

Black: #1d1d1d
Purple: #b066ff
Blue: #203447
Light Blue: #1f4662
Blue2: #1C2F40
Yellow: #ffc600
Pink: #EB4471
White: #d7d7d7

There are dozens of free color picking tools like Adobe Color, Coolors and
FlatUI that you can use to settle on yours.
Two special notes for Sparking Joy with colors:

Take care to ensure that your color contrasts meet accessibility guidelines -
as a rule, dark text on light background passes more easily than vice versa
Using CSS Variables for every color helps you implement Dark Mode
easily, which many users enjoy. Plan ahead - instead of using variables like
–black or –blue in your code, you should use something “semantic”
like –text-color or –link-color so that it makes more sense
swapping out colors for Dark mode.

33.6 Backgrounds
Interesting backgrounds can give a lot of texture and inspirational feel to your
work. Use them judiciously - it doesn’t help to have a distracting background
when the user should be looking in the foreground!

Gradients only require a few lines of CSS, so have great performance. You can
generate good background gradients with free tools like WebGradients, UI
Gradients, and Gradient Animator.

If you want to get a little more interesting, you can use more CSS, tesselating
icons or subtle textures.

Marketing pages should grab attention. You can use something like Bootstrap’s
Jumbotron or a Hero Generator, together with free stock photos from Unsplash
or Pexels to add instant visual interest.

33.7 Icons and Illustrations

On the smaller end of the scale, having a consistent icon set that you are
comfortable with can help you use iconography to convey intent rather than
using text. FontAwesome is best known, but both paid options like Shape.so and
Streamline Icons, as well as great free alternatives, like The Noun Project and
CSS.GG, will be helpful in various scenarios.
On the larger end of the scale, you can draw on free illustration resources for
your marketing pages and empty states. Undraw, Humaaans and Ouch! are just
a few examples of all the amazing free illustrations out there for your demos.
LottieFiles offer animated illustrations.

For doing your own graphics, Canva and Snappa are the market leading free
tools for non-designers to do basic graphic design.

33.8 Animations and Video

Animations can be very involved if you want to do them well - dedicated tools
like Svgator and Greensock need dedicated study to create custom animations.

If you don’t have the time, you can grab animations off the shelf for everything
from loading spinners (CSSFX and SpinKit) to buttons (Animista and
Animate.css). In general, you want to animate state changes, so that you guide
your user’s eyes smoothly to the next state.

If you need more firepower in video form, video makers like Animoto, Biteable
and Powtoon are there to help.

33.9 Easter Eggs

You can add even more delight by rewarding users in surprising ways:

Josh W. Comeau’s useSound helps you makes apps you can hear
React-Rewards help you add microinteractions that reward success
Canvas based interactive visualization in 2D with Processing or D3, or in
3D with Three.js (with great React demos in react-three-fiber)
Konami Codes are popular easter eggs - GenieJS is a more general
keybinding library
Clippy.js to add a little virtual assistant for your site
The Nostalgia category in general is a very ripe field for sparking joy. Clones of
old Windows and iPods regularly rank well on Reddit.

33.10 Learning Design

Having put off actually learning design as much as possible, you can finally dive
into the many great “Design for Developers” resources out there. Here are the
canonical, extremely well known resources you should check out:

7 Practical Tips for Cheating at Design by Adam Wathan & Steve Schoger
(who also wrote Refactoring UI in book form)
7 Rules for Creating Gorgeous UI by Erik Kennedy (who also teaches
Learn UI Design)
Design for Developers Frontend Masters Workshop by Sarah Drasner (with
repo here)
Degreeless Design by Tregg Frank

Nothing will beat practice by following the popular design inspiration sites like
Dribbble, CollectUI and Codrops to hone your skill.

Good luck, and don’t forget to check out the spark-joy repo for even more
resources!
Chapter 34
Lampshading
“The person who asks is a fool for five minutes, but the person who
does not ask remains a fool forever.” - Unknown

We are often told that Knowledge is Power. This is mostly true - except for at
least two points in your career.

Have you thought about how Ignorance can be Power too? I can think of at
least two stages in a career when you can wield lack of knowledge as a form of
power (in the neutral, ability to influence others to do what you need sense, not
in the petty dominating over others sense).

And we’ll talk about how you can wield ignorance throughout the rest of your
career too - with Lampshading!

34.1 When you’re very senior

First, when you’re in senior management, typically at least a couple layers
removed from individual contributors. Beyond a certain level you are not being
paid to have the right answers - that’s what your reports are for. It’s your job to
ask the right questions, and to enable your team to figure out how to get the
answers.

In my career so far I’ve often noticed that it is senior management, not middle or
junior people, that are most likely to say “Whoa, whoa, whoa. I don’t
understand what’s going on here. Can you explain like I’m five?” Done right, it
can expose weak reasoning and bust bullshit, particularly when framed with the
(mostly correct) belief that “If you can’t explain it simply, you don’t understand
it well enough.”.

Note I’m not absolving incompetent management of the need to know domain
knowledge necessary to be an effective leader. I’m simply observing that at
senior levels you are not expected to know everything, and that’s an interesting
violation of “Knowledge is Power” you have probably experienced.

34.2 When you’re new

Second, when you’re new, typically entry level in a career or a new joiner to a
community or company. At this level, again, nobody expects you to know
anything. Sure, you needed to know enough to fool someone into hiring you.
But so long as you never lied or lied-by-omission, nobody is going to turn
around and fire you for having holes in your knowledge.

Of course, there are cases where this doesn’t apply. Junior talent are the most
expendable, and some companies don’t have a healthy attitude to mentorship and
hiring. But in general, I find the tech industry a lot better for mentoring than,
say, finance. Tech companies generally place explicit responsibility on
seniors/team leads to mentor juniors, especially as part of their career
progression goals.

You might imagine, having restarted my career 2-4 times depending how you
count it, that I have a good deal of personal experience with being a total
newbie.

34.3 Storytime!
Here I can tell you about my first day on my new dev job, fresh out of bootcamp.

My team all joined on the same day - three new hires (me and two more
experienced devs). My new boss, a confident senior dev who had had a long
tenure with the firm, was walking us through our tech stack. All of a sudden he
paused, and said, “oh by the way, we’re going to use TypeScript. You all know
TypeScript, right?”. Coworker 1 nodded, Coworker 2 nodded. There was that
unspoken sense of duh, we’re all professionals here, of course we use
TypeScript.

And then all eyes were on me.

I don’t do well with peer pressure. In Gretchen Rubin’s Four Tendencies model,
I’m an Obliger - I like to please people and put my own concerns aside. Of
course my bootcamp hadn’t taught TypeScript, we’d only had three months to
learn fullstack JS! And of course I wanted to say yes!

I had a probably visible moment of panic, before going with “no I don’t know
TypeScript.” My boss simply nodded, saying, “you can learn on the job”, and
moved on.

I think in my first few months I probably had a dozen little tests like that. Did I
know how to do professional code reviews? (No) Did I know how to do BEM
naming? (No, and I proudly still don’t) Did I know what Clean Code was? (eh..
nope).

Every time I confessed ignorance, they gave me what I needed to learn, and I
caught up. If I made a mistake, they taught me what I did wrong. What were
they gonna do, fire me? They knew what they were doing when they hired me
out of bootcamp.

34.4 Lampshading
So we see that confessing ignorance works at both the senior and junior stages of
careers. But it also works in isolated situations as well, for example when you
caveat what you don’t know while learning in public.

Given my casual interest in creative writing, I often compare this technique with
Lampshading. To quote from TV Tropes:
 Lampshade Hanging (or, more informally, Lampshading) is the
writers’ trick of dealing with any element of the story that threatens
the audience’s Willing Suspension of Disbelief, whether a very
implausible plot development, or a particularly blatant use of a trope,
by calling attention to it and simply moving on.

Applied to real life: You call out your own weakness, so that others can’t.

In fact, by most functional team dynamics, others are then obliged to help you
fix your weakness. This is soft power.

Many Americans (of a certain age) immediately sympathize with this by linking
it to the final battle in 8 Mile. In it, Eminem kicks off by naming every single
weakness of his that his opponent Papa Doc was going to, literally stealing all
the words from Papa Doc’s mouth and turning himself into a sympathetic
character. Weakness is strength here purely because of lampshading.

34.5 The Stupid Question Safe Harbor

In real life, I often lampshade by invoking the “Stupid Question Safe Harbor”
(SQSH).

A “Safe Harbor” is a legal idea that explicitly okays some behavior that may be
in a grey zone due to unclear rules. So I use it as an analogy for how we act
when someone says “I have a Stupid Question”.

When we invoke the “Stupid Question Safe Harbor”, we are acknowledging the
question is potentially stupid, AND that we all know that there’s not really such
a thing as a stupid question, but we’ll just get it out of the way to ask something
really basic - because getting mutual understanding is more important than
saving face.

The trick here is you actually are saving face - now you’ve invoked the SQSH,
people understand you’re roleplaying, you’re explicitly invoking a well
understood mode of conversation, and you’re not ACTUALLY that stupid.
Right? Right?? nervous laughter

When you are in a group scenario, the SQSH has positive externalities. There
may be multiple people wondering the same thing, but only one person has to
“take the hit” of asking the “stupid question”, and yet all benefit. I like
performing this role of Stupid Questions as a Service.

34.6 Advanced Lampshading

Once you learn to look out for Lampshading, you may see powerful users of it
out there in the wild who use it to Learn in Public:

Kyle Simpson famously was told “You Don’t Know JS” in an interview,
and turned that into his primary claim to fame, controversial title and all.
I eventually took my own TypeScript learnings, explicitly lampshaded that I
was learning, and put them online and that became the React TypeScript
Cheatsheets
I frequently lampshade my mistakes during my talks. Clicker not working?
Call attention to it. Joke didn’t land? Call myself out. Self aware, self
deprecating humor is always appreciated by the audience, and fills dead air.
But you can also use it to set up a Pledge, in advance of a Turn and the final
Prestige, which is exactly how I set up my own livecoding talks.
This woman lampshading masterfully to ward off all trolls on Twitter
Who else lampshades very well? Let me know.
Chapter 35
Conference CFPs
When conferences want speakers, they have two options: invite well known
speakers or open up a selection process for all other speakers. If you’re a new
speaker, you’ll mostly get your speaking opportunities through the latter process,
which is called a Call for Papers (CFP).

Don’t let the name fool you – you don’t have to write a paper to get accepted!
The term is a holdover from academic conferences where you would submit
papers you’d worked on. But there are other commonalities – you send in one or
more proposed talks, with a title and abstract, and a review committee looks
through all the submissions to curate the lineup. This is usually done 3-6 months
in advance, so you have time to work on your talk if and when it is accepted.

Speaking can open many doors for you. From building your professional
network, to getting in front of employers, to promoting a great idea or library
that you want everyone to know. Everyone should try speaking - to teach what
they learn and improve their communication skills.

“The biggest boost for my career the past five years wasn’t working at
Facebook or being a manager, it was developing public speaking
skills.” - Charity Majors

However, the difficulty of getting a speaking opportunity ramps up dramatically

when you graduate from meetups and workplace lunch-and-learns to a full-
fledged developer conference. This chapter is dedicated to helping you come up
with great CFPs to help you start. We can discuss actual speaking advice in a
future chapter.
35.1 Who Am I to Advise You?
I’m not a veteran, world-class speaker. I don’t maintain any widely used library
or framework. I started my first dev job in January 2018. My first meetup talk
was in Dec 2017. My first conference talk was in Aug 2018. In the year-and-a-
half since then I have spoken at 20+ events from 250 person local community
conferences to 4k person bigger ones, internationally from the UK to Sweden
to India and two JSConfs in Singapore and Hawaii.

I don’t say this to flex, merely to establish what I’ve done and also what I’ve not
yet done (e.g. been an emcee or been invited to more “prestigious”
conferences). I know I’m solidly on the B or C list. I’m get a few conference
invites, which give me more freedom from the CFP process, but most of the time
I still have to go through it. If you’re a beginner, I hope that makes my advice
more relatable to you.

35.2 Watch a lot of talks

Speaking and CFPs and the world of conferences have their own special
language. And like any language, you learn best by immersion.

My YouTube Watch List is 400+ videos long. When I have lunch or am bored, I
pull up a video and watch a talk. Most conferences directly copy and paste titles
and talk abstracts into the videos. Start paying attention to those, since you’re
about to start writing them. Watching talks also trains the YouTube algorithm to
start recommending them rather than entertainment, which is a nice nudge when
I procrastinate.

You can find lists of more great talks on Hacker News.

35.3 Speak at a Meetup

If you haven’t spoken at a meetup yet, I strongly recommend you do so a couple
times before you speak at a conference. This is the best chance to get your
speaking nerves out of the way, iron out the presentation technologies you want
to use and trial your content on people who aren’t your dog. On the flip side,
meetup organizers are always looking for speakers, so you will be doing them a
favor. Some meetup organizers like GitNation actively use meetups to seed
future conference speakers, so you may even get noticed for a conference based
on a meetup talk you give.

35.4 Pick a Conference

Once you know the conference, you roughly know the audience. First time
speakers often have a goal to speak, but they forget that speakers are there to
serve the audience and the goals of the conference organizers. So the better you
understand the conference and the audience, the higher your odds of being
accepted.

You can find conferences via community listings:

https://reactjs.org/community/conferences.html
https://events.vuejs.org/conferences/
https://jsconf.com/
https://conferences.css-tricks.com/
https://twitter.com/moztechcfps
https://twitter.com/cfp_land
https://twitter.com/callingallpaper
https://confs.tech/

If you’re new to conferences, “the game” can be rather opaque, so here are some
basic, general facts (each conf will have exceptions!):

Conference organizers want to sell tickets, have a great content mix,

and sell next year’s tickets, in roughly that order. Speaker selection is a
major part of how these goals are achieved.
Fortunately, you don’t have to put butts in seats. Organizers will invite
more famous speakers to do that. This is important: don’t do what they
do. Not yet. They’re playing a different game, and the exact specifics of
the talk/abstract matters less. You haven’t earned that yet.
Your job is therefore to be a part of their content selection. This selection
will be determined by the target audience of the conference. The more
established the conference is, the more that “good selection” is a priority
since ticket sales are assured.
Community conferences are often framework or language focused. For
example, JSConf takes a VERY wide variety of topics - you don’t even
have to use JS or program for the web. It will always have room for the
embedded JS talk or the creative coding talk or the other creative coding
talk or the other other creative coding talk.
Company-sponsored conferences are often around a certain idea or
movement, even if you don’t use the particular company. For example,
Netlify sponsors JAMstackConf and yet invites speakers who don’t
necessarily use or talk about Netlify at all. Scope is a little narrower and
more “vertical” than “horizontal” if that makes sense to you.
A conference’s speaker slots are limited. A rule of thumb is 8-12 speakers
per day, per track (you can get more lightning talk speakers at the cost of
some full talk speakers). So a three day single track conference has a max
of 36 talks. The applicant pool for a conference ranges from an average
200 to something like 800-1200 for a JSConf. (Some conferences are
invite-only). Your odds go down or up depending on these variables. A
rejection doesn’t sting as much once you see how incredibly selective it is.
It’s basically as non deterministic as applying for colleges.
However since we already established the importance of mix, there are
subgames to be played here. Even if 70% of CFP applicants use React,
JSConf doesn’t want to suddenly have 70% of talks be about React. So
CFPs get put in buckets, whether explicitly or subconsciously. React CFPs
will be compared on their merits with other React CFPs. And there will be
some less competitive categories. Again, this may not be an explicit policy,
but it happens regardless. Because “good mix” - in the subjective view of
reviewers - is so important.
Most conferences (again, with clear exceptions) will take big names over
unknowns per domain. For example, if both Sarah Drasner and I were to
submit a CFP on Vue or Design or SVG animations, they would be silly not
to take her over me. However if this happened in every single talk, there
would never be any new faces on stage, and no pipeline for the next
 generation of speakers. Given equal levels of unknown, employers also get
taken into account. This is why “blind” CFP review is important for some
level of equity, serendipity, and renewal. In my experience, most CFPs are
NOT blind. Mainly because putting butts in seats is more important for
most conferences.

To sum up everything we just covered: As a first time speaker, your best

opportunities are to apply to multi-track, multi-day conferences that have
committed to a “blind” CFP review process, around a framework or language or
architecture you know well. You may have a better shot speaking about a less
competitive topic, if that option is available to you.

You should especially seek out conferences that put out high quality videos of
every talk. This has two purposes. Part of your first talk’s job is to be a calling
card for your next talk. One great talk can kickstart a great speaking career all
on its own. Secondly, you can tell the exact nature and tone of previous talks
that have been accepted for that specific conference, and therefore it is much
easier to do research when pitching your own talk, and then preparing to speak
for it.

35.5 Pick a Topic

Given you now know your target audience, there are two things to sort out
before you even start writing your title or abstract.

First, you have to find a topic. This is, at its simplest, finding the intersection
between the things you’re very interested in and the things that everyone else is
interested in. The simple reason for this disparity in interest is that you’re gonna
be spending a bunch more time on this topic than the audience is, but you still
need an audience to show up (and, more to the point, for CFP reviewers to rate
you highly).

This intersection might either seem daunting or too broad to be useful.

If you find it daunting: you don’t need to have a ton of production

experience in the topic to give a talk on it. You don’t need to be the creator
 of the framework or library. You don’t need to understand its internals. As
long as you’ve probably spent more time on your particular topic than your
audience, they’ll have something to learn from you. To some extent, you
can even “mortgage your future” a bit - propose a talk on something you
want to learn, before you’ve learned it, and use the talk acceptance as an
artificial deadline. I don’t recommend always doing this, but I’ve seen it
work well.
If you find it too broad to be useful: understand that in aggregate, the
interests of large groups of people are predictable. They always want to
know what the future holds. They always want a comprehensive
introduction to something popular. They always want real life “war stories”
of things they’ll probably have to do in future, from people who’ve
successfully been through it. Developers always want easy ways to add
design touches without being a designer. And vice versa designers. If you
need ideas, think about which of your experiences overlap with hot topics.
Accessibility, Automation, AI, Design Systems, No Code, GraphQL,
Serverless, Service Discovery, Infrastructure as Code. Everyone has the
same insecurities and in a way you are there to satisfy their insecurities.
Conference organizers look to other conferences for inspiration, and so
should you.

To be EXTRA CLEAR here: use this tactic only if you need it - it is

perfectly fine to do a talk about non hyped technologies too. But
people do respond to buzzwords!

A reliable way of gauging the interest of others is to look at community watering

holes. What topics keep coming up on Hacker News, Twitter, or Reddit? You
can niche down from megacommunities to industry ones - for web development
this would be sites like Dev.to, CSS Tricks, and Smashing Magazine. What are
the most active github repos? What are megatrends on package downloads?
What are framework and library core team members putting out? What are
company leaders (whether ones you work at or just notable ones in the news)
doing that is interesting? But be aware that sometimes people don’t know what
they want until they see it.
You can also gauge relative interest and your own interest by creating more.
Blog more and see which blog posts get abnormal traction. Twitter, HN and
Reddit are wonderful feedback mechanisms to gauge interest. The MVP of a
talk is a blogpost.

If you aren’t a great writer, that’s fine, you can also create demos. Diana Smith
has made a career of CSS art and I’ve never read a blog post of hers. You can
bet she’ll be accepted to speak anywhere (I’m pretty sure she has spoken, I just
can’t find it right now). Your YouTube watch history and GitHub timeline are
also great indicators of your revealed interests.

A special note on nontechnical talks: I love them. Conference organizers don’t.

Advice on Career Management, Impostor Syndrome, Salary Negotiation,
Working Remote, Learning in Public (Chapter 9)? They are great, and last
longer than any technology you choose. Conferences should have more of
them. They don’t.

The reality is that the ultimate customers of conferences are the bosses of the
people attending conferences. They want to see some “I can use this at work”
return on investment on sending their employees. Most bosses find sending
people to technically-heavy conferences easier to justify, hence there is more
demand for technical talks. Less cynically, the timeframes for measuring and
getting return on investment (2-3yrs, the stereotypical tenure of an in-demand
tech worker) dictate what you invest in.

If you work at a mission-driven company, for example a non profit or a

government entity or school system or museum, definitely see how you can
incorporate your social impact into your talk. Developers are always looking
for more inspiration on how their tech reaches out to the “real world”, because
most of us spend all day working on SaaS apps and marketing pages.

35.6 Pick a Genre

Once you know your topic, there are several different genres of talk that will
dictate your CFP title and abstract. Of course, you can choose not to stick to a
genre, or to subvert a well known genre, but within the confines of a CFP it is
often easier to just stay inside a genre. I haven’t collected a full list of genres,
but here is a non exhaustive list:

The War Story: This is a great first talk genre for someone with some
work experience. You simply tell a story of something you went through at
work, including setbacks, lessons learned, and ESPECIALLY any
quantitative benefits gained. You don’t have to be the world expert in
anything except your specific situation. It usually helps if you work
somewhere notable like AirBnb but a lesser known name is fine if you
advertise the interesting elements of the story like Millie Macdonald did.
Library/Framework/Product Launch: Conference organizers like to be at
the start of something big. To do this genre of talk well, you have to tackle
an important problem, and sell the idea that you have developed a good
solution for it. You don’t have to have made it yet, but of course it helps.
Examples: Dan Abramov, Ryan Dahl
How to X: How to do Error Handling in GraphQL. How to do Input
Masking in Vue. How to make Static Sites Dynamic. How to Be a Web
A/V Artist. 14 Ways to Bounce a Ball. You get the gist!
Introduction to X: This is easy Meetup fodder, but is more difficult to get
traction at conferences, usually because conference organizers don’t want to
be perceived as having talks which could just as easily have been on the
docs or README instead. So a good Introduction to X talk will also have
to be creatively framed and titled. One of these I’ve seen recently is Louisa
Barret’s Intro to Color Theory, except it wasn’t named that. It was titled
The Teenage Mutant Ninja Turtle Guide to Color Theory. You can even
add a single word like A Whirlwind Introduction To TypeScript. See how
this works?
What’s New in X: Straight survey of what’s new. This is also often framed
as “State of X”. You often have to be rather established to do this kind of
talk, like Mark Erikson or Ben Ilegbodu, or Sarah Drasner or Evan You.
But even if you’re not super established, you can also bring data like Sacha
Greif or just straight up explain things entertainingly like Tara Manicsic.
Fundamentals: This is a GREAT genre for beginners (not that it is
exclusive to beginners). CS Fundamentals like Algorithms, Data
Structures, State Machines, and Coroutines are always loved because they
reinterpret boring things that everyone “should” know, in a more familiar
and up-to-date context. But I name this genre more broadly because you
 can also think of other fundamentals to teach, like the JS Event Loop,
Visual Design or Game Programming Techniques.
Live Coding: This is an intimidating genre to many, because a mistake can
derail a talk without a satisfying conclusion. However, the “live wire act”
fascinates audiences, for the same reason we enjoy watching acrobats do
death-defying stunts. We know they are well-rehearsed but there is still a
risk of catastrophe. Being able to watch working code form over time gives
extreme confidence in the tool or concept being demonstrated. Two less
appreciated benefits are the familiarity of IDE as presentation tool and the
natural guard against rushing (first time speakers, like me, make the
mistake of talking too fast to hide nervousness and risk losing audiences).
My best talk is a livecode talk and I think interest in this genre is on the
rise. SmashingConf is now organizing 100% livecode conferences, and
React Live is also 100% live code.
Heresy Talks: Definitely not for the faint of heart. To do a Heresy talk, you
have to go to a conference where >80% of people love Technology X and
tell them why Technology X isn’t good enough (yet) or question the tropes
that fans use to oversell it. See Corey Quinn’s Heresy in the Church of
Docker ad DockerCon or Robert Zhu’s The Case Against GraphQL at
GraphQL Asia. The pro is that attention is guaranteed with all your
slandering. The con is that you better be confident in your claims or be
prepared to be torn apart.
Intersection Talks: This is definitely downstream of picking your topic,
but usually people with interests in X and interests in Y are underserved
with talks about X + Y. There are an infinite number of topic intersections,
too many to name, but just talk about the obvious tips and tricks and notes
that come to mind when you consider intersections.
The Perf Talk: This is a great genre for speed demons. Pick a common use
case, start off with an inefficient, high number, and whittle it down with
trick after trick after trick. Here are examples with Jake and Surma
reducing an app’s TTI from 6 seconds to 1 and Sasha Aickin reducing
React SSR from 1025ms to 5ms.

35.7 Pick a Title

Your title is twice as important as your abstract. CFP reviewers will look at both
your title and your abstract. But conference attendees often just look at your
title. Especially in multi-track conferences, most conferences only have room to
print out your talk title, and that will often be the deciding factor between
whether your talk has crickets or is standing-room-only (I know this from real
experience).

But no pressure: you can still tweak your title after getting accepted.

To the extent that your genre dictates your title, just go with that. (I’ve put all
genre title examples above in the Genre section)

If you can come up with a memorable name that encapsulates your core pitch,
like Never Write Another HoC, do that. If your talk is good, its title will be
quoted back to you with surprising frequency, so make it something you can live
with.

Examples:

Never Write Another HoC

The Hard Parts of Open Source
What Is Success?
Simple Made Easy
Even Naming This Talk is Hard

Getting creative and eye-catching is helpful. Remember that CFP reviewers will
mostly be scanning through hundreds of CFPs, usually in a Google sheet or
table. Short titles stand out. Special buzzwords stand out. Again, scan through
old published conference schedules to get an idea of what works.

If none of the above fit, don’t push it. Just take the most boring, practical title
you can do that touches on the main technologies you’ll be demonstrating.
Sometimes plain and simple is best!

35.8 Write an Abstract

With your genre and title chosen, your abstract will practically write itself. You
sketch an outline of the talk you want to do. If it helps, you can bullet point out
all the things you want to do in your talk, group and sort your points, and then
use that as brainstorm fodder for your abstract. Don’t give away the whole talk,
but show just enough to pique interest.

Most conferences only ask for abstracts, but some will leave room for more
context on why you are the best person to present this topic (it’s usually optional,
but USE IT!!!).

The first paragraph of your abstract is most important, since it is what will be
printed and used in the YouTube description. Most abstracts are just one
paragraph. The first sentence draws the attention. The last sentence seals the
deal. As with all writing, Gary Provost’s timeless advice on writing applies:

This sentence has five words. Here are five more words. Five-word
sentences are fine. But several together become monotonous. Listen
to what is happening. The writing is getting boring. The sound of it
drones. It’s like a stuck record. The ear demands some variety. Now
listen. I vary the sentence length, and I create music. Music. The
writing sings. It has a pleasant rhythm, a lilt, a harmony. I use short
sentences. And I use sentences of medium length. And sometimes,
when I am certain the reader is rested, I will engage him with a
sentence of considerable length, a sentence that burns with energy and
builds with all the impetus of a crescendo, the roll of the drums, the
crash of the cymbals–sounds that say listen to this, it is important.

Do that, for your talk. Use less words if you can. Most of my abstracts are
under 100 words.

Abstracts are great places to stick attention-grabbing data points. Did you know
TypeScript is at 65% adoption of JavaScript users? Or that 51% of developers
use VSCode? Or that “we recently refactored 100K lines of JavaScript to
TypeScript”? Or that I slashed my webpack build times by 20% with this one
weird trick? We are suckers for numbers.
Most abstract submissions allow markdown for emphasis and simple styling.
Use it. Sparingly.

Just like your talk title, you’ll rarely be held exactly to it. Nobody is watching
your talk holding you to your abstract at knifepoint. You reserve the right to
change things, hopefully not too drastically or too last minute. You won’t use
this right often, but it’s there if you need it.

Run your abstract by a few developer friends, with no context. If they don’t get
it, that’s a problem. You likely have a better idea of what your talk is than
you’ve actually written down. Rip it up, try again. Be more obvious, less
abstract. Appeal to what people will get out of your talk rather than the
specifics of how to get there (which is the reason why people should come to
your talk!).

35.9 Building a CFP Process

Ok, so you’ve written one CFP. Congrats! You’re not done.

You can see this 12 Minute Video of How I Write CFPs explaining my process
below

As you’ve probably heard, due to the selectivity and randomness, CFP

submission is a numbers game. So it’s more important that you build a
sustainable CFP process than have any particular CFP get accepted. You’ll be
submitting between 2-5 CFP’s per conference, and there are probably dozens
of conferences each year that you are a good fit for.

To avoid accidentally becoming a fulltime CFP writer, you’ll want to have a

bank of topics and title/abstract samples that you can reuse. I tend to run with 5-
10 of these, of varying readiness to present (remember, you don’t have to be a
world expert in these topics to talk about them). Tweak each submission to the
conference’s target audience as appropriate, like you would a cover letter in a
mass job search. In a way, you’re kind of looking for a job, or at least a short
term gig.
Get a good photo, use the same photo everywhere. People recognize faces faster
than names.

Write a short bio, you’ll be asked for it over and over again. Don’t write down
your life story, just a simple statement of what you do, what you identify as and
what you’re generally interested in. As your speaking career grows you’ll want
to have a short, medium, and long bio on your site for organizers to just copy
paste without asking.

As you start getting acceptances and recorded talks, keep a list of your best
talks. You’ll be asked for those in future CFPs. If you make them easily
discoverable and shareable, people will start inviting you without a CFP.

35.10 Example CFPs and Peer Review

Of course I have already given my advice that you should watch a bunch of talks
and pay attention to titles and descriptions. But it helps to see examples of
accepted CFPs, so I will list what I have here:

You can find every single title and abstract for accepted, pending and
rejected (dead) talks on my site)
My first CFP (accepted for React Rally)
My first JSConf CFP (accepted for JSConf Hawaii)
React Rally Bad Example Proposal
David Khourshid’s React Rally CFP
Devon Lindsey’s React Rally CFP
Motherlode of CFP Examples from Will Larson also check Tweet Thread

If you purchased the Community Package for this book, feel free to drop your
CFP for peer review in the community chat!

35.11 Next Steps & Recommended

Reads
Phew, that was a long chapter. I hope it helps! Ping me if you get accepted, I
will be cheering for you.

As always, I am not the only source of advice on this stage. Here are other
advice pieces I have come across:

Phil Nash: how to find CFPs

Peggy Rayzis:

1. State the problem

2. State your solution
3. What the audience will learn from your talk (optional: how you plan to
teach it)
4. 3-5 sentences max.

Dan Abramov: Preparing for a Tech Talk

CFPLand Guide to Speaking
How to get into Speaking with Karl Hughes of CFPLand

Author’s Note: This was purely advice on how to get your CFPs
accepted. In a future edition of this book I will add a chapter on
Speaking Advice – I cut that out for now due to Covid-19.
Chapter 36
Mise en Place Writing
If you want to write, you probably want to write high quality articles, in high
quantity.

I know of only one way of doing this: Mise en Place Writing. Instead of
making writing a habit, you should make pre-writing a habit. By decoupling
writing from pre-writing, you can write more, faster, and better.

36.1 Mise en Whatnow?

Wikipedia defines Mise en place as:

a French culinary phrase which means “putting in place” or

“everything in its place”. It refers to the setup required before
cooking, and is often used in professional kitchens to refer to
organizing and arranging the ingredients (e.g., cuts of meat, relishes,
sauces, par-cooked items, spices, freshly chopped vegetables, and
other components) that a cook will require for the menu items that are
expected to be prepared during a shift

The idea is that cooking is faster, easier and more enjoyable if you have all the
stuff you’ll need to do prepared beforehand. It’s basically all the fun parts of
cooking separated from the boring parts. If you’ve ever had the chance to do a
cooking class in a foreign country (A great way to appreciate local cuisine in
personal travel or team retreats), notice that it’s fun because all the prep is done
for you.
Of course, for chefs, typically you’re also the one doing the prep so you’re not
really saving any work. But it can be nice to break work up into more palatable
(pun intended?) chunks of “prep” vs “cook” instead of “Prep & Cook”. In fact,
if you prep early, you also get a chance to spot missing ingredients that you’ll
need, and be able to run out and get them, rather than discovering that you don’t
have them while cooking (!).

36.2 Writing isn’t Just Writing

What’s true for chefs is even more true for writers. The actual act of writing is
only the final assembly stage of a longer, more involved process. Instead of
grocery shopping (or stocking up), chopping, measuring, cutting, peeling,
slicing, we have ideation, research, peer review, audience testing, reframing,
illustration, organization, and more.

The key insight of Mise en Place Writing is that we should decouple writing
from pre-writing.
Writing is an intensive, focused process. It takes me anywhere from 1-5 hours to
pump out an average article - in that time I am doing nothing else.

That’s a lot of continuous time dedicated to just one thing - rare in today’s
attention economy. If I were to add to that ideation and research and
organization and so on, it’d take even longer, and I’d do a poorer job of it.
Ironically, this is the stuff that actually has high leverage on what readers will
take away from what I write. So I should spend more time on that.
36.3 Components of Pre-Writing
Pre-writing is low intensity and often serendipitous, dependent on thoughts
flowing into you rather than you putting thoughts out. Here is a nonexclusive
list of things that can be realistically counted as pre-writing:

Ideation (Deciding the menu): Literally, what are possible things you could
be writing about? Raw Idea Velocity is the focus here - remember you’re
not signing up to actually deliver the thing - but if you had a flash of
inspiration or insight sometime somewhere, write it down. It’s not
uncommon for me to watch a good talk and come out of it with two ideas of
things to write about.

If you feel like you lack ideas for things to write about, your bar is too
high. Even if it’s been definitively explained elsewhere, you can still
get value learning in public by explaining in your own words to others
who think like you.
If you have too MANY ideas - I can sometimes relate - run it by a
mental filter of What People Want. You’ll want to take note of what
people are interested in. Or, y’know, just ask them what they want.

Research (Finding recipes): Links, facts, quotes, stories, demos, repos,

tweets, talks, podcasts, timelines, histories, taxonomies. Your research
journey starts immediately after the Idea. When you get the Idea Flash,
definitely note down its origin. That’s research. This is the “meat” of many
genres of blogposts - concrete pieces of information that readers can take
away. Can you imagine doing comprehensive research just before you
write? You might never end up writing! You’re collecting all the stuff
you’re going to use to write in future, except you’re doing it as you come
across it.
Peer Review (Taste test with staff): Research will be a lot easier and faster
with Peer Review. This is an advantage of having a network - a small group
of people who know more than you, that you can tap on to get more
research direction and to get a feel of immediate objections to address.
Audience Testing (Trial run with potential diners): This is a little wider net
than Peer Review - instead of consulting people who know more than you,
you’re now testing the messaging on the people you’re writing this for.
 This is an extra step I rarely do for my blogposts, but, for example, I’ll do
this when chatting with developers in conferences and meetups to gauge
reaction. Broadway shows have the concept of Workshopping in a smaller
audience, with the understanding that everything from plot to props to cast
can be changed based on feedback, before the show actually launches live.
For more highly produced pieces of content, like talks, workshops, or
books, this is worth investing in so that you have the impact you hope for.
Reframing (Renaming or Improvising the dish): The initial idea might not
be what you actually end up writing. Whether it is due to audience
feedback or delayed inspiration, you might find a more interesting angle to
approach the topic, or find a better analogy. It’s cheaper to pivot the entire
focus of your writing when you haven’t written it yet. Just by illustration -
this chapter you’re reading was originally titled “How and Why I Write” -
good, but not as interesting and memorable. I found a better framing, and
reframed.
Organization (Presenting the dish): Deciding on a structure for your article
sets it apart from a stream-of-consciousness rant. It lets people zoom in and
out of your thoughts by skimming or diving in as needed. If you really need
to deliver a message, use the Tell them what you will tell them, Tell them,
and Tell them what you just told them metastructure, that highlights the
structure itself. I don’t always do that because it can feel repetitive. But
structure choice is important. See, for example, that I’ve brought you along
this list in roughly chronological order.
Illustration (Taking a photo for the menu/website): A picture speaks a
thousand words. Think about how you can help the reader give a visual
reference for what you will describe - as a bonus, it makes your thesis a lot
more sharable. Some things might be harder to illustrate - Maggie
Appleton has great ideas on how to illustrate the invisible. Mental imagery
can work too - you’ll notice I don’t use many visuals here - but I am
invoking a cooking analogy that you already have entrenched in your head.

As you can see, there’s a lot that you can do to improve your writing before you
write. We should have a separate workflow for pre-writing than we do for
writing.
36.4 The Pre-Writing Workflow
The idea of grooming a backlog is key to productive writing. For the past few
months I have been accumulating a backlog of ideas that could be interesting
topics to write about. As of right now it stands at around 50-70 topics.

First, make sure you have a cross platform note-taking tool - I evaluated
Evernote, Notion, Roam Research, and SimpleNote, but currently am using
OneNote because it is free forever with the backing of Microsoft, and has good
offline support. I might move to Joplin in future, or write my own. It’s not
really about the tool - at my scale, it’s trivial to switch tools - but the feature set
needs to support the workflow.

And the workflow is this - anytime you have any content idea anywhere -
reading something, watching a talk, listening to a podcast, having a conversation
with a friend, thinking to yourself in a shower - you need to note it down in a
searchable place. If it attaches to some other relevant piece of thought, you
collect these together in a growing list of ideas, quotes, soundbites, links, talking
points and so on.

It has to be easy and fast. I don’t know about you but I can forget ideas in
minutes. If I don’t write it down it might be gone forever. I’ve been known to
jump out of the shower dripping wet just to go write something down.

Human Brains are great at abstract thinking and creative inspiration. Computers
are great at storage and search. Use them as your second brain.

Each note you make is a little kitchen, and you’re assembling the pieces in place
for a future you to come in and just get to cooking.

36.5 The Infinite Kitchen

When practicing Mise en Place, Chefs are limited by available kitchen space-
time. Yes, I am invoking space-time equality. You not only have raw table
square footage limits, but food laid out must be consumed within a certain time
as well.

Writers have no such restriction.

You, the writer, have an Infinite Kitchen in the Cloud.

Screw struggling to come up with 1 blogpost a month. You’re now

simultaneously preparing 50 blogposts at once. You’re adding ingredients as
they come in, you’re chopping them up, rearranging, taste testing, noting what
you’re still missing, throwing entire kitchens out, smashing two kitchens
together.

Have fun! Be messy! Get weird! No one else is watching!

And then you write.

36.6 Writing
The process of writing is the same whether I write once a day or I am trying to
create a monster skyscraper or even a book. I still separate pre-writing from
writing.

Each time I sit down to write, I go through my growing list and think about what
is the most interesting thing I could write about that day. The nice thing about
having a groomed backlog is that all the related links and notes and thoughts
from myself over time is collected in a list ready for me to flesh out into a full
piece. It’s just less intimidating that way. But there’s also a little dopamine hit
from this concentrated dosage of inspiration from all my past selves who have
sent this message into the future.

The key insight of Mise en Place Writing is that we should decouple writing
from pre-writing. With that, our writing improves, as well as our enjoyment of
writing.
36.7 Improvisation is OK
With all that work done pre-writing, I might be giving you the impression that I
am strictly separating everything all the time and I don’t deviate from the plan
once I enter Writing Mode. Not true. Writing Mode is another opportunity to re-
experience the pre-writing and the writing job all at the same time, just with the
benefit of some extra prep that I’ve done before hand.

Improvisation is OK.

36.8 Editing
A lot of people put heavy emphasis on editing. I agree that it can add a lot of
value. But I don’t do a lot of it. For one thing, I don’t have a ton of time. For
another, I find it often doesn’t add as much value as hoped. You can run things
by Hemingway or Grammarly but they are no substitutes for human judgment.
Finding a good editor is harder than just grabbing a coworker, but that’s what a
lot of people do and accordingly they don’t get the same value as a good editor
would.

I wish I had more insights here but I just don’t have a ton of experience with
editing. I will say that I edit my posts a lot after publication - they are all
intended to be living documents in a Digital Garden - so if something doesn’t
read quite right or someone chimes in with a crucial thing I overlooked, I will go
change it. But usually, it’s more important to err on the side of getting it out
there rather than be bogged down in heavy editing, especially when it can be
edited post-publication.
Chapter 37
Side Projects
Side Projects aren’t necessary to succeed in this industry, but they offer a huge
advantage for your learning and career development. I make a strong
recommendation that, if at all possible, you have one or two side projects you
are constantly shipping.

37.1 Why Side Projects?

Learn better. All side projects are forms of applying what you learn. It’s
amazing how much you learn when you try to use what you have learned in
theory. You quickly find the holes in your understanding. You learn what is true
and what is marketing BS. You learn that not everyone knows what they’re
talking about, despite sounding smart. And of course you remember what you
use a whole lot better.

Breakable Toys. The book Apprenticeship Patterns popularized this way of

viewing side projects. Many software developers work in an environment where
the consequences of failure are high. But experience is built upon failure.
Exceptional progress can only be made when exceptional risks are safe to take.
By working on smaller projects outside of work, you have a way to experiment
and make mistakes, without the usual consequences. You can get past Hello
World quicker with a Breakable Toy. When you encounter a new way to do
something, like a new library or framework, you can put it into your side project
to see how it feels in a nontrivial use case you know well. When your colleagues
ask for your opinion on certain technologies, you’re no longer making a decision
based on docs or marketing, you can assert some authority from actually having
used it in something “real.”
 Examples: Both Kent C. Dodds and Adam Rackis maintain bookshelf
apps (Kent’s, Adam’s) as breakable toys - must be something about
avid book readers! If learning a language, Vincent Prouillet notes that
creating a static site generator is a great side project because of all the
functionality needed.

Prototyping new things. You don’t just have to work on apps. You can try
building your own X from scratch, or creating a “Lite” version of something you
already use. People often learn so much from building a “Lite version” of their
main app or tool that they end up applying it to their actual work, like Dominic
Gannaway did with Inferno.js (now he is on the React core team), or Zack
Argyle building a Pinterest PWA and convincing the CEO to switch the real
Pinterest site over to a PWA (now he manages the React Native team). Google
used to be famous for its 20% rule, which spawned amazing side projects like
Gmail, Chromecast, and AdSense (worth billions of dollars).

Practice Shipping. Shipping is a whole other discipline than coding. When you
ship code at work, you are doing the shipping equivalent of bumper bowling.
The system is set up to not let you fail as much as possible. You have coworkers
and bosses around you to help you decide what to do, when to do it, how to
market it, what your budget is, what not to do. When you ship, your coworkers
are obliged to pay attention. None of this true in real life. When you work on
side projects you practice all the other noncode aspects of coding that make your
code matter: decision making, prioritizing, marketing, documenting. If you
dream of founding a startup someday, you should practice these skills before you
start relying on them for a living. If you are a Junior Engineer looking to grow
to Senior, understand that one of the few things everybody identifies as a key
quality of a Senior Engineer is the ability to independently execute. Act for the
job you want.

Permissionless Improvement. The other thing about Side Projects is that

nobody can tell you no. As long as you don’t give away company secrets, you
can usually work on whatever you want. The danger with company laddering,
however well intentioned, is that it puts a cap on your career progression, tuned
to a theoretical expectation of an average engineer. But you are not an average
engineer. You’re reading this book in your free time for crying out loud! If you
are feeling undervalued or artificially limited at work, your side projects are an
outlet where you can put your full awesome on display. You shouldn’t have to
keep your project a secret: If you have a supportive manager, they will not only
recognize that you are trying to stretch your wings, but actively encourage you
and give you resources. A manager that is afraid of you improving yourself
shouldn’t be your manager at all. Which leads us nicely to….

Resume Builder. Side Projects should never be a required part of any job
application, but it usually helps to show that you can work independently and
that you are passionate and curious about technology. Your current job might
work on some legacy technologies for good reason, but if you want to switch
jobs to work on a newer tech stack and have no experience in that stack, it can be
a resume saver to have a Side Project that demonstrates you have built
something nontrivial with the stack you want to work with. Of course, some
people take this too far and do Resume Driven Development. In practice, I find
that this is more often a criticism by bitter Reddit trolls than actual dev behavior.
If you are pursuing a career in Infosec, getting bug bounties on BugCrowd and
HackerOne are excellent resume items.

Improve your productivity. Your Side Project can be a dev tool that makes you
more efficient at work. This can often be the best kind of side project to do,
because the Side Projects you learn the most from are the Side Projects you
use, plus it saves you valuable time at work. Think expansively of the entire
range of tasks you do - from things you do 50 times a day to things you only do
once a month. Randall Munroe of xkcd has a great chart that does the math on
how much time you should invest in automating tasks:
User Empathy. Your Side Project can often put you in the shoes of your
company’s end user. As an employee, you can usually try it for free. Since you
build the product, you might think you understand it intimately - until you
actually try to use it as a user. Suddenly all the bug reports become real.
Suddenly the bad design decisions matter. Suddenly documentation and good
copy are critical, rather than a chore.

Making Money. If your Side Project makes money, you suddenly gain options.
You don’t have to go all Pieter Levels-level Indie Hacker, but a little passive
income on the side never hurts. But if it ends up going unexpectedly well, as
happened for devs like Taylor, Mike, and Anne, you now have uncapped upside.
Mikael Cho ended up pivoting his entire business to his side project, Unsplash.
When you work, you are renting out your time. When you do a Side Project,
you own equity. Rich people own equity. Be like rich people. Your project also
serves as a good BATNA (see the Negotiation chapter, Chapter 31, for more) -
when negotiating your next role.

A brief note on potentially money making projects: Be careful of IP

Assignment. Most developers sign a “proprietary invention
agreement”, which may range from “we don’t care what you do in
your own time” to “we own you 24/7”, and may be variously
unenforceable depending on what jurisdiction you are in. Negative
outcomes may range from getting fired (though it worked out for
Reilly Chase - always good to have options!) to the company claiming
they own your project (!). Try to make clear what the acceptable
boundaries are - this is easier if you don’t keep your project a secret
from your manager. Common sense rules apply. Don’t directly
compete with or clone your employer’s products. Get explicit
permission if you need to work on it during work hours. Don’t use
company equipment to make your project (just for avoidance of doubt
down the line).

Productive Fun. Don’t forget you can work on things simply because it is fun.
You don’t need a better reason than that. However there is a difference between
passive fun (leaning back, watching Netflix, reading) and productive fun
(making, experimenting, failing). Most people are extremely imbalanced in their
Consume:Create ratio - correct it with a fun Side Project!

37.2 Code-Life Balance

Be wary of burnout. If you code at work and code for fun, you are burning the
candle at both ends. It’s fine if you have a long wick, just recognize that even
you need some days off. You are building a career, not running a short sprint.
And excelling at your career can be meaningless if it comes at the cost of health,
family, and friends.
You are a developer, but you are also more than a developer. Your Side Project
does not have to be writing more code, it can be code-adjacent, or just nothing to
do with code at all. You can still experience a lot of the benefits enumerated
above.

37.3 Project Ideas

Some project ideas for you to think about:

Work on your own open source library. This is a common one for
developers because the risk is low. But the reward is often low too. It is
usually unpaid work and a maintenance burden. But it can help you be
more productive at work or get some conference/networking opportunities,
while giving back to your community. Don’t forget that you can clone
existing open source apps as well! (Chapter 10)
Open Source your Knowledge. See Chapter 13!
Contribute to your local meetup/community/nonprofit. Your valuable
skills can be put to great use helping out on projects that other people need
and cannot make. Many developers got their start in web dev making a site
for their band. Everyone needs a site!
Build your Portfolio or Blog. A portfolio or blog is a project too - spend a
bit of time every year making sure your online profile is updated to reflect
your latest skills and interests. See Marketing Yourself (Chapter 39) for
more. Other forms of content are also interesting: running a podcast,
newsletter, livestream, or YouTube channel - but know that they are higher
effort and bigger commitments.
Teaching. If you want to make your first money in the content creation
game, there can be no better place to start than a platform like Egghead,
Frontend Masters, Pluralsight, or LinkedIn Learning. They will give you
the resources you need to record your first lessons, market them for you to
their existing audience, and take care of payments. All you need to do is
create compelling content.
Writing a Book. If you’re feeling particularly adventurous and your
blogging/other content has seen some good results, you can also go for
 writing and selling your first book. You’re looking at the result of one such
Side Project!
Closed Source Side Hustle. You can also create and operate an app for
money. This is basically a full-on Side Hustle, and involves the highest
level of responsibility and support because you have recurring customers.
To get ideas you can check out Ideaswatch, or you can simply look for
problems to solve at work. Dylan Feltus saw a need for a feature request
tracker at his company, so he built NextPlease.io, and his own CEO is a
now proud customer.

37.4 Project Advice

Start small and break it up. The biggest mistake people make when they’re
doing a Side Project is they start too large. They try to build a massive project
that solves 100 different problems they see in the world, rather than something
that does one thing better. When you let the project scope blow up, you become
unable to finish it. Repeat this too many times, and you start thinking that you
are the problem - that you are the type of person who doesn’t finish projects.
Don’t let yourself get there. Beware the yak shave and jealously guard the scope
of your project. It’s OK for your open source library to be a little bit shitty.

Pick constraints. Scott Young decided he would go through MIT’s four year
computer science curriculum (all of it, no cut corners) in 1 year. This is how he
frames the MIT Challenge that made him famous:

A good rule of thumb is that a project should have at least three

constraints: scope, content and mission. Scope means you constrain
the project to be only a certain amount of time or a clearly defined
size. Content means what you’re actually going to do—I chose exams
and programming for my MIT Challenge, but I could have gone with
something different (say a research project). Mission means you
narrowly pick what your project stands for, which then lets you
make cuts more easily when things start to grow.
One such useful constraint is to decide up front whether your project is about
shipping a new product or about learning a new technology. Don’t let yourself
do both. You can also put a time limit and take dedicated time off for this
project. Ben Orenstein reserved his Side Projects for short, one week
“Codecations”, which gave him the skills and confidence to strike out and found
his own bootstrapped startup. However, don’t limit your projects to things
you already know. It is good to practice having to learn on demand too. If you
only stay within your comfort zone, you never really grow.

Consistency and Momentum are King. A project that you leave for too long
gathers dust and dies. It’s easy to look at that project you haven’t touched in a
week and say you’ll get back to it next week. Then a month. Then a year.
Making a regular commitment that you don’t break helps you see forward
momentum on this project, and helps others see it too so that they know that they
can keep cheering you on. When your friends check in on you you’ll have
something positive to report, instead of the awkward “yeah I haven’t got any
updates”.

Have an end date. Projects that drag on forever cause guilt due to their
incomplete state. Having no end in sight can be strangely demotivating, even if
you are doing it for fun. Being able to get closure and move on frees you of
responsibility so that you can tackle the next thing. Define “Good Enough” up
front, and don’t let your scope expand when you get there.

One great “forcing function” for you to ship your project and get closure is to
commit to giving a live demo or talk at a meetup or some other event in the
near future. Not everyone responds well to this kind of pressure! But it works
for chronic procrastinators like me.

“Fixed deadline, negotiable scope” has to be the most underrated

pattern in product management. It’s the secret to shipping. - Ryan
Singer

Check Multiple Boxes. In Sarah Drasner’s timeless post on Prioritizing, she

advocates picking projects based on whether it helps to fulfil multiple goals at
once. If you have four areas of concern, like community, mentorship, money,
and personal fulfilment, then picking a project at the intersection of two or more
of those areas can have higher mileage for your time. I have four that you can
use:

Project benefits you personally (money, network, etc)

Project is one you enjoy/get excited about
Project benefits people you love/care about (can be broader community)
Project brings in my domain knowledge from prior hobbies/interests (e.g.
finance, fiction, games, movies)

When I think about the best project choices I have made, I tend to
think about winning even if I fail. What that means is I’m choosing
my projects based on the skills and relationships I develop that can
transcend or persist after that project. - Tim Ferris

37.5 Further Inspiration

Here are some life changing side projects that people have shipped and that you
could do:

Jennifer Dewalt shipped 180 sites in 180 days while learning to code, and
now is technical cofounder of a YCombinator-backed startup.
Jessica Hische practiced design by shipping one drop cap a day every day
since Sept 2009.
Niklas Göke built a massive audience writing one book summary a day
from 2016.
Casey Neistat put up a daily vlog for 550 days and became “one of the
Internet’s most famous celebrities”.
Kate Bingaman practiced illustration by drawing something she purchased
everyday from 2006 to 2014.
Michelle Poler decided to get over fear by spending 100 days facing her
fears. This kick-started her motivational speaking career. Jia Jiang did the
same with rejection.
 Megan Gebhart couldn’t decide what she wanted to do, so she decided to
have a cup of coffee with a different person every week for a year.
Both Pieter Levels and the Shooting Unicorns duo decided to do 12 projects
in 12 months, and both didn’t complete it because they found something so
successful that it became their full time gig.
This book was shipped by writing 2-4000 words every day from April 10th
to June 1st 2020.

Of course, entire companies have emerged out of side projects, from Slack
(offshoot of a failed MMORPG) to Apple (a side project of an Atari employee).
Chapter 38
Developer’s Guide to Twitter
Twitter is at once optional, yet incredibly important in the developer community.
An academic survey concluded that developers use Twitter for Awareness of
new projects and practices, serendipitous and social Learning, and building
professional Relationships.

We know that great projects and communities are organized on Twitter. But at
the same time great developers also do well without any Twitter presence
whatsoever. An enlightened empiricist might therefore conclude that Twitter has
zero bearing on developer success!

The truth is, whether you would benefit from Twitter depends on the community
you’re in and your natural affinity to the format. The #1 feature of any social
network is the people already on it. Look at the leading figures in the
language or framework or other developer community you care about. Where
are they most active? That’s probably where you should be. For whatever
reason, Twitter is currently the watering hole for everyone from frontend web
development to machine learning to infosec. If you’re reading this in the future,
it may have changed, but I doubt it.

The reason I have confidence in Twitter is how central it is to developer

networking. Although there are about 40 million developers worldwide, the
most engaged/connected 1-2 million are on Twitter. Pull up your favorite
conference’s talks, even studiously anti-salesy ones like Strange Loop. Count
the number of times Twitter was mentioned or shown on screen. I stopped
playing when I realized that too many people put their Twitter handles on the
first slide. Even at Facebook, Microsoft and Google conferences, all companies
with competing social networks, developers offer their Twitter as their primary
means of contact. If that weren’t enough, I’ve seen thousands of developers get
jobs and contracts off of Twitter.
It’s free. You owe it to yourself to at least try it out. If you don’t end up liking it,
fair deal, at least you gave it a shot. This chapter is dedicated to helping you
get the most out of Twitter, however long you choose to be involved.

38.1 Getting Started

Everyone basically has the same advice for getting started with Twitter - follow
some good people in your community and follow who they follow. Some people
advise looking at hashtags (e.g. topical, like #webdev, #swift, #devops or event-
based, like #devopsdays2020) to discover more good follows, but that is too
broad for my taste. Some community leaders, like Tracy Lee, keep lists of
developers they explicitly recommend following.

Projects you use may also have a Twitter account - some merely post project
updates, but others may also retweet interesting work done by community
members that you should check out. Follow people who work on that project,
and follow your peers who are also doing cool things with it. Here is where you
will start to find your community - people who can inspire, encourage , and
challenge you.

The other thing you can do from the get-go is to set up your profile. Get as good
a Twitter handle as you can - preferably your name, without underscores, no
misspellings, no numbers. Of course it might already be taken, so you may need
to get creative, or pick some other handle representing what you want to be
known for (e.g. there are a lot of Joe’s in tech, so Joe Previte goes by JavaScript
Joe, and his site is http://jsjoe.io/, so his handle is just @jsjoeio). This is
mainly important because it is the primary way people will call on you. Don’t
worry, you can change it later if you need to.

The other basic element of the profile is selecting a good avatar picture and
name. If in doubt, just use your real name, and a good picture of you smiling (or
a picture of you with a great story to it that you can tell when asked). This is
your “face” online - people will see it before they see anything else you post, and
eventually subconsciously associate your profile whether or not they want to
read what you have to say. When people talk about you in real life, they’re
likely to use your Twitter name and handle. This transfers across social
networks, and people like seeing the same names and faces pop up across
GitHub, Twitter, YouTube, and Slack. In a world of default anonymity,
consistent identity is king.

Note: See Marketing Yourself, Chapter 39, for more on this!

In your bio, you should indicate what you do and what you’re about. This is
Twitter’s equivalent of a business card. Offering your job title and company, and
what you do there, can be a good shorthand, but be sure to double check whether
there are any company social media restrictions you need to abide by (for
example, publicly traded companies often have regulator-imposed restrictions).
You can also choose to get a little more creative and inject some personality
instead - this isn’t LinkedIn after all!

As with anything here, there are reasons to ignore my recommendations. I am

simply offering them as a good place to start.

38.2 What Do YOU Want?

Twitter is a confusing combination of newsfeed, microblogging platform,
professional network, customer support, and entertainment channel. It is a
massively multiplayer, open-world, mostly text-based, infinite game without a
manual. It gamifies you with meaningless internet points that nevertheless can
convert into very real real-world value (in terms of jobs, knowledge, sales,
traffic, and even friendships).

Because there are no rules, you should make your own. It is easy to sign up
with the intention of staying informed on technologies you care about, but then
getting sidetracked into an infinite feed of memes, clickbait, and outrage. The
timeline is a slot machine and you need only scroll down to get the next hit of
dopamine. You can legitimately find yourself in the grasp of social media
addiction, and Twitter is only too happy to feed it. At a minimum, shut off all
email and phone notifications (which are on by default). If addiction is starting
to severely impact yourself or someone you know, seek help. For example, if
you find you cannot sit and code for two hours without compulsively checking
Twitter when you need to focus.

While you can connect with luminaries in your field and find future coworkers,
remember that “Dev Twitter” is dwarfed by the rest of the 330 million Twitter
users, engaged in every form of human interest from politics to finance to dog
ratings to academic research to K-pop. Developers you follow also have a range
of interests, and unclear policies about what they will or won’t do on the
platform. Different people use Twitter in drastically different ways - some only
tweet about a single topic, others broadcast every waking thought. You will have
to decide what you want out of Twitter in broadly three dimensions:

Input: What tweets you want to read

Interaction: When do you engage with other people
Creation: What do you post of your own

Since this is personal social media, you have the right to do whatever you feel
like doing, and it is difficult to give general advice in book form. But I can offer
some high level principles along with some reasoning as to why they are a good
idea, and you can then decide how much you agree with it.

38.3 What I Want From Twitter

For me, Twitter is not a game of getting followers. Having reach for my work
is good - it’s why you’re reading this after all - but it is easy to demonstrate that
getting a very high follower count is an anti-goal. Just check out the replies for
anyone with over a million followers. It is a cesspool of the worst of the
Internet. Twitter becomes unusable for most “famous” people. At the extremes,
you will be tempted to compromise your ethics or self respect, like Siraj Raval.

Your impact also impedes what you can say. Like it or not, with great audience
comes great responsibility, and your audience will be the first to remind you of it
when you step out of line - placing high stakes where previously there were
none, and effectively losing control of your own public voice. To be rich and
famous is good, but to be comfortable and anonymous (or rather, known-just-
enough-to-be-credible) is better.
Experienced users can also tell when you buy followers, and it looks dreadful.

The 10,000-100,000 follower range seems like a sweet spot - enough to open
doors for you, but not so much that it starts controlling you instead.

A better goal for Twitter is to get off Twitter. By this, I mean that you want
your Twitter activity and friendships to translate into off-platform activity and
friendships. It is at its best when the people and projects that we find on it leads
to impact - collaborating on open source, working together on a company,
teaching the next generation, organizing for social change, or even real life
friendships.

I don’t know who first said this, but it rings true of each platform:

Facebook is for past relationships (people you used to know)

LinkedIn is for fake relationships (people you pretend to know)
Twitter is for future relationships (people you will know)

Real human connection is the goal - what Seth Godin might call Finding your
Tribe. You don’t need everybody to know you. You’re just there to find people
who share your interests. Kevin Kwok compared this to “Tapping a tuning fork
and seeing who resonates.”

I experienced this in a real way one weekend when I decided I wanted to start
the first SvelteJS meetup in New York with no organizing experience and no
resources. Within one week I got a venue, speakers, and 50 people showing up to
kick it off, all entirely via Twitter friends. Since then, it translated into a global
conference attended by thousands of developers across five continents. In other
parts of my life and career, Twitter has translated into countless speaking, open
source, work, and friendship opportunities. My experience is not special. You
can have this too with a few years of consistent engagement with fellow
developers.

38.4 Your Twitter Feed

The first thing you need to get control over is the inflow of information. This is
a matter of signal to noise. Some people may be a lot “noisier” than others -
tweeting about stuff you have no interest in. It will take a while to learn what
people share and what you want to see.

Unfollowing someone noisy is a good first step, muting and blocking them is
more aggressive. All of these are reversible decisions. I’ve ended up following
people I’ve blocked because I made a mistaken snap judgement. Other people
act as “signal boosters” - retweeting and quote tweeting important/quality stuff
from others. You can stay on top of interesting but noisy people, by leaning on
others who do the filtering work for you.

I mute the nitpickers, block the outraged, like the kind, follow the
insightful. - Naval Ravikant

Keep in mind that you’re dropping into the deep end. As awesome as it is to be
a fly on the wall listening to experts debating, you’re going to be missing context
and required knowledge to keep up - for now. You’re also going to see people
performing at their best - sharing their wins and “overnight” success. Keep in
mind that their struggles and sacrifices are real but hidden. It’s normal to feel
overwhelmed when you compare everyone’s best to your worst. Twitter has
been described as an “imposter syndrome slot machine” - take inspiration and
insight, but keep everything in perspective.

Some more beginner-friendly ways to find other developers is to get involved in

Twitter chats. This isn’t a formal feature of Twitter - it is just a social
agreement to come together at a given time and discuss topics using a shared
hashtag. You can then surf by hashtag and find good questions and answers to
riff off. Good Twitter chats to start with are #devdiscuss,
#eggheadchats, and #codenewbie.

Twitter gives you an algorithmic feed by default (giving you “Top Tweets”
determined by their black box algorithm). You can switch this to a chronological
feed on some apps, but it is anecdotally poorly supported. While you can’t do
much about your Home Feed (representing everybody you follow), you can stay
on top of select groups of people by using Twitter Lists. You can also stay on
top of high priority accounts by turning on notifications for them (you can do
this while still not letting Twitter interrupt you with push notifications). For a
more advanced workflow, look into using Twitter Lists and Tweetdeck. I
personally refrain from them because I fear those would lead me to spend even
more time on Twitter.

38.5 Join the Conversation

Twitter is very egalitarian - the very promise of the platform is that anybody can
reply to someone and potentially get noticed. However, the way you reply can
deeply affect the relationships you make, the branding you establish, and your
internal emotional state. As you figure out what kind of people you like to
follow, you also build some idea of the “rules of engagement” you can use for
yourself. This next part concerns how you interact with others.

Probably at the top of the heap in terms of concerns is the balance of personal vs
professional. How much of your “whole self” do you share in public, or how
much do you “stay in your lane”? It isn’t a binary decision - people want to
interact with human beings, not bots - but there is some balance that will be
more right for you than others. Everyone has a filter - you will need to decide
what yours is.

If you need a pointer, my advice is to start off 90% professional, focused on a

small set of topics you work on or are interested in learning. In your early days,
this helps tune your signal-to-noise ratio clearly to one end, so that people know
where you have Planted Your Flag and know what they will get in following
you, mentioning you, and replying to you. Over time, as you become more of a
known quantity, you can loosen up a bit - people also get very invested in
personal journeys, like mini episodes of a years-long TV series (starring you!).

The other dimension to think about is your positivity. A huge swathe of social
media is driven by constant outrage - while justified to various degrees, the
majority of it may not be in your immediate Circle of Influence. Engaging in
outrage and criticism might feel good in the short run, but may negatively impact
your mental health in the long run. You also have the same impact on anyone
who follows you. I’m not saying to never criticise or to never be outraged. I’m
just recommending that you pick your battles. It’s not the same as pretending
that “Everything is Awesome!” either. If something is truly terrible, by all
means, call it out. But remember that human beings always deserve human
decency. Criticise actions, not people.

If in doubt - stay 90% positive. Take special effort to point out truly awesome
things (e.g. work that other people have done), and elaborate why they are
great. People appreciate when you are a Beacon of Awesome.

In short: make shit, don’t stir it.

And now let’s talk about creating.

38.6 Being Helpful on the Internet

It goes without saying that you should be posting your original work - projects
you’ve worked on, blog posts you’ve written, talks you’ve given. Tag and thank
people accordingly and they might help you spread your work. This is going to
be a primary reason people follow you, to get updates and inspiration as you
continue to do great work. As Daniel Vassallo says, “Make something
interesting in real life, and go share it where people are interested in what you
did.”

You might feel that you haven’t done anything interesting yet. That’s fine. One
good way to get started is with retweeting content you like from others. As you
become more able to add value yourself you can start alternating between
retweets and your own original content.

There are a great number of other ways you can be helpful on the Internet:

Answer questions when people need help

Offer insightful responses in discussions
Tag appropriate people (in moderation!)
Ask good questions - thought provoking, not “please debug my code”
Offer code or design tips - Samantha Ming and Steve Schoger are great
examples
 Share great projects and blog posts
Summarize podcasts and talks
Pick Up What They Put Down - give genuine feedback and build upon
things that your mentors are working on.

Take some pointers from Daniel Vassallo, author of Everyone Can Build a
Twitter Audience:

A high-quality tweet:

Is on a topic you have credibility on.

Is on a topic that interests your audience.
Is on a topic that interests you.
Is about something you experienced.
Has concrete details rather than abstract.
Doesn’t ask for anything.

Professional tweets have a few genres, and you could adopt Bianca Ciotti’s
taxonomy of posts and think about how different kinds of accounts have
different mixes of posts. For example, Brand Accounts like Wendy’s are mostly
Delightful, whereas Product Accounts like GitHub are mostly Transactional.

When you read something great off Twitter (e.g. via Hacker News or shared
internally at work or in an email newsletter), check to see if the author has
shared it on their Twitter. You can track it down easily by pasting the URL into
Twitter’s search, or use a chrome extension like this to automate that. Give that
author positive feedback, retweet it to your followers (ideally with an elaboration
of what you liked). If the post is not on Twitter, great! That’s something you
should post as a standalone tweet.

It is quite reasonable to get your first two to four thousand followers without any
notable achievement of your own, just by being an active community
participant. The reason I know this is because that’s what I did for a year while
learning to code. Having a good (read: helpful, informative, or funny) early
reply on someone else’s popular post gives you a lot of exposure.

It may seem silly, but humor is helpful too. Everyone needs to let loose every
now and then, and we all appreciate the occasional joke, meme, or cat picture.
Twitter definitely has a “back of the class” vibe to it. Not taking ourselves too
seriously and making lighthearted jokes is part of the fun. Some people in fact
find a lot of traction running meme accounts. This is great if you want to be a
comedian, but doesn’t always help you in your professional pursuits.

By far the most rewarding thing is creating something you’re proud of and
sharing it on Twitter. Your followers may not respond to every one, but do
enough good work and it will eventually be noticed. Just be sure not to hinge
your self worth on the vagaries of Twitter’s recommendation algorithms.

The main idea is that you don’t always want to be a taker in your various
relationships with people you meet on Twitter. You should give as much, or
more, than you get. Ironically, being a chronic giver will help you get much
more out of Twitter too.

38.7 Twitter as a Second Brain

“It’s like Evernote with a slot machine” - Visakan Veerasamy

One way to consistently add value as part of your Twitter engagement is to stop
thinking of every interaction as a transaction or a professional interaction. Sure,
on some level you could argue for it, but it probably doesn’t help. Nice people
don’t keep score. It’s better to think of Twitter as the ultimate tool for
Learning in Public.

Tweet out anything insightful that you learn. We’ve discussed summarizing
podcasts and talks, but you can go a LOT further. Share interesting quotes with
attribution to the source. Screenshot pages of books you read with key sentences
highlighted. Record videos of amazing demos. Learn in Public.

Note that this works for you even with zero followers. Because you are using
Twitter as a note-taking app, you now have a free, immutable, publicly
searchable record of everything you’ve learned.
You might chafe at the format - 280 characters isn’t a lot to work with. But
constraints are sometimes blessings in disguise. In this case, you are forced to
summarize everything, and break up your summaries to multiple tweets if you
need to. This makes every tweet an interactable and linkable chunk of
knowledge - fast to read, and trimmed of excess fat. Because it’s so short,
there’s no point spending too much time on it either.

It turns out this is great for Future You - and the people who follow you. All
content must be condensed to this tiny format - bigger than a headline and
smaller than a paragraph. It means that everyone (loosely) has an even playing
field, and you aren’t allowed to ramble on without getting straight to the point.
For those familiar with the Faustian bargain of Google AMP - Twitter is “AMP
for thoughts”. From the consumption side, Twitter is RSS reborn.

What’s great about tying a social network to your note taking is that your
followers have an equal chance of benefiting from your notes, as they do
contributing to them. Instead of a comment section all the way down at the
bottom of a blogpost or YouTube video, they can chime in at the appropriate
spot. I have learned a tremendous amount from people pointing out related
resources and readings. This informal, spontaneous, collaborative learning is a
form of Open Source Knowledge and can be very powerful for building your
knowledge, reputation, and network all at the same time.

A final tip: Tweet Threading works across time - power users call this a
Zettelkasten or Memex. You can explore that concept on your own.

38.8 Dealing with Haters

At some point you’ve probably seen someone get “cancelled” over their tweets.
Twitter outrage mobs do form, and you need to be mentally prepared, but don’t
let that scare you into not putting out anything. Canceling doesn’t happen as
often as you might fear. Nobody wants to be the one to “punch down”, so it
mostly happens when you’ve got some amount of following already. That
means you have plenty of time to get your “media training” in.
The basic filter you should run your tweets by is thinking about what your tweets
would look like out of context - because they likely will be taken out of context.
The old-school version of this is known as the “Front-Page Test” - how would
you feel if it showed up tomorrow morning on the front page of the local paper?
It can be funny to make inappropriate jokes - but there is a line, and when you
cross it, there can be consequences. You can delete tweets, but not memories.

Chances are you won’t be involved in anything as serious as that New York
Times story I just linked. It’s far more likely that you will attract the occasional
loud critic, or be quietly removed from opportunities that you might otherwise
have received.

In these situations it is important that your good intentions are clear and that you
demonstrate that you can receive and act upon feedback well. Instead of
instantly defending yourself, listen to the substance of the criticism, and address
them or apologize accordingly. We all screw up sometimes, and knowing how to
admit you are wrong is a better strategy than trying to never be wrong. As Tim
Ferriss notes, some version of “I hear you” will diffuse 80% of haters. Just make
sure you mean it.

Recognize the signs when someone is arguing in bad faith:

Nitpicking
Insults
Straw-manning
Goalpost-moving
Deflection

When you do, stop replying. There is no point continuing the conversation.
Also, recognizing these traits will help you avoid arguing in bad faith yourself.

Learn to disagree respectfully, as intelligently and constructively as you can. Try

to go as far up the Hierarchy of Disagreement as you can:
De-escalating tension is a great life skill. Nonviolent Communication is both a
book and school of thought used by everyone from educators to hostage
negotiators. You may want to check it out.

Not taking things personally is a superpower. If people are attacking you as a

person, you should block/mute liberally - you don’t need them in your life. If
they are trolls, don’t feed them. But if people are criticising your work, you
don’t have to take it as a personal affront. You can convert your loudest critics to
your biggest teachers if you are willing to divorce your identity from your work,
and take feedback dispassionately. Words on the Internet won’t break you - and
once you’ve survived one, you can survive more. Lay a firm foundation with the
bricks that others throw at you.
Finally, there is always the option of taking a temporary or permanent break
from Twitter. Some great developers have sadly been harrassed off the platform.
If the mob is affecting your personal safety or mental health, look after yourself
first. Twitter is a nice-to-have, not an industry requirement.

38.9 Definitely Bad Ideas

Again it is difficult for me to tell you what to do on your own personal social
media, but for those who are just looking to get started, I can offer a few more
pointers:

No racism, misogyny, gatekeeping. Just don’t. Not even ironic jokes.

Your tweets WILL be screenshotted and taken out of context and you WILL
lose jobs and friends. Tread extremely carefully here. You can delete
tweets you shouldn’t have tweeted, but you cannot unsay things you should
not have said. People remember.
Don’t be a “Reply Guy”. A reply guy is a term for someone who
frequently comments on tweets in an annoying, condescending, forward, or
otherwise unsolicited manner, often making the conversation about
themselves. It doesn’t have to be gender specific of course, but it is so
overwhelmingly done by men to women that the name stuck. Some women
react by making generalizations of all men, which only drives reply guys
further. Do not engage, do not mansplain, do not defend. Assume they
know it is a generalization, don’t make it worse. You aren’t going to
enlighten anyone with your heroic reply. If you are concerned about
unintentionally coming off as a reply guy, you can see this thread on the
Nine Types of Reply Guy to fast-forward your social calibration.

One annoying variant is when someone posts work using a particular

framework, and you ask why they don’t use your favorite framework.
Just don’t. Instead, do the work of translating it to your framework,
and they will happily send people your way when they ask (they
always ask).

Don’t share secrets. You will gain access to more and more privileged
information as you grow in your career and network. This is beneficial to
 you, but nobody’s going to tell you anything if you just blab it out to show
how cool you are. Of course, telling company secrets is a fireable offence.
Don’t police others’ Twitter behavior. They have a right to use Twitter
differently from you. If you find yourself getting upset over a like or
retweet or follow or unfollow, you may be getting too caught up in Twitter
drama. We tend to judge ourselves based on our intentions, but judge others
based on their action. Because Twitter is a cold medium, we even judge
inaction, despite clearly knowing that there are more important things in
life than Twitter.
Imagine explaining why you’re upset to a friend who doesn’t use Twitter. If
all you get is bemused sympathy, you may be starting to lose a grip on
things that actually matter. Let it go. Respect people’s right to disagree. Of
course, genuinely reprehensible behavior with deserved real world
consequence does happen on Twitter too. It’s a fine line to draw and
nobody does it well. Just remember that there is a line, and Twitter has no
built-in mechanism to tell you when you’ve crossed it. Meta-outrage will
happily consume your life and mental health if you let it.

Yes, it is ironic giving advice that you shouldn’t tell others how to
use Twitter, in a chapter meant to tell others how to use Twitter.
Unfortunately, this rule is recursive – people who police others’
Twitter behavior don’t appreciate being told not to police others’
Twitter behavior. Therefore, I don’t. Feel free to ignore
everything here – it’s your life, your rules.

Don’t use excessive hashtags. Self-styled “SEO experts” might tell you to
throw on a bunch of hashtags to “increase discoverability” or something.
No serious Twitter user actually does that. We can Smell Corporate a mile
away. Keep hashtags to a max of three in your bio, and up to two in your
tweets. Ironic usage is, of course, allowed. But be funny or Poe’s law will
strike.

As you proceed, you will figure out your own rules for what you don’t do on
Twitter. I personally use “dinner table rules” - I avoid discussing politics,
religion, climate change, medical conditions, and other non-finance-or-dev-or-
career-related topics (I make some exceptions for cat pictures and good music).
I also refrain from unconstructive industry debates:

Should you deploy on Fridays?

Should you work nights and weekends to be successful?
Do degrees matter?
Should algorithms/data structures be part of interviews?
Should managers code?
Do 10x engineers exist?
What font is that? What theme is that? What toilet paper do you use?
Tabs vs Spaces, vim vs emacs?

For others, those topics are a key part of their identity and they have as much
right to discuss them as you do to ignore, unfollow, or mute.

Just remember that you have the right to free speech, but that right doesn’t shield
you from criticism or consequences.

38.10 Final thoughts

This chapter can seem like an overwhelming amount of do’s and don’ts for
something that is ultimately specific to your personality and career stage. I
absolutely agree. Just get started and figure things out as you go. I offered as
many tips as possible because of how helpful Twitter can be to your professional
career and network.

Everyone’s approach to Twitter is going to differ based on personal preference

and productivity beliefs. But the “macros” of your Twitter time is going to come
back to those three things: Input, Interaction, and Creation. Some people
believe in “write only Twitter” - purely using Twitter as a microblogging
platform for publication. But people can tell when you don’t reciprocate
engagement and treat Twitter as a one-way street. Some others read too much,
hooked on the randomness and dopamine hit of memes and serendipity. An even
balance of 1/3 of time on each is a good starting point.
As you get more advanced in your usage, there are generalist guides to Twitter
you can lean on. Two well known guides you should check out are The
Holloway Guide to Using Twitter and Daniel Vassallo’s Everyone Can Build a
Twitter Audience.

Support other people. Avoid toxicity. Strive for “Yes, and…”, instead of “Well,
actually…”. Your experience of Twitter will be best when you try to win hearts
instead of change minds.

And be patient - you are building a network that will be with you an entire
career, and maybe lifetime. Your Twitter relationships will probably outlast
any job. Invest accordingly.
Chapter 39
Marketing Yourself (without Being
a Celebrity)

39.1 When to Use This Tactic

Ideally you are constantly marketing yourself, but it’s understandable if you
don’t want it to take over your whole life. So: pull up this tactic when:

You have done something significant that you are proud of or enjoyed
Just before some major professional move or project launch (jobhunting or
getting a promotion or even when trying to pitch an idea)

For the rest of this essay I will primarily talk in terms of marketing yourself, but
the tactics here also work for marketing your ideas and your projects.

39.2 Introduction
Marketing is important for your career. This isn’t earth-shattering news:
according to a recent survey, 91% of you already agree.

But people tend to doubt their ability to market themselves well. They see “tech
celebrities,” and then they look at themselves, and they say: “I’m not like that;
when I put out a blogpost I don’t get a billion likes,” or “I don’t want to be like
them — that seems hard.”

The mistake here is equating marketing with celebrity. It’s like saying your
favorite restaurant shouldn’t bother trying because McDonald’s exists. They’re
two different (but related) things!
You are a product. You work really hard on making yourself a great product.
You owe it to yourself to spend some time on your marketing even if you don’t
want to be a “celebrity”. Like it or not, people want to put you in a box. Help
them put you in an expensive, high-sentimental-value, glittering, easy to reach
box. Preferably at eye level, near checkout, next to other nice looking boxes.

It’s not that hard to be better than 95% of devs at marketing. The simple fact is
that most devs don’t do the basic things that people tell them to do. I think this
has two causes:

It’s not code. Code is black and white. Marketing is shades of gray.
A lot of advice is very generic. “Blog more”. Devs often need more help
transpiling this to actionable instructions.

Let me try.

39.3 You Already Know What Good

Personal Marketing Is
You may not feel confident in practicing good marketing, but you should realize
you are being marketed at ALL. THE. TIME. Therefore you can be a world
class expert in marketing that resonates with you. That’s the kind of personal
marketing that you can practice - not that other scammy, sleazy, invasive,
privacy destroying kind.

You’ve almost certainly already benefited from good marketing — by finding

out about something from someone somewhere, that registered a hook in your
mind, that eventually drove you to check it out, and now you cannot function
without it.

And you certainly want to benefit in the other direction: you want to be that
thing that others find out about from someone somewhere. You want to register
hooks in people’s minds. You want to drive people to check you out. And you
want people to prioritize working with you.
One constraint you have (one that other marketers wish they had) is that you
don’t have to market to the whole world. You can target the specific
audiences you want to work for, and no more than that. As long as you are well-
known in those circles, you don’t need a public presence at all. Your conversion
rate will be higher, and your stress probably lower (as will be your luck surface
area).

39.4 Personal Branding

The topic of marketing yourself is pretty tightly intertwined with personal
branding. If you’re like me, you’ve never really thought about the difference
until right now.

Think of yourself as a plain, unmarked can of soda. You’ve got awesome fizz
inside. Branding would slap a distinctive logo and colors on the can. Marketing
would then be responsible for getting you, the freshly minted can of Coca Cola,
at the top of people’s minds.

Branding is the stuff that uniquely identifies you. Marketing gets your
awesome in front of people.

Of course, it helps marketing to have strong branding. This is why they are
correlated. In fact, the strongest branding creates its own market. You don’t
want a laptop, you want a Macbook. You don’t want an electric vehicle, you
want a Tesla. You don’t want sneakers, you want Air Jordans. You can probably
come up with more examples.

It’s really easy to sell to a market in which you are the only seller. Shooting fish
in a barrel you made. Nobody can compete with you at being you.

The other wonderful feature of personal branding is that it is entirely up to you

to create stuff that uniquely identifies you. There’s no store somewhere where
you can pick a brand off the shelf and put it on like a new coat. You create it
from thin air, with the full dimensionality of all that human diversity has to
offer. Seven billion humans on Earth doesn’t even come close to exhausting the
possible space of unique selling points you can pick.
39.4.1 Picking a Personal Brand

Your personal brand is how people talk about you when you’re not in the room.

So naturally, one way to start picking a brand is to listen to what people have
naturally chosen for you.

Caution: you may not like what you hear! That’s OK! That’s what we’re trying
to fix.

39.4.2 Personal Anecdote Time!

If you can get a friend to tell it to you straight, good. If you can get some people
on a podcast talking about you without you there, good.

Or, like me, you can accidentally eavesdrop on a conversation. I swear I did this
unintentionally!

The first time I found out I had established an incredibly strong personal brand
was when I was at a house party with 20 friends and friends of friends. While in
a small group, I overheard someone behind me talking about me. They
introduced me as “that guy that preaches Learn in Public”. Then, at a later hour,
I heard another person introduce me without me there. Then, again, when
joining a new group, a third person introduced me the exact same way.

I don’t consider myself a personal branding expert. But I understood instantly

that I had pulled off a very important feat. I had written so much about a topic
that multiple people instantly associated me with that topic. It’s not critical that
they say it in the exact same way (actually that can be a bit creepy/culty) but it’s
good enough if they use the same terms.

39.4.3 Anything But Average

There are other aspects of my personal brand that don’t get as much attention,
but I bring them up front and center when relevant. I changed careers at 30. I
used to be in finance. I served as a combat engineer in the Army. I am from
Singapore. I speak Mandarin. I’ve written production Haskell code. I sing a
capella. I am a humongous Terry Pratchett fan (GNU Terry Pratchett). I love
Svelte and React and TypeScript. I am passionate about Frontend/CLI tooling
and developer experience. I listen to way too many podcasts. The list goes on.

But I have this list down cold. I know exactly which parts of me spark interest
and conversation without going too off track. Therefore I can sustain interest
and conversation longer, and in exchange, people know when to call on me. You
should keep a list too — know your strengths and unfair advantages.

What I do NOT consider my personal brand is the stuff that doesn’t differentiate
me at all. For example, when asked about my hobbies, I deflect extremely
quickly. I identify as a “Basic Bro”: I have my PS4, and Nintendo Switch, I like
Marvel movies and watch the same Netflix shows you watch. Just like the
million other Basic Bros like me.

Totally basic. Totally boring. NOT a personal brand.

In fact anything not “average” is a good candidate for inclusion. In particular:

Diversity is strength. Adversity is strength. Weakness is strength. Nothing is off
limits - the only requirements are that you be comfortable self identifying with
your personal brand, AND that it evokes positive emotions as a result.

I’m serious about that second part - You don’t want trolling or outrage or cruel
sarcasm to be your brand, nor do you want to bum people out all the time.
Instead, entertain, educate, inspire, motivate.

39.4.4 Brand Templates

What I did accidentally, you can do intentionally.

A nice formula for a personal brand is Identity + Opinions. A personal

brand based solely on who you are, doesn’t really communicate what you’re
about. A personal brand based solely on what you do is quite… impersonal.
People like knowing a bit of both, and you can give it to them in a few short
words. Some ideas:

“I’m a former public school teacher and I think the way we teach people to
code can be greatly improved.”
 “I was an actual architect and we’re doing software architecture all wrong.”
“I did my graduate thesis on static analysis and I see a new generation of
tools that make developers faster and less frustrated.”

I really want to give you more hints on this, but I’m afraid if I gave more
examples I might limit your imagination. Don’t even take this formula as a
given. It’s just one template – Another template is “X for Y”: “<what you
do> for <who you do it for>”. “I create gorgeous, accessible frontends
for DTC ecommerce brands” is a highly marketable oneliner pitch. “I create
backends that scale to millions of peak concurrent users for live streaming
apps.” And so on. This is a more business oriented template that puts the target
audience/customer squarely in focus.

The point is, being able to pitch yourself (and why people should care) in a
short, consistent way is a powerful weapon in your marketing arsenal. You can
choose to think about this rather than improvise.

39.4.5 Brand Manifestation

Once you know what you’re about and have nailed down your brand, it’s time to
plaster it all over. You know how Nike pays athletes millions of dollars just to
wear stuff with their logo on it? That’s what you’re going to do with everything
you touch. Top brand consultants ask: “What are the best ways to connect your
values and unique value proposition to your site?” You should do that with your
portfolio, blog, Twitter, resume, and work output.

Manifest your brand. You don’t have to stay digital. In fact, in a digital-first
world, going physical sticks out. If your product gives people peace of mind,
you might fill your office with aromatic candles and hand them out as gifts (this
is not hypothetical; this has been done). Shirley Wu is a data visualization
consultant; she printed out her data visualizations as her business cards and
hands them out at conferences. You BET they return 1000x their marketing
expense in memorability and virality.

Be remarkable. Seth Godin (you’re going to hear his name a lot in marketing,
think about why) calls this having a Purple Cow. Design Pickle, a design
agency, picked a unique name, and literally dress up in pickle suits and hand
out pickles at conferences, which gets them notoriety and business. To manifest
their brand, they lean hard into it, and see great success while having a lot of
fun, because their brand is authentic and consistent all the way through from
their name down to their swag.

39.4.6 Consistency

Humans love consistency. Developers REALLLLY love consistency.

Here’s an idea of how much humans love consistency. We often want people
who are famous for doing a thing, to come on to OUR stage, and do the thing.
Then they do the thing, and we cheer! Simple as that. There’s so much chaos in
the world and having some cultural touchstones that never change is comfort and
nostalgia and joy bundled up into one. Here’s Seth McFarlane being prodded to
do the voice of Kermit the Frog and Stewie from Family Guy - something he’s
done a billion times on a billion talk shows - but he does it anyway and we love
it anyway. We LOVE when people Do the Thing!

Similarly, when we market ourselves, we should be consistent. People love

seeing the same names and faces pop up again (caveat: you should mainly be
associated with positive vibes when you do this).

I recommend taking consistency to an extreme level. We used to do this

offline with business cards. Online, our profiles have become not only our
business cards, but also our faces. The majority of people who see you online
will never see you in person. In most platforms, your profile photo is “read”
before your username. Your username is in turn read before your message. Your
message is read more than any link you drop. And so on. Therefore I strongly
recommend:

Photo. Take a good photo and use the same photo everywhere. A
professional photographer is worth it, but even better can be something with
a good story, or an impressive venue. If possible, try to show your real
face, and try to smile. This already puts you ahead of 50% of users who
don’t understand the value of this.
Photos are seen before usernames. Examples here and here.
 Companies spend millions on their logos. So why shouldn’t you spend
some time on yours? We are irrationally focused on faces, and we really
like it when people smile at us. Thankfully, because it’s just a photo, it
costs us nothing to smile at everybody all the time. It’s a really easy way to
associate your face with positive emotions. And when we see you pop up
on multiple different platforms with the same smiling face, we light up!
The emotion completely transfers, and the branding is nonverbal but
immediate.
Real Name. Show your real, professional name if possible, unless your
username is your working name. This works especially well in anonymous
platforms like Reddit and Hacker News, because you are taking an
additional step of de-anonymizing yourself. People respect this.
Username. Your username should be your name if possible (so people can
guess it), or failing which, something you intimately identify with. You
should probably have the same one on most platforms, so that people can
find you/tag you easily. Some, like myself, will simply use their usernames
as their working names for ever. This can be a branding opportunity as
well, similar to the way musicians adopt mononyms and fighter pilots adopt
callsigns.
Words. You should consistently associate yourself with a small set of
words. Where a bio is allowed, you should have those words prominently
displayed. For example, it doesn’t take a lot to show up whenever SVG
Animation or React and TypeScript are mentioned. You can set Google
Alerts or Tweetdeck filters for this, and before long you’ll just get
associated with those terms. When you have your own words, like a
catchphrase or motto, and it catches on, that is yet another level of personal
branding.

You will have made it when people start making fun of you. I’m not 100%
serious, but I’m at least a little bit serious: Can people make memes of you, and
others instantly get it? If so, you’ve got a personal brand.

All this personal branding will be 10x more effective when you have a Domain.

39.5 You Need a Domain

You need a domain.

I mean this in both senses of the word:

1. Set up a site at yourname.com that has all your best work

2. Pick a field that you are About.

The first just makes sense - instead of putting all your work on a platform
somebody else owns, like Twitter, YouTube, LinkedIn, or another industry blog,
have it primarily discoverable on your own site/blog. This builds your site as a
destination and lets you fully control your presentation and narrative — even
off-site, on Google.

Having a distinctive site design is yet another point of personal branding that,
because you are a dev, costs basically nothing. People come to my site and they
remember my scrollbars.

Just understand that your domain and your website are the center of
your identity, so ideally you’d have a good domain that will last a
literal lifetime. - Daniel Miessler

But the second meaning deserves more introspection: I am asking you to plant
your flag. Put up your personal bat signal.

39.5.1 Planting Your Flag

I used to have a very crude, kinda sexist name for this idea: “Be the Guy.” This
is because I noticed how many people were doing this:

The Points Guy is the Internet’s pre-eminent authority on travel perks (now
a 9-figure business)
The RideShare Guy blogged about Ride Sharing for 4 years, and became
the guy Wall Street called upon when Uber and Lyft IPO’d
Science communicators have definitely caught on to this. Neil deGrasse
Tyson always introduces himself as your Personal Astrophysicist. But he’s
 completely owned by Bill Nye, the Science Guy!

If you skim over “the guy” as a gender-neutral shorthand, the actual important
thing about having “a guy” is that you look better just by “knowing a guy”.
Listen to Barney Stinson brag in “How I Met Your Mother”:

You know how I got a guy for everything?… My suit guy, my shoe
guy, my ticket guy, my club guy, and if I don’t have a guy for
something I have a guy guy to get me a guy!

This effect is real and it is extraordinarily powerful.

Just by “having a guy” for something, you suddenly feel no desire to overlap
with that person’s domain. You can now focus on something else. And, to the
extent you do that, you are now utterly dependent on “having a guy”. You’re
also extremely invested in your “guy” (aka go-to person – the gender is not
important) being as successful and prominent as possible, so that you look better
by association.

It should strike you now that being someone’s go-to person is very valuable, and
that this also scales pretty much infinitely (you can be as many people’s go-to
person as you want, so long as they rarely actually call on you).

You get there by planting a flag on your domain, and saying, “this is what I do”
(a framing I stole from an excellent Patrick McKenzie keynote). People want
expertise. People want to defer to authority. People don’t actually need it all the
time, they just want the option just in case. People love hoarding options. You
can satiate that latent insecurity indefinitely. Most people also define “expertise”
simply as “someone who has spent more time on a thing than I have” (The bar is
depressingly low, to be honest. People should have higher standards, but they
just don’t. This is a systematic weakness you can – responsibly – exploit.)

39.5.2 Picking A Domain

 BTW, are you chafing for career advancement, or want to be seen as a
leader by your peers? My stock advice is, find an area that is
important but under-owned and become everyone’s go-to expert on
that topic. - Charity Majors

You don’t need to get too creative with this one. You want to connect yourself to
something important:

Maybe something people deal with daily but don’t really think about too
much (especially if they know they are leaving something on the table, like
airline points — it’s easy to make money by helping people unlock free
money).
Maybe something people only deal with once in a blue moon, but when
they do it REALLY hurts (so you gain unfair expertise by specializing in
having repeated exposure to rare events across multiple customers).

There are a bunch of these, so to narrow them down even more, look out for
something you disproportionately love. Look for your own revealed
preferences: Search a topic in Slack or Twitter and see how often you talk about
it. Look up your own YouTube watch history. An ideal domain for you is
something that seems like work to others but is fun to you.

With everything you love, there are things to hate. Find something within what
you love, that you are ABSURDLY unsatisfied with. That love-hate tension can
fuel you for years.

For any important enough problem, there are plenty of experts. Do you feel like
you haven’t narrowed enough? Shrink your world. Be an internal expert at your
company for your domain. This also helps you focus on things that bring value
to a company, and therefore your career. It’s also a very natural onramp to being
an external expert when you leave.

39.5.3 Claiming Your Domain

Picking your domain is 90% of the journey. Most people don’t even get that far.
To really clean up, be prolific around that domain. Show up. To every
conversation. I call this “High Availability for Humans”. In the same way we
architect our systems for “High Availability”, meaning we can send everything
their way because they are very reliable and responsive, we can make ourselves
Highly Available around our chosen domain, meaning everyone can send
questions our way, because we are very reliable and responsive.

By showing up consistently, you become part of the consideration set. Humans

don’t have room for a very wide consideration set. It’s usually two or three. If
we make lists and try really hard, we can get up to 10 (see the Oscars), but even
then there’s really only two or three that have a real shot.

Think about the last time you purchased soap. You probably buy one of two
brands of soap. But there are 100 on the shelves. They just weren’t in your
consideration set, so they never had a chance.

Your goal, as a brand, is to make it into everyone’s consideration set. You do

that by being Highly Available.

By the way, we also have huge Availability Bias when it comes to recall. We
conflate “top of mind” with “being the best”.

It’s your job to be the best at what you do (and to define what that means), but
don’t stop there. It’s also entirely within your control to be considered the best,
which is what claiming your domain is all about.

39.5.4 Give Up Freedom — For Now

The flip side of planting your flag is that you shouldn’t plant it anywhere else.
People like to see commitment. It implies, and usually does mean, that you have
no choice but to be a domain expert. You signal commitment by giving up
optionality. This is 100% OK - what you lose in degrees of freedom you gain
10x in marketing ability.

Author’s note: 10x may be an understatement. Cory House saw a 15x

increase in enquiries when he went from “general dev consulting” to
 “helping teams transition to React”. Same dev, different pitch, 15x
opportunities.

The secret is — and don’t tell anyone — that if you pick a domain and it doesn’t
work out, you can still pivot if you need to. Nobody’s going to hold it against
you, as long as you don’t pivot too often.

If you really aspire toward more general prominence, you will find a much easier
time of it if you first prove yourself in a single domain.

39.5.5 Blogging

Blogging is usually mentioned prominently in the “Marketing for Developers”

space — so I feel I must address it here, despite it being only one part of the
general mindset I want you to have.

I will always encourage you to blog — but don’t fool yourself that merely
pushing a new post every month will do anything for you by itself. That’s just
motivational shit people say to get you started. There’s a lot of generic,
scattershot advice about how you should blog more. These are usually people
trying to sell you a course on blogging. (Except Steve Yegge!)

The fact is blogs gain extra power when they are focused on a domain. CSS
Tricks is a well-known blog in the frontend dev space, and, as you might guess,
for a long time it’s domain was entirely CSS tricks. (It’s expanded since then).
Like everything else you follow, it’s all about signal vs noise.

Blogs help you get more juice out of that domain name you own, by constantly
updating it with fresh content. You can also use it to feed that other valuable
online business asset: your email list! Overall, it is just a good general principle
to own your own distribution.

Twitter is a form of microblogging. It lets you export data easily and your
content shows up on Google without an auth wall. All good things. But you’re
still subject to an algorithmic feed. Social media followings are definitely not
distribution that you own — but it can be worth it to make the Faustian bargain
of growing faster on a platform (like Twitter) first, then pivoting that to your
blog/mailing list once you have some reach. Growing a blog/mailing list from
zero with no other presence is hard.

39.6 Marketing Your Business Value vs

Your Coding Skills
39.6.1 Business Value

A large genre of “Marketing for Developers” advice basically reduces you to an

abstract Business Black Box where your only role and value to the company is to
Grow Revenue or Reduce Cost (or Die Trying?). I call this “Marketing Your
Business Value”. This is, of course, technically correct: Technology is a means
to an end, and ultimately your employer has to cover costs and justify your
salary. It is especially in your interest to help them justify as high a salary as
possible.

Have at your fingertips all the relevant statistics, data, quotes, and anecdotes for
when you solved major product pain points, or contributed a major revenue
generating/cost saving feature. Julia Evans calls this a Brag Document. You
should be able to recite your big wins on demand, and frame it in terms of
What’s In It For Them, because you will probably have to. Managers and
employers are well intentioned, and want to evaluate you fairly and objectively,
but often the topic of your contributions comes up completely without warning
and out of context, and you want to put yourself on the best footing every time.

Consider this “applied personal branding” — You’ll know you’ve succeeded

when your boss is able to repeat everything you say you’ve done to her boss, to
advocate for you as full-throatedly as you should do yourself. Make that easy. If
you can, get it down to a concise elevator pitch — Patrick McKenzie is fond of
citing a friend’s business value as “wrote the backend billing code that 97% of
Google’s revenue passes through.” Enough said.

You might notice some differences between the general form of personal
branding we discussed previously, and this “applied” form of personal branding.
They are different because you have different goals. With general personal
branding, you are trying to be memorable and relatable. People want to get to
know you and people like the somewhat familiar (But not too familiar!
Familiarity breeds contempt.) With applied personal branding, you are
straightforwardly trying to sell yourself and help others sell you. Here you want
to focus on unique achievements and traits, including highlighting notable
successes.

Be just a little shameless. Nobody’s going to like fighting for you if you don’t
show any interest in fighting for yourself.

39.6.2 Coding Skills

Unfortunately, “Market Your Business Value” is not at all helpful advice for
people who have yet to make attributable business impact through their work:
Code Newbies and Junior Devs. Sometimes, even as a Senior Dev, you are still
trying to market yourself to fellow Devs. These two situations call for a different
kind of marketing that is under examined: Marketing your Coding Skills.

To do this kind of marketing, you basically have to understand the psyche of

your target audience: developers. What are they looking for?

There are explicit requirements (those bullet points that companies list on job
descriptions) and implicit requirements (subconscious biases and unnamed
requirements). You can make it very complicated if you want to, but I think at
the core developers generally care about one thing: that you Do Cool Shit.
Some have an expansive definition of coding skills - even if you’ve done
something totally unrelated, they’ll easily assume you can pick up what you
need later. Others need something closer to home - that you’ve Done Cool Shit
in a related tech stack.

If you’re marketing yourself for employment, then the risk averse will also want
to know that you have also Covered Your Bases — That, along with the upside
potential of hiring you because you’ve Done Cool Shit, the downside risk of
your being a bad hire is minimized. Do you know Git? Can you solve
FizzBuzz? Is your code readable and well documented? If you have shepherded
a nontrivial project from start to finish, and have people you can ask for
references. If instead you’re just marketing your projects and ideas, then
downside matters less — it’s easy to walk away.

The definition of Cool really depends on your taste, but people’s interests are
broadly predictable in aggregate. If you look at tech sections of popular
aggregator sites like Reddit and sort by, say, most upvoted posts in the past year,
you can see patterns in what is popular. In fact, I’ve done exactly that for
/r/reactjs!

Even if your project is less visual, and more abstract, you still need to explain to
the average programmer why your project is Cool - it solves a common/difficult
problem, or it uses a new technology, or it has desirable performance metrics.
The best Cool Shit will be stuff you have been paid money for and put in
production, and that people can go check out live. If you don’t have that yet, you
can always Clone Well Known Apps (automatically Cool) - or win a Hackathon
(check out Major League Hacking) - or Build Your Own X from Scratch, another
popular developer genre.

39.6.3 Portfolios vs Proof of Work

Usually the advice is to assemble your Cool Shit in a Portfolio. Portfolios do

two good things and two bad things:

They display your work easily and spells out the quick takeaways per piece
- you control your narrative!
They help you diversify your appeal - if one project doesn’t spark interest,
the next one might!

In this sense it is most like a Stock Portfolio — you’re diversifying

risk rather than adding upside.

They look skimpy without quantity - meaning you feel forced to Go Wide
instead of Go Deep. Quantity over Quality.
They overly bias toward flashy demos (which doesn’t really help if you’re
not focusing on Frontend Dev/Design)

You can and should buy designs if design isn’t a skill you’re trying to
market - it gives your projects an instant facelift which is generally
 worth multiples of the <$100 that a premium design typically costs.

Some people plan their projects based on how they will look on a portfolio - the
dreaded “Portfolio Driven Development.” That lacks heart, and it will show
when you talk about your projects at interviews and talks. Instead, pursue the
projects that seem most interesting to you, and then figure out how to present
them later. Your interest and enthusiasm when talking about them will go further
than padding the portfolio.

In actual practice, there is a wide variety of devs and dev careers for which
portfolios make no sense at all. Your humble author is one of them. You can
market your coding skills in any number of more relevant ways, from doing
major contributions to Open Source, to being Highly Available surrounding a
Domain, to blogging. The most general, default marketing skill is definitely
blogging. You can write about any kind of technical topic in your blog.

At the end of the day, what you really want to accomplish is to demonstrate
Proof of Work. Just like in a blockchain transaction, anyone checking you out
should be able to instantly and trivially verify that you have worked on some
very non-trivial things. When it comes to marketing in public, this is a business
card, resume, and interview all rolled into one.

39.7 Marketing Yourself in Public

The better you have a handle on your Personal Brand, your Domain, your
Business Value or your Coding Skills, the easier time you will have marketing in
public. Everything we’ve discussed up to this point is useful in public, so I’ll
just leave you with a few more pointers to consider whenever you engage and
want to promote yourself online.

Pick a Channel. The best marketing channels are the ones you’re already on.
Whatever the reason you enjoy it, you have a natural affinity for it. For me, it
was Reddit, and then Twitter. Dev communities like Dev.to are great too, as are
the ones you build on your own (aka your mailing list). Just be aware that some
platforms are less rewarding than others. For example, Facebook charges you to
reach your own subscribers, LinkedIn is full of spam, and Reddit and Hacker
News don’t show an avatar so you don’t get to imprint your personal brand. I
think Instagram and YouTube are huge areas of opportunity for developers. Just
pick one or two, and go all in. A lot of people use social media tools like Buffer
to crosspost, but I think this is misguided, because you end up underinvesting in
every platform and everyone can tell you aren’t there to engage.

Don’t Lie. Most things are taken at face value online, and this is wonderful for
getting your message out there. But if you misrepresent what you were
responsible for, or straight up fabricate something, you will eventually get found
out. We like to think that things live forever online, but I think it’s actually
easier to erase something from Google than it is to undo the reputation damage
caused by a lie. People will hold it against you for years, and you will not have a
chance to defend yourself or atone for your sins. Stephen Covey calls this the
Speed of Trust. Once you lose trust, everything you say gets run against a
suspicion check, and you have to put up more proof points to be taken seriously.
This also applies to promises of future commitment too — if you simply do what
you say you were going to do, you will stand out.

Don’t Share Secrets. You will gain more privileged information over time as
you grow in your career. This is advantageous to you, and you should do
everything you can to show you are a trustworthy guardian of that information.
People might flatter you to get that information, or offer an information swap.
But the only way to encourage more information flow to you is to show that you
can keep a secret. If it helps, I’ve started by flatly saying “That’s not my info to
discuss” and people usually get the hint.

I always think about Christopher Lee, who fought in the British

Special Forces in World War II before his legendary acting career.
When pried for information about what he did in the war, he would
say: “Can you keep a secret? Well, so can I.”

Inbound vs Outbound Personal Marketing. I borrowed this idea from

Hubspot’s Inbound marketing and Seth Godin’s Permission marketing.
Outbound Personal Marketing is what most people do when they look for
jobs. They only do it when they need to, trawling through reams of job listings
and putting their CV in the pile with everyone else’s. Inbound Personal
Marketing is what you’ll end up doing if you do everything here right: people
(prospective bosses and coworkers, not recruiters) will know your work and your
interests, and will hit you up on exactly the things you love to do.

Market Like Nobody’s Watching. Because probably nobody is, when you’re
just starting out. It’s OK: this is your time to experiment, screw up, find your
voice. Because marketing yourself doesn’t ordinarily fall within normal comfort
zones, you should try to do a little more than you’re comfortable with. An
aggressive form of this advice? If you’re not getting complaints about how
you’re showing up everywhere, you’re not doing it enough. This advice makes
sense to some people, and is way too upfront and annoying for others. We each
have to find our own balance — it’s your name on the line after all.

Market Like One Person’s Watching. Marketing is more effective when it is

targeted at a specific someone instead of just everyone. Customize your message
to an audience that you choose. People often don’t know what they want or why
they care, so focus on what’s in it for them, and tell them why they care. Quote
their prior selves if possible.

Market for the Job You Want. This is a variant of “Careful what you wish
for… you just might get it.” You’ll probably end up getting what you market
yourself for… so make sure it’s something you want!

39.8 Marketing Yourself at Work

It’s both easier and harder to market yourself at work. It’s easier, because it’s a
smaller pond, and your coworkers have no choice but to listen to you. It’s
harder, because while you have people’s attention, abuse will not be tolerated.

If you are obnoxious online, people can mute you and carry on with their lives.
If you are obnoxious at work, it can backfire pretty directly on you. In particular
- always share credit where it’s due and never take credit for something that
wasn’t yours. Of course this applies in public too, but enough people do it at
work that I feel the need to remind you.
Basics aside, you would probably agree that it’s important to ensure you get
visibility for the work that you have done. Here are some ideas:

Log your own metrics for significant projects. Before-after latencies.

Increase in signups. Reduced cloud spend. Uptime improvement.
Increased session time. I’m sure your company has an expensive,
comprehensive and well instrumented metrics logging system (this is a joke
- one does not exist). Don’t trust it. It will fail you when you need it most,
or be unable to tell the story you want told. Hand collect metrics, links,
press coverage. Take screenshots. Collect qualitative anecdotes, quotes,
shoutouts. The best time to do this is right after you see a good result - you
won’t have time to go back for it. Stick it in a special place somewhere for
a special occasion - like, say, a performance review. If you use Slack, it can
be helpful to make your own Slack channel and Slack yourself your own
notable achievements. This gives you a nice chronological log of work.
Awesome Status Updates. Status Updates are a humdrum routine at most
workplaces. Most people put no effort into them. You can buck the trend
by making them awesome with just a little more effort. I’ve seen this “flip
the bits” in team morale – after seeing just one person do this, people
realize they can either continue being boring or join in the effort to do the
best work of their lives.
Unprompted Status Updates. Sometimes a project is disorganized enough
that there aren’t even regular updates scheduled. Management probably
vaguely knows what is going on, but is too busy to ask for more. You can
fill the leadership vacuum simply by doing your own regular status
updates.
Do Demos. Offer to do them every time. This is an internal marketing
opportunity that people regularly turn down because of the stress of public
speaking or because it’s more work. You don’t even have to wait for an
assigned time for demos — since many workplaces are now at least
partially remote and asynchronous, you can simply put up a short recording
of your own demo! Good demos will spread virally — and so will you.
Caveat: make sure you have the stakeholder approvals you need before you
do this; don’t demo work that isn’t ready for prime time.
Signature Initiative. I stole this idea from Amazon, but I’m sure other
workplaces have terms for this. Basically, something that you do on the
side at work, that sidesteps the usual org chart and showcases your abilities
 and ideas. After pitching the idea unsuccessfully for two years, Zack
Argyle convinced Pinterest’s CEO to turn Pinterest into a PWA based on a
Hackathon project. This had tremendous business impact and probably
made his subsequent career. That’s a very high bar, but don’t worry, your
contributions don’t have to be that directly product related. Simpler
initiatives I’ve seen might be to find opportunities to share your interests
with fellow devs. Start an internal book club. A lunch and learn series. If
leaders at Google and Etsy started an external talk series, why can’t you?
Matthew Gerstman started a JavaScript Guild at Dropbox, and created a
newsletter, forum, and event for hundreds of his fellow engineers to
improve their craft. This is wonderful! I did something similar at Two
Sigma, and when I left, my coworkers said they would genuinely miss my
sharing and discussions.

For more ideas on becoming indispensable at work, check out Seth Godin’s
Linchpin. You can find a decent summary here.

39.9 Things That DO NOT MATTER

Appealing to Everybody.
Short-term Optimizations.

Day of the week and time of day that you post

Short term analytics (e.g. weekly traffic)
It’s not really that they don’t matter, it’s just that you should be
working on more evergreen things that make short term nonsense
irrelevant.

Being a Celebrity.

Better to be rich and unknown than poor and famous. If you can build
a successful tech career without being a celebrity, then absolutely do
that — unless you just crave the attention.
I haven’t mentioned followers once in this entire essay. You can buy
followers and everyone can tell. It looks sad.
 Building real relationships with peers and mentors you respect is way
more fulfilling than raw numerical mass appeal.

39.10 Recap
That was a LOT of high level marketing concepts. Do take a while to digest
them. The last section is going to be a grab bag of tactical ideas for marketing
yourself - after you get the important details in place.

To recap:

Assemble your Personal Brand, your Domain, and your Coding Skills/Business
Value, then Market Yourself in Public + at Work.
As Troy Hunt often notes in his career advice, good personal marketing is your
Plan B. If you only start doing it when you need it, it will be too late. Take the
time to work on it while the stakes are low, and you’ll be much better at it when
the stakes are high.

39.11 Bonus: Marketing Hacks

Here’s a list of “hacks” that can get you quick wins with Marketing Yourself.
Try them out and let me know how it goes!

Help Others Market. This is so simple as to feel “dumb” even pointing it

out, but it works. You want practice in marketing, but don’t want to take
the full plunge yourself, or don’t feel like you have something to offer yet.
You can find others who are brilliant but uninterested in marketing, and
offer free marketing help! Here’s Dan Abramov:

I’m pretty good at making demos, but I’m not very good at
original ideas, so what I try to do is find smart people with really
good ideas who are struggling to explain those ideas and why
those ideas matter, and I popularize them because those ideas
deserve that. And I think people respond to that. And you
remember who you learn from.

Market the same thing three different ways. A great exercise to hone
your marketing skills is to interpret the same thing three different ways.
During a prior job I was forced to queue up tweets for the same blogpost
multiple times, but because of Twitter rules I wasn’t allowed to repeat
myself. I used to dread it, but then reframed it when I realized that this was
a great exercise in figuring out how to market the same thing to different
audiences. You can do this with your own personal brand, too. You’re a
multidimensional person — if there is some part of you that connects better
with your audience in context, use that! I recommend Leil Lowndes’ How
to Talk To Anyone for great tips on this.
Crosspost on Industry Blogs. A nice way to get attention for your work is
to do great work on someone else’s platform. Industry blogs (and
newsletters) are pretty much always looking for quality content. For
Frontend Dev, the ones with rigorous editing are CSS Tricks, Smashing
Magazine, and A List Apart. For Backend, you can try Twilio, Digital
Ocean, or Linode’s blogs.

See more tips in Write, A Lot (Chapter 18)

Collaborations. Related to crossposting and helping others — you can
raise your profile by working with others who already have very high
profiles. Justin Mares bootstrapped his own profile by coauthoring a book
with Gabe Weinberg, Founder of DuckDuckGo. Same for Blake Masters
with Peter Thiel. Ben Casnocha with Reid Hoffman. If you can work out a
non-exploitative deal where you do a bunch of legwork but learn a lot, and
then copublish with the author, take it. That’s a rare deal; most often you
will just be Picking Up What They Put Down and working your way
toward becoming a peer the slow way. If they have a meetup, forum,
podcast, or whatever platform, show up on theirs, and then get them to
show up on yours.
Industry Awards. Some people set a lot of store by awards and
certifications. Well regarded programs include Microsoft MVP, Google
GDE, AWS Heroes. As a pure signaling mechanism, certifications work
like anything else works — an unhappy mix of credible, gamified, and
incomplete. But having a bunch of logos on your site/slides generally helps
you, so long as they are not your biggest claim to fame.
Memorable words/catch phrase/motto. This is used by companies and
reality stars alike, and can be a bit tacky if you try to, well, make fetch
happen, but if you strike a nerve and capture the zeitgeist you can really
carry your message far. Nike spends billions to make sure that every time
you think of the words “Just Do It,” they come up. You can do that too.
Friendcatchers. Make them.
Visualize your work. If you draw, you can be WORLD BEATING at
marketing. Draw everything you can. Even the invisible stuff.
ESPECIALLY the invisible stuff.

If you say you cannot draw, that’s a lie. Use Excalidraw.

Elevator Pitch. In the old days, you prepared pitch literally for when you
ran into the decisionmaker on a 30-second elevator ride. A typical template
goes something like “if you’re a <role> who <point of view>, I/my
thing <what it does> in <some eyepopping metric>”. In this
day of both TikTok and podcasts, attention spans are both shorter and
longer than that. You need to tailor your elevator pitch accordingly. Be
able to sell yourself/your idea/your project in:
 1 hour
15 minutes
5 minutes
30 seconds
280 characters (a tweet)
(stretch goal) 2 words

Summarize the top three books in your field for your blog. This idea is
often attributed to Tim Ferriss, but I’m sure multiple people have come up
with it. The idea is that you don’t have to be original to have a great blog:
it’s easy to bootstrap your web presence — and your own expertise — by
covering existing ground. If you do it very well you can rise to prominence
for that reason alone: Shane Parrish and Mike Dariano built Farnam Street
and The Waiter’s Pad purely off summaries. Then practice marketing your
summaries by syndicating them on Twitter. Make talks out of them at work
and on YouTube.

Further Reading:

flawless app’s Marketing for Engineers repo - a hand-picked collection of

resources for solving practical marketing tasks, like finding beta testers,
growing first user base, advertising project without a budget, and scaling
marketing activities for building constant revenue streams.
Chapter 40
The Operating System of You
Human “hardware” doesn’t differ by much. We have mostly the same bodies.
We consume and exert the same amount of energy. 70% of us have IQ’s between
85-115. Just a 30-point difference.

Therefore the spectacular variations in human performance we observe must be

due to the “software” we run.

Here’s the kicker: software can be upgraded.

Human beings are works in progress that mistakenly think they are
finished. - Dan Gilbert

40.1 Your “Applications”

Throughout this book, I have endeavored to give you the knowledge you need to
succeed, but I have intentionally structured it in a nonlinear fashion. The idea is
that throughout your 4-8 year early dev career, you will be able to revisit
different parts of this book as they become relevant.

In other words, I have installed 35 new applications into your memory that you
can boot up and run on demand. I really hope you use them well.

Tactics are like utilities. You pull them up for a quick reference when you need
them, drop them again when you are done.

Strategies are like big apps. You will almost constantly run them and all your
data is in them, so you take your time to choose. Slack or Discord? Notion or
OneNote? Figma or Sketch? Visual Studio or IntelliJ?

Principles are like daemons (or services, which is Windows’ much less
interesting word for the same thing). You should always have them on. They
protect you from malware, they prompt you to take action, they help you handle
the thousands of inbound decisions and choices that you make every day.

If you find any bugs in these apps, send a bug report to me!

But what about your underlying operating system itself? Who is taking care of
that? That’s where your underlying Habits come in. If your Principles,
Strategies and Tactics operate at the conscious level, then your Habits work on
your subconscious.
40.2 Coding Career Habits

I’m not a great programmer; I’m just a good programmer with great
habits. - Kent Beck
Because your habits are automatic, and regular, they have tremendous
compounding power, both good and bad. The authorities on this are James
Clear’s Atomic Habits, Charles Duhigg’s The Power of Habit, and Stephen
Covey’s 7 Habits of Highly Effective People - they offer more detail than I can
do justice to here, so I recommend you read them.

Your outcomes are a lagging measure of your habits. Your net

worth is a lagging measure of your financial habits. Your weight is a
lagging measure of your eating habits. Your knowledge is a lagging
measure of your learning habits. Your clutter is a lagging measure of
your cleaning habits. You get what you repeat. - James Clear

However, it is possible to stretch our “Operating Systems” analogy further. We

can think about how we can take the concrete concepts we have learned from
half a century of programming operating systems, and apply them to the rather
fuzzier goal of running our careers and lives.

40.2.1 Your “Firmware”

The first category of habit to get control of are the habits that directly operate
your “hardware”: Your physical and mental health. Family, faith, hobbies,
fitness, sleep. If these habits aren’t maintained well, they can cause a hard-to-
diagnose system failure in yourself.

Sleep is important, not least because we spend a third of each day doing it. You
should know Why We Sleep.

Sleep produces complex neurochemical baths that improve our brains

in various ways. And it “restocks the armory of our immune system,
helping fight malignancy, preventing infection, and warding off all
manner of sickness.” In other words, sleep greatly enhances our
evolutionary fitness—just in ways we can’t see. - Bill Gates
Don’t forget to sweat your ergonomics too. Consider this basic 4 step checklist
from Pieter Levels:

Is your screen at arm length away from you?

Is the top of your screen at the same level as your eyes?
Is your elbow in a 90° rectangular angle on the table?
Are your feet on the ground?

As Scott Hanselman says:

Take care of yourself. This job can destroy your hands, back,
shoulders. Walk, talk, stand, squat, whatever. Your hands and back
and brain are your money. Treat them right now and they’ll last you
30-50 years.

Repetitive Strain Injury can end your coding career unexpectedly. It doesn’t feel
serious at first, but accumulated damage over years can be too late to reverse
when it starts getting serious. Check my compilation of RSI resources for more.

40.2.2 Your “External Devices”

The second kind of Habit handles all your interactions with everything directly
connected to you that isn’t actually you. There are many such angles to consider,
but I will pick out Storage, Networking, and Virtualization as examples.

Modern CPU’s have a series of caches, from L1 to RAM. The further away you
go, the slower the speed of recall. This is loosely analogous to the human
Forgetting Curve. But for true, persistent, durable storage, we need to store our
information on hard disks. For humans, the most efficient form of this is
writing. Therefore the habit of writing a lot helps you increase the bandwidth of
everything you communicate to your future self and the outside world. This
seems costly in terms of times, but remember that the speed of most algorithms
are drastically improved with just a little bit of memoization and judiciously
stored data structures. Even context switching becomes a lot cheaper!
Your current brain is good, but see what happens when you build a “Second
Brain” that does everything your first is bad at!

Computers got a lot more interesting once they started talking to other
computers. In fact, there’s a rule for just how much more interesting: Metcalfe’s
Law says the value of your network grows quadratically! This is why you are
well served spending time building your network, including outside of your
current company. Whatever you choose, whether open sourcing your
knowledge, speaking at conferences, or marketing yourself, will help.

Learning in Public is so powerful precisely because it lets you do both Storage

and Networking at the same time, with a built-in infinite feedback loop.

Finally, many apps are better easier run inside virtualized containers, where a
constrained environment helps provide better reliability and scalability. In the
same way, you can make your environment conducive to your productivity.
Use an applied understanding of psychology to turn yourself Indistractable,
offering some process isolation from the diversions of our modern Attention
Economy. Don’t overcomplicate your work rituals – start with simple tricks like
the Pomodoro Technique and work your way up. Learn the impacts of your
work environment on your own productivity and satisfaction. Remote workers
universally report much better productivity when they have a clear separation
between where they work and where they sleep. Don’t run “work apps” in your
“home container” and don’t intermix personal affairs with work!

40.2.3 Your “Scheduler”

The third category of Habit concerns your scheduler (also known as a process
manager). Does it drop tasks? Does it prioritize low priority tasks over high
priority ones? Is it bad at task switching or terminating clearly stalled apps? If
so, it may be buggy. Get control of your schedule. Create a single source of
truth (per category), put everything in it, and make time for things that matter.

If you feel constant background anxiety and need a more prescriptive

guide, the classic text on handling this is Getting Things Done. If that
goes too far and you want something more relatable to developers, see
 Marc Andreesen’s Guide to Personal Productivity (balance it with his
2020 update).

To tell if things matter, defer execution as much as possible: Say “No” more to
your impulses and other people’s requests. Just like you would want any API
to behave, rejecting tasks is better than accepting and never doing them.
Knowing how to say No well Sparks Joy.

Remember our biases in the Eisenhower Matrix - we often neglect the Not
Urgent yet Important things for the Urgent yet Not Important ones:

Almost every endeavor of lasting, long term value is Not Urgent, yet Important.
If time is more valuable than money, then the skill of making time is more
valuable than the skill of making money. Learn to make time.

Strategy matters. Make time for the big strategic decisions in your life. Time
is uneven – Some years will pass like days, but some days will feel like years.
You can’t control when your big career breaks will happen, but you can
periodically step back to reassess the big picture, everything from Business
Strategy to industry Megatrends to how you are progressing on Career
Ladders. Luck will favor the prepared mind.

When you do work also matters. Your focus and energy do not stay constant at
all times of the day. The science of chronotypes has found widespread
acceptance and it is worth figuring out which you are. This will help you batch
focused work to times when your mental acuity is high, and leave administrative
chores to afternoon lulls. The best discussion of this I’ve come across is Dan
Pink’s When: The Scientific Secrets of Perfect Timing.

The idea of optimal batching doesn’t just apply to diurnal rhythms, it also
applies to the work week. For example, Sarah Drasner dedicates the start of her
week to meetings, and blocks out large chunks toward the end of the week for
uninterrupted coding. Paul Graham’s term for this is Maker’s Schedule,
Manager’s Schedule – if you have to do both, try to alternate between modes
rather than constantly intermix them. The road to burnout is paved with context
switching.

40.2.4 Your “Kernel”

The last kind of Habit is one I cannot articulate for you. You’ll have to find it
within yourself. It has many names:

Purpose
Vision
Mission
Calling
Intrinsic motivation

But I like the word Drive. Lose it, and you will eventually burn out. Keep your
drive alive. In Dan Pink’s book on the topic, he notes:
 As children, we are driven by our inner desires to learn, to discover
and to help others. But as we grow, we are programmed by our
society to need extrinsic motivations: if we take out the trash, study
hard, and work tirelessly, we will be rewarded with friendly praise,
high grades, and good paychecks. Slowly, we lose more and more of
our intrinsic motivation. Extrinsic promises destroy intrinsic
motivation.

If you were an operating system, this is your equivalent of pid 0. The “system
process” that makes your whole system run. It’s the process that runs all the
other processes. Except instead of calling it a process, we might call it a
principle. When you lack direction, when you have nothing else to do, when you
have too much to do, or when everything is going horribly wrong, this is the one
principle you fall back onto. We covered some in this book, but there are many
more that could work for you. Pick one, internalize it, make it your guiding
light, pass it on to others.

It took me >30 years to find mine, but you can have it too: Lifelong learning in
public.

“The worst thing you can ever do is think that you know enough.
Never stop learning. Ever.” - Arnold Schwarzenegger

40.2.5 Recap

I am not the first to make the analogy of humans to computers – it makes sense
that the same algorithms we use to maximize performance of our machines, are
probably also great Algorithms to Live By. But for our context, we just focused
on four categories of habits:

Firmware: Mental and Physical Health

External Devices: Writing, Networking, and Environment
Scheduler: Prioritization and Scheduling
 Kernel: Drive

Nobody is perfect at any of this – so don’t expect this of yourself. But every
little bit you can do to improve your baseline habits helps. You can backslide on
any given day, week, month, or year. It’s fine – just get back on the horse.

Every action you take is a vote for the type of person you wish to
become. No single instance will transform your beliefs, but as the
votes build up, so does the evidence of your identity. This is why
habits are crucial. They cast repeated votes for being a type of person.
- James Clear

40.3 The Emotional Journey of your

Coding Career
The ultimate “health check” for your “operating system” is how you feel. Your
emotions and mental health. We haven’t talked much about it in this book, but
how you feel is valid and it matters. It’s OK to take mental health days off
work, and it’s OK to talk about your feelings and ask for help. Our culture, our
mentors, and even this book, venerates constant learning and learning how to
learn. That is great for personal growth. We have so many workaholics that the
industry constantly stresses work life balance and many successful people ignore
it. We will never be satisfied until we also learn how to be happy. Despite
reading everything in this book, you’re still going to make strategic mistakes and
tactical errors. Learn to forgive yourself. When we wake up one day and find
what we have is Good Enough, we find peace.

Keep in mind the emotional journey of creating anything great:

We all go through these peaks and troughs. You’ll feel this on any project,
learning any skill, and especially when building a great coding career.

Everything that makes you you, is your operating system. Take care of it. It’s
all you’ve got.

Acknowledgements
This book owes a lot to friends and reviewers for its existence. Thanks to:

Daniel Vassallo for the original push to start writing

Joel Hooks and Joe Previte for constant encouragement and ideas while I
write my first book
Nat Sharpe for being a great editor through the ten most important chapters
Liang Huiqian for organizing research on Engineering Career Ladders
Dan Abramov for finding and trusting me before almost everyone else
 Quincy Larson for FreeCodeCamp, which helped me start my Coding
Career (and for writing the forward!)
Reviewers

Jeff Escalante for in-depth review of every chapter with a lot of

personal anecdotes thrown in
Robin Wieruch for in-depth review of many chapters with GREAT
suggestions
Gergely Orosz for excellent recommendations on the Writing Chapter
Tobi Obeck for great feedback on the Negotiation and Spark Joy
Chapters
Samantha Bretous who helped me get in the readers’ heads with the
Preface, Junior-to-Senior, Profit Center, and Mise en Place chapters
Greg Las for typesetting advice and helping me make the book so
much more presentable.
Many other early reviewers for great comments: Robin Wieruch,
Emma Bostian

All errors that remain are my own. I’m sorry if I forgot anyone here - there were
literally dozens of people who helped me in ways big and small, and hundreds of
people who bought pre-launch that encouraged me along the way.

And thank you for reading! If you have any feedback, tweet at me or the book
and join the book’s community forum!