Into the Programmer’s Mind

A brief introduction to programming

If you are interested in how programmers think or in becoming a programmer yourself then this article is for you; it doesn’t matter if you’ve ever written a single line of code, buckle up because I’ll take you on a journey into and through the programmer’s mind. The hope is for you to leave this article with a better understanding of what programming is and how programmers think.

Programming is the term I’ll be using, some people call it coding, and others call it software engineering; different people use different terms, and despite the minor differences in definitions they’re all pretty much the same thing. So, what is programming?

Programming is the abusive non-consensual act of commanding a stupid piece of hardware to do math for you so that you can relax and sip on your coffee instead; that of course is the purest of definitions for programming, but let’s try a nicer definition. Programming is the act of talking to a piece of hardware to have it do something for you. For the sake of simplicity moving forward I’ll use the word computer instead of a piece of hardware; personal computers, mobile phones, and smart fridges are examples of what I mean by computers.

Computers, unluckily, can understand one and only one language; that language is called Machine Language, which consists of 1’s and 0’s. Fret not my friends, you won’t have to speak that language.

What you do have is hundreds of languages to choose from instead, because unluckily again, people realized machine language is too difficult to master so they invented new languages, many new languages mostly using the English alphabet but are not English, and then introduced many translator programs (called compilers or interpreters) that will translate that language for you to machine language.

That, of course, wasn’t enough for some people, so they decided to write more translators on top of translators, creating a complex chain of translations down to machine language. Some people went so far as to create virtual machines that understand completely different languages with their own chain of translators on top that will eventually translate whatever they’re running into machine language. This of course proved to be extremely beneficial, but we’ll leave that topic for another day.

This pattern of constantly trying to figure out and refine things is a very important commonality between programmers; it’s also one of the most important things to keep in mind as you start your own journey as a programmer. Nothing is perfect, and the path between you and your goal is far from being straight.

Programmers try to solve problems all the time; it’s not perfect, and there’s no one right way to do something.

Throughout my time as a programmer I met so many people who gave up on themselves because they didn’t think they were smart enough; this misconception is partially because of the way we test students in our education system, and how far that happens to be from real-life programming. The other side of that coin is the way our education system makes it seem like there’s only one way to solving a problem.

I remember when I was taking my bachelor’s degree in Computer Science in one of the exams we were given a question with most of the solution code written, and we only needed to fill in the blanks, on paper. Not only were we required to remember how to perfectly write code in a given language, but we were also expected to know how the professor was thinking when he wrote the partial solution.

In my own journey as a professional programmer I found that if you understand logic, then you’re good to go; it won’t be easy, but you’ll be able to do it. If you don’t have a great understanding of logic then luckily you can practice as you go. In summary, you can do it no matter how smart you think you are.

To battle those thoughts, just keep in mind that we created the machines, not the other way around. Machines are not smart, they’re just efficient. We are here to take advantage of that however we see suitable.

Computers are stupid, and you’re boss.

Expecting to perfectly remember how to do everything in any programming language is absurd, and even expecting to perfectly remember how to write code to do simple things, such as creating a button that does something upon clicking on it, is not always reasonable.

That might come as a surprise to a lot of aspiring programmers such as yourself; the truth is, programming languages come to life and drastically evolve very often. Luckily you have documentations to refer to whenever you feel the need to do so.

If that was true, I hear you ask, then what do you need to learn and remember? Well, you need to learn and remember the what, and not necessarily the how. You will naturally remember the how as you practice, but as you learn focus on the what, this way you can always look it up again.

For example, if clicking a button is initiating a time consuming computation that freezes your application’s user interface you have to understand that you’re dealing with a threading problem; you should know what a UI Thread is and that what you need is multi threading. Knowing how to implement those can easily be searched as long as you know what you’re looking for.

As long as you remember the what, you can look up the documentation just by searching on Google. Yes, Google, and every programmer no matter how senior uses Google (or a similar search engine) to look up things all the time, and that’s fine.

Programmers don’t always know how to do something, but they know very well what to look for.

Much of the difficulty of programming lies in translating our thoughts into code; it’s not the code that is difficult, it’s the translation.

To give you a simple example imagine yourself programming a calculator; more precisely let’s say you wanted to implement the division operator. You create three text boxes, A, B, and C, and a division button. You say C = A / B. Now you put 5 in A and 2 in B and click; lo and behold you get a 2 in C.

Turns out, in that specific programming language you’re using, if you divide two integers such as 5 and 2 then the result will be an integer as well. You Google that and you quickly learn that you have to convert A and B to a Float first.

Next you do C = A.toFloat() / B.toFloat(), you put 5 and 2 again and you get 2.5. So far so good.

Now you put 5 and 0 and all of a sudden everything goes down in flames. Turns out computers are so stupid the only way they can tell you that you did something wrong dividing by 0 is by crashing your whole application. Great, now you have to manually make sure that B is not 0 before you actually do the division.

You write, If (B != 0) Then C = A.toFloat() / B.toFloat(). You run your code, you put 5 and 0 and the application does nothing. Good start, but is that what you want? Maybe you want to show something to the user.

In your mind the problem was straightforward; divide A by B and put that in C, but to say that in a programming language you have to be super precise. That was a simple example; what if you want to do animations, with navigation, with interactivity? What if your code is too slow and you need to make it run faster?

The good thing to remember here is that trial and error is not a sin; you can do it as many times as you’d like until you feel confident in what you have created. A lot of the times other people have tried something similar to what you’re trying to do, and so again, Google and documentations are your best friends in this case.

It’s difficult to translate human thoughts and processes into code that the computer understands.

So how do you translate an application from an idea in your mind into a computer program? One of the important things that programmers do when trying to solve a problem or write an application is to take the idea and chop it into smaller and simpler pieces.

For example, let’s say you want to build a calculator; on which platform do you want to run it? Windows? Android? iOS? Next question is, which framework do you want to use? Do you want to do Native Android or Hybrid Web? Those options are things that you can Google after deciding on the platform.

Once you have your mind made, you need to think of the smaller pieces that make up a calculator; buttons, text fields, and the actual code to do the math. How do you build a button using the framework you chose? How do you build text fields? How do you write the math code in the programming language that framework supports? How do you hook up the buttons to that math code? All those questions can translate into steps that you can take to build the entire calculator.

For beginners, I recommend going from the visual to the unseen; in other words, I recommend building buttons and text fields that do nothing first, then write the math code, then hook up those parts together. As you advance in your journey and you become more confident, going the other way around would be a recommended approach.

Programmers think of problems like a jigsaw puzzle; they are aware of the big picture but spend most of their time building the individual pieces, then they hook up those pieces together.

So you built all the pieces, you hooked them up together, and you ran the application…something goes wrong. Maybe the application crashes. Maybe it has unexpected behavior. You’re not alone; in fact, getting an application to work perfectly on the first run very rarely happens.

I remember once I was asked to research making native iOS applications. Setting things up and running my first empty project was fairly simple, then I wanted to create a second page and navigate between the first and the second page. First day I couldn’t get it to work, second day I couldn’t get it to work, third day, fourth day, it took me a full week just to get a simple navigation back and forth working.

The moral of the story is, it is very much expected that things won’t work correctly at first, and it’s very much expected that you’ll have to deal with bugs and crashes that might take you hours, days, and sometimes months to fix. If you fail, learn and try again. Sleep on it, it helps; I can’t tell you how many times I spent a full day on a problem only to resolve it first thing next morning.

Programmers realize that if they spend enough time on a problem, eventually it’ll be resolved.

After you finally get things working you need to test, then test again, then test some more. At some point you’ll venture into the world of unit testing and UI testing and all of that good stuff. No matter how much you test, however, it’s highly likely that you’ll get some users that have a bug or two. Maybe it’s that browser or that phone they’re using, and if you’ve set things up correctly you’ll be able to take a look at those crashes.

No matter what it is, that kind of scenario should be expected and planned for. As a programmer surely you do need to have your applications tested before you send them out to the public, and you aim to give your users the best experience possible, but if bugs occur you fix them and move on. Programmers are not afraid of creating bugs but are eager to get them eliminated.

Programmers create and fix bugs all the time; it’s not just you.

Once you get the hang of one platform, one framework, and one programming language, a plethora of gates will open up to you; the technology might be different, but the process is pretty much the same for all other platforms, all other frameworks, and all other programming languages. If you did it once, you can do it again.

Programmers start their ideas with the problem they’re trying to solve, then move backwards to the technology they need to use to solve that problem; not the other way around. If you find yourself trying to figure out what you can do with a specific technology then you’re going in the wrong direction.

Programmers have confidence in their ability to learn and sometimes even create the technology they need to use in order to solve the problem at hand. That’s the attitude you need to have as an aspiring programmer, and it’s one hell of an attitude.

Programmers can and will learn any technology they need to learn in order to solve the problem at hand.

Last but not least, programmers think of themselves as creators, writers, artists, and they enjoy being in control of their creations. They enjoy writing readable, beautiful, and efficient code that will add up to useful and stable creations, perhaps used by hundred, thousands, and even millions of people around the world.

This is the mindset of a programmer, so if you feel like that’s something you want to do, if you feel that you’d enjoy this type of life, then don’t let anything hold you back. You can do it, and all the obstacles you stumble upon are nothing but learning experiences that everyone else down that path goes through.

Programmers are creators; they give birth to different applications and solutions, and they enjoy others using them.

I hope that you enjoyed reading this article and found it useful. Until next time, Dev Bites signing out.