An example of algorithmic thinking to be efficient and happy!

This year I’ve been focusing on reading more. In previous years I’ve read mostly read other blogs, but this year I have been been reading more books (both fiction and non-fiction) and quality news (news that requires a subscription and is not fully reliant advertising).

I subscribed to digital access of the Australian Financial Review and actually get it physically delivered on Saturdays. Confusingly, getting full digital access AND getting the paper physically delivered on a Saturday was half the price of a digital access only subscription.

In last Saturday’s paper there was an article about NSW lagging behind on introducing a digital skills curriculum, which mentioned Swinburne University of Technology computing professor Leon Sterling as saying that a lot of people were put off by the idea that computer classes were just about teaching kids how to do coding, but coding was just a way to get students thinking differently.

Reading the article made me think about how learning to code had trained me to solve problems with algorithms, and the benefits of being able to do so. I think everyone can realise and understand the efficiency of being able to automate repetitive tasks with code/algorithms, but I think that the personal enjoyment and satisfaction of engaging your brain to design the algorithms and write the code often goes unappreciated.

I demonstrated a way of writing a simple line of code to avoid to manual drudgery today, and it inspired me to write this post.

I noticed one of the One Model developers typing a series of numbers into a calculator. It turned out they were calculating how many lines of code they had edited in a pull request. The numbers were coming from the green and boxes shown in the following picture (they had a significantly longer list than this example).

Bitbucket files changed

How I solved this with an algorithm and some code was:

  1. I opened up the Chrome’s developer tools by right clicking on the first green box and selecting “Inspect” from the right click menu.
  2. The first part of the algorithm needs to select all the numbers in the green boxes. I changed the selected HTML element to the parent that contained all the green boxes. Observing that the element for the green box had a “lines-added” class. I wrote the following script into the developer tools console to return all the green box elements.
    $(".lines-added", $0).toArray().map(box => parseInt(box.innerText))
  3. The second part was to add those numbers together. To do that I extended the script to what follows.
    $(".lines-added", $0).toArray().map(box => parseInt(box.innerText))
        .reduce((total, value) => total + value)

This output the total of 538 into the console and was much easier than typing them one by one into a calculator.

I use a similar technique frequently to select text from web pages that can’t be easily selected with the mouse and copied e.g. the values in a column in a table. I’m definitely not the only one who has come up with this technique and coding it did require JavaScript skills, but if I didn’t have the mindset to use algorithms to solve problems I’d be stuck copying text one by one.

Advertisements
An example of algorithmic thinking to be efficient and happy!

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.

Inconsistent

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