Recently I’ve been getting spam from the “standards organisation” OASIS inviting a company that I don’t work for1 to join a new standards initiative. There’s no pretense that I’m being invited because of my clearly superior knowledge of the area involved, merely that the company could get great advertising exposure by participating – including being listed on a press release! Naturally we’d need to become OASIS members and pay the appropriate fee, and to be in the press release you’d have to be at minimum a “sponsor level member”.

On the one hand it’s nice that they aren’t pretending to be anything other than a for-profit marketing company, but isn’t it a bit sad that we think standards are just a marketing tool?

1 – yes, they’ve done so much research into how much I have to contribute that they’ve got the company wrong ↩

HTML 5 Boilerplate reminded me of an old-school tool which is extremely useful for concatenating JS and CSS files on the fly – server side includes:

<FilesMatch ".*\.combined\.(js|css)$">
  Options +Includes
  SetOutputFilter INCLUDES
</FilesMatch>

Then you have a main scripts.combined.js (or css) which contains:

<!--#include file="libs/backbone-min.js" -->
<!--#include file="libs/underscore-min.js" -->
<!--#include file="libs/jquery-1.7.1.min.js" -->

Plus any other files you need, in the order you specify. This works great for development mode so you can change a file on the fly and just refresh the browser without running any kind of build script. When it comes time to push to production, it’s easy for a build script to process the file ahead of time and be confident that you’ll get exactly the same result.

This evening I stumbled across two interesting posts about alternate layouts for pairing rather than sitting side by side. Firstly Tom Dale talking about Tilde’s corner desk pairing setup (and some of the software setup they use) and that was inspired by Josh Susser’s face to face pairing setup at Pivotal Labs.

Both approaches require more floor space which makes them difficult to setup but I would expect the face to face pairing to be a heck of a lot better if done well. I’ve always preferred having separate screens in mirror configuration as well as separate keyboards and mice to allow the developers to sit a little further apart to be comfortable and to be able to look straight ahead at the screen. That said, I quite like having a second monitor for spreading out windows as we have at LMAX so it’s not clear cut which is better.

It’s also interesting to note the popularity of the flat screen iMacs as opposed to Mac Pros or laptops. The former being too expensive for extra power and extensibility that generally isn’t required and the latter often being a bit too individualised to be good as pairing machines. Plus laptops, while amazingly powerful these days still have less bang for the buck and the reduction in performance is just enough to matter for development.

Yan Pritzker recently posted “5 ways to get insane productivity boosts for coders” which provides some good tips on how to improve your usage of tools when doing technical work. To summarise:

• Never look when you can search
• Don’t repeat yourself (by setting up shortcuts and command line aliases)
• Learn a scripting language
• Learn an editor (and use that editor everywhere)
• Learn regular expressions

However, nearly all of these tips really boil down to how to be more productive at writing text and the mechanics of writing code – editing actual source code files, jumping to different places in those files, executing commands more efficiently etc. Are these really the tasks that consume the vast majority of a developers time?

While often it feels like they are, after all we spend all day working with a text editor or the command line, are we really spending all that time struggling to keep up with the stream of code our brains are trying to output? Personally, I spend a lot more time thinking about what the best algorithm is, what direction we should be pushing the design in and how to do that and so on. Rarely do I need to type at full speed for extended periods of time.

Given that, I suspect the real bottlenecks in developer productivity are more along the lines of:

• Comprehending an area of code and its design
• Identifying, evaluating and selecting potential solutions to a problem (be that choice of algorithm, design choices or choice of classes/libraries etc)
• Understanding and sharing a design vision within the team
• Understanding and sharing requirements within the team

This isn’t an exhaustive list but it should give an idea for the types of things that really limit programmer productivity. In other words, someone who types with two fingers can be much more productive than someone who knows every shortcut in their editor if they are able to identify a simpler solution to the problem.

For example, recently LMAX needed to make a large and potentially quite risky change to how our system worked. The change affected a core concept in the system and so could have knock-on effects to a wide range of components and be very hard to test effectively. At the start of our two week iteration we already had a potential solution planned out but the developers were uncomfortable with the amount of risk involved with that plan. So we spent a full week discussing options, exploring the code and experimenting, plus talking with business experts to get a better understanding of the domain model. All that discussion led us to find a much simpler solution which, if something was missed, would be sure to cause failures in our existing acceptance tests. Even counting that initial week of discussion, finding the right solution meant we could deliver the change in about half the time we had expected.

So by all means, spend time learning to use your tools better, it avoids a lot of tedious boring work, but if you really want a step change improvement in productivity, work to improve you communication, design and thinking skills.

If you’re experiencing an issue when using Chrome with Google Maps where typing in a location and hitting enter either does nothing or just says “Loading…” forever, you’ve very likely hit upon a bug in the Skype click-to-call extension.

Skype automatically installs this “add-on” when you install Skype and it adds links to phone numbers so that you can click them to call on Skype. Unfortunately, Google Maps seems to be triggering a bug in the extension and so it is either corrupting the data returned to the Google Maps javascript or just preventing the request from ever returning.

To solve the issue, just uninstall the Skype click to call add-on. I did that by right clicking the Skype icon in the toolbar and selecting “Uninstall” but it should be possible to remove it from the about:extensions page.

I also found a Skype click-to-call plugin in about:plugins that I disabled as well – I’m not sure if it’s removed along with the extension.