tldr; When adopting tools, do so to eliminate waste. It’s not worth adopting a tool for the sake of the clout of adopting it. For development, automate things you do the same often (or should/could do the same often). Build shareable processes that require little training overhead. Identify pieces of your process that require a common language; these places are usually where tools can be introduced to solidify that common language.

Don’t mess with my flow

If you are a leader of a development team, you know that it can be hard to adopt any team-wide change in workflow. This is especially true if the new project tools are a significant shift away from the way you already work. The truth is, the overhead of managing the tools (instead of working on the project itself) can bog down your team, make for some confusion, and ultimately cause over-engineering and waste of time.

But the truth...

The quantified self is really quite a hot topic. Ivan Kirigin talks about it in his post here as a potential startup idea. I’ve created something simple I’d like to share with all of you.

It is really quite simple, but also very flexible. Before I explain what it is, I’ll cover some of the conceptual reasoning behind the solution.

I believe that to do lists are generally quite hard to deal with, and overall don’t help my productivity. They require me to return to them over and over throughout the day, managing them, and often only serve as a place to mark things as done (rather than a place to ensure that I am being productive).

However, I don’t mind prompts. I don’t mind alerts. Certainly too many of irrelevant alerts can be annoying. But if I am motivated to use the alerts, I will.

As a developer, I am used to constant feedback. I am used to my machine telling me when I have...