Done is a strange word. So strange in fact that most development paradigms and frameworks make attempts to nail down their own interpretation of the word to help developers grasp the concept of “done” and turn it into something tangible. A classic example of this would be SMART targets. SMART targets turn qualitative goals and objectives into quantitative target(s) that can be more easily measured, to make it clear when they have been achieved or are “done”. If anything, turning an objective into a set of SMART targets gives the game away about the word done. Being “done” is wholly related to what you are attempting to do. “Done” doesn’t mean anything by itself, because the traditional definition is that it means that a task has been completed, which means the entire definition of done relies on the task at hand.
Recently I have been examining my own understanding of productivity. More specifically, I’ve been looking into the difference between when I do and do not feel productive. Ultimately I realised it was not actually linked to the work I was doing, but the tasks that I had completed. This made me realise that a task I’d worked on for eight hours and I hadn’t completed made me feel less productive actually completing a few tasks that each took an hour, despite the fact that I had put more time into the former.
It is worth noting at this point that a lot of this is already widely acknowledged. Generally speaking, big projects are broken down into small chunks or tasks and measured on a per-task basis. Occasionally, however, a small task is overshadowed by a larger, more intimidating task. For example, 10 smaller tasks might be preventing a build from being built or released, thus the build becomes the focus and the smaller tasks become overshadowed. When this happens, it is easy to fall into the trap of feeling like nothing is being accomplished, despite the fact that the multiple smaller tasks that make up the big task are being completed one-by-one. This result in feeling a task is done and feeling productive is linked to finishing major tasks, as opposed to finishing any tasks.
With regards to developing a single feature or mechanic, the feeling of being productive is easily lost amongst the overhead of the task at hand. When working through building a simple mechanic, such as creating a grappling hook in 3D space, the first point of completion comes when the feature is mechanically implemented (in this case when the player looks at a point, they can link a grapple to it and move in a swinging motion around the point). At this stage of development the feature is mechanically complete, and therefore, with regards to the initial brief, it is done. The problem comes when looking at the feature in the wider terms of a project. Questions get raised about the mechanic such as “does the grappling hook feel good”, “can we improve how realistic the physics are”, and “what happens when we start at different heights start to affect the feeling of being complete”, which make the task feel incomplete. This causes the feeling of completeness to be lost until those questions have been answered. However, after those questions come even more questions such as “how abstract is the code”, “will the mechanic drop into any project”, “does it look realistic” etc. This shows how a simple feature, even when it is mechanically complete, fails to contribute to a sense of productivity because it has some unfinished aspects, even though those are not connected to the original brief.
When looking at tasks that contribute to the wider project, completing tasks that are part of a bigger feature can feel unproductive because they feel insignificant in comparison. Even if the smaller task can take hours or days, it can still feel like little has been achieved as the “parent” task hasn’t yet been completed. An example of this might be developing a menu system for a game. One of the smaller tasks might be creating a flowing system to allow users move between different menu screens. Despite the fact that feature is integral and useful, if the developer is focussed on creating the menu as a whole then that feeling of success can be swept aside as they continue onward towards the ultimate goal. This means, instead of feeling like you’re being pretty productive every day, you don’t feel productive until the whole menu is finished after several weeks. Ultimately this results in feeling relatively unproductive most of the time, despite the completion of tasks.
What it is worth taking away is that it is very easy to feel unproductive when you are actually being productive; because your scope has been extended beyond the work you are doing to include the work you have yet to do. It is not a bad thing to keep the wider context in mind; certainly when programming keeping wider project integration in mind is crucial. The point is that it should not overshadow the smaller successes.
A good way to change this mentality is to put something in place to track each task you complete. This could be as simple as keeping a tally on your desk, or giving yourself a small reward like a round of applause. You could take it a step further and tie your successes into another aspect you want to improve upon, like tweeting each successes to help with improving your social media presence, or by drinking a small glass of water each time you complete a task. Either way, it is important to recognise success in all its forms. By changing how you perceive being “done”, you can improve your ability to recognise your own productivity. Eventually, you’ll realise how productive you actually are, and in turn this will help you to be even more productive (and who doesn’t love productivity)!
Happy productivity,
Adam
Adam Boyne 
Leave a Reply