Author Archives: Steve Barnett

Notes on Show Your Work

Naga IT Services
Filed under: Process, Projects

Over the weekend I read Austin Kleon’s Show Your Work. The book is about getting discovered and self-promotion, but I picked it up with a more general vibe in mind. Skimming through the preview I was hoping I would get some nuggets of good advice by reading it, and I wasn’t disappointed.

The book is divided into ten sections:

  1. You don’t have to be a genius.
  2. Think process, not product.
  3. Share something small every day.
  4. Open up your cabinet of curiosities.
  5. Tell good stories.
  6. Teach what you know.
  7. Don’t turn into human spam.
  8. Learn to take a punch.
  9. Sell out.
  10. Stick around.

Show Your Work sketchnotes - page 1

Early in the book, Austin talks about collaboration and connections, in the context of being part of a group. I really dig this because that’s how I feel about all the meetups and things I’m involved with (CTFEDs, SPIN, RailsBridge. I loathe the term “networking,” but I do really enjoy hanging out with smart people, and talking about interesting things.

Other themes in the book were things like honest, openness and vulnerability: humans like connecting with other humans.

I also enjoyed his discussion around sharing something small every day (even though I mostly fail at doing that!): over time, doing lots of little things can add up to a big thing.

Show Your Work sketchnotes - page 2

Having recently read Sharon Bowman’s excellent Training From The Back Of The Room, I really liked the section in Mr Kleon’s book on teaching what you know. He talks about how, by teaching other people what you know, you learn things yourself.

Perhaps the biggest takeaway from the book for me was the section that explains why sharing your work won’t put you out of business: quite the opposite in fact. I’ve had many arguments with people about this before. I’ve mostly tried to talk about how there is plenty work to go around and that it’s on a continuum (my clients aren’t necessarily the same as your clients). I’ve also tried to talk about how keeping things secret doesn’t work. If your only value to the client is that secrecy, then your business won’t last long.

Mr Kleon talks about how knowing the technique is very different from mastery of it. The various activities of User Experience are an excellent example of this. Usability testing has very simple steps (or so it seems): find a person, watch them use a product, and take notes. Doing it well is another matter entirely: who do you find; what tasks do they do; what do you ask them (and what do you not); what things are important (and not); how do you interpret the results? That knowledge only comes with practice and mentorship.

I guess it’s not surprising that nowadays I find myself working on Open Source projects like Vumi and Universal Core.

Show Your Work sketchnotes - page 3

One last thing I took away was to “find my knuckleballers” – the people who share my mission and principles. For me, that’s focusing on Progressive Enhancement. I want to always be mindful of the worst case scenarios and build things that will work on bad connections on hostile browsers. I want to build things that work when JavaScript fails to load, things that load fast and don’t cost the users lots of money.

It seems that there are very few people like that in Cape Town. Justin, Alex, and Rich are people whose work and principles I hold in high regard.

Show Your Work sketchnotes - page 4

Two quick front-end performance-related things

Naga IT Services
Filed under: Process

At work I’m doing some researching and setting up of things to help improve the front-end performance of our stuff. Here are two quick things that keep bubbling up.

Prefer fewer, larger, files

Avoid many, smaller, files.

This is because, broadly speaking, latency trumps bandwidth when it comes to performance concerns.

Prefer simple CSS selectors

Rather have an extra class in your HTML.

This is because browsers can figure out simpler selectors faster.

Training From The Back Of The Room

Naga IT Services
Filed under: Process, Reading

Over the past few days I read through Sharon Bowman’s book “Training from the back of the room.” I mostly read it to give me some new ideas for RailsBridge Cape Town, but also because I generally want to improve my facilitation skills. They’re kind of the same reasons that I went on Growing Agile’s great Facilitation workshop last year, which uses a bunch of the techniques in Ms Bowman’s book.

Quite a lot of my job is arguing about / selling people on ideas and approaches (building with Progressive Enhancement, or Responsive Web Design, or adopting a particularly User-Centered Design flavour of User Experience). I’ve also been trying to keep in mind Mike Monteiro’s advice in his books and talks (which are about being a Designer, but lots of the lessons apply across disciplines. Check out his keynote at Interaction15).

What I learnt about RailsBridge

Reading Ms Bowman’s book, my biggest realisation was that we need to be a lot more learner- and learning objective-focused. We’ve made a lot of changes to the course since July 2013, and added lots of good things (based on feedback from the students), but we haven’t added them all in ways that are really learner-focused. The changes tend towards more of us talking, and not more of them doing, which it should be.

In particular, we’ve added some contextualising / explaining into the opening presentation. We should be doing these things as activities by the students instead. We also need a much better as-they-arrive set up. At the moment, they’re welcomed, grab a drink and a name tag, but they should start with something topic-related immediately.


We’re care a lot about feedback at our RailsBridge because we’re really interested in continuous improvement. After reading Ms Bowman’s book, I realise that we’re doing it a bit wrong: our feedback mechanisms have been great for us, but we should be focusing on it being great for the students. We started this a bit with using pair-teaching at recent RailsBridges, but we need to keep moving in that direction.

One of the challenges we face is pacing: our students arrive and (especially) leave at very varied times. This makes it difficult to do things that involve big groups of people: we can do single and pair activities fairly easily, though, so we’ll need to focus on those.

Next steps

There’s so much good stuff in the book that it’ll take a while for it all to sink in. I think that the book would have worked slightly better for me in print. I’ve ordered a paper copy (I read it this time on Kindle) so that I can re-read it, scribble in it, and make notes.

I’m also going to make up index cards of the 65 activities in the book and have them as a deck of cards. I’m going to use that deck to help me figure out which activitieswould work best at RailsBridge.

I really enjoyed Training from the back of the room and learned a lot about how the brain works, and a better way of teaching. I hope it will help me make some changes that will mean a better learning experience for RailsBridge attendees.

Hands-on device testing

Naga IT Services
Filed under: Industry, Projects

One of my side projects is the Nomad Device Lab. It’s an Open Device Lab: a shared community pool of internet-connected devices that’s free to use for testing purposes by web and app developers. If you do a Google image search for device lab, you see a lot of walls of devices. For me, this feels a bit off.

Having all the devices on the wall is okay for testing layout and general functionality, but it misses a bit part of the testing: the user experience.

One difference is the physical experience: how you hold and interact with the device. Tapping a phone mounted on a wall is not the same as the more usual use case of using it with one hand and one thumb.

Another difference is performance: the speed of the site. Even though phones and tablets (and many other types of internet-connected devices) are getting faster, they’re still slow compared to their laptop and desktop counterparts. It’s hard to gauge just how slow when you’re looking at a wall of devices all updating.

Although I’m a big fan of apps like Ghostlab and tools like BrowserSync (which I use a lot), taking the time to sit and play with your sites manually on a range of devices really lets you feel the pain of loading and interaction times.