DRAFT: This Time Is DifferentMay 12, 2020 · 4 mins read
This time is different. “Clean slate. Solid foundations. This time I will build things the right way.”
Early in my career, I was obsessed with “best practices”. I wanted to write code that would stand the test of time. Code that was objectively ideal. After all, my programming idols on Twitter said it was good. This is clearly the best way of building software. Who am I to question them?
This is the same mindset that leads to the exhausting pursuit of the shiniest of tech stacks. How can I convince my boss to let me use Rectangular.js, Crust, Kappa, and GiraffeQL to build our new serverless CRUD app orchestrated by Gooberyetis? We need to use microservices, the best state management patterns, and only the purest of functional programming paradigms, so we are future proof. If it works for BigCorp, surely it works for us.
Don’t get me wrong though, these are all great tools (jk, none of them exist). Just keep in mind that tools like these are often extracted from specific use cases and engineering cultures that might differ from yours.
Learning a new language that was unlike anything I had used before was humbling. I struggled for hours trying to understand pattern matching. Variable declarations are one of the first things you learn as a total beginner in any programming language. Yet here I was struggling to understand it, despite having done this for a few years.
Great post about learning new mental models via new languages. When I started my career I learned Ruby and JS. For a while, those idioms shaped the way I thought about code. When I learned Elixir and about the Erlang VM (BEAM), everything I knew about backends and APIs changed https://t.co/cKOMNfF6Ua— Lauren Tan ✨😷✨ (@sugarpirate_) May 1, 2020
I’ve picked up more languages and tools since then, but the humbling lessons don’t stop. Paradoxically, the more I know, the less I understand.
We often look to proxies like Twitter follower counts, stars on GitHub, and loudness of voice to tell us what we should do next. That’s fair—sometimes, you just want to get your job done. Software is still a relatively young industry, and it seems to change rapidly. That often is overwhelming. But don’t start from the default of thinking that this must be good because someone else said so. Consider the problem you’re trying to solve, the opportunity cost of going with this solution instead of another, and the tradeoffs your team is comfortable making. Dealing with ambiguity and making tradeoffs is part of the job.
More importantly, realize that whatever you decide to go with today will likely change in the long term. If your project even lasts that long :) And that’s okay.
I learn from many random sources on the internet. One source I find myself going back to often are videos about cooking. There’s something magical about watching people make things. And I like to eat.
When I first watched Jiro Dreams of Sushi almost 10 years ago, I didn’t understand what drove Ono. His obsession with perfection seemed pointless. Surely at some point, after decades of making sushi, there would be nothing left to perfect.
I’ve come to realize that perfection is not a destination. It’s an incremental journey, process, or whatever you want to call it. Whether it’s today’s project, or a project I’ll work on next year, every piece of software is the same, only different. Put another way, something that works well on one project might not yield the same results in another.
Instead of seeing code as an unchanging structure, like a building, think of your software as a living thing. Every project changes and grows over time. The people who work on it come and go. The people who use your software also change. Like things that constantly change, software is never finished. It just gets released (hopefully continuously).
“We are simply never going to realize a state of software nirvana where everything is supremely satisfying. That’s an important emotional realization. The fundamental reward of an improvement process is the experience of betterment, not some mythical destination.” - Mark Slee
This blog post was inspired by this writing from Mark Slee. It was written 10 years ago, but it’s still excellent. Highly recommended.
Written by Lauren Tan who lives and works in the Bay Area building useful things. You should follow her on Twitter