Category Archives: Productivity

Personal Productivity Random Tech

Evading the now

March 24, 2013 – 10:26 am

Ever since I notionally transitioned into adulthood, I’ve always been interested in current events. Not just keeping up with the latest technological developments either, news in general is something I like to keep tabs on. Years ago, you basically had two sources: the fairly superficial summaries from TV news and tabloids, or the more in-depth coverage from broadsheet special reports and dedicated periodicals. Generally speaking you got the superficial once or twice a day, and something more probing every week/month.

The Internet changed everything, including the news. I still believe that change is for the better – I remember what it was like to try to find specialist technical information in the years before Google, and I can’t believe how I managed – but I also think that lots of us don’t manage this tsunami of information availability very well, particular when it comes to its frequency. I think the constant stream of information at all levels of detail has overwhelmed some of us to the extent that we don’t know how to stop looking at it, and this has some knock-on effects for creativity and independent thought.

I started thinking about this because I recently took a 2 week holiday, and for the first time in many, many years I took the opportunity to be completely unavailable for the duration. Anyone who has been self-employed, or simply personally committed to a project to the level that they don’t know how to let go, knows what a huge deal this is. Frankly, I badly needed the proper down time and so did my wife (unfortunately the net effect has actually been to push extra stress on to the surrounding weeks, but at least we could relax for a while). It turned out that the place we stayed had almost non-existent Internet access anyway, so my choice was enforced.

So for 2 weeks we had no Internet, TV, radio, papers, nothing – the world outside may as well have not existed. We just had a bunch of pre-loaded Kindles, iOS devices and notebooks – no twitch-checking Twitter, no news, no daily RSS. At first, it felt isolating. Then, it felt liberating. I found myself feeling much more creative, and being able to think about the ‘long game’ a lot more clearly. It wasn’t that I didn’t care what was going on in the world, or that I had any less of a need overall to keep up with technical developments etc. The point was that I didn’t have to think about it so often – catching up with it in a week would be absolutely fine. Or two weeks. Anything ‘important’ that I missed would get flagged up again anyway, and in the meantime, I found there was much more free space in my daily consciousness, not only for relaxation and enjoyment, but for creativity and strategic thinking too.

Looking back it should be obvious. More quiet time to think has to be better, right? There was also a study recently saying that kids should be allowed to get bored because it makes them more creative, and I bet it works for adults too. I’ve always been a bit contemplative anyway, quite content sitting quietly and just thinking. But without realising, I’d sidelined that almost entirely from my routine – extroverts always had this ‘work hard, play hard’ mantra they lived by, but without realising I’d adhered to an equivalent for introverts – ‘work hard, consume new information obsessively in free time hard’ perhaps. Before the Internet, and more specifically before the ‘velocity’ of the Internet increased via Twitter etc, there were lower frequency rhythms in the way new or topical information became available that naturally paced my consumption and the depth/length of contemplation on each, but once the limits were off I slowly became like an ex-hunger striker at an all you can eat buffet. I didn’t even realise it had happened until I went cold turkey.

So, what next? Obviously I’m not going to stop using Twitter, or reading tech news. But what I am going to do is deliberately unplug regularly for periods of time in future. I think a couple of days at a time is the minimum required to reach the kind of ‘quiet brain’ that seemed to me to be much more cogent and creative than the one I live with most days. A weekend a month perhaps, plus at least one full week a year. It’s a bit like clearing all the crap off your desk once in a while – which come to think of it I should also do more often ;)

Tags , , | Permalink | Comments (3)
Business Development Productivity

What open source taught me about management

September 9, 2012 – 12:00 am

I was a manager of developers in an organisation for a few years, and during that period I learned a lot. But if I’m honest, I learned far more about being a manager from leading a large open source project for 10 years, because that taught me a lot about what makes developers tick. Of course, I’ve always been a developer myself too, but you often don’t think that clearly about your own motivations.

Open source developers are usually volunteers. They choose to spend their own time contributing to your project – maybe they do it as part of paid work or their own projects too, but even then it takes extra effort to contribute back in a meaningful way, since the quickest and hackiest option usually isn’t the one that will be accepted upstream. These guys are going out of their way to help, even though no-one is cutting them a check in return. Crazy? And not only that, they usually defer to project leaders or core team members, changing their contributions or beefing them up based on their suggestions even though they don’t have to. Curious?

‘Meritocracy’ is a word that’s bandied around a lot, but in open source it’s an accurate description; people only listen to your opinion, or accept your direction, because they want to, and trust you enough to respect your decisions. This is a two-way street; the leader essentially builds this trust not only through leading by example, but also by accepting feedback from others, even when it’s conflicting with their own current stance, with good grace and consideration.

Because there’s no strict ‘hiring’ process as such (it’s more of an ‘onion skin’ sort of approach where developers are given increasingly more power as they soak into the community and contribute more), and geographical locations are irrelevant, you often end up with quite rag-tag band of people in an open source project, each with their own strengths and opinions, arguably a more diverse bunch than you’d find inside a single company. This mixture of experiences, ages, cultures and languages can be a challenge sometimes, but it also brings things to the table that could really only occur when you throw this sort of melting pot together. I learned a vast amount about dealing with people just by being exposed to that variety over the years.

But most of all, I learned that motivating smart, creative people can be done entirely for free – you just have to have the right attitude.

A lot of managers seem to believe that carrot and stick techniques coupled with metrics and monitoring are the best way to ensure employee productivity. You can encourage people with salary and benefits, make sure they work hard by applying metrics on time and task completion, have disciplinary proceedings when those goals aren’t met, and so on. You have none of those in open source, and yet great work gets done anyway – by some metrics, projects can be equivalent of millions of dollars of investment. Why does this work?

Well, as it happens, what pushes the buttons of creative people like developers most of all is the work itself, and the experience of doing it. Sure, we all need money; we need to live somewhere, eat, buy expensive shiny gadgets and so on, but actually, the good developers would be (and indeed are) writing software regardless of whether someone paid them to do it. For most good developers, what really matters once they’re comfortable with their financial situation is:

  1. To work on projects they care about
  2. To learn new and interesting things
  3. To have creative control/influence over their work
  4. To be treated like adults and not micromanaged
  5. To be recognised for their work

Open source projects put a big tick in all of these boxes, and that’s why they can be so successful despite there often being no money involved. As a manager, if you concentrate on these 5 things, you’ll increase your chances of attracting good developers – the salary and benefits have to be reasonable too of course, but those 5 will tip the balance.

Of course, rather than ramble on like this I could have just pointed to Maslow’s Hierarchy of Needs; all managers are familiar with that and use it to guide their management style, right? Right?

Tags , , , | Permalink | Comments (11)
Business Personal Productivity

You probably underestimate yourself

June 30, 2012 – 5:07 pm

For the purposes of this post, I’m going to assume that the reader is a relatively normal person, and not a raging egomaniac, or a nihilistic sociopath – investment bankers, you might want to stop reading now ;) .

Still with me? OK. So, I don’t know precisely what you do for a living; given my usual readership you’re quite likely to be a software developer, but I believe this applies pretty universally. I’m willing to bet that you probably assume that other people in your industry are way better than you are. That you look at the big company names, and big celebrities in your industry, and are a bit intimidated by their position, their expertise, and their track record. You might have the impression that because of the resources and experience these people / companies have, and perhaps the infinitely more ‘suitable’ location they live in, there’s no chance you could ever compete with them.

If so, I’m pleased to be able to tell you: you’re wrong.

Here’s a personal story. I grew up on a tiny island that in my early youth was based largely on horticulture, and then later morphed into a financial services centre. Neither of these professions interested me in the slightest. Software companies just don’t come from here, unless they service the local finance industry, or so the wisdom goes. The assumption regularly made by people both within the island and outside it, is that the only way to obtain real expertise is to bring it in from outside, because what expertise could you possibly expect to find in a small population in the back-end of nowhere anyway?

In this environment, a few of us grew up and found we wanted to be software developers, but we generally assumed we weren’t that good, at least in the grand scheme of things. Maybe we could impress each other, but surely that wouldn’t wash outside the island. Some of us tried to address that by working twice as hard, and learning as much as we could, from anywhere that we could, assuming all the time that we were basically regional hillbillies struggling to catch up with the far more sophisticated outside world. Maybe if we worked really hard, we might just be good enough to get an entry-level position or something, and then learn all the really smart stuff that everyone in the rest of the world must be doing that we had no idea about.

As time went on, through one means or another we started to interact more with the outside world. There were joint projects with global teams, the Internet opened things up and open source projects were joined and even started, and some even worked with/for these big-named companies in fabled places like Silicon Valley. And guess what we found, much to our surprise?

The range of ability was exactly the same in these places as it was in our tiny ‘backwards’  island. Sure, there were more people, leading to more companies and more positions, but the ability scale was occupied in broadly the same proportions. The people we thought were great developers just in the context of our island were still great developers on the world stage, even in centres of excellence. Projects we worked on ended up being highly respected by people far outside these shores. We competed, and were surprised to win sometimes. And yet we came from the middle of nowhere, in tech industry terms.

We made the classic mistake of assuming that we were worse than the competition, just because we weren’t based in these larger, more famous places. That assumption had some positive effects – making us work harder for it – but also some negative effects too, such as making us rule out a lot of options unnecessarily. In fact the playing field was a lot more level than we thought it was.

There are other examples too. I spotted a quote from Dame Mary Perkins of local company Specsavers in our local paper a few days ago, when she talked about their experience of setting up in Melbourne. She said that they’d thought there would be 4 million people’s worth of skills and qualifications, but in fact the people were no better than the people they found back home in Guernsey. Scale really doesn’t matter very much.

And again, in a recent interview Bradley Wiggins, current favourite of the Tour de France, he illustrated his surprise at his position: “kids from Kilburn are expected to be postmen, milkmen or work in Ladbrokes”.

So, you almost certainly underestimate yourself, and you probably overestimate other people / companies too. Often the hardest thing about doing something outside the norm (for your environment) is believing that it’s possible in the first place. Get over that, and pretty much anything is achievable if you put your mind to it.

Tags , , | Permalink | Comments (6)
Business Open Source Productivity

Oh no, not a ‘Best of’ collection?

May 2, 2012 – 12:21 pm

Well, yes – and my apologies if you’ve already seen these.  In celebration of the new blog and before I’ve polished any new entries for it – I often write & refine my posts over several sessions, I find the content is better that way – I thought I’d flag up three posts from this blog that I’m particularly satisfied with, and that I think resonated well with people.

  1. Work 2.0 – the interruptible programmer
  2. How to make decisions
  3. My evolving view of open source licenses

Hope you enjoy!

Tags , , , , | Permalink | Comment (0)
Personal Productivity Random

No Excuses

May 9, 2011 – 6:22 pm

Perhaps there’s a small risk of someone starting a file on me for saying this, but I’m willing to be we all have voices in our heads. I don’t mean the type which whisper murderous thoughts or paranoid conspiracy theories (if you have those, this blog really isn’t an adequate place for you to obtain consultation), but some kind of internal dialogue we have with ourselves, often to justify the decisions we take, or don’t take.

One of the things that voice in our head often does is provide us with excuses. Maybe you have a project which you keep saying you want to start, but you “don’t have time” (probably the most common excuse for everything), or maybe you want to change jobs completely but “I can’t throw my career away”, or “I don’t have the training”. People in corporate IT departments are especially good at excuses – trying that new platform / environment is “too risky” or allowing the CEO to use the device he wants to use would “break corporate standards” or “risk network security”. Maybe that customer or employee has a great idea for a new service or change in approach, but it’s “too hard to get there from here”, or “would probably cost too much”.

Very often, excuses are just people building a natural safety buffer about themselves to avoid having to deal with something that’s a little bit scary, difficult or unknown. If you tell yourself (or other people) that there’s some considered reason or analytical risk which stops you from going out on that limb, for taking a bit of risk, then that’s a comfy position to leave yourself in. It’s not you making the decision to resist taking that step, it’s an unavoidable environmental factor. A global immutable constant. It’s comforting to think about it like that, because then it’s not your fault that another year passed and you feel like it’s a re-run of the one before.

We’re all complex and I’m not going to tell you what’s right or wrong for you, but here’s my experience: taking a few risks, trying new things, embarking on something when you have no idea where it will take you – these are all good things, and you do yourself a disservice by avoiding them. Now, I’m not a huge risk taker, I’m not high-rolling in Vegas or blagging my way into risky business ventures or anything, but I recognise that taking some considered risks, and putting yourself outside of your comfort zone, is necessary to get anywhere – something that I’ve come to appreciate a lot in the last few years particularly. Besides, it’s almost never as bad as you imagine, and having taken the plunge you might be surprised how well you can figure stuff out as you go along.

So when I find myself coming up with a list of reasons why I can’t do something, I find it useful to roll out a simple mental phrase: ‘No Excuses’ . For added effect, imagine it’s being boomed out by James Earl Jones, who is staring down at you with that intense, serious gaze of his – there’s just no bullsh*tting him ;) . There’s a decent chance that some or perhaps all of those things that you think are impediments are really just excuses – and you’re really better off without them. No excuses, just try it – what’s the worst that could happen?

Permalink | Comments (5)
Business Personal Productivity

How to make decisions

April 21, 2011 – 5:19 pm

Decisions are hard. Well ok, not all decisions are hard – given the choice of whether or not to receive a swift kick to the gentleman’s area, most of us would politely decline without having to give it much thought. So let’s rephrase – making an important decision for which there is no clear optimal answer is hard. And yet, making these kinds of decisions, in a theoretically unbounded possibility space with uncertain and/or unknown variables, is the one thing we humans still do considerably better than machines, and it forms the basis of pretty much every important event in our lives – who your partner is, what you do for a living, what projects you work on, what your hobbies are, where you live, and so on.

The thing is, in the developed world in particular, our options are almost limitless – in practice we have very few real constraints on what we choose to to, barring a few fairly sensible laws. Barring a small number of hard factors, such as poverty, discrimination, and oppression (which should be fought wherever they are found), the only limits to most people’s decision making are those which they impose on themselves, resulting in a large number of options. This is a good thing, but it does make decision making complicated. How on earth do you sift through all those alternatives?

Opportunity Cost

Understanding the concept of opportunity cost is vital to any decision making process. It’s just as important to consider what you won’t be doing as a result of a choice, as what you will be doing. Picking contract project A might mean you don’t have time for personal project B, taking that corporate job might mean you can’t dedicate time to developing that business idea you have, and so on. For a while, I tried to defy the reality of opportunity cost by ‘cheating’ – I would do multiple things at once, and just put in very long hours. I worked on projects in my spare time while being employed, I would multi-task between many projects (contract, open-source and personal). That works to a degree, but it’s important to realise two things:

  1. There’s a limit on how long you can burn the candle at both ends.
    I speak from experience here, burn-out and work/stress related health problems are very real, whatever you might think as a young, healthy, workaholic programmer. You can work 12-16 hour days for a while, but eventually you’re going to have to stop, or something will make you stop. If you need to do it to bootstrap, fine, but always remember the clock is ticking – plan for that.
  2. The more you divide your time, the less efficient / productive you will become.
    If you spend 10 hours a week on each of 4 projects, in 4 weeks you will have done a weeks worth of work on each, right? Wrong. In fact, you’d probably be lucky to get half that. The more you divide yourself, the less you’re going to get done on each thing, just because of a lack of focus and a need to keep context-switching.

So, my message here is that you can’t cheat opportunity cost – things conflict, and it’s best to not to pretend that they don’t. This should not only inform your decision process, but it should also bring it into sharper focus – accepting that you can’t have your cake and eat it means you’re less likely to let yourself wiggle out of making an actual either/or decision when really it’s there.

Evaluating the options

The logical person’s approach to evaluating their options tends be be analytical, gathering as much information about each option in front of them, and quantifying each of the pros and cons, risks and opportunities, and so on. This is fine, as a starting point, and teases out a lot of fundamental ‘hard’ information that you need to have available. But in my experience the best you can hope for from this kind of process is that you will eliminate the outliers; those cases which will never work, or which you definitely don’t want to do (although it’s of course worth making sure you understand your own assumptions and biases here), leaving you with a pool of ‘maybe’ options. It  won’t, in any non-trivial decision space, provide you with an absolute dead-cert answer; or if it does, you probably haven’t considered enough alternatives ;)

The simple reason for this is that for any significant decision there are bound to be many factors and variables which are unknown, poorly quantifiable, subjective, or incomparable with each other. There won’t be some magical formula which you can plug all the variables into and come out with a single best answer, nor will the factors usually be clear enough even for you to rank them in any sort of objective order – or if you can establish a discrete ranking, it probably just means you’ve identified some more to discard, or you’re kidding yourself.

Making the decision

OK, so assuming you’re now left with a bunch of ‘maybe’ options, all of which have many uncertainties and incomparable pros and cons. How do you make that decision? You’re probably going to think this is a cop-out, but here’s my personal answer; sleep on it, and then follow your gut. Seriously, forget the analysis, and turn off your brain; it’s already contributed as much as it’s capable of doing in the previous step. Hard as it may be, particularly if you’re a naturally logical, analytical person, there are some things that simply cannot be analysed and quantified. Probably any of the remaining options in your list are good (or if this a case of choosing the lesser of N evils, equally bad) – so going with the one that you have an emotional attachment with is usually the right one, because that’s the one you’ll fight hardest for when things get tough. Which they probably will at some point, right? Never underestimate the power of emotional attachment and enthusiasm to the success of any endeavour when things get difficult. You can’t engineer this kind of affinity, and your gut will tell you when it’s there, more reliably than any checklist can ever hope to do.

Living with it

While it’s important to be nimble in many respects (in business, you can’t sit still and periodic course corrections are essential), you do need to give any decision a fighting chance to develop before you change tack. Try not to second-guess yourself too much in the early stages – it’s hard, and this is something I struggle with all the time, but it’s ultimately counter-productive in the shorter term. By all means it’s important to reflect periodically and learn from what worked and what didn’t, using that experience to influence your future decisions, but equally for your own sanity you have to be able to drive a metaphorical stake into the ground representing a decision you make, and only look forward from that point, for long enough to see what happens, for better or worse. Glancing over your shoulder from the outset wondering if you made the right decision is never helpful and is likely to undermine what you’re doing.

Conclusion

So, that’s my 2 cents on the decision making process. Thanks to @GeekAndDad for triggering me to finish the half-written post I had on this subject :)

Permalink | Comments (10)
Development Personal Productivity

Work 2.0 – the interruptible programmer

September 4, 2010 – 12:25 pm

I’m 37, and I’ve been a (professional) developer for 16 years. You would have thought that in that time, I’d have figured out an effective work style which delivered the desired outcomes (code cut, products shipped etc) without causing detrimental knock-on effects – but, sadly, you’d be wrong. I think the style in which I practiced my craft for the first 15 years of my career was much the same as every other enthusiastic developer: you put a ton of hours in. 12-16+ hour days, evening and weekend coding marathons, pizza in the keyboard, crunch times, 3am debugging sessions where you just can’t go to bed because you can feel the source of that bug just beyond your fingertips, dammit, desperate last-minute sprints to deadlines where you manage to slot that last piece in, Jack Bauer-like, just before the world goes to hell. If you’re in the demographic I’m talking about, you’re nodding sagely, and probably grinning a little too, reminiscing on past trials and glories. This sort of crazy dedication is respected in our circles, and is pretty much expected of any developer who has claimed to earn their stripes.

But, it turns out this kind of thing is not good for your health – who knew? Those of you who know me or keep up with my blog know that I’ve been dragged kicking and screaming away from my old ways, because of back issues that I initially ignored, then tried to cope with using token accommodations, and finally succumbed to in a big way. Being self-employed, this was a major problem. Crawling out of the pit I dug for myself took a long time and a lot of frustration – I read quite a few productivity books on the subject to try to find answers on how to keep working, and in the end found that the answers you mould for yourself tend to be the best ones. I’d like to share one of the things I learned along the way.

But I’m ‘In The Zone’!!

So, I want to talk about the biggest problem I encountered: concentration periods. I can’t sit at a desk for longer than about an hour at a time now; if I don’t get up and walk around, do some gentle stretching etc, at least this often, I’ll pay for it badly once I do move, and probably over the next few days too. I also can’t realistically work more than a standard 8 hour day without pain any more. The problem with this was that, as a programmer, the style which I developed over 15+ years involved getting gradually ‘Into The Zone’ and coding for very long periods at a time, uninterrupted. This is a common theme among coders, who like to shut themselves away for hours at a time, wear headphones to avoid distractions, have ‘quiet times’ and so on – and it’s also why we tend to react really badly when interrupted. Programming requires concentration, and concentration seems to run on a valve system – it takes time to warm up, and once it’s going, you don’t want to turn it off because starting it up again is a major hassle.

I thought there was no way around this, and had begun to resign myself to just being less productive because of it. However, over the last 6  months in particular, I’ve discovered that, far from being an intractable problem, this ‘slow warm up, long uninterrupted focus time’ approach is to a large degree a learned behaviour, and it’s possible to re-train yourself to cope with things differently. It’s a little like when people learn to adopt polyphasic sleep patterns – it’s not that you can’t do it, it’s just that when you’ve become accustomed to doing things a certain way, changing that is initially very, very hard. But it’s not impossible, given the right amount of motivation and time to adjust.

So, my goal was to acclimatise myself to many shorter work chunks during the day instead of a few very large ones, while still maintaining productivity. The key to this was to learn how to get back ‘In The Zone’ in the shortest time possible – much like the way polyphasic sleepers train themselves to achieve REM sleep more quickly. I’m mostly there now, or at least way better at it than I was, so, what techniques did I use to make this transition?

  1. Embrace interruptions
    This is less of a technique and more of a deliberate psychological adjustment which cuts across all the practical approaches I’ll cover next. Instead of being the typical coder who avoids interruptions at all costs, you need to accept them, and learn to manage them better. It’s hard – you have to try to set aside years of resisting interruptions and initially, until you adjust, you’ll feel like you can’t get enough done. Many people will probably want to give up, unless there’s something specific motivating them to push through it – for me, daily pain was a great motivator. My main message here is that the transition is just a phase, and that it is possible to be an interruptable programmer who still gets things done. But you have to learn not to fight against it, hence why this is the first point.
  2. Maintain context outside of your head at all times
    Much of the problem with interruptions is that of losing context. When you’re in that Zone, you’re juggling a whole bunch of context in your head, adjusting it on the fly, and maintaining and tweaking connections between issues constantly. Interruptions make you drop all that, and it takes time to pick it all up again. My answer to this was to externalise as much as possible, on as many levels as possible:

    1. Maintain a running commentary on your current task
      I am my very own chronicler.       I write notes on what I’m doing all the time, whether it’s adding a comment line to a ticket, committing frequently and writing detailed commit notes (you do use a DVCS to make light commits more practical, right? ;) ) scribbling a drawing on (ordered) pieces of paper. This really isn’t that onerous, and in fact externalising your thoughts can often help you clarify them. Basically the guide is that roughly every 30 minutes, I should have generated some new piece of context which is stored somewhere other than my head. If I haven’t, then that’s context I’d have more trouble re-building mentally if I’m interrupted. It doesn’t take much time to do, and it has other benefits too such as recording your thought & decision process.
    2. Ruthlessly ignore tangental issues
      You might have noticed that in the last bullet, I used the words ‘current task’, singular. Not ‘tasks’. There is no such thing as having more than one ‘current task’ – there is only the one task you’re actually working on, and distractions.
      We probably all use bug trackers / ticket systems to track bugs and feature requests, but when you’re working on a ticket, it’s very common to spot a new bug, or identify an opportunity for improvement, or think of a cool new feature. How many of us go ahead and deal with that right away, because it’s in the area we’re already in, or it’s ‘trivial’, or it’s a cool idea that you want to try right now?  I know I did – but I don’t any more; any tangental issues not related to what I’m currently doing get dumped into the ticket system and immediately forgotten until I’m done with the current task, regardless of their size, relevance or priority. It sounds simple and obvious, and this might even be official procedure in your organisation, but I challenge most coders to say that they actually do this all the time. The benefit is that even the tiniest of distractions add an extra level of context that you have to maintain, which is then harder to pick up again after an interruption.
      For this to work, you need a ticket system which is fast, lightweight, and doesn’t require you to be anal about how much detail you put in initially. You need to be in & out of there in 30 seconds so you can offload that thought without getting distracted – you can flesh it out later.
    3. Always know what you’re doing next
      This is one from GTD (‘Next actions’), but it’s a good one. When you come back from a break or interruption, you should spend no time at all figuring out what you need to be doing next. Your ticket system will help you here, and so will the running commentary that hopefully you’ve been keeping on your active task. If you’ve been forced to switch gears or projects, so long as you’ve maintained this external context universally, you should have no issue knowing what the next actions on each item are. The important thing is to have one next action on each project. If you have several, you’ll have to spend time choosing between them, and that’s wasted time (see the next section on prioritisation). At any one time, you should not only have just one current task, but one unambiguous next action on that task. Half the problem of working effectively is knowing what you’re doing next.
  3. Prioritise Negatively
    I mentioned next actions in the previous section, but how do you decide what comes next? A lot of time can be frittered away agonising over priorities, and I used to struggle with it; I would plan on the assumption that I wanted to do everything on the list, and I just needed to figure out which I needed to do first. I discovered that I could cut the amount of time I spent on planning, and also get better, less ambiguous priorities by inverting the decision making process – to assume a baseline that I wouldn’t do any of the tasks, and assessing the negative outcomes of not doing each one. So instead of ‘which of feature A or B is more important to have?’, it became ‘Let’s assume we ship without feature A and B. What are the issues caused by omitting them in each case?’. It might appear to be a subtle difference, but having to justify inclusion entirely, rather than trying to establish a relative ordering assuming they all get done eventually, tends to tease out more frank evaluations in my experience.
  4. Recognise the benefits of breaks
    Much of the above is about limiting the negative aspects of taking breaks, but the fact is, that they have many work-related benefits too. I’m willing to bet that all coders have stayed late at work, or late into the night, trying to fix a problem, only to find that they fix it within 15 minutes the next day, or think of the answer in some unlikely place like the shower. The reason for this is very simple – extended periods of concentration seem productive, and can be on operational / sequential thinking, but for anything else such as creative thinking or problem solving, it’s very often exactly the opposite. Not only do tired minds think less clearly, but often the answer to a problem lies not in more extensive thinking down the current path which you’ve been exploring in vain for the last few hours, but in looking at the problem from a completely different perspective. Long periods of concentration tend to ‘lock in’ current trains of thought, making inspiration and strokes of genius all too rare. Creativity always happens when you’re not trying, and it’s an often under-appreciated but vital element of the programming toolbox. Interrupting that train of thought can actually be a very good thing indeed.

There’s more I could talk about, but that’s quite enough for now I think. I hope someone finds this interesting or useful :)

Tags , , , , , | Permalink | Comments (88)