Imagine you’re holding a hot mug of coffee. Assume this is a very important task, so do it very actively. What do you sense? Here are some of the things I can offer if you’re being lazy and unimaginative (coughs):
- Smell. It smells good ==> It’s the aroma of coffee.
- Taste. It should taste good. ==> It’s coffee and I know what it tastes like even without tasting this specific batch.
- Touch. I feel the mug. ==> That’s the handle of the mug. ==> Each finger has different pressures at different points
- Temperature. The mug is hot ==> If the mug is this hot, then the coffee is much hotter ==> Maybe I shouldn’t attempt to drink it yet, lest I burnt my precious lips
And so on…
So an ordinary task like that can be chock full of information based on how much attention you’re giving it actively. Let’s take the temperature point as an example. The key here is to understand that at every step, we’re trying to perceive something (the mug is hot) and connect it to what we already know (the coffee is hot, but you didn’t touch the coffee itself right now!) and finally we’re reasoning about (it’s not the mug that’s really hot, it’s the coffee in it).
Now this whole process happens so fast that you don’t notice these dimensions unless you pause for a zen state of mind. But you’ve built this model of perceptions and inferences over your whole life which is why it’s so obvious (unless you begin to probe too deep and end up at…quantum mechanics?! I don’t even…). I’ll repeat again: Most of what we do that seems “obvious” is only “obvious” because you have done a lot of work to develop a “sense” of it in the past and you’re probably doing it right now too but you’re simply not aware of it because your active attention is elsewhere.
If you understand this, you probably know both zen and programming. You’re enlightened. Go on now. Spread the message. You must.
No? Okay. Now, I’ll address the title of this post: Coding is initially hard because you don’t have a model of sensing or feeling what it is, what it does and why you should care. It’s absolutely horrible because you can’t use your existing physical senses to understand.
In fact, this characteristic is so in-built that there is a word for it: abstraction. Yeah, you probably heard but you don’t know it well enough.
“I learned very early the difference between knowing the name of something and knowing something.” – Richard P. Feynman, World-class physicist and all-around fun guy to hang out with
Everything in code is an abstraction away from physical reality but derived from it. if that sounded unnecessarily verbose, ignore. Just understand abstraction is why you’re forced to learn so much stuff that is code-specific: binary math, code complexity, data types, data structures, algorithms, higher abstractions, etc. Abstraction is why you may feel you don’t get it.
You might think using algorithms for say, searching through your head about “What % fat milk did Mom ask me to bring again? Ugh!” but you don’t say it, can’t express it or analyse it or improve much upon it. Because well, it takes too much time to run experiments on your slowly-but-over-a-long-period evolving brain but hey, in code, that’s easy. Sometimes too easy. And guess what? This gives you a lot of power: the fact that you can break your code 1000 times and if it works the 1001th time, it’s worth all the petty failures. It doesn’t even matter if it’s spaghetti code because it works! You made something that has a purpose and now, you can spend time on it and make it better…if you care about it. Or you can open-source it and if someone likes it, they’ll use and/or take care of your code.
For a beginner, this means that once you’re done playing around with loops and conditional statements, you should question things you took for granted: what is a variable? where is it stored? and so on. Not just these questions but ask as much as you can. This is the only way you’ll have a better idea of what’s going on. Eventually, you want to be in the zone/flow-state when you’re coding and you can do that only if you’re able to lose yourself in a richer, more vivid model of how programming works. And if you’re stuck with a bug, you need to really get this drilled into your head: programs are deterministic. Computers only do what they’re told to. This is obvious but you don’t understand it until you understand and accept its consequences. One such consequence is that if the program didn’t do what you thought it would, the fault is in your code, not the computer. To be blunt, it’s right in front of you. Sitting in those files. Or maybe it’s already in the open, in your editor. Waiting to be found. And when you find it, oh boy, you’ll squash it. And reign supreme. Sorta. Practical advice? Write your bug-squashing experiences in a blog or private journal so that your future self can know it wasn’t obvious in the past. Why? It’s like my mathematics teacher told me in school: “If you derive the proof yourself, you’ll understand it much better.” So, create your own proof to remind yourself nothing is obvious.
For above-beginner, it’s important to immerse yourself in coding to understand intuitively what each thing a programmer does really means. This means delving into design patterns, algorithms, data structures, writing documentation, version control, etc. But don’t make the mistake that I made. Don’t spend time thinking you need to know all of this. Noone does. There is no perfect programmer or a program with zero bugs. They simply don’t exist. No, don’t even talk to me about programming wizards and 10x engineers. Those are buzzwords. And buzzwords are for products, so that you can sell them. Not for humans. You and I can’t be packaged into a nice box or be offered to someone as a subscription deal.
It’s like life in general: everybody is a work-in-progress. All you can be is a humble learner with limitless curiosity. Pay attention actively to the task at hand if you want to understand the characteristics of your code clearly. Learn as much as you can. But most importantly, master abstractions. Everything another person wants to communicate is just abstracted into the code you’re reading. Every line of code you’ll ever write is a translation of your thoughts abstracted into code. Intuition is what you’re really looking for. Rest all are details that can be searched on Google or Stackoverflow.
P.S.: If there is someone reading this and is suffering with impostor syndrome, I’ll make it clear. You’re doing fine. You’re learning. Your workflow has changed. Your routine has changed. Your code has improved from that shitty hello world program and will continue to improve. Just remind yourself that what’s obvious to you isn’t so for another who just stumbled onto the field as a beginner. She’ll have to go through all that you did and it won’t be obvious for her. So smile a little, help those who are stuck, and don’t be too hard on yourself. Great code takes time to write. Great programmers take time… to just BE.