Get things done: My setup

I have been using slightly twisted version of GTD for my everyday tasks as well as for my long term goals for last 8 months, and it has been a great ride. I want to share my overall setup of my GTD system and then the each piece of the setup in more details. In this post, I am going to explain my overall setup of the GTD system.

Before I dig in, let me put my requirements and use-cases so that one can understand why my setup exists:

1. I should be able to follow GTD not strictly but with modifications as per my needs.
2. I should be able to use just one system to track my daily tasks as well tasks for my long term goals.
3. I should be able to use the same system for my home and office tasks, but still be able to separate them so that I don't endup caring about the office-related tasks at home (for the most part).
4. The tasks should be backed-up in cloud as well as on the client side.
5. I should also see my scheduled tasks in my iOS/OSX calendar.
6. All parts of the system are always in sync.
7. Lastly, I don't mind to shell out some limited amount of dollars for the setup.

I know! A long and complex list of use-cases to begin with.

To get things done my way, I have tried a lot of apps and services that claims to do GTD. Most of them were good but either they won't fit into my requirements or they were simply not following any version of GTD! I won't name all the options that I tried as they as a lot of them and also does not serve the purpose of this post which to share my existing and working solution.

After trying out a number of options, I finally stick to these apps/services:

• 2Do (iPhone and Mac app)
• Toodledo (cloud backup/sync)
• iOS/OSX Calendar

And this how I set them up to meet all my above requirements:

My GTD setup

I found 2Do allowed me to modify and use my own version of GTD as the app provides a lot of flexibility and options to tweak the process. I will go deeper into my tweaked GTD process using this app in a future post, but for now I will just post my complete system setup.

2Do does provide a lot of options to sync the tasks using multiple cloud services like DropBox, iCloud and Toodledo. I chose to go with Toodledo, as it fit nicely with 2Do and also allows me to get the tasks to show up in my Calendar apps.

So when I add tasks using 2Do on my iPhone and/or Mac, it gets synced with Toodledo. Then once you add Toodledo as ICS subscription to the Calendar/iCal, you can view all the scheduled tasks in your calendar as well. I use 2Do on my iPhone primarily for tracking my non-office tasks while the one on my Mac for my office tasks even though I keep both in sync and can see, add and edit them on either iPhone and Mac. But in order to separate myself from office work while at home, I have tweaked the system so that I don't worry or even see most of my office tasks on my iPhone.

This setup has worked wonders for me, keeping me up to date of all my tasks no matter where and how I add them.

Let me know in comments if you have used similar setup and have suggestions on how to make it even better.

The perfect software

I came across this awesome blog that shares some of the experiences of the team that writes software for the NASA space shuttle. It presents a great insight into how powerful software can be. As a software developer, we sometime take things (read bugs!) for granted, but if there are lives that depends on the same software, then entire definition of 'bugs' changes.

A must read for every software engineer:

http://www.fastcompany.com/28121/they-write-right-stuff

Epigrams on Programming

Just for fun :) http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

My favorite quotes:

"Whenever two programmers meet to criticize their programs, both are silent."

"Every program has (at least) two purposes: the one for which it was written and another for which it wasn't."

Invaluable lessons from Jeff Bezos

If you are an entrepreneur or want to be one or work in a startup or a big company and want to learn from one of the best entrepreneur in the world, you should read this awesome blog about lessons to learn from Jeff Bezos, founder and CEO of Amazon.

Here is the two-pager on that blog, in case you don't want to read the entire blog.

1. Be Stubborn and Flexible 

According to Bezos, good entrepreneurs must be stubborn and flexible. When referring to Amazon, Bezos says, “We are stubborn on vision. We are flexible on details.”

2. Stick with Two Pizzas teams
When teams grow larger, they have a tendency to become less efficient. This inefficiency reduces the output of the team and leads to waste. So keep teams small and let them test.

3. Never Stop Experimenting
An awesome quote from Bezos:

“If you double the number of experiments you do per year you’re going to double your inventiveness.”

4. Be Willing to Invent

5. Think Long Term
Once, when asked about Amazon’s revenue growth, Bezos couldn’t even remember the exact growth percentage, something rare for a CEO. When asked why he didn’t know, he said:

“I’m thinking a few years out. I’ve already forgotten those numbers.”

6. Tie Experimentation, Willingness to Invent, and Innovation All Together
At his talk in November 2012 at the re: Invent conference, Bezos explains how:

Innovation = Experimentation + Willingness to Invent

“Now there are a couple of other things that are essential for innovation and invention that are not as fun. One of them is you have to have a willingness to fail. You have to have a willingness to be misunderstood for long periods of time. If you do something in a new way, and I don’t care what it is, people are initially going to misunderstand it relative to the traditional way..."

“.. So it’s okay though if you have a willingness to be misunderstood for long periods of time, if you have a willingness to fail, then what you can do is you can ramp up your rate of experimentation. So successful invention is inventions that customers care about. It’s actually relatively easy to invent new things that customers don’t care about..."

7. Present and Discuss Memoranda, not Slide Shows
“The traditional kind of corporate meeting is somebody gets up in the front of the room and presents…some kind of slide show. In our view…you get very little information that way, you get bullet points. It’s easy for the presenter but difficult for the audience. And so, instead, what we do is all of our meetings are structured around a 6-page narrative memo. And when you have to write your ideas out in complete sentences and complete paragraphs, it forces a deeper clarity of thinking.”

8. Obsess About Customers
“Focusing on the customer makes a company more resilient.”

At Amazon, there is a common line of thinking:
“Start with the customer and work backwards.“

9. Base Your Strategy on Things That Won’t Change
Bezos at re: Invent, November 2012:

“I very frequently get the question: ‘what’s going to change in the next 10 years?’ And that is a very interesting question; it’s a very common one. I almost never get the question: ‘what’s not going to change in the next 10 years?’ And I submit to you that that second question is actually the more important of the two – because you can build a business strategy around the things that are stable in time….in our retail business, we know that customers want low prices and I know that’s going to be true 10 years from now..."

10. Identify and Remove Risk
According to Bezos, the best entrepreneurs don’t like risk and work to identify it and remove it in the early days of a business. He says:

“Good entrepreneurs don’t like risk; they seek to reduce risk…Starting a company is already risky, and then you systematically eliminate risk step by step in those early days….you kind of need to systematically identify risk and then as the company gets bigger and more robust, you can start taking risks again but in those early days a lot of it is about ‘okay I have a good idea, how do we reduce risk?’”

11. Get Started Now to Avoid Regret LaterWhen Bezos was thinking about building Amazon, he had to decide whether to start the company or keep his good job on Wall Street. He created a framework to use for making the decision that he calls a Regret Minimization Framework. It helped him realize he didn’t want to not do it and regret it later. This fear of regret is one of the key reasons why he decided to go ahead and start Amazon.

12. Bezos Gives Entrepreneurs AdviceAt his talk at re: Invent, he gave some direct advice to all entrepreneurs:

1) “Never chase the hot thing….you need to position yourself and wait for the wave. And the way you do that is you pick something you’re passionate about. That’s the number one piece of advice that I’d give to someone that wants to start a company or start a new endeavor inside of a bigger company. Make sure it’s something you’re interested in, something you’re passionate about. Missionaries build better products…I’d take a missionary over a mercenary any day. Mercenaries want to flip the company and get rich, missionaries want to build a great product or service – and one of those paradoxes is usually the missionaries end up making more money anyway…..pick something you’re passionate about.”

2) “Start with the customer and work backwards. Those two things, passion and customer centricity, will take you an awful long way.”

TDD is not all about writing tests first

TDD's mantra:

In words:

• Add a failing test
• Write code to pass the test
• Refactor

If you want to get a firm grip on this awesome methodology, read this book by Kent Beck.

However, TDD is not just about writing your tests first or to increase your code's test coverage. These are just the add-ons that you get for free when you use TDD. The mantra behind using TDD is to improve your design, to think from a consumer point of view who is going to use your components or APIs. These consumers can be anyone, it could be you, your team mates, other teams or general public.

Then, you may ask how can writing tests first allows you to better design your interfaces? Good question. Lets think about it in this way. Why we write software? One possible answer is to create some applications that does few useful things that wouldn't have been possible or too tedious to do manually. Its creates something with some intent that someone can use it. So two things that pop out: intent and use. I think that TDD allows you to get these two things right, the intent and use, while creating software. Again you may ask, still how writing a test helps you to get these two things right? Good question again.

When you are writing a test even without the code itself, the most important thing that comes to your mind is how am I going to use this component in my system or application. This makes you think about the interfaces, the parameters, the exceptions you want this method to throw. And there you design your API.

And then the other most important thing you think about what is the intent or the purpose of the code that you are about to write. What you want this piece of code to do? That is what makes you to write your assert statements.

Yes, it could be very difficult to digest this test-first approach initially if you haven't been practicing such methodology but once you do you will see the results and it value. You will be amazed to see how easy it becomes to design your components if they are easy to test.

I have been using TDD for more than a year now and I can definitely see the difference in the way I think and develop software. Its weird but TDD makes you to not to hate writing unit tests since they are the not burdensome-after-thoughts anymore.

Then, there are so many other good things that come for free when you write your tests first. It makes you confident about refactoring existing code. I am currently working on a system at Amazon that serves million of customers and allow them to play with their apps with almost zero downtime. How can you imagine refactoring such a service where a simple mistake can either lead to doing something unintended that breaks millions' of users Appstore experience or can breaks a functionality (or Appstore client) in its entirety? We want our tests to fail first in such cases. 

Then there is code coverage. You won't believe the results of running a code coverage tool on a codebase that is written using TDD approach. It does not give you a single opportunity to make the coverage better by looking at the results and then 'hack' the tests to increase the coverage since you already get an amazing high code coverage for free!

Give it a try, its worth it.