Monday, February 8, 2010

Your Work Buddy Really Helps

Working for long stretches on your own has a few pitfalls, a few challenges and several benefits.

The benefits are obvious - no interruptions, intellectual freedom, total ownership of successes (and failures) and flexibility in work methods.

The challenges are pretty easy to figure out as well - but if you haven't done a large project on your own, some of this might be new.

Motivation can be an issue - just getting the initiative to start the day. Focus can also be a challenge - it's not hard to get distracted by interesting little things along the way and find yourself miles from where you were headed (can anyone say Twitter?). Thirdly, there's the challenge of planning and finding the right amount of planning. It's tempting to form a rough idea of a direction in your mind then pursue it without writing anything down. When you don't need to explain to anyone, it might seem a reasonable path forward. But then you'll find, it's easy to forget (or mis-remember) the chosen path, weeks after you decided on one.

On the pitfalls front, mistakes are less easy to find when your work doesn't have to 'plug in' to someone else's work. As well, our brains are much more happy working 'multi-modally.' That is, not working only in internalized mode, but in others such as speech, written words, images, diagrams. All these other modes of operation allow our memories to be better 'cross-linked,' making our memory and learning more resilient, recallable and less prone to errors. We naturally get these multi-modal crosslinks when we work in teams. We write and publish documents that are shared. We talk in person or on a phone. We stand around and sketch diagrams on white-boards. All these things strengthen our vision of what we are doing, where we are going.

An invaluable tip for managing the work-alone situation is to build in a work-buddy system using simple electronic tools. When your project involves computer work, and you are on the machine all the time anyway, a blog or even a simple text file is a good means to invoke a virtual work-buddy to help you along.

More casual than a workplan, less onerous than a formalized logbook, a work-buddy log can keep you on track, focussed and maintain some continuity from one day to the next.

I don't find it so useful in long term planning. A small, more formal document is still better for that from my experience. Setting long term goals still seems to benefit from gantt-chart-like tools where you can visualize concurrent tasks, and linkages. But for the near- to mid-term, I've worked well with this work-buddy log approach.

Style and Structure.

The most important part of the blog is establishing a simple structure, but simplicity is key. If there are more than four or five elements to the structure, you'll forget them. So what I use is

  1. Dates - they are the backbone of the whole system. So making them standout is important. I use a double underline, because some of logging is done in a text only file (for rapid access). On my online (but private) 'blog' based Work-Buddy log I let the system do the dating for me, so I can concentrate on the rest.
  2. Plans. I make numbered short plan lists whenever I can think of two or more things I should be doing, then I hammer away at that list.
  3. Bugs - I log any bug in my development work with an all-caps BUG: tag so that I can easily find them again.
  4. To-do's - I log any thing I should remember to do, but don't need to do right away, with a TODO: tag. Again, I can find those easy.
  5. Finally, accomplishments. I start lines that highlight an accomplishment with a text arrow '->;' This is a minor but important thing.  It may sound silly but typing that arrow becomes a kind of 'reward' for completion of an item. E.g. a bug fix, a listed goal or a todo item.

With those elements I manage to create a structured place where I can describe my thinking process and work through details of how to move forward. Often, I find that just articulating the makeup of a problem in conversational-toned writing will lead you to a solution.

I get excellent continuity between work sessions by wrapping up my days with a "First thing tomorrow..." instruction to myself.   It's sometimes hard to recall where your mind was as you wrapped up the day, and a verbose instruction about where you want to start your day is very helpful.

My comment about a 'text-only' file is worth highlighting. While in a development environment, I'm working with text files that are computer code, thus having a text-only file in which I'm logging my progress and thoughts is a very easy, light-weight way to keep up the work-buddy system. If I had to switch to another application, or a browser to log things, it might just put enough of an impediment in my path that I wouldn't do it.  Plus a document with fancy titling, styles, margins etc might also be enough of a deterrent. Let alone opening a large behemoth like applications (hello MS Word) before you can start logging.

When working on other things (e.g. web-based projects), I do use the browser based blogging approach.  In a tabbed browser, it's very easy to have one of those tabs be an open blogger session.   A blogging account set to private (so you're not sharing your detailled design details with everyone) is a good way forward.  For some, privacy might not be an issue, and getting occasional comments on your thoughts might prove fruitful (or distracting!).

Which ever way you approach it, the ability to review your recent thoughts, or solidify thoughts enough that you both retain and apply some rigour to them is a very helpful tool when working on large projects by yourself.

Researchinator turns to the work-buddy to see where we left off...

Thursday, February 4, 2010

General Progress

A busy week, with a consulting engagement on one hand, and integrating new features into my desktop code going on simultaneously. On the consultation side, I'm providing review and critique services on funding proposals. The usual challenges there always flummox me. While I meticulously craft my proposals and ensure no questions are left unanswered in my own work, I continue to see people applying for big government bucks who can't be bothered to fill out their proposal to the guidelines. They leave entire sections empty never acknowledge that their might be competitors and don't understand simple concepts like "intellectual property." One applicant seemed to think that IP meant ability of their team to read and think deep thoughts.

On the app side of things, I'm in the midst of a crash-fest with multi-threaded UI control just now. I'm reasonably confident that I'll be able to wrestle this to the ground, but I'd really like to put the development to bed with something stable and roughly competent at meeting design intent so that I can turn the money-chase back on. It feels tantalizingly close, but then it has for about 8wks.

I suspect I need to peg a new date in spring sometime to make some tough decisions, for now though, the intellectual tension is somewhat rewarding and the progress is certainly nice.

Researchinator out...