Whenever I need to sort a list of items, I now find myself using quicksort. I most frequently use it when prioritising my goals. Quicksort provides a fast and methodical way to sort lists of things, and it’s normally used internally by computers, but that doesn’t stop you from using it yourself, manually. In case you haven’t encountered the algorithm before, I’ll walk through how to use it. All of this can be done in your favourite text editor or note taking tool.

0) Start with a list of items you want to sort. In this example, I’ll use a few of my goals for this week:

The SLCD site has easy-to-use instructions for adding content
I have a time booked for my first toastmasters speech
I’m getting the hang of cooking the curried udon noodle stir-fry
My LinkedIn resume is freshly updated with my recent changes
Some fresh updates for TTD are online

1) Select and highlight an element that you think should be approximately in the middle in the list. This is called the “pivot” element.

The SLCD site has easy-to-use instructions for adding content
I have a time booked for my first toastmasters speech
I’m getting the hang of cooking the curried udon noodle stir-fry
—– My LinkedIn resume is freshly updated with my recent changes
Some fresh updates for TTD are online

2) Compare every item on the list to the pivot element, and move them either above or below it.

The SLCD site has easy-to-use instructions for adding content
I have a time booked for my first toastmasters speech
Some fresh updates for TTD are online
—– My LinkedIn resume is freshly updated with my recent changes
I’m getting the hang of cooking the curried udon noodle stir-fry

3) Repeat the process from step 1 for the items above, and then the items below the pivot.

The SLCD site has easy-to-use instructions for adding content
Some fresh updates for TTD are online
— I have a time booked for my first toastmasters speech
—– My LinkedIn resume is freshly updated with my recent changes
I’m getting the hang of cooking the curried udon noodle stir-fry

4) When sorting larger lists, you’ll need to keep going, subdividing the list above and below the pivot, until all the items are sorted.

Try it out! It’s quick and easy once you’ve got the hang of it, and you’ll gain nerd bragging rights (if you choose to publicise your achievement)!

I use a LiveJournal account as a private journal, and so all my posts are private. As far as I’ve been able to tell so far, LiveJournal always defaults to public when posting a new entry.

After getting a bit annoyed, I realised GreaseMonkey would be the perfect tool to fix the UI for myself. So, I wrote a quick script to set the privacy selector to “Private” on the post page. And so, I present possibly the shortest GreaseMonkey script ever. Enjoy!

privatejournal.user.js

Report on ACS Young IT conference in Adelaide – Day 2, 30th May

Leadership by Linda Zeelie

A definition of leadership – “the lifting of people’s vision to a higher sight, the raising of their performance to a higher standard, the building of their personality beyond its normal limitations”

There are poor, good and great leaders. Are you working for a great, or at least a good leader? If you are, you’ll be extended and your performance will improve. If not, you’ll become doubtful of your abilities and you’ll become less capable over time.

To become a great leader, learn from other leaders (good and bad). Working with a bad leader is useful to learn about leadership, but it’s not good for you. So learn your lessons quick then get out!

Have a vision AND a plan. You should be able to record and explain it simply and concisely. If you can’t explain it simply, you simply don’t know it.

No decision is always a poor decision. Make a decision, and once you’ve made it, be very, very decisive. Do not waver, own the decision!

When things go well, share the success. When things go wrong, own the failure. Take responsibility, even when it’s not directly your fault.

Linda had a very strong conviction to her speaking. I could sense that she felt that what she was talking about was really important, and many of her points stuck with me. Definitely one of the best talks of the conference.

Things have been quiet here on the blog because I’ve recently applied for a job at Google, which has meant lots of revision of algorithms and data structures. It feels like studying for an exam! My technical phone interview is on tomorrow morning, and if all goes well I should have an on-site interview a few weeks later. Wish me luck!

Photo credit: B. Roewert

Report on ACS Young IT conference in Adelaide – Day 1, 29th May

The Art of Visual Effects by Didier Elzinga, CEO of Rising Sun Pictures

What follows are my summaries of the main points I took away from this talk.

At first, hard work (long hours, late nights) is important. But at a point this stops being true. Instead, the value of what you create becomes more important. You create this value in smaller moments, and you create far more value in this shorter period of time. The rest of your time is training for those moments.

The creative process isn’t magic – it is a rigorous process. For example, coming up with one great idea by brainstorming then filtering down those ideas.

1000 ideas –> 100 good ideas –> 10 very good ideas –> 1 great idea.

To perform this process, you need to make the brainstorming process as cheap as possible, so it doesn’t take too long to come up with the 1000 ideas. The number 1000 here was used literally, so you actually have a list of 1000 ideas before you start to filter them down. If you have less than 1000 ideas to start with, you’ll have less chance of having found the 1 great idea. This process relies on trust, so that everyone present feels comfortable blurting out “stupid” ideas.

Be courageous – don’t do something just because “that’s what everyone else does”. We need to learn from failure, and to do that we need to talk about it.

A classic question – “What would I try if I knew I could not fail?” but this question seemed to be opening up more possibilities for me. Very interesting if you can really look at answering it deeply.

Two techniques for meetings:

1. You come to a meeting with a problem that you need help with. You state your problem, but before anyone is allowed to answer, everyone has a chance to ask questions (and only questions) to clarify what was meant by the problem. This avoids people getting stuck on the first solution that comes to mind, which is often formed on an incorrect understanding of the problem.
2. Once people are ready to answer, face away from them and write notes. You are not allowed to talk. This way your own point of view (which hasn’t been able to solve the problem for you) won’t influence them, and they’ll be able to freely discuss a solution.

Compared to coming up with an idea, writing a web app is like trying to swim through treacle. After completing a week-long iteration on TickTickDone, it typically takes a day or two to unwind and mentally process the iteration’s work, then about an hour to come up with the tasks for the next week. Actually coding and testing those features takes the majority of the week’s 15 hours work.

The one-web-app-per-week idea is limited by how much functionality you can develop within the limited timeframe. I’d like to make my time spent coding as efficient as possible. So, I’m setting myself the challenge of creating a framework on top of Django and jQuery such that I can re-develop the current version of TickTickDone (iteration 8, made up of 8 weeks work) within one week.

At the moment, TTD’s code is not great in the DRY department. That problem exists in the javascript code and also in the python code, which is troubled by many very similar unit tests for very similar AJAX response functions. So as a solution, I plan to start by abstracting as many common patterns as I can. I’ll also try exploring the jQuery plugin library for pre-built components to help along the way, and see if I can form all of these into a cohesive library. Once I feel it’s ready, I’ll try using it to re-develop TickTickDone in a week.

An obvious alternative to this whole approach (and the one commonly used) is to hire more people to code for you. That’s not an option for me at the moment because I don’t have the money to hire more coders (a constraint), but it’s also not a great strategy due to the communication scaling problems in large teams.

Any thoughts? Has anyone done this (or tried to do this) before? Let me know in the comments.