My quest for productivity

My struggle to implement a working productivity system is summarized by the following image.

It shows my progress in David Allen's "Getting things done" after several months. No matter how hard I try I have been unable to bring myself to any of the necessary habits. I believe that the system works. I have just been unable to motivate myself enough for the changes required.

I believe that my failure to adhere to the "gospel" is caused by a lack of need. Through all my life I have tried to improve my own productivity always with little or no results.

This have never caused any issues since I have been lucky enough to have worked with small and well-defined projects. Even though I was involved in some extracurricular activities during my school years. None of them have been taxing enough to force me to improve my productivity. And the story continues in my post university years.

• I work with little or no pressing need for long term plans.
• I live close enough to both the store and work to not have to manage my commute.
• My side projects have been small enough in scope to not disturb my work.
• I seldom plan my leisure activities ahead of time.

All this have held me back in my quest to improve my own productivity. But recent developments in my life (I've become a father) have forced me to rethink my efforts.

Now I will have to manage my time to be able to both be a dad and continue to learn new things. To get myself on the right track I have decided to start with one system and a tool.

Zen To Done which is a twist of the GTD system focusing on a limited set of habit changes. Hopefully it will be easier to get started with this system. It focuses on making small  changes instead of the massive overhaul that GTD preaches. The system also seems to shift focus from capturing to doing. The adaptations seems to have made GTD accessible and useful for "normal" people.

Bullet journal which is a structured way of keeping tabs on daily activities and events.
Previously I have been able to implement and maintain a bullet journal for short hectic periods but I have never been able to stick with it when things cool down.
One of the major issues for me have been a desire to separate work events from daily life events.
This constant shifting makes it hard to trust the capture tool which in turn leads to a loss of focus.

One of the major issues I have faced in trying to implement these systems is the "capture" step.
I am having trouble finding a stylish and convenient way of making sure that I always carry my capture tool.
My dress-code at work is probably considered formal for Norway but it is business-casual in the rest of the world.
This together with the fact that I have no need to carry anything to work creates an issue when I want to carry a notebook around.

I am stuck in the grey-zone between being formal enough to wear a suit (which would facilitate a notebook) and being casual enough to have pants equipped with large pockets. To get around this issue I have decided to take the advice
of The Goldman Sachs Unofficial guide to being a man, especially advise number 3.

“Rebel from business casual. Burn your khakis and wear a suit or jeans.”

The simple act of wearing a jacket to work every day should improve my chances of success.
Apart from giving me the space to carry my capture system it will has the added benefit of moving my daily wardrobe up a notch.
My goal is fairly simple, I want to be able to continue to develop my skills while still being able to spend a lot of time with my family.
As a part of the process I will write down my experiences in implementing these systems as well as how I work around any issues that might rise.

What you should be told on the first day of any CS course

I can't count the number of times that I've been told that for developers the tools don't matter, just give us a prompt, a basic text editor and away we go.

The idea that the tools you use is inconsequential is at least as I see it one of the worst misconceptions about development, especially since it's spread by old developers and university teachers to fresh minds looking to write their first lines of code.

As an example current projects include a lot of back and forth between python, excel and mssql, as you can imagine this leads to good deal of semi manual string manipulation.

The work pattern of copying large amount of strings around while making minute changes to the order of characters is nothing specific to the projects I am currently working on, id say it's one of the cornerstones of any development project. 

At the very least you should refactor your code before finishing a project.

These situations doesn't necessarily require a decent text editor but I think anyone that have tried refactoring a reasonably sized program in nano would agree that it's not fun.

However this task done in a fully equipped advanced text editor like sublime, emacs, vi or atom is relatively joyous.

Finally even though I dislike the notion that advanced tools is unnecessary for developers I do believe that the choice of these tools is up to each of us.

I do for example use sublime for almost all of my development with the sole exception of C# which I write in the frankly excellent Visual Studio.

To sum up the advice I would have liked to have been told my first day at CS would be:

"Start this first day with trying out emacs,vi or sublime and use one of them for the next 3 years." 

I believe that the single best thing I've done for my development skills and workplace sanity is to use an advanced text editor.

Task based concurrency in C#

I have recently switched over to a company that mainly works with C# and python.
One of my first assignments have been to implement a minimal scheduler I have been trying to wrap my head around task based concurrency in C#.
This was necessary since I decided upon a "worker -- producer" setup with a producer that fetches "tasks" from a database, and a collection of workers that executes the tasks independently. This provides the benefit of allowing us to scale the number of workers to fit the current systems cpu and memory resources.
This approach is not without limitations but most of them are basic thread safety concerns.
The main issue however have been my somewhat lacking experience using tasks, which have lead to this post.

Real stuff

Below I will try and explain the basics for my use case:

The goal is to run a specific function in a object as a new task and await the result. The command used will be on similar to the following:

public async Task<bool> Execute(int n)
{
    return n == 0;
}

And the basic caller function will be similar to the following:

public async void Run()
{
    while(true)
    {
        if(!task.Empty)
        {
            Command c = tasks.Next();
            // MAGIC PART
         }
     }
}

The command class in the example implements my Execute function and the "Run" function will run in a worker object.

My initial attempts at "magic" ended up with the task running synchronously with the calling thread blocking and awaiting the result. This behavior was close to the desired result, however there was no possibility to specify await time, or to do other processing on the worker thread.

//Initial Magic
Task<bool> task = c.Execute();

To achieve my desired result this function call had to be adapted, I ended up having to create a "runner" task that handled the waiting for the intended task.

var runner = Task.Factory.StartNew(() =>
{
  var runningTask = c.Execute();
  return runningTask;
});

This "runner" task can then be ignored until the worker is free to await the result. Or as in my case it can be used to create a timeout loop for the task.

while (waited < timeOut)
{
  if (runner.Wait(500) || runner.IsCompleted)
  {
    break;
  }
    Thread.Sleep(1);
    waited += 500;
}

This loop "pools" the task every 500 ms to see if it has completed, and if the timeout value is reached I am free to cancel the task.