Culturally, we web developers have a bad habit of selling things by telling you they’re easy — just follow these steps. Simply do x, y and z. From the beginning, it’s been driving me crazy.
Nothing about programming has ever been simple or easy for me. In fact, it’s been a struggle every step of the way. Is it me?
Just, simply and my personal (least) favorite programming descriptor — trivial — are presumptive, tone-deaf, very frequently wrong.
What’s missing here are the qualifiers: Trivially easy… if you have a decade of programming experience. Simply follow these steps… assuming your environment mirrors the one I was using the day I wrote this. Just type this command to install this library… if you know what a package installer is, don’t have any permissions issues, and the OS didn’t change an unlisted dependency.
All signs point to an insidious programming elitism problem, as DevMountain founder Cahlan Sharp writes for TechCrunch. If there were anything trivial about developing software, why would we be flocking to Stack Overflow in search of answers? If things are really so simple and easy, why do web developers pull down six figures and product roadmaps stretch off into the distance?
Because programming is not easy.
The fact is, programming is hard. It takes a lot of time, forethought, and experience to do well. Learning the syntax of the language (no small feat) is just the beginning. Large, complex ecosystems (not to mention personal fortunes) have been built around simplifying each step of the process; new founders with new promises of how easy their service will make things. It’s why coding boot camps were a $460 million dollar industry in 2019.
Ironically, the result of all of this simplicity is a mess of complexity.
Sometimes, these so-called miracle solutions only create more programming headaches. Sure, fewer of us are configuring Linux servers — that was awful, I had no idea what I was doing, and I appreciate not having to do it anymore.
But more of us than ever are trying to figure out why the CI choked on the latest build. If we’re being DOSed by bad actors, one of our API customers, or (more likely) one of our own services. Why the BI dashboard doesn’t match the same stat we’re displaying to users.
If it were just me who struggles to manage this complexity, why do most companies have the same answer when VCs ask what they’re raising money for? The response is so common we can almost recite it in unison: to scale engineering. There’s a good reason for that answer, beyond a lack of creativity: organizations face a long and expensive list of solvable-but-time-consuming software problems, and we all know it.
If it’s all so simple, why is it so expensive?
- Because the “trivial” things take days instead of hours.
- Because builds come back missing features that were trickier than we realized once we dug into them.
- Because the deliverable is useless without the feature that got cut.
- Because the product team didn’t understand what actually would have been feasible for devs, if anyone had thought to frame the problem that way.
- Because we hit a wall on a bug, and it tooks hours to track down.
To help non-developers make sense of the mess, we build platforms based on templates. Shopify, Wix, Wordpress and the rest are trying to solve the same problem — put the code into the background, or hide it altogether.
Sell templates with simple, aesthetic photography and design. Make app stores to fill in all the esoteria that didn’t make the 80/20 cut. Create buttons and menus to force templates into new configurations, and hope it does what you need. If you can afford it, invest a small fortune to have it customized.
But the amazing thing about code — the reason we stomach the chaos and pay the high fees — is its incredible power. Even poorly written code, anchored to the physics of processors and the internet itself, is a thousand times more powerful than no code.
But true power lies in the holy grail: well-written code.
Good code is like poetry, expressing complex ideas in a simple, elegant way. Stripping an idea down to its most pure, most authentic self, able to communicate both with machines and humans.
In our complexity, we’re leaving people on the sidelines and preventing them from ever experiencing that beauty and power. Because they aren’t smart enough? I don’t think so. I find it far more likely that they’re being left out because they don’t have years to invest in learning the syntax, acclimating to the environment, and uncovering the gotchas one painful hour at a time, with a dribble of productivity in the early stages, if they’re lucky.
I’m creating a place where no developer of any skill level gets left behind — and I’m calling it Trivial as a permanent reminder of the trap we must not fall into.
Trivial is a place where you can learn to write software as you go, getting immediate value out of the time you’re investing. Trivial is a place where the steps are intuitive, the examples work when you try them, and anyone can build a bot in minutes without a decade of experience.
Trivial puts code in the foreground, because that’s where the real power is. I don’t want to hide it behind buttons, subjugate it to some dusty corner where you can write 200-line nightmarish global functions, or require you to build and maintain a local environment.
Rather, my goal for Trivial is to make code understandable and enjoyable for everyone who wants to learn. We’ll strip away the complexity around code that turns so many people away. To create an environment that doesn’t just teach you how the code works, but how to do incredible things with it.
How to get more out of your time, and how to access the joy that comes from having control over your environment.
At the end of the day, code is a tool. It’s a bit unwieldy for everyone but the pros, and it too often seems like magic to the naked eye.
And yes, a place for developers.
After years of struggle, and despite our tone-deaf promises of ease, we too deserve a place where things JFW.
We’re looking for pre-release users of all skill levels. Contact us, and help us build the platform we wish we’d had to learn on.