Matthew Lang

Nice geometry on the Dart.

via Pedal Consumption

Curtis McHale sums up why clients should wait for their favourite consultant.

Think of Gandalf (Lord of the Rings wizard if you don’t know). He was always running from one place to another. Someone always needed his help. He was a busy dude and couldn’t just take on every issue at the drop of a hat.

Any decent consultant is going to be like that. Really if you need more than a few hours of work, you should be expecting to wait.
— Wizards are Busy People by Curtis McHale

Never thought of myself as a wizard before though, but I do like the idea.

No way could I build an online product.

That was me two years ago. Thankfully my confidence has went up since then, but it took me some time to get to the point of shipping a product online. To do this I wrote about my product and what I hoped it would do. I put it down on paper and then started to realise how simple it would be to build.

Michelle's 11 point list is a great place to start if you want to "pick yourself".

1. Write. Set aside time to ask questions, dream, think big. Put your phone on silent and set an alarm twenty minutes out.
   — 11 ways to "pick yourself" by Project Exponential

Read on for the full list. It's worth it.

Last week I started work on an idea for application. Just a small prototype of the idea really. No tests, no fancy user-interface, just the bare bones of the idea. In typical agile fashion I wrote out some of the basic features that I needed for the prototype as user stories on index cards and then set to work. Then a call from a client came in and before I know it, it’s two days later and I’ve not started work on the prototype.

My problem is that I’m starting client work as it comes in and my own projects are getting done in really small pieces. I am not keeping a daily schedule.

Truth is I haven’t kept a schedule of my work for at least a couple of years now. Not since I worked at a consultancy where you could plan your day most days. There was days where you would have interruptions to your schedule, but as it was customer support calls, you had determine if the customer’s support issue was that important that it had to be resolved there and then. With interruptions like this mounting on daily basis, I abandoned my calendar of work and just did work ad-hoc.

Now though I am more in control of my own time and schedule. I am my own company and I need to schedule work to ensure that client work gets done most days, but I also allow for some time to work on ideas and products.

Scheduling your work in a calendar is a commitment to getting that work done. I have the benefit of having a laptop with an external monitor so I use my laptop as my secondary screen. On here I have my calendar and I leave it open while I am working as a reminder to stay focused on the task I have set myself.

I’m using Apple’s Calendar application and the iCloud service to synchronize my calendar to my phone. This makes it easy for me to schedule stuff in my calendar when I am away from my desk. I use the brilliant Fantastical app to manage my calendar from my phone. It has a great agenda view for upcoming appointments and it has a very easy appointment entry system that means you don’t need to fill in four different fields to make an appointment. It’s smart enough to know that “10am Meeting with client” should be scheduled for 10am.

Scheduling your day and your week is a great way to making a commitment to getting things done. It’s more structured than a to do list, but provides a way of breaking your day down into chunks so that you’re not working on the same thing for hours or days at a time.

There’s a great line from the start of “Pirates of the Caribbean: Dead Man’s Chest” spoken by everyone’s favourite pirate Jack Sparrow.

Complications arose, ensued, were overcome.

If only it was that easy. It is never that easy. When complications do happen, are we making things complicated for ourselves?

I do. I make things ridiculously complicated sometimes when I’m writing code. I’m always thinking too far ahead. What if we need to do this, what if the format changes? I’m always thinking of edge cases for features that won’t be encountered on a daily basis. I find it quite a hard habit to break.

Take for example this form I was working on yesterday. It required three things:

1. A question
2. Your email address
3. A list of other email addresses

So handling the first two things is easy, but I wanted to do something smart with the list of email addresses so that people could input any number of email addresses. I ended up with a form like this:

Handling the code to add and remove the email addresses from the list wouldn’t be too difficult but it’s clearly not the easiest thing to do. Annoyed at the complicated form I would need to build, I left my project to do some client work that had been scheduled in.

Then it hit me that night. What else uses lists of email addresses that are not constrained by size? When you are writing an email you simply enter the names of the people you want to send the email to. In one textbox. It’s that easy. The next day I changed my form to use a single textbox for the list of email addresses. A complicated form made easy.

Two things I took from this:

1. Keep it simple stupid

The KISS principle is a recurring topic in software development, but we developers tend to think of the YAGNI (You aren’t gonna need it) principle. The two are similar, but what I need to remember is the simplest and stupidest way is always going to work. It might not be clever, but as long as a simple design works, we should use it. If the simple design can’t handle an edge case in the future we can fix it then. There’s no need to worry about it for the moment.

2. Look to other examples

When building software, there’s no shortage of examples that you can refer to for influence. I’m not suggesting that you take a straight copy of a unique feature for another product, but when designing processes for your application, it can help to look to other examples to see how it is handled already. It’s probably going to be simpler than you first thought. I didn’t even think to initially look towards other examples of how this could be done. I could have saved myself a lot of time.

So there we go. My complications were not as quickly overcome as Jack Sparrow’s complications, but then he doesn’t write code does he?

Journalong is just one of a number of options that I could recommend. But there are others if saving your journal entries to Dropbox isn't your thing.

Peter Aitken kindly informed me of a new service, Oh life, that uses just email for your journal. Looks great.

Realise your own energy distribution with Nicholas Bate.

Great analogy on deadlines for engineers.

Similar to a soccer game when your opponent leads 0:1 and there are only 5 minutes left on the clock. The team will try everything to score asap. But outside of such pressured situations the team simply focuses on ball possession and making good plays. There is nobody asking the players at what time they will score the first goal. Not before the game and especially not during it.

— It Ships When It Ships by Bjoern Zinssmeister

Over the weekend I was looking for a replacement for Google calendars. I was sure that I would be at least using Apple’s Calendar service and iCloud, but I wasn’t sure what other tools would be great to support this. So I asked my ADN friends for their recommendations. Within minutes I got a few from people with their favourite scheduling apps and tools. There was a clear favourite but I wanted to wait for more responses. I left it to the next day for more people to reply. The next morning I reviewed all the responses that people had sent to me.

As a thank you, I composed a single post the next day just saying thanks to all of the people that replied to my question. They didn’t need to reply to my question, but they did and I’m thankful for the responses they gave me. Trawling through the responses was a bit of a chore but I managed to get everyone’s name in one post and sent it. It would be nice if you automate this kind of thing.

It gave me an idea. An question and answer management tool for App.net. It’s probably not on the priority list for many users on App.net, but for those that are looking to streamline the question and answer process and make it easier I had a vision for a small service that would do the following.

1. It would allow you to compose #askadn questions with optional hash tags for preferred answers that people should give.
2. It would aggregate the results and keep totals for each response by looking for preferred hash tags in replies or by looking for recurring words in the replies that are given.
3. It would compose thank you posts for all the people that took part. If all the respondants don’t fit in a single post, the thank you post could be split into a number of posts to thank groups of respondants.

It’s just an idea, but the reason I am putting it here is that someone else might already be in the process of building something similar to this idea. Maybe no one is building it, but perhaps someone will. If no one builds it, then I will.

I’m just throwing this out there.

Amazing account of the moving of these spy planes from the Lockheed plant to Area 51.

Dorsey Kammerer was appointed to head up the activity to build and use the transportation carriage system. An early-on step was to equip a pickup truck with a set of extension poles sized to the width, height of the main transport carriage trailer. An initial plan was to drive the best estimate route of travel, noting the obstacles to easy movement of the carriage boxes. Several photos show this arrangement and its use along the roads.

— Transporting the A-12 by Roadrunners Internationale