haruki zaemon

Here are some ugly truths about white masters and black servants in Australian history.

From a logical and grammatical standpoint, calling women “females” is stupid.

Every day I experience how language can bring people together and build power. But language can also be divisive, dangerous, and exclusionary.

It’s the idea that when employees aren’t properly trained, integrated, or managed, they are operating at less than optimal efficiency and “team debt” is accrued.

Women in tech are the canary in the coal mine.

The tech industry may have a problem with women, but women don’t have a problem with technology.

The One King Lear is an honest attempt to solve a long-standing problem concerning the text of what many people regard as Shakespeare’s masterpiece.

Yitang “Tom” Zhang, a popular math professor at the University of New Hampshire, stunned the world of pure mathematics when he announced that he had proven the “bounded gaps” conjecture about the distribution of prime numbers—a crucial milestone on the way to the even more elusive twin primes conjecture, and a major achievement in itself.

Thinking about work in terms of boxes tends to make us behave as if it’s boxes, which tends to lead us to treat something complex as if it’s complicated, which is disorder, which usually leads to an uncontrolled dive into chaos if it persists, and that’s not usually a good thing.

a general rule of thumb: design your logging such that you can determine the state of the system at the time an event is logged.

2Q is a good buffering algorithm (giving a 5-10% improvement in hit rate over LRU for a wide variety of applications and buffer sizes and never hurting), having constant time overhead, and requiring little or no tuning. It works well for the same intuitive reason that LRU/B works well: it bases buffer priority on sustained popularity rather than on a single access.

Purposes are deduced from behaviour, not from rhetoric or stated goals.
– Donella H. Meadows, Thinking in Systems: A Primer.

It is fairly easy to formulate a set of values that sound pleasing and for which no real action is required. We might instead call these truisms.

It is much more difficult to define a set of values upon which we will act and for which we will be champion.

Harder still is finding others who share our values and our desire to act upon them, especially as values change over time.

The past while I have too readily been angered by what in hindsight was a mismatch of values. As a good friend and mentor once observed:

There is no right or wrong; there is only compatible or incompatible.
– James Ross

I would have been a better leader if I had been less cocky in my early career, and more confident in my middle career.

– anonymous

When I was 15 I quit school and lived in a Dojo in Japan. Through an accident of fate, I also ended up inheriting a large number of responsibilities. But I was 15. I was a teenager. Mature enough to be living overseas by myself to be sure, but I had quickly grown too big for my own boots. An unhealthy combination of self-importance and fear of failure.

Thankfully, one of the senior students living outside the Dojo sat me down one day and explained politely but in no uncertain terms that I was being a dick. It was one of the most generous things anyone has ever done for me.

I wish I had someone like that when I was a software development “teenager”. Someone to sit me down and explain how, when, and why I should pull my head in. That in the fight to build perfect software it’s easy to lose sight of the people. That empathy is more than just understanding how to solve a user’s problems.

I think if I had, I’d be a much better software developer than I am.

Metaphor:

|ˈmɛtəfə, -fɔː| noun A thing regarded as representative or symbolic of something else.

Analogy:

|əˈnalədʒi| noun A comparison between one thing and another, typically for the purpose of explanation or clarification.

Metaphors and analogies are useful tools to help someone understand something unfamiliar in the context of something familiar. The comparison doesn’t have to be literal but it helps that there is enough similarity to help cross the conceptual gap.

There is a fine line between metaphor for the purpose of understanding, and legitimising or emphasising the supposed importance of something by giving it a name borrowed from some other field.

One particular area of personal affront is the co-opting of martial-arts terminology in software development. Not only do I see the use of these terms as unnecessary, they are more often than not painfully misinterpreted and repurposed to suit a desired interpretation. In other words, something unfamiliar is used to help explain something familiar.

Which reminds me of this wonderful sketch from one of my all-time favourite shows, Blackadder:

Whenever I hear the expression “if X isn’t working for you, you’re not doing it right,” I always think of Nattō (なっとう)—a traditional Japanese food made from fermented soybeans.

Nattō is roughly the Japanese equivalent of Vegemite. That is, if you grew up eating it you think it’s God’s culinary gift to humankind. Otherwise, it’s possibly the most disgusting thing you’ve ever had the misfortune to try. There really is no in between.

Being non-Japanese, it’s fairly common for Japanese people to ask me if I like Nattō. Whenever I tell someone that I’m well and truly in the does-not-like camp, I am inevitably told with absolute certainty that the only possible explanation for me not liking it is because I’m “eating it wrong.” “Do you eat it with wasabi? No? Well then that’s your problem.” “What? You don’t top it with mayonnaise and some soy sauce?” “The secret to eating Nattō is spring onion!” The list of variations is seemingly endless.

I often see similar behaviour around software development tools and process. Only in these cases it’s much more like this magnificent piece by Jim Carrey:

For the 3 of you that follow my blog, the feed URL has changed. You can now find it at http://harukizaemon.com/atom.xml.

Six days ago, my extraordinary wife Jess gave birth to our third and final (yes, really!) child at home, a beautiful boy with a working title where his name shall shortly, hopefully, be.

Two days ago, I turned 40.

Today, I finally shipped my first iPhone app, Readtime, that I have been working on sporadically for a few months now with Benjamin Birnbaum and Ben Green, and the support of the Cogent folk.

I wish I had something pithy to end with but I don’t. I’m mostly just sitting here, wired, reflecting on what a crazy time it’s been, how utterly fortunate I am to have the life that I do, and hoping that by writing it all down, I might finally get to sleep. I think it’s worked :)

UPDATE: Our son has a name, George Samuel Harris.

I grew up at the dawn of personal computing. I was lucky enough to have been given a Commodore 64 as a christmas present and it blew my mind.

First Logo, then Basic, and before long I was scribbling down source code on reams of dot-matrix paper my step-Father brought home from work. I created screens that brought joy to my Mum by making “Happy Birthday” flash across our television screen in glorious 8-bit. I made a database to track every delivery of every test match in the Ashes Test series from England; an application that helped organise my Mum’s recipes so we wouldn’t lose all those great dishes my Hungarian Grandmother had scribbled down on bits of yellow, tabacco-stained paper; Mandelbrot sets – taking days to render until I realised that offscreen rendering was about 100 times faster - that had my friends jaws dropping at their beauty. I even copied verbatim the machine code from some magazine so that the kids at school could use a joystick to control simple sprites moving across the screen. I didn’t really understand what I was doing but they all thought I was a genius!

Eventually I started making a living writing software for very small Independent Software Vendors. Working in small teams, we produced amazing user experiences that I am still proud of 15-20 years later. It was as though I’d managed to con the world into paying me to do something that I really loved - creating software that put smiles on people’s faces.

For too many years now though, I have not really enjoyed my “chosen” profession. Sure, I’ve had moments here and there that have been thoroughly enjoyable but I’ve also had a sort of existential crisis every 12-18 months or so. “What was I doing this for?” “I’m clearly no good at this.” “Maybe I should find another line of work?”

Thankfully I’ve usually had the fortune to work with great people that have helped me through. It’s amazing just how important having great people around is no matter what you do. But even still I’ve developed a real love-hate relationship with the only real money-making skill I posess.

Then recently I tweeted:

I suspect very few “agile” teams actively work towards eliminating all the ceremony: standups, retrospectives, etc. ironic really.

What I meant by that is perhaps a discussion for another day but it did prompt a response from one of my colleagues:

I suspect the only way to remove all the ceremony is to remove all the other members of the team.

And you know what?, I think he’s absolutely right. Software development, and specifically corporate software development, is almost entirely about the organisation and the people therein. More specifically, it is about addressing the needs and problems of the organisation which largely revolve around scaling people and processes. I’ve been saying almost precisely that for years - “software is a means to end; it is not even close to the most important problem to solve.”

Now, don’t get me wrong. I’m not suggesting that’s a bad thing at all. Large organisations exist to produce “value” for shareholders, be they employees, management boards, or actual stockholders and software is but one means to that end. Were I to work within a large organisation, I would continue to deliver the same message.

The thing is though, I never took that line of thinking to its logical conclusion. Until that tweet. When I did, I realised that my growing apathy towards software development was completely unfounded. What I’d grown weary of had nothing to do with software development. Rather, I was tired of solving organisational problems. I was tired of focusing inwardly. I missed working in a team of people that implicitly and explicitly trusted one another to build software that addressed the needs and problems of people outside the organisation. I wanted to rekindle that love I had of using software as my tool to delight people. I realised that’s why I enjoy product development, real product development - not the kind that goes under the guise of “innovation” within large corporates.

Thankfully, for the past 18 months or so I’ve been working in a company that has supported my family-work balance, and with colleagues whose passion reminded me of my own. I feel as though I can work towards getting closer to my software development roots. Ultimately, I want to go back to working in small teams of highly motivated and trusting people building, importantly, end user products. I realise that I actually LOVE software development, just not as many now commonly know it.

I’d always been a spiritual person but my practices had been somewhat ad-hoc in nature. Then, in my late 20s, I met a group of people that seemed to speak my language. They belonged to a local church and so I went along. I converted soon thereafter and have been devout for more than a decade. However, it has been a somewhat rocky road. So much so that I recently went to see my local pastor.

I told him that no matter how often I practiced, how hard I prayed, or how diligently I followed the rituals, I still encountered problems I couldn’t resolve. That not everything I turned my hand to was a success. I told him that I was beginning to have my doubts. That there didn’t seem to be any scientific proof for any of his beliefs or for that matter anything written in the scriptures. That I sometimes preferred to meditate alone and that I found the gatherings to be succumbing to a kind of group-think. In reply he offered some words of advice.

He told me that no matter what, I should believe. That scientific evidence was unnecessary and that what mattered most was that I believed and followed all the practices as set out in the scriptures. He urged me to read and study the scriptures and to attend church gatherings to discuss my understanding with others wiser than I, who may have more insight into my spirituality. God is there, he said, to help those that are willing to take the time to understand his teachings. That I should not be disappointed if my prayers were not answered, and that not everything I do will turn out for the best, as I am not yet enlightened. For when I am able to worship fully and sincerely and in the correct manner, all will be revealed.

Actually, I’ve never been particularly spiritual, I’ve certainly never joined a church, and I think the only time I’ve ever had any kind of religious instruction was at High School – although I have read various parts of the Old and New Testaments. That said, I have been witness to this kind of discussion both in person and via blogs, Twitter, etc. only you’ll need to replace Religion with Agile, Pastor with Coach, Church with XP User Group, etc.

Unlike some languages, Ruby has no real way (that I know of) to define overloaded methods. Instead, you can specify that certain arguments are optional. For example, if we were to re-implement the Enumerable#reduce method, we might do so like this:

def reduce(memo = nil)
  return slice(1..-1).reduce(first) if memo.nil?
  each { |element| memo = yield(memo, element) }
  memo
end

That is, if no memo was specified, use the first element as the memo with a call to #reduce on the remaining elements of the array.

This approach generally works out fine unless either nil is actually a valid value, or interestingly, when it’s not. In the first case, I don’t want nil to trigger the special behaviour, I want it passed to my block. In the latter case, I’ve encountered times when a programming bug has meant that I’ve explicitly passed nil to a method in error which has triggered the special behaviour.

At first I attempted to solve this problem using a splat:

def reduce(*args)
  return slice(1..-1).reduce(first) if args.length
  raise ArgumentError, "wrong number of arguments(#{args.length} for 0..1)" if args.length > 1
  each { |element| memo = yield(memo, element) }
  memo
end

Which on the face of it isn’t too bad I suppose but get’s awfully complex when you have methods that accept multiple arguments.

Another option might be to use named arguments and a hash. For example:

def reduce(args = {})
  return slice(1..-1).reduce(first) unless args.has_key?(:memo)
  raise ArgumentError, "wrong number of arguments(#{args.length} for 0..1)" if args.length > 1
  each { |element| memo = yield(memo, element) }
  memo
end

some_array.reduce(memo: "some memo")

But from experience, this makes the calling code unnecessarily complicated and is no better with multiple arguments.

The solution I settled on, and believe me I’m open to suggestions, is to use a default value that I know won’t be used by calling code:

UNSPECIFIED = Object.new

def reduce(memo = UNSPECIFIED)
  return slice(1..-1).reduce(first) if memo.equal?(UNSPECIFIED)
  each { |element| memo = yield(memo, element) }
  memo
end

This way the calling code remains the same, the method definition remains largely the same, and to my mind explicitly calls out the case where the arguments aren’t specified by the caller – much the same way you can call #block_given? to determine if a block has been passed to a method.