Questions starting at 31:20 are pretty interesting.

My most recent system which I am very pleased with so far consists of only the following four folders:

• Inbox – Only emails with me in the ‘To’ field, kept for three months.
• CCed – Only emails with me in the ‘CC’ field, kept for one month.
• Lists – Any emails that don’t have me in either the ‘To’ or ‘CC’ fields, kept for two weeks.
• Archive – No filters put email in this folder, it is 100% manual, kept forever.

This system has made it easy to filter out the important emails (sent directly to me) from less important emails (which I am typically CCed on) or mailing lists (which seldom require any action).  I use the auto archiving (deletion) feature of my email client which allows me to automatically dispose of emails after a preset period based on the folder they are stored in.

I hope to phase out the archive folder sometime as I use Evernote to store any information I want to be able to find easily at a later date: as a purpose designed note/idea management application it is highly superior for the storing, organising and searching of data.

The first is the assumption that you could create something with the same quality level as the existing solution in the stated number of days; most likely you will be lucky to have a functional prototype with minimal functionality.  It is highly unlikely that you will have produced something that is as well tested, optimised and documented as the existing solution.

Secondly, as developers writing software which we intend to sell to users to pay the bills, we should be focused on the core features that define our product.  It is these core features we should be pouring our energy and time into designing, building and testing.  Developing alternatives to existing technology that is not in our core feature set is a waste of valuable time and energy and will not differentiate our product from that of our competitors.

We should instead be looking to leverage as many established technologies or components as possible when developing new systems as this lets us spend most of our time where it matters most on our core differentiating features.

My solution is the humble Moleskine Weekly Notebook (below).  As the name suggests the weekly notebook is a cunning combination of weekly diary (on the left page) and notebook (on the right page).  This allows me to write my to-do list for the week on the notebook page and record what I do each day on the appropriate section of the diary page.

Having my work log and to-do list in the same physical entity has been a real break-through for me as it means I can track my progress towards my objectives and be able to account for where my time is spent each day.  This has allowed me to analyse my working patterns and evaluate what is taking up time that could be better spent working on the tasks in my to-do list.  Being able to record unexpected events that have taken up time e.g. build breaks or sickness has also proven very useful.

What I don’t use this notebook for is an actual appointment diary or strategic to-do list as I have found through experimentation that there is seldom sufficient space for such things.  I have Microsoft Outlook which does appointment and calendar management and Evernote which does high level strategic tasks lists and note gathering.

“The perfect is the enemy of the good.” – Voltaire.

The pursuit of perfection is counter to the pursuit of a working product.  To build the perfect product takes time: lots of time, more time than most companies can afford.  To produce a good enough product takes significantly less time which increases the chances of actually getting it to market, making a profit and surviving long enough as a business to make a second improved iteration of the product.

“For many events, roughly 80% of the effects come from 20% of the causes.” – Pareto Principle.

According to the Pareto Principle (also known as the 80-20 rule) the first eighty percent of the output (effects) comes from only twenty percent of the work (causes).  This eighty percent output is the ‘good enough’ product, therefore to produce the perfect product takes five times as long as the merely good enough.

The question you should ask is ‘Do we need perfection?’.  I suspect unless you are programming medical, industrial or military equipment or software the answer is likely to be ‘No’.

Hat tip to Cliff for pointing this video out to me.

Consider yourself warned if you are using an RSS reader!

Update: I didn’t move the RSS feeds in the end.

Despite being almost an hour long this is a very insightful video that I’d recommend any Software Engineer watches. I find it fascinating that so many programmers want to erase their perceived (or actual) mistakes in source control systems. I guess everyone secretly wants to be the perfect super programmer. However I typically learn more from my failures than my successes: perhaps it is natural to be more introspective about failure than success?

If you find the title or video too pretentious then the question and answers session (around 42:40) is still quite interesting as the presenters get grilled by the audience.

So here is a brief description of how to do it:

1. Install the X-Code developer tools (for GCC, make and other build tools) from your Snow Leopard installation DvD.
2. Install the X11 Window System from your Snow Leopard installation DvD.
3. Run ‘Software Update‘ from the apple menu on your Mac to get the latest X-Code updates.
4. Download the latest MacPorts installer (.dmg file extension) for Snow Leopard from here: http://distfiles.macports.org/MacPorts/.
5. Mount the installer image file (.dmg) and run the contained MacPorts installer (.pkg).
6. Once installation is complete open a terminal window from Applications->Utilities->Terminal.
7. Type ‘port‘ at the terminal then press enter to run MacPorts.  You should see output like the following if it installed correctly:
   MacPorts 1.8.1
   Entering interactive mode… (“help” for help, “quit” to quit)
   Then type ‘quit‘ then press enter to exit port’s interactive mode.
8. Type ‘sudo port selfupdate‘ and press enter to update MacPorts to the latest version.  You will be asked to enter the administrators password before continuing.  Depending on how new the version you downloaded is, MacPorts may do some upgrading.
9. Once the update is finished type ‘sudo port install py26-matplotlib‘ and press enter.  This will attempt to install the latest version of matplotlib for Python version 2.6.*.   You may be asked to enter the administrators password before continuing.  MacPorts will now download, configure, build and stage the dependencies needed to build the latest matplotlib for Python 2.6.  This took at least thirty minutes on my iMac and involved lots and lots of scrolling text output from the build process.
10. Next we need to switch our environment to use version 2.6.* of Python that MacPorts just built and installed with matplotlib.  To do this run the following two commands, note you may be asked to enter the administrators password before continuing:
    1. ‘sudo port install python_select‘ and hit enter.
    2. ‘sudo python_select python26‘ and hit enter.
11. To test this all worked type the following: ‘python -V’ and hit enter.  You should see output like ‘Python 2.6.4‘ which should match the version of python MacPorts built and installed.
12. Finally to test if matplotlib was installed correctly do the following:
    1. Type ‘python‘ and hit enter to enter the python interactive shell.
    2. Type ‘import matplotlib‘ and hit enter, this will import the matplotlib module.  There should be no output if this works.
    3. Type ‘print matplotlib.__version__‘ and hit enter. This will print the version of matplotlib that is installed, you should see output like ‘0.99.1.1‘.
    4. Type ‘exit()‘ to quit the python interactive shell.