Changes!
You may have noticed that the layout of this blog has changed and a few new features have appeared. I have implemented a couple of things I have had on my to-do list for a while now.
Three Column layout
I have been finding that a two column layout does not have sufficient space for all the widgets I would like to have, without having to resort to a really long second column. So after a bit of thinking and some research I converted my current theme into a three column layout.
I found the following two posts very helpful when converting my theme into a three column layout: Adding Extra Sidebar to your WordPress Theme and How to Create Multiple Dynamic Sidebars for WordPress Widgets. I also found the CSS Edit application by MacRabbit to be an essential tool for easy CSS tweaking, its so good I actually bought a licence.
Most Popular Posts Widget
It is important to be able to point visitors to the most popular content to keep them interested. The ‘Most discussed posts’ widget provides a customisable list of the most commented on posts on your blog. There are other widgets that can list the most popular posts by visits (page views) but they require extra database activity to record the visits which I’d rather not have to use on my hosting plan.
Google Reader Widget
This widget interacts with Google’s Reader service to provide a list of your recently shared items in Google Reader. This is a great widget for sharing the posts or articles you have found most interesting with your readers, you can even add comments to each item. This won’t completely replace my Friday linkage posts as there are sites I find without going through an RSS feed but it is something I have wanted on my blog from its conception.
Twitter for WordPress Widget
I have been using this Widget to display my latest tweets for a while now. However due to not having enough space in the second column I’ve never been able to have more than my last tweet visible. Now I am using a three column layout I can now have my last few tweets displayed which I think makes them a bit more coherent.
RSS Icon Widget
An RSS feed link and icon is something I have been wanting to add to my template for a while, this handy little widget lets me do just that without any template voodoo. Although it would be nice if it could also give and icon and link for the comments feed too.
The main thing I have left to deal with is some further minor tweaking of the theme and to replace the current banner with something a less geometric and a bit more fluid and interesting. For the new image I had been thinking of something to do with ink in water but so far I’ve not found the sort of horizontal image I’d like.
Beware the Golden Hammer!
The ‘Golden Hammer‘ is a very common anti-pattern, which can be best summed up by the phrase “if all you have is a hammer, everything looks like a nail“. This anti-pattern occurs when the perpetrator has typically learned a particularly powerful technique or design (the hammer), which they then go on to apply blindly to all problems (the nails) they encounter whether it is a suitable solution or not.
This can be especially evident amongst beginner programmers, who are learning new techniques almost constantly, but it only seems to become a dangerous anti-pattern if the individual becomes overly fixated on a particular technique.
Interestingly this anti-pattern can apply to more than just individuals, in my experience it can also apply to teams or even entire organisations. One of the ways I have seen this manifest at a team or organisational level is with attempts to solve social problems with technology solutions. This trait seems to be especially strong in software development organisations: perhaps because technology is their usual solution to problems.
Such social issues faced by development teams and organisations can include things like not breaking the build, lack of communication or lack of testing. These problems really are not technology problems, they are social (people) problems, yet time and again I have witnessed technology solutions to these problems. For example, more elaborate and sophisticated check-in systems being introduced in response to constantly broken builds, where a much simpler social solution such as peer pressure to not break the build would be much more effective.
Avoiding the Golden Hammer when programming is achievable with some self awarness and honesty: are you using your current technique for the right reasons? However, identifying and interveening when a team or organisation is about to use the Golden Hammer is much more challenging as it can involve going against the solution favoured by the majority along with the polical implications that brings…
Challenged to grow
I have come to the realisation that the most experienced person in a group is not usually the person getting the most benefit in terms of skills or experience gained when working on a collaborative project. In fact the more experienced the individual the less benefit they stand to gain, the inverse is true of the less experienced individuals who due to their low levels of experience have the most to gain.
This balance can be seen in most projects involving more than a couple of participants. A team’s experience distribution can typically be visualised as a pyramid with the most experienced individuals at the top of the pyramid and the most numerous and least experienced group of individuals at the bottom. There is the occasional team where the experience pyramid is inverted but I have yet to have the opportunity to work with such a group.
The experience composition of a typical team usually works quite well, with the more experienced members directing those that are less experienced than them. This helps to explain why the more experienced you become the more time you seem to spend in meetings planning, discussing and thinking about the design of the product.
The breakdown of the project tasks based on individual experience levels also means that each individual should be supplied with tasks that are mostly within their capabilities. Some stretch tasks should also be set (with sufficient support from more experienced team members) to ensure each individual continues to develop their skills. This should mean that the tasks you work on should be within your capabilities and as your capabilities increase so should the complexity of the tasks you are set, to prevent stagnation.
It should be noted that if an individual fails at a task then their next task should be something that is well within their capabilities. To do otherwise is to risk a loss of confidence, as multiple failures in a row can seriously undermine an individual’s confidence and ability (see negative reinforcement). This is why most modern coaches will not allow their athletes to finish a training session with a failure.
Tasks that stretch or challenge you as an individual are a good thing but they should not be forced upon you and they should not be chained together, some respite is required between challenges. More experienced team members are an essential resource to those undertaking stretch tasks due to the advice and moral support they can offer.
No bad programming languages
I encountered some truly hideous source code today in a programming language in which I wouldn’t have thought hideous obscure code was possible: C#. It was my first real experience of abject horror when looking at the source code of a C# application. Obviously with hindsight it would seem that you can write hugely, dense, brittle and hard to understand programs in any programming language. And yet I would not expect a C# source code to be this obtuse or brittle but I would expect a Perl script to be dense and hard to read.
It is not that I have anything against Perl as a programming language: it is a fine language. I find that Perl’s motto of `There’s more than one way to do it.’ means that it is a programming language with (you guessed it) more than one way to implement most operations. This flexibility is a double edged sword: it allows a lot of creativity in program implementation, yet it also means that a dozen Perl coders will produce a dozen radically different scripts for the same problem. This makes Perl quite hard on beginners or infrequent maintainers of Perl scripts: as to understand any given Perl script requires an understanding of much more of the Perl programming language than it would for most comparable programming languages.
I digress.
I’ve known for years that it is possible to write awful obscure code in low level languages like C and C++ but it really hadn’t occurred to me that a high level language like C# could be abused to the same degree. Thinking about this some more, it is not the fault of the programming language itself but of the programmer that is using it.
So, brittle obtuse code is the result of a bad programmer not a bad programming language: well except maybe Brain Fuck (but thats kinda the point).








