Lately I’ve been looking into how much time I spend in front of Mail (Apple’s email client). I feel like it’s always a struggle to get away from email for two reasons. If I close Mail I am afraid to open it again as I know it will be a chore to get to the bottom of the pile , but if I leave it open all day I find it hard to complete my day’s work without constant interruption.
Time for a personal assistant you say?
Maybe, but there might be a better way in the interim. Like trying to find the ultimate way of organising tasks, keeping on top of email can be just as daunting (read: useless). I poked around the 43folders web site and may just have found it.
Merlin Mann is the creator of 43folders and his website about finding the time and attention to do your best creative work.
Delving in to some of the posts, I managed to get a basis of how I might go about keeping on top of emails (codename Inbox Zero).
After having a read of this site and venturing off into Google, I finally had a plan. Create some folders in Mail (abandoning my previous structure) and action emails in the appropriate way. I’m not creating anything new and revolutionary here, but so far using these ideas is working for me (and making a massive difference to the time spent in front of email).
For anyone possibly interested in the way I am doing things, let me know in the comments. I might just find the time to follow this up.
In a previous job I dealt with the IT tasks related to a multi level marketing business. We stored everything in a database of course and due to the nature of multi level marketing most of the operations performed had to take into account the tree like structure of the people involved.
An example would be, given a party that was run there would be rewards based on future bookings made, how much the party sold and so on. The largest direct benefitor of these rewards was of course the person that ran the party. However this person had a manager, who in turn may have a manager who in turn may have a manager and so on up the tree. At each level the manager got a cut based on a number of factors such as how many people she was managing, what her position was an so on.
At the time the way I dealt with trees was via adjacency lists, mostly because that’s what was most logical to me and how it seemed everyone else did it. I thought I’d have a look around and see if anything had changed in the last couple of years and found this article on using nested sets to deal with hierarchical data.
It seems to me that this method trades insertion performance for selection performance which for most situations is fantastic! It seems to be exactly what I need given I’ll be performing far more selects than inserts and it also has given me another tool in my toolbox.
It’s long been understood that to keep someone in IT happy one of the most important things is change and new stuff. I think this constitutes new stuff for me.
It may be the engineer inside me, but I find optimizing systems to be highly challenging and rewarding. I enjoyed the time spent analysing and refactoring SQL code and more recently have thoroughly enjoyed refactoring some of our existing applications to run more quickly.
The great thing about optimizing computer code is that you genuinely know if you’ve succeeded or not. You have metrics from before and after your code changes to prove they were effective. It also makes you think about how things are working in the application at a much lower level. It feels pretty good that by you spending a couple of hours on a problem you could be potentially saving days, weeks or months of run time when applied to a number of users.
In this article the author details how he went about improving the speed of a facial recognition implementation by 25 times. That’s a massive improvement and I found the process to be pretty nicely indicative of how a real programmer thinks sometimes. If you consider that this process perhaps took him a day of work, and returned some software that potentially requires 25 time less equipment to run, it just goes to show how much difference one person really can make!
The presentation covered some material from the book, as well as delving into a few other concepts. It took a few days to get through the hour long presentation, but was worth the watch.
Some of the information I picked up and will be thinking about:
Keeping momentum – Projects always start off enthusiastically and taper off drastically as time goes on. Breaking projects into much smaller chunks (a couple of days to a week) so you can keep up momentum is beneficial.
Vocabulary – Drop a few words from your vocabulary because they cause things to go wrong. Can’t, need, easy are a few examples. We “can’t” launch like this. Why not? Do you actually “need” to introduce this new feature? Is it really that important? Telling someone that something is “easy” is a no-no. Don’t describe other peoples work with this word (“Just add this for me, it’s easy”).
Passive collaboration – Alone time is extremely important to getting things done. Anyone will tell you they are most productive early in the morning, or late at night when there is no interruptions. Find a 2 hour block, switch off communication and shut your door. Communicate passively (IM, Email) rather than face to face, or in meetings. Just because you have something you want to share, it may not be (and probably isn’t) more important than what the person you are interrupting was already in the middle of.
Now and 10 years – When thinking about product features and design use this rule. What’s important now and still will be in 10 years (speed, ease of use). Think about improving areas that will still be relevant in 10 years.
Lower end of market – Most mainstream established products are too difficult for a new user to use well. Companies like Microsoft and Intuit have had their products out there for decades and it’s hard to compete with that. They keep adding new features so people will upgrade each year. They used to fill a simple need, but have moved past that and cram anything and everything into their applications. Move your product into that empty space. Solve someone’s need and solve it well.
Teach/share – Don’t horde your thoughts and ideas. People and companies who share, flourish. Blog, release code, write about what you are doing. If you do this, people will remember you.
Solve simple problems – Everyone wants to be the one who solves the hard problem. Give up on hard problems. There’s far too many simple problems that need solving and solving well.
Curate your product – Treat your product like a museum. Every feature request, every change you make, look at the bigger picture. A curator doesn’t add artwork to the museum just because someone wants them to. Make sure your product will remain intact.
If interested, you can view it here at the 37signals blog.
I’m a big fan of Javascript frameworks that help me get things done, I’m a huge fan of anything that helps me get things done easier. My favourite framework though is jQuery after having tried a few just over a year ago I settled on jQuery as a better choice than Prototype and thankfully I’ve been proven right.
John Resig, the creator of jQuery is also a bit of a proponent for another framework called MochiKit. The idea of MochiKit is to “Make Javascript Suck Less” and as such doesn’t really offer many out there features that others might, it more concentrates on filling in functionality gaps that are present in the Javascript language.
These things include better comparator functions, which enable sorting and so on, also there are handy formatting functions, asynchronous functions and data functions for handling JSON. DOM manipulation looks to be very good, though whether it’s easier than jQuery is probably up to personal choice. Basically MochiKit seems to fill in the gaps of Javascript and do exactly what it says it does, make programming with Javascript suck less by giving you the functions you always wished you had.
I plan on checking this out and feel like it’s probably a worth addition to anybodys’ toolbox that is writing client side code.