Matthew Lang

Love the paint job on this Pista.

via FGGT

A few weeks back I tried to improve some code I was working on, but after a couple of hours I resided myself to the fact that it just couldn't be done in that small space of time.

Yesterday I looked at the same code and within half an hour managed to make a big improvement to it. So what was the difference between yesterday and a few weeks ago?

It could have been a number of different things. What was my workload like that morning? Did I have other things on my mind? Did I start the day with tea or coffee? Who knows. Hundreds of different factors could have affected my thinking that day.

When you're working you focus as much attention and energy as you can on delivering what is expected of you. Some days though you just need that bit longer to get your head round something.

We can't always be thinking and working 100% effectively all of the time. What I do know is I can't be switched on all the time.

via Singletrack

Ever that get that feeling where you're continually picking up pace with work and you get faster and faster at getting through your list of tasks? The last few days have been like that with my work for a client. Fast paced work, getting things done. Great for the client when you can carry out the changes they need quickly.

However there comes a time where this pace of work becomes counter-productive. While I can recall the details of each code change I made for the client, I wonder if I'll still remember those changes next week? Have I spent enough time reviewing each of the changes I made? Are there enough tests to cover the code changes I made? Could the code have been refactored in a beneficial way?

Getting things done is great, but getting things done correctly is even better. Checking things off from your list is great, but a review of the work for a few minutes is even better as it could lead to you finding something that you might have missed. Don't forget to review the work you do to ensure that it's your best work that you can deliver.

Yes it's that time again where I consider moving to another blog platform. Over the last few years I've tried Blogger, Wordpress, Tumblr, Posterous, Octopress and now I am currently on Squarespace.

The key benefit for me at the moment is that I can have two active blogs sitting on one site without having to separate them into different sub-domains. However I am wondering about merging my two blogs back into one so this isn't a big influence on the decision. What I do want is ease of deployment and a bit more control over my blog.

In the last few weeks I have just about nailed the setup on my favourite text editor and it now doubles up as my main tool for writing in Markdown. Squarespace does support Markdown, but I wish I had an easier way of posting to my blog.

Octopress is calling again, it did have a nice easy way of publishing, but I like the ability to post from the web which Squarespace does allow.

Hmm, a tough decision.

Test-driven development (TDD) is often seen as the long way to developing software. The misconception perceived by many is that writing tests and code is going take longer than simply writing code. While this statement is in fact true, many don't take into account the what's happens further down the development process.

Developers that practice TDD are continually writing tests to ensure that all parts of the software work. This practice reduces the chances of bugs appearing in the code in a later date. Developers that don't practice TDD are writing code that is usually handed to another team for testing. Chances of the code containing bugs at this point are quite high, and so a game of ping pong ensues with the code moving between the developers and the testers until it is working. This can ultimately take longer than the time it took a developer to produce the same code using TDD.

Selling TDD to clients is difficult because they don't see the benefit of this practice. Clients want their product and the want it now. Writing tests takes too long. It puts the developer in a difficult position. Do you take the gig and hope to squeeze in the tests as your developing and hope the client doesn't notice? Or do you take the gig and forgot about the tests knowing that future work will come back to you in the form of bugs that the client has discovered? Of course the last alternative is to not take the gig at all.

The long path that clients see when they are told about TDD isn't as long they think it is. In fact it is actually worth their while to spend the time investing in tests that ensures their code for their product or service continues to work in the future. Following the path of not writing tests might look like the short path to start with but there's no guarantee that it will stay that way.

Then tune in every day to Nicholas Bate. I especially like the last one on the routes to more business list:

Never, ever, ever allow yourself to doubt that you can get a bigger slice of the pie.

via FGGT

Not everyone is cut out for it. It takes not only a passion for the work but plenty of sacrifice. It means there will be no paid vacations or retirement fund matching or group healthcare plan. It means years of saving and planning and struggling and scrapping. But you will know, in those tough years, if it is for you. Because those struggles will not deter you — they will fuel you. Because, that is all part of the work too.

— A Passion for Work by Patrick Rhone