How to Software Engineering, Intro

A guide to killing your first job as a software engineer

Famous hacker George Hotz defines software engineering as a garbage discipline where you convert business requirements into React components. And I think George is partially right. The majority of software engineers act as a translation layer between Jira tickets and code. We do not write algorithms, despite what's tested in most interviews for software engineering jobs. And the job itself is nothing like what one learns in a computer science degree. Both “product requirement translator” and “software Lego connector” are more accurate names of what the actual job entails. What we really do is convert ambiguous product requirements into a set of well-defined programming tasks and then connect AWS services, libraries, and frameworks together like Legos to complete those tasks. But unlike Legos, there’s no instruction manual for how these different building blocks fit together to satisfy our company’s specific needs. And this "garbage" discipline also happens to back a $659B industry. It provides us with incredible products and services like Amazon, Uber, and Spotify. And it's one of the highest paying, most flexible careers you can get.

I define Software Engineering as:

The art and science of solving business problems with software.

It’s what you get when you take programming and combine it with other people, business constraints, money, and a long period of time. What follows is my guide for how to do it well. The most important skills and information I’ve acquired during my career as a software engineer at both AWS and Ada. Skills and information that will help you hit the ground running in your first software engineering job or improve at your current one.

Beyond programming

Just keeping in mind that your job is to solve business problems and not write code will put you in the upper echelon of software engineers. Your employer does not care how much code you write or how elegant or efficient your code is if it doesn’t solve any of their problems. The most beautiful, efficient, well-documented, and well-tested piece of code is useless if it doesn’t do something that is useful for the company.

Programming is to software engineering as dribbling is to basketball. It’s a large part of the game, but it is by no means the entire game. And in fact, you can still do incredibly well with very little of it. Why dribble down the entire court for a layup if you can pass to your teammate who’s already wide-open under the opponent’s net? Why build a solution to a solved problem when an existing solution that’s tried and true already exists? Sure, it can be fun to show off your dribbling skills or to build something from scratch, but the objective is not fun (that’s what pick-up games and side projects are for), the objective is to win.

That brings me to my first principle for doing software engineering well:

Remember that you are a problem solver, not a programmer.

Imagine that you’re renovating your kitchen and need to install a new sink. Would your first instinct be to design a sink, source the individual materials, and then build the sink from scratch? No, of course not. You’d just go to the hardware store and buy one of the hundreds of pre-built sinks that they sell. Yet programmers try and build the metaphorical sink from scratch all the time. Their identification as someone who writes code limits them from solving problems without using code. Don’t fall into this trap. Identify yourself as a problem solver, not a programmer. Look for no-code or pre-built solutions before you try and program the solution from scratch. Throw your ego aside and stand on the shoulders of giants if such shoulders are available. There are no brownie points for difficulty.

When to build it yourself

A tremendously valuable skill in software engineering that you learned nothing about in school or bootcamps is knowing when to use an existing solution instead of building it yourself. A carpenter doesn’t forge his own hammer or make his own nails. That’s outside of his area of expertise and it would be incredibly inefficient for him to do so. Similarly, a good software engineer doesn’t build things that are outside of their company’s core mission.

Here are my 2 steps for determining whether or not you should build it yourself:

1. Never build tools, unless your company is a tool-building company.

This includes:

• Authentication solutions

• Secret Management

• Databases

• Programming languages

If you’re thinking of building one of the above, don’t. If someone at your company is advocating to build one of the above, stop them. There are tons of existing solutions to the above problems built by people who’ve dedicated their lives to building those solutions. Throw your ego aside and admit that you won’t be able to build a better database than the world’s best database designers without putting in similar time and effort. And if your company is not a database company, you cannot afford that time and effort.

When I was at AWS my team spent a year building our own custom secret management solution for our service. The consensus by the engineers on the team once we’d finished was that we should have just used a pre-existing solution. The one-year project would have been a one-week project.

2. Only build things that you can build better than anyone else.

If your solution isn’t going to be better than what already exists, there’s no point in building it. Focus on building things that your company specializes in and use existing tools and solutions for everything else.

You and your team are best positioned to build things that directly align with your company’s mission. The things that you’ve built before and the things you think the most about. If you work at a fintech company that makes personal finance tools, focus on building personal finance tools, not your own authentication mechanism.

This brings me to my second principle for doing software engineering well.

Don’t reinvent the wheel.

One of the most impactful things you can do as a software engineer is to stop your company from building something that already exists. Doing so will save them thousands of hours and potentially millions of dollars. That’s a career’s worth of impact in a single decision.

What You’ll Learn Next

• The only 10 git commands that you’ll ever need

• How to write code that reads like a book

• How to give a useful code review

• How to become the Stephen King of design docs

and more information and skills that took me a few thousand hours to figure out myself.