Programming Isn't a Skill, It's a Mindset

Spoiler

Or as those darn scientists insist on calling it, ABSTRACT: A programmer isn’t someone who can write code, a programmer is someone who can think.

When most people speak of, are told of, or think about, a “programmer” as an abstract being, they either picture one of two things: Either someone in their favorite all black gear, sunglasses, and a lime green-on-black terminal window open with lines flying by (see also: hacker), if they’ve watched too many movies, or someone sitting at their computer with a text editor / IDE / pick your favorite app, typing code into.

They’re thinking of the outward skill of a programmer. Do not get me wrong, good programmers do need some physical skills, such as good typing, but by far, that’s not the majority. No. A programmer is defined by their mind. Their thought process, how they take a problem, disassemble it, synthesize a solution, and then find a realization of that solution (write it). A true programmer is someone who has strong logical thought, but with that pinch of creativity that causes those rare “This shouldn’t work but I’ll try it anyway” moments. A true programmer is someone who can hold vast amounts of concepts, concurrent thoughts, and state of what they’re doing in their head, at once, for extended periods of time. Writing code, or at least, knowing what to write when to write, isn’t it. Syntax can be looked up. The exact semantics required to turn your idea into computer (compiler, at least) understandable words and symbols are easily found online. But they are nothing if you don’t have a meaning behind your code, a concept to put into reality. The internet cannot write programs for you, but, it can help write your programs with you. We, as a collective entity, are the type of people not to back down from a challenge, but to poke and prod, take different angles, and try and find the obscure hole in the proverbial wall that causes it to all come crashing down. Every problem has a solution. It may be hard to see, it may not be intuitive, it may go completely against rational thought, but every. Problem. Has. A. Solution.

We are not hired because we can type for files in content/ into a terminal window, but because we knew that for files in content/ was the best way to accomplish the task assigned. I’ll repeat: Knowing what to write, when to write, is not the hard part. You’ll find that I myself, for example, can honestly claim to have touched dozens of languages in my spare time. Languages have their quirks, some differ on a fundamental level, some take some serious detours from convention, but all can be learned, in time, with a little thought. Without that thought though, there will be no success.

Once one starts to learn programming, they might know static, concrete, completely defined concepts. You might know how to read a string, print a string, and read a string from a file, but if I said “read a string, use that string as a file name, read it, and print it,” you would be lost. Why? You already have the building blocks, you have the components. But you don’t have the “glue” per se to attach them together, and that is something that cannot be taught, but must be learned. Once you’ve gone for a few years, your library of fixed, solid examples becomes a library of flexible, changeable templates. Suddenly, something slightly different from what the examples showed is no longer out of the question: you can abstract the problem enough to bring it back down with working code. And if the example doesn’t quite fit, you know enough to modify it to the point where it can. As you continue your journey, perhaps, you may find you can abstract problems out of the language itself and into purely abstract (drinking game now in effect on “abstract”) form. You don’t think about “Get a line from file separated by spaces” as code:

words = open("filename.txt", "r").read().split(' ')

But more of a “to-do list” of language-independent steps that bridge the starting point to the desired outcome:

* Take filename
* Open file (for reading)
* Read contents of file
* Split contents based on spaces
* Store split contents into array

As long as you know the semantics for any language, you can now do this. Congratulations, guess what can be found with an easy Google. Even better yet, soon blocks like this will move onto the same plane, meaning you can transpose the language between entire programs as long as every individual building block can be understood.

Naturally, this means that not everyone is cut out to be a developer. Some just… don’t have the mindset. They don’t like trying to remember that many things, or they don’t have the best attention span (myself included, actually) and can lose their train of thought easily, thus causing everything to come crashing down, you get the picture. In the end, some other fields like, for example, car repair (which, since I’m also certified in, I will speak about). Doing mechanic work is way more physical. Yes, you should memorize how to change a brake pad by yourself. Yes, failing that, having the ability to reason “if I remove the bolts going through the pad, the pad will be able to be removed” is valuable. But in the end, most of it is either A) available in some manual on the local shop computer, or B) something you’ll do so many times that it’ll become second nature. Brake change? Remove tires, Remove caliper and set aside safely, remove the mounting bracket if it’s in the way, pry old pads out, replace shims, clean new pads, put in, open caliper cylinder, replace bracket if removed, apply brake cleaner to rotor if touched, re-attach caliper, re-attach wheel, make sure to torque the nuts to spec. Sure it sounds like a lot but in the field it might take you 5 minutes to run through everything, assuming no major issues. Sure, the diagnostic repairman needs a similar level of reasoning to determine what’s wrong to begin with, but once that has happened, we know the fix, we apply the list that corresponds to said fix, done. Even someone that really doesn’t have their heart in it (hello) can still do it, just maybe without as much vigor. Programming…. is not like that. It’s, again, primarily mental, and someone who isn’t interested will, quite honestly, fail.

Conclusion

What I guess I’m trying to say after rambling in circles is this: if you’re new, learning, planning to learn or just curious: don’t be discouraged if you look at a code snippet and have absolutely 0 clue what’s going on. Don’t feel bad that of the literal hundreds of languages in use today, you might only be comfortable with one or two. This will all come in due time. Even if you’re experienced, googling syntax, weird bugs, or compiler errors is normal. Really! If you can take an assignment, break it down into its core problems and their desired end states, and find the steps to make that solution… then find the steps for those steps and repeat recursively until you’ve hit the most basic level? Well.. that’s all it really is. If you can do that, to me, you are a programmer. And finally, if you’re someone who’s looking at this and either realizing this isn’t what you’re cut out for, or are currently taking a course or two but really aren’t feeling it: I’ll be direct, move on. Nobody likes spending years going down the wrong road only to realize it’s not for them, and having lost the time and maybe monetary involvement associated. If that’s you, please, look at something else in the meantime. Find your true calling. However….. Do note. There is a difference between not comprehending the language and not comprehending the process. If you get a task in your programming class, know the solution immediately, can see it in your head, but… dread actually doing it because the language the class is using is just so god-awful that it makes you nauseous looking at it? You, my friend, would make an excellent programmer. Just not in that language. Try and finish the course, but look into another language afterwards to see if you can find something that’s more palatable. Python, C#, C++, and Java, to name a few, are all pretty common. Maybe you’re more of an assembly person, who knows? But if it’s not the code that bothers you, it’s the taking time out of your day to have to brainstorm, that is what I’m talking about when I say consider other options. Having to take a piece of paper, or explain to yourself, or a friend, is not bad. Not having the answer instantly is not bad. If this really is your field though, stick with it. Your future self will love you for it.

Rambling over, I’ve been Teknikal_Domain, signing off now. Have a happy day, everyone.