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.

Learning phases

I’ve been trying to learn things this week (specifically Haskell). So
far I’ve been through a lot of different moods, and I thought it’d be
handy to write them down so that next time I’m the teacher I can
remember what it’s like to be on the receiving end. I’m not sure I
(and certainly not anyone else) goes through all of these every
time, nor necessarily in the same order which I can’t remember anyway.

Frustration

These symbols all have no meaning to me, what is even going on here?

Atomic comprehension

If this symbol means that, and this symbol means that, then
combining these two must mean…

Holistic comprehension

OK, so this whole thing does this, which means that these parts must
somehow contribute to doing this. Let’s see…

Argument by analogy

Oh, hold on, what they’re saying is exactly like this other thing from
a different area of my experience. I’ll just pretend it’s the same for
the moment.

Paralysis of choice

I have a problem, and I’ve been given a bunch of tools, and I don’t
know which to apply.

All I have is a hammer

Well, I understood how to apply a lambda function to a collection with
map, so I’m going to contort this problem until it looks like I need
to apply a lambda function to a collection with map.

Progress by context

I have no idea what I’m supposed to do here, but I just read a section
on list comprehension so I bet I’m supposed to use [x | x <- xs]
somehow.

Confusion of dissimilarity

I have no idea how to turn that map into a comprehension or vice
versa, but I was able to produce each at different times on the same
day.

Joy of simplicity

You know what, it’s true when they say that if it type-checks, it
probably works.

Disillusion through broken dreams

Oh, off-by-one errors (and rotation of dimensions) still
type-check. This is bullshit.

Reinventing the wheel

So, I need a thing that applies this thing to all those things,
let me write a function applyFunction :: (a -> b) -> [a] -> [b] that
gives me one of those.

Discovering existing wheels

I have a thing and I need a different thing, let me look in the API
documentation until I find the function that does exactly that.

Rage-quitting

This error makes no sense, screw the entire city of Glasgow.

Rabbit hole tangents

This error makes no sense, but those words look sufficiently rare to
shove into Google. Ooh, three blog posts, a bug report and a PhD
thesis!

Trial and (type) error

This error makes no sense, but it’s telling me line 25 is wrong so
I’ll just rewrite line 25. Again. And again.

Stop! Hammock time

I have no idea how to solve this problem, but it’s
lunchtime. [Om nom nom] Ooh, this problem is trivial.

Minimum Viable Enlightenment

I don’t know what I got wrong, but based on the error message I think
I make this change…yes, that works. I don’t know what I got right.

Law of highfalutin words (I)

I wish someone could explain this to people who didn’t learn the word
“monoid” at school.

Law of highfalutin words (II)

Yes, I can help you with that problem, I just solved it myself. You
see, it becomes easier when you realise that these two things
constitute a monoid.

On switching to Linux

In November, I switched to GNU/Linux at home (I still use OS X at work, because I still write Objective-C in Xcode at work). Or rather, I switched back: I’d been using it around a decade ago.

The Ubuntu installer on my MacBook air

In December, I resolved to spend more time working with Free Software during 2015 and beyond. Now I find that my story is not unique, others have left OS X (now a dead link, sadly) or are concerned at the state of Apple. I have had conversations with friends about moving from OS X to Debian, to OpenBSD, to other systems.

In my case, there was no watershed moment, no Damascene conversion from the Tablet According to Jobs to the Stallman Doctrine. Rather, my experience has been one of a thousand tiny cuts, and the feeling that while GNU is not actually a better system, it’s one that I’m allowed to make changes to. When iWork was ‘upgraded’ to a less-capable version with an incompatible file format, cut. Every time I plug my Apple display into my Apple computer, then have to unplug it and connect it again before it works properly, cut. Even when the display works, I have to unplug the (Apple) keyboard and plug it back in, cut. Every time iTunes connects to the network but doesn’t let me play any of my tunes, cut. When Apple trumpets the superiority of their new map that shows I live in “Royal Spa”, cut. When iCloud showed its message that I have to upgrade to the new way and devices still on the old way can’t see my files any more, cut. Like the above-linked authors, I’ve got to a point where the only Apple-supplied software in my Dock is the Finder. In my case, it’s happened one app at a time.

The thing is, Apple’s been building some great new things. There’s the watch, Swift, improvements to Cocoa, and they still have the best hardware around. If it weren’t for both the real regressions and the fear of potential regressions on every upgrade or app update, I’d still be confident that their Unix desktop were the best. As it is, I think it could possibly be the least worst, but I’m no longer certain.

Most of the time I don’t care about my computer’s operating environment. This isn’t so much the year of Desktop Linux for me, as the year of Desktop Ambivalence. The OS is the thing that spends most of the time and RAM involved in showing me an emacs window, or a terminal emulator, or a Smalltalk machine, or a web browser. I shouldn’t need to care how it works. But if it’s going to get in my way, give me a chance to do something about it.

The standard trope response is “LOL you must have a bad idea of UX if you use Linux”, which is the sort of thing that was true at the turn of the millennium when most of us were last tyre-kicking some GNU distro but is now an outdated view of the world. But again, should there be a problem, I hope to have the ability to fix it both for myself and others.

So far this year I’ve started small. I’ve been reminding myself of the differences between OS X and BSD commands that I’m used to, and the Linux and SysV commands that I’ve not used frequently in nearly a decade. I’ve been learning about Vala and GTK+.