A pig and a chicken decide to go into business. After bouncing a few ideas around, they decide to open a restaurant. “What shall we call it?” says the pig. “Ham and eggs,” says the chicken. “No thanks,” says the pig. “You’d just be involved, but I’d be committed.”

Thankfully, this was removed from the latest version of the Scrum Guide.

It’s not difficult to see why. When you say “pigs and chickens” to someone these days, they don’t think about a cheesy, inexplicable, unfunny joke about commitment and involvement and restaurants. They think about this:

Somehow, I don’t think the idea of developers stealing the stakeholders’ eggs and the stakeholders launching themselves at the developers with a massive slingshot in retaliation would go down that well with management in many organisations.

Some people argue that the features of CSS pre-processors such as variables aren’t necessary if you write your CSS correctly, and indeed, there are design patterns that aim to reduce repetition and magic constants in vanilla CSS. One such example is Object Oriented CSS (OOCSS).

OOCSS sets down two main principles:

• Separate structure and skin
• Separate container and content

I won’t discuss these in any detail here (you can read about them elsewhere), but I’ll just give an example. Whereas with a CSS pre-processor, you might write code such as this:

@small: 12px;

.sidebar {
  background: #ccc;
  font-size: @small;
}

.permalink {
  border-top: 1px solid #ccc;
  color: #333;
  font-size: @small;
}

<div class="sidebar"></div>
<div class="permalink"></div>

in OOCSS, you would use a separate class called small instead of the variable:

.small {
  font-size: 12px;
}

.sidebar {
  background: #ccc;
}

.permalink {
  border-top: 1px solid #ccc;
  color: #333;
}

<div class="sidebar small"></div>
<div class="permalink small"></div>

There you go. Vanilla CSS. DRY vanilla CSS. There’s no need for a pre-processor after all, is there?

Is there?

There is one big problem here. You haven’t eliminated repetition altogether. You’ve just moved it from your stylesheet into your HTML. By avoiding named constants and moving your font size declaration into a separate class, you now have to add a reference to the small class everywhere in your code where you are using the sidebar class or the permalink class. For some classes in a large site, this can potentially be in dozens if not hundreds of places. Congratulations, you’ve just robbed Peter to pay Paul — and found out that he’s asking for ten times as much.

Another, more serious problem occurs if you need to change your existing class names in order to retro-fit OOCSS into an existing site. For example, you may need to replace this:

<button class="button">Ordinary Button</button>
<button class="submit-button">Submit button</button>
<button class="small-button">Small button</button>
<button class="small-submit-button">Small submit button</button>

with this:

<button class="button">Ordinary Button</button>
<button class="button submit-button">Submit button</button>
<button class="button small">Small button</button>
<button class="button submit-button small">Small submit button</button>

You see the problem here? If you are referencing any of the old class names, such as small-button, in JavaScript anywhere (think: jQuery selectors), that code will break. On a complex web application, this can be a high-risk refactoring, requiring changes in potentially dozens of places.

“When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with ‘bad’ design. The program becomes fragile, rigid, unpredictable and unreusable.” — Robert C Martin

Now don’t get me wrong here. I don’t think OOCSS is necessarily a bad thing. It is well worth considering as a framework for new projects. But it can be pretty tricky to retro-fit it to an existing website.

Advanced features.

Some people say that features such as mathematical expressions are not necessary, because you can easily use comments instead to document your thought processes. For example, rather than using this:

.contents {
  width: @site-width – (@sidebar-width + @gutter-width);
}

you can do something like this:

.contents {
  width: 600px; /* site width less combined widths of sidebar & gutter */
}

This is a very strange argument indeed — the practice it promotes has been universally condemned as an antipattern in every other programming discipline from the 1960s right through to the present day. Even more strange is the fact that one of its proponents is none other than Bert Bos, the former chairman of the W3C CSS Working Group, who considers symbolic constants in CSS to be harmful. This is a bit like the head of the General Medical Council telling us that using disinfectant in hospitals is harmful.

Again, the problem here is when you need to make a change. Let’s say that you wish to change your site width from 800 to 900 pixels, for example. Using this approach, you would have to recalculate potentially dozens of values throughout your stylesheets, and on top of that, you couldn’t use search and replace: you would have to do it manually, drastically increasing the risk of making a mistake. By contrast, an expression-based approach allows you to try out different widths safely by changing only one or two values at most.

Another problem comes when you are trying to add new features to your site. With a comment-based approach, you will need to hunt through your entire stylesheet to find the values you need to make the calculation. With an expression-based approach, on the other hand, you can just use IntelliSense, and don’t even need to know what the exact values are.

What about leaky abstractions?

The problem with the concept of leaky abstractions is that it can be used to argue against anything, since all abstractions are leaky to some degree or another. The important question is to what extent the value added by the abstraction outweighs the potential problems introduced by the leaks.

It seems that the biggest fear of CSS pre-processors is what effect they will have on the size of the generated stylesheets and on performance, or whether they’ll make debugging harder because what shows up in the browser isn’t what you edit. Oddly enough, people who express these fears are usually more than happy to use all sorts of technologies to pre-process their HTML, such as PHP, or ASP.NET, or even XSLT. In fact, CSS pre-processors often do a better job of things, since they pretty-print the resulting output whereas PHP and ASP.NET don’t. If you’ve ever tried to wade your way through generated HTML with nonsensical indentation and lines thousands of characters long, you’ll know exactly what I mean. One thing I would say about this, however, is that it’s better to run your pre-processor on the server rather than on the client, since that way you are able to view the generated CSS fairly easily.

In practice, I’ve found that the improvements elsewhere far more than make up for the friction introduced by the transformation step. Furthermore, in combination with a good organisational strategy (organise your class nesting to mirror the structure of your HTML documents), they can actually reduce your dependence on Firebug for sorting out CSS issues, since it’s easier to identify and eliminate conflicts between poorly specified class declarations in your source itself.

Personally, I think concerns about the size of your generated CSS are overblown. Yes, your generated stylesheets can grow quite a bit if you’re not careful, but the best way to tackle that is to use HTTP compression, and since most of the size increase you get from CSS pre-processors is in the form of low-entropy, repetitive data, it compresses very well. That doesn’t give you carte blanche to ignore file sizes altogether of course (HTTP compression isn’t available in all cases: buggy browsers and/or misconfigured proxy servers can stop it from happening about 5-10% of the time) but as long as you are aware of what causes the most bloat (mixins), and take a little bit of care, you’ll be fine. Maintainability versus performance is a trade-off that you have to make at every level of your code, not just this one, so it’s best to fine tune things here (and CSS pre-processors make fine-tuning of this nature fairly easy) only in response to known, measurable performance issues.

“Premature optimization is the root of all evil” — Donald Knuth

In conclusion.

CSS as a language has some pretty severe limitations which make it very difficult to avoid bad programming practices such as magic numbers and DRY violations, and which make your stylesheets very fragile in the face of changing requirements. While there are design patterns that can alleviate the problem, they are not in and of themselves a complete solution, and even if you do use techniques such as OOCSS, a pre-processor will still be necessary if you want your stylesheets to be easy to maintain and easy to refactor, especially if you are working with legacy code.

Of course, there are potential gotchas with CSS pre-processors, but the same can be said of any technology, and in this case none of them are deal-breakers by any stretch of the imagination: they are far from insurmountable, and the benefits far more than make up for them. Having researched the alternatives, my position on the matter is unchanged: if you’re not using a pre-processor to keep your CSS under control, you’re doing it wrong.

But reading the 501 Manifesto has made me think again about this.

Most of the reactions I’ve seen to the 501 Manifesto seem to have completely misunderstood it. It’s not about having a go at open source or blogging or anything, and it’s not about wilfully switching out of code mode the minute you leave the office: the message of the 501 Manifesto is simply that we favour competence and professionalism over passion.

This is something that needs to be said, and forcefully. There is a noisy group of prima donnas on Twitter (they prefer to think of themselves as “high end developers” or “ninjas”) who are loudly promoting the toxic message that passion and competence are one and the same, or at the very least, closely correlated. If you don’t blog, if you are not contributing to open source projects, if you are not attending conferences in your spare time, if you are not on GitHub, if you don’t view software development as a lifestyle, then according to them, that automatically makes you incompetent.

The author of the 501 Manifesto calls these people “toilet coders.” People who push code to GitHub even while sitting on the toilet.

Here’s the deal: if you are using Bitbucket or Google Code or Codeplex, and you’re happy with it, stick with it. While you may get more contributions on GitHub, and while most Git users are fine, if it’s beneath anyone’s dignity to use Mercurial to send you a pull request, that automatically makes them a Toilet Coder and your community is probably better off without them. Heck, they should be thankful that you’re open sourcing your code at all and not charging a small fortune for it. The only valid reason for choosing Git and GitHub over one of the alternatives is that you prefer it.

Oh, and forget about all this “GitHub is your resume” nonsense. For every recruiter that follows this line of thinking, there are dozens of others who don’t. Besides, if they aren’t prepared to accept an online portfolio on Bitbucket or Google Code or Codeplex instead, then similarly, they are Toilet Coders, and you are probably better off not having them as a boss if you value quality time with your family.

The fact of the matter is that what you do with your personal projects, and in your spare time, outside of work, is entirely up to you. Just because you don’t want to use GitHub doesn’t make you incompetent. Just because you don’t contribute to open source projects doesn’t make you incompetent. Just because you don’t have any personal coding projects at all doesn’t make you incompetent. Just because you don’t use Node.js and CoffeeScript and Ruby on Rails and CQRS and all the latest over-hyped this, that and the next thing doesn’t make you incompetent. Just because you use Windows rather than Linux doesn’t make you incompetent. Just because you prefer Entity Framework to NHibernate doesn’t make you incompetent. Just because you don’t use vim doesn’t make you incompetent. Switching out of code mode when you go home doesn’t make you incompetent. The only thing that makes you incompetent is not knowing, or not being able to apply correctly, the baseline skill set required by your team.

Don’t burn yourself out trying to impress people you don’t work for who don’t understand the difference between passion, competence, and GitHub.

Unfortunately, it can be difficult to know exactly where you yourself stand in the great scheme of things, and it’s all too easy to think you’re better than you are, so I thought I’d jot down some different levels of JavaScript experience and skill to measure yourself against. These are they.

0. You avoid it altogether and insist on using Silverlight instead.

1. Your use of JavaScript is limited to searching the web for jQuery plugins, and snippets that you can copy and paste.

2. You are able to write your own short scripts (<100 lines or so) but these are fairly simple and mainly flat and strictly procedural in organisation. You know the basics of JavaScript syntax but would be hard pressed to say exactly which data types are available to you, and if you are aware of the var keyword, you don’t know what it does. You are scared of cross-browser language differences, though you aren’t able to give any specific examples. Your JavaScript reference of choice is W3schools. You have never heard of CoffeeScript.

If you don’t see anything wrong with setTimeout("myEvent();", 1000), you fall into this category.

3. You understand JavaScript’s scoping rules, the var keyword and the (function() { ... })() construct. You understand how to use functions as first class objects, and you know exactly what jQuery returns from a call to $('.selector'). You think CoffeeScript is a solution looking for a problem. You know who John Resig is.

4. You are familiar with JavaScript’s object model and know how to implement private and public members and class inheritance and to apply the SOLID principles to JavaScript code. You are not afraid of more ambitious JavaScript projects, though you still think the language can get pretty unwieldy. You have written your own jQuery plugins. You understand the point of CoffeeScript, even though you may never have used it. Your JavaScript reference of choice is the Mozilla Developer Network. You know who Douglas Crockford is.

5. You know that Automatic Semicolon Insertion is not a browser-specific bug, but a feature clearly defined in the ECMA standard. You are confident with larger JavaScript projects, and use frameworks and libraries such as backbone.js, knockout.js and require.js to structure your code. You use JavaScript unit testing frameworks such as Jasmine, QUnit or Mocha, and tools such as JSLint and ECMAScript 5′s "use strict" directive to validate your code structure. You consider W3schools unreliable and are able to say exactly why. You understand how to optimise your code for performance. You know who Brendan Eich is.

6. You build applications which use JavaScript extensively if not exclusively, and have a working knowledge of both Node.js and CoffeeScript. You are able to spot and avoid memory leaks in JavaScript applications. You have contributed code to jQuery or another popular JavaScript library. You are aware of the CommonJS project. Your JavaScript reference of choice is the ECMA standard itself. You know who Jeremy Ashkenas is.

7. You are Douglas Crockford.

I think on this scale I’d probably rate myself at around 4 or so, aspiring towards 5 or 6 though not quite there yet. What about you? Where do you see yourself on this scale?

They annoy me because they’re fighting the wrong battle. Git fanatics who say that “Git has won” are so intent on killing off Mercurial that they’ve completely lost the plot with the issue that really matters. It’s old-school, inefficient, restrictive, trunk-based tools like Subversion and TFS that are the problem, not Mercurial.

People who say that “Git has won” point to the success of Github. While this is impressive, it doesn’t give the whole picture: a huge proportion of the industry is still stuck with Subversion, and the majority of corporate developers view the Github crowd as a bunch of arrogant prima donnas who believe that passion==competence and who think that they’re high-end developers simply because they blog, use Twitter, and know Ruby on Rails. Uncle Bob Martin is particularly scathing about people like that. Github is also dominated by developer tools and libraries, and seems to be significantly less popular among authors of userland software as far as I can tell.

Unfortunately, sorting out the facts from the hype isn’t easy. Version control surveys seem to be a bit thin on the ground, and usually have inbuilt biases that skew the picture somewhat. The most reliable ones would probably come from a company such as Gartner or Forrester Research, but I’ve found these a bit hard to pin down too. The most recent one that I could find was this survey from Dr Dobbs/Forrester Research (hat tip: David Richards of WANdisco):

I see no reason to doubt these figures, though they are about three years old now and I haven’t been able to find a more recent repeat of the same survey.

Aside from that, the best I can come up with is the annual Eclipse Community Survey, which is conducted every April. Since Eclipse is an IDE that tends to be widely used in enterprise settings primarily among Java developers, it’s probably the best fit for what I’m looking for, and while it largely filters out the loud Ruby on Rails type fanaticism, it unfortunately also largely ignores the .NET world, which can be infuriatingly conservative at times. However, it does paint a picture in broad brush strokes that gives some indication of how things have been changing since then.

Their figures are as follows:

Some observations here:

• The 2011 survey put Git in third place, just behind CVS (!) in second place with 13.3%. This represents a fivefold increase in two years, which makes it increasingly hard to argue that Git hasn’t yet “crossed the chasm.” The claim that “Git has won,” however, is quite clearly premature, given that Subversion users still outnumber Git users four to one.
• Mercurial, coming fourth equal alongside Perforce, has a larger market share than I expected given the demographic: I was under the impression that outside of the .NET ecosystem, it was pretty much a lost cause these days. If you were to factor in .NET developers, its mindshare relative to Git would probably be somewhat higher, since many .NET developers are still dissatisfied with Git’s Windows support and usability story. Certainly, if you’re happy with Mercurial and don’t need to contribute to projects on Github, there’s no need to switch to Git on the basis of mindshare alone at this stage.
• Subversion is starting to lose market share, and I expect this trend to continue if not to accelerate over the next year or two, so you should seriously be evaluating a distributed option for new projects sooner rather than later, otherwise you are at risk of being left behind. However, it’s too early to complain about existing projects still using it, especially if they are surrounded by a lot of process and infrastructure making migration difficult.

It’ll be interesting to see what the 2012 survey reveals, but extrapolating these figures would suggest that current market shares are probably somewhere around 18-20% for Git, 6-7% for Mercurial, and 40-45% for Subversion. This would put Git on course to overtake Subversion to the number 1 slot sometime towards the end of next year.

But having said that, HTML/JavaScript/CSS is not without its pain points — and one of the biggest pain points of the lot is CSS.

Here’s the problem. We all know that repetition in code is a bad practice, as are magic constants (bare numbers or strings whose purpose is not clear either from the content or the context). Unfortunately, it’s almost impossible to write vanilla CSS without resorting to copious quantities of both of them. It’s also far too easy to make your selectors too wide-ranging, with the result that fixing one styling issue introduces a dozen more. Vanilla CSS invariably turns into a Big Ball of Mud sooner or later. Usually sooner.

But wouldn’t it be nice if you could have nested class declarations?

#header {
  h1 {
    font-size: 26px;
    font-weight: bold;
  }
  p { font-size: 12px;
    a { text-decoration: none;
      &:hover { border-width: 1px }
    }
  }
}

Or if you could have one class declaration inherit from another?

.rounded-corners {
  border-radius: 5px;
  -webkit-border-radius: 5px;
  -moz-border-radius: 5px;
}

#header {
  .rounded-corners;
}

Or even from a parametrised class declaration?

.rounded-corners (@radius: 5px) {
  border-radius: @radius;
  -webkit-border-radius: @radius;
  -moz-border-radius: @radius;
}

#header {
  .rounded-corners;
}
#footer {
  .rounded-corners(10px);
}

Or if you could have predefined constants?

@heading-color: #ff6600;

/* snip */

h1, h2 {
  color: @heading-color;
}

Or if you could have functions?

@link-color: #ff6600;
@vlink-color: darken(@link-color, 15%);

a {
  color: @link-color;
  &:visited {
    color: @vlink-color;
  }
}

Well look no more. There are a couple of nifty languages that extend CSS in these very ways, and more. Namely: Less CSS and Sass/SCSS. I’ve been experimenting with Less recently, and I’m now using it on my blog. Sass is fairly similar but has a different syntax. They work simply by compiling into vanilla CSS, in much the same way as CoffeeScript compiles to JavaScript.

Syntactically, Less is a superset of CSS itself, so adoption is generally very easy and the learning curve fairly gentle. Your existing stylesheets should work without modification, though having said that, it is particularly strict about correct syntax, so if you have any typos or browser-specific hacks (which generally only apply to very old browsers such as IE 5.5), you’ll need to get rid of them.

Less is written in JavaScript, and can run either in the browser (all browsers from IE6 upwards are supported), or on the server via Node.js. If you want to run it server-side but don’t want to use Node, there’s a .NET version available called dotLess (conveniently available through NuGet), which also supports features such as CSS minification and caching, and is useful if your business requirements mandate supporting browsers with JavaScript disabled. If you want syntax highlighting in Visual Studio, the Mindscape Web Workbench provides support for both Less and Sass/SCSS, with CoffeeScript support thrown in for good measure.

The bottom line is, if you care about clean code, you need to be using one of these tools. I can not stress this strongly enough: vanilla CSS is a mess, especially on more complex websites, and Less and Sass open up many opportunities to allow you to refactor your style sheets into something more maintainable and robust.

Now when somebody writes that on their blog, they’re generally criticised as being elitist and condescending. This is because they tend to talk about the “alpha geeks” or the “20%,” and everyone else or the “80%.”

I’m not going to say that. But I am still going to say that there are two types of programmer.

• Those for whom programming is a means to an end.
• Those for whom programming is an end in itself.

If you’ve been following me on Twitter, and if you’ve read my recent blog posts, you’ll know that this has been something of a theme for me for the past couple of months or so. What got me going about it was reading this remark in a blog post by Jeremy Miller a few months back:

I had a great time at CodeMash yet again. For those of us who look at software development as more of a lifestyle than just a way to meet the mortgage, these kinds of events are like a huge dose of nutrition for the soul. I really liked Scott Chacon’s keynote address and it’s got my head a going about how to make our workplace better (see this again).

It’s not a bad post, all in all, but whoa there. Since when was software development supposed to be a lifestyle?

Don’t get me wrong here. I’m all for being passionate about programming, for sharpening the saw, for improving your skillset, for using the best tools for the job, and all that, but when I hear of people describing software development as a lifestyle, I wonder just what makes them tick. And this isn’t a criticism of Jeremy either. It’s more a criticism of myself. There have been times when I myself have slipped into that way of thinking, and I’ve not found it to be beneficial. It’s easy to fall into that trap when you have the kind of mind that enjoys programming, and it takes a good deal of self-discipline to avoid it. In fact, paradoxically, I find that when I get into programming-as-an-end-in-itself mode, I end up getting less code written, not more.

This, in a nutshell, is what’s been behind a lot of the things I’ve been blogging about recently. It’s been behind my recent decision to stop using vim, for instance. For that, and everything else I’ve been looking into, I’ve been asking myself the question: is this a means to an end, or is it an end in itself?

So to those of you who would want to persuade me to reconsider learning vim properly, or to switch from Mercurial to git, please allow me to remind you of one important fact.

You can’t learn everything.

As programmers, we face a firehose of new tools, new technologies, and so on. Many of these are promoted loudly with great fanfare on the Internet by their fans. In the case of some (*cough* git *cough* ruby on rails *cough*) the fanboy hype is deafening. Most of them are claimed by their proponents to be counterexamples to Fred Brooks’ classic essay, No Silver Bullet. Almost none of them are anything of the sort. Yes, they are beneficial to a greater or lesser extent, but in most cases, there are trade-offs.

It simply isn’t possible to give all of them more than a cursory once-over. You have to triage what to learn and what not to learn. Aggressively. Learning vim would rob me of time familiarising myself with other, more important technologies such as Selenium or backbone.js, for instance. Frameworks and tools that you do learn are huge and complex these days, and if you try to learn too many of them, you end up with a very superficial understanding of them that can lead to problems. Either that, or else you end up spending so much time on the computer that you damage your health and your relationships with other people.

So in the past few weeks, I’ve been taking a good hard look at everything I’m doing, re-evaluating what I should be taking up, what I should be dropping, and what I should just allow to carry on as-is. With that in mind, I’ve been formulating some criteria by which I should decide what to adopt, and what to ignore. With everything I’ve been doing, I’m asking myself a few pertinent questions now:

• Does this solve a problem that I am currently facing or am likely to face in the not too distant future? If so, how effectively?
• Will knowing it enhance my career prospects? More importantly, will not knowing it harm my career prospects?
• Are there any examples of real-world applications using it, or is it all smoke and mirrors?
• What is the ramp-up time, and is it worth it?
• Is it in line with the direction I am heading, or is it a distraction?
• If it makes programming easier, does it do so at the expense of the end users?

The last point is a key implication of programming being a means to an end rather than an end in itself. If programming is a means to an end, and you care about your end users, you will base your choice of tools and frameworks on what serves them best. On the other hand, if programming is an end in itself, you will choose the cool languages and tools that everyone is raving about, but at the expense of your audience. This is of course what WordPress got right but Diaspora got wrong.

I’ve decided that in terms of tools and technologies, I should focus on my core competencies: namely, the Microsoft .NET stack, HTML 5 and JavaScript. I also want to up my game as far as test-driven development is concerned — hence, I’ll probably have another, closer look at MSpec — and also get to grips much more with agile development methodologies, in particular Scrum, which we have been using at work for the past year or so. As far as my other skills are concerned, such as PHP, Python, Django and Linux, these are useful skills to have, but how much time I spend on them from now on is something I am yet to decide. While it’s good to diversify to an extent, I don’t think much of the Pragmatic Programmers’ suggestion that you should learn another language every year, simply because that takes you into the realm of programming for programming’s sake, and besides, I don’t think it’s realistic, unless you are content to be a jack of all trades and master of none.

Bloggingggaaaaaaaa!

The ALT.NET movement makes me feel a little bit uneasy somehow. While there are some pretty good people in there, and I fully support the aim of finding better ways to do things, the movement as a whole seems to have largely degenerated into a clique of programming-as-an-end-in-itself Ruby fanboys with inflated egos who only do .NET under protest for their day jobs, and who complain about Microsoft tools purely for the sake of complaining about Microsoft tools. I ended up in conversation on Twitter with several of them in the wake of my TFS==Lotus Notes blog post, and I think some of that may have rubbed off onto me. Certainly, I’ve been doing far too much complaining recently, and I’m sure it doesn’t make me look good.

I’ve come to the conclusion that the programmers most worth following on Twitter, most worth subscribing to in Google Reader, are the people who are building end-user applications aimed at non-developers. This isn’t necessarily because they’re smarter — frameworks and developer tools are technically more challenging beasts to write and maintain — but because they tend to have a better grip on reality. Building end-user applications puts activities such as socialising and speaking to non-programmers right at the heart of programming: you have to talk to people before you start in order to get ideas, and then you have to talk to them afterwards in order to make sure you’ve delivered something that they can use without getting confused. And of course, you also have to talk to them in between times to make sure you are on the right lines. This is where agile software development hits the nail on the head — developers are expected to talk to the customers on a daily basis. On the other hand, only ever building programming tools and libraries, and little or nothing else, seems a bit self-serving to me.

At the same time, I’ve also been asking the same questions about my blog. Over the past few years, I’ve constantly found it to be a very time consuming animal, where I don’t see much benefit coming out of it, and I keep wondering why I do it. Most of my recent blog posts have said, “You should be doing this,” or “You shouldn’t be doing that,” or “This is a cool tool,” or “That process is bad,” or other things in that vein, and I’ve been saying very little about what I’ve actually been doing myself. This is just punditry, and I don’t want to be just another talking head. We have too many talking heads in our industry, and it gets rather boring after a while.

I also think I got carried away somewhat with the whole Mercurial/source control thing. Now don’t get me wrong: I still maintain that Mercurial is the best source control tool available today by a long shot, that only git comes anywhere near it, that the old-school centralised model is past its sell-by date and no longer fit for purpose, and that if you’re not using a DVCS, you’re harming your productivity, making a rod for your back, and exposing your project to unnecessary and unacceptable risks. But there comes a time when you have to let things drop, otherwise you end up coming across like a noisy fanboy yourself and you just annoy people who have missed them as they flew straight past coming out of the firehose. In fact, this fanboy attitude is totally out of order in the Mercurial culture itself, where viewing programming (and by extension, source control) as a means to an end and not an end in itself is very much the norm.

I’ve therefore decided that I need to take a break from blogging for the next few months. Quite when, or even whether, I return is anyone’s guess, but if I do, I’m not planning to carry on writing in the same vein as I’ve been doing so up to now. If I’m to carry on blogging, I want to build stuff that I can talk about and showcase here on my blog first. Unfortunately, at the moment, most of the code I write that’s worth talking about is at work, and there’s obviously a limit to how much I can write about that. But the Agile Manifesto tells us to favour working software over comprehensive documentation, and as a corollary, the contents of your github or bitbucket account say more about you as a developer than the contents of your blog.

I’ll no doubt continue working on some personal programming projects in my spare time. In fact, hopefully I’ll be able to spend more time working on programming projects without getting distracted by blogging about x, y or z. But it will have to be time-boxed anyway. During the week, I am out of the house from seven in the morning until seven in the evening, which doesn’t leave me much time for anything other than sleep, and I want to free up more time for socialising, church activities, and developing other interests that don’t involve sitting over a computer.

1. Pet projects don’t need to be extensive or advanced for you to stand out from the crowd. The vast majority of .NET developers have no personal projects whatsoever, so as little as one evening a month spent on them should be more than adequate.

2. Can we cut out all the cringeworthy Bravo Sierra about “passionate developers,” please? There are less clichéd ways of saying much the same thing, and besides, I get the impression that some recruiters view passion as a substitute for competence. It isn’t. You get plenty of passionate developers who think that Pokémon exception handling is perfectly acceptable, for instance.

3. It’s also possible to have too much passion for programming. People who get too passionate about programming forget that it is a means to an end, and not an end in itself. A telltale sign that you are dealing with such a person is that their github account contains nothing but vim scripts and clones of developer tools and class libraries. If, as a recruiter, you want to look for personal projects, look for ones aimed at non-developers. That way, you get some indication that you’re dealing with someone who at least has some grip on reality.

Take a look at its list of about eighty or so “interesting” repositories, for starters. There’s a lot of cool stuff there: Prototype, Scriptaculous, Ruby on Rails, MooTools, Groovy, Sinatra, Redis, Symfony, and so on. The list changes from time to time, and I have no idea what criteria are used to construct it, but at the time of writing, with only one exception  — phpBB — every single repository on the list is either a programming language, or a programming framework or library, or a programming tool.

You can see something similar — and quite surprising — when you look at the list of most popular languages on Github. The dominance of JavaScript, Ruby and Python is not all that surprising, but the fourth most popular language on Github is Shell. In other words, bash scripting — the Linux equivalent of DOS batch files or PowerShell.

C# — probably the most sought-after programming language by employers in the Real World — does not appear in the top ten. Clicking through to it from the right hand column shows that it is number twelve. But which is number eleven? After a minute or two of clicking on educated guesses then completely at random, I discovered, much to my surprise, that it is actually VimL.

I kid you not. Github apparently has more repositories dedicated to the scripting language for Vim — a console-based text editor mainly used by hard-core geeks — than to C#.

Why am I highlighting these things? Because they are indicative of a problem that seems to be plaguing the open source world and the programming blogosphere these days. There is far too much of a focus on processes and tools, and not enough of a focus on individuals and interactions. I’ve been getting too much inclined that way myself in the past couple of years here on my blog and on Twitter, and I’m getting weary of it.

You can understand why this would be. Programming languages, tools and frameworks are fun to work on because they’re hard and make you a better programmer, they scratch a personal itch, and they look good if you’re trying to attract the attention of trendy startups in Silicon Valley. And of course these things are important. But they are written by open source developers, for open source developers. They are of no direct interest whatsoever to non-developers.

Where are all the WordPress plugins and themes? The personal productivity software? Personal finance? Health and fitness? Photo and video editors? Education? Motoring? Foreign language learning? E-commerce? Geolocation? Astronomy? Twitter and Facebook clients? Games? Screensavers? Android and iPhone apps? Yes, they’re out there, but you have to hunt for them. And among all the blog posts about how CQRS, NoSQL and IOC containers are so cool, where are all the success stories telling us how they’re being used in the Real World?

Programming does not exist in a vacuum, folks. If we were serious about the Agile slogan, “Individuals and interactions over processes and tools,” projects aimed at non-developers would predominate. As it is, a lot of it seems like a case of programming for programming’s sake.

A lot of developers are introverts, and find it easier to spend time writing code than interacting with people. But if you want to produce something that’s really useful, you need to spend some time getting out from behind the computer, developing other hobbies and interests, and interacting with people. After all, that’s where the ideas for useful software come from in the first place.

Being a successful developer really does require you to put individuals and interactions over processes and tools.

Queuing at a station counter or a ticket machine is something I only normally have to do once a month or so but all the same, it’s still a complete faff at quarter past seven in the morning, especially if, like me, you’re not a morning person. Getting to the station that extra bit earlier and ending up in a queue of twenty other commuters at that time of the morning when your train is due in five minutes is just a little bit stressful.

On the other hand, I pay a regular visit to Tesco or Sainsbury’s at least once a week. When I do, I have much more leeway with my time. It’s later in the day so I’m not bleary eyed and newly out of bed. Having to stand in a queue for ten or fifteen minutes doesn’t faze me nearly so much. It would be a much more seamless fit into your average commuter’s weekly routine.