I’d like to thank Ric Parkin for stepping in for the last issue of Overload. I needed to take a break and now I’m back. Taking a break can take various forms. Sometimes they are by choice, for example just to go outside and enjoy some sunshine for a brief moment, and on other occasions a hiatus is enforced either by others or by personal circumstances, often for longer. Though such an interruption can be irritating, it can also be useful. Just leaving the computer for a moment to get a glass of water will let you rehydrate, allowing better concentration. Simply standing up and looking out of the window is reputed to be good for our eyes. I personally find I frequently spot the cause of a bug or a problem by glancing away from the monitors then looking back. It seems the change of physical perspective can also shift my mental viewpoint. Stepping away from the keyboard is important for both the quality of your work, and for you. Many programmers have notoriously bad posture. Taking a moment to stretch and re-adjust the body can both help to avoid chronic problems such as lower back pain, upper limb disorder or repetitive strain injury (RSI) for which insufficient rest breaks are purported to be a risk factor [RSI]. I’m not suggesting stretching prevents RSI, just that self-awareness combined with some movement can avoid long term issues.
Other forms of rest are neither self-imposed nor preventative. After, in fact during, this year’s ACCU conference I had so much fun talking to so many people, I lost my voice. I was left, literally speechless. This is very frustrating, but means you have to listen and may therefore spot things you would not otherwise have done had you been seeking a moment to share your words of wisdom or a timely wisecrack. I have lost my voice on a few occasions. It never ceases to amaze me the number of times people will try to phone me up, and even if warned still expect me to speak. Unsurprisingly, the sound of a ringing phone is not a miraculous cure for laryngitis. At the conference I was reduced to having a list of useful phrases to hand, which I recently rediscovered. The first on the list is, of course, “I’ve lost my voice,” closely followed by “Geeks”, “Drink!” and “Slackers”. If you couldn’t speak for a few days what phrases would you choose? It’s interesting to look back and see what I ‘said’ to various people, and am aware that it probably reveals more about me than I want to know. Why did I not have at least one positive, life affirming stock phrase prepared? How many times did I really need to write down ”WTF?!”?!
It is good to take time out to think about your regular routine. Do you take a lunch break? Many people grab an overpriced sandwich and then return to their keyboard to lunch ‘al desko’, or indeed get food delivered straight to their desk. The rationale seems to be that there is a linear relationship between time spent in front of a computer and the amount of productive work completed. Once we had decided how to quantify ‘productive’, I suspect the graph would be neither linear nor, importantly, increasing after a critical point. Even if there’s nowhere nice to sit and eat your lunch, it is often worth just going for a walk round the block just to give yourself space to step away from the problem at hand and look at it differently. Do you go home at night? I have met several people who will stay until really late, almost every day. It can be difficult to tear yourself away from a very interesting problem, and yet it is often when we withdraw from the forefront of a situation we get a clearer perspective. Sometimes programmers will stay late trying to make last minute bug fixes in order to release on time. Many of us will have been at our desks in the small hours, hacking away, possibly making new bugs as we go. It might avoid reputational damage to delay the release rather than release last minute untested hacks and patches. Sleep is, after all, important, even though there seems to be a current trend among students for taking so called ‘smart drugs’ of late. These allow you to ‘pull an all-nighter’ presumably allowing you to make a deadline for course work or to cram all night before an exam. It would be interesting to find a way to measure the quality of the work produced under such circumstances. Many of us do turn to stimulants to stave off sleep. Famously, a “Mathematician is a machine for turning coffee into theorems.” [Renyi] and programmers also turn coffee into source code, so perhaps staying awake at the appropriate time matters too.
The father of Russian vodka [vodka], Dmitri Mendeleev is also renowned for inventing (or discovering) the periodic table. Though others before him had tried to arrange the elements in some organised structure, his approach formed the basis of what we’d recognise today as the periodic table. He suspected some atomic weights were wrong and correctly predicted that some elements had not yet been discovered. The popular story tells us he discovered the ordering after writing the elements on playing cards and arranging them in different ways for days [Mendeleev]. In fact, it seems he spent many sleepless nights thinking about the problem and dozed off one day to realise a new arrangement in a dream:
On the night of February 17, 1869, the Russian scientist Dmitri Mendeleyev went to bed frustrated by a puzzle he had been playing with for years: how the atomic weights of the chemical elements could be grouped in some meaningful way – and one that, with any luck, would open a window onto the hidden structure of nature. He dreamed, as he later recalled, of ‘a table where all the elements fell into place as required.’ His intuition that when the elements were listed in order of weight, their properties repeated in regular intervals, gave rise to the Periodic Table of the Elements – which, though much revised since, underlies modern chemistry. [dream]
Kekulé is said to have discovered the shape of benzene in a day-dream, seeing the Ouroboros snake chasing its own tail [Kekulé]. Whether these visions showed a deep truth to the chemists or whether the moment of sleep and dreams allowed different, less conscious associations and reformulations to occur could be a matter for dispute. Furthermore there is every chance these claims about visions in dreams are simply fables [Baylor]. The tales of inspired dreams are often interwoven with long patches of sleep deprivation, while trying to grapple with a problem. When you are absorbed deeply in a problem it is hard to step back and you do need to give it enough time to be able to hold several of the pieces in your head. Nevertheless, I am certain that stepping away from either the lab bench, or the keyboard, can allow different perspectives to form. Perhaps all workplaces should have camp-beds or comfy chairs installed for a quick nap if you get stuck. Or perhaps you should just go home sometimes, take a holiday or even take a sabbatical if you can.
The term Sabbatical has its roots in the Old Testament, where we are told God takes a rest from Creation on the seventh day, or rather stops, having completed the task. This theme of rest emerges in other places, such as letting fields rest, which is still practised in agriculture, letting the land lie fallow from time to time, partly to stop pests and bugs from building up. It seems academic sabbaticals are frequently taken to finish a piece of work without distractions, rather than as a complete rest. Not all employers allow sabbaticals, though some will allow time for training, such as attending a conference. Perhaps you write code as a hobby rather than professionally, though you should still take time to sit back and relax or reflect. Sometimes a physical change of circumstances can help. Sitting at the same desk can make it hard to let go and find a new viewpoint. Some people manage to find a ‘sacred space’ or ‘(wo)man cave’ to withdraw to. If you can’t find a physical space, then you can step back in other ways, perhaps getting lost in music. For example, Adam Tornhill recently considered the relationship between music and concentration in CVu [Tornhill14].
Sabbaticals are for a specific period of time, be that one day, or a whole year. It can be surprisingly difficult to write a program or solve a difficult problem in a pre-specified time period, or indeed guess in advance how long might be needed. Perhaps one reason people stay too long at work is because either they are ‘in the zone’ or being distracted by various other things that might need dealing with first, or even are stuck and have a looming deadline, so feel staying late and hitting the problem with various hammers might just work. It can be helpful to time box activity, maybe just allowing yourself an hour, to the end of the working day, or the end of a week to do something. It can then be useful to get some feedback. Someone else’s viewpoint will differ to yours. A code review can reveal better ways of doing things and potential problems. Watching someone use your shiny new code can be informative. It might be worth getting continuous feedback as you go, via tests and a continuous integration setup, from colleagues, maybe as you pair program. You could even wire yourself up, to measure what you are really up to. Ed Sykes recently mentioned Quantify Dev [QD] which logs stats on you as a developer, such as build time or if it succeeds or not. The theory is by exploring this data you can find ways to improve. I’m not completely sure I want stats kept on how many browser tabs I have open, or how much time I have spent playing 2048  recently, though a different perspective on how you are developing is always useful.
Perhaps this had been a long-winded way for thanking Ric and owning up that I still have no idea what to write an editorial on. Hopefully I will be in a better position to write one next time.
Overload Journal #121 - June 2014 + Journal Editorial
|Browse in :||
All > Journal Columns > Editorial (178)
Any of these categories - All of these categories