Tempus Fugit

A common concern programmers have when I talk about my year off is that I’ll be unemployable at the end of it. After all, the industry moves really quickly and if I’m off thinking about things that aren’t programming, I’ll fall off the treadmill. Programmers are like the red queen, constantly running in order to stand still. Aren’t they?

Well, no, not really. Looking at the current TIOBE programming language index, I’ve written software in nine of the top ten languages (which are all at least a decade old). The likelihood that all of these will become obsolete in a year is miniscule, and the likelihood that the underlying principles of organisation of thought will perish is smaller still.

What about the platforms? Will big screens, small screens, touch screens, pointing devices, keyboards, web clients  or network servers disappear within the next year? How would a freeze-dried programmer from 2014 or even 2005 cope with today’s near-identical world?

Maybe, should I come back to professional programming next year, I’ll find that I’ve grown my ability to understand things that aren’t programming; a skill that could stand programmers in great stead. I doubt, however, that I’ll have lost my ability to use a text editor and a compiler, tools that remain obstinately similar to their 1950s forebears.

Week One

Nearly eight days ago I stopped working to have a break. I’ve been describing it as a “gap year”, because I’ve arranged my finances to last at least that long with some contingency. Also, I want to set a year as the anchor in my mind, so I don’t do what normally happens and take the first interesting-looking job that comes along. There’s a danger that I’ll be bored around a month from now and start interviewing again.

Honestly, after one week I feel better rested but not like I’ve made some fundamental life change. That’s partly because one of my first projects for this year is to complete an MSc in software engineering, so I’m still “a programmer” by trade to some extent. One goal for this year is to experience more of humanity than just programming.

I’ve taken some time out to do that which can be described (with capital letters, no less) as The Arts: visiting the Birmingham Museum and Art Gallery and the Library of Birmingham. And I turned my hand to graphic design to lay out a new “business” card, which I hope I’ll have to hand next week. I’m speaking at #pragmaconf in October and people there might want to know who I am.

In literature news, Goodreads tells me I read Snow Crash, Emotional Design, a Philip K Dick anthology and I started on the Salmon of Doubt. Add to that this month’s Linux Voice, Linux Format and CACM. A lot of reading, but things that programmer-me would have got around to anyway.

In home economics news, I did bake two loaves of plum bread (plums “sourced locally”, by which I mean they were scrumped from a tree up the road) which is something I haven’t had time to do in nearly a year.

Criticising the Four Freedoms

The core principle of Free Software is that people who use software
retain certain freedoms, unlike the situation with proprietary
software in which all of the freedom associated with the software
remains with the vendor. Those are the Four Freedoms:

A program is free software if the program’s users have the four essential freedoms:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Without other resources, these freedoms are pretty academic. Let’s
take access to a computer as a given for the purpose of this argument:
you’re one of “the program’s users”, so presumably you have the
material needed to use the program.

But does the program need all the resources it uses?

I can study and modify the program. Access to the source code is
indeed a prerequisite; comprehensible source code is also a
prerequisite. So are the study materials I need to comprehend the
source code, and the time it’ll take me to do that study.

So that’s me on the receiving end of free software, what about the
producing end? Nothing in the world of free software compels me to
choose the simplest language, to design my software for
comprehensibility, nor to make available the tools and information
needed to understand the source code that enables the other
freedoms. But unless I do that, the four freedoms are only
hypothetical.

Improving a presentation with slides

Take a look at your slides. For each slide, think how you would present the same information if you didn’t have the slide. Practise that, so that you can give the information on the slide without using the slide as an aide memoire. Practise that, until you can introduce that topic, discuss it, and move on to the next without a single reference to the slide. Do the same for each slide.

How will that improve my slides?

It won’t. It will improve your presentation with slides, by turning it into a presentation without slides.

As an optional extra, you could make new slides that support the presentation, but it shouldn’t be necessary.

“When I had that problem”

A common lie in programming is that every project is new, that no problem has been seen before. This is the reason given for estimates being bad, for plans being bad, for design being bad…for anything other than diving in uninformed being bad.

But I’ve noticed that more and more frequently my discussions about problems-technical problems, organisational problems, personal problems-involve the phrase “when I had that problem”. That somebody (and, as time goes on, that’s more frequently me) has seen this problem or one with many similarities before.

It’s time to stop pretending that your UI fronting a database table is up there among the Hilbert problems as one of the big research questions of the 21st century. We have seen that before, or something like it, and we tried things, some of them worked. They probably weren’t the best possible solutions but they were solutions.