You are not your ideas – a strategy to lessen the blow of rejection

Inspired by @dys_morphia on Twitter, I’ve decided to document my strategy for dealing with rejection of ideas. This particular approach came from a discussion with James Ross and Simon Harris many years ago working with on a consulting project.

James, Simon and I were discussing a bunch of ideas about design and implementation. We were thrashing through them thick and fast and each of us were proposing particular solutions which would be then unceremoniously torn apart by the others. To people outside our little gathering it really looked like we were intent on destruction.  Nothing could be further from the truth, as even though the other 2 are mostly wrong about everything and can’t see the genius of my ideas, as the respect for our work and our worth is paramount in these discussions. Few ideas survived the withering attacks, yet none of us felt harm, hurt or lacking in respect from the participants.

After we’d been doing this for a while, we started to reflect on why this is such an “easy” task for the 3 of us to perform, yet it appears to be very stressful for others. We talked a lot about rejection and about how people feel very close affinity to their ideas and proposals, and that rejection (or criticism) of them is like a personal attack.

James made this very clear explanation about how he thinks about ideas, and why Simon and I probably feel the same way – yet others struggle.

He said(*), “Many people hold their ideas close to themselves, their ideas are hugged, like a teddy to the chest, so any attack on the idea is in very close proximity to themselves and attacks hit not only the idea, but the person behind the idea. The idea is precious, there’s not many of them, and each one is special and nurtured and getting new ideas is a hard thing to do”.

This was compared to what we do, “We feel our ideas are like balls. We generate them, we toss them into the ring for people to observe and comment on. They’re cheap and cheerful and colourful and we know there is a bucket of them we can just keep getting new ones from. Sure, some are special and different in their own way, but the ideas are tossed away from our selves, and criticism of the size and colour of the balls are clearly not directed at the person”

I don’t want people to think that James, Simon and I are reckless, or foolhardy, or don’t care about our ideas. There’s often very heated debate about our thoughts, our dreams, our visions (and our fears) when we engage in these conversations. It’s just that we realise that our ideas have a life of their own, and it’s our job to bring them to life – we’re the parent of those ideas. We’re not part of the ideas.

If you’re an aspiring artist, a software designer, a poet, an author – or even just somebody trying to work out where to go for lunch, then consider setting your ideas free – toss them away and give them life of their own. You’ve already done the important work in the communication. You can’t be held responsible for how others react to your ideas, any more than you can be held responsible for other people liking your choice in bikes (even though there is a clear right answer here) and more importantly, by giving life and freedom to the ideas, you’re making it clear of a very important fact, you are not your ideas.

(*) I can’t remember exactly what was said, so I’m going to make up the story to convey the intent.


You say you want a revolution..

“Well, you know. We all want to change the world”

My title on LinkedIn is “Reluctant Architect”. This should not be considered a reflection about how I feel about my job, the company I work at, or the work that I do. It’s more of a reflection about what the rest of the industry thinks of an Architect in the software sense.

Basically, the term has been completely hijacked and the use is completely wrong. For the most part architect in the computing industry is some old white guy who’s completely forgotten anything about software development (if they ever did any) and spends all day writing PowerPoint presentations on choosing WebSphere vs Weblogic. This is then inflicted on the organisation like stone tablets being handed down from the mountain.

I can’t find enough words to describe how much I disagree with the concept, the implementation and the horrors that are perpetrated by organisations that follow this model. It is the ultimate in disempowerment, it actively discourages teams from learning and puts power in the hands of people least capable of using it effectively.

So, while I’ve given a roasting to the way my industry has traditionally handled architecture, how, and what do I do differently?

My background is software development, and I’ve spent a lot of years working with, and mentoring teams, but without a doubt the biggest influence on my recent career has been becoming a parent. I have the most wonderful 8 year old boy, who has the same level of enthusiasm for life as his father along with the youthful confidence that everything he knows is right. At this point, you have to transition from “telling” to “experiencing”. No amount of me telling George that “eating that many lollies will make you feel sick” would convince him. So, short of doing things that would actually (or likely) kill him, I encourage him to safely explore his boundaries. Quite often there is joy in the discovery, and quite often there is cuddles and comforting words after a “learning experience”.

So, being an architect, and a reluctant one at that.

(From 1550s, from Middle French architecte, from Latin architectus, from Greek arkhitekton “master builder, director of works,” from arkhi- “chief” (see archon) + tekton “builder, carpenter”. An Old English word for it was heahcræftiga “high-crafter.”

This pretty much sums up what I feel about the role in general. I am an old white guy with many scars from building systems the wrong way, or seeing other teams build things the wrong way and I wasn’t quick enough to help them. I try very hard to build relationships with the technical staff across the organisation so I can influence their approaches and thinking without needing to actually tell them “do it this way”. This sounds all a bit unicorn and rainbows and holding hands summer-time walks on the beach, but I’d say there’s very few people at REA that have any doubt about my position on various topics, and what my likely response is if they test those boundaries.

Specifically, what does this look like in practice? Glad you asked! I’ll outline the process that I go through (and have done) at REA focussing on architectural change.

The history

When I joined REA nearly 4 years ago, there was a small number of large applications, there was strong coupling and releases were painful. We were tied strongly to data centres with applications running on racked tin. Applications made many assumptions about how close they were to each other (latency for example). Control of applications were “tier” based (back-end vs front-end) and there was contention across the organisation for product releases.

The strategy

Working with Rich, the main goal was to structure the organisation to allow faster releases and improve the quality of the systems (reduce coupling) to make this possible. There was a heavy investment into cloud computing (using Amazon) as the means to reduce contention in the development and testing area, with still having a pathway to multiple production deployment environments controlled by the business aligned organisational structures (we call them “Lines of Business”)

The vision

A dashboard for each Line of Business that shows all cloud providers in the world, their latencies and suitability for applications, including cost. The teams are able to deploy services across the globe, according to data transfer requirements, latency rules and follow the “cheapest” computing and storage options.


Yeah, something like that, but less Neo and more graphs.

The direction

We need to have our monolithic coupled applications split so that each Line of Business can deploy them independently. Our operational staff need to have visibility into the health of the applications without actually knowing where they are. The systems need to support increased speed of delivery of new function for each of the Lines of Business.

The final attribute is considered one of the driving reasons for these changes – so I’m going to focus on it in future sections. However, at this point most of the work that I do is making sure the technical leaders for the various Lines of Business understand the vision and the direction without interfering too much in the actual implementation.

There’s also a lot more to the ongoing strategy involved, but that’s probably another topic for another time.

The design

I strongly value autonomy and self-discovery by the teams. I think learning by doing is the most powerful approach and Open Source ecosystems have shown that the mutations from different development approaches (generally) improve the state of the art as the development teams learn from previous implementations.

In terms of the design of “the architectural direction and improvements” I’ll explain how I’m influencing the understanding and behaviour around application deployment, modularity and most importantly monitoring and fault tolerance.

I realise that “make application deployment, modularity etc, etc better” isn’t a desirable directive, because it’s not very useful and because in many cases people don’t have a clear idea what “better” is. For developers especially many of these concepts are quite foreign, so what I aim for is smaller fine grained directives that help to provide some gentle prodding for exploration in the right areas.

By doing this, what I’m trying to get teams to “work through” is the potential difficulties involved in implementing some of the architectural improvements in their specific contexts. If I actually knew the answers I’d probably work with the teams directly, but I rarely know “exactly how” teams should implement things. I’m blessed by being surrounded by an awesome group of developers and technical specialists that are very capable of implementing improvements in their own contexts, my role is to show them the path to take.

The implementation

Taking the example of “improve modularity and decoupling”. What is needed under these circumstances is independent services. However, a key part of the total system improvements, especially when relating to multiple independent systems is monitoring and fault tolerance (and investigation). REA Group use AWS for many of our system deployments, so some of this is ‘more important’ than dealing with racked tin, but the same principles should apply.

So, now we think a bit. What can I do at this point, and what principles can I impose on the teams to move in the right direction. One of the most expensive parts of software is the operation of running systems. Most of this is because the monitoring, logging and debugging tools are “left as afterthoughts”. I could say “make sure all systems have monitoring, logging and debugging according to the checklist defined in subsection 42, document 27b-6”. That sort of directive could sound familiar to many people, and is pretty much everything I despise about “enterprise architects”.

My directive was “remove ssh access to all deployed systems, nobody can log in”.

To say the response was incendiary was possibly an understatement. Nomex underwear is standard issue for my job, but it’s very interesting to see how often it’s needed. The other thing that interested me was “what roles gave what responses”.

For the most part, experience ops people (hi Cos, love your work) saw through my facade and knew what was up. They’re also generally used to working in constrained environments, and as a result have a huge toolbox to still effectively do their work. The other good news is that these wonderful people also become great advocates for improvement, because most of the burden of running systems fall in their laps.

Developers are predictably “y u no luv me” because what their main focus is to develop and deploy rapidly, debug issues locally and repeat. There’s probably a good reason for excluding some of these principles during development, but as I will repeat, unless the developers feel the pain themselves, it’s unlikely that changes are going to be made. All that does mean is that the operation team gets sad.

Why did I choose that particular course of action?

Well, it’s pretty controversial, so there’s lots of talk (and complaining) so people communicate with each other about how terribly unreasonable that I am, and how I don’t understand “the reality’ of software development. It’s visible and easy to do (don’t start sshd, easy) and should it turn out to be a retrograde step, it’s easy to change back.

The other benefits we see from this is that our systems start to become immutable – a property that I find particularly valuable in coding, and it transfers nicely to system components as well. This is a great thing in AWS land because we can just shoot the cattle and launch another one, and I know that nobody has been on the box “fixing” it.

By not being able to log into the box, we have to think hard about how we log and monitor our system components, especially important things like tracing transactions through the system. What sort of identifiers? What do our components do under failure conditions, network connections etc

The aftermath

There’s a school of thought that I should carefully explain my reasoning behind my decisions so it’s clear to everybody, and there is limited “heat and light”. There may be some merit to that, but my role is not a dictator, it’s an educator and a communication enabler. I don’t mind if the teams are all plotting to subvert me, or even getting together to bitch about how unreasonable I am, but the point is, they’re talking about it – with each other. That’s a big win. I love watching our internal IRC when somebody proposes “how about I use a bastion box to get to the instances” and there tends to be a few comments like “don’t say that, you’ll make Jon angry”, or “shhhh, don’t say it out loud”. That’s fine. It means that people are paying attention, and that even tongue in cheek comments like that make me feel like a difference is being made.

The second part is that I’m not always sure that I’m right. Sometimes I just go with “this seems like a good idea”. Like parenting with George, provided nobody is going to die (or projects fail spectacularly) then making these sorts of decisions and directions will gain valuable insight into our projects and systems, even if we start to go in the wrong direction.

The astute readers here (well, let’s face it, if you’re reading my blog, you’re probably already astute) will notice that I’ve only described a very thin slice for the implementation. Yes, that’s true. This is a big thing, it’s a long term view and to be honest, it’s sometimes disheartening to have to wait. It’s worth the wait, just need to hold firm and be confident that what you’re doing is the right thing. So don’t be confused that the descriptions above cover all that is needed, even from a pure “this is the direction” point. There’s probably 20-30 separate parts of the implementation that is being influenced at any point in time.

I’m looking for long term change with the work I do. Not short term fixes. I want teams to participate in this journey and not just be told what it looks like. There’s also significant parts of cultural change that form part of what I’m aiming for. People do get stuck “thinking the same way” and it’s my role to try and encourage them to think in a way that systems will be constructed in superior ways.

I hope this turned out to be of value to some people, I’m happy to discuss it further in public, or private emails. I’m very happy to help organisations understand how architecture can be better integrated with the development and operation of systems.

Micro services, what even are they?

This blog post was inspired by Jonathan Ferguson (@jonoabroad on Twitter) where the exchange started.

All the Twitters

@jonoabroad “Does anyone have an agreed term of what micro services is?”
@joneaves “Does it need one?”
@jonoabroad “yes. How is it any different to SOA?”

At this point, 140 characters was just going to make things harder so I suggested I’d respond with a blog post. So here it is.

Firstly, I’m going to start by saying I’ve probably got no right to be leading the charge for a definition for micro services, but I do have a lot of skin in this game, as it’s the direction that I’ve been pushing REA development for the past 2-3 years.  Much of this is my personal perspective, but I do think it’s broadly applicable and does provide what I consider an alternate viewpoint on the vision for micro services that exist. 

To answer Jonathan’s second question “How is it any different to SOA?”, my immediate response is “the intent is different”. With SOA, the intent is a layered architecture of co-operating services where SOA focuses on describing the organisation and co-ordination of the services. With micro services, the intent is to describe the nature of the services themselves and not quite so much the organisation and co-ordination of them.

While SOA is used as a comparison, SOA itself has no “one true definition” but merely a collection of patterns/principles and attributes regarding the organisation and co-ordination between services. I should point out that I see micro services and SOA working well together, with micro services describing attributes of the services themselves and SOA providing useful guidance on how to arrange them.

So, why do I think this way?

I’m a software developer, designer and architect. I like to think a lot about the human factors of software development and how can I put systems in place to encourage development teams to “do the right thing” when building software. There’s far too much shit software out there, and I like to have teams not contribute to that. With that in mind, why did I think micro services was a “good approach”? My definition is meant to be used to guide _development_. The benefits that we get operationally is wonderful – but that’s not the primary reason. It’s to get developers to stop building Borgified software with unclear responsibilities and brittle coupling.

First it’s probably worth providing my definition of what a micro service is, so that there’s at least some context around the discussions that may, or may not ensue. After defining the attributes, I’ll expand on why I consider them important.

Desirable attributes of a micro service is;

  1. The responsibility is narrow. The service does one thing, and one thing well.
  2. The code base is small. The service can be rewritten and redeployed in 2 weeks
  3. There is no 3.

I tried to think of more, but most of them were derived from these. A valuable attribute is the ease of upgrade and redeployment. This is directly related to #1. Another valuable attribute is the ease of change. Both #1 and #2 provide support here. There is also the ability for services to be re-used effectively. This is related to #1.  A person much smarter than I am once said “The unit of reuse is the unit of release”.

There’s possibly some rambly hipster crap about “REST services” and “HATEOAS” but really, that’s such flavour of the month and not really something that I think is that important. Certainly no more interesting than JSON vs XML vs ASN.1. All of these things can be done well, or badly – but don’t provide a defining point on if an implementation has desirable attributes.

The responsibility is narrow

This key point relates to design and the fundamental architectural principles. If the responsibility is narrow, then hopefully it follows that the codebase will be small. If the responsibility is narrow, then the understanding of where to make changes is clearer and design intent can be carried forward. If the responsibility is narrow, then understanding how the service fits in the broader network of services, or how the service can be reused is much clearer.

The second important part here is the ability to release the services often, cheaply and without needing to have a deep graph of dependencies. Having a narrow responsibility means that any systems that want to use the services are only coupled to that service for that responsibility. There’s no undesirable coupling. 

Like object oriented software, services are best with high cohesion and low coupling. Creating services as micro services helps in this regard.

The code base is small

When I first started proposing micro services I wanted to appeal to the developers, so I said that services could be written in any language they choose, The only caveats were that the component had to conform to our monitoring and logging interfaces (to aid with deployment and operations) and that it could be re-written in 2 weeks.

This created significant consternation, not by developers, but by management. They were concerned about the “explosion of software that nobody could understand”. I did laugh while explaining my reasoning. I laughed mostly because their basis of concern was that “it would take too long”. Sadly this shows the lack of understanding about software that pervades our industry.

Most developers are perfectly capable of understanding new syntax, and generally can understand new syntax in a relatively short period of time. What takes much, much longer is understanding twisted and tortured domain logic, scattered across 6 packages and libraries all bundled together in one monolithic application. 

My rationale is that if software is written according to the simple rules (narrow responsibility and small codebase) then the actual language choice is for the most part irrelevant in terms of defect fixing and extension. Sadly, I don’t have a lot of data points in this regard, as developers seem to want to choose the path of least resistance (which is normally keep writing the same old shit in the same way), but I do have a great example written by my team. 

We had the need to write a service and one of the team wrote it in Go. It was working well, performed as expected and when it came to adding some additional monitoring we hit a snag because the Go runtime wasn’t supported by NewRelic. The developer who wrote it had sadly departed the team (I still miss you Eric!) so another team member re-wrote the service and had it redeployed in 2 weeks. Written in Java, using Dropwizard. It was a perfect example of exactly what I was proposing.

There are some really useful patterns that we developed while creating the service, not really suitable for addition here, but if there is enough interest I can expand on it in another post. However, the way we thought about building the initial service and more importantly the automated testing around that service made re-development trivial, and incredibly safe.


Toy Robot Coding Puzzle

It may come as a bit of a surprise to many developers in Melbourne (and possibly other places) that I’m the author of the much loved and used “Toy Robot Test”. What may surprise people more is that it’s been around since 2007 and was written when I needed to evaluate a large number of hires for people at ANZ.

It shouldn’t be a huge surprise that it’s not entirely original – lets face it, nothing is. It was heavily influenced by the “Mars Rover” code puzzle that was in use at ThoughtWorks when I was there. I was also involved in hiring people at TW during this period and while I didn’t do this as part of my evaluation, I probably wrote and re-wrote code for this puzzle about 20-30 times as I explored different solutions so I could talk to candidates about it.

When it came to needing one for ANZ, it was all very familiar.

The other part of this that is also very familiar is the one question I keep being asked, which is “Shouldn’t we change it, it’s common and people could ‘cheat’ and copy the solution?”. To this I normally sigh, then start with telling a story all over again. This has happened again recently as one of our wonderful HR recruiting staff asked the same question, so I wrote her an email in response. I was chatting with a good buddy (hey there Travo) who asked me about the code puzzle in a similar way, I showed him the email.

He then suggested that I post my response in a blog. It seems like a good idea, but it’s probably worth understanding how the code puzzle works in my recruitment pipeline. It’s the first filter, which is quite unusual for many people (something else I often get asked about).

Why? Well, the sorts of filters for somebody you want to hire as a software developer are;

  1. Are they a competent software developer?
  2. Are they an asshole?
  3. Can they cope with working with/near me?

In my life experience, people are generally not assholes. So as a result, doing some form of “phone screen” or “cultural interview” first is pointless – because it’s really, really likely they’re a nice person who you’d enjoy hanging out and having a beer/wine/halal drink of choice with. However, if I’m going to hire them as somebody who will write code that’s pretty important. So, I figure – maybe I should ask that. And, in my experience, most people are *fucking terrible* at writing code (no really, you all are, deal with it).

So, I use the filter that’s going to let the smallest number of potentially non-asshole people through. Then I can chat with them about technical stuff and I can do things like work out exactly how much they do know about technology, if they’re smart and use emacs, and other important things like keybindings and directory structure preferences. Also, doing this gives them a reasonable idea about what it might be like to work with me. So, that kinda sorts out 2 and 3.

Apart from letting some Scala people through this process when even I was too naive to think people would use that borg of a system, it’s worked pretty well. So yeah, the point of this blog post – why I don’t care that the Toy Robot Coding puzzle is well known.

Hi Jon,

Can we write a new Robot puzzle please?



Hiya (redacted),

I suppose I’m trying to get you to articulate why you think you want to do these things.

You’re telling me things about what is happening (which I already knew about), but there’s another part to this that I want to discuss with you, but I want to understand what you want.

 I suspect that you’re worried that people are going to “cheat” the code review and that’s why you want it changed. I’ve had this discussion with everybody since I started doing this – so it’s by no means a new conversation.

Now, this is the very funny part. The general quality of responses from candidates is so poor that they’re too ineffective to even copy a good version of it. Think about that for a minute. Most of the candidates are incapable of copying a working solution to try and “trick” me. What does that say about most programmers? It’s a pretty sad indictment of our industry that they can’t Google a good solution, modify slightly and understand what was written enough to trick me through an interview. It’s embarrassing.

There is also the problem (regardless of what we do) where somebody else can write the code for the candidate.

Now, this is where we have a conversation with the candidate and ask them about the code. Turns out if they didn’t write it – they don’t know how it works, or how to extend it, or how to talk about the potential design issues with it.

Our potential outcomes are as follows;

  1. Candidate is able to complete code puzzle honestly and “passes”
  2. Candidate is able to complete code puzzle honestly and “fails”
  3. Candidate copies from github and passes
  4. Candidate copies from github and fails
  5. Candidate has submission written by 3rd party and passes
  6. Candidate has submission written by 3rd party and fails

Now, our recruitment process will treat 1,3,5 as identical and 2,4,6 as identical during the code review phase. Of course, obvious copying of the wrong names etc may make for great amusement but is otherwise undetectable.

2,4,6 we don’t care about – because they failed anyway

Of 1,3,5 we really need to try and identify 1 separately from 3 and 5, as 1 is the candidate we are at most interested in progressing with.

 If we examine the characteristics of 3 and 5, we notice that they are the same. It’s really just “code not written by the candidate”. So, if we choose a different puzzle we are under the incorrect assumption that it will somehow make it “harder” for the candidate to cheat – but option 5 is still untouched.

So, that’s why we talk to the candidate about the code. In depth, and often with reference to the design decisions they have made (or not made) and ask them about how they would extend it.  This allows us to detect both 3 and 5.

Having said all of this, I hope you can understand more about why “changing the code puzzle” really doesn’t matter at all. We can change it for other reasons (such as a different problem for the fun of it) but having an “original” problem doesn’t mean anything in terms of improving our hiring decision strategy.

Going paperless

I decided to go paperless at home, and have purchased a scanner and going to digitise all the random pieces of paper I get during the year.

I’m wading through all my tax from last year and realise that it would be a lot easier if I didn’t have to shuffle the papers around, and store them.

If you’ve done this – what are some good pieces of advice you can give? I don’t plan to scan receipts, maybe bills. What should or shouldn’t I bother with?

Providing a framework for communication

A lot of my work at present is helping the technical leaders of our business aligned groups do their work effectively. There’s lots of communication individually, and as a team.

Having all the smart people (and me) in a room greatly aids decision making, but one of the most valuable communication aids that I’ve implemented is describing responsibility and accountability in terms of bounded contexts.

Eric Evans uses this term in Domain Driven Design to separate out modelling concepts and to try and stop the “grand unified theory of Customer object definition”. What I’m using the bounded contexts for is to describe the areas of accountability for the tech leads and say “whatever happens inside that boundary is your problem, but you have to communicate to other contexts using my rules”.

So far, this has been working very well. It really helps in guiding the communication to “what bounded context should this functionality logically be located” and hence the ownership.  Then, the tech lead working in that area is completely free to implement the functionality according to their methods, exposing the interaction via an interface that is “proscribed” (but generally we thrash about as a team defining what this will look like).

As I was trying to describe this process internally to managers at REA, I found that this article ( provided a nice starting point.


Chicken and Vegetable Green Curry

I love this dish, because it’s nice easy to cook, super cheap to make and freezes really well. You can also substitute like crazy on any of the items. Cooking to me is all about the exploration. Swap the chicken with fish (so good, so, so good), use red curry or massaman curry, drop the meat completely and just have vegetables. Drop the vegetables and add bacon (only kidding, never tried that).

Don’t be daunted by the number of items in the list – it’s mostly just random different vegetables that I like to add in, and the volume of curry it makes is pretty large, I normally get 6-8 decent sized serves out of it of which I freeze in 500ml storage containers.  If you want to reduce the volume, reduce the meat to 250g and only use 1 can of coconut liquid as well as reducing random vegetables in both volume and number. This is more art than science, it will work out fine – trust me.

When I talk about adding oil to things, I mean a small amount, like 1 tsp – not a cup. You’re not deep frying things, it’s just to help the meat and vegetables brown without sticking. For the frying parts, you can exclude the oil completely if you like.


  • 10 minutes for prep / chopping
  • 30 minutes for cooking (depending on how you chop the vegies)


  • The ingredients listed serves about 6-8 depending on how much you serve.  I use a 250ml cup and just scoop the curry out onto the rice, and each serving for me is about 1 to 1.5 scoops.

Kitchen Cookware

  • Medium or large frypan
  • Large frypan or wok (I use a wok)
  • Microwave and microwave proof dishes (not required, but makes prep and cooking time much faster)
  • Nice sharp knife
  • Wooden spoon/spatula


  • 1/2 jar of Valcom Green Curry Paste (could use any brand, but this is what I like)
  • 400ml (one big can) of Coconut Cream (replace with Coconut milk if you want a thinner sauce)
  • 400ml (one big can) of Coconut Milk (replace with Cream if you want a creamier/thicker curry sauce)
  • 1 tsp of Fish Sauce
  • 1 tsp of sugar
  • 1 kaffir lime leaf
  • 1 small hot chilli (optional – but I like it)
  • 500g of chicken (I prefer thighs, but breasts work ok)
  • 2 medium potatoes
  • 1 medium sweet potato
  • 1 small green capsicum (or half a larger one)
  • 1 small red capsicum
  • 2 small brown onions
  • 2 carrots
  • big handful of green beans
  • vegetable oil of some form – I’ve used Peanut and Olive – both work fine
  • rice for serving on (I use long grained rice of a random sort that was on special at the supermarket)


  1. Pour some oil in the wok and heat on high, add 1/2 jar of Green Curry Paste – cook until slightly spitty and fragrant, reduce heat to low (this is really important, or bad things happen to the about to be added coconut milk)
  2. Cook for a little longer (~1 min) until the paste stops popping and mix in the Coconut Cream (if you use milk here, be super careful, I’ve had the milk separate and go all curdly at this point – much safer to use the Cream)
  3. Mix with a wooden spoon and keep a careful watch – if it starts boiling hard, then remove from heat (add back to heat when you start adding in the vegetables)
  4. Chop the (optional) chilli and the kaffir lime leaf into tiny weeny little pieces – add to the wok – mix in
  5. Peel the sweet potato  – chop into 1cm cubes (or whatever you feel like – it doesn’t matter to be honest)
  6. Cook the sweet potato in the microwave for about 2 mins with a bit of water – this should just soften it. You’ll have to adjust for your microwave and the size of the potato, but the objective is to “half cook it” not turn it to mush.
  7. Add oil to the 2nd frypan, and lightly fry the sweet potato – just make the outside bits all nice and brown – should take about 1-2 minutes
  8. Add the fried sweet potato to the wok, mix in (wok should be on low heat – sauce should not be boiling rapidly – as you add the vegetables it will cool the sauce, just keep an eye on it)
  9. Repeat steps 6-9 for the potato (peeling optional)
  10. Repeat steps 6-9 for the carrots (if you peel them, I’m coming to your house to slap you)
  11. Roughly chop the onions and add to the wok
  12. Roughly chop the capsicum (both red and green) and add to the wok
  13. ## Rice ## (see the end)
  14. Chop the beans into 1/2 or 1/3 and add to the wok
  15. At this point you are probably over the top of the curry sauce, don’t stress we’ll fix that in a minute, just keep stirring it
  16. Chop up the chicken – you can make strips if you want, I like to make cubes and fry until it’s browned on the outside – more colour is good in my opinion – but don’t overcook it – you want the inside of it still pink/raw
  17. Add the browned chicken to the wok
  18. Add in the 2nd can of Coconut liquid – stir in thoroughly
  19. Add in 1 tsp of Fish sauce – mix well
  20. Add in 1 tsp of sugar – mix well
  21. Taste the sauce – it should be mildly fragrant with a little bit of heat.
  22. Keep stirring, turning and making sure it’s not sticking to the bottom of the pan – adjust heat
  23. Cook slowly until the potato is cooked through. That’s my trigger for it “being ready”. It normally takes about 30 mins, but that’s my microwave, my timing and my chopping sizes. Don’t be stressed if it takes another 10-15 minutes – grab a glass of wine, watch a bit of TV, set the table, panic because the guests are about to arrive and you forgot to sweep the floor.
  24. Serve to your guests – bask in the glory of their compliments

Rice – I use a rice cooker which helps because it’s zero effort and I don’t have to watch it. Depending on how you cook your rice, I would normally put it on at about the time I start chopping the beans.  If you have a kitchen minion, you can direct them to do it at that point, or cook the rice at the end. Cooking the curry for longer on low heat IS GOOD so don’t worry about that, the only thing to watch is that it’s on a low heat and isn’t sticking on the bottom of the pan/wok.  

When I made this last night I put the rice on at the very end, sat and ate cheese, dip and crackers drinking wine with my guest. It was probably 60 minutes after the curry had “finished” before I served up and it was delicious.