Quite randomly in the middle of a session, Visual Studio went bonkers and started saying “No files were found to look in. Find was stopped in progress.” whenever I tried to search for anything.

Visual Studio being what it is (a buggy but widely used tool), I went to Google. And Google delivered: the solution is to press Ctrl + Scroll Lock. Huh? As a fix that’s on par with spitting over your left shoulder on a Thursday with a full moon.

And if that wasn’t weird enough, the bug has existed in the last 3 (three) versions of Visual Studio: 2003 and 2005 and 2008 (which we use). And no one at MS has bothered to fix it.

I’ve been at my new job almost two months now, and by now I feel like I’ve been doing it for a long time. I think much of that is due to how small and informal the team is, and how tightly involved I am. I am half the development team. My previous job (at a big bank) was framed and structured by all sorts of procedures, automated processes, approvals, systems, and schedules. Here I just sit down and do whatever I decide needs to be done.

On the one hand this leads to a lot of freedom and independence and responsibility. Our speed of response is stunning: if an urgent bug is found, the fix can be in production minutes after we’ve tested the fix.

But there are downsides, too. There can be confusion and lack of direction, because there was (until recently) no clear process in place for prioritising requirements or for scheduling and planning releases. There is tedious manual work which is easy to get wrong, because the deployment process is not automated. And so on.

The good thing is that it’s all changing. The other half of the development team is almost as new to the firm as I am (although he has worked there a few summers, he only started full-time a couple of months before me). Since we’re both new, we have no emotional investment in the current processes and systems. And we’re planning to change just about everything.

A new source control system is coming soon (SVN instead of VSS). A new development process is already being tried out (Scrum-inspired). Development tools to improve code quality (Resharper) have been introduced. Automated unit tests are slowly being put in place, and automated acceptance tests are being discussed. Automated build and deployment will be coming next.

My last job was, in a way, the perfect preparation for this. Had I come straight from school, or from another unstructured chaos-inspired place, I might not even know that things could be done differently, and we would have muddled on, just like the developers before us seem to have done. The gears would grind slower and slower, but we would probably be able to keep moving for several more years.

But I have seen the other end of the scale, and I know – not theoretically but from my own experience – the benefits of an automated build process, deployment scripts, code reviews etc. I know how much easier life could be. I know what we should be aiming for, and even though the ideal setup here will be very different from what we had there, I know how to figure out the way to get there.

If any of my previous colleagues are reading this, I’d like to send them a big thank-you for preparing me for this! You all thought I was working for the bank, and in reality you were all working on training me.

An approximate excerpt from a CV, from someone applying for a developer job at the company I work for:

I program in my spare time. […] I also write programs to help me with online games. For example I wrote a program in Java to help me play NukeZone. The program simulates IE and gives me an overview of the whole economy in the game world, which gives me an advantage over all other players. It uses proxy servers to avoid being detected so my account does not get cancelled. All the data are saved in a MySQL database and displayed on the screen.

Hmm. You cheat in games, and you’re boasting about it. And you think this would somehow help your chances of getting hired?

Think again.

A very bad bug was accidentally introduced into one Linux distribution two years ago. (Bruce Schneier has a brief overview with links to more.)

The bug itself is interesting enough. But far more interesting is how it got there. Basically, a Debian developer found what to him looked like less-than-perfectly clean code in the OpenSSL library. A tool for checking code quality complained about a specific line of code. The developer wondered if he could remove that line, asked some people, got what he thought was approval, and decided to go ahead. It turned out that he hadn’t really understood what he was doing, and no one else noticed that what he removed was a very crucial step.

All sorts of improvements to the development and code review process are being discussed, and lots of finger-pointing is going on. But the root of the issue is that someone wrote non-obvious code and didn’t comment it. A developer wrote code with no thought for those who might be reading or maintaining it. It would have taken them 5 seconds to add a one-line comment confirming that, yes, they did indeed mean to put this unorthodox line here.

I’m not the first commenter to say this. I just feel really strongly about writing maintainable code!

(This is my last post about the WordPress migration, I promise!)

I liked WordPress better than Movable Type as soon as I’d installed it, and my opinion hasn’t changed. If you’re using MT and haven’t tried WP, do try it out!

The only advantage of MT that I have noticed thus far is that it is possible to manage several blogs via one control panel. But on the other hand most settings and templates are blog-specific anyway, so I’m not sure how much time that actually saves (apart from software upgrades).

Just about every part of WP is more user-friendly than the MT equivalent. The control panel is better designed and easier to navigate. The templates are more transparent and much easier to work with. Instead of MT’s strange tags (of which there are two flavours and I could never remember what the difference was) WP uses normal php functions.

Wordpress is also more feature-rich and more flexible. I can create static pages in addition to blog posts, add a list of links, easily switch between themes, add direct “edit this” links to individual posts, etc. And from a developer point of view, the WP functions give me more control with less work (mostly because they have many more parameters) than the MT tags.

Wordpress makes tinkering a lot more convenient because pages are served dynamically. MT on the other hand pre-builds and saves all pages, so each template change leads to a full rebuild of all the affected pages. With 600+ blog posts, the rebuild caused by a change to the main template takes long enough to make me really reluctant to change things. (And there is no option to rebuild just one post as a test case.)

The documentation for WP is an order of magnitude better than that for MT. Compare: the MTCategories tag vs the wp_list_categories function.

My initial plan was to use an existing theme for this blog, perhaps only changing a few fonts and colours. I browsed a bunch of themes, downloaded half a dozen, and tried them out. When I had picked the few that seemed most promising, I took a look at the code of each one to see which one would be easiest to modify. The WordPress template structure turned out to be so clear and transparent and the documentation so helpful that I ended up writing my own theme, using the existing themes only as a source of ideas and to get an idea of what functions were available. And I did this when I had no experience of WordPress, whereas I never got comfortable enough with MT to write a theme from scratch, even after having used it for over two years.

So I got a nice exercise in web design, learning PHP and CSS, both of which I’d touched before but not really used much. Now I can write passable PHP code and do some pretty nifty things with CSS. Hmm, perhaps I could find a way to squeeze in some javascript here, too?

I also had the pleasure to use the Firefox Web Developer extension. A very nice tool, so good that it’s worth downloading Firefox just to get that extension.

The Best Software Writing I is, well, a collection of good writing about software. Edited by Joel Spolsky, who is quite a good software writer himself.

The book covers a wide range of topics – from the design of social software to how to hire developers. However they all tend towards the “peopleware” side of things: the interaction between humans and software, rather than the technical minutiae of writing code. The selection has clearly not been guided by any sort of overarching theme or purpose, but rather by what Joel is interested in.

And that, I think, is the greatest weakness of the book: an unclear aim. Joel claims on the back cover that “the goal of this book is to encourage better writing about software by highlighting some of the best writing of the year”. That’s an admirable goal, but it leads to a book that’s aimed at everyone and no one in particular. It’s even unclear whether the book is mostly meant for a technical or non-technical audience. Almost all of the essays assume some familiarity with software development, although not at a very technical level – a technically-minded non-developer wouldn’t have any difficulty. And yet there are footnotes explaining basic concepts in idiotic terms: “Dev = developer = an actual computer programmer”. Huh?

Some reviewers disagree, and mean that the book’s greatest weakness is that you have to pay for it, while most (or possibly all) of the material can be found online for free, including Joel’s introduction. But I like the feel of a book in my hands, and I also like to have a book in my bookshelf so it reminds me to re-read it occasionally. So even though I’d read several of the essays and blog entries before, I chose to buy the book rather than look for the rest online.

The quality of the essays varies. Some were worth reading once, and I’ll skip them the next time. There was a bit too much Eric Sink for my taste (come on Joel, three essays by Eric and only one by Paul Graham? What were you thinking?) and I really don’t think that why the lucky stiff is an example of good software writing. On the other hand, A Group Is Its Own Worst Enemy by Clay Shirky is so good that it’s almost worth buying the book just to read this one essay.

Because the book was written with no one in particular in mind, I’m not really sure who I’d recommend it to. The most likely audience would be technically-minded people interested in the human factors of software development. But the contents of this book aren’t new, the thoughts aren’t new, so someone who’s interested in the field will most likely have read these or similar materials already. Worth picking up if you haven’t.

Amazon UK, Amazon US.

Two interesting blog posts about programmers and their preferences.

Here’s one that explains the fundamental difference between (most) programmers and (most) managers:

So here’s my theory: Managers must work shallow and wide, while programmers must work narrow and deep. People who are naturally tuned to one particular method of work will not only enjoy their jobs a lot more, but be better at them. I’m a deep guy, I should be doing deep work.

I didn’t say it was a particularly insightful theory.

It may not be an insightful theory but it certainly strikes a chord with me. I’ve said many times to both to my current manager and the two previous ones that I have no aspirations whatsoever to move up the traditional career ladder that inevitably leads to managing people. In fact if I was forced to I’m pretty sure I’d rather quit. Wide vs. deep is not the only reason for this preference but is certainly a big part.

The other talks about the role that personal preferences play in technological choices, and about why you need to know your audience before you can tell them what they should do.

When someone tells you “you need better tools: try Lisp”, ask “what about Lisp do you think would help me?” If they start listing reasons without first trying to understand who you are, may I say there’s a problem.

This is something I have encountered many times. People who recommend me some music or other, and when I ask them why they think I would like it, their only reason is “because this band is great” or “well I just think you would”. Book reviews that effectively say “everyone will like this book” or “best book of the year”. Of course they may sometimes be right, but more often it’s just a sign of sloppy thinking.

I’m still channelling all my creative writing urges into tinkering with Ruby rather than writing blog posts. Really like it.

Less than a week of vacation and already my fingers were twitching and wanting to code. I’ve wanted to learn a new language for a while, so I started playing with Ruby.

It’s been a bit of a struggle since many fundamentals work quite differently from what I’m used to in the .NET world. I have to look up just about everything: how to declare a class or a method or an attribute or a variable, how to refer to code in other files, how to call methods, how to raise exceptions… It doesn’t help that most things have at least two syntax options: methods can be called with or without parentheses, blocks defined with do…end or with brackets.

Nevertheless exploring the language is fun. It’s a welcoming language, easy to get started with – you just write code and run it. No messing with classpaths (that’s all done for you) or solutions or projects or compiling (not necessary at all). In fact there’s even a web tutorial named Try Ruby! that includes an online interactive interpreter, just type and see things happen. There are also a lot of tutorials, docs and example code available on the web. (I started with the tutorial at RubyLearning.)

In fact getting started with Ruby was so easy that my biggest hurdle thus far was finding a project to write. All the applications that I really need I have either written or bought already. The few things that I want to build at some point are either too large for these few weeks I have, or too Windows-specific / GUI-heavy, so I would spend more time struggling with the implementation specifics than learning the language. In the end I decided to rewrite a tool I already have, a small backup utility that I wrote in VB.NET almost two years ago.

Different languages encourage different things, from the moment you first meet them. The .NET version of my backup utility has a GUI because Visual Studio makes GUI-building very easy and almost encourages you to start from the GUI and work backwards from there. Ruby doesn’t do that, so this will probably a command line app only. Ruby, on the other hand, encourages unit tests – a unit test framework comes bundled with the standard installation – so this version will probably be much better tested than the .NET one.

I attended a presentation yesterday by Kent Beck, one of the big names in software development, who had been invited to talk to the developer community at the company I work for. I went with great expectations and came away quite disappointed.

The title of the talk was “Trends in Agile Development” and the premise was that trends in software development methodologies mirror larger trends in business and in society – increasing accountability, transparency and responsibility, and increasing focus on relationships. Unfortunately he didn’t manage to actually say much more about this than what I wrote above, despite talking for an hour and a half (plus about half an hour of Q&A time). This could have been interesting if he had pointed out some non-obvious conclusions, or explained why we are seeing what we are seeing, or what this can lead to. Now he just stated the obvious.

The audience seemed to agree. Most of the Q&A time was spent on more technical aspects of Agile Development. There was only one question about the specific topic (about how these trends relate to the growth of open source software) and he didn’t really answer that question.

Kent Beck may be a good programmer, and he may have done some good thinking about programming methodology, but he is not a sociologist.