Matthew Lang avatar

Contemplating a blog move

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.

The long path

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.

Do you have a passion for work?

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

Be a game changer

It’s a sad fact of life, but there’s many workers out there simply dotting the i’s and the crossing the t’s when it comes to their jobs. They start at nine, do what’s required of them, and then make a bee-line for the door at the end of the day. I'll be the first to say that even I have been guilty if this behaviour. Yes, you are doing your job, but surely there’s more to your job than doing the minimum necessary?

It’s not always the worker’s fault though, many jobs out there just don’t ask or want people to be creative. They look for the basic skills needed for the job and nothing else. Many employers just want the job done and nothing more. Is that enough?

NHS meals idea

James Martin, a British chef and TV personality had a show that recently ran on TV, where he was trying to improve the kitchen and meals service of a number of NHS hospitals in England and Wales. In one show, he improved the costs of one kitchen by reducing the amount of waste food generated. Rather than just making enough meals so that everyone had a choice, James suggested that the kitchen staff take orders for each ward and make enough food to fulfil the orders.

From one day’s service, the kitchen had reduced it’s waste and also it’s costs. That cost projected over a year ran into a saving of tens of thousands of pounds. As anyone who knows about the current state of the NHS and it’s financial problems, ideas like this are exactly what’s needed to improve the NHS to allow to run effectively and also pay for itself.

When the kitchen and meals manager was shown the savings, she did nothing more than just smile. Why does it take a celebrity chef to come in and implement such a simple idea that saves thousands of pounds for the hospital? Where’s the innovation from inside the NHS? Do employee’s even have the time to be creative during their jobs?

Be innovative on company time

In a previous job, I wanted to compile a newsletter for customers notifying them of news and events in the world of ERP software. I pitched the idea to my boss at the time, who wanted the same thing done. I suggested putting together a first draft of the newsletter together and sending it to him before sending it to customers. I was asked by my boss if I could do the newsletter in my own time. So I have an idea, but I must do in my time?

I don’t know if my employer at the time was aware of this fact but I have my own things to do in my time. Working on ideas that benefit my employer in my time is not own. And here in lies another problem. Employers need to allow their employees to be innovative and creative on company time.

I’m not suggesting that every company should follow Google’s example of allowing their employees to be creative. What I am suggesting is that employers allow their stuff to set aside some time to develop ideas and be more creative.

Being a game changer at work means doing more than simply doing the absolute minimum necessary to get through the day. Being a game changer means thinking about the work you and continually reviewing your work to look for more effective of ways of doing things. Not only does that require that as a worker you be more productive, but as an employer you need to allow your employees to be creative and develop idea during company time.

So what are you waiting for, how can you change your game today?

So Google Reader is finally being killed off. The RSS reader that spurred many clones and provided a way for you to follow any number of your favourite blogs easily is to close down this summer.

With very few updates to the service in the last couple of years it is hardly surprising. It might be a bad day for Google Reader fans but there's an opportunity here for someone to earn themselves a nice fortune.

The space left my Google Reader now means that there's a place for a well designed cross platform RSS Reader.
And I'm willing to pay for it.

Over the next few days I'm going to be looking for an alternative to Google Reader. It's sad to see the service go but nothing is forever. The one good thing from this is that Google Reader already provides a way for you to export your feeds. Shouldn't be too difficult to get up and running on something else soon.

Reviewing the master list

It’s become clear to me that there’s far too much stuff on my master list. It’s things that I want to do, but I’ve started reaching too far forward into the future and starting noting stuff down that I want to do but I won’t be able to do for at least six months.

Speculating on what I should be doing in months is no good. I need to see a short term list of things that I can be working on now rather than later. My master list is also slightly unbalanced.

One thing I can do about the issue of the number of items in my master list is to adopt an idea from
Kanban boards. In a previous role in an agile team, we kept a backlog of development cards that represented application changes that were next in line to be worked on.

In order to keep my master list lean but still keep a note of stuff for the future, I'm going to keep a separate backlog file that contains actions for projects that I want to do in the future but perhaps don't have the time in the near future. Doing this and reviewing it once a month will also mean that I can just forget about my backlog until I have cleared everything from my master list.