« October 2013 | Main | January 2014 »

November 28, 2013

Thankful for the work

About a month ago, a friend of mine sent me email asking me to answer a few questions about programming so that he could put together some advice for a niece of his who was struggling with computer science in her high school classes. I wrote him a reply and pretty much promptly forgot about it.

I came across it again this morning and what struck me re-reading it is how thankful I am that I get to do this work as my profession. So, while I'm thankful for a lot of things that I won't go into here, I'm immensely grateful that I draw so much intellectual reward from the work I do. Not everyone is so lucky.

Happy Thanksgiving everyone.

What do you love about programming?

What I really love about programming is that more often than not, I am trying to take a mental model of some thing -- some problem I'm trying to solve, perhaps, or maybe just some process -- and comprehend it enough to break it down into parts that will interact and become a computational model of that same thing.
Another thing that I love is how much programming has been changing ever since it began. Programmers and researchers create whole new languages constantly to try and meet new challenges, to find new ways of modeling the world and solving problems. There's a huge body of work that's already been done, but I feel like we've discovered a whole new continent to explore and we've barely left the beach where we landed. Whether you're one person working alone or as part of a team, you can be constantly growing as a programmer. There is no end, only constant, wondrous change.

What’s something about programming you wish someone had told you when you were starting out?

Honestly, there are probably several things.

The first would be to have a healthy skepticism of whatever new flavor-of-the-month technique or method comes along. By "healthy", I mean that you should be open-minded about new methodologies, but temper that with seeking evidence for the claims the methodology makes. Often, the proponent of a new way of working in programming is simply trying to rationalize what has worked well for him or her -- that may not work well for everyone, and it may just be that the person is him- or herself really productive, and that any approach may have worked. Programming is difficult, and we are often easily lured to new ideas which may make it easier -- these aren't always better, merely newer, and so we have to evaluate them as rationally as we can.

Another thing I wish someone had told me was what a rich early history computer programming has; there was so much wonderful theoretical and actual work done in the early age of computer science that I now feel we truly do stand on the shoulders of giants. These were people solving really hard, fundamental problems in algorithms, in language design, in thinking about how problems break down, in efficient uses of resources, in the representation of time and interdependency, in human-computer interfaces, in all sorts of things, in every branch of computer science you can think of. The fact of the matter is that a lot of these papers are very hard to read; they often rely heavily on mathematics and on language that has very specific meanings, and so you might have to read and think about a paper for a long time before you fully understand it. But it's marvelous.

I also don't think I understood coming into it just how much a programmer's job involves communication. Unless you are completely working in a vacuum, which is extremely rare (how do you breathe in there?), you'll have to communicate with other people. About six months ago I was asked on a panel what the most important language was for programmers to learn, and I said completely honestly: "English" (or whatever language it is your co-workers use). Even if you're working on your own, you'll be solving problems that are described in natural language, not in computer terms, and being able to understand both the stated requirements of a system and those ephemeral issues surrounding a problem will be valuable. I've learned easily a dozen computer languages in my fifteen years as a professional programmer, and even created a couple, and none of that matters compared to being able to read, write, listen, and speak fluently. Be prepared to ask questions, probably lots of them, as simply as you can.

What about programming is fun for you?

Breaking down a problem into sensible parts is probably the most fun thing, but maybe it's just because that's what I've been up to lately. Taking something large and maybe not even entirely defined and putting it in smaller chunks that you can grasp and start to fit together is really wonderful. I've heard this process described as firing "tracer bullets" through the code -- you solve a problem end to end as narrowly as you can, and then once you understand the whole way it will work together, you broaden it out to cover more of what it needs to do. It's terrific.

It's also always fun to see the results. There are occasionally moments when a system you've built will surprise and delight you, when something you didn't explicitly code in a mathematical sense will nonetheless come out of the program you've written. These are sparkling wonders. I can recall maybe midway through Star Wars: Starfighter's development when I challenged my project leader's assumptions about how AI should be structured for flight games and went a different way. The resulting prototype ended up being reasonably difficult to fly against, but it also exhibited what fighter pilots call a "scissoring" pattern -- not something I had coded deliberately, but which had simply emerged from how the AI "thought" about what it was going to do next. That was a moment of magic I'll never forget.

I also really enjoy learning new programming languages. It's like a whole new way of seeing the world. I don't paint or sculpt or create visual arts like those, but I imagine it's a little bit like discovering pastels or oil paints, or getting a new lens for a camera, or working with clay for the first time or in a different way. New tools provide new ways of looking at the world in the same way, I think.

I really enjoy working with people who have very different skills than I do -- I've worked with a lot of great designers, artists, animators, creative people of every stripe, and I almost always come away from it energized to do my best work. When you're working with good people, you push yourself to excel to meet their own best work, and the results can be much, much greater than what any one of you could have done on your own.

What about programming is funny?

I don't know that I find a lot of humor in programming per se. But that said, I've found that I've always been around a lot of smart, creative people, and those people tend to be funny. I don't think this is unique to programming, however; whenever you dive deep in a particular subject, you end up with new building blocks for humor, whether it's terminology that means something different normally and can be played off of or punned with, or just the deep nerdy stuff that comes from shared experiences in programming. Many of the little jokes or funny observations that you'll hear in conference talks or in general conversation with other people who do what you do are only funny because you've experienced something like it yourself. It's a laugh of recognition.

What made you want to be a programmer?

I was really lucky to come along at a time when computers were still young. My father worked as a computer programmer professionally all his life, and he would bring home a terminal some weekends to play games on. It would spool out page after page of teletype on green and white paper, and we'd explore the crystal caverns for hours through a 200baud modem connected to his work. That gave me a fascination for how those things were put together, and when I got an Apple ][+ a few years later after showing an affinity for it in my school, I was hooked for life. That machine came with two manuals: a hardware reference, and a reference manual for programming in Basic. I've basically been programming ever since, but I started by writing text adventures and simple arcade games.
I think the hook was set by being able to imagine things and then see them on my screen, taking some weird esoteric instructions in a file and translating that into a robot moving around in RobotWar, for example, or even just having a prompt on the screen that was there because I made it be there. It was to me, and remains, absolute magic.

What’s your favourite teenage programming memory?

I wrote a 3D wireframe renderer on that very Apple ][+ when I was in my early teens, and I also used it to code up some visualizations of how aerodynamics and the Bernoulli effect worked for a science fair around that time. That was all pretty cool. But that's a long time ago and it's kind of hard to remember :)

What about programming is annoying?

It can be really frustrating to work with a system that is implemented differently from how you would have done it or that was made to solve a different sort of problem than it's being used to solve now. Sometimes you're even the person who wrote it, and you want to go back and tell your past self to make just a couple of changes so that the system is easier to maintain and extend in the future. But these things just happen, often, as a result of code that has to be written to meet a deadline or which outlives its usefulness or which multiple people have supported over its lifetime, none of whom have really thought through the way the system was meant to be maintained or extended, just bolting on the functionality they thought needed to be there. It happens.

The other is when your iteration time slows down. Working on small programs is wonderful because you can keep everything in your head all at once and nothing takes long to do or evaluate. When you work on large code bases with many contributors, this isn't true any more -- you can't understand all of it, no one person understands all of it, and making changes can become a long and protracted process. Iterations themselves can be very slow just because changes cause chain reactions of things that need to be recompiled and relinked, which can become time-consuming. Nothing promotes creativity better than iterations taking no more than a few seconds to test.

Posted by Brett Douville at 09:02 AM | Comments (0)