Software Is for Humans, Not Machines
Code is harder to read than it is to write. I’m hardly the first person who has made that observation, but understanding that is critical to becoming a “senior” software engineer. Programming languages aren’t for computers — they’re for people. They exist so we can organize our thoughts collaboratively on what a computer should do. Otherwise, we’d just be writing 1s and 0s.
This is especially true for startups, where often what you’re doing is turning the designs of a novel business idea (like, say, this one) into rules for the computer. The challenges we face creating startup software usually aren’t gnarly computer science problems; they’re knowing the tools that are out there and gluing them together to make a product. As such, the code itself is a description of how the business works. It’s the algorithm of your operations. It’s the state machine of your finances.
When business needs change, you need to be able to change those rules to reflect it. In this way, making a program for image compression or audio sharing is almost simpler. Once you’re done, you’re done. But the codebase of a startup is a living, breathing, changing reflection of the business itself. When a shift happens, what was once safe to be hard-coded is now tech debt. Your business’s core data is now legacy. Your software no longer reflects reality, and the workarounds begin.
So we go and we fix it. We migrate the codebase and the data to the new business. To do that, though, you need to be able to understand what you’re migrating from. Because the second the old feature was implemented and signed off on, you definitely forgot what it was doing. Or, more likely, some other poor soul has to come in and figure out what that feature was doing. I’ve certainly been that poor soul, tracing through 100s of lines of code in dozens of file just to end at a comment of “// … i’m so sorry.”
So when you craft software, you don’t write your code for the computer — you write it so the next person who comes along can understand what you did and why you did it. You create tests so if that person accidentally breaks something, it doesn’t go unnoticed. You add comments to explain what lead to those decisions.
And yet, that itself can be a trap in the startup world. When time to market is everything, the pride you take in doing the job “well” can become a liability. Being fast and dirty is sometimes the correct choice. Having been a founder in the past, I know first hand if the company has a certain cash runway, your ability to turn out code “fast enough” can be the difference between shipping product and shedding coworkers. It does not matter if your code can be updated to fit new business needs if the business itself no longer exists.
I find that balance compelling. I’ve always enjoyed prototyping, and in many ways a startup the ultimate prototype. You need to make the tradeoffs for 3, 6 and 12 months out. You throw the ball in the air knowing that you’ll have to be the one who catches it.
That’s why I do software engineering for startups. I think we do a good job of striking that balance between today and tomorrow at Hello Alfred, and we’re always looking for humans who like engineering for other humans.
