Facebook is the Death Star, and we're all building it.

Do you ever wonder what happened to all the innocent construction workers on the Death Star (v2.0) when it is destroyed? If you've watched Kevin Smith's Clerks, you certainly would have. If you haven't seen it, Google "Clerks Star Wars" and watch a short clip from it. For those that can't be bothered, the discussion between a customer and a store clerk revolves around the destruction of the second Death Star in Return of the Jedi. Given that it was still under construction at the time, it is almost certain that many thousands of workers would've been killed in the blast. The customer feels that it's terrible that so many people were killed just doing their jobs (roofer, plumbers, electricians etc) that weren't, strictly speaking, part of the "Empire". The clerk argues that the independent contractor has a moral obligation to know who they're working for before they take on the job. If you're building a Death Star, it's really your duty to know what it is you're helping to build. If you get killed in the process, well... you knew the risk when you took on the job.

What does this have to do with you? Well, Facebook is the Death Star, and you're helping build it.

Ok, so you're not part of the Empire, but you're contributing to the construction nonetheless. You're the plumber or the electrician, the guy that forgot to put in safety rails, the girl that builds the strangely located trash compactors in prison blocks and then ensures they have large tentacled creatures in them, or maybe you're just the one responsible for naming Mr. Coffee and Mr. Radar. The point is, you don't need to work for the Empire to be complicit in its success.

Tim Berners-Lee, in his Scientific American article, wrote, "If we, the Web's users, allow these and other trends to proceed unchecked, the Web could be broken into fragmented islands. We could lose the freedom to connect with whichever Web sites we want." One of the trends he speaks of are the walled gardens of information; silos of user data owned by the likes of Facebook and LinkedIn. He argues, "Each site is a silo, walled off from the others. Yes, your site’s pages are on the Web, but your data are not."

He quite clearly sees the onus on us, as web users, to prevent this from happening. But I think it actually goes further than that. Data portability is certainly an issue, but friend data is at best transient and for any individual can become outdated in a year or two. Sure those awesome photos of your mate dressed as the Death Star may be stuck permanently in Facebook's database, but in a year or two, you're not going to care. Even the network of friends you build today is quite possibly a lot different than the one you'll create in 2 or 3 years time. This data is usually not critical and is, more importantly, replaceable. People left MySpace for Facebook and built new networks, and they can certainly leave Facebook for Diaspora or whatever comes up next. No, the real problem is Facebook becoming a defacto standard for your online identity. 

Many applications now provide the ability to log on to their system using Facebook Connect. In many cases, this is now the exclusive means of registering. Signing up to just about anything is becoming a simple matter of clicking the "Facebook Connect" button. For many of us, it's almost too tempting to take the quick route rather than signing up a whole new account with a new password. What we're not doing, however, is giving thought to what we're really doing. By joining something like Digg with that one click, we're permanently tying our Digg identity to our Facebook identity. Without thinking, we've made an implicit decision that our Facebook account will be active longer than our Digg account. From this point on, we can't delete our Facebook account without losing access to Digg as well. By doing this, we've all decided to make Facebook our permanent record, our online authentication protocol and our secure means of access to dozens of websites and applications.

Most of us sign up to a social network with little thought to the security behind it. Afterall, do I really care if someone knows what I did last summer? But if your Facebook account becomes your online passport, how secure is it? If your Facebook account is compromised how many sites does that hacker now have access to? How many sites can a hacker sign up to and assume your identity in the process? How many sites have your Credit Card stored securely for easy checkout? The hacker now has access to it all. The more ubiquitous Facebook becomes in your life, the more likely it is to be compromised and the more destructive it will be when it happens. What was originally a means to connect with friends, has become your single online identity. But you don't need a hacker installing malware on your PC. This an identity that is persistently logged in on your home laptop, your iPad, your iPhone and your work PC. Have you ever lost your phone or even just left your computer logged on at work? Someone now has access to everything you do online. Worse than that they even have a handy list of every website you're signed up to with Facebook Connect.  

Returning for a moment to the Star Wars analogy; remember when Jar Jar Binks voted to dissolve the Galactic Senate (thus handing control to Senator Palpatine) and you were screaming at your TV because everyone in the damned movie must have to be a complete and utter moron to not see it happening? Well...you just put Jar Jar Binks in charge of your online identity. Nice work dumbass.

These are all personal issues, things that affect the end user. I'm not proposing people go out deleting their Facebook accounts. Facebook connect is actually really handy. But what about the big picture? What happens when everybody on the Internet uses Facebook as their online identity? What happens when sites start offering Facebook Connect as the only means to sign up? Without realising it, you've made Facebook the sole authentication system for logging on to just about anything on the Internet. A closed-network owned by a private company now has a complete record of every site every person on the web visits. Think about that for a second. Remember that kid from that Social Network movie you saw the other day? He's holding all the keys to everything...literally.

The danger in Facebook isn't in that you can't take your friends elsewhere, the danger in Facebook is having it become a defacto standard means of authentication on the Web. Every time somebody hands the keys to their Blippy account over to Facebook, that is one more person who is now "stuck" with Facebook. You can decide to leave your social network behind, but if you use Facebook Connect, leaving Facebook also means leaving behind every account on any one of a hundred different websites. The barrier to entry is insignificant, yet the barrier to exit is so insurmountable that it's scary. It doesn't matter what the Diaspora project do. The social network is all but irrelevant now, it's the online authentication hook that is what will ensure Facebook survives any new up and comer. 

Of course, there are ways to stop this happening. As developers, we're the ones building the Death Star. Every time we add Facebook Connect, we're adding another piece of armour to make Facebook stronger, more powerful. Our users want Facebook Connect, and that is fine, but we have an obligation to give them a way out too. Some sites, like Groupon, give users the ability to disconnect their account from Facebook. You just add a password, and you can then just login manually. The problem is if I delete my Facebook account before I do this, I can't log in to Groupon to flick the switch! This is something akin to uninstalling Adobe Photoshop only to realise that you had to deactivate it first. Problem is now you can't deactivate it without it being installed, and you can't install it without deactivating it. Catch 22.

The real problem is having Facebook as a permanent centralised authentication system in the first place. It's one thing to "get started" with Facebook Connect, but an application should always provide another means of accessing the application without Facebook (even for those who connected with Connect in the first place). If Facebook becomes inaccessible, or we want to stop supporting Facebook, or even if Facebook stops supporting us, we need to have a solution ready to allow users to continue using our application without that reliance on Facebook Connect.

The goal here is to prevent Facebook "lock in" and I believe, the humble "forgot password" is the place to start. I'm putting forward the suggestion that applications that implement Facebook Connect should add a "login without Facebook" next to their "login with Facebook" link. This would work something like a "forgot password" function for Facebook users who no longer want to connect using Facebook. This would transparently modify their accounts to allow manual login and simultaneously perform a "forgot password" retrieval. The user gets an email with a link to create a password, and from then on they can use that to login instead of Facebook. Groupon is actually one site out there that is already subtly doing just this using their existing "forgot password" function, but it certainly isn't obvious. As time goes on, users are going to become more and aware of how much they're relying on Facebook for authentication, and eventually they're going to want out. It's up to us as developers to give them by providing that "out".

Of course, Facebook may have already worked this out. Now they want you to use Facebook for your email as well...can you see where I'm going with this?

We're building the Death Star, make no mistake. And every time a user signs up using Facebook Connect another Ewok dies. Do you want that on your conscience? We have an obligation to ensure that there are as many exposed shield generators and poorly positioned ventilations shafts as possible. Only by creating weaknesses in the Death Star as we assist in its construction can we ensure that some whiney kid in an X-Wing can destroy it when the world finally realises what we've built. As developers, it's our responsibility to make sure we don't contribute to the yet to be coined "Facebook lock-in". We must provide our users not only a means to use our applications without Facebook, but also a means to use our application should they have already stopped using Facebook. By perpetuating the need for Facebook logins in our applications, we perpetuate the security risk that Facebook Connect presents to our already over-connected users.

Why you absolutely MUST write an API when you write your next app

I'm a bit of hacker. I've worked with serious software engineers, and I'm definitely not one of those, although I can be when it's required. They're the types that spend more time writing and talking about what they're going to code than they do actually coding it. The word engineer suits these types perfectly. A piece of software to them is constructed from piece by piece of pre-defined, pre-designed and pre-fabricated code. There is more art than science to what I do. I liken what I do to gardening more than building a bridge. To me, software is more of an organic thing and I start software the way I start in the garden. I pick up a shovel and start digging. Over time as plants grow (or die), the yard changes and you change with it. I'm not building bank software or landing planes. I'm building to an ever changing target, evolving my software to suit a need that is never well defined, never fully known. It's whatever I feel like making it.

The big disclaimer here is that sometimes I need to be an engineer. If I'm working for a client on a fixed price project, then obviously everything needs to be engineered to a certain goal. So I can work that way, I just prefer not to. My client work is structured and defined, my pet projects are the result of an ever evolving process of discovery and learning. Of course, that isn't to say you can forget about security, performance or reliability...but it means these things are just one part of an iterative process, not a project in themselves.

For the most part, not being constrained by things like "best practices" is a wonderful freedom. I think of something, and I start coding it. When I'm done, I might go back and tweak or even throw away the prototype and start again (kind of like how we're onto our second Japanese Maple, after the first one died). It's wonderful when you know nobody will ever look at your code, or discover your hacks, it allows you to solve problems now without worrying too much about later. It's like an author taking short cuts with facts, names and places instead of wasting time researching. It just gets in the way of writing the story. But there is a big problem with this type of development. What you gain in agility, you lose in portability. By coding for yourself, you're forgetting about everyone else. 

If you build a successful product, there is a fair chance that at some point you're going to need to get someone else involved. It may be as an employee joining your coding team, or showing a potential investor what you've been working on or it may be by releasing an API for others to integrate with your system. For the first time you're suddenly faced with that embarrassing feeling of your parents dropping in to visit...and it's the morning after a really really big party. It's at this point you suddenly regret all the shortcuts, the laziness, the hacks and the sambuca...oh Lord the sambuca!

That's where writing a public API from day 1 comes in.

You don't have to have your whole house neat, just the bits your parents are going to be seeing. Writing a public API as you develop your system forces you to keep a certain level of decency without constraining your ability to be agile elsewhere. By using your own API you also force yourself to follow the same rules that you expect others to follow when interfacing with your code. It prevents you taking shortcuts that you rightly wouldn't let anyone else take.

If you're an agile or "lean" developer, the one thing you never think about is what this app is going to need to do in the future. You're only ever worried about what it needs to do today. This means your code can evolve into a horrible flying spaghetti monster (if you believe in such things). What makes sense today, may not seem like such a good idea tomorrow. By having a well defined core API you have at least one part of your system (hopefully the important bit) that is well documented, well considered and well written. It's something akin to maintaining a tidy formal lounge whilst the rest of your house is being subjected to an ill-considered conga line.

When it eventually comes time to make your API public, it's already tested and known to work. You know what problems your users are likely to encounter, because you've already encountered them yourself. Best of all, you're not trying to shoehorn a heap of public points of access where they were never intended. Writing an API as you go means you solve a lot of problems before they ever happen...and all without having to think about it too much. The API is as flexible as you want it to be until the day you make it public.

As you grow your application, your API grows with it. The more reliable it becomes, the more likely you will turn to it rather than hacking in a new piece of code elsewhere. When new developers come on board they have something they can immediately recognise and understand. We're all terrible at documenting our code, but with a published API you all of a sudden are advertising what you're application does...you want it to be well documented. Your users won't stand for anything less. 

All of this is the main reason most developers recommend working on open source projects. Open source means everything you do is available for anyone to see. Hacks and cheats are found and highlighted by others, and hopefully you'll learn a better way in the process. You lose this benefit of peer review when you're working on your own private projects. Writing to your own API is the next best thing. Hacks look a whole lot worse when you have to document them for someone else.

Why indecision is worse than a bad decision

Indecision is the worst trait you can find in a startup founder. Actually, it's the worst trait you can find in anyone tasked with leading or shaping the direction of any company or project. Indecision, is simply delaying the making of a decision. Sounds reasonably obvious when you say it out load, but what isn't obvious is the implications of delaying a decision. Delaying a decision is effectively delaying work. Being indecisive is therefore no better than procrastination. Both are a barrier to getting things done. It doesn't matter whether you're running a startup, or just deciding on what to eat for lunch, indecision just makes things worse. Right now you may be stuck deciding what to eat, but in an hour's time your lunch break is over and you're bloody starving. Better to suck it up now and just have the damned noodles.

People are indecisive out of fear of making a bad decision. The logic goes that by delaying the decision, I can gather more information and then have a more informed opinion later. The information they're waiting for is really just something to either make them feel more secure in what they've already decided, or something to sway them away from something they don't want to decide. Either way, more information is unlikely to help. If you're in a position where you need to make a call now; make the call now. Looking at the menu for another ten minutes isn't going to make the noodles taste any better.

The absolute worst case is the person who delays a decision until it gets to a point that it simply becomes someone else's decision. If you meet someone like this, run the other way...especially if they're leading a team you're in. I've found myself in a position a couple of times where I've relied on someone above me in a company to make tough decisions.  In many cases the person just went on holiday, or avoided me for a week just to avoid the inevitable discussion, decision and implications. In the end, the hard tasks just fall to someone else often ill equipped to deal them. This lack of confidence in one's ability to make difficult decisions makes for poor leaders and, consequently, poor teams.

There are many reasonable sounding excuses for delays in decision making. Gathering information is one such reason and is often necessitous when making a decision. The danger in gathering too much information is when the information is being gathered simply to confirm a well known hypothesis. If it looks like someone in your team isn't pulling their weight, there is little point gathering evidence to confirm the fact. If they're not up to scratch, show them the door. The opposite case is the search for information to avoid a difficult, but necessary, choice. The reality is that if you look hard enough you can find information to confirm just about anything you like. Giving someone the opportunity to do so just gives them a chance to put weight behind a decision that everyone knows is wrong.

Another reason for indecision is when there doesn't appear to be a good option. Sometimes you're faced with a situation where you have two choices, and they're both bad. The natural inclination of most people is to simply delay making a decision in the hope that a better option comes along. Of course it's possible, but if a better option doesn't surface, you've likely left yourself with the same two choices you started with...except now you're a month poorer as well. Sometimes you just have to play the cards you're dealt.

Some time ago I watched a great video on youtube about indecision and inaction over global warming. The premise of the video is that we can act or not act, and global warming could be true or not true. There are therefore 4 possible outcomes, the best case being we act on global warming and it turns out to be true, and the worst case is that we don't act and it also turns out to be true. The interesting part about the video in this context, is arriving at how to decide if you should act.. 

Imagine we're provided with a situation where we may or may not have a major problem in our software; we'll use the infamous Y2K bug as an example. If we spend a heap of money investigating if our software is affected and it IS then we're all thrilled that we avoided disaster. Good decision! If it turns out that we weren't affected...well at least we know! That's still pretty good....even if it did cost us a truck load of time and money.

Now, let's imagine we didn't do anything. NYE rocks around and we're out partying the night away. Barry, our sysadmin calls us at midnight with the news. If everything is ok we all high-five each other and get on with the partying. If, on the other hand, all of our software is now dead, banks are going belly up, planes are crashing, toasters are exploding...well...we'd probably be in a really bad place. Here's a handy little chart with the possible outcomes from a situation like this.

In essence, when you have an unknown outcome it's always better to act than it is to not act. If you don't act and things go bad, they can go really bad. So what's this got to do with indecision? Well, indecision is the same as not acting. By not making a decision, you're in effect choosing the "don't act" column. By not acting, you're rolling the dice and hoping for the best, you're giving up any say in the matter, you're relinquishing control to some external power, you're crossing your fingers and toes. This isn't the way to deal with global warming, and it isn't the right way to run your business. If you have control, use it.

Difficult situations don't disappear. They just get worse. If you've got a bad employee causing problems, delaying the hard decision to give him the boot just increases the chances of him affecting those around him. If your website is losing you money, delaying the decision to pull the pin will just cost you even more. Decide early, and act swiftly.

So what's the worst that can happen if you make the wrong decision? The fact that you decided to do it means that it was the right decision at the time with the information you had. So it only became a bad decision when unknowns surfaced, or when something changed. When that happens, you simply make a new decision. That may be that you alter what you were doing slightly, or it may be that you scrap it in favour of a new path. Either way, by making a decision you forced an outcome. If you hadn't acted, those unknowns would still be unknown. By making decisions constantly based on the information available, you uncover newer information more quickly. Inaction rarely provides anything actionable.

Very rarely, you can make a call which turns out so horribly wrong that you wonder how you could ever have made such a stupid mistake. When this happens, talk it out. If your customers are pissed at you, get on the phone, email, twitter and talk to them. Apologise for your mistake and ask what you can do to make it better. If you broke something, let people know, and get help to fix it. It is highly unlikely that you'll ever make a mistake that you can't recover from. Put you hand up, own the error and start talking about how to fix it. Taking actions sometimes means taking risks, but without taking risks you will never achieve something great.

So when you're faced with a decision, look at your options, talk it over, experiment, research and ponder...but when you're done, make a decision. The sooner you get moving, the sooner you find out if you were right or not. The earlier you act, the more choices you will likely have available. Leave your decisions until the last minute, and you'll often find the options have dwindled significantly. 

Optimize, don't Organize: Part 7

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here


7. Sticky notes, and why they rock.

If you have a wall next to you (or even that whiteboard I told you not to use), sticky notes may well be your saviour.

It’s harder to escape your decisions.

A sticky note wall tends to promote a “first in, first out” mentality. The oldest and most important tasks tend to end up at the top of the list rather than at the bottom. For some reason when you added that task to the top, you considered it to be the most important. It probably still is, even if you don’t feel like doing it. Putting it off isn’t as easy as moving it to the bottom of the list, at least not unless you re-sort and re-evaluate the entire list (and even that’s not a bad thing).

Just because it’s new doesn’t make it more important.

We have a tendency to think that new tasks are more important than old ones. Someone jumps on the phone and tells us they need something done by the end of the day so we drop everything to get it done, forgetting that we have two other tasks that also need doing by the end of the day. Just because it’s newer, doesn’t make it more important. If anything, our older tasks should take priority. The sticky note list will tend to force you to put newer tasks below older ones. And if you really need to place it above your existing items, you have to be damned certain you want to raise the limit on “importance”, because eventually you’re going to run out of “higher” on your wall or whiteboard.

Sticky notes are only semi-permanent

My sticky notes are on a painted wall. The glue lasts about three or four weeks before the heater (or air-con) blows them off the wall. In reality, if I haven’t done a task that’s been on my list for three weeks, I’m probably not ever going to do it. When your notes fall on the floor, it forces you to re-evaluate them. Is this task worth rewriting on a new note, or should I just bin it?

Sticky notes are real

Taking down a task is a reward in itself. The little square of paper has texture and colour. If it’s been on your wall for a few weeks, you may have even gotten used to the quirkiness of whatever you wrote. It’s a real thing that existed in your little work space. It gives the task life and a sense of reality. Best of all, they’re something you can screw up into a tiny ball and take a shot at the nearest bin (or colleague’s head, whichever works). 


Previous chapters:

Optimize, don't Organize: Part 6

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here

6. Why most task lists don’t work


As a rule, task lists don’t work. They become cluttered, out of date and full of things we never intend on doing. 

Why digital lists don’t work.

Digital lists are too easy to add to. We add things that aren’t important, things that we don’t need to remember and things we feel we “should” do, but never will. Worse than that is that tasks are too easy to strike off. With a click of a mouse or a swipe of a finger we can permanently erase our failure to complete something that we originally thought was important enough to add in the first place.  With every second person owning a smart phone, digital tasks lists are popular for their portability and convenience. Whilst it may be great to remember what you needed to buy down the shop, organizing your work in a digital list is always going to end in tears. If it’s too easy to fill with clutter, and too easy to remove our failures, we won’t trust it. If we don’t trust it, we won’t use it.

Why pen and paper doesn’t work.

I have too many notebooks. I take notes in meetings, I take notes on the phone and I take notes when I’m programming. I don’t need a todo list on my desk as well. Pen and paper tasks lists are also the worst for maintainability. As your tasks are crossed off your list becomes more and more messy. This either forces you to regularly rewrite your list, or to throw it out entirely. You can’t sort, you can’t undo, you scribble phone messages in the corner and worst of all you most likely can’t read your own writing. We write something down in a hurry and are later left wondering, “what’s ‘sulmif buffon’?”

Why whiteboards don’t work.

Whiteboards are the worst. Even someone with the best penmanship can’t write for shit on a whiteboard. The whiteboard suffers from all the same problems as pen and paper but without any of benefits. Possibly the only thing in favour of a whiteboard is also its biggest drawback - the ability to erase. It might be handy to be scrub off that completed task, but it’s also just as easy to accidently remove your whole weeks work. Somewhat contradictorily, whiteboards are also a magnet for old information. Unlike a paper list which we may eventually throw out, a whiteboard tends to collect things that nobody ever thinks to wipe off. Out of date information is the worst kind.


Coming up:

7 - Sticky notes, and why they rock.


Optimize, don't Organize: Part 5

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here


5. The better way to prioritize.

The only thing you ever need to be concerned about is what you should be doing right now. Tomorrow’s list doesn’t help you right now. Worry about now now, and later later.

If something can wait, make it wait.

This doesn’t mean procrastinate or avoid things which really need to be done. It means something which has to be done today really should get done today. Priority isn’t always about relative importance. Sometimes the least significant job still needs to be done by COB today. The flip side of this is that if something doesn’t need to be done until next month, leave it till later. Don’t leave it to the last minute, but if you have something that needs doing sooner, do it...even if it just landed on your desk right now.

Clear junk in batches.

Sometimes you accumulate junk jobs. You need to renew your domain names, export your transaction statement, send that email to that guy from school, call back that person who left a message and then you have to take out the bloody bins. Rather than constantly interrupting your day with junk jobs, gather them up and do them in one morning. The danger with junk jobs is that they let you procrastinate. That 10 minute task can easily turn into a 30 minute task when you bookend it with Twittering. Set yourself three hours, and tick off one junk job after another. Once you’re done your list will be half the size and you can get on to doing the real work.

Do big tasks early.

Plenty of people suggest getting “quick wins” out of the way to build up momentum. This works sometimes, but more often than not clearing junk off your list before tackling a big job is just procrastination. Quick wins become more about seeming busy than they are about actually being busy. Worst of all, short tasks are the worst way to get into the zone. Big tasks, whilst hard to start, mean you’ll get more done in a shorter space of time.  You don’t need to be motivated to do the whole job, just motivated enough to start it.  The main reason to get your big tasks out of the way early is because they’re harder to finish when it comes to crunch time. If you’ve done all your big tasks, it'll be easier to find time to do the smaller ones at crunch time. That one big job you’ve got is unlikely to get any easier or any less important. Get it done first before moving on to the easy stuff.

Don’t do things in halves.

We all have to multi-task on occasion, but the reality is that we all suck at it. Dividing your attention between many tasks will make you less efficient overall. By concentrating on one task at a time, you’ll get all of them done a whole lot quicker. It is almost always quicker to knock over three full jobs than it is to complete six half-finished jobs. Working on one task at a time allows you to immerse yourself in that problem and see it through to completion. If you put it down only to have to pick it up again later, you have to relearn, rethink and remember. The less remembering we have to do for unfinished tasks, the more we can use our brains to remember more important things.


Coming up:

6 - Why task lists don't work.
7 - Sticky notes, and why they rock.


Optimize, don't Organize: Part 4

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here

4. What’s the worst that can happen?

So what if you forget? What’s the worst that will happen? Do you really need to remember everything? Consider this before you add something to your todo list.

If it’s important, someone else will remind you.

In reality, there isn’t much you’ll need to remember that someone else isn’t also remembering. That’s not to say you should just become an unreliable slob, but it does mean if you DO forget something, someone will most likely let you know. I wouldn’t plan my life around forgetting everything, but it is a reality that you can get away with not trying to remember every little detail. The more important something is, the more people you’ll have knocking on your door for it. If you’re being reminded constantly about doing something, writing it down isn’t going to help you any more.

If it’s not important, why are you prioritising it?

A todo list is a list of things that you really MUST do. If it’s not a must, it shouldn’t be on your list. The quickest way to kill a list is to fill it with things you really have no intention of ever doing. If you add every little thing to it, you’ll quickly end up with a MAYBEDO list, not a TODO list. Nobody wants a MAYBEDO list; it just sounds stupid.

It’s important to you.

This is the one and only item that should be on your todo list. Your list is about you. That doesn’t mean you should fill your list with Golf, Video Games and Beer. Sometimes things that are important to you aren’t necessarily fun, but they still need to get done. If your list only has things which YOU find important on it, you’ll be far more motivated to tick things off. As soon as you hit an item that is for someone else, your list will fail. If it’s for someone else, let them put it on their list. However, buying flowers for your wife may be FOR her, but it’s still in YOUR best interests. The key here is that if you forget something on your own list, there will be no one to remind you, and you’ll only screw yourself over. The problem will be all yours. If that’s the case, put it on your list.


Coming up:

5 - The better way to prioritize.
6 - Why task lists don't work.
7 - Sticky notes, and why they rock.

Optimize, don't Organize: Part 3

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here


3.Too much information is a bad thing.

If you don’t rely on your memory enough, you will get slow and lazy.  Conversely, if you try to remember too much, you end up remembering nothing. It's not only important to remember the right information, it's important to not overdo it. By trying to remember or learn more than you actually need, the important details can become lost in amongst the redundant details.

Information overload.

I remember at high school and university how much I’d laugh at people summarising text books. I can't think of a more useless activity. Some students would take a 400 page text book, and summarise it down to a 50 page set of notes and take that into an exam. These are the people that invariably don’t finish exams. They spend more time looking up examples than they do actually working. There is a balance. My “cheat sheet” only ever consisted of formulae that I really had no hope of remembering. While they were summarising, I was revising the application of these formulae. Everything in an exam is an application of knowledge. If you don’t trust yourself to hold that knowledge, how can you possibly hope to apply it? 

Long lists never last.

A mountain of notes, when finished, seems to be an insurmountable challenge. Similarly, long todo lists are more scary than they are helpful. In an attempt to get organized, the first thing everybody does is write down a todo list. Then they see a mountain of work and give up in disgust. Long lists are the world’s worst motivator. Yes it might feel good to tick a few items off, but when you feel like you’re not even scratching the surface it becomes a big turn off. You don’t even want to look at the list for the fear of rapid onset depression. The longer the list, the quicker you will drop it. If you must make a list, list the things that you need to do today or this week. Keep next month’s out of sight until next month.

Be selective about what you write down.

Some things you really should just remember. Your partner’s birthday, your computer password and when that “really important thing” is due are things you should probably be able to remember. If you need to write these things down to remember them, you’re going to find yourself in trouble. Over reliance on todo lists is as bad as not having one at all. As good as my wife is at organising, she can never remember our anniversary without looking it up first. One day you’ll be caught without your precious list, and then you'll find yourself red faced, or worse. Barring serious health concerns or a head injury you’ll always have your memory with you. Trust it...even if it is just a little bit. Over reliance on lists and notes just makes us lazy.

Coming up:

4 -  What's the worst that can happen?
5 - The better way to prioritize.
6 - Why task lists don't work.
7 - Sticky notes, and why they rock.


Optimize, don't Organize: Part 2

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

Read Part 1 of Optimize, don't Organize here

2. Work to your strengths but remember your limitations.

I’m usually a great navigator. I refuse to buy a GPS, not because of some manly desire to always know the directions, but because it’s a fantastic mental exercise. I enjoy the test of looking at a map, remembering the route and then getting there. What's even better is being able to get to some new location a second time, without needing to look it up again. I don't have a great memory for details, but I have a great memory for generalities. Knowing this strength and weakness of mine is how I never get lost.

Remember the turn, not the name.

The usual method for navigation is to write down a step by step recipe, “Right at York, Left at Sayers” etc. Recalling these instructions not only involves remembering many distinct (and often peculiar) names, but it requires looking for itty bitty street signs whilst trying not to run over small animals or old ladies.

The problem with remembering specifics is that it's far too easy to get them wrong. This is especially true in suburbs where street names are often along a certain theme. Our suburb, for example, are named after New York streets. I grew up in a suburb where the street names were all native trees. The cues we use to remember words or names are easily confused when you're forced to pick one name from many thematically similar names. This is especially true when you see them one at a time instead of as a whole.

In reality, it’s far easier to remember to turn left after the sports ground, or right at first roundabout, or straight until you reach the school. In a broader context, it’s easier to remember generalities than it is to remember specifics, but more on that in a moment. It also means that once you've been to a location once, you have a visual memory of where to turn instead of just a name you need to try and recall. 

Know when you don’t know.

Before I go any further, if you’re lost, pull over and look at the damn map. Nothing will make you look like more of an imbecile than driving around protesting, “I’m sure it was a left at that last junction”. If you think you got it wrong, own up to it. Stop and have a look. Nobody will ever get angry at you for not knowing everything, but they will sure get pissed if you pretend you do.

In any situation, it's always better to say you need to look something up than to pretend you know. I've conducted possibly hundreds of job interviews of the years, and one trick that never failed me was to ask a candidate a question which they could not possibly remember. At least 80% of people try to prove their worth by having a guess, rambling incessantly and just hoping they hit the right answer or worse yet state a blatant untruth with absolute conviction in the hopes that if they believe it we will too. The 20% that say, "I don't know, I'd need to look it up" are the ones that get a big tick in my book. I'd rather work with someone who knows they don't know than someone who'd rather lead us all down the wrong path in an effort to impress.

Broad concepts are easier to recall than intricate details.

If you were to describe a movie plot to someone, you talk in broad terms about big ideas. It’s unlikely that when describing Die Hard (the first and best), that you’d feel the need to mention that it was in LA or that the protagonist's name was John McClane. What you’d more likely describe is, a cop, a terrorist, an office tower, explosives and hostages.  Even if you haven’t seen the movie in 20 years, that is enough for you to start recalling your own finer details about the movie. Therefore, rather than trying to recall specifics, recall the big picture stuff and let your subconscious fill in the gaps for you.

Just as remembering a sports ground is easier than remembering a street name, it's also easier to remember general programming concepts than it is to remember specific syntactic rules. It's the main reason why when a developer learns one language, they can often easily jump from one to the next. Once you learn how to create a loop in one language, applying that same knowledge anywhere else is simply a matter of looking the syntax specifics of that language.

In a wider sense, broad knowledge of how an internal combustion engine works is far more beneficial (and easier to learn) than it is to learn the specifics of a particular make and model of car. Before fuel injection engines came along, pretty much ever car worked the same way. If you had replaced the distributor off a Toyota, you could probably do the same on a Ford. Knowing exactly how a distributor works isn't as important as knowing that all cars have them.

Learn to apply, not to recall.

Unless you’re responsible for making split-second decisions in a critical scenario, you are most likely always going to have time to stop and look something up. It’s far better to learn how to research and apply knowledge than it is to remember things off the top of your head. This is especially true given the wonderful source of information and knowledge that is the Internet.  Whilst you may forget the specifics you learn today, you will still remember the general application of that knowledge in 20 years time. 

If you have put your efforts into learning general principles and broad concepts, when you are faced with a new problem at the detailed level, your broad knowledge will allow you to fill in the gaps. Being adaptable is about taking general learning, twisting it and making it fit a new situation. If, in school, you spent your time memorising the formula for Newton's Second Law (Force = Mass x Acceleration), it will assist you in solving exactly one problem. If instead of memorising the formula, you learned how it can be altered, rearranged and applied with other formulae, then whenever you're confronted with any one of a hundred different problems, you're understanding of the concepts behind it all would allow you to invent a means to solve the problem. Anyone who spent their time rote learning formulae failed to gain the ability to apply the formula they're remembering!

In short, it is always easy to look up specifics, and it is always hard to look up their application.

Coming up:

3 - Too much information is a bad thing.
4 -  What's the worst that can happen?
5 - The better way to prioritize.
6 - Why task lists don't work.
7 - Sticky notes, and why they rock.

Optimize, don't Organize: Part 1

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at [email protected] or even Twitter @alandownie

1. Don’t remember what you don’t need

I drive some people crazy; especially my wife. To some people I seem forgetful and careless; to others I appear efficient and percipient. It all depends on the person and the context. I make a point to remember things which I need to remember, and I rely on people, resources and notes to cover the rest. Forgetting stuff I don't need leaves room for things I do need.

There’s no need to remember something someone else will. 

My wife is a list person. Everything we ever do individually, socially or financially is written down in a list somewhere. I don’t need to remember where we’ll be for lunch next week any more than a security guard needs to know “today’s specials” at K-mart. In the context of databases, we’re a highly normalized couple...but only in the context of databases. Just as she need not understand the inner workings of our Rancilio espresso machine, I need not know what we’re doing next Thursday at 6pm. This isn’t a matter of delegation; it’s a matter of playing to one's strengths...or to someone else’s as the case may be. 

There’s no need to remember something you don’t need to know. 

If you were to ask me what our quarterly tax bill is, I wouldn’t be able to tell you. There is little point in me remembering, or even knowing when our accountant has it more than under control. I have a vague inkling that my birthday is somewhere in September, but I’m damned sure to remember my wife’s and son’s. The point is, remembering things which we will never need to act on just fills our minds with information that will never be useful. Remembering all the capital cities of the world may make for a fun trick at dinner parties, but unless you're choosing "Cities of the World for $500", there is not otherwise a lot of point.

There’s no need to remember something you can look up. 

My domain is here in front of my computer, developing software. I have over 10 years experience doing just that. Surely by that measure, I’d be able to code blind in any of 5 different languages? Sorry to disappoint, but no. I tackle every problem on its merits. I rely on proven techniques, of course, but more frequently I refer to previous work done, or online resources. The recall of knowledge is far less important than its application. Besides, do you really think you can remember everything about a certain API, language or framework? Even if you could, it’d only be out of date next year, so why bother? There are certain tools or techniques which never date and are broadly applicable, these are worth remembering. But remembering specifics or minute details which may only server you once or twice in your programming life is a complete waste of space.

Be an expert on things you DO need to remember. 

Of course, it’s not all as easy as forgetting whatever you like. The idea of clearing space in the old memory banks is to make room for something else. In this case, when you’re expected to be an expert, you MUST be an expert. In situations when you can’t rely on someone else, you can’t look it up and you really DO need to know, then it is absolutely essential that you have the answer. It’s ok to be a slacker when it doesn’t matter, but when something is your responsibility and people look to you for the answer; you have a duty to those around you to know your stuff inside out. We're not all programmers, and we don't all of the Internet at our fingertips every day of the week. If you need to know your stuff, make sure you bloody well know it.

Coming up:

2 - Work to your strengths, but remember your limitations.
3 - Too much information is a bad thing.
4 -  What's the worst that can happen?
5 - The better way to prioritize.
6 - Why task lists don't work.
7 - Sticky notes, and why they rock.