Stay somewhere long enough to see legacy code
Most engineers change jobs frequently, but the best engineers I’ve known tend to stay somewhere for a long time. It can be difficult seeing your peers move to exciting, flashy companies with big salaries and titles, but I’ve found that staying in one place gives you deep wisdom and perspective.
The caveat here is that you need to find a good company (somewhere that is growing and where you trust the leadership team). If you’re able to find that, then:
- You’ll learn how your decisions turned out. One of the key parts to learning is having a feedback cycle. If you don’t stay at a company long enough, you’ll never be able to see how the software you built turns out (whether good or bad).
- You’ll constantly evolve yourself as the company changes. You’ll tend to be provided opportunities as a company grows that you might not have gotten if you were a new hire somewhere else.
- You’ll gain confidence in making things happen. As you spend time building in your current environment, you’ll get better at it and start to understand what it takes to ship a product or feature.
Creativity should go to the right place
If you look at any of the tables that are still around from hundreds of years ago, you’ll notice they’re typically made the same way: mortise and tenon construction. Mortise and tenon joinery is simple and straightforward, but also strong and long-lasting. It’s been the gold standard for table construction for thousands of years.
The interesting thing is that while the construction method is typically the same, the style of antique furniture can be wildly different: from extremely ornate federal style furniture with marquetry and inlays of the 1700s to large, craftsman style pieces from the early 1900s.
Likewise, I believe the key to building timeless software is to build the bones of your system in a standard way, and to use your creativity in other areas. This means sticking with battle tested tooling (e.g. PostgreSQL) and innovating on solving user problems with your product.
It’s not “Speed vs. Quality”, it’s “Speed + Quality”
I think the biggest determinant of quality is the skill of the craftsperson, not the amount of time someone spends focusing on quality. On the margins, it’s true that if you spend more time on something, the output will tend to be higher quality. But I also think a skilled craftsperson tasked with creating a table is going to take far less time and produce a higher quality product than an unskilled craftsperson who is focusing extensively on the quality of the outcome.
In my belief, skill and expertise are such overriding determinants of final build quality that I think we should talk about the “Speed + Quality” combination, i.e. becoming more skillful so that you can finish things faster AND with higher quality.
Here’s an example: Frank Strazza, a well-known master woodworker, put on a dovetail demonstration at the Texas Woodworking Festival where he finished a set of half-blind dovetails in 15 minutes. The end result was far more pristine and high quality than something that would’ve taken an amateur woodworker over an hour to finish.
You’ll notice this in all disciplines: speed and quality are inherently linked. If you’re an amateur, you likely don’t have the ability to create something high quality yet. As you become more experienced, your work becomes higher quality because of your methods, tools, and general knowledge. It becomes easier and faster for you complete work. At the same time, your minimum quality bar also increases and the work you output by default is higher quality.
Software engineering is no different. Take a look at Russ Cox’s PDF parsing library. He wrote over a few weekends because he needed to parse some PDFs. The resulting library is still in use in many codebases (including Assembled’s) and is considered one of the main libraries for parsing PDFs in Golang.
All this is to say: build lots of stuff and continuously improve as you build. The more pieces of furniture you create, the more software you write, the better the overall quality of your output will be so long as you’re looking for feedback and constantly improving your techniques.
Beta fast, launch slow
At Stripe, there was a mantra that for new features, we should bring on beta users at 25% and launch at 98%. The idea was to focus early on product and idea validation, ensuring that you’re iterating as soon as possible with real users. This was paired with extremely high standards for a feature launch – we only fully launched the product to the public once all the kinks had been removed.
We use the same “Beta fast, launch slow” framework at Assembled to build high quality products that people actually want to use.