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.

An example of algorithmic thinking to be efficient and happy!

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

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

Why you should blog

For the last few years I have been a career mentor for I.T. students at QUT. As part of that I try to inspire the students to start blogging. In this post, I’m going to detail reasons why you should blog. It’s written with students and graduates in mind, but I think everyone should be blogging. I regret that I was slow to start.

It is intimidating to start. You might think that you don’t have anything worth blogging about, or that your posts won’t be good enough for others. Forget about what others might think.

You should blog for your own personal development.

Blogging will help you work through ideas, you will learn more as you research your posts, and your communication will improve.

Blogging is good for your career. It will show your interest, that you enjoy learning. It will also show that you can communicate and share ideas. It will differentiate you from other students and graduates without a blog.

Forget that others might read your blog and start blogging for your own benefit. Blog about what you are learning, the parts you found challenging and what helped you to overcome that. Blog about what you have built and how you have applied what you are learning.

You are just starting out in your career and that gives you a different perspective from experienced bloggers. Writing from your perspective might allow you to create content that helps others starting out in their career. Sooner or later people will start reading your blog and you will have contributed to the community. You might even find looking at your view count addictive!

Hopefully this convinces you to start and I am always happy to help and review.

If you need more convincing I recommend you read Scott Hansleman’s or Steve Yegge’s or Erik Dietrich’s opinions.

Why you should blog