Last updated: 2024-10-02

This is an abbreviated brain dump of things I’ve learned after building software professionally for twenty years. Some of them are obvious. Some of them took repeated failures on my part to learn. Most of them are reminders for my future self.

It’s worth noting that the major sections are listed in this order:

You
Other Humans
Companies
Software Development

That’s because working with humans is the most important part of being a software developer. First, yourself, then your coworkers, and finally, your company. The tech side of the job is the easiest and least important part.

Disclaimer:

I’m not smart enough to come up with most of the items below.

Instead, I very much stole many of these ideas (often word-for-word!) from smarter people than me when I realized what they were saying was true. And I usually only realized something was true when I learned a lesson after I fucked up doing the opposite thing first.

I apologize that many of these items are verbatim copied from Twitter, blog posts, and other sources. I initially saved them just for myself and often didn’t bother with attribution. Now that I’ve begun sharing this document with others, it’s too late for many of them to find the original source. (Feel free to link me to the source, and I’ll happily annotate any items below.)

1. You

1.1 Your Career

1.1.1 Learning

Going to college will not teach you anything you couldn’t learn on your own. However, it will teach you many things that you would never have learned on your own.
- It’s OK if you don’t have a degree. But saying a degree is not helpful because you don’t have one speaks more about your baggage.
Work hard to surround yourself with people smarter than you.
- An important skill to have as you get older is the ability to be taught something by someone younger than you.
  - Experience is a curse. Never lose the ability to be too stupid to know something can’t be done.
The most underrated skill to learn as an engineer is how to write clearly – both in technical documentation and prose.
- If you can make a strong written case that appeals to a non-engineer for a technical change you want the business to sign off on, then you can spend your career doing whatever you want.
- You will become a different person in the future, so you might as well write as if you’re trying to talk to someone else.
You don’t learn from experience. You learn from reflecting on experience.
- Some things can’t be learned. They have to be realized.

1.1.2 Doing the work

Starting is harder than finishing.
- Most distractions do not come so much from our environment but from our own minds.
Never admit if a task was faster or easier than someone above you expected.
- Never tell the client how long something will actually take to complete. That doesn’t mean lie. But it does protect both of you from false expectations in the future.
Don’t ignore the unimportant tasks so long that they become urgent.
- It is important / To tidy unimportant things / So that they remain / Unimportant
I’ve never cared about being a good programmer. I care about solving problems. It’s amazing how many problems can be solved with mediocre programming and care. -Greg Pierce

1.1.3 Growing

Early in your career, changing jobs frequently is OK (even encouraged!). It’s the only way to get a raise and experience enough variety of companies, technology, and people to determine what makes you happy.
- Desire takes care of itself. The hard part is figuring out what to want and how to want it without wanting it too much or too little and without being paralyzed by someone else’s guilt. -Jared Sinclair
  - Many give up within a few months. Most give up within a few years. If you are still at it after 5-10 years, there is not much competition left.
Titles don’t matter. Your accomplishments and how you treated other people is what you’ll be judged and remembered by.
If you’re the smartest person in the room, quit and join a company where you aren’t.
- If you’re always the smart person in any room, I assure you you are not.
When you don’t create things, you become defined by your tastes rather than your ability.
- Your tastes only narrow & exclude people. So, create.

1.1.4 Success

Tech is just what you do to save up some money so you can quit your job and focus on programming.
Your first instinct is usually correct.
The best ideas are the ones we don’t anticipate.
- The best work of my career has always happened when I was focused on something else.
- Encourage serendipity.

1.1.5 Failure

You are incompetent. Really. Never let anyone convince you otherwise. If you understand this, you can plan accordingly.
If you’ve never failed, you’ve never pushed yourself hard enough.
- Keep a list of your biggest mistakes. When others fail, show them the list so they feel safe.
- When you aren’t willing to make mistakes, your mistakes will be more severe and public.

1.1.6 Money

Do not base your self-worth on your salary.
If your job offers a retirement plan (401k), max it out.
Stock options can make you a millionaire or become worthless. Treat them like pretend money and don’t rely on them.

1.2 Self-Care

1.2.1 Physical

Exercise. You don’t have to lift weights or run marathons. Just move. That’s it. That’s the whole secret.
Take the ergonomics of your workspace seriously. Your forty-year-old future self will thank you.
If you don’t schedule a break, your body will take one for you. And it probably won’t be at a convenient time.

1.2.2 Mental

Again, exercise. It helps your mind even more than your body.
Burnout
- Rest and procrastination are not the same thing. Procrastination gets in the way of your goals. Rest helps you achieve them.
- Only you and your family can determine how much you’re willing to give to a job, and that bears constant re-assessment.
Most people are unhappy because they fail to realize when they’re happy.
Manage your energy, not your time.
- The opposite of play is not work; the opposite of play is depression.
- You waste years by not being able to waste hours.
Find out before you flip out —Ted Lasso
- Worrying is like paying a debt you don’t owe.
  - Be a gray rock. Almost none of this actually matters.

1.3 Big Life Stuff

The dread is worse than the doing. -My grandmother
Grief is love with nowhere to go.
Time moves with or without you. -Diane
Never think that anything in life is getting easier. It’s you who are getting better.
- Pain is a request for change.
There isn’t another timeline. The bravest thing you can do is to accept with gratitude the world as it is. What punishments of god are not gifts? It’s a gift to exist. And with existence comes suffering. There’s no escaping that. If you are grateful for your life, then you have to be grateful for all of it. You can’t pick and choose. What’s the point of being here and being human if you can’t be the most human you can be? That doesn’t mean the best human. But being the most human. And that involves acknowledging and ultimately being grateful for the things you wish didn’t happen. -Stephen Colbert

2. Other Humans

2.1 Computers are easy. People are hard.

2.2 Help them

Be kind to interns and junior developers. Hire more of them. They’re energetic and naive enough to call out company bullshit in ways experienced developers are afraid to do.
When giving feedback, that feedback must be: True, necessary, and kind. If it’s not all three, it will be ignored.

2.3 Learn from

The smartest person at the company is just making everything up as they go along.
- Engineers from tech giants and elite colleges don’t know what they’re doing either.
Don’t dismiss or pass over anyone just because they don’t have a degree.

2.4 Deal with

Everyone is broken in some way. If they say they aren’t, then they’re lying or haven’t figured it out yet.
- Never underestimate someone who has hit rock bottom and found their way back.
Believe people the second time they show you who they are.
Emotions don’t respond to logic.
- This applies to other people as much as it applies to yourself.
Sometimes you have to hug the person you don’t like so you know how big of a hole to dig in the backyard.

2.5 Be good

Always say thank you.
Compliments are free to give but pay back huge dividends.
Be kind to everyone. Not because it’ll help your career (it will), but just because.

3. Companies

3.1 Politics

Politics is unavoidable. I’m sorry.
50% of software engineering is convincing managers to let you do the work and 50% is convincing managers that you did the work. The next 100% is actually doing the work. -Ryan Grove
Withholding criticism is selfish because that means you care more about that person being upset at you than making the product better.
“Fault” is not the same thing as “blame”.

3.2 Culture

In the workplace, cursing should be rare but passionate.
- Yell at things, not people.
Don’t drink alcohol at work.
The free coffee from a fancy thousand-dollar coffee maker at a large corporation tastes exactly the same as the burned single-pot coffee at a mom-and-pop business. Perks can be fun, but they shouldn’t be important.

3.3 People

3.3.1 Misc

The biggest concern for any organization should be when their most passionate people become quiet.
No one is irreplaceable.
- If someone is irreplaceable, that’s the fault of the business.
- When a coworker quits, tell them you’ll miss them and are happy for them.

3.3.2 Managers

If you’re a manager, never publicly blame an employee. It’s always your responsibility.
Picard management tip: Tolerate failure, not incompetence. Learn the difference.
Managers have less power than you think. Way less power. If you ever wonder why a manager doesn’t make an obvious change or fire someone, it’s because they can’t.
Never ask, “Are there any problems?” with whatever “thing” your team is working on. Instead, ask, “Tell me about the problems.” The first implies, “I don’t want to hear about any problems,” and the second says, “I want to know so I can help.” -Niall
Never stand in the way of someone switching to another team. Help them!
- Never stand in the way of someone who wants to leave for another company. Help them!
If your manager doesn’t demonstrate respect for their own work/life balance, they won’t respect yours, either.

3.4 Bad Stuff

A toxic workplace is more likely to change you than you are to change it.
If there is a corporate culture of publicly assigning blame to bugs, it’s time to leave.
- If your manager publicly blames you, look for another job.
Keep a tally of each day when you feel worse at the end of the work day than you did at the beginning. When the bad days consistently outnumber the good ones, it’s time to leave.
Companies will not feel guilty about firing you.
- Don’t feel guilty about firing the company you work for.

4. Software Development

Almost everything that goes wrong in software development can be summed up by this: Humans interpret instructions. Software follows instructions. –Paul Cantrell

4.1 Process

4.1.1 Planning

4.1.1.1 Estimating

Negotiate decisions, not estimates.
Without clear requirements, it always takes longer than 100% of the expected time. -Tyler
The smallest accurate unit of estimation for software is one week.
Assume 30% overhead for the things you don’t know you don’t know.
How long you think something will take has very little relation to how long something actually takes if you don’t know what you’re talking about.
Data is a compass, not a map. -via Niall

4.1.1.2 Misc

Sprints are a planning and evaluation cadence, not a delivery cadence.
When it comes to project management, you can’t set a wedding date without going on a first date.
- Thinking takes place as much on paper as in your own head.
- You need to think through what are the bad things that could happen and what are the good things that could happen. You need to be ready for either. You should probably make two lists. -Donald Rumsfeld
- If you can’t hold an entire idea in your mind, crystal clear and ready for manipulation and expansion, then you haven’t broken it down far enough yet.
Planning is inherently a constraint placed to observe and measure effort.

4.1.2 Group Work

Small, independent teams with clear requirements and the appropriate agency to make their own decisions can do amazing things!
Small teams are more productive and produce better results than large ones.
- High-trust teams don’t need code review. Team members only need to know what is changing and why.
  - It’s not that you trust others not to make a mistake—because they will—but that you trust they care as much as you do.
- Five developers are the maximum per project. (A single product may house more than one project.)
  - If there is still too much work, that’s a business problem – not a project management one.
    - Adding more people after a project is halfway finished only makes things worse.
When building software, I have found that when I feel bored, it’s often because I know intuitively that what we’re doing is wasteful, but I can’t articulate why. If it’s monotonous but I believe it to be essential/unavoidable, I am engaged. When I can form clear thoughts about the waste, I’ll speak up. But when I have a gut feeling that we’re spending our time poorly but can’t explain it, then I just feel bored. So, the boredom tells me we might have an opportunity to improve our process.

4.2 Architecture

4.2.1 High-level

First Law of Software Architecture: Everything in software architecture is a trade-off. If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet.
- Second Law of Software Architecture: Why is more important than how.
Some problems are complicated; others are merely complex.
- Others are not simple, but they are straightforward.
Don’t fight the frameworks and design patterns endorsed by the platform.
A complete rewrite is the wrong choice 99% of the time.
- If you do rewrite, double your estimate to account for all the stuff you forgot to account for.
More than three layers of abstraction are tech debt.
- The Katz Conjecture: To effectively use any abstraction, you must have a solid understanding of what it’s abstracting. Any abstraction that doesn’t sufficiently simplify what it’s abstracting makes everything worse. Any abstraction you don’t understand is a risk to your project.
It’s easier to combine things than break them apart.
Computers are fast – aspire to do all work on the main thread until there’s a demonstrable reason not to. It reduces complexity and makes the code easier to reason about and hold in your head.

4.2.2 Low-level

Being a good engineer means knowing best practices. Being a senior engineer means knowing when to break best practices.
People’s willingness to talk, work together, and find solutions is more potent than any coding pattern.
Making code flexible and generic up front is usually a waste, as you’ll often never need that flexibility. Instead, make the code easy to refactor by making it as simple as possible.
- Office buildings. Not cathedrals.
- Every ugly system is also a successful system. Every beautiful system has never seen spontaneous adoption.

4.3 Programming

4.3.1 General

Programming languages and tech stacks are secondary. Only a handful of software development patterns and principles matter per field. Learn those, and everything else becomes an implementation detail.
- Nothing is ever needed for everything. (Re: technology choices / tools.)
You haven’t learned a technology well enough until you can hate it.
- Java is a terrible programming language that is good at everything.
The point of type systems is not correctness – it’s to let autocomplete tell you what you can do.

4.3.2 Code Quality

Good code can be understood by a junior engineer, and great code can be understood by a college freshman. The best code is no code at all.
- If a junior developer can’t understand your code now, it’s probably wrong.
Duplicated code is cheaper than the wrong abstraction.
- The longer I spend time in the software industry, the more I think that the primacy of “don’t repeat yourself,” in all its many forms and scales, is a tragic flaw. I think it is far, far harder than most anyone would like to admit to write something that is usefully and sustainably reusable over any but the shortest distances in space and time.
Code you can modify later is better than perfect code now.
- You can always improve the efficiency of readable code, but you can’t get back the time spent maintaining unreadable code.
  - Clever code doesn’t win any awards.
- Code that doesn’t ship is never correct.
Don’t make Future-You hate Past-You
- Most legacy code is better than you think it is and solves edge cases you aren’t aware of.
  - Chesterton’s Fence: “Do not remove a fence until you know why it was put up in the first place.”
- If you won’t be able to read your code six months from now, it’s wrong.

4.3.3 Trust Me

Nothing seems so easy as another engineer’s problem.
Never write your own time zone logic, encryption algorithms, or security software unless you’re an expert.
- You’re not an expert.

4.4 Design with a capital “D”

4.4.1 Misc

Making things look simple by hiding things doesn’t actually make them simple. This applies to both software architecture, individual lines of code, and user-interface design.
Be careful when people argue that good software must be efficient and frictionless. Sometimes, friction is necessary. Artificially adding friction at the right moment can slow down the user and save them from doing something bad.
Apple is very good at making hardware. This is because the hardware is designed to meet software needs, instead of the software being redesigned to use what the hardware provides. This is impossible to convey to people who have spent their whole careers doing the best they can with the hardware they’re given.

4.4.2 Features

Tablestake Features: You can’t win with them. But you will lose without them.
Don’t ask people what they want. Watch what they do, and give them what they need. -John Carmack

4.5 Design with a little “d”

A user interface is like a joke. If you have to explain it, it’s not that good.
The primary rule of user interface design is that users won’t read a single god damn word you put on the page.

Thanks for coming to my TED Talk.

Contents