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?

Sometimes it helps to imagine a user experience that doesn’t even seem possible. Why? Because after many years of programming, engineers tend to become quite practical and practiced in standards, conventions, and so on—almost to the point that we begin to design software by rote rather than by focusing on the user experience. Imagining a seemingly impossible user experience helps break the rote mindset. More importantly, those years of experience are always hard at work, so in the process of imagining the impossible, we might find that some particular experience is effectively impossible with today’s tech but with a few tweaks we can create an experience that’s really close and really remarkable.

7. Code for Future Engineers

It is no longer sufficient to write code that works and passes unit tests. If that’s all you do, then you’re unlikely to advance significantly in the software industry because any engineer can do that, so you’ll find yourself in a very large and competitive sea of engineers, many of whom are working hard for that next promotion or engineering level.

Externally, software is design for users and the user experience (see previous point). But internally, design software for future engineers—not for yourself, not for today, but for a new engineer 5 years from now. That mindset and intention has two effects.

First: it helps you design, write, and document code more clearly because you realize that future engineers will step into a complex code base and have to understand and make changes and, moreover, probably be under pressure to do so either because they’re new engineers (and trying to do well at their new job) or because the company has imposed time limits on them. When that future engineer finds your well design, well written, and well documented code, it’s an oasis in a desert complete with food, water, and maps.

Second: significant career advancement in tech is only 50% technical skill. The other 50% is your impact on other engineers because look around… code affects many engineers. Providing that oasis has a signifiant impact. It allows other engineers to ramp up more quickly, which helps them be successful more quickly, which helps the team achieve its goals more quickly (or, at least, on time), which helps the company succeed, which provides value to users and customers. When that is your impact—by coding for future engineers—you won’t have to advance your career, the industry will pull you up.

8. Be Like Mike

Professional sports athletes play to win. When they walk onto the field (or court), they are expected to play their best and win. There’s no equivocation in their work or performance: the play their best to win every game. To that end, professional athletes constantly train to improve.

It’s not uncommon for software engineers to write code only well enough to make it compile and do the basic functions that the business (or users) need. Worse, such engineers think this is acceptable or “good enough”; they don’t see any problems with their work. These engineers are not professionals, not team players, and not helping the team (the business) win.

Winning in engineering is a lot less clear than scoring the most points in a game—and doing that consistently enough to win the season. 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 coding 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.