Programming explained to your mother ! #

So I start with a heavy burden, that I've been carrying for a very long time. As a software engineer, the question you most often have to encounter is : "What is it you do already ?". It's often brought up by a family member, your aunt, your grandfather and even your own mom.

It's not that I don't know what I'm doing, I know what, when, how to do things. But the fact is that I don't now how to explain it clearly to people other than my pairs. At the end, I'm escaping the question by answering at what's the company doing, and what's my place within it.

So I need to find a way to explain to those who don't have a clue, in the simplest way possible, what it is I do all day and thus, without giving a course on how a computer works and such things. Plus, it has to be short and memorable, so that next time, the conversation can be strengthened and more interactive.

Pfiou! A lot to think of. Where do I start ?

From the myths #

Let's first break the unfounded rumors that people think programmers are, and make facts out of it.

"You're some kind of scientist, working at the computer"

Well, picture a dude wearing a white coat and playing with rats all day long. Now, just trade the lab for an office, the coat for contextual clothing and the rat for a computer.

Computer engineers works in multiple fields, accountability, military, NASA, research, labs, finance, modelization, maths and much more. In fact, for almost every work on the planet, there's probably a computer doing part of it. But the computer cannot work by himself, its has to be "taught" how to perform so. And that's part of the computer engineers role.

So, when I say "contextual clothing", I mean, that we wear the same clothes that our colleges do, in the field we're working on. If you're working in a lab, then it'll probably be a nice white coat.

"So you guys are just nerds, sitting at a computer all day !"

Yep... That's pretty much it. Done !

Spending all day in front of a screen is part of our jobs, but it does not explain the job itself. You can sit all day long at the computer all day long, scrolling your Facebook feed, you won't make an engineer out of it.

In our jobs, we mostly have to write a manual for the computer, so it can do what ever we need it to perform. This is what we call code. Some manuals are long, some are short and some others are referring to other manuals to work. What a manual and code does, is to describe how to do a task, one in english the other using one of the multiple languages that computers understand.

For example, to make a manual on how to clean the room, I have to refer to manuals that describes how to use a vacuum cleaner and how to fold a shirt. If those manuals are transformed in a computer language, then a robot, which is a self moving computer, could clean a room.

For a code example, to make the sum of a list of number the computer code would be this :

var numbers = [5,8,5,7,6,4,9,4,8];
var sum = 0;
numbers.forEach(number => sum += number);
document.write(sum);

And could be written this way in english :

Given the following of numbers (5,8,5,7,6,4,9,4,8) and a sum that is initially equal to zero. Go through each single number in the list and add it to the sum. When done, write down the sum.

We do all of this in front of a computer, so we can count quite a lot of days, spent in front of a monitor trying to make the computer make we described in the code.

And yes, some of us are the college nerds you once knew. First, it's relevant, and second, WTF! As a matter of fact, it's probably those girls and guys that performs the best.

Who rules the world ? Nerds !
—Beyoncé

An application, is simply the code/manual used and applied to a computer, phone, tablet, to obtain the expected result.

But any manual has flaws, and that's what we're calling bugs. This is when the manual cannot manage a special case. And when a manual surprisingly works properly on a case it shouldn't we call this a feature.

"My computer is buggy, that's your fault !"

There're many ways to find a case that doesn't work, the easiest is to try to use it for things it isn't built for. As an example can you use this manual to fold a Barbie shirt? Does it work on Hagrid's shirts ? What if the shirt is the size of planets ? What if the vacuum cleaner is not plugged in?

And then what happen if I change the type of object the manual applies to? If, I try to use the vacuum cleaner to clean the cat. Or if I swap a dependency, and uses the manual for petting a cat instead of the one on the vacuum cleaning; could I still manage to clean a room ?

Those are called edge cases, when the manual/code is not made to endure some extreme cases. To fix then, should I upgrade the manual to manage those cases, and therefore, create conditions to manage those extreme situations. Or should I just define those situations as exceptions that the manual/code can't perform with ?

Those cases are sometimes the developers faults, but it's most commonly the user that tries to do something with the code or application that it wasn't designed for. That's also why, in parallel of the code, and in parallel of an application, there also is a manual, this time, for human to read and understand.

Now, computers are complexes systems, working with millions lines of code. And it happened that some of these lines are slow for a computer to process. As an example, it's pretty easy for modern computer to display an image, but it's much more difficult for it to generate one from scratch. The same way it'll be easier to human to show a photo than to paint it.

"Just some code monkey."

The infinite monkey theorem states that a monkey hitting keys at random on a keyboard for an infinite amount of time will almost surely type a given text, such as the complete works of William Shakespeare at a given time.

Thanks god, that's not how we (should) work. First, we aren't working on random tasks, the program we're working on is designed for a user, and therefore, has some precise defined tasks to perform. We first need to define what is the program expected to do, what will the user will put in and what will come out.

If we take this back to a most common issue; a farmer wants to transform its cereals. The input is the wheat, the output is flour, so we need to find a manual that defines how to transform whet to flour.

Once that's define, we look at what is available on the market that could be adapted to the context of the final user. Here a windmill would be a nice solution, but since the farmer lives on a valley nearby a river, we have to adapt the manual to work with a river.

Only then, once the schema of the expectation are well defined we start writing a code that will do just that. And we test it against all the situations we might have or think of.

The testing part does not apply properly to the mill example, because you cannot build multiple mills to check if the blueprints are OK. But at large scale this is the way to check if everything is working well. Picture a car, how many crash tests did it went through before being available on the market ?

So it's not just about writing computer code, it's also about defining who are the users, what do there needs, what do there expect, what is the context, what are the constraints, how to build it, how to make it resilient, compatible... And only then we write code.

Wrapping up #

Computer code is the way to write procedure for a computer to understand and perform. This code works pretty much like a manual, only it's written in an other language specific to computers. To do so, we need programmers who are people who knows how to do such things. Some are engineers but you don't need a PhD or a MD to do so, some of the best and amazing tech available was initially made by people with short scholarship background.

To do so, we focus on a specific task and on how to do it as well as possible, meeting with client, brain storming, defining the best way to do it and only then sit at the computer to write it down. Once done, we confront it to the initial need to check if the results are correct. Then we check if it reacts properly when facing extreme situation, trying to tackle as many bugs as possible.

So what it is you do ?

I use my knowledge in computer science and engineering to teach computers how to answer very specific problems. To do so, I encounter the client and define the requirements with him. Then I workout ways to obtain the expected result. Then I write the manual to do so, for the computer, in a computer language that's called code. Finally I test it against multiple situations to check if it gives proper results and is resilient.