This is part 5 of an ongoing series detailing my journey from total noob to hobbyist coder. I share my thoughts as I learn the basics of programming. You can find the rest of the series here.
One of the challenging things about learning to code is that while you are still mastering the basics of fundamental languages, the whole ecosystem seems to be evolving at a breakneck pace. By the time I get a handle on CSS, everyone will scoff at folks who don’t use React. Why learn C or Python when I could be using Go? Why bother with Go when I could devote myself to Rust instead? If Ruby is the language that helps beginners fall in love with programming, why didn’t anyone tell me that at the start?
Charles Martin, a veteran software engineer and consultant, wrote a piece for our our blog this week that touched on this idea same idea in a slightly different way:
Start by accepting that change is inevitable.
Any project, no matter how well planned, will result in something that is at least somewhat different than what was first envisioned. Development processes must accept this and be prepared to cope with it.
As a consequence of this, software is never finished, only abandoned.
We like to make a special, crisply-defined point at which a development project is “finished.” The reality, however, is that any fixed time at which we say “it’s done” is just an artificial dividing line. New features, revised features, and bug fixes will start to come in the moment the “finished” product is delivered. (Actually, there will be changes that are still needed, representing technical debt and deferred requirements, at the very moment the software is released.)
Terrifying! These realizations can, if you’re not careful, lead to a sort of paralysis, a Zeno’s Paradox of programming in which the start of any journey inevitably reveals the impossibility of an end.
I was chatting with Teresa Dietrich, our new chief product officer, about this conundrum. She has been working in technology for three decades, and seen plenty of trends come and go. “Every few years we have this brand new architecture and it's going to change the world, right? The truth, however, is that you cannot remove complexity from a system.” Every system involves not just code, she explained, but the folks who write it, maintain it, and rely on it. “It’s people, process, and technology. What happens when a new software architecture comes along? You have to ask, where did you move the complexity?”
This way of thinking about the situation struck a chord with me. It’s almost a fundamental law of nature: complexity is a constant. Bringing a new programming language into the picture might solve some pain points or produce some gains in speed and cost. But now your code base has five languages, not four. How does that trickle down across the expertise of the hires you’ve made over the last few years? And the support engineers who sit on another continent, who handle crises for customers in seven different spoken languages. “If we really decide a new coding language is a priority and is going to move the needle, can we step back and find another language to deprecate at the same time?" asked Teresa.
Our brains learn to recognize patterns over time, and that makes certain approaches seem more intuitive. Here’s a nice quote from an article by Sandy Maguire, which has been introducing me to if, and, or, and nand.
“While computer science has very little to do with snowmen, it has everything to do with patterns. The study of computer science, like mathematics, is one of overwhelming self-referentiality. The patterns that seemed so difficult and novel yesterday are today’s run-of-the-mill building blocks. Like a snowball rolling down a mountain, the student of computer science cannot help but gain momentum as these concepts begin converge in one huge avalanche.”
There are lots of ways to express this universal truth, but I tend to favor dark humor. Let me know your own stories about code, complexity, and infinite choice in the comments.
All languages were created equal, but some were created more === than others. — Arne Mæhlum (@arnemahl) February 1, 2020