How to Avoid Making Huge Mistakes with Life’s Big Decisions

The Mistake

A condemned three-story house in DetroitWhen my wife and I had been married for a year, we made a decision to purchase an apartment. It remains, to date, the worst decision we’ve ever made.

To start off with, we probably shouldn’t have purchased anything at all. But there was pressure from parents, the peer pressure of our friends doing the same thing, and the constant fear in Sydney-siders of “getting left behind the market”. Looking back now, I see the bigger factors that we’d been married for one year, we were both very early in our careers, we had very little savings relative to our incomes, and we were living in a friend’s place for low rent. There weren’t really any good reasons to buy.

The big mistake, though, was the place we bought. We spent a couple of months looking in the seaside suburb of Cronulla before realising there were apartments we liked and apartments we could afford, but nothing that fell into both categories. We begrudgingly started looking two suburbs back from the beach and went into a real estate agent there. He said he had the perfect thing for us, one more suburb to the west. We went and had a look and, well, it was fantastic. It was large, bright, only ten years old, had a view of the city over a soccer field, a supermarket at the end of the street, and we could afford it… just. When we left the apartment, the agent asked us straight up, “So, do you want to buy it?” We looked at each other stunned, not knowing what to say, and he knew the answer was “Yes”.

The Consequencs of the Mistake

Young woman with fingers in ears and eyes closedSo we bought this place, and we immediately – as in, the first night – started learning everything wrong with it. Ten year old apartment buildings have far thinner walls than the 40 year old place we’d been living in. When our neighbours called someone on the phone, we heard every word they said. When they yelled their heads off at each other, we got to listen to that, too.

Having a supermarket at the end of the street made getting groceries handy, but it was also easy to get a trolley, because there was an endless supply of them dumped in the entranceway of the apartment block. Speaking of dumped, it turns out that when people live in a block of 40 apartments they feel pretty anonymous and do things like throw their garbage bags on the ground in the driveway rather than go the extra step of opening the cage where the bin is and putting the garbage in there.

The playing fields were a nice outlook on weeknights, but every Saturday morning at 7am we’d be woken by the screeching voice of a netball organiser announcing “This week’s special of coffee and a doughnut for $2”. The “special” was the same every week. Friday, Saturday and Sunday nights were fun, as we discovered the fields served as a thoroughfare for people leaving the local pubs and walking back to their homes. It was a regular occurrence to be woken up by a woman screaming at 2am and rushing to the window to see if someone was being attacked, only to find four inebriated women stumbling across the field together and screaming with laughter as each one in turn fell over in the mud.

Finally, a ten minute drive to the beach makes it seem a long way away. When we lived within walking distance of the ocean, we’d go for a swim on every fair night after work for about 5 months of the year. In the summer after we moved, we went to the beach twice.

In short, we’d bought a really nice apartment in what was not a nice area. Everyone says, “Location, location, location,” and we learnt it the hard way. There’s lots of stuff to look back on and laugh about now, but at the time it was a pretty terrible place to live. When we eventually sold it years later, it was for a few thousand dollars less than we bought it. Fears of missing out on the market seemed a bit exaggerated.

Okay. That sucked. How did that happen?

Reflecting on what went wrong over the following years, I’ve realised we made mistakes at three different levels.

Level 1: Property Mistakes

At the first level, we made property-buying mistakes. We made three big resolutions to try and protect us in the future:

Property Resolution #1: We would never purchase a property with shared walls again. If we shared a wall with someone, we wanted the freedom to leave at short notice.

Property Resolution #2: We would never purchase a property without first living in the immediate area. There’s too much you don’t know until you’ve been a local.

Property Resolution #3: We will tell our kids not to bother buying an apartment. Real estate transaction costs are astronomical, so if you’re planning to have a family, and to one day own a house, it might be better to just save for that house.

Level 2: Decision Mistakes

Those learnings were all about buying property, though, something I’m not planning to do too often. At a higher level, we’d made two mistakes in the way we’d gone about making our decision:

Decision Mistake #1: We hadn’t considered all our options. Once we started to look away from the beach, we saw one apartment, we liked the look of it, and we got railroaded into buying it by a really good salesman. We didn’t look at any other apartments in that suburb. We didn’t ever see any apartments in the suburb we’d planned to look in. Worst of all, we ended up spending more than we’d originally been thinking and it didn’t occur to us to go back to Cronulla to see what this new limit would afford us in the place we really wanted to live.

Decision Mistake #2: We weren’t clear on what features were really important to us. After seeing dozens of run-down places in Cronulla, we were blown away by the modern interior of the place we eventually bought. We realised too late that we’d traded that nice interior for things that we valued a lot more: a nice street, quiet surroundings and being near the beach.

Level 3: The Big Mistake

Thinking one more level up, we realised we had a problem at the life level: We had no process for ensuring the big decisions we made were good decisions.


 A Second Chance

"Your past mistakes are meant to guide you, not define you."Five years after leaving our first disastrous real estate purchase behind us, we got a chance to have another try at finding a good home to buy. We heeded the learnings of our previous failure right from the start: we moved into the area where we wanted to buy six months before we started looking, and we ruled out all apartments, semis and townhouses without a moment’s thought.

We went one step further, though: rather than just avoiding our key property pitfalls, we came up with a system for making the decision that was intended to avoid the two core decision making problems we’d identified from before: not considering all the options, and not being clear on what features were really important to us.

How we bought our house

What we did was fairly simple but, in the end, extremely powerful. Here’s the process:

Step One: We wrote down everything that we thought we would like as a feature in a house and property. We’d both lived in at least 5 places by now, and inspected scores more, so it was a pretty long list. We also wrote down things that we definitely didn’t want, but we wrote these as positive items – things we wanted – e.g. “Not next to a power substation.”

Step Two: We sorted the list of features, so that we had a list of most important features to least important. I actually wrote a small computer program that helped us do this by presenting features two at a time and making us choose which was more important. We asked ourselves: “If there were two identical houses except that one had this feature and the other house had the other feature, which would we choose?” We entered this into the program, and it sorted the list based on our answers.

Step Three: For every house we visited, we scored the property for each feature out of 5 stars (no half stars allowed!). We kept the whole thing together in one spreadsheet. This gave us a commanding overview of the decision we were making.

This process seems pretty simple, and it is. Lots of people trying to make a decision go through a similar process, though a lot of people miss the most important step: sorting the features. Without sorting the features, you have what is typically referred to as “a list of pros and cons”.

Pros and Cons lists are terrible because they assume that every feature is equally as important as the others, which is very rarely the case. We quite often saw houses which rated very highly on lots of the features we’d listed, but it scored poorly on a couple of the most important ones at the top of the list. We would come out of an open house feeling quite positive about the place, but when we got home and put it in our spreadsheet we’d realise it was a dud.

The Big Decisions Method

While we were going through all this, it dawned on me that what we’d designed in our little spreadsheet was a universally useful tool. Not only was it a useful method for anyone purchasing property, it was useful for any decision of this nature, where there were multiple options and lots of features to consider. Our simple process:

  1. List your features
  2. Sort your features
  3. Score your options

was a winner. When our car gave up the ghost we used our method to decide what to buy next. We ended up with something that wasn’t the choice I thought we’d make at the start, but which is far more suited to our needs and values. I used the method the last time I changed jobs, and I’m still in the same job, almost nine years later.

The Big Decisions App

When I’d been working at Tyro for five years, they gave me an iPad as an anniversary gift. Being the dyed-in-the-wool software engineer that I am, the first thing I thought was, “I’ve got to learn how to write apps for this thing!” Before you can make an app, though, you need a good idea for an app, and somehow it dawned on me that this decision method we’d conceived would make a great app.

I looked at other decision helper apps on the App Store, thinking, “Someone must have done this already.” Indeed, there were lots of decision-making apps, but they fell at two ends of the complexity scale. On the one end, there was a swathe of free and 99c apps that did nothing more than toss a virtual coin. On the other end, there were a couple of apps that were trying to do something similar to what we’d designed, but had users typing in decimal numbers for weights and scores, really offering little more than a spreadsheet template.

Screenshot of the 'Big Decisions' app for iPadSo I embarked on turning our method into an app: Big Decisions. It turns out that it takes a very long time to make a good app, and if you’ve only got an hour or two spare each night, that becomes a very, very long time. I remember working for months before presenting the first completed (I thought) version to my wife and observing her try to use it. “Oh, dear,” I thought as I watched her fumble around and look at me quizzically, “I’ve got a lot more work to do.”

It took almost a year until I finally had something that was good enough to put on the App Store. There were plenty more things I wanted to add, but it was time to get some feedback. Would it be a success? Would we become stinking rich overnight? Would it change people’s lives? Would a single person even download it?

Well, we’re not stinking rich yet, but I’m happy to report that people find the app, people buy the app, and it seems people love the app. There’s even reports of it helping people change their lives. One reviewer wrote on the App Store:

“This app is a pleasant surprise! I wasn’t expecting much, but I am very pleased to share that it actually helped me with a few major life decisions.”

Another one, who appears to have an academic background in decision-making research, wrote:

“Big Decisions is one of the best decision aid apps I’ve seen, and I’ve explored most (if not all). It’s useful, attractive, smart, and sleek.”

 

The Results

So, the app is a moderate success. What about our house? You might think that the end of this story will be that we found a fantastic property with everything we wanted at a ridiculously low price and snapped it up… but it’s not.

We bought a house that is fifty years old, and looks it. It had an extension in the 80s that has left it with a weird layout; you either have to walk through the laundry or a bedroom to get to the back living area. There’s no less than eight different floor coverings: two styles of carpet, polished floorboards, and five different styles of lino. The garden is so high-maintenance that we could probably keep a full-time gardener busy. The train, my preferred mode of transport, is 25 minutes walk away. The kitchen looks about 20 years old and didn’t even have a space for a dishwasher.

Why did we buy such a bizarre house? Because it’s in a fantastic street, a peaceful cul-de-sac full of young families and away from main roads. It’s brick. It’s within walking distance to schools, walking distance to playgrounds, and there’s an express bus to the city two blocks away. And it has my wife’s favourite feature: you can watch the kids in the backyard from the kitchen while preparing dinner or washing the dishes (or packing the dishes in the dishwasher we installed).

We didn’t get everything we wanted in a house – far from it – but we got the things that were most important to us, the things that we’d identified at the start of our search. And the proof is always in the pudding: we’ve loved every minute of living here.


Big Decisions is available on the App Store.

Image credits:
detroithouse.jpg‘ by Groovnick (flickr)

Lalalala.. I don’t wanna hear this!‘ by Hilde Skjølberg
Your past mistakes are meant to guide you, not define you.‘ by Live Life Happy (flickr)

Notes from YOW! 2014: Troy Hunt on Security: ‘Hack Yourself First’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Troy Hunt (@troyhunt) spoke about “developers building up cyber-offence skills and proactively seeking out security vulnerabilities in their own websites before an attacker does”. (Slides, Video)

Hackers Are Security Experts

A stereotypical security hacker, using a computer in a dark room while wearing a guy flakes mask and a black hat.He started out with the obvious but perhaps too often forgotten observation: “You can’t defend your app unless you actually understand how the hacker’s technology works.”

He described how hackers only need to “get it right” once. Those developing and deploying the system need to get it right every time. (This is sometimes called the “Fortification Principle”. Apparently DARPA are working on evening out the playing field.)

Know Where Security Applies

He asked: If your company has a Twitter account, who chose the password? The marketing intern, or the Security team? Continue reading

Notes from YOW! 2014: Ed Kmett on ’Stop Treading Water: Learning to Learn’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Ed Kmett (@kmett) started by asking: “What is the cost of using the wrong solutions, integrated over your entire career?” (Slides, Video)

Then he revealed that the topic he’d chosen for the talk was…

“How to be a genius”.

Portrait of genius physicist Richard FeynmanHe talked about a strategy for solving big problems described by famous theoretical physicist Richard Feynman (pictured):

  1. Keep a bunch of your favourite problems in your head.
  2. Every time you hear a new idea -> test it against one of your problems to see if it helps.
  3. If it does, tell people about the breakthrough, and they’ll think you’re a genius.

Note that, in Feynman’s approach, genius is attributed not necessarily to those that come up with new ideas, but often to those who figure out where to apply them.

Developers and Researchers

He noted that developers are in the business of solving problems, searching for solutions, while researchers often have solutions, but are searching for the right problems to apply them to. As a developer, it can be good to keep abreast of what researchers are discovering in hope of finding a solution to one of your favourite problems.

Memory Retention

He discussed human memory retention and the need to revisit topics over time to retain knowledge about them. The brain remembers far better information that is used or revised repeatedly. Knowing this, you can hack the brain by intentionally repeating material that you want to remember. (For example, after going to a conference, you could write a blog about the important points from each talk you went to.)

He chatted a little bit about jargon, saying that if you’re going to use jargon, you should always be willing to explain what it means.

Image credit: Richard Phillips Feynman (1918 – 1988) (unknown)

(My notes from) Ken Scambler on ‘Two Years of Real-World FP at REA’

This evening I went to a YOW Night where Ken Scambler (@KenScambler) spoke about the introduction and evolution of using Scala at REA Group. Here’s my notes…

Functional Scala Benefits

The sprial logo of the functional programming language language ScalaThe benefits of going functional are to get to code that is: Modular, Abstract, Composable.

Modularity is about being able to fit entire sections of code in your head without having to consider things going on outside that code, and also about being able to replace small parts without affecting the whole.

To write a total function (a function that returns a result for all possible input values), you need to elevate all possibilities into the type system. For example, you can’t throw an exception, you have to encode that possibility of an error into the return value somehow.

Abstraction should reduce changes to code, because unnecessary detail is not all across the code.

Whole systems can be composed from functional components.

Functional programming is not about picking up a hipster language. It’s about producing better software.
Continue reading

What would a Microservices PaaS Design Look Like?

Is this a Microservice PaaS?

A beekeeper looking at a frame of honeycomb from a hive. This blog looks at how a Microservices PaaS Design might be framed.Last week I wrote about PaaS and Microservices, asking, “Is a Microservices PaaS in our future?” Since then, I’ve had a number of URLs thrown at me along with the question, “Is this what you mean?”

Probably the closest in intent, based in the way they’re marketing themselves, are Giant Swarm. These guys are certainly putting themselves out there as “Simple Microservice Infrastructure”, and I think they’ve made some ground on implementing such a thing by including service discovery as part of their platform.

Does Docker == Microservices Paas Design?

However, my impression from their docs, as I explained in a comment on said previous blog, is that so far they’ve really only built a “Docker-based PaaS”, and are leaving most of the work of building a MSA, in terms of both choosing and configuring technologies, up to the developers of the system. To quote myself again: “in terms of setting me up with an architecture, it stops at ‘You’ve got Docker!’” (I didn’t realise it had service discovery when I wrote this.)

One of the Giant Swarm developers, Timo Derstappen, joined in the conversation. Continue reading

Is a Microservices PaaS In Our Future?

Last month at the Sydney Microservices Meetup, the Meetup’s organiser, Yamen Sader, presented a great talk on “A Microservices Reference Architecture“.

My own talk on the night, which was a case study about the evolution of microservices at Tyro Payments, laid out many examples of practices and tools we’ve used, but left it for people to either follow or ignore what we’ve done as they feel led. Yamen’s talk, on the other hand, was deliberately prescriptive, describing by the end what he obviously considers to be a widely-applicable framework - a “microservice platform in a box”, if you will. (He also ranked the importance of his suggestions based on a hilarious scale of Seinfeld characters, so he could recommended some ideas more strongly than others.)

Is a Microservices PaaS In Our Future?

A trendy, blue-lit data centre, the kind of place where it would be cool to run a Microservices PaaSYamen’s talk, as well as being really interesting, left me wondering about the future of microservices development. In particular, it had me wondering whether, at some point in the near future, we’ll see a Microservices Platform as a Service, or MSA-PaaS. I’m now thinking… Continue reading

Microservices at Tyro: An Evolutionary Tale (Presentation)

In February, I presented a talk at the Sydney Microservices Meetup titled “Microservices at Tyro: An Evolutionary Tale”.

Microservices at Tyro

I wanted to talk mostly about things we’ve been doing with microservices at Tyro Payments over the last year, but also about the almost 10 years of practice with distributed computing that has led us towards what we’re doing today.

I’ve merged my slides and the audio from the talk into a video, which you can watch below. If you’re more the reading type, there’s a transcript from the talk beneath the video. My talk goes for 40 minutes and then there’s 20 minutes of Q&A.

The talk covers:

  • Who is Tyro Payments?
  • Why are we doing Microservices?
  • Tyro’s Architecture History
  • Current development in Microservices
  • Tyro Microservices Practices
  • Asynchronous Communication Strategies
  • Helping Out Ops
  • Microservices Technologies and Patterns
  • Challenges we’ve been having at Tyro
  • Microservices pre-requisites

Continue reading

Notes from YOW! 2014: Scott Shaw on ‘Avoiding Speedbumps on the Road to Microservices’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

A "Speed Bump Ahead" sign, akin to Scott Shaw's warnings in his microservices talkScott Shaw (@scottwshaw), Head of Technology at Thoughtworks, spoke about “three of the biggest issues that microservice teams encounter”. (Slides)

Scott began by listing the following as “Basics”:

He said, “If you don’t know about these things you should at least google them before you start doing micro services.”

The speed bumps he talked about were:

  • Data aggregation
  • Access Control & Security
  • Managing Change

Continue reading

Notes from YOW! 2014: Cameron Barrie on ‘Mobile at Warp Speed’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

A bright photo taken using a slow exposure in a train tunnel, giving the impression of moving at warp speed, such as in the topic of Cameron Barrie's Mobile talk.Cameron Barrie (@whalec), Managing Director and Principle Mobile Consultant at Bilue, spoke on “how to apply solid engineering practices to your mobile applications by understanding common mistakes made, and how to mitigate against the risks.” (Slides)

Mobile: Move Fast

He said it’s crucial to be able to move fast. If you’re not disrupting, you’re probably being disrupted.

You need to be honest about what moving fast means for your organisation: you can’t start with crappy code and processes and just start moving fast. Continue reading

Notes from YOW! 2014: Mary Poppendieck on ‘The (Agile) Scaling Dilemma’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Lots of empty seats at a stadium. Can Agile scale to this kind of crowd?Mary Poppendieck (@mpoppendieck) spoke about scaling agile teams. (Slides)

She started by saying:

“There’s a big assumption that if agile is good, scaling agile must be good.”

Which made my jaw drop. I make that assumption. It had never occurred to me. Maybe agile techniques don’t work in a larger organisation?

She talked about four constraints on scaling: system complexity, organisational mindset, multi-team communication, and the time and energy of bright creative people. Continue reading