Making the most from your time (or, working smarter, not harder)

‘Work smarter, not harder’ as the saying goes. For most people this is common sense. There’s many ways you can interpret this advice, from finding tools and techniques to help you automate repetitive tasks, to prioritizing tasks that have the highest contribution towards achieving a goal and depriortizing or even ignoring other less important tasks – why spend time on a task if it doesn’t help you get to your goal?

After spending a while writing this article I very nearly decided not post it, because don’t most people get this already, it’s kind of obvious, right? Well, it’s only obvious if you already get it, and maybe not so obvious if you don’t. The reason why I felt there’s value to share this is I’ve come across enough people during my years of working in Software Development who just don’t get it. If these people can gain even a smallest something from this post, then hopefully they’ll be saved from their misguided attempts to ‘do all the things’.

Deciding where to spend your time is like choosing where to invest your money. We each have a finite (and limited) amount of time to invest in working on tasks, as there’s only 24 hours in a day and at least some of those hours need to be spent sleeping. More often than not the amount of time you have available is less than the time to complete all your tasks (either at work or in our personal lives).

Who needs to sleep?

First, let’s get rid of the idea that spending more time working and less time sleeping is the answer to all problems. This is not going to help you in the long term. Reducing your hours of sleep so you can do more during the day is usually not a sensible approach, as in the long run you’ll just end up more tired, and working while tired means you’re less alert, less effective, and more likely to make mistakes. Obvious points to make, but some people just don’t get this. Spending more time working rarely means you complete more work. If anything, it may mean you get more done but at a lower quality and with more errors and mistakes. If that’s acceptable for you and/or your employer then great, but for most of us that’s not a sensible or effective option.

Automating Repetitive Tasks

As software developers, we’re in a much better position to be able to automate tasks than non-software developers. Have a manual task that is time consuming and you find yourself repeating it again and again? Write a utility to help you automate the task! Ok, so it’s not always as easy as that, and you might not have the free time to spend developing the automation. But if the amount of time invested up front to build the automation is going to free up time to work on other tasks in the future, then it might be worth the initial investment. Discuss with your supervisor if you’re unsure if you should be spending time on building automation rather than working on completing the task itself.

Developing a script or a standalone app to help automate tasks doesn’t have to be a major development effort either. Sometimes learning shortcuts with your exiting tools can be a major time saver. Here’s some quick ideas:

  • Learn some simple regular expressions for matching patterns, and how your text editor of choice uses them to do search and replace tasks. Manual and repetitive tasks like replacing some pattern of text in a file can be done in seconds if you can use some regex.
  • Moving or deleting a column of data in a tabular text file: most text editors have the ability to select a column of text with the mouse, rather than text spanning horizontal lines. This makes it easy to delete or move a column.
  • Learn a couple of approaches for how to work with multiple files in multiple subdirectories. This can often be combined with other approaches, like using a regex for a pattern matching and replacing text. If you have to apply an update across multiple files, knowing how to write a quick script to find all matching files in all subdirectories can be a massive timesaver.
  • Keep a directory of common scripts you’ve developed in the past so you can reuse them in the future. It’s often quicker and easier to reuse a previous script as a starting point and modify it, rather than start from scratch every time
  • If your scripts are generic and can be shared (and do not contain company proprietary information, and/or your company allows you to share source code publicly – always check if you’re unsure), share reusable snippets either as Github Gists, or share as a public GitHub project, or similar code sharing sites like Pastebin. This allows you to build up a library of useful scripts, and also allows others to benefit from your work too.
  • Use the opportunity to write a script to automate a task as an opportunity to learn a new language. Learn some JavaScript and node.js, Groovy, or [insert language you’ve been meaning to learn here]
  • Never underestimate the tools you have right at your fingertips. If you’re lucky enough to be developing on a *nix platform, your shell has a myriad of tools that you can pipe together to complete a more complex task, e.g. find -exec, sort, grep, awk, sed, wc -l, and bash scripting in general to build something more complex than a single one liner

Prioritizing your tasks

In general, most of us in our jobs have some tasks or responsibilities that are core to our role, things that we have to or are expected to do, and there’s most likely an assortment of other tasks that are not essential or time critical, and maybe don’t even contribute towards achieving whatever your core responsibility is. These other non-essential tasks may come up from time to time, they might be ‘nice to haves’, they may come up in conversations as improvement type side projects. These additional tasks may also be longer term skills development type activities like mentoring or knowledge transfer type tasks. In the long run these add value to your organization as a whole, but they might not contribute to getting a product built and shipped out the door today.

If we had to categorize each task in terms of importance, we could think of a number of varying scales along where we could put each task:

  • essential to achieving core role responsibilities, verses non-essential
  • short term tasks verses longer term tasks
  • tasks that result in short term/immediate gains (quick wins), verses longer term gains (strategic investments), for either you or your company
  • high effort, verses low effort

Think about the tasks you have, and try to prioritize them in a way that you can (if possible) spend time on tasks that have either higher short or long term gains, and de-prioritize other non-essential tasks.

If you really can’t get away from doing ‘all the things’ yourself, at least try and automate as much as you can so you can free up time to work on tasks that have greater rewards or impact.

‘Automate all the things’, not ‘do all the things’!

Game development in progress: Space Invaders clone – update 2

Earlier this year I started developing a Space Invaders inspired game for Android. I started back in March, and have worked on it for a around 20 to 30 hours or so, on and off. Not being an expert in Android development or game development in general, it’s been a learning experience. The book I read back in March, Android Game Development by Example, was a good book to get started. I realize I probably could have got to a playable game quicker if I’d used a game development platform like Unity3d, but I wanted to get to grips with writing a game by from the ground up first. I’ll circle back and probably rewrite it using something like Unity later.

Right now I’m at a point where it’s playable but there’s a few key features I still need to add, like the bases/shields at the bottom of the screen, and the invaders need to shoot missiles at the player. It’s a pretty easy game at this point 🙂 I have a few ideas for some gameplay variations to add too.

I started implementing as a standalone Java app using the Java2d api and the 2d game engine that I’d previously worked on for my first attempt at a game in Java, a version of one of the classic Nintendo Game n Watch games, Turtle Bridge.

I tried to replicate the animation of the invaders moving one at a time, one row at a time and got pretty close:

Compared to current day AAA tier video game development projects which typically have multi-million dollar budgets and teams of artists, story writers, sound engineers, QA, developers, as well as marketing and PR teams, I find it fascinating that Space Invaders was originally developed by a single developer, Tomohiro Nishikado. Not only did he develop the sofware for the game, but he also designed the hardware on which the game runs.

There’s some interesting features of the game that were not part of the original design, but resulted from limitations of the hardware. For example, the invaders speed up as fewer are left remaining on the screen. This is a defining feature of the game, but was a side effect from the 8080 processor being unable to animate a full screen of invaders at the same speed compared to a screen with only 1 or 2 remaining. Rather compensate in software to keep a constant frame rate, this feature was kept.

Other features in the game play logic could easily be overlooked by a casual player:

  • The mystery ship appears on a regular, timed basis, at around each 25 seconds
  • The mystery ship is worth 300 points on the first 23rd shot on each screen, and then 300 on every 15th shot for the remainder of the screen. For all other shots it’s 100 points (if you play for high scores, then this fact is probably very well known to you 🙂 )
  • Missiles from the invaders will not kill the player if fired from the last row on the screen

Here’s a quick video of how far I’ve got so far. This is running on a device simulator, so the frame rate is not as fast as on a real device:

I’ve still got some work to do, but I’m pleased on my progress so far.

Unix source commit history from 1970 to present (and links to other shared commercial source)

A single github repo has been shared that combines historical commits for the Unix operating system going all the way back to 1970.

As a software developer I find it fascinating to look at the source of other software that you use and often take for granted. We’re lucky enough to be able to freely browse source of many open source projects, shared on github and other online repos. You can learn a lot from looking through code written by other developers.

There’s also a many interesting and previously commercial systems that have had their source publicly shared. A few examples that I’ve come across: