Blog

FAWM 2014

Last year I took part in FAWMFebruary Album Writing Month. I did it again last year, and actually made an album this time: 15 songs in 28 days. It was super-stressful, and for the sake of my sanity I should not be allowed to aim for 14 songs in 2015.

Most of it was made on my iPad, although I finished a couple of tracks in Ardour. I used a lot of GarageBand, along with Figure, Thor, Korg Gadget, and Funkbox. I bought a cable that let me record my guitar from my iPad, and friends lent me a banjo & a decent audio recorder.

It's a mix of acoustic recordings, synthy dance electronica, and atmospheric darker electronic music. You can explore it track-by-track on my FAWM page (until 2015, as the site retires older stuff each year), or download the whole album as a zip. I've also included the MP3s below.

  1. A Departure (acoustic folk-rock)
  2. Let's Get Started (dance/electronica)
  3. Are You Receiving? (synthpop/electronica)
  4. Synthetic Floor Filler (dance/electronica)
  5. It's Going To Happen (spoken word/folk-rock)
  6. String Theory (instrumental/folk)
  7. Time Slips Past (chiptune/electronica)
  8. Boopwub (electronica/dubstep)
  9. Ice Giants (dance/electronica)
  10. Numericalities (dance/electronica)
  11. Forever Safe (ambient/electronica)
  12. Elongate Thistledown (dance/synthpop)
  13. Thanks, Steve (instrumental/soft rock)
  14. Potbound Mint (synthpop/waltz)
  15. Sometimes Things Just Go Your Way (instrumental/chamber pop)

As an extra bonus track, here's a dance track I made post-FAWM. Unlike last year, I'd like to keep making music in the rest of 2014. I must have at least another EP in me.

Products with benefits

The first in an occasional series about product design heuristics. The second part is about what "social" should really mean.

I generally work with startups, which means I'm working with companies that are still trying to figure out what they're building. I'm not a product manager, but over time I've assembled some heuristics that help figure out if a product is on track.

When you're building a user-driven product or adding a feature, the user must benefit and the company must benefit.

This sounds obvious but it's surprising how many companies put their own wishes above their customers'. It's an approach that can pay off in the short term, but at best you're growing an indifferent, surly customer base. At worst, you're driving people away. Human beings have very little patience. If you're not putting them first, they'll go somewhere else.

It's a heuristic – not a cast-iron rule – so it's not a disaster if you take a different path. But you are swimming against the tide, and you're going to have an uphill battle1. You're going to have to explain to your users why they should do what you want, or create something so compelling they'll jump through your hoops. Equally, if users benefit but the business doesn't, make sure you have a plausible plan for the long run. Your business isn't going to implode, but it might limp along, struggle to attract users, or fail to evoke the passionate response you want.

An example

A startup is building a Foursquare-like service, but instead of checking in to places users will write a short review. The startup thinks they'll gather deeper knowledge about the places you visit, and that they can monetise that database. But they're missing a key step: why will a user write a review? What does the user get out of it?

Writing a review is a lot of effort. Even if it's just a sentence or two, the user still has to figure out:

  • What's good about this place?
  • What's bad about it?
  • Am I broadly for or against?
  • How am I going to express that in words?

And don't forget the user's out in the world, probably with friends. Will they really ignore the people with them and tap out a review on their phone? This is starting to sound like a rather anti-social product. Users won't complain about it; they just won't use it. Check-ins are already an unnatural behaviour – something a user's persuaded into trying, rather than demanding – and the mandatory review step makes that even harder.

Carrot and stick

People use your features for two broad reasons:

  1. Good things happen if they do.
  2. Bad things happen if they don't.

The first motivation is infinitely more preferable: the carrot is better than the stick. If you're lucky you can sometimes force things on your user, but everything flows more smoothly if the users want it themselves.

People shop on Amazon because they want cheap products conveniently delivered to them. They post statuses on Facebook so their friends click 'Like'. They sign up to Groupon to get big discounts in their inbox. Users actively want these things: they would complain if you took them away. But there's a benefit to the companies too: profit for Amazon, and engaged users for Facebook & Groupon2.

The second option puts your company's needs first. It's a mild form of blackmail. You're putting an obstacle in front of your user, and hoping that they want your offering enough to put up with your bullshit3. You can spot these by looking for double obstacles: something you've added to make the first obstacle work4. YouTube's first obstacle was "Watch this advert before you see a video", but nobody wants to watch an ad. So they added a second obstacle that makes you wait 5 seconds before you can skip it. Groupon really wants to email you every day5, so as soon as you land on a Groupon page they show you an undismissable box demanding you sign up.

A screenshot of the undismissable Groupon popup.

Nobody on the internet thinks to themselves "I really wish this web page would demand my email address the instant I visit it." Groupon's betting that the people it turns off – the people who say "Stuff this" and close the tab – are worth less to them than the email addresses from casual visitors who want to see the offer. You could argue that users benefit from this too, as they get offers in their inbox every day, but it's an arm-twisty way of getting users. The user didn't get the chance to see some Groupon deals and decide to sign up because they liked the look of them: they signed up because that's the only way to see the offer in the first place.

Streaming music is another example. Companies like Rdio, Pandora, and Last.fm. Their streaming radio products generally limit how many times per hour you can skip a track. It's because of licensing laws, and the costs of licensing music: labels charge less for "radio" plays than "on-demand" plays, and it's easier to convince the labels that you're in the former category if you have limitations. Users hate it, but the businesses think it's the only way they can survive6.

Magical sticks that turn into carrots

There are occasional circumstances where you obstruct your user for a good reason: for the good of the community. A real life example is airport security: nobody wants to have to queue for ages and get searched, but most people don't want bombs on planes. So we mildly inconvenience everybody so society avoids hostage situations. A tech example is Dattch, a lesbian dating app. There's a bunch of people on the internet who love to spam & harass lesbians. So Dattch insists you sign in with Facebook, and every profile is screened by a human to ensure it's real. It's not that they think their users want to wait for several hours as soon as they sign up – it's that it's better for the rest of the community if the company has a chance to screen out the weirdos.

Who's getting it right?

It's hard to give examples of companies that get it right, because it looks so damn obvious. Consider any online shop, pretty much: people want to buy things, and the company wants to sell things. As long as the customers are happy with the product and the business is making a profit, everybody's happy. Or consider Dropbox: users benefit from having their files available everywhere, and Dropbox benefits from power users who buy premium accounts (and from being the de facto way of syncing files across devices).

Marketplace leaders are good examples, too – the eBays & AirBNBs of the world. Their users are both buyers & sellers: buyers win by having easier access to more products/accommodation, and the sellers can reach a bigger audience or even sell something they couldn't before. The business wins by taking a commission.

And despite the way they haemorrhage money, music streaming services would argue that they benefit from data when users listen. It can use that data to improve its personalisation services, and also sell aggregate information back to the music labels. It's still a cut-throat business, which demonstrates that even if you think you've ticked both boxes you're not guaranteed success.

The takeaway

When creating a product or adding a new feature, make sure that both the user and your company will benefit. Users are fickle; they won't do things solely because you want them to. There's got to be something in it for them. And likewise, you won't last long as a business if you give the users everything: there's got to be something in it for the company too. It might be a long-term payoff. It might not be direct. It's OK if it's not always there, but have a clear reason in your mind to forego it.


  1. I enjoyed this mixed metaphor so I left it in.  ↩

  2. "Engaged users" means "People use your product", which means "We can sell things to them." Groupon sells to people directly. Facebook sells advertising space, which is an opportunity for someone else to sell to their users.  ↩

  3. This isn't the same as a dark pattern – dark patterns are actively trying to trick people. These examples are trying to work around human nature.  ↩

  4. Another way of spotting this is asking, "Did this request come from the advertising department?"  ↩

  5. If they email you every day, they can sell to you every day. If they sell to you every day, you're more likely to buy something.  ↩

  6. Spotify is taking a different approach: they're trying to get a huge audience before they run out of money. They have higher licensing costs, but if they can get enough users then economies of scale kick in and they'll be profitable.  ↩

What makes Bit Pilot fun

A screenshot from the game Bit Pilot

Yesterday, for the first time in about a year, I played Bit Pilot. It's an astonishingly good game, and I found myself pondering what qualities made it fun. Games aren't made via checklists, of course. You can't take these elements, tick them off, and expect to have a fun game. There's also a standard disclaimer. But that doesn't mean we shouldn't try to learn from the work of others. So, why is Bit Pilot fun?

Bit Pilot has a simple concept, well-executed. You control a spaceship in a restricted playing area. Dodge the asteroids and laser beams. Collect power-ups if you can. That's it: there's no sprawling back-story, no giant sandbox, no growling beefy protagonist. Just you versus the game – and you will always lose. There's also no victory screen: you're pitted against your own prior performance (your high score) and any friends you can persuade to play too. This simplicity is an attraction. But a simple idea, no matter how elegant, isn't going to make people play for hours unless there's something more at work.

Balancing a chair on two legs

You're sitting at a desk and you push yourself away from it and now this four-legged chair is balanced on its two hind legs and you. are. awesome. We've all delighted in that, right? There's two unconscious thoughts that ping-pong back and forth while you're doing this:

  1. I'm so skilled. Check out my goat-like balance. This is ace. I'm ace.
  2. WHOA FUCK I ALMOST LOST IT phew I'm fine

It's this interplay that Bit Pilot replicates. Most of the time you feel in control and impressed with your abilities, but there's these little nudging pokes that knock you off balance. It's not a stable system; sometimes you'll get away with it, but in the end you'll lose. You come back for more because of the times you get away with it, and because the feeling of control is so addictive.

Pushing your boundaries

The reason you always lose is because Bit Pilot gently but constantly pushes on your boundaries. The special asteroids and laser beams are part of this, but the main pressure is the asteroids becoming bigger. Over time there's less space and more asteroid. You can't win; eventually there'll be no space left.

Super Hexagon is another game that got its hooks into me. It's difficult in a different way; it's far more overwhelming at first1. There's so much happening on-screen it's hard to grasp what's happening. And just when you start to get a grip, the game speeds up, or reverses direction, or introduces a new obstacle. Super Hexagon doesn't give me the same balanced-on-a-knife-edge feeling, though maybe I've played it too much. When I die in Bit Pilot, I think "I should have avoided that." When I die in Super Hexagon, I think "Yeah, you got me." Infinite runners like Canabalt have the purest implementation of this: they speed up the longer you play, giving you less time to react.

A balanced difficulty curve

Some games don't forgive mistakes. Super Hexagon and Canabalt both have instadeath: one mistake and you die. Other games give you lives. Bit Pilot has a lives system – your ship starts with two shields, and you can accumulate more – but it's more effective than your standard 3-lives-then-game-over mechanism.

There's no penalty for losing a life – no going back to the start of a level or losing your power-ups. The graphics and sound tell you you messed up, but there's no immediate consequence beyond feeling more exposed than before. You can also pick up extra shields, until your ship is nestled in the centre of a giant hexagonal onion. But it gets harder and harder to keep them: the more shields you have, the bigger you are. You can't slip through tiny gaps any more. Conversely, you become a smaller target as you get closer to death. The stakes are higher, but the odds are more in your favour.

No time to reflect

A key hook in both Super Hexagon and Super Crate Box is keeping the time between "game over" and "new game" as short as possible. One quick reflexive tap and you're back in the action. No time to think about the previous game; stay in the zone, and keep playing. It's not a case of thinking "Just one more go." It's a case of not thinking at all.

Perfect controls

A game has perfect controls if you never think about them. Bit Pilot has a neat two-thumbs method that is a devil to explain, but it feels fantastic. Essentially, your two thumbs sum together. You can't understand it without playing the game, but it enables tiny intricate moves as well as big sweeping manoeuvres. You won't make many of those, though; part of its appeal is that (despite the fast pace) it's a game of subtlety. You'll die quickly if you pinball around the screen. Patiently wait in the middle, though, and make small adjustments... you'll live a little longer.

Super Crate Box, by contrast, has infuriating controls2. PC to touchscreen ports are always hard because on-screen buttons suck. Around 50% of my Super Crate Box deaths are down to a lack of control; things going awry between my fingers and the device. I end up jumping when I meant to shoot, shooting when I tried to jump, my jump going awry. It's frustrating, and it never happens in Bit Pilot or Super Hexagon. The chair-balance feeling depends on creating a feeling of mastery; you can't get that if it doesn't feel like your avatar3 obeys your commands.

Making it happen in your own work

I'm not a game developer, so I can't tell you how to build the perfect controls or chair-balancing feeling into your own games. I suspect it's art, not science; tweaking and playtesting until it feels right. I never got obsessed by Canabalt, but the developer spent a lot of time tweaking it until it played well.

And if your game lacks these qualities, don't worry. These principles aren't universal. Plenty of great games are made of different elements. There are games I love that are story-driven, or subverting the form, or wonderful art, or are simply absurd. But if your game lacks tension, excitement, and stickiness, think about whether you're lacking that chair-balanced-on-two-legs feeling.


  1. I think Super Hexagon is what my mother fears all computer games are: requiring twitchy, lightning-quick reflexes, along with hypnotic graphics and bleepy music.  ↩

  2. Though I have only played it on iOS. ↩

  3. By which I mean "the in-game dingus that represents you, the player". ↩

My laser-cut iPhone stand

When I got my iPhone I wanted a desk stand to accompany it. A friend had a stand that was simply a rubber strap with notches at each end. It seemed ideal – simple, portable, hard to break. But I couldn't find it online & my friend disavowed all knowledge, so I made one instead.

Unlike my laser-cut iPad stand, this one didn't go so well. Choosing silicone was my first mistake. It seemed the ideal material: safe to laser cut, reasonably priced, a good balance of stiffness and floppiness. But silicone's also heat-resistant – that's why it's used for cookware – and laser cutters use heat to cut. It didn't cut cleanly; no matter what I tried I had to finish each stand with a craft knife. I used 4mm silicone; thinner might have worked better, but it would be less rigid & durable.

My second mistake was also born of ignorance: few iPhone apps have landscape mode. iOS itself won't switch to landscape, so if you use the stand you'll be tilting your head a lot. The stand works in a portrait orientation, just about, but I don't trust it.

I can't recommend using this stand. But if you've been looking for a rubber strap stand, can't find one to buy, and want to make one of your own: this might be a good starting point. There's nothing wrong with the design, it's just not that useful. (And pick a different rubber).

Don't start with the foundations

I had an interesting conversation recently. It was something of a role reversal; the product person came at it from a data perspective, and I came at it from a product perspective. We were trying to figure out the roadmap – what features we could build, what features we should build, and their priority.

I produced a useful metaphor as part of this, but let's talk about the issue first. When you're developing a product or service, you should start at the front. What is the service? How will people interact with it? Why are people paying you for it1? How does it fit in with your existing/future services? You need this in a little more detail than an elevator pitch, but not to the level of a specification for external developers.

Once you've got this planning done you can figure out how to build it. That's the point to start thinking about the data you'll need to execute your plans – not before.

My conversation partner approached this from the other direction. "We're going to need data from our users for whatever we build," he thought, "And data is going to drive the business. Let's start there. What data is easy to collect? What can we do with that?"

That's a valid starting point for brainstorming. It can help you think up enhancements and quick wins. But it's not a good way to design your core product2. Chances are if it's easy, other people are already doing it. And even if it was really hard to collect or quantify certain data, if it's core to your business you'll have to figure out a way to capture it.

The data you collect & process is the crucial base for your product, but you don't start there. The metaphor:

If you're building a house, you'll need solid foundations. But you don't design the foundations first and then ask, "What can I build on top of this?"


  1. The $10 equivalent of this sentence: what's the value proposition?  ↩

  2. I'm using "product" and "service" interchangeably in this article. I don't think any of this thinking is specific to one or the other.  ↩

Goodbye, Google Reader

Google Reader gets turned off today. It's still working now, but the pop-ups were persistent. I know we're in the last few hours. Despite that I'm nowhere near acceptance; I don't want it to die. It's a new experience: the first time I've lost an online service I loved. I've drifted away from other products & communities over the years, but nothing else was part of my online life until the owners took it out and shot it.

I've used RSS for over a decade but I was a late convert to Reader. I used Opera's built in RSS reader for years, which was... alright. I had some janky unison setup that synced unread items between my desktop and my laptop1. That satisficed for years, but I switched when I could no longer tolerate the lack of feed organisation2. Over the years my habits changed – less reading at a desk on a PC, more on the sofa with my iPad – but Google Reader was the underpinning for all of that.

Reader wasn't an eyecatching product. It wasn't beautiful; it didn't feel fun. You didn't sign up and have your mind blown. But it was reliable, and versatile, and always available. It was a Volvo, not a Porsche. It's breathable air: you don't think about how much you depend on it until it's running out.

The first secret of Reader is that it's a tool – just like a car, or a laptop, or a Leatherman. Everybody used it differently (and some people not at all3). There's no one RSS world. When the shutdown was announced, most friends reacted in one of two ways: they were distraught, or they were incredulous. "Wait," the second group asked. "You guys are still using that? It's 2013! What are you still using RSS for?"

Well, like any tool, a lot of different things. Some people who won't miss Reader used it for discovery – finding new stuff to read. That's a solved problem for many people. Interesting stuff will surface on Facebook, Twitter, Hacker News or Reddit4. But that's not how I use RSS. Some other people use it as a firehose – to follow BBC News, The Guardian, or other big sources that publish multiple times a day5. But that's not me either. Personally, I use RSS as a combination of:

  1. Post-discovery reading. You get linked to something. It's so good you read 10 other pages, or consume the entire archive. You'd like to read the new stuff in the future, so you add it to your RSS reader.
  2. Niche updates. I have a thing for newspaper corrections so I'm subscribed to the Guardian's feed. I like reading the blogs of my friends, even though they only update 3 or 4 times a year. Sometimes it's something delightfully weird. They update irregularly and take seconds per post to read.
  3. Personal alerts. I've got a bunch of saved searches for relevant job adverts in London, eBay items, Kindle special offers, gig alerts, and music recommendations. There's also some social networks I don't log in to, but still get notifications if someone comments on my stuff.

If you're not a completist and follow the right people on Twitter, number 1 might not be a problem for you. But there's a lot of great writing that I only see in my Reader account, and social networks won't help with 2 or 3. Maybe other people use email for that and filter relentlessly; I think that keeping up with 300+ infrequently-updated sources is better suited to RSS6.

The second secret of Reader is that it was the foundation of an ecosystem. I use Reader on my desktop, and Reeder on my phone/iPad. I save links to Pinboard, Instapaper, & occasionally Tumblr. I hoped that the 3 month lead time would be enough for a credible alternative to emerge, but all seem flawed. Reeder for iPad hasn't been updated in months and lacks support for any alternatives; thus two components must change. I have a lot of sympathy for the people working on replacements: as I said, people used Reader in hundreds of different ways. I want a public API, the ability to keep feeds in folders, support for Instapaper, and good keyboard navigation so I can go through a feed of 30 items in 60 seconds7. Other users will have a completely different list. And that's not to dismiss the technical challenge of polling millions of feeds in a timely manner.

I don't know yet what my replacement will be. I'm cautiously optimistic about Digg Reader. Marco went for Feed Wrangler & Mr Reader, which is a strong enough endorsement for me to try it too. Another friend found email to be his replacement, but his love for Reader came from the social features; I barely used those. I'll probably try going cold turkey for a while too, to see what I miss.

Part of me is excited to look back on today. What will future me think of this? Right now, it feels painful, the end of an era. Maybe it will be. Maybe my reading habits will change yet again. Or maybe it'll be no big deal; the switch to some other service will feel seamless. Only time will tell.


  1. Yes: this is insane, in retrospect. But it was a different time; having two machines made me a power user. Normal people didn't do that. There was no Dropbox, no iCloud. Wifi was not ubiquitous; smartphones barely existed. And you could hold doubts about free hosted services without seeming like a kook; I mean, what would happen if they decided to turn everything off one day?  ↩

  2. Opera has folders now.  ↩

  3. Which is fine, obviously. I'm not trying to convert you to the Church of RSS; I'm just explaining why I liked Reader.  ↩

  4. And it's probably no coincidence that several of these friends work for a content discovery startup.  ↩

  5. Those people are crazy.  ↩

  6. Some people have asked why I need this. The truth is, I don't – in the same way I don't need Twitter, or my iPad, or a latté over my morning code review. But I do like it. It's part of the texture of my life and makes things easier. I don't want to give it up or change it, but I'm forced to.  ↩

  7. Ideal for photo blogs, one-hit wonder Tumblrs, or just culling a firehose.  ↩

Smart, gets things done, opinionated

I've been helping a client with their technical hiring. They need more developers and it's notoriously hard to select the good ones. It's extraordinarily difficult to tell the difference between someone who sounds good and someone who is good. It's practically impossible if you're not a developer yourself; that's where I came in.

One standard tenet of screening programmers comes from Joel Spolsky:

How do you know whether to hire someone? In principle, it's simple. You’re looking for people who are

  1. Smart, and
  2. Get things done.

That's it. That's all you’re looking for.

That's definitely a great starting point. But I think the list needs one more item: opinionated.

It's not enough to be smart and to get things done. I've interviewed a number of candidates who had a strong history of both. But as soon as I tried to get an opinion out of them I found myself stuck in a bog of equivocation.

Taste

Sometimes the opinions are matters of taste. I like to ask candidates what websites they like, what tools they use, and what they like about them. The last part's the key. I'm not trying to bond with you when I ask what websites you like; I'm trying to get a sense for your taste, your critical eye, and your ability to intuit what's under the bonnet. I'm not going to rule you out for using NetBeans when I like vim; if you're interviewed by someone who will, you probably don't want to work there anyway. I'm trying to figure out how you approach problems, what crutches you have1, and how much thought you've given to how you work.

Here's an example: you interview two candidates and ask them for their favourite websites. Both say they like Twitter. "Why?" you ask. Candidate A mumbles something inoffensive about how he likes talking to his friends. Candidate B talks about the problem of distributing messages to millions of people, near-instantaneously, pushing the data to web browsers and mobile devices. Who's the stronger candidate?

But delivery is important, too: what if candidate A had spoken confidently about how Twitter's changed how he interacts with his friends, how the public interacts with celebrities, and completely reinvented breaking news: all of a sudden it's not so clear-cut. One candidate is more focused on technology, the other on sociological impact. The right choice depends on your company & the job role, but now you've got more information to make the decision.

Technology

Sometimes the opinions are about technology. I always try to include an open-ended design question in an interview; lately I've been using "How might you design a system that lets people play Monopoly with each other over the internet?"2. The openness is a feature; good candidates will ask a few questions before diving in, and there are lots of dramatically different ways of answering.

One candidate proposed a peer-to-peer solution. That's uncommon, but not insane. You can make that work. But he couldn't explain the strengths or drawbacks. He couldn't explain why he'd chosen that instead of a client-server approach. "There's a number of factors involved" isn't an answer if you can't name some factors. I'm totally fine with a candidate changing their mind! A great answer would be "I started this as a peer-to-peer solution, but now I see problems with synchronisation and preventing cheating. So, in retrospect, I think a client-server model would be better." Unfortunately I couldn't get anything out of this candidate; I encouraged and cajoled, but he stuck with neutral platitudes.

The best people I've worked with all have strong opinions about how software & the Internet should work. We don't always agree, but being unafraid to express an opinion means we can discuss a problem and find a decent solution.

There's one final nuance: the people you want have pragmatic opinions and respect other points of view. I don't want people who insist they're right, don't listen to others, or ignore reality. Sometimes there are valid reasons to cut corners, do a hacky job, or do something that stinks. You need people who will roll up their sleeves and get stuck in. But equally, you should expect to hear about how you screwed up, how the situation should never have reached that point, and how to stop it happening in future.

I'm a developer. What am I supposed to do differently?

  • Be fearless in interviews. Your goal is to demonstrate your skills & knowledge, not avoid offence. Let's say you discovered the company's using a PHP-based stack, your CV says you just migrated from PHP to Java because PHP was unscalable, and now the interviewer's asking you what the problem was. Trust me: he's not feeling hurt. He's not saying that PHP's great and Java's crap. He wants to know what the problems were, and how changing language fixed them. Don't apologise, or equivocate, or say things like "That's just my opinion." It's obviously your opinion. Explain why you hold it.
  • Look at things with a critical eye. Pick a website or app you use daily. What's good about it? What sucks? If you could wave a magic wand, what would you change? What would you change it to? Why do you think it's not that way already? If that change made things better for you, would it make things worse for others? If so, do you still think it should be changed?
  • Ask questions. An opinion isn't a snap judgement, and it's only useful if it's been thought through. Interviews aren't interrogations – you get to ask questions too. Don't immediately jump into an answer if someone asks you to design a system; you don't know enough yet. How many users are we expecting? How technical are the users? Are there budget constraints? Is it web-only, desktop-only, mobile-only, or some combination thereof? Is performance an issue? Is it more important to optimise for server-side performance or client-side performance? Can we presume that all our users speak English? Can we trust our data to be valid? Can we hand-wave past a particular bit for now, or would you like me to outline that first?
  • Work on your interpersonal skills. Disagreement is fine. Discussion is great. But you must express that disagreement constructively, otherwise you're just being an asshole. Dale Carnegie wrote the classic book on this; The Usual Error is also worth reading.
  • Sometimes you have to watch the world burn. Maybe your interviewer is offended by your dislike of PHP, your belief in semantic HTML, or your system design. Be open to the possibility that you're wrong, and be humble, but remember the interviewer's done you a favour. Do you really want to work with someone who isn't open to other people's ideas and won't listen to explanation? Do you want to work somewhere where disagreements are settled with "I'm right because I've been here longest?"

  1. Everybody has crutches; they're not a bad thing. Why wouldn't you want the computer to make your life easier? Some of my favourites include syntax highlighting, auto-indentation, and auto-lint-on-save. IDE users probably like automated refactoring, inline help, and code generation.  ↩

  2. Shamelessly lifted from Reginald Braithwaite.  ↩

My FAWM 2013 experience

Earlier this year, a Hackspace member offered the mailing list a free MIDI controller. I'd been considering taking part in FAWM – February Album Writing Month – and this pushed me over the edge. I accepted the MIDI controller. I signed up for FAWM and announced my intentions. So how did I do?

Not well.

FAWM sets a simple goal: 14 songs, 28 days. People take part for all kinds of reasons and have different criteria for what constitutes a song. It's a challenge, not a competition: you're only accountable to yourself. Personally, I wanted to write chiptunes – 8-bit/retro computer game music. I've admired the genre for a long time, and I messed around with making some a couple of years ago. But I didn't manage more than a couple of 20-30 second snippets back then. It taught me how to use the software/hardware (I'm working on a separate article about that), but this would be the first "proper" music I've written since my GCSEs.

I wasn't expecting electronic music to be so time consuming. At full speed, with no blocks on inspiration, I could make one track a day. But that's an entire day of effort; 8-10 hours doing nothing else. More realistically, I could write 1 song every 2 days. I thought this would be enough, especially if I worked hard on weekends. But by February 10th I'd only managed 3 tracks and I knew I wasn't going to catch up. Between work, Valentine's day, & a friend's week-long visit from the USA I was never going to hit 14 songs. I intended to make a couple more songs with what was left of the month, but I wasn't enjoying it. So I gave up.

I've got a few half-written tracks left over, including one that's a "proper" chiptune (written with the Gameboy's hardware limitations in mind). One of my worries was that although I was using simple synths and tone generators, I wasn't making "real" chiptunes. The chiptune police would kick down my door, NES zappers drawn, shouting "Imposter!". Thus I tried sticking a bit closer to the original medium. I'd like to finish them off at some point, but I'm waiting for the desire to return.

So here they are: 3 songs that were meant to be chiptunes but probably count more as "chiptune inspired":

Would I do it again next year? Probably not. The FAWM community itself is amazing and I really appreciated the encouragement I received. But I don't think I can cram 14 chiptunes into one month without putting everything else on hold; even if I could, that doesn't seem like a fun activity. If I did take part again it would probably be something acoustic.

A brief dose of futurism

Much has been written about Google's self-driving cars. To recap: Google has started publicly demonstrating a car that can drive on public streets all by itself. It's deeply impressive technology, and is a manifestation of a decades-old prediction. Cars that drive themselves! No more congestion! No more accidents! Tomorrow's world today!

Because this technology is still stuck in the lab, demonstrated under carefully controlled conditions, my instincts are to dismiss it as speculation or decades away. But I've learnt that my instincts are basically slaves to my lack of long-term imagination. When I was 14 I read about e-ink and flexible displays. They seemed far-fetched then, but Kindles have been around for years and flexible displays seem just around the corner. Self-driving cars are probably closer than I think.

So how would that affect the tech world? Why would Google bother? Google say it's to advance society, which is probably partially true. But to me, the interesting part is the data. A self-driving car necessarily involves a whole bunch of sensors and cameras. A GPS and internet link are practically a given. So when this technology makes it into commercial vehicles Google's going to have a huge competitive advantage when it comes to maps and local data.

You won't need a dedicated street view team because you can use the imagery from people's cars. 3D maps like Apple's come from laser rangefinders and cameras, both of which will be built in to people's cars. Traffic flow data already comes from people's phones; it's a tiny step to pull it from the car directly. Updating maps with new/missing/altered roads is a similarly small step. As mobile bandwidth increases, the idea of a live streetview might actually be feasible. Scary as hell, but feasible.

This is all obviously good news for Google and good news for Google's users, but mapping competitors should worry. It's not about taking the human out of the process; it's taking the employee out of it. Other companies would have to pay people to gather data that Google's harvesting ambiently.

And now something completely unrelated

For a while I've been trying to figure out how to fit this thought into 140 characters, and failed:

You may think that with iPads and private space travel and drone strikes that we're living in the future. But your washing machine's UI begs to differ.

But trying to get a thought into a tweet can leave it open to misinterpretation. Is it a less-pithy version of "The future's already here, it's just not very evenly distributed"? Did Warren Ellis pre-emptively skewer it? The answer to both questions is "Yes and no."

My intention wasn't to normalise the age we're living in. I was trying to express the concept that some things are mind-blowingly amazing, whereas others remain mundane and niggling. I thought the great promise of the future isn't a few giant things, but a thousand tiny ones. Maybe we're condemned to overlook them; progress itself is a thousand tiny steps rather than one giant leap.

The shape of my life now is radically different compared to my life in 2003. And yet I still have to do my best Egyptologist impression when doing the laundry. A courier can't be more specific about a delivery time than a 12 hour window. I still buy pasta from the supermarket and find 3 unopened packs when I get home.

All I'm saying is there's still some room for improvement.

Help! Chrome's ignoring my Cache-Control headers!

You're a web developer and you've discovered your web app's sending a lot of static assets over the wire with every page load. These are static assets, so there's no need – they don't ever change. If you configure your web server with the right headers, you can tell browsers to cache them forever. Pages will load faster, and your server will be under less load. So you create a .htaccess file with something like this in it:

<ifModule mod_headers.c>
Header set Cache-Control "max-age=604800, public"
</ifModule>

You load your website and watch the network inspector in Chrome. You hit refresh, but you still see loads of requests for your static files. You hit refresh again. Maybe it cached this time, or maybe not. But refresh again, and everything gets retransferred! You start looking at individual requests. The headers are being set properly. You read the spec, and everything looks fine. Other browsers are respecting the headers and doing the right thing. What the hell's going on?

You're not going mad, and you probably haven't messed up. Chrome's trying to be helpful: it can't tell you're a web developer, and it doesn't know you're tapping that refresh button to test the server. Chrome's detecting the multiple refreshes, presuming you're doing it because the page is broken, and reloading everything from the server. I haven't figured out the exact behaviour it uses to do this, but it seems it involves whether you click through to other pages or not. As a result, you'll get more reliable testing if you navigate around your app a bit rather than clicking refresh.