Jason Ogaard: Learning to write code not as hard as you might think
One of the polite things you can do with people you don’t know very well is ask them about their jobs.
What do they do? Who do they do it for? Where is the job located? Do they like what they do? How do they get along with their colleagues? These are all perfectly fine questions to ask someone. My issue with this is that I don’t really like to talk about what I do.
Most of the time when I answer with “software engineer,” the person I’m talking to says “oh” unenthusiastically, and then I try to change topics. Most people outside of software engineers don’t really know what we do and how we do it. It also doesn’t help that we’re portrayed as hyper-intelligent social skill-less outcasts in the media. Sometimes people will ask a question along the lines of ‘So you just type 1’s and 0’s into the computer all day long?” The short answer to that is “no”; the long answer will come later).
In my last column I described open source software and the merits of having source code available to everyone. It has since become clear to me that not many people know what source code is. I would like to try to explain to you what code might look like and how it works.
When people ask me about 1’s and 0’s, they’re not technically wrong. Computers deal only in 1’s and 0’s. Technically, if I really wanted to, I could write all my code as 1’s and 0’s. The problem with doing that is that the meaning behind the code becomes lost quickly. Humans aren’t that great at reading or remembering long numbers, let alone trying to translate them to some English meaning. Humans are pretty good with words, though.
In order to make writing software more efficient, it makes sense to use words that form a logical sentence. Those words are then entered into a program called a compiler. The compiler turns those words into 1’s and 0’s that can be interpreted by a computer. Once the code is compiled, you can build it into an executable file that anyone can install on a computer. Most of the code we write ends up inside what’s called “if then” statements.
It would look basically like this:
if some statement is true
then do something
For example, let’s take my schedule for writing columns. A logical sentence for that could be the following:
if today is Sunday
then deliver column.
There’s one problem with that though. I don’t deliver a column every Sunday;I deliver a column every other Sunday. To keep track of which Sunday it is we could use a count and check that count. Something like this:
if today is Sunday
then count count + 1
if count is an odd number and today is Sunday
then deliver columnWith this logic we have a count that increments by one if the day is Sunday. Then we check the count and the day. If I were to publish this (rather simple) code for anyone to use, others could take it and add features to it or fix bugs in it. This is the advantage open source software gives us. Anyone can download the code, modify it to his or her desire, compile it, build it and redistribute it as an entirely new program.
Anyone can learn how to write code. If you’re interested, codecademy.com is a terrific resource for beginners.--
JASON OGAARD was born in Bemidji and is a software engineer for FICO, a Minneapolis-based public company providing analytics and decision-making services, including credit scoring credit bureaus.