The other day I saw an Instagram reel describing the process of creating a sliding button, like the ones you find in your settings app. It was a satirization of the process, of the relationship between designers and engineers. The designer cluelessly works to their hearts content, spawning an incredibly complex series of shapes, colors, and animations. Meanwhile, the engineer, drenched in sweat, desperately tries to turn the naive designer’s vision into a (hopefully somewhat functional) reality. Just as the architect’s wildest wet dream is the construction team’s most horrific nightmare—the graphic designer’s greatest desire is the programmer’s greatest fear.

And so, I found myself popping open the comments section and finding that one of the top comments asked an unexpected question. Something along the lines of: “I have no coding experience—is it really that hard to code a button?”

When somebody says the architect’s dream is the construction worker’s nightmare, it’s pretty easy to imagine why. Beautiful curves and complex interlocking marvels are self-evidently more complicated than a rectangular prism of wood, concrete, and glass. Not so, with code. To the average person, it just seems like two different people using computers to make the same result, where one struggles and the other doesn’t. It doesn’t click.

So, to begin to answer the question¹, yes, it is absolutely that hard to code a button.

To get into why, the first thing we need to understand is that these people are using different tools. Their hands are both at a keyboard and mouse, but the software they’re using is entirely different. Designers use design software—tools specially made to accelerate the process of visual conception. It’s a similar case with the arcitect. It is easier to draw or digitally design a building than to erect it². Thus, the programmer is akin to the construction worker. They are not blessed with the luxury of thought translating so cleanly to reality, as the designers are. They must build from scratch—from the ground up. The designer has made the blueprint, the outline. Nothing more than a mere model. The builder, the programmer, must do the grueling work of making impractical and unreasonable dreams into reality.

If you’ve never programmed before, it may seem a bit magical. Some hoodie-wearing miscreant speedily types away at a laptop, thousands of green lines of matrix-style code reflected in their sunglasses. Eventually, out pops an application, or a website, or, god forbid, malware. How do they do it? No one knows. We allow the wizards their craft, and for our lack of curiosity we gain convenience and algorithm-driven bliss in exchange.

But, as a member of the wizard inner circle, I’m here to break the unspoken covenant and explain the true machinations of our spells. Because, truth is, coding a button is not dissimilar to constructing a real, physical button. Point being, it’s a colossal pain in the ass.

Imagine you’re a toy manufacturer. Your job is to make a toy with a button on it that, when pressed, will randomly play one of a number of sound clips. Like a talking teddy bear, maybe. You press a button and out it squeaks: “I love warm hugs!”

Now imagine you have to do this from scratch. You need to design the actual physical mechanism of the button. Do you make it clicky, or squishy, or smooth? Do you make it a shallow, small button, or do you make it a deeper button? How do you design the button so that it is enjoyable to press? Or, more importantly, how do you design the button so that the button fades into the background—the user, the kid, shouldn’t even have to think about it. And, how do you do all that while still making a toy people can afford?

But you’re not done once you’ve solved those problems. You need to make the button actually work. You’ll need to wire it up to a battery and a speaker. You’ll also have to make that speaker have all the audio clips you need, and you’ll need to make the button set off a random audio clip. Meaning, you’ll likely need to get someone to program the speaker to respond correctly to the button input.

Now, after all this, you might feel like an infomercial actor: “there’s got to be a better way!“. Maybe you can use off-the-shelf parts? That sounds like it’d be easier. But using off-the-shelf parts has its own set of complications. First you need to find a part that fits your exact use case. It needs to be the right size, shape, it needs to be compatible with the other parts you’re using, and it needs to do all that while being affordable and available in high quantities. You’ll need to set up and manage relationships with manufacturers and suppliers, and you’ll need to integrate installing the part into your assembly line. You’ll need people who understand how the part works and what to do if things go wrong or it behaves unexpectedly. You’ll also need to know how durable the part is. If a kid presses it too fast or too often or too hard, will it be able to withstand it? How many presses can it handle before it breaks? God help you if you want to actually make the button fit the style of your toy, because now you’ll need to modify every single button to fit your preferences, and then make sure your modifications don’t break the button.

Programming is even worse, because instead of creating a toy, you’re creating a blueprint for it. That blueprint then gets sent over the wire to a hundred gorillion different computers, each using different browsers on different versions. Each computer-browser combination then rebuilds the toy(website) based on your blueprint, often doing things in their own quirky and personalized way. Some see fit to install things in a weird order, and others just don’t understand your blueprint and simply ignore parts of it, spitting out a teddy bear missing buttons or paws or maybe even a speaker. You have to write your blueprint such that every single mini-manufacturer reliably creates the exact same product, or at least one close enough to be fine. You might even have to add special instructions for different manufacturers because you’ll know they’ll mess things up otherwise. You’ll have to come to terms with never having the ideal version of your toy in people’s hands—a million compromises have to be made to get it there. The tools don’t exist for you to fulfill your vision. In order to make your teddy bear, you have to work with the tools. They are your master, more than you are theirs.

Fortunately, there exist a million and one tools for making things easier. Each also makes things harder in its own unique way. For example, let’s say I use something called “TailwindCSS”. In short, it’s a tool used to make styling easier. Meaning, it makes it a lot simpler to change the color and shape of the button on the teddy bear without breaking anything. But, in the teddy bear analogy, this might be akin to hiring a design manager. Sure, he’ll take a lot off your shoulders and make your job easier, but now you have to handle him. You’ll have to figure out how to communicate with him, and how to best get him to do what you want. He has his own opinion and style for doing things that you’ll need to account for in your instruction. He’s going to need an office, and you’ll have to go through all the work of onboarding him and incorporating him into the organization. Even worse, he regularly updates his styling and capabilities, meaning you’ll have to retest and readjust how you work with him as he changes. He’ll make an effort not to break anything without you noticing, but he’s human, so there’s never any guarentee.

So it is with everything. In programming, you’ll use “build tools”, a set of utilities and functions built and maintained by a bunch of strangers you’ll never meet. You’ll have to import this machinery into your factory, and pray it doesn’t conflict with anything else you have there. You may also have a tool to manage your tools. The abstraction is useful, and often simplifies and streamlines your job, but it’s never perfect and it is always something you have to mold yourself to work with. You have to adapt to the flaws and complications in the system, because the system cannot adapt to you.

At the end of the day, making one button might be relatively simple—if your standards are on the floor. If you don’t care how it looks or that it works especially efficiently or cleanly, you can just toss it together without having to worry about all the extra cruft. But, if you want your teddy bear to survive the market—if you want your website to fit in on the modern web—you’ll have to start putting together your factory and building a team. May god help you if one of your tools breaks in some way you don’t expect. Even the wizards of the circle may just tell you to throw in the towel and start again from scratch.