The one question I ask all software developer interviewees

I have a favourite question that I always ask of all interviewees.

“What do you do to improve your skills and keep up to date?”

Despite its simplicity I find it incredibly effective.

First, I think because it is simple and straightforward it appeals to interviewees. It’s not a trick question, or an arbitrary problem solving question unrelated to what they are interviewing for. It doesn’t require prior preparation, and it shouldn’t create any additional stress or pressure for them to answer. Candidates can simplify explain what it is they do.

Second, it encourages an honest answer from the interviewee. It is also easy to determine the candidates that are lying with follow up questions.

Third, it identifies the candidates who have a passion for software development. The candidates that understand that there are always new things to learn and ways to improve. I think these developers are the ones that do the best work. The ones that take pride in what they do and don’t just accept the status quo. These are the developers you want to build a team of. They create a motivated culture. A culture where people learn from their mistakes. A culture where everyone wants to be the best they can be and deliver the best work they can.

Fourth, in addition to being a very effective way to evaluate candidates I enjoy that this question allows me to learn new things myself. I’ve been introduced to websites, blogs, podcasts and even books that I hadn’t even heard of before allowing me to expand my knowledge.

If you interview software developers this needs to be a question you ask your candidates, and if you are a software developer this is a question you need to be able to answer.

The one question I ask all software developer interviewees

Why One Model is moving our infrastructure out of Opsworks

At One Model we’ve been using Opsworks since December 2015 so that we could script, configure, and maintain our infrastructure with Chef. Overall using Opsworks has been frustrating and we probably should have abandoned it a while ago. I should clarify that we are using Opsworks Stacks (the other variations didn’t exist when we started using it).

There are 3 main reasons behind the decision to move away from Opsworks.

  • It can be inconsistent.
  • It receives little support or investment from AWS.
  • Developing and testing recipes is hard.


This is the most frustrating aspect. Instances fail in the setup phase without any reason or error, but then succeed on the next attempt without any changes being made. It happens fairly frequently, almost every second instance created seems to be affected.

Opsworks fail

It’s frustrating because when it happens it takes 20 or 30 minutes for the setup to timeout before you can stop the instance and try again. It’s more frustrating because there are no errors in the recipes and the next attempt to start the instance will succeed. It’s even more frustrating because there are no errors and nothing obvious that can be fixed to prevent the issue.

This issue also means Opsworks cannot be relied on. What if it occurs when a new instance is being started to ensure service availability?

Lack of internal support

Opsworks Stacks appears to be a forgotten child of AWS and it has been a long time since the last significant update. There still isn’t an option to use an application load balancer (which was released almost a year and a half ago), only classic load balancers are supported. Also, the version of Chef available is a major version behind.

While there have been no updates to Opsworks Stacks, AWS has released other Opsworks products – OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise. We haven’t tried these but they appear to just be managed instances of Chef and Puppet, and I suspect that they are more to get existing users of Chef and Puppet to migrate those services into AWS then providing an alternative to Opsworks Stacks.

Difficult to use

There is no point using a technology to solve a problem if it only complicates things more, and ultimately Opsworks wasn’t making our lives easier. An advantage of Opsworks was that we didn’t have to manage infrastructure for running Chef, but this made it more difficult to test recipes. The easiest way was to use Opsworks, but it is tediously slow (even without setups failing mysteriously).

Additionally using Opsworks required us to learn Chef – a combination of Ruby and scripting languages. Chef is more powerful than what we were using it for, but this made it more complicated for us to learn and understand. It also didn’t help that the version in Opsworks is out of date.

What’s next?

The long term plan is to have our applications run in containers, but while we make the necessary changes we will migrate from Opsworks to building custom AMIs with Packer. We have found Packer easy to learn and quick to get started with. The additional benefit is that using custom AMIs makes starting new instances quicker, as the setup has been done as part of creating the AMI.

Why One Model is moving our infrastructure out of Opsworks

Revisiting why you should start blogging early

Happy New Year!

One of my last posts was “Why you should start blogging early”, an attempt to demonstrate the benefits of starting blogging sooner rather than later. I posted that back in May, 2017, and that was pretty much it for the rest of the year (apart from a post about how little I blogged). An upside (possibly the only) to not posting anything else is that it is a good demonstration of the point I was making.

End of 2017 views

Despite posting next to nothing after May my number of views continued to grow, thanks to all the posts I had written previously. My previous posts continued to gain traction and attract more views. I already have had more views this month in 4 days, than I did in January 2016.

So once again, the earlier you start, the more content you will have, and the more views you will receive!

On a related note: last year I had a goal of writing a post each week. This year I want to write more posts than last year. I am not sure if I will be able to maintain a week cadence, but as long as I finish the year with at least 17 posts I’ll be happy.

Revisiting why you should start blogging early

Dusting off the cobwebs

Well, it’s been a while. The fact that the last time I blogged was in May reaffirms how quickly this year (especially the 2nd half) has gone for me.

At the start of the year I had the goal of writing a blog post a week, and I did pretty well at sticking to that until April. Looking back, that April period was where the habit started to go off the rails. I had a period of what I guess was writer’s block, where I was attempting to turn my thoughts on another blog post into a post of my own. It turned into a struggle and took me over a month.

I think failing the goal during that period took away some of the pressure I had created to blog weekly. After that when I was busy I wasn’t worried about blogging, since I had already missed some weekly posts.
I’m thinking about this not to try and make excuses, but to analyse what happened and how I can regain a habit of blogging more regularly again.

I think another big factor was that I stopped walking to and from work. It was on these walks that I would think about what I would write, and I would even start to draft posts in my head. Due to an achilles injury I started to catch the ferry instead of walking. I don’t find the ferry as good an environment for organising my thoughts as the walk. Maybe it is the stops with people getting on and off. Maybe it is the fact that I am sitting down and can read. At least I have been reading productively, and not just scrolling through Facebook/Instagram/Imgur.

Even though I haven’t been walking I have been thinking about blogging and have been writing ideas and notes into my draft document for when I get back into the habit, but that has proven a little difficult. My wife and I had our first baby and our priorities, routines, and lifestyle have been changed fairly dramatically. It is no coincidence that I am writing this on a rare night home alone.

With that I think I will leave it there for tonight. This objective for this post was to update the blog and take the first step towards regular blogging again. I hope to write more posts covering some of the other things that have happened throughout the year soon.

Dusting off the cobwebs

Why you should start blogging early

This is a quick post that I was inspired to write by looking at my blog’s stats and follows on from my previous advice to blog.

You should start blogging early because the results compound over time. Here are the stats from my site (out of WordPress).

blog stats

What I am seeing is that the popular posts from previous years still continue to attract views, even ones like Setting up LESS compilation to CSS with Gulp in Visual Studio 2013 which refer to a version of Visual Studio two generations old now. While that post should have a fairly limited lifetime, I expect others posts such as Avoiding numeric overflows in Redshift decimal multiplication to be useful and attract views for a lot longer. I posted Avoiding numeric overflows in Redshift decimal multiplication in August 2016 and it got 90 views before the end of the year. This year it has had 363 views and is my 2nd most popular post viewed this year.

I hope this highlights the benefits of starting blogging and producing content earlier. The earlier you start blogging, the more content you will have available in the future. This is more content that people could find your blog through or more overall views you could receive.

Why you should start blogging early

Lightning Talk at Brisbane Software Developers Startup Community

Last week I did a lightning talk at the Brisbane Software Developers Startup Community meetup drawing on my experience from Techstars and One Model. I came up with 4 areas I wanted to cover and the following is the script I prepared.

Shared experiences

I think something that gets underestimated is the importance of being in a motivating environment with people you can relate to. I got a real boost when we started working out of the Techstars office, compared to before that when I was working from home by myself. The camaraderie we had in the Techstars cohort is something I missed when it finished and I came back to Brisbane. When I started to hire developers here, we worked out of the Gravity co-working space and that provided a similar environment.

Taking part in Techstars was a great experience. If you get the chance to take part in a startup accelerator I’d highly recommend it. On top of the advice and the kick start it will give your business, there is a benefit to being alongside other motivated founders who are on the same journey of starting a company. If you’re not interested in being in an accelerator I’d at least look at working out of a coworking space like Fishburners or RiverCityLabs. And hopefully this meetup can become a community.

Mentor Whiplash

Techstars is all about its network. Each company met with about 90 different mentors, within the first week and a half! There was a lot of back to back, speed dating style meetings. On top of that, and one of my favourite parts of the experience, every Wednesday night they’d have a founder story, and not just from other Techstars founders. I found it motivating to hear other’s journeys, and I enjoyed listening to the different approaches taken.

You end up getting a lot of ideas and advice, often quite conflicting. This can result indecision, and gets referred to as mentor whiplash.

I think this is pretty common, even without getting a lot of advice. All that needs to happen is someone suggests an approach different to you current path. There’s no real way to deal with this, ultimately you just have to internalise the advice and decide for yourself is it right or wrong for you.

Always be selling

Yeah, it’s a cliche, but it’s true. If you’re a solo founder, it’s going to seem obvious that you need to be selling your company. Where it is not so obvious is if you are part of a team. In that case you might think you can get away with focusing on building the product, probably a bit like I did originally. However you won’t.

You should always be thinking about selling. Even if you aren’t selling directly to customers you need to think about selling to investors and potential employees. This is an area I feel that we could do better in at One Model.

A couple of easy ways I think you can do this are:

  • Blogging about the company and the software being developed and challenges you’re overcoming.
  • Putting out open source software and building a community around that.

Another benefit to this is that if your startup doesn’t work out, you have created some collateral to help you get another job if required.

Also on the topic of sales, something else I think that makes developers uncomfortable is selling features that don’t exist yet. Unfortunately this is something has to be done, even just for the simple reason of getting market validation. You don’t want to build something and then start to try and sell it and find out it is entirely wrong. A way of phrasing this that resonated with me was “sell the future”.

Hire Slow Fire Fast

Finally the part I think I’ve found the hardest has been hiring. I do regret not having put effort into creating a company blog and presence so that we have a pipeline of candidates. I’m also a bit jealous of people that have consulted, or worked in a consulting firm and have a good network of fellow developers they can reach out to for candidates.

Without that, we’ve been relying on recruiters and it’s been a slow process to scale up the team. For the most part the developers I’ve hired have been excellent, but early on I did have to let one developer go. It was pretty obvious early on that they weren’t working out, not from a skills perspective, but from an attitude and work ethic. Unfortunately in startups I think you have to be a bit ruthless, you’re trying to be as effective as possible and as a founder you have enough to do without having to manage someone to get them to perform. I hadn’t fired anyone before and I was pretty nervous about doing it, but I feel it was the right move for the company and the the replacement we hired has been awesome.

Lightning Talk at Brisbane Software Developers Startup Community

Thoughts on “Turning Tech Hobbies into Side Hustle”

Last week month I read Turning Tech Hobbies into Side Hustle by Erik Dietrich and it led to me to analyse what I am doing and whether it is productive or a hobby.

Initially I thought the message of the post was extreme, but after consideration changed my mind. The message I initially got was aim for a direct reward from hobbies, Erik’s example being book sales from writing a book on F#. After further consideration I found a better takeaway was be honest with how you are spending your time. If you are learning something to satisfy your curiosity, don’t count that as productive time/career development. Later if you find that you are not happy with your career progress, you can evaluate whether that time is unproductive and could be better spent. From this perspective learning a new language is no different to other hobbies, you just need to be honest that it is a hobby.

With that, I decided to take a look at myself and ensure I was being honest.

Coincidentally, and maybe why I found the post extreme initially, something I have wanted to do is learn a functional language. Being honest with myself I do want to do this to improve my software development, not for my own vanity. Functional programming concepts are making their way into a lot of languages. Tuples and pattern matching are some of the features in the latest C# release. Erik is correct, that just learning a language does not have quantifiable value. When I do learn a functional language following his suggestion, or at least blogging about it, will produce more value. Learning a functional language is not high in my priorities, which I’ll come back to later.

Speaking at a meetup is something that is partly motivated by vanity, but not entirely so. I think it would be beneficial, for myself and for One Model, to get a bit of awareness from me presenting. It may also be possible to quantify the value of speaking. The main outcome I’m after is more candidates for recruitment, which is measurable. So while there is some vanity behind the motivation, there are valid reasons too. If I wait until I have something worth presenting, instead of just getting up there for the sake of speaking, I think I am approaching it correctly.

I don’t have a quantifiable outcome in mind for blogging. I wonder if Erik did when he started? I doubt he envisioned that he’d be getting paid to write blog posts for other sites/companies. I think I could get more out of this blog if I target a more specific audience. This blog promotes me, but I could be promoting One Model more with it.

This brings me to the last point I want to write about. I don’t think I’m the target audience for Erik’s post. I am a founder and partial owner of One Model and by working to increase the value of the company, I increase the value of the shares I own. I actually get maximum value from my personal time by spending it in ways that benefit both myself and One Model, and most of the time that is what I do. When I was researching Selenium, I was doing it so that I could create automated UI tests for One Model.


Well, this took me a lot longer to complete than it should have. April was a busy month for me, but that’s not the real reason this took so long. Writing up the analysis of the post and myself ended up being more difficult than I anticipated and I let this take away my motivation. I’m disappointed I broke my weekly post streak, and that I have let a month pass without adding value to my blog. On the positive side I have finished this now and feel recharged. Time to get back into regular blogging.

Thoughts on “Turning Tech Hobbies into Side Hustle”