Career Advice

1. Add Value

Success follows value.

Ensure that the work you do adds value to the business and other people.

2. Write Well

Write well every document that’s read by other people (even if it’s just a README).

People usually don’t tell you when your writing is poor, but they will notice because it’s tedious to read—you’re making them do extra work to understand you. Being known for poor writing won’t hurt your career, but it certainly won’t help it either. On the other hand, if you’re known for impeccable writing, that will help your career because clear writing adds value, and success follows value.

3. Hype Yourself

In the workplace, if you don’t believe in yourself and your work, why should anyone else? Bragging, excessive pride, and self-promotion are typically rude, frowned upon. But self-evaluations and promos are the one time I suggest and encourage you to do exactly that: brag, be proud, and most definitely be a self-promoter. Never lie or overstate the facts for self-evaluations, promos, resumes, and job interviews, but make yourself and your accomplishments shine—be your biggest fan.

Sometimes good managers will see past some self-doubt and believe in an engineer before they’re self-confident, but don’t count on that. Managers are looking out for their careers, too, so they tend to gravitate towards self-confident people because they seem like a safer bet (of course, sometimes people are “all show”, just talk and no real performance).

4. Step Up

Volunteer for work and projects that no one else is eager to do. (But also stand up for yourself: do not allow yourself to be the engineer on whom all “shit work” is dumped.) This is also known as “(taking the) initiative”, being a “go-getter”, and “(taking) ownership”. Those might be cliché, but they’re nevertheless important because “actions speak louder than words”. Ultimately, when all is said and done, businesses look to and reward people who get work done.

5. Don’t Fail

Don’t fail if you break the rules. Judiciously breaking the rules is sometimes good and necessary to make exceptionally fast or large progress. The reward and the risk are also exceptional: succeed and you’re a hero; but fail and you lose significant engineering credibility. That won’t end your career, but rebuilding engineering credibility is difficult and time-consuming. If you realize early that you’ll fail, own it and get ahead of it—let your manager know.

6. Design for Users

The famous Steve Jobs quote:

You have to start with the customer experience and work backwards to the technology.

Watch the video Steve Jobs Insult Response.

Consciously, intentionally think: how will humans uses this program? Draw out or mock up the experiences of using the program—don’t worry about how you’ll make the experiences work. Iterate on the experiences over and over and over again until you can “use” the program in a way that you (or others) think is remarkably logical, consistent, easy, and helpful.

After all, isn’t that the entire point of computers: to help humans work better, faster, and easier?

7. Build for the Future

It is no longer sufficient to write code that works and passes unit tests. This was true before AI, and now it’s eminently true.

Since AI can do the tedious labour of writing code, what makes a human programmer better, more promotable, than another? It’s the human that thinks about the business and builds software for the future.

At the low level of code, this means ensuring code is well-designed especially when written by AI, which has no taste. Since AI makes mistakes, at some point a human will need to understand the “why” and the business logic behind the code.

At the higher level of architecture, this means knowing what systems to build and deploy, and how and why. Unlike code that either compiles or doesn’t, systems architecture is vast and nebulous. It’s also sensitive to a business’s proclivities and industry trends. For example, MySQL or Postgres? Today, I see this as more of a future business question than a technical one; I’d ask management: “Five years from now, will it be easier to hire great MySQL talent or Postgres talent?”

From software to systems, set the business up for success.

8. Be Like Mike

Professional sports athletes play to win. When they walk onto the field, they are expected to play their best and win. There’s no equivocation in their work or performance: they play their best to win every game.

Before AI, it was not uncommon for software engineers to write code only well enough to compile and apparently work. With AI and vibe coding, a person might not even read or understand the code they’re shipping. Both are unacceptable and unprofessional because they don’t help the team (the business) win.

Winning in engineering is a lot less clear than scoring the most points in a game, but there are parallels:

• Winning means designing and implementing software that is impeccable in every detail
• Training meaning continuously learning and practicing how to win—read a book!
• Being a team player means building for future engineers (see point 7)
• Playing your best means never settling for “it compiles and works” as good enough

For every program and project you do, Be Like Mike: be the Michael Jordan of engineering.

9. Don’t Complain

Don’t complain unless the value you’ve added clearly exceeds your complaints.

Note: this does not apply to objectively bad (or "toxic") situations. This only applies to good or neutral situations.

During my long career, I’ve noticed a paradox: some engineers who complain are successful and effective, but other engineers who complain are not. I’ve even seen some engineers complain loudly (and somewhat rudely) and still succeed, whereas other engineers complain quietly and politely but still fail. Pondering this paradox with some managers, we figured out the difference: clout, as one manager called it.

The successful complainers (the ones with clout) have a proven track record of output and adding value. And they continue to add value by shipping code, leveling up other engineers, and being an expert in their field. As such, their complaints are received positively because management knows that 1) they know what they’re talking about and 2) they can and will fix it—if given the opportunity.

But the failed complainers have none of that. As such, their complaints are received negatively because there’s no evidence that they can or will do anything about them. But these engineers don’t see it that way; they usually think they’re right and that people should listen to them. And maybe they are right, and maybe people should listen to them. But without a proven track record of output and adding value, management won’t take that risk, and other engineers will think “Yeah, well, what have you done? It’s easy to criticize. It’s a lot harder to ship something that other people use, even if it’s not perfect.”

Until you have a track record of output and value, learn from those who do.

10. Become the Exception

You’ll encounter people whose engineering level (and total compensation) don’t seem to match their contributions or output. Yes, it’s unfair and demoralizing, but that changes nothing—never has. As the saying goes, “If you can’t beat ’em, join ’em.”

Without sacrificing any of the previous advice (especially 1: add value), study and learn from the exceptions. Presuming you actually deserve what they have, be unabashed in your effort to obtain it. Listen to but don’t believe the naysayers and obstructionists. Almost nothing good is given; even when it’s earned, you must reach out and grab it.