On the extremes of computer science

I didn’t study computer science at school or university, and still manage to work as a programmer.

That is not to say that I don’t need to know some things that are taught on computer science courses. Just this week I’ve had to build a couple of different data structures and understand their running time: very CS.

I’ve also needed to know things that aren’t on a CS degree, too. The acceptance criteria for one of my projects are written in French, and none of the CS courses I’ve seen in UK universities include that in the syllabus.

I’m neither arguing for nor against the validity of a CS background in professional software development. I’m arguing against taking either side. You need to know some CS things to write software, you need to know some other things, multiple backgrounds are appropriate and welcome.

Dogmatic paradigmatism

First, you put all of your faith in structured programming, and you got burned. You found it hard to associate the operations in your software with the data upon which they act, and to make sure that the expectations made on the data in one place are satisfied when that data has been modified in that other place, or over there in yet another place. Clearly structured programming is broken.

Then, you put all of your faith in object-oriented programming, and you got burned. You found it hard to follow the flow of a program when it jumps in and out of different classes, and to see which parts were coupled to what. Clearly object-oriented programming is broken.

Then, you put all of your faith in functional programming, and you got burned. You found it hard to represent real business processes in terms of immutable data structures and pure functions, and to express changes to the operating environment without using side effects. Clearly functional programming is broken.

Or maybe it’s you. Maybe, rather than relying on faith to make these conceptual thought frameworks do what you need from them, you could have thought about the concepts.

In which I interview so you don’t have to

Describing job interviews for technical roles in the software industry to people who have left or have always been outside the software industry requires two things: patience on the part of the one doing the describing, and the ability for the listener to take a joke. Over the last twelve years I have taken countless job interviews so that you don’t have to. Here’s what I’ve found: presented as a guide to running the average software developer interview. As with all descriptions of mediocrity, you should treat this as best practice.

[Be clear on this: not all interviews are like this. But this is an expectable baseline, derived from experience.]

Person Specification

The ideal candidate will be rich. We’re going to put them through hours – maybe even days – of tests, interviews, meetings, and “informal chats” that they’d better be on best behaviour for anyway. They need to be able to afford taking that time away from work, friends, other opportunities, so they’d better be rich.

That multiple-hour interview process means that they’d better be desperate for a job too. As you’ll find out in the section on our process, we pride ourselves on not giving away too much. We’re not selling our company to you, because we know we’re offering the chance to do what you’ve always wanted: sit in our open plan office space next to our own particular loud crisp-eater muttering at Eclipse.

The ability to go without food is desirable too. Even if a stage of the interview is planned to take so long that it would go over lunch, and even though we might put a break for lunch in, we might also forget to do any catering. Computers don’t need food and programmers are sort of like computers, we heard. We actually occasionally do feed our staff, and advertise this as a perk.

Our Process

The first thing we want to check is whether you can solve logical problems. We don’t actually need you to solve logical problems, after all, that’s what the computers are for. But we’ll give you an aptitude/basic reasoning test anyway [yes, although it’s no longer the 1960s and we aren’t IBM, this is still common if not universal].

The reasoning test is there to weed out people who didn’t have the same education as us, or were raised speaking a different language, or in a different culture. Empathy is hard, and to avoid unduly stressing our staff we want to make sure that their colleagues are as similar to them as possible. Additionally the hour you’ll take going through this test is an hour we don’t have to make eye contact or conversation with you: empathy is hard.

To be honest we have no idea what this test means or how to interpret its results. Everybody before you went through this test, and they’d raise merry hell if we “lowered the bar” by removing it now. As a holacracy/meritocracy/hypocrisy/this week’s organisational behaviour buzzword, we empower our employees to not see any changes that might raise a small amount of discomfort.

So after that test, depending on the seniority of the position and the candidate’s experience, we’ll…no, not really. We did nearly keep a straight face through that sentence though. In fact we didn’t read your CV except to find out whether the keywords that describe the problems we have right now and the solutions we have chosen last week appear. We didn’t read your GitHub/Lanyrd/Bitbucket profiles either, except to check that you have them so we know how much free work to expect out of you in addition to the paid stuff. Our project management system works on the Pareto Principle: 80 hours a week on our stuff, 20 hours a week on open source stuff that we can co-opt.

The next stage in the process is actually the same for everybody: a basic programming test to find out whether you even know what a computer is. We don’t care that you’re [glances at CV] Grace Hopper, we still don’t believe that you can reverse a linked list. None of our employees has ever had to reverse a linked list on the job, and we’d fire them if they did reverse a linked list on the job because there are libraries for that.

Now we’ll come onto the technical interview: a cross-examination by a panel of between one and twelve [not joking] people who have, or have had, a word like “engineer” in their job description at some point. These people are tasked with finding out whether you’ve solved the same problems in your career as they have in theirs. If you haven’t, you might not be clever enough. If you have, then what new experiences are you bringing to the table?

By the way, our flexibility on your technical skills will go down as you become more experienced. We appreciate that new grads might not have used our tools/frameworks/technology and are willing to train them, but if you have more than six months’ experience with Java we’re going to call you a Java developer and only consider you for Java roles.

After all of that, it’s still possible that you might have somehow snuck through the system despite not going to the same university or belonging to the same society as the founder. We can’t really quantify the idea of “culture fit” but that’s what we’re examining in the next part of the process and we’ll know it when we don’t see it.

The Offer

You’ll get a phone call from us while you’re in the bath. We’ll outline the position, pay and (unless this is an American company and there isn’t any) holiday provision. You then have two seconds in which to reply, with either “Yes” or whatever the other one is. You may have other irons in the fire but of course you’ll want to drop all of those when we tell you about the parking space we’ve already allocated for you [This has happened. I don’t have a car.].

The Job

You will be working with a team of people who all went through that same interview and decided they wanted to work in our environment. We will leave it to you to decide what that means.

The Alternative

There are some less…scientific…approaches to hiring that involve using the candidate’s stated and visible experience to have a conversation about what they’ve done, how they do and don’t like to work, how they’ve responded to success and failure, and whether the challenges they would like to see in their career match up with the environment we’re able to provide. While that sounds like quite a pleasant experience for everybody involved we fail to see how it could possibly translate into discovering whether we want to work with you or vice versa.

Turn it off and back on again

I’m now six months into what I expected to be about a year out of working in technology, and I’m starting to think about what comes next and trying to make it happen. The difficulty I have is that it’s hard to explain what I’m looking for in a way that makes sense to those that are hiring, or that I can summarise in a search term for job sites. I’m considering running a company again to do all this myself, but that doesn’t obviate the problem, I still need to be able to describe this to potential clients and explain why they would want to buy one.

The difficulty comes from being a people person. I listen to people, I talk to people, I get people to talk to other people, I learn from people, I teach people, I perform for people, I watch people, I read what people have to say, and I write for people. And I happen to want to do that for money in the software industry, but if you tell that to a hiring manager on a software team you’ll get a blank stare followed by “um, but how much have you used MongoDB from Scala in your last job?”. You don’t need to try this yourself, I have done it. This is what happens.

I don’t mind much what technology I use, as long as we’re using it because it helps to address the problems we or our customers have rather than because a developer threw a strop if they weren’t going to be allowed to rewrite everything that already works well in NodeCaml. I care about understanding and solving the problems people have, and about understanding the people who have those problems. “I think we should use this” is not fine. “I think we should use this because” is perfectly fine. “We’re a $VENDOR shop” is probably not fine.

So the problem I have is that the job I know how to apply for and get is “programmer” (these days with some highfalutin prefix that really comes down to “better paid”), but that usually comes with some expectation to focus on the programming, and leave all the gloopy soft stuff like what programming should be done and whether it’s a good idea to do it now to other people. What I want to be doing is (being paid for) the gloopy soft stuff like making programmers into better programmers, working out what programming should be done (if any) and whether it’s a good idea to do it now, helping programmers to understand the people they’re helping, and helping the people being helped by programmers to understand the programmers, with the programming itself being a context not a focus. I have no idea how to explain that succinctly to people who might want to hire one of those, nor how to find people who might want to hire one of those.

Practically, based on what I’ve experienced about my own health and its relationship with my work, I also need to be realistic about where and when I work. That’s from or within cycling distance of home (around Leamington Spa, Warwick, Kenilworth and Coventry), from usual working hours my own timezone. If your company is in a different timezone and supports remote work, that’s great, but if you need me to work from your timezone then it’s not great. In fact, you don’t support remote work, you just support local employees who don’t always come into the office.

If you are someone who wants one of those, know someone who wants one of those, or know how to describe one of those succinctly, please do help me out. Based on the last time I tried this, here’s a couple of lists:

Things I’ve never done, but would

These aren’t necessarily things my next job must have, and aren’t all even work-related, but are things that I would take the opportunity to do.

  • Work in a field on a farm. Preferably in control of a tractor.
  • Have a job title that begins with the letters ‘C’ or ‘D’ (I managed ‘Q’ a while back).
  • Spend lots of time supporting the Free Software Definition
  • Include going to lunch with each other employee in the company in my responsibilities.
  • Visit Iceland.

Things I don’t like

These are the things I would try to avoid.

  • I still seriously hate raw celery.
  • Client work, in those cases where we don’t all really think that the client is doing something important.
  • “Rock star” programmers, and people who hire them.

Clown Trousers

An indirect side effect of stopping programming is that none of my trousers fit any more.

People who like to explain things before they have all the facts (or “programmers” as we sometimes call them) will justify this observation by pointing out that I have more time for exercise now. I do, but I don’t use it. While working at Facebook I walked six miles each day as part of my commute and worked at a variable-height desk; I spent a lot of time walking and standing.

When I began my gap year, I put some effort into running every day. That didn’t last long. I still stand a lot to play musical instruments, but am significantly less active now that I’m 8kg lighter than programmer Graham.

Looking at videos of programmer me, I just see an obese, tired guy surviving on caffeine, sugar snacks and three big meals a day as he lurched between commuting trips, flights abroad, conference talks and infrequent visits to bed. Peak Graham (weight for weight) came in June, as attested by the video of my AltConf talk, I have no idea what I’m doing.

It turns out I had no idea what I was doing to myself either. But now that I’m not doing it, the historical record that is my wardrobe tells me I’m healthier than I have been in over five years.

You may not need hipster silicon valley nutritional engineering sludge. You may not need an extra hour in the day to fit in a run and a shower. You may not need to drop a few hundred quid on a watch that also reminds you to stand up. You might just need to discover what you’re doing wrong, and not do it like that.

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.