Blue Lug is a bike shop in Japan. Crust Bikes design cool bikes. This video is a zen-like 43 minute dive into building up a Dreamer. There’s so much effort and attention to detail that goes into making this beautiful bicycle. The process is well understood so the end result is a testamet to the mastery of the people (or just a person, it’s hard to tell when you can’t see their face) building the bike.
Sure. this video isn’t about software development, but its It’s a calming and inspiring watch all the same.
I am a big fan of the idea of improvement kata. I’ve practiced kata at work several times: establish where you want to go, establish where you are now, regularly do small things to improve where you are until you get where you want to go.
I consider myself a self-taught programmer. My learning was all to get something working rather than doing it the good way. Well, I’d like to get better at doing things the good way and improvement kata is the way I want to do it.
Enter Jon Bentley’s Programming Pearls, a book about solving computer problems effectively. The book has been on my self and then my kindle library for years. I’ve never really gotten past the first chapter. I definitely haven’t taken on the exercises – I felt I was too dumb.
This weekend I decided to have a go at one or two problems in Chapter One. Over the course of some early mornings before the rest of the family got up, and a little bit on Sunday afternoon, I wrote a script that generates random numbers and a program that sorts them.
The generator was written in Ruby, my go-to language. I implemented the Fisher-Yates shuffle algorithm and employed a favourite ruby trick, the ability to set or return more than one value. It made me feel quite the clever clogs.
a.each_with_index do |item, index| random_index = rand(index..(a.size-1)) a[index], a[random_index] = a[random_index], a[index] end
The problem in chapter one called for a bitvector, basically an array of bits. I had it in my head that that was something that would be easy to do in C. So I broke out WSL2 and installed gcc.
Before I even got to implementing the bitvector I had to teach myself the basics of C programming: writing output, reading and writing a file, pointers, memory allocation, compiler flags. It was super fun.
Then it came to the bitvector implementation and I realised that C deals with bytes, not bits, and I was going to have to do some work to get to the bits. It would have been the same in Ruby. I had a look at some documentation for getting down to the bit level and declared it too much for a single kata.
I found a gist that looked like it created the thing I needed, typed the three functions I’d need (I seem to learn better by doing that) and implemented the sort algorithm. After some faffing around with the order of compiler flags had a working program. Good enough for one weekend.
I learned a few useful things in this kata. I think the biggest benefit was just getting back into the programming headspace. I’m going to persist with this practice and continue using Programming Pearls as a source of ideas.
This kata highlighted by ignorance of bitwise operations. It’s something I’ve never got, something I’ve never really had to deal with. It does seem like something that I should at least understand when I come across it, though. My next kata may dive into that.
I am not a natural born programmer. I think I wrote three programs before I went to university, all in BASIC. The first was the classic one anyone who’s spent time with a C-64 has done:
10 PRINT “JOE IS COOL” 20 GOTO 10 RUN
The author as a teenager, playing golf rather than coding.
The second asked your name and if you entered anything other than “JOE” it would call you a dick. The third was an ambitious attempt at a text adventure written. I got stuck as soon as the story called for the user to pick one of three choices.
Even at university I wasn’t really a programmer. My degree was in Information Science and it wasn’t really based around writing software. The coding we did do was weird in the context of today. A lot of it was in MS Access or bespoke AI tools and a sprinkling of C++. An odd mix, right? The big project in the final year was written in a 4GL and hooked up to a Digital RDBMS.
I’m a fan of saying that university teaches you to learn and think. I think it’s fair to say that university taught me how to learn to code on the job. And it was on the job that I discovered the joy of programming.
Over the years I was lucky to be in jobs that gave me many opportunities to work on dozens of different applications, tools, and languages. I’ve written apps in Delphi, Java, ColdFusion, PHP, FoxPro, C#, and, my favourite, Ruby. I’ve built them on top of half a dozen databases. For a while I was a Unix sysadmin, sorting out the email for some “world famous in New Zealand” bands. I’ve been made things for fun, things for bands, things for government, things for big corporations.
A lot of the time I was on my own, inheriting existing stuff, and flailing about until I understood how they worked. My self-taught techniques got things going, but, man, I don’t think you’d call them good.
As my career progressed, I became a member of some great teams and learned from people who really understood how to code. I think I got good at debugging, at finding why a problem is happening and marking it with an X. I’m still not that great at fixing the bugs, or not causing them in the first place.
As an engineering manager I don’t code unless it’s really, positively, absolutely, necessary. I’ll be a rubber duck for anyone who asks. I’ll explain business rules and give excuses for why something “works that way”, but I don’t generally put shit into production.
One of the best articles on engineering management is Bored People Quit by Michael Lopp. It has some wonderful advice but the bit that has stuck with me is the coda:
Part of your credibility as a leader is your public and repeated declaration that it’s your job to help your team succeed, but you have another task: you need to keep building stuff. I’ve gone back and forth on whether managers should code and my opinion is: don’t stop coding. Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think and how they become bored.
And that’s why I spend several hours this weekend practicing coding. It’s why the post after this one will (probably) be all about that practice. I have always loved the joy and discovery of programming and it’s important for me to keep finding the joy. This blog is here to make sure I keep doing it and to celebrate the joy.
Double Fine Adventure is a behind-the-scenes documentary series chronicling the making of Broken Age, from Kickstarter promotion through to distribution on multiple platforms.
It’s a 20-episode series and it’s as bingeable as anything you’ll find on Netflix. All the nuts and bolts of making a game are covered but, more importantly, you feel like you get to know the Double Fine team as they put in the work to create a game they are proud of.
Double Fine Adventure is about those people, more than anything else. I’d work there in a heartbeat.
I tend to watch the series every year or so and I always come away with a renewed appreciation of the fact that good things are made by people who really care about what they’re doing.
