### Tek's Domain

#<NTA:NnT:SSrgS:H6.6-198:W200-90.72:CBWg>

# 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
* 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.