Week Seven

Having spent a few weeks trying all of the things and letting life happen, this week was about selection and focus. What should I actually concentrate on, and put energy into?

It’s time to add some structure to this situation. Dropping all of the things and taking life as it comes was relaxing, enjoyable, and necessary. Re-moulding things and building something new out of the parts will be necessary to provide a new sense of engagement and purpose.

Week five

“You look so much happier!”

I get the best compliments. Also, I feel so much happier. I have put people, friendships, connections, and experiences first, and am taking advantage of the rewards.

One such experience was a visit a couple of further education (16-18 years old) computing classes in my county. I was mostly there to talk about my background in the industry and help them to understand what jobs there are and what employers look for. I was blown away by the things these students could make in their robotics classes though, with Mindstorms kits talking to laptops and mobile apps.

That was a huge step up from the turtle robots we had shuffling around the floor. in my school. And it still feels like there’s even more opportunity there, like there’s a huge gap between what a student sees computers being capable of and what they can do with the tools we (the industry) give them.

Week four

Pragma conf was a lot of fun! I met loads of new and old friends, which led to meaningful conversations about what we do, what we sometimes feel we should do, and what we want to do.

One such conversation, with Chris Eidhof, was about how we think about programming. It was brought to mind again recently by Derek Jones’s post on Lisp and functional programming languages. His description of the Lisp community reminds me a lot of my own post on the tankard brigade, in that what keeps Lisp going is the exclusivity, and the need to know arcane rules to get things done when non-purists have much easier means to the same end.

What intrigues me about that is that it puts me into the tankard brigade, which gives me a lot to reflect on. When I look at Lisp I see a parsimony, a lack of arbitrary rules. It looks like there’s a single underlying metaphor, and everything in my solution can be expressed through that metaphor (no matter how I solved the problem). I look at Lisp and see functions. I look at Io or Self and see messages. But when I look at supposedly more accessible languages I see a bag of edge cases and special “oh, you want to do that? No, you need one of these” conditions, with no metaphor.

Staying power

You would imagine that by now I would have come to realise how long my attention span is and worked to find projects that fit within it, but no. This is one of the changes I need to make soon.

So often I start a project really excited by it, but am really excited by something else before the end. Book projects always work that way, and quite a few software projects. Sometimes even talks, given a long enough lead time between being asked for a topic and actually giving the talk.

The usual result is that I become distracted before the end of the project, which leads to procrastination. That then makes it take longer, which only increases the distraction and disengagement.

What I’m saying is that if I ever say that I’m thinking of starting a PhD, you have my permission to chastise me. Four years is not within my observed boredom limit. Six months is closer to the mark.

Week three

This is both an international and a hyper-local update. I say international, although I’m still in an airport less than twenty miles from my house. I’m on my way to Florence, to talk about *-oriented programming at Pragma Conference 2015. It’ll be fun to catch up with friends in a new city, and close the conference with what I hope is an informative talk. I’ll put my notes up some time after the talk.

The theme of this week has been friends. I’ve had lots of things I could be doing, and even a few things I should be doing. For the most part I’ve been letting that take second place to spending time with friends. I’ve ended up playing a lot of tunes and singing a lot of songs as a result, and maybe only written four or five paragraphs of useful text.

Speaking of singing and playing, our band is going to play the main spot at Folk in the Barn, Stockton on the 27th. Anyone who’s around the Somerville Arms, Leamington on Tuesday 13th October or Harbury folk club on Thursday 5th November will also discover a subset of the band doing a couple of numbers. International readers will be amused by the provincial nature of this part of the post; a lot of the fun of this break has been connecting with the local area and things that are going on around me.

Week Two

As week one featured an observation of how post-work life was similar to working life, this week’s post is a catalogue of differences. Not all of these differences are huge.

No watch

I own five watches (three wrist, two pocket) but have only worn one once in the last two weeks. Most of the time, I don’t need to know what the time is and don’t need to mark its passing.

No beard

When you get up at 5:30 every morning for the commuter train, putting time into your appearance takes a back seat to getting out of the door quickly. I now shave every day; not particularly important except that it indicates I have time to do so.

No computer

Or at least no sitting at a computer. I’m writing this on a laptop which I’ve just been using to write up the dissertation, but when I’m not doing that, or editing music scores in MuseScore, I’m not “at” a computer. Tempus Fugit was written on my phone: the best computer is the one you have on you.

No tech news

My morning ritual used to involve a lot of RSS tech news feeds, as well as browsing some aggregation sites like lobste.rs to find articles to read. Now that’s all been pared back, apart from a few people who write well. I usually have two or three unread articles every day now, which are more often than not web comics.

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.

“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.

A kata above

The code kata is a method software craftspeople use to practice their craft. The idea is that you take a problem you understand, like FizzBuzz or Conway’s Life, and build an application that implements it. Then build another one. And another. Pretty soon, you should be quite good at building a thing with well-understood requirements.

But that’s the problem, isn’t it? Our professional time can be split into two parts:

  • the part where we don’t think we quite understand what we’re meant to be doing.
  • the part where we are wrong.

So what’s the point of being good at implementing well-understood requirements effortlessly? A partial answer is that being able to do so frees up our minds to think about the real problem, which is understanding the real problem. I’m sure our customers will be happy to hear that the only way we have to practice that is to take their money and pretend that we know what we’re doing.

What are the causes of not knowing what we’re doing? I can think of at least two: not knowing what the requirements actually are (which includes knowing what everyone thinks they are but not knowing how fulfilling those will change them), and having an existing system to adapt to the new requirements. A lot of the time, both of these are unknown.

We already have plenty of “work with legacy code” katas. We call them open source issue trackers. Find a project, find a bug, dive in and fix it. Practice working with code that’s new to you, and already solves most of its problems.

You’ll find that with open source and free software, the two extremes of bugfixing get practiced a lot. At one end, people are willing to fix trivial bugs that mean inserting one if into the existing code. At the other end, people will do complete rewrites, throwing away working code and its bugfixes to introduce “clean”, though not necessarily working, code. It’s the expanse of space between these, where you need to make substantial changes but without throwing out the beneficial existing behaviour, where there’s space for legacy code katas.

But maybe we also need the “requirements kata”. Think of one of your interests that isn’t programming, and find a forum on it. Locate a thread where someone has asked a question that’s led to either no answer or a convoluted process to solve their problem, and think about how you could design a software system to solve that, and what other information you’d need to specify it well. Think about how you’d validate that the derived system actually solves the problem.