1. Kindergarten. 2. College. 3. Preschool and Professional Athletics. 4. Effective Software Engineering. Most of us muddle along in the middle.

The Golden Rule of Software Engineering

It’s late now, after a couple beers. So this might get philosophical.

I’ve been a software engineer in the Valley for a while now. Written code and led teams, especially in tech startups, both successful and failed. And been lucky enough to work with amazingly skillful programmers. At times, one pauses to reflect. This week, I decided to write down some musings.

Also, forgive me. Years ago, I studied math. So I like to make gratuitously categorical statements that defy logic and number statements for no apparent reason.

Rule 1: On average, you’ll throw it away

Startups are exciting. You have a founding team with a vision. By good fortune and hard work, you have funding, a few brilliant engineers, and a lot of energy. It’s like loading a rocket with fuel, aiming it in the right direction, and launching it.

Oops — I’m sorry. Of course, that’s a lie. It’s not like that at all.

1. The best companies iterate like mad, and adjust course all the time. Typically, success is the result of numerous iterations and one or two major or minor pivots. This is especially true in startups, but also applies to big companies launching new products.
2. Even so, most software products fail. Most startups fail. You’ve probably already failed a few times, or you’re not being ambitious enough.
3. Consequently, most code you write will not be used the way you expect. The product won’t work, won’t launch, or will be replaced by something else. Or it’ll just get buried and mostly forgotten in a dark corner of some larger system.

This might be bothersome, but it’s bothersome in the same way that exercise is tiring. That’s just how it works. It can’t be any other way.

When you’re innovating, throwing things away is an inherent part how you create value.

Only a small fraction of the code that’s written every day by engineers around the world is going to be used heavily for long time. Sure, there are plenty of examples like the Linux kernel and Google’s MapReduce that are massively useful at enormous scale, but statistically, chances are that the piece of code you’re working on right now has relatively low value. Even companies with highly successful products are in a constant state of rewriting and replacing. Code that’s valuable now might be abandoned a few months later.

The best and most productive engineers create valuable software not by getting it right the first time, but by creating more often, learning quickly, and creating more effectively from their learnings. Their batting average at creating useful software gradually rises. It’s like exercising more often, measuring your progress, and getting a personal trainer to refine your training strategy.

Rule 2: Code isn’t worth much

Rule 1 might seem a bit discouraging. But of course, people can and do build things of real value. Your team may indeed be building a product that can help millions of people, or generate millions in revenue.

A productive company has immense value. But if much of the code you’re writing isn’t worth much — well, then what is?

In fact, some of the most important things an engineering team produces are everything but the code:

• Know-how. You know how the codebase works — and crucially, have the understanding and ability to change it. You have technical expertise in the frameworks, programming languages, databases, or distributed architectures you use. You know the approaches that failed. You have user experiences and user data — and can use them to make decisions.
• Process. You’ve learned how best to divide work and organize. How to hack prototypes. How to do code reviews. How to hire and mentor. How deployment and testing process work for your product. Your metrics and analytics on user or customer engagement.
• Team. You’ve learned in what ways each team members is valuable — or not — and in what roles. You have users or customers who like and understand your product. You’ve built relationships, and probably some friendships, with your coworkers. Maybe you’ve open sourced code and grown a community of developers. You’ve developed culture and an ability to work together.

Notice I didn’t use the word “knowledge.” Knowledge alone is static. Know-how is knowledge in motion. The most valuable software teams have useful software combined with the ability to change and grow the software.

As an engineer focusing on specific problems every day, it’s easy to lose sight of how much you’re building implicitly. You are always thinking about code. About the problem of the moment. But what you’re really building — what will stay with the company, and with you, even after you leave — is everything else.

If you don’t believe me, reflect back on your work this year. Imagine someone asking you in five years what the most valuable lessons were. It’s unlikely it will be the specific detail you’re most worried about right now. It likely will involve learning how you built and shipped things (or failed to), your users or customers, the connections with the people you worked with.

Rule 3: Help yourself by helping others

Rules 1 and 2 don’t mean you need to change what you’re doing entirely. Indeed, especially early in your engineering career, you may be able to forget all about them and still be productive. But if you take a little time to internalize what they mean, you’ll notice it has a subtle and pervasive effect.
If the lasting value of your work is know-how, process, and team, you begin to understand that even when you’re hacking alone at night, it’s not only about you making things work right now. It’s really about everyone continuously improving things. It’s about the future.
For example:

• Do your comments and pull requests say not just what you’re doing, but also why? Do you encourage others to speak up and ask questions, so you share your thought process and they poke holes in your approach?
• Do you use code reviews not just to catch your own bugs, but to communicate knowledge?
• Do you ever consider switching roles with someone to test if you’ve documented things well?
• After you sprint to get a demo working, do you also budget time and enlist help in fixing problems and making it better? Do you discuss deployment, updates, and continuous delivery?
• Do you take 5% of your time just to walk around, discuss other people’s problems, learn, and help? Even when you’re busy?
• Do you debug processes in your company the way you debug programs, writing them down and revisiting how well they’re working?
• Do you mentor others by guiding them to fix a bug or add a feature, even when you could do it quicker by yourself?
• Do you give colleagues feedback about their performance? Do you solicit feedback yourself, when others are too shy to offer it?
• If you’re a lead or manager, are you planning around what an engineer can do right now, or wondering how might inspire them to be twice as strong in six months? Do you think of team members as fixed-sized gears, or as growing creatures with expanding capabilities?

The upshot of all this is to remember of the broader, reusable value you’re creating. Even in a profession built around machines, it’s still about the people. Like you learned in kindergarten, what really matters is thinking of others. You help yourself most by helping others. The Golden Rule works for techies, too.

❧

If you’ve found any of this helpful or (especially) if you have responses or disagreements, please recommend or leave a comment. I’d appreciate your thoughts! Find me: LinkedIn, GitHub, Quora, Twitter, Medium.

Published in Techspiration + Ideas + Making It Happen.