Are you talking about software kitchens?

This is a cop-out because it’s a rehash of my previous post, but as an added bonus, here’s a video of me delivering it as a speech at my Toastmasters club.

Toastmasters is a club for improving your public speaking skills. You give speeches and take on speaking roles, and get feedback about what you did well and areas for improvement at the end of the session. The club I go to is full of amazing people and certainly one of the reasons we’re still here in Stockholm! Of course, as you might expect, there’s an evaluation to go along with the video.

And my actual speech draft. When you’re up on stage, some things just don’t go the way you plan, and even from the beginning things started out slightly different 🙂


I work in IT as a software developer, but it’s hard for me to explain what that means to anyone else. A few years ago, to work in IT meant you were “good at fixing computers” or “installing antivirus”. Nowadays it means you’re “making the next facebook” or “about to become a billionaire”. There’s just so many facets to being a software developer that it’s sometimes easier to just grin and nod sagely rather than to explain exactly what I do.

One analogy I’ve recently found useful is a kitchen in a restaurant. No one knows how a software company works (unless you work in one), but everyone has some idea of how a restaurant works, even if they haven’t worked at one. You have waiters, you have the cooks and of course you have the customers. In such a setting, I’m one of the guys in the kitchen.

But this is where it gets interesting. Every kitchen is different. I work in a small kitchen where I have to share my tools, ingredients and space with other cooks. Everyone chips in for a dish, someone does the chopping, someone does the tasting and someone does the frying. Mostly. Some kitchens cook without tasting. Some kitchens have only one cook. Some kitchens have the best tools. Some kitchens have the best cooks. Sometimes the cooks are overwhelmed and overworked. Sometimes the cooks aren’t even from the restaurant, but from the pizzeria across the road. cough outsourcing

Many of the struggles I face are more easily explained as soon as I talk about a restaurant. When I tell people about how users of our software have unrealistic expectations of how it should work, or what can be changed, rather than empathy sometimes I get “but it’s just software, can’t you just change it?”

But when I tell people about unreasonable customers at a restaurant they go, “yeah, I understand”
Imagine a restaurant where customers walk in, and they tell the waiter what they’d like to eat. “Can I have this but vegetarian?” “Can I have truffles on the side?” “Can I have the pecan pie, but no nuts?” “Can I have fried rice, but without the rice?”

We’re more familiar with the idea of an unreasonable customer at a restaurant than an unreasonable user of some software application. In both cases, the customer has no idea how hard their request actually is. They think they have an idea of how hard it is, but without actually having worked in a kitchen, they haven’t got a clue. Of course they might have been chefs before, or formed their estimate based on visits to other restaurants, but that’s kind of irrelevant because there’s someone between the customer and the cooks.

It’s the waiter.

Most of the time the waiter says “sure we can do that”, sometimes he says “that is impossible Madam”, but it’s really up to how well he understands what’s being asked. Often he has other agendas. Maybe he would like to please a really important customer, sometimes he is wildly optimistic about what his kitchen can produce. Whatever the case, he converts a customer request, into a slip for the kitchen.

And this is where I come into the picture.

The slip arrives at the kitchen and everyone scrambles. We look at the slip and go “What the? How could we possibly make this in time?” There’s a deadline to meet, sometimes you’re still dealing with the fallout from the last dish and what sometimes ends up being put on the plate is something thrown together in a rather haphazard manner. Along with prayers that all of the stuff went in. No one likes a meat pre without the meat. Unless they asked for it of course….After all no one likes a meat pie without the meat…unless they asked for it of course. Sometimes it’s so bad the waiter simply rejects it outright.

Assuming that it’s decent enough to be served, and the waiter has written the slip correctly (certainly not taken for granted in many places! sometimes what you asked for is not what you get…), you eventually receive your dish. Sometimes when you see it on the plate it looks delicious, but you bite into it and you find an eggshell or bits of plastic (remember the haphazard assembly?). Sometimes it tastes fantastic but when you arrive home, you spend the next week camped out in front of the toilet.

You might think there are food inspectors that go around restaurants, making sure something like this doesn’t happen, or that offenders get punished and blacklisted…. but there are areas where the analogy becomes a little more absurd. All that for the next speech.

In the meantime I hope I’ve helped provide better context into how a software developer fits in to a software company, and the kinds of challenges we face. How about you? Do you work in a hypothetical restaurant? Are you a cook? A waiter? Or perhaps the person standing outside the restaurant, touting customers and trying to get them in. I’m looking forward to hearing about your restaurant stories.

This isn’t the restaurant you’re looking for…

This is part 2. Part 1 is here.

So this is where the software development as a restaurant analogy starts getting a little weird. To be fair, these examples are more quirks of the industry more than the profession itself.

A customer at a restaurant

Customer: “There’s a fly in my soup”
Waiter: “Oops, that must mean there’s a fly in everyone else’s soup”
Customer: “What are you going to do about it?”
Waiter: “Well, if it’s a big enough fly, tomorrow’s soups will not have it. Otherwise everyone will have to live with it for a few months.”
Customer: “Eh?”
Waiter: “Well, even after a few months, it’s a Maybe. Depends on if there are also roaches in the soup”

If you’ve ever watched a restaurant service challenge on Masterchef (try the Australian one, it’s much better :P), producing dishes for a bunch of people is back-breaking work. Even if it is the same dish over and over again. If we think of software as food, producing a copy of the software requires little-to-no effort. One consequence of this is if there’s an eggshell in one dish, all versions of that dish probably have the eggshell too. The exact same one.

Not all eggshells are created equal though, a single dish has a unique combination of flies and eggshells. Some are known, and some are yet to be discovered. There’s an ongoing struggle in the kitchen between removing the undesirables, and adding more flavour to the dish. Or some other dish variation…

A customer arrives at a restaurant.

Waiter: “Welcome Madam, we have the clam chowder, Florentine steak and vegetarian lasagne available today”.
Customer: “That sounds interesting. I’d like a clam chowder, but I’m actually lactose intolerant. Can you do something for me?”
Waiter: “Certainly Madam, but you will have to come back later. Maybe we will have it on the menu by then”
Customer: “How much later?”
Waiter: “Maybe a few months. Maybe a year. It depends. In the meantime, maybe you can try removing the cream yourself.”

If you’re in a restaurant, you’re expecting some flexibility. Small variations are taken for granted. In a software restaurant, since you’re getting copies of stuff, you’re not getting changes until the “master” copy is updated. When does the “master” copy get updated? Remember that we’ve already got flies to squash and eggshells to remove, in addition to flavours to add. And that’s not the only problem.

In the kitchen

Waiter: “We have 100 more orders of the clam chowder coming through.”
Cook: “The clam chowder from last month is the one you want. Just make a 100 copies of it. You know where the food cloning machine is.”
Waiter: “Guys, there’s lots of flies in that one…”
Cook: “We’re trying to fix the recipe. We only have the old one to work with. It’s a hundred pages long, full of corrections and hard to know what’s needed for what taste anymore.”
Waiter: “Do we have something for lactose intolerance?”
Cook: “Erm… maybe in a few months. Could they take out the cream themselves?”
Waiter: “Seriously?”

Software developers aren’t really cooks. They “cook” the “master” copy of the dish, but really, they spend most of their time refining recipes. Software developers are more like recipe authors than cooks. Except the recipes are hundreds of pages long, often passed down from generation to generation without much explanation; and steps interact with each other in strange and wonderful ways, where it can magically give rise to eggshells and roaches along the way.

Just think about what kind of process someone refining recipes has to go through to “test” their recipes! Say you’re trying to refine a recipe. Maybe make it more spicy, for your friends from Indonesia. How would you go about doing it?

If you’ve tried to put a dish together, and had to improvise, you know how hard it can be to work your way back to what went into that one amazing dish. When you’re trying out different things, sometimes it can be hard to keep track of what taste was the result of what magic ingredient you added. And you can never create that one amazing dish. Ever again.

In the kitchen

Waiter: “Someone’s found a roach in the lasagna”
Cook: “Did it come from the bechamel sauce?”
Waiter: “Maybe. How would they know?”
Cook: “If it did we may have a bigger problem. That bechamel sauce is used in the fish pie and croquettes as well.”
Waiter: “So they’ve all got the roach?”
Cook: “Yessiree. Actually if they don’t have it, it means it’s a problem only with the lasanga recipe, not the bechamel”
Waiter: “Seriously?”

In any normal kitchen, if a batch of sauce is bad, you just make a new one. In a software kitchen, if a sauce is bad, everything it’s gone into is bad. Every single dish with it. And there’s nothing to be done till the sauce recipe is fixed.

It also highlights a problem common to both kitchens. It’s sometimes pretty hard to figure out what caused a problem! (Think masterchef taste test… what went into a dish to cause a particular taste?)

Surely this can’t be the way software is made! There’s got to be food inspectors coming in occasionally right? Well… tune in next time to find out why, despite what seems like a pretty crummy state of things, more established software kitchens have their own secret sauce recipes … for making secret sauces

What kitchen do you work in?

I often have trouble explaining what I do to someone outside of IT, especially for the first time. Don’t get me wrong, I’m not embarrassed to be a Software Developer (certainly not a Software Engineer, but that’s another topic for another time), but more getting across all the nuances of what I do across. Anyone who’s worked in say databases or devops knows what I mean, just saying you work in IT is much easier than explaining what is it you do.

One analogy I’ve used in the past is a kitchen in a restaurant. Most people have some idea of how a restaurant works, even if they haven’t worked at one. There’s a difference between a small mom-and-pop operation and a michelin star restaurant though, from the food itself right down to where the ingredients come from. The supply chain and the processes involved in turning the raw ingredients into an amazing dish are quite different. The interesting part is how far you can really stretch the analogy, and get across the nuances of your workplace 😉 An interesting exercise is to compare what you do to the appropriate area of the restaurant.

Imagine a restaurant where customers walk in, and they tell the waiter what they’d like to eat. Most of the time they’re familiar with the menu, and they want the same thing, but with a little twist. “Can I have this but vegetarian?” “Can I have truffles on the side?” “Can I have the pecan pie, but no nuts?”

Now the customer has no idea how hard their request actually is. They think they have an idea of how hard it is, but without actually having worked in a kitchen, they haven’t got a clue. Of course they might have been chefs before, or formed their estimate based on visits to other restaurants, but that’s kind of irrelevant because it’s now the responsibility of the waiter.

Most of the time the waiter says “sure we can do that”, sometimes he says “that is impossible Madam”, but it’s really up to how well he understands what’s being asked. Often he has other agendas. Maybe he would like to please a really important customer, sometimes he is wildly optimistic about what his kitchen can produce. Whatever the case, he converts a customer request, into a slip for the kitchen.

Every kitchen is different. I work in a small kitchen where I have to share my tools, ingredients and space with other cooks. Everyone chips in for a dish, someone does the chopping, someone does the tasting and someone does the frying. Mostly. Some kitchens cook without tasting. Some kitchens have only one cook. Some kitchens have the best tools. Some kitchens have the best cooks. Sometimes the best cooks are overwhelmed and overworked. Sometimes the cooks are from the pizzeria across the road.

The slip arrives at the kitchen and everyone scrambles. In many software kitchens, particularly the small ones, everyone is pretty good at making the dish, but no one wants to know how to put the dish together. It’s often seen as “not interesting” or “not as glamorous” as doing the actual cooking. Consequently, the dish assembly is usually thrown together in a rather haphazard manner. Sometimes it’s so bad the waiter simply rejects it outright.

Assuming that it’s decent enough to be served, and the waiter has written the slip correctly (certainly not taken for granted in many places!), you eventually receive your dish. Sometimes when you see it on the plate it looks delicious, but you bite into it and you find an eggshell or bits of plastic (remember the haphazard assembly?). Sometimes it tastes fantastic but when you arrive home, you spend the next week camped out in front of the toilet.

You might think there are food inspectors that go around restaurants, making sure something like this doesn’t happen, or that offenders get punished and blacklisted…. but there are areas where the analogy becomes a little more absurd. That, and how developers aren’t really cooks in the next instalment…

Scheduling canned spam

Suppose your friend’s birthday is coming up. You see it in your calendar, and you’d like to congratulate him/her on the day itself, but you know you have a horrible memory. Or perhaps you’ll be travelling and won’t have access to a phone or the internet. So instead you write a nice message in advance and schedule it using something like Mixmax or Boomerang to be sent on the day itself. Joy and appreciation ensues, and you gain brownie points and goodwill in spades.

This is so effective that you decide to do the same thing for every single friend in your address book. In a fit of exuberance you schedule the same email to be sent to every friend on facebook, helped largely thanks to mail merge features.

One day you’re telling a friend about Mixmax and the penny drops. She asks you if the email she got for her birthday was scheduled. Question is, should she be angry?

I’ve been on both the giving and receiving end. I help run a local Toastmasters club and send copious amounts of canned emails to new guests. I also receive my fair share of canned spam, and I really doubt there’s someone writing and sending each of those personalised marketing emails!

Phrased one way, it seems absurd. Does planning for something in advance cheapen its value? More emotively, is the quality or meaningfulness of a message reduced.

I was trying to figure out why the idea of someone sending canned emails annoyed me so much, and I’ve come to the conclusion it’s the relative ease which gets my goat. It takes me ages to write a simple email, so much so that sometimes I just give up and say I’ll make a mental note to catch up next time instead… which I never do. So hearing someone else barely lifting a finger to do it doesn’t sit so well.

But there’s more to it. If Martha sent me a scheduled email on my birthday, I think I’d be pretty uncomfortable, even if I could rationalise why she did it. I’d be doubly pissed if I recognised the contents from other canned emails she’d sent out.

Who it’s from, and how personal the message is makes a big difference. Not to mention how efficient you are at dealing with birthday cards yourself.

But if getting annoyed at something like this really means not being able to stay in touch with as many people, setting up a system doesn’t seem that bad after all. Just maybe not to everyone and a little less canned…

Piano Lessons

Growing up in Singapore with typical asian parents meant that my sister and I were forced coerced encouraged to learn how to play the piano. We had a piano teacher who would come over every week, giving us pieces to practice. I remember this one time where she gave us some bars and told us to compose melodies. Ten minutes before she arrived, I was hastily stringing random notes together on the sheets she gave us. Worst part of it was I had to sit through her trying to play each bar of music, wishing the ground would open and swallow me up there and then.

As much as I hated playing the piano, it’s probably the only reason I can read musical notes or string a melody together. It’s not the most useful skill as a developer, but something I am thankful that I have the opportunity to know. I don’t think I could have ever picked that up if I was handed a piano and told go learn this yourself. I had to be forced to.

Years later, I think the tyranny of choice is still just as relevant. My most productive days are the ones where I have to work through so much stuff that I don’t have time to think about what task to pick next. If it’s not ordered in a nice neat stack and I’m instead given the option to choose which task to do next, half the battle is lost for me.

So I want to be a dictator of my time once more. Not an absolute, iron-fisted maniac yet, but certainly with grand aspirations. I can only decree that these are the things I will do this week for now, but soon, these are the only things I will do today.

It’s not to say I want to cut out spontaneity in my life. There’s always time for spontaneous things I want to do. It’s the things that aren’t spontaneous that need to be forced into submission.

And I know some days I know I am going to wake up, smell the coffee and wonder wtf. Maybe I should go out and meet some friends instead, rather than sticking to this. But it’s precisely those days I need to come down hard on choice. There should be no other option available to pick from, just one.

Which is why the post made it out at all this week 🙂

IT stand up anyone?

So Martha did a humorous speech yesterday based off one of Michael McIntyre’s gigs. It was about how convoluted the process of buying tickets online had become, involving indecipherable captchas, countless fields to fill in and confirmations and legalese to read through if you really wanted to make sure your ass is covered and you haven’t actually signed / checkbox-ed away your firstborn child.

As she was talking about how strange it was that you have to confirm your email (they just want to make sure you really know your email!), all I could think of was the technical reasons behind it. It sucks when your system captures the wrong email address and keeps sending to a dead lead. Which then got me thinking. Why aren’t there any stand up comedians that work solely in professions. I’d think a stand-up comedian in IT would make a crazy killing in say San Fran, kind of like Dilbert but hardcore tech. Heck, even the word stand up means something different in IT than in comedy ~ta-dunk~.

So obviously the first thing you do when you have an idea like that is Google. And there really arent’t that many hits. For one there’s http://geekcomedytour.com/, which doesn’t seem like it’s been updated for about a decade. A whole tour of geeks doing comedy, who would have thought? It turn out that there’s quite some geek specific comedy like nerdist and even something like http://www.wcgeeksversusnerds.com/, where debates about the obscurest of topics in pop culture happen, like DOROTHY vs ALICE – “who is the best at navigating bizarre new lands?”. Random collection at http://www.giantbomb.com/forums/off-topic-31/nerdy-comedians-477293/ too which I have to go through at some point to figure out if they’re actually worth my while 🙂

But the bottom line is, I can’t seem to find any comedy specific to the IT industry. Something that will touch the soul of a tech person like http://devopsreactions.tumblr.com/ does. Anybody who codes or has to maintain systems can identify with that. But why not bring that to life? Why not make it living and breathing?

Apart from the lack of mass appeal, I think a big question is time. More than any other industry, the face of the landscape changes in the blink of an eye. And you can show your age and affect your appeal based solely on the choice of tech stack you choose to make fun of. And desensitisation. I’ve only started working at the new place for 3 months now and I can already tell some people have well and truly drank the koolaid. And when you drink the koolaid and something just ridiculously crazy to an outsider or someone coming in for the first time happens, you just go – yeah, that’s normal, nothing to see here, just move on, even when your hair is on fire, the sprinklers are on and people are running around screaming.

So let’s try and make it happen. I’ll give my next speech from the humorous manual, and make it something about IT. Let’s see how that works out.

Turning the page

To put thoughts into words, and to share those words with you, the reader. Such is writing. Some people have no problem talking about ideas, but hand them a paper and pen and they are lost. There is something about writing that forces you to structure your thoughts, to make up for the lack of context provided by a conversation in person.

I want to become a better writer. To better share what I know, and better understand what I do not. So here I am, practising. Practice makes perfect, so they say, but there is a reason why I’ve been playing badminton off and on for a number of years now but still get my ass handed to me every time. I like playing badminton, but I certainly can’t say I’ve been practising.

I want to become a better writer. To think better. There is a reason why people pay for time to practice. Exchanging cash for focus sounds like a quick fix, a shortcut to mastery. I think there is something to it, but only if you are thinking about what you are doing and constantly reevaluating. Only if you are thinking about what you are writing.

Derek Sivers, founder of CDBaby and all round amazing guy has advice for TED speakers. Speak only about insightful things. Only talk about what brings value for the audience, because it’s not about you. On one hand, once you know something, it is hard to imagine how “not knowing” feels like, so what is valuable to your audience does not seem as valuable to you. The other side of the coin is when I’m the only person on the planet who might find how a specific configuration of parts on software causes a bug interesting.

And there is always the fear. The fear that stops me dead in my tracks. The fear that stops me from pushing the publish button. The fear that makes me pause, look at what I’ve written and say I can’t believe I wrote that and toss it in the graveyard of forgotten dreams.

I will write, and I will think about what I write. I will write regularly, and I will write for you, whoever you may be, whereever you are. There will be no room for fear, no time for hesitation. The audience await, the readers clamour for the souls of manuscripts pushing against the door of existence.

All that is left is to turn the page, to put pen to paper and make them real.

Stuck in Stockholm

The second quarter for 2015 just ended and it’s been pretty chock full for us. After an unsuccessful attempt to get to London we’ve decided to stay in Stockholm for the next few years!

Fresh off the boat

Apart from some certainty about where we’ll be six months from now (we really didn’t know at the beginning of Q2!), it also means we can make some concrete decisions about where we’re staying and working on. There’s no avoiding the winters, but at least it’s sunny outside for now.

Sunny weather outside!

Now that we’ve been in Stockholm for just over 2 years, and likely a few more, we might as well make better use of it. Inspired by Eat your Kimchi, we’re starting a small side blog to write up some of our experiences in Stockholm. Something we’ve affectionately titled Stuck in Stockholm.

Getting to know the people and the places here has not always been a walk in the park, and we’d like to share some of our experiences navigating the foreign landscape that is Stockholm.

This is for you, the new migrant stepping off the boat, ready for danger at any turn. Whether for work, for education, or more commonly as it turns out, for love, you’re ready to roll up your sleeves and do the hard yards to call yourself a resident of the land… at least for a few months.

Check it out, comments are welcome with more posts to come.

We’ve also got our own spot now, so if any of you are passing by Stockholm you’ve got a bed in this part of the world. Here’s a shot of the living room.

Our new living room
Not the most creative bunch as you can tell 😉 Not only does it look uncannily similar to our place in Sydney, it’s even filled with the same things!

Board games
To be fair, they aren’t the same set of games but they will be after our next trip down under.

On the topic of board games, we’ve also put our small boardgame scanning app Gamenauts on the app store, play store, amazon store and more to come. Don’t even get me started on the horrigible release and approval process…or the horrors of how much of a cut they take. >:(

Gamenauts

Much learning here, we’ve actually had the app out on the Google Play store for a while now, but it’s only after Marty spammed a bunch of board game groups on Google+ that we started seeing a spike in numbers.

It’s still a modest number of downloads, and even less in actual revenue. Let’s just say it isn’t enough to cover a decent meal here in Stockholm, but the upward gradient has been steeper than anything we’ve had so far. It’s also hard to describe the feeling you get when you see someone else writing about you, in a different language no less!

I’m going to cut the shameless hawking here and spare you the agony. There’ve been a few more things we’ve been up to though, so stay tuned!

CS0234: The type or namespace name ‘System’ does not exist in the namespace ‘Windows.’ when running Cordova for WP8

All this cryptic error messages really says is…use the 64 bit version of Windows, not the 32 bit as the cordova docs suggest.

As a tip to prevent much pain, suffering and tears, the Windows Phone emulator will NOT run in in a nested virtualisation environment, at least not when I tried it on Virtualbox. e.g. it won’t run on a mac running Virtualbox containing Windows.

Bootcamp or something similar is probably your best bet for running it on a mac. Or a windows phone device, though Parallels users might have better luck.

Simplest event system you can use with React.js

A common scenario when dealing with React is inter-component communication, particularly when the components do not share a parent child relationship.

For example, consider the case of a context-dependent header bar action that affects the main content window.

<Layout>  
    <AppBar />
    <Content />
</Layout>  

Arguably, there are a number of alternative solutions such as providing a callback to the AppBar, and propogate back down to the content (you can invoke component methods directly via a ref), but we’ll focus on the non parent-child case mentioned in the official docs.

It turns out that if you’re using browserify you already have access to an implementation of NodeJS events, so emit away.

// eventService.js
'use strict';

var events = require('events');  
var eventEmitter = new events.EventEmitter();

module.exports = eventEmitter;  
var bus = require('./eventService');

...
// caller
handleAction: function(arg) {  
  bus.emit('addCard', arg);
}

// receiver
componentDidMount: function() {  
  bus.on('addCard', this.addCard);
}