Output Stream of Consciousness

While I was chatting away in World of Warcraft, while I was on one of the interminable transport rides, someone asked exactly what computer programming was all about. It was an intriguing question to try to answer in a non-trite manner.

So, before my thoughts on it disappear, I thought I might just answer the question for all.

Computer programming is telling computers what to do. Computers are extremely stupid. However, they're very fast at being extremely stupid.

Especially these days, you rely on other people having done a lot of the programming work. "You mean like stealing it and putting your name on it?", my erstwhile chat partner asked. No, not like that (though there are people who do that, too!). Operating systems are big collections of lots of programming that other people have already done.

For example, in part of my program, I can put in "MoveTo(DisplayContext,0,0); LineTo(DisplayContext,50,75);" to draw a diagonal line in Windows.

I've been programming long enough to remember just how hard it really is to tell a computer to draw a diagonal line. Computers don't really know what a diagonal line is.

There's a way to figure it out using math, but surprisingly, computers don't really know math, either. Well, not in the same sense that mathematicians do.

Computers can add and subtract really easily, but they haven't a clue how to solve anything. Some math translates easily to instructions, some does not.

An old way of drawing diagonal lines uses Bresenham's Line Algorithm. It's pretty simple, but not totally trivial. It also does not show the parts where you actually prod the hardware into showing

So, over the years, we have collected a lot of these things into operating systems and shared libraries. We have also collected some things into computer languages. Computer languages like C, Java and Delphi are not the instructions your computer understands. They have to be translated first. There's a good reason to use C, Java or Delphi instead of putting raw instructions together. Computer raw instructions are ugly as sin.

Even assembly language is not native computer instructions.

It's pretty easy to take for granted the fact that a computer language will just calculate all the 'jump to this instruction' instructions for you these days.

Now, leaving aside all the deep, deep detail, what about computer programming in a larger sense?

Well, it's still telling a computer what to do, but it's all about managing your project. After all, there's no sense telling the computer what to do and then throwing everything out, unless it's just an experiment.

A large part of this is writing your computer programs so that you can read them later. The computer itself does not care how ugly your program code looks to the human eye. Calling your piece of code to draw a spiral "WheeLookitThatGo()" will work just the same as calling it "DrawSpiral()". You're the only one that will suffer. Unless you have coworkers, in which case, they may suffer with you.

Some people say that making HTML for web pages is not programming. I would say that it is. It's a matter of balance and what you want to do. HTML let you do some interesting things, but you do not have access to everything your operating system can do.

Using C instead of HTML lets you do pretty much anything. However, the amount of effort you need to go to can be huge, and C will not prevent you from doing bad things, inadvertently or not :)

The choice of what you use is chosen partly by what you know, partly by what's the most productive, and partly by limitations that you cannot live with.

So what else is involved in programming?

Skills in debugging, for one. Debugging is the ability to find out why something is going wrong.

Sometimes, it goes wrong on your own machine, where you have all your tools at your disposal. Plenty of things can go wrong, and modern programs are very complicated. The other day, I had a bug where the second time I showed a login window, pressing OK would not do anything. I found out that my "AlreadyAnswered" value was true, and was not being reset to false before I showed the window again. Bugs like this happen all the time.

Sometimes, it happens on other peoples' machines, and that can be aggravating. Sometimes, what's going on is misreported to you, but often, a change in environment can do it. Perhaps you create a file based on the user's name, and they typed in their name as Wal*mart - '*' is often not allowed as part of a filename. More than anything, debugging this sort of thing requires patience, persistence, and good rapport with whoever is having the problem, or at least whoever is helping the person who is having the problem.

Other skills: design is a skill that you may not need if you're part of a larger team that already has a designer, but some skills here are required. This can consist of how to make pieces fit together the best, and how to split out the pieces in the first place, as well as how the logic flows.

The difficulty: there are many designs that can get your the same functionality. You can load all clients into memory and look them up by customer number. You can leave them all in the database and look them up individually when client information is requested. The first design works very well for a small list of clients, but will fail miserably when you have hundreds of thousands of them. The second design might work better for hundreds of thousands of clients, but if you ask for the clients a lot, the time spent asking the database can be very slow.

A more complex design that would work would be to keep often-requested clients in memory, and go to the database for everyone else. It's a lot more complicated, though, because it requires all sorts of decisions like "how many clients should we keep in memory", "how do we tell whether a client should be kept in memory?" and "how long should we keep them in memory?"

There's a lot of compromise and foresight involved, especially if you want to help design big systems.

There are a lot of other things that programmers do. Writing automated tests can be boring but can prevent a lot of embarrassment when you accidentally break something but didn't know (that can happen a lot, actually). Using version control systems keeps older versions of your code around and lets you share code for a big project with other developers. Making estimates of how long things will take is an excellent skill to have.

Above all, computer programming is first and foremost a creative trade. Even if you're generally being told what to do, there are usually incredible numbers of ways of doing it.

Since it's a creative trade, mood is important. People can crunch numbers and fill in reports if they're feeling a little off-base, but interruptions, icky moods and the like can throw off your programming acumen and productivity. Scribbling, discussing with other developers, and sometimes even just "sleeping on the problem", if it's a particularly nasty problem, can all help.

Math skills occasionally help, though you don't need tons of math skills. Unless you're being contracted by NASA for something, or you're the lead developer on a multi-phase petroleum flow analysis project, your chances of having to use calculus or any higher college pure math in a programming project are pretty gosh-darned slim.

Above all, taking pride in work and skills, and improving is what makes a good programmer. This is a field where just "being in it for the money" doesn't help much.

A bit of a ramble that, and I know I've missed great big areas like "what's object oriented programming?" and the like, but I'll save those topics for another day.

Questions are most welcome :)

Comments:

Wow, that must have been one heck of a transport ride. I should have mentioned in our conversation later that night that a good reason I don't get bored with my job is the variety of things I do. A day usually can consist of testing, merging, building, and the odd bit of development here and there. Always lots of things to do for a change of pace.

I know what you mean about interruptions though. My neighbour in the cubes is not too easy to tune out a lot of the time. I look forward to a new arrangement after the move. Some noise-cancelling headphones are probably in order too.

Comment by ElTwo [Visitor] — 12/15/05 @ 02:05

He must have been flying from Auberdine to Theramore; that's the longest griff ride (or ride of any type) I can think of in the game.

One advantage that L2 has is that, with a few exceptions, he doesn't have to deal with people. And you thought computers were dumb?

Comment by Adam [Visitor] — 12/15/05 @ 12:26

I didn't get this bitter and jaded by myself. It took years of customer service at CO-OP to get where I'm at now. :)

Another reason to be thankful for the career change.

Comment by ElTwo [Visitor] — 12/15/05 @ 18:18

I'm trying to remember whether there's a route from Gadgetzan to Auberdine. I do remember being on a very, very long trip one time. I was new to Kalimdor, though, and wanted to watch all the scenery to see what I was passing over. I think this ride was shorter, but all the Alliance-related flights seem to require going through Auberdine. I was on my way from Feathermoon to Auberdine - can't remember if that was one trip or two.

We moved and rearranged at work. I share a small office, and thank goodness, because we can close the door. Support is right nearby, and they use speakerphones... a lot. We can shut it out, but other people can't - I can sense there will be some climbing irritability in January when everyone's back.

I never get bored at work per se. Just frustrated. I'm good at what I do not really just due to any smarts I may have, but my ability to start concentrating and weaving skeins of thought around many different parts of the same topic. The initial phases of design and heavy debugging are particularly like that. But, it's like juggling - if I'm doing something easy, I can keep going even with interruptions, but if I have five balls in the air required to do something, interruptions make me necessarily drop them all, and because it was a "five-baller" to begin with, getting back on track takes ages.

I just like being productive, really.

Comment by nimble [Member] — 12/19/05 @ 11:51

The unpacking continues at our new office. The loudest thing right now seems to be the air-conditioning. It cuts on and off periodically and it's about the volume you'd expect from a server room, but in a main work area instead. I've noticed a few people keeping their jackets on throughout the day.

I know what you mean about concentration. With a number of equal-priority problems coming in at the same time, I sometimes fall into a scatter-shot approach that doesn't always get much accomplished.

Comment by ElTwo [Visitor] — 12/20/05 @ 21:04

I guess if that ends up being the worst noise, you'll be okay, but things are probably running on a skeleton crew right now. Maybe printer sabotage is not out of the question.

Too much air conditioning sucks in a job where you make most of your livelihood by typing. Coooold fingeerrrr (insert James Bond music here)

One nice change at work is that we actually have a test lab. I can hear the high, high frequencies, and it's not diminishing with age yet. We have had servers in our room with high-frequency squeaks in their hard drives on occasion, or monitors with fast-vibrating ferrite beads that just drive me crazy when they're on. Adds to the mythology that I'm crazy, I know (nobody who's been into our little office apart from me can hear it), but I'm so glad those things are out of there (we had squealing monitors on the test boxes - not often turned on, but ouch!).

What else can you do sometimes other than a scatter-shot approach? One thing I've found is that when things go awry for one reason or another, you're almost always waiting on the results of a test or someone to phone back or something, and that really makes it hard to sit down and concentrate on anything, because you'll be asked to switch directions at any moment.

Comment by nimble [Member] — 12/21/05 @ 02:39

Actually, what I find is that frequently one complaining customer helps me solve problems for another. As I'm trying to track down a problem I often head down avenues I don't normally. That then tends to cause the "Oh, that's funny" syndrome which causes me to click for a problem raised by another customer a while before. It's a bit disorienting at first, but being pulled in unexpected directions does have some positive effects.

Of course, then you get the clients who do complain about anything and everything. You then spend your day corralling them and their complaint to try to prove it's them, and not the product, and that can be a bit frustrating. I don't know about your work, but I always assume we're at fault until I can prove otherwise on the grounds that the customers are supposed to be knowledgable, experienced people in their fields who'll do their own cursory investigation first. Sometimes they are.

Comment by Adam [Visitor] — 12/24/05 @ 17:04

I find that on occasion, but usually only with relatively recently-added pieces. I like to get to the actual root causes of the troubles, and not just papering over the symptoms, so when those things come up, I usually spend a while (occasionally it seems like "too long", but good things often come of it) digging around.

The product is mature enough that we've got a lot of the low-hanging fruit, though. A lot of the cool things we want require some serious refactoring in order to give us a place to put the cool things in. If We Knew Then What We Know Now (and had a lot more money so the pressure wasn't on as badly) Syndrome definitely applies :)

Comment by nimble [Member] — 12/28/05 @ 11:05