How This Technologist Complicates GTD

August 15, 2012 by Leave a Comment

I’m a GTD kind of guy. But, I got “into” GTD for the complete wrong reasons. I like pens and paper, paperclips, new notebooks, bags, toys, and shit. I like processes and systems and the idea of productivity and efficiency. I re-listened to one of my favorite MoM episodes The Awkward Journey To GTD and began to think of my own journey (that is far, far from over).

Here is my short account.

The problem

I re-started college in 2007 after a 4 year “break” where I needed to “find myself” and quickly found that working a little more than part time, commuting 2 hours a day to school (in the northwest Pennsylvania snow belt) and managing a full time course load seemed like too much.

Being into pens and paper, new notebooks, and toys and shit, I started searching for something that could help me get over the dread of having too much work and not enough time to do it. I stumbled onto Merlin Mann, Cal Newport, Leo Babauta, Lifehack, Lifehacker, and other lifehackery types of things.

The beginning of the solution and my fiddliness

Being into all of the toys and systems and shit that surround GTD I fell down the rabbit hole of creating the most awesome Hipster PDA while following this insane workflow (don’t read it!), using it until I switched to Blackberry and Outlook tasks, moving to tools like Remember the Milk, going back to paper with DIY Planner, getting a Mac and switching to OmniFocus, getting pissed that I couldn’t use OmniFocus on a Windows machine at work and school and writing up my workflow on how to use Toodledo for GTD, using just my iPad and iPhone with OmniFocus, move to Things to try out their wicked fast and wicked late cloud sync, and now back to OmniFocus. If you want to see my toolset for this year, you can see it here.

It was a journey to say the least. I got a lot done in that time like graduating from college, got married, got two puppies, a kitty, and a fish, wrote in my spare time for an Android site and now for Lifehack, made some good friends, went from a software engineer to IT manager of a company. But, all this fiddliness is still with me and leading me down the same rabbit holes that I don’t want to go down anymore.

Complicating the simple

GTD is a really simple process; we just tend to complicate it and clog ourselves up with tools and processes. I do this with everything though.

There is something else I learned about software development over the last few months that I can apply to my GTD process (and my life process). Developing software isn’t the reason you develop software; you do it to solve problems. So, if I can solve a problem with a simple, technical solution, that’s what I need to aim for.

GTD is a simple solution for a complex problem. No need to complicate it any more with added processes, analyzation of what contexts to use, how to best organize your projects, etc. We techie types lovvvee to complicate the simple and use new shiny toys and shit.

There is also no need to follow GTD to a “T” and implement every last detail that David Allen suggests. And that is coming from a guy with a GTD Notetaker Wallet and a schedule weekly review on his calendar ;)

Moving on

When I have figured out the best way to organize a complicated process like retiring two servers from an active Active Directory environment with 80+ users but can’t seem to “remember” to pay my cable bill, I’m not GTDing correctly. The overcomplicating of GTD over the years has slowly eroded my belief in it working for me 100% of the time. I have a hard time trusting my system when I don’t believe it works. But, the reality that I have come to is this: GTD doesn’t make my life complicated; I make my life complicated by complicating GTD.

If you can relate to this, it’s time to step back, utilize your current tools and processes, get out of your own way, and simply get things done.

Filed Under: Productivity Tagged With: , , , , ,

When Analog Tools are OK

August 13, 2012 by 2 Comments

Just because you are into technology and want to be as efficient as possible, that doesn’t mean that you can’t use “Luddite” tools to get some stuff done.

I am in front of a computer all day and have an iPad or iPhone at my disposal almost 100% of the time. You can call it “too connected” if you’d like (and there definitely are some truths to that), but it’s the way I tend to live.

So many uses

Digital tools have enabled us to get more things done and to continually get them done faster. For instance, I have a small program at work that can search for a string of text in our Enterprise Resource Planning software and change it to whatever we want. Just a few months earlier they were doing this all by “hand”, that is, going in to each record and manually updating it to the new text. Not only was this slow, it was error prone as well.

And just think, before the ERP system was there, someone would have had to do that by hand again.

Obviously, not using a digital tool or process to make these updates is stupid and time consuming.

Except for these

But, there are many processes and and workflows where Not using an analog tool may be stupid and time consuming. Here are just a few:

  1. Brainstorming

    I’ve tried so many digital mind mapping tools and other brainstorming techniques. If you can show me that there is a digital tool that does brainstorming better and faster than a pen and paper or marker and wipe off board, I will buy you lunch (no, I won’t). Using analog tools to brainstorm and get down ideas is natural. Instead of figuring out the best way to use the tool, you just write.

  2. On the fly explanation

    While developing a new system, starting a new business, or just working with someone on something complicated, it’s important to be able to explain things naturally and on the fly. Pen and paper are great for this as well. You can draw relationships between things, point out small nuances, or even rip the paper apart and start over.

    I keep a large pad of paper on my desk. When people come in and work with me, we use that pad like crazy. It’s simple and effective and helps us get things done.

  3. Day planning

    I am an avid OmniFocus, Evernote, and other digital productivity tool user, but when it comes to daily planning, paper is a great tool. There are a lot of great tools out there that are pre-made (like the Emergent Task Planner), but a blank piece of paper and your own format works just as good as anything else.

    Tools like OmniFocus and others that store projects, actions, due dates, notes, etc. are important for the shear fact of being able to search and “shuck and jive” your input around. But, daily planning can be a nice break from that where an analog tool can give you some clarity.

Just because I’m into tech tools and processes doens’t mean that I think analog and paper tools are useless. Both digital and analog serve their own purpose. It’s up to you to find exactly how either fit into your workflow and make your more effective.

Filed Under: Productivity Tagged With: , , , , ,

How I Plan Projects

May 6, 2012 by Leave a Comment

Planning a project is a creative and intuitive endeavor. It requires that you have way more ideas than you will ever use and that you aren’t hard on yourself for coming up with something that could be perceived as “stupid”. You have to be able to “give yourself a break” and become an idea generating machine to ensure that you are planning for everything you need to get done in your project.

You then need to be able to organize the information into tasks in an intelligent way.

I follow a loose “Natural Planning Model” offered by Mr. David Allen. Here’s how it goes.

Creating the vision

The reason that you have a project in the first place is because there is more than one task to complete between point A and point B. That is, your current state is not the state that you wish it were in. You have things to do.

You can’t know where a project is supposed to end up without knowing of what done looks like. That’s why I make my project something highly doable. I then envision what it would look like when the project is done and what the definition success would be.

For example, for an upcoming project of getting new all-season tires for my car, the project title would be:

“Install new all-season tires on the Solara”

and my vision of success would look something like:

“Ensure that my new tires are installed on my car and that my winter tires are put away securely until next winter.”

I store the project title as a new project in OmniFocus and the vision of success as the project’s note.

Creating the mind map

This is where your creative side comes into play. Mindmapping is an excellent way to let your ideas flow naturally and gives you the ability to account for everything related to a project. I personally use MindNode Pro for my Mac. I copy the title of the project from OmniFocus and make that the base node of the MindMap as well as what the mindmap will be saved as.

I think start adding nodes for anything I can think of that is related to the project. I don’t worry about order or context at this time. Just whatever comes to mind like:

  • Order tires on TireRack
  • Look at the tire recommendations form Efficise and decide which to purchase
  • Make sure that you have plastic bags to store winter tires in
  • Make an appointment with Monro

You get the idea.

Creating the outline

After I have a ton of ideas and potential actions I start to group them by “sub-project” in the mindmap. I then transfer them to the OmniFocus project by exporting the MindNode file to OPML, opening in OmniOutliner Pro and then dragging tasks from OmniOutlinter to OmniFocus (this workflow needs a little work still).

After moving them to OmniFocus I then decide which tasks are parallel and which have to be cone in order. I give them a context in good GTD fashion and possibly start dates and due dates for time sensitive tasks and project milestones.

Acting

Once my project is outlined then my overarching OmniFocus system provides me with the tasks that I need to see at the right times. If there are important tasks in the project then I see them show up in my “core” perspective through the day. If they aren’t important for that day, I will then see them in my available tasks in the certain context that I work in when I move to the “less important” tasks of the day.

I then do the tasks. Rocket science. I know.

Adjustments

It’s inevitable that you will have to change some things in your project as it moves forward. That’s where my weekly (sometimes bi-weekly) reviews come in. If I see something fishy in my project during my review, like a stalled task, complete tasks, hidden tasks (damn you, OmniFocus!), or anything else, I take care of it during the review.

And that’s it. I try to spend way more time “doing” then “planning”. That’s important.

Filed Under: Productivity Tagged With: , , ,

Becoming a Better Software Engineer 3: Know Your Productive Times

January 7, 2012 by Leave a Comment

I subscribe to the GTD methodology of project planning/tracking and life management, and while GTD is great for keeping all of your “stuff” in work and life under control, it does sort of fall by the way side when it comes to planning your day around your most powerful times.

A good book about the concept about knowing when you have the most energy as well as how to create it is The Power of Full Engagement by Jim Loehr and Tony Schwartz. This book explains that time isn’t the key to productivity; it is understanding and exploiting when you have the most energy. The problem with the software development field, especially that of a normal corporate setting, is that technologists are expected to get their coding done between a certain set time. That may be fine for some, but for many these aren’t their productive times. Especially some developers that rely on late nights and caffeine.

So what to do?

You have to find your most productive times as a developer. Not only the times that are good for actual coding, but the times that are the best for design, bug tracking, bug fixing, documentation, meeting and brainstorming with users, and, if you have to deal with it, mind-numbing paperwork. For me, there is no one time that is good for any of these, and I have to make sure that I split them up during my day to use my energy for each type of work specifically.

How to do it

Are you better at coding in the morning? Late at night? What’s the best time for creating documentation of your code? You have to find when you are energized for different types of of development work.

The best way to do this is simply to keep a log of your days. Do this for a week. Basically just make a list of the tasks that you have done, the time of day, what your energy level was, and how you felt doing it. I tend to just say I have “low” or “high” energy (binary is always better). You can then take a look at this data at the end of the week to help you decide when your best times for certain tasks are.

The next step is to take this new found data (boy, is it valuable!) and block out times on your calendar that coincide with the times where you have the most energy to get certain types of tasks done. This may be difficult, especially when you can’t or don’t make your own hours, but you can at least start to create a framework for using your energy to develop and do technical work more efficiently.

Why do it?

Knowing your productive times to get your technical work done not only helps you get more done, it allows you to get it done with the least amount of effort, freeing up even more energy to create new and better software or ideas related to current projects. Rather than force yourself to get something done, especially during a time of day or night that you don’t want to do it, it’s much better to put a little investigation time in to see when the best moment of your day is.

[Photo credit: Danemusic via flickr (CC BY-NC-SA 2.0)]

Filed Under: Productivity Tagged With: , ,