Computer Programming

From jbum wiki
Jump to: navigation, search

Computer Programming is a very broad topic, and almost every article on this Wiki, with the possible exception of the one on Birds touches on it. I started programming at CalArts in the early 1980s, where I was a music composition student. My first "useful" programs were used to assist my efforts in Music Composition. But that word "useful" deserves a closer look.

For my entire career, I have always enjoyed creative computing -- or using computers for arts and entertainment. The arts are essentially defined by their *lack* of utility. One of the first computer programs I remember writing was generating random numbers, and randomness has always had a strong pull for me. The presence of randomness in computer software is usually evidence that the program is pretty interesting, and probably not particular "useful". More to the point, the more "useful" a programming project is, the less likely I will be super interested in working on it. I think this basically comes down to the fact that I self-identify as an artist by nature.

My skills in programming are pretty much self-acquired. I took no programming classes at CalArts (they weren't offered) and I continued to teach myself after graduation. I started working professionall as a programmer before I graduated, and despite a variety of weird job titles like (Director, CTO, Systems Analyst, etc.) I've always thought of myself as a programmer first and foremost.

Having said that, I've worked with a lot of people with formal computer science training and some of them have a different approach, or belong to a different tribe than me (many of these self-identify as "systems programmers" -- I tend to self-identify more as a "front-end programmer" although I am also a "full-stack programmer"). As a self-taught programmer, I've always been fairly results-oriented. I'll do a little refactoring, but I don't lose sleep over it the way some of my colleagues do. I definitely prefer my software to have a clear impact on the end user, rather than on other programmers.

I've always taken pride in being more of a generalist and a quick study. I've learned and used a lot of different languages. One of my survival strategies is that I try not to get overly dependent on any one language. I also don't like to use PDE (programming development environments) because these go in and out of fashion and if you get too reliant on them, you are left in the cold when they are discontinued. Bear in mind that the PDEs I was using for the first half of my career no longer exist, and Eclipse, which is a horrible beast, was once considered to be quite simple and elegant. I try to stick to the basics unless I'm forced not to: a good text editor, console/printf debugging (or debugging via image drawing, if I'm doing something like puzzle construction). I'll use a symbolic step debugger at last resort but it's not my first choice because it slows me down.

As I've gained experience the kinds of self-made bugs I've had to fix have been much reduced (and I've gotten much better and finding and fixing the ones I still make). When I was first starting out, a lot of my bugs were due to my misconceptions about how the algorithms I was writing would play out or manifest, so I would create more "design flaw" bugs that were the result of faulty thinking. I have enough experience now that those kinds of bugs happen very rarely, if at all. Most of my bugs now are really simple syntax errors due to typos, and there are very few of those, since most of those are caught by the compiler or interpreter.

There are some styles of programming which are of relatively recent vintage (to me) which are tough for me to appreciate, just as some of my older colleagues in the early 90s had a hard time understanding the cult-like appeal of Object Oriented Programming, which was newish at the time.

  • I am not on-board with the recent trend towards building automated tests into everything. This is mainly because every time I've participated in this activity, the amount of time spent writing tests greatly exceeds the time that would have been spent fixing the bugs they supposedly prevent. Plus the tests themselves provide additional surface area for bugs.
  • I have never attended a productive code review. I'm sure they happen somewhere. But if a project is so large it really needs 'em, it's probably not for me. In general I prefer smaller projects where I have more autonomy to large organized team efforts.
  • I love the idea of pair programming, but have never seen it work in practice. I do enjoy working in complimentary pairs however.
  • I'm not a Scrum advocate. I'm a get-shit-done-with-the-smallest-team-possible advocate. Scrum is a strategy for dealing with teams that are too large. The best team is a pair. After that it's all downhill.
  • These days a lot of software engineers spend most of their time combining existing prepackaged modules / libraries, rather than writing algorithms. Their job is

reduced to identifying the boxes to pull off the shelf and gluing them together. This doesn't seem very fun to me, although it certainly has its place especially if you need to get a lot done. Ultimately, I love writing algorithms, and working out problems in code, and don't want to give that up.