Category Archives: Projects

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

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.

Gathering stats and Herding Cats

Naga IT Services
Filed under: Industry, Projects, Talk notes

On Thursday 5th February, I gave a short talk at the Cape Town Scrum Users Group about RailsBridge.

gathering-stats-and-herding-cats

My slides are up on Speakerdeck. I talked about RailsBridge itself (the upstream organisation and how our Cape Town chapter came to be) and the Cape Town team’s focus on Continuous Improvement. I talked about the various methods we’ve used to gather feedback (and how successful or not they were), what feedback received, and what we did with it (lots of things!).

I’ll be giving a remixed version of this talk at the Cape Town Ruby Brigade in March, where I’ll focus more on the Ruby and Rails bits, and the curriculum.

(Yes, me doing all this Ruby stuff is slightly odd, since where I work now (Praekelt Fuondation) is a Python shop. Vumi, for example, is all Python. ¯\_(ツ)_/¯ )

Rape Crisis CTFEDs Hackathon: the seconding

Naga IT Services
Filed under: Projects

A few weeks ago, the Cape Town Front-end Developer meetup group for our second Rape Crisis Cape Town Trust hackathon. Although it went better than the last one, there is still lots for us to learn about the shape and structure of hackathons, and about how we can best help organisations like RCCTT.

What went well

The Style Guide is progressing nicely. We’ve got a Grunt set up to generate the style guide and get things moving along quickly, and we’re making good progress with it. We’re sort of aiming for a bit of a Style Guide driven development approach.

Even though it was after the hackathon, we managed to squeeze in some time to update the mobile Theme for the site to add some basic colours and branding to make it look a little more like the desktop site. This is temporary (it will fall away once the new, shiny, responsive is ready), but we think it was a useful short term solution, and didn’t take too long to do.

Using GitHub issues is still sort of working. Having a To Do list that you can grab things from, or assign things to people on is very handy.

What didn’t go well

Set up. Again. Even though most of us had the bits and pieces we needed on our machines (MySQL, PHP, something to run a local web server), we hit a few speed bumps when trying to run the site locally. For next time we need to be more on the ball about being ready: we need to be clear that everyone must have a copy of the site up and running on their machine before arriving on the day. The flip side to that is that set up problems are often easier to fix with someone helping, so leaving it to the day is tempting if you get stuck during the process. The other part of this is that we left it to the last minute. We’re all busy at our day jobs, and Saturday was there before we knew it.

We also got sidetracked by another problem on the live site. This is usual developer behaviour, and rightly so: when something is wrong on production, anyone who can help drops what they’re doing and tries to help fix the problem. There was odd behaviour from a particular WordPress Plugin on the live site: the Page Peel Plugin. The version of WordPress on the live site was updated, and that caused the Plugin to throw an error, which in turn stopped the widgets from registering. The widgets are basically all the little blocks that aren’t main content. For this site, that meant the homepage looked really broken! It was not a happy hour or so.

What to do differently next time

I really like how Zurb run their Wired events (their yearly 24 hour hackathon-like thing to help non-profits). Their recent post about it, Mobilizing Nonprofits Through Design Thinking, is inspiring, and has helped solidify some of the things we were thinking about from our recent experience.

We think we’d like to have a dedicated Project Manager for the day. That might be one of us developers stepping away from the keyboard for the day, or we could rope in one of our PM or Scrum Master friends from work. Having someone to keep us going and steer a bit would be really helpful.

On a related point, we’d also like someone from RCCTT there for the day to help guide decisions. It might also be interesting for them to see how this works, and what the hackathon actually entails. We would also be able to sneak in some content work with them. Another thing that’s on the back burner is a Content Strategy exercise for the site: having a RCCTT staff member on the team would mean that we could look at doing little bursts of that on the day.