Unravel the magic of programming

Last Updated on May 26, 2023

Are you the kind of person that likes magic? If you’re not, try to remember why other people like it, and bear with me.

There is a reason why it’s called a "magic trick": because it’s fake, it’s make-believe. But what makes people like it is due to the fact that they feel amazed when they can’t explain why it’s fake even though they know it’s doable because it just happened right in front of their eyes. Notice that if the magic were real like wizards do, people wouldn’t be so instigated because there wouldn’t be a trick to unravel, but finding out how the trick works is something that also makes it lose its charm. It is a very thin line.

This is true for most individuals, but there is a certain group that enjoys finding out how the tricks work: the magicians! Magicians are people that, in addition to liking the tricks themselves, also like the gimmicks that make the trick possible, especially because it makes them better magicians doing so.

As programmers, we should avoid treating programming as if it was magic, the way it is seen from the audience’s perspective, or as if it was an impossible thing, especially when dealing with complex problems, because as a skillful programmer – and here I quote The Prestige – "you’re a magician, not a wizard."

Start with the sleight of hand

When you’re starting to learn how to do magic, you won’t be pulling a rabbit from a hat, levitating, or making a statue disappear on day one. Rather than that, you’ll find out that there is a series of basic techniques that are necessary to perform those fancier tricks more effectively and convincingly, like the sleight of hand, the misdirection, or the equivocation, otherwise you’ll spoil the magic secret to the audience, making it lose its effect.

Sometimes we’re so eager to do great deeds that we end up forgetting that they can only achieve their maximum potential or be possible if we have a strong foundation on the basics. Forgetting this also makes us feel overwhelmed by the simple thought of larger challenges.

The last sentence was about practicing magic, but the same thing can be said about programming, so read it again considering this context.

It is ubiquitous to say that we should focus on the basics before messing with more complex technologies and techniques, however most beginners don’t understand the reason for it because they seem to get by just fine without it until they face some task that requires it.

In these cases, we either freeze and get distressed or go back to the basics then we finally understand it. With this in mind, especially when you feel overwhelmed by a problem you’re trying to solve, remember that the foundation is what makes you face bigger challenges with more confidence, so make sure they’re solid.

Practice and experiment

Even though rolling a coin on your knuckles or flourishing cards are cool things to perform, these are not magic tricks. The only thing that will make you better at performing a trick is actually practicing, observing where the difficulties of each trick reside, criticizing yourself, and experimenting with variations and approaches to improvise in case something goes wrong.

Practice and experimentation lead you to be more prepared.

The gist of this idea is not too different when it comes to becoming a better programmer: pairing theory and practice is a very effective way of discovering your knowledge gaps, things that you assumed you understood when reading but noticed are not that simple when you got your hands dirty, but there is one crucial difference between practicing magic tricks and programming: the way we do repetitions. When practicing magic you try to perform the same trick as much as you can to make sure that you actually understood how it’s supposed to be done, but if you do that with programming you will not become a better programmer, you’ll become a person that is better on typing the same sequence of characters in a text file, and this is not what we want.

When practicing programming, try to find challenges that depend on the same set of skills you’re trying to exercise, that are different from the outside but similar in essence. For example, let’s say you’re studying JavaScript promises you could try to implement a to-do list application, then a blog engine, and so on. Notice that while both of these examples are very different, you will need to understand very solidly how promises work to implement them properly. Here’s a list of links with ideas for you to practice, try to filter the ones that are relevant to your case:

Observe other magicians

As stated at the beginning of this article, magicians get better at what they do by finding out how a magic trick is done rather than getting frustrated when the mystery comes to an end. Sometimes it isn’t a simple task to figure out how a trick works. You have to watch it multiple times, observe the details, imagine the parts that the magician hides from you or distracts you from, and even try to produce the same result yourself. Notice that trying to perform the trick includes imagining the missing parts because most of what you know is the same as the general audience does, and sometimes there are gimmicks that you never saw or imagined that require some research.

This mindset should also apply when you face a problem you’ve never seen before, or when you bump into a solution for a difficult problem without access to the source code. In circumstances like this, it’s effortless to get impressed and think that the solution is probably too complex or ingenious for us to understand, but fear not!

It’s not because you don’t know firsthand how to solve a problem that you’re not capable of understanding the solution for it eventually.

A good part of what makes us evolve as programmers it’s based on curiosity and observation, so wondering how an existing solution for a problem is implemented and trying to understand its implications can be a very powerful stimulus for you to explore new concepts. Let me give a concrete scenario to think about:

When I started using Trello, I really liked it, but I saw it as a basic application. Of course, it had fewer features back then, but I still wasn’t aware how much I underestimated the complexity of the application until I tried to create a clone to practice full-stack development. The frontend part was fine, and there were some available libraries to do drag-and-drop already, but when I got to the reordering feature it’s when it got me.

I beat my brain out a couple of times until I came up with a set of REST endpoints that I could create to send the reorder request to the backend. That should be enough, right? Well, not yet.

How was I supposed to persist the order of the cards from a list in a SQL database? Should I store the card index itself in a column? But what if I move a card to be the first on the list? Will I have to update the index of all the subsequent cards? That doesn’t seem like a good approach. Ok, maybe it should be stored as a linked list to make updates easier? But how will I order the cards efficiently? These questions exposed me to a series of possibilities that made me think about their tradeoffs, research this problem, and even check for some open-source solutions.

The way I solved it isn’t important to the scope of this article because the point is: observing Trello and the curiosity to try to understand how it works made me a better programmer.

Sometimes after investigating a ready solution, you might get frustrated by thinking: "I would never have thought it myself." or even "I don’t know most of the requirements to understand it." and that’s fine, don’t allow it to let you down, a lot of the human progress happens like this, don’t feel bad just because at that point you didn’t know everything needed to solve the problem because now you do, or at least you know what the requirements are to research it, use it as a support for your next explorations!

Don’t be afraid to be inventive

One thing that makes it hard to create a new trick is when there is no documented technique or art to enable what you’re trying to perform, but good magicians enjoy this part as well! At some point in history, most of the techniques used in magic tricks also didn’t exist. They had to be either invented or technologies to support them had to be developed, like a trick that depends on mirrors in a society where mirrors are not available yet. Magicians won’t give up an idea just because nobody has tried to do it yet, they will think it makes it even more exciting to do so, and they will try to engineer new ideas, break the limits.

Don’t think something is too difficult to achieve just because nobody before you did it or made it openly available.

When we’re early in programming careers, it might feel overwhelming to come up with new ideas, challenging the status quo. We feel as if nobody we consider "smarter" than us did it, we might not be capable enough to do it either.

By thinking in this way, we end up capping our progress instead of enabling new possibilities, so don’t be afraid to be inventive when you face some new challenge, don’t rely only on open-available solutions, and even allow yourself to question the existing solutions to reach for better ways.

Sometimes it might feel like you’re re-inventing the wheel, especially if you try a new solution and end up at the same place the existing ones got, and this is also fine: re-inventing the wheel is perfectly acceptable if you’re studying how wheels work and can be improved.

Unravel the magic

One of the most important traits of a magician is being confident that they can, and will, unravel the magic. They know that if someone can do something, someone else can do it as well, so they don’t tremble before the challenges, they get empowered by them, and they know that with patience and endeavor, they can crack it.

Think this as the same way of thinking you should apply with programming, don’t see the problems you need to solve as something bigger than you, but rather see them as something that you can, and will, overcome.

At this point, I hope I was able to make you see more clearly what I meant by saying that, by comparing magic tricks with programming, we should act like the magician rather than the audience.

So now, for my last trick, I’ll saw this analogy in half.

There is one crucial point that makes magicians different from programmers: magicians try their best to hide the gimmicks of their tricks, they try to be mysterious, and when people find out how they do the trick , it usually means that they are now less impressive, but this is not true for programmers. When you develop a solution for a problem, and later someone discovers what you do or get to the same conclusion as you, this is good, it means that more people support this idea, this is how things like design patterns arise. This is something that should give you more confidence!

Abracadabra.