Given that I write a blog, it should come as no surprise to you that I read blogs as well. There’s about twenty that I read regularly – not daily, but a steady rotation through the list ensures that I see each one at least twice a week. The blogs range from the very techy to simply enjoyable writing.

There’s quite a lot of turnover in that list. One single very interesting post may be enough to get a blog onto the list. Then I keep checking the blog for a few weeks to see what else they come up with. If a month goes past without any posts of value, they’re thrown out, no matter how good that first post was. There’s enough cross-linking among good tech blogs to make sure that I don’t miss anything really astounding.

The blog that I’ve been reading the longest is Jeff Atwood’s Coding Horror. I have read every single post since at least the beginning of 2005 (when I started doing .NET development). With other blogs, I might skip what they wrote while I was out on vacation, but not with Coding Horror.

What makes it so good? Interesting content is the primary factor. Most of it is about “.NET and human factors”, as the blog byline says, or about general software development issues. He makes me think of things in a new light, or think of things that I hadn’t even stopped to consider before. While I don’t always agree with his views, he is clearly a man who thinks, and there aren’t too many of them out there! The issues he writes about are so general that most would be relevant or useful even if I worked with COBOL. At the same time, the range of topics is wide enough that he doesn’t get boring or repeat himself. I haven’t found any other blog or magazine out there that is so consistently interesting.

Which brings to mind another important component: consistency. He posts regularly, and consistently about a single topic. There are no posts about his vacation, or photos from his latest night out, and no long gaps – bad habits that ruin many other programming blogs. A programming blog should be about programming; private life belongs elsewhere. Few readers are likely to be interested in both. (I don’t follow this rule myself, but on the other hand I never aspired to a large audience for this blog.)

There is also consistence of quality, both in content and in presentation. Jeff’s blog is not the kind that gets the whole blogosphere’s attention for a few days, only to be forgotten after that. Instead there is a steady flow of interesting, thought-provoking, enlightening, well-written commentary.

Finally, his blog is a pleasure to read because it looks good. It is clean, clear and easy on the eyes. Compare, for example, the CodeBetter blogs: large and noisy header, blinking ads, colourful links, a gazillion reminders to “Share this post: Email it! | bookmark it! | digg it! | reddit!| kick it!”, and a side bar longer than my arm.

If I had a tech blog, I would be really proud and satisfied if I could make it as good as Jeff’s.

This past week has been a good one from a work point of view. Lots of actual hands-on coding, which I enjoy more than the more mundane aspects of development works (tweaks to config files, and tedious manual testing of dodgy third-party applications). I am exploring, building, playing, and solving puzzles. What more can one ask for?

I’ve been learning a whole new language – a specialised one that was developed internally at our company. It was created for a specific audience and a specific domain, and has never been distributed outside the firm. This has led to great freedom and thus some quirky developments. I can’t really say much about the interesting technical features of the language, mostly because I know too little about it, and because it would just be too complicated to explain… But the technical side is just a small part of it. The culture and management of the language are at least as interesting.

On the plus side, the language is flexible, open to change, and evolves all the time. Anything that needs to be changed, can be changed, since we own and control it. And it can be changed quickly, because the language and the management processes around it were developed by a firm who needs to be nimble to stay in business.

The flip side of this malleability is that people only change that which they want/need to change. If there are a dozen cases to consider, but you only need one to work, you implement the one, and ignore all the others. If you’re feeling generous, you leave a comment in the code about this. This is exactly what I encountered in my project this week. And of course I will only implement the one addition I need, and leave the remaining ten for someone else!

Another, related weakness is the documentation (lack of). It is an easy step to skip when working towards a tight deadline. So documentation is scarce, brief and mostly auto-generated. Some basic things appear to be completely undocumented; you just need to figure it out on your own. I still haven’t found a categorised list of built-in functions, for example. On the other hand, because the language was developed internally and is used very actively, there is a large pool of knowledge about it, and it is easily accessible. It is much easier for me to get hold of a senior developer responsible for the core features of this language than, say, Java, for example!

The lack of documentation is also offset by transparency. All source code is stored centrally, so anyone can access all of it – and it’s all searchable, of course. This makes it a lot easier to learn the language. It also contributes to the flexibility and changeability of the language: if I find 15 date-handling functions but not one that does just what I need, I can easily add it using the 15 as examples. And if the code doesn’t behave as expected, I can debug (and possibly fix) each and every part of it. It is quite exciting to get to dive so deeply into the core parts of a large code library.

Productivity is a very satisfying feeling. Achievement, in the simplest sense: being able to look back and say, “I have done this”.

I like to have clear markers of progress even in small things. It makes the achievement more concrete and solid. My “to do” lists are tangible, on pieces of paper, because I like the feeling of crossing off tasks one by one and seeing the list shrink. Especially at times when I feel that I am not getting much done – because of tiredness, or because I spend more time learning than producing, or just because I am new to things and not able to move as fast as I want to – the act of crossing off a to do item reminds me that I am actually moving forward.

Not that producing is more important than learning. (If I thought that, I’d still be churning out Excel models with great efficiency, and getting paid very well for it!) But learning is such a never-ending process that it is easy to become oblivious of the speed at which it is happening. There’s an excellent Swedish word, fartblind, that means “speed blind”. In the concrete sense, when you’ve been driving on a motorway and come to an exit, it’s easy to underestimate your speed – and likewise when you’re driving on a very smooth road in a very quiet car. In the figurative sense, it’s only when I do something with what I’ve learned, that I can see, yes, I have actually learned this, I know this now. I need landmarks, lamp posts to help me judge the speed.

From a ticking-off-tasks point of view, this week ended on a very pleasant note. Yesterday and today I submitted my first two formal Change Requests. Once the developer, that is myself, has finished making whatever change I’m making, I need to submit a request for the change to be incorporated into the system (which really deserves to be called The System) – all changes go through a formal process before they’re approved and rolled out. The Change Request explains the reason for the change, summarises the changes made, and links to each of the files that have changed. Submitting a Change Request doesn’t mean that everything is done, but it is a landmark.

These two change requests were not just good because they were the first.
#1 was exciting because each of the steps leading to the Change Request was done on my initiative. The project was given to me, and it was up to me to get it done. Getting it done had me asking a lot of very basic questions and getting a lot of help, but the process was all mine.

#2 was interesting in a completely different, educational way. Out of the ca 15 files involved in the change, there were 2 java source files, 5 configuration files for The System, 4 input files for another proprietary application, 1 Excel template and 3 config files for a job scheduling application. That’s a lot of configuring and very little code. In fact, if we find ourselves making more changes of this sort, the code will be rewritten so that subsequent changes wouldn’t require any code changes at all.

All of which made me realise much more clearly how little of software development is really about code, and how much is about the systems and processes around it. Both in terms of importance, and in terms of how much time they take. It’s something I knew in my head but not in my bones, because I hadn’t been involved in anything like it before.

It would seem that the less code-focused the development process is, the better – because that probably means it is more robust. Processes add overhead, but they also add stability and scaleability. Like a skeleton, really. The formal change management system that we have, for example, may take time, but having an established process means that I do not need to worry about it – I can be sure that a suitable someone will review my changes, and that the changes will be rolled out. And it provides both traceability and transparency: both myself and anybody else can see all the details and the status of the change request at any time.

Perhaps it’s just a personal preference, of course. I like transparency, explicitness and clarity. It seems to echo the GTD approach that I use for keeping my own life in order. I don’t like vague manual processes where you’re sort of supposed to get various people’s approvals, but you need to hunt them down one by one, and then you need to keep chasing them to get their replies, and they will all want to know what the others have said, and it’s never quite clear whether you’re done or not.

Phew… this came out quite a bit longer than I had planned. I have had a week of activity and no blogging, so I guess there was a fair amount that needed to be flushed out of the head. And the two posts I had planned on productivity and on processes appear to have become one.

One of the side effects of having a developer job is that I have very little energy or desire for coding in my spare time these days.

There is only so much code that one can fit into a head in one day. 10 hours of muddling around in strange languages and environments leaves that part of my brain completely drained, so when I come home, I don’t want to see any code. I don’t even feel like turning on the computer.

My previous job was a comfortable one. I knew what I was doing. I had a month or two of intense learning when we started using SAS, but after 6 months even that was quite familiar, and there was only incremental learning in small steps. About half of my job I could have done in my sleep, especially the simpler Excel tasks.

Now, on the other hand, everything is new, and there is so much to learn. Only on a few rare occasions when someone has needed something done in Excel, and asked me for advice, have I felt that I know what I’m doing.

The languages are new. The systems are new – source control, build systems, application servers. All of these are things I had heard of (thank heavens for the Internet) but didn’t really have a clue about how they work. Even the environments are new to me, since much of our “stuff” resides and runs on UNIX servers, and I had never even seen UNIX up close. On the first day I was utterly helpless – I couldn’t even copy a file from one folder to another. I had barely touched databases in my previous job, and now I’m neck deep in Sybase stored procedures. In fact SQL is the easiest part of my job since I had at least encountered it before!

All of what I’m doing is very useful and interesting. But it does take a lot of energy.

I’ve been a member and moderator of XtremeVBTalk, a discussion forum about Visual Basic, for several years now. At first I asked a few questions, but I soon realised that answering them is a lot more interesting and educational, so I’ve mostly been doing that. I especially like answering questions that I almost know the answer to, but not entirely – I know where to start but not where it will end. (Those are the educational ones.) The other interesting category is open-ended questions about fundamental principles and approaches – the kind that asks, “How would you approach this problem” or “How would you start thinking about this”.

That site has done more for my education and development as a programmer than any other resource out there. In fact, if it hadn’t been for XVBT, I am pretty sure I wouldn’t hold my current programming job. I might have gotten there by some other route in the end, but it would certainly have taken a lot longer.

Answering other people’s questions, and reading even more questions, I can’t help noticing that some people there have no business programming. The whole enterprise is obviously doomed from the start. Some of them stick around for many months, and there is no perceptible improvement in the quality of their posts. Their questions are not ignorant – which would excusable. Worse: they display such a fundamental lack of understanding of the basic principles of programming that I don’t even understand how they think. I’ve tentatively come to conclude that to them, programming appears to be a combination of (1) imitation (= copy & paste), (2) random attempts at changing things without understanding why they do what they do, or knowing what effect they expect the change to have, and (3) simply crossing their fingers and hoping. Basically they appear to treat computers as black magic, unpredictable and unfathomable, rather than as dumb machines.

I found an interesting article a month or two ago, that talks about this – The camel has two humps, by Dehnadi and Bornat. The authors gave students a multiple-choice test asking them to predict the results of very simple Java programs, focusing on simple assignment. The code for a typical question looked like this:

int a = 10;
int b = 20;
a = b;

Their intention was to “observe the mental models that students used when thinking about assignment instructions”. The test was administered twice – before the start of a programming course, and in the middle – and correlated to results on examinations.

Some quotes from the article:

We expected that after a short period of instruction our novices would be fairly confused and so
would display a wide range of mental models. We expected that as time went by the ones who
were successfully learning to program would converge on a model that corresponds to the way that
a Java program works.

We could hardly expect that students would choose the Java model of assignment […], but it rapidly became clear that despite their various choices of model, in the first administration
they divided into three distinct groups with no overlap at all:

• 44% used the same model for all, or almost all, of the questions. We called this the consistent
  group.
• 39% used different models for different questions. We called this the the inconsistent group.
• The remaining 8% refused to answer all or almost all of the questions. We called this the
  blank group.

It turns out that the consistent group generally succeeds in their exams, and the inconsistent group performs poorly. Notably, some students moved from the inconsistent group to the consistent one during their course, but no one moved in the opposite direction.

And finally the important bit – why is this so? This is the part that I found really interesting, because it matched my own observations so closely:

It now seems to us, although we are aware that at this point we do not have sufficient data, and so
it must remain a speculation, that what distinguishes the two groups is their different attitudes to
meaninglessness.
Formal logical proofs, and therefore programs – which are formal logical proofs that particular
computations are possible, expressed in a formal system called a programming language – are
utterly meaningless. To write a computer program you have to come to terms with this, to accept
that whatever the problem seems to mean, the machine will blindly follow its meaningless rules and
come to some meaningless conclusion. In behaving consistently in the test, the consistent group
showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems
in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group,
on the other hand, looks for meaning where it is not. The blank group knows that it is looking at
meaninglessness, and rejects it.

I recommend you to have a look if you’re interested in programming and/or education at all. It’s a well-written article and easy to follow, since presents both the methodology and results very clearly. And at only 13 pages it’s quick to read.

Now that I’ve moved to a new team, the old team needs someone to replace me. I spent most of this morning interviewing candidates for the job.

The main requirements are reasonable knowledge of finance and financial markets, and good knowledge of Excel VBA and SAS. We’re prepared to (and will probably have to) relax this somewhat and just pick the person who’s closest. I had hoped to find someone better than myself, but it looks like the combination of skills we’re after is a rare one.

The applicants (four of them) have been a mixed lot. Interestingly, three out of the four where Australians. Looks like this is the thing for young Aussies to do: get an education, then travel a while, then spend a couple of years in London. (Our newly-hired team assistant is also Australian.)

Most interestingly, several of the CVs were factually correct but in reality misleading. Two out of four listed both SAS and Excel VBA prominently on their CVs, but when questioned about their experience admitted that they haven’t used them for years, and when asked to demonstrate their skills, they could barely manage the basics, if that. A third one hadn’t done any SAS work but Excel VBA was among the first-listed of his technical skills, and he supposedly had a programming background including C++, yet he struggled hard with questions that required him to write pseudocode for a simple problem.

I think it is almost impossible to evaluate someone’s coding skills without letting them actually write code. Almost anyone can make their past projects sound important, and present themselves as being central to the projects’ success. But when I ask them to actually do something, I can see what they’re really able to do.

Sample Excel problem: return the name associated with the highest value in a list. One candidate’s solution: hard-coded link to the cell with relevant name. Hopeless.
Sample coding problem: create a checkerboard pattern, with alternating black and white cells (or alternating 0s and 1s). Those who knew (or claimed to know) VBA got to write VBA code, others could write pseudocode or use any other language they liked. Only two got anywhere near a working solution.

(That last one I actually “stole” from one of my own interviews, when I was looking around for a developer job a month ago. I think it’s an excellent question because all it really requires is logical thinking, and you could write many variations on the basic theme.)

And what can one say about a candidate who, when interviewed about his financial knowledge, says that his real background is in programming so that’s his strong side, and when interviewed about his programming knowledge, points out that his recent jobs have all been finance-oriented, so that’s what he’s better at.

On the positive side, one of the candidates actually had a honest CV that reflected his skills, and was able to demonstrate those skills in practice. He doesn’t know any SAS, but if we could learn it then surely so can he. And he appeared to have a solid foundation – good coding habits, clean code, sensibly commented. (He actually brought printouts of his code to the interview, which definitely worked in his favour.) I’d rather hire someone with good habits and let them learn the language, than someone who knows the language but produces messy code. Unless we suddenly get a last-minute application, looks like he’s got the job.

It’s interesting to put Java and .NET side by side. .NET has been described as Microsoft’s attempt to beat Java at its own game, and even as “Java done right”. The designers of the .NET framework and the Common Language Runtimes could look at Java and see what worked and what didn’t, and learn from it.

Something that I think Microsoft got right with .NET is making everything an Object.
It’s like whoever wrote Java thought that object-orientation is good, but didn’t quite dare to go all the way. Or perhaps (and more likely) it’s historical baggage again…. Java’s distinction between primitive types and their Object equivalents, such as int and Integer, is the most obvious example. ints are for simple maths but they cannot be put in Collections – you need an object for that. On the other hand, you cannot just add two Integers. And each boxing/unboxing requires an explicit instantiation of a new object. It all adds up to a whole lot of code that just juggles data types.

That’s being changed in Java 5, but they still appear to be doing some sort of halfway fix. Just reading the Immutable Objects section in this overview of boxing in J2SE 5.0 makes me nervous.

In .NET, on the other hand, the Int32 data type is a full and proper Object. It’s a value type and lives on the stack, but you can still treat it as an object. Boxing is still necessary, but is almost invisible. Very smooth, very elegant.

You could argue that this is just hiding the details from the user, and leads to less efficient code. An invisible boxing requires as much resources as a visible one. But for most apps, differences of 15 ms are really not important, and developer time costs more than processor time.

I’ve always thought that, from a distance, case sensitivity looks like a bad idea. It’s even worse up close.

There is no upside. It only creates more work and endless opportunities for hard-to-catch mistakes. The only thing it allows you to do is to have a variable of type String named string, or perhaps two variables named astring and aString, but is that worth all this extra effort? It’s not like there is a shortage of available variable names so that we need to utilise every possible combination of letters. And no one in their right mind would use variable names that only differ by casing, anyway.

Humans don’t think in lowercase and uppercase. If I address a letter to someone in LONDON it will go to the same place as one addressed to London. Programming languages are primarily for human consumption, and should be designed thereafter. Otherwise we can all go back to writing Assembler code.

And if a language is to have case sensitivity for historical reasons (because C had it, decades ago, so all the C-derived languages are stuck with it) then the IDE should at least try to make it easy for the developer and correct, or suggest corrections for, typing errors that only involve casing.

If I type

fileutil f = new fileutil();

and there is no fileutil class but there is a FileUtil class, then it would be nice if the IDE fixed that! After all, it can suggest solutions to more advanced issues, such as incomplete referencing – if I create an ArrayList but haven’t imported the java.util.ArrayList class, it proposes to import it – and it can also suggest conceptually more complex changes like refactorings.

Is this some sort of macho thing where “Real Programmers Like Hitting the Shift Key”?

A Target store has painted a huge Target logo on their roof, so that it can be seen in satellite pictures such as those in Google Maps. (Found via BoingBoing.)

Ingeniously obvious – it’s a great way to advertise your location – and it’ll be interesting to see where this goes. We’ve already also got the Scientologists’ symbol. I’m sure we’ll soon be seeing dedicated art / installation projects that are meant to be viewed from high above.

(Sightseeing with Google Satellite Maps has many more interesting views.)

Edit: It appears that the logo was originally painted for overflying aircraft and not Google Maps. Less amusing, but the point still holds true.

This year’s most immediately successful Christmas present: a Sony PSP + Lumines. It’s a Tetris-like game but more and better. After a while, Tetris just comes down to having incredibly fast fingers. Here, planning and forethought matter more, and it’s possible to get a lot better by practising. Higher levels are not just faster but also different, and require different tactics.

The “colorful, swirling backgrounds” that the review describes as “clear and clutter-free” are anything but, in my opinion (big flashing things in colours that are very close to the colours of actual game elements) but I’ve got to admit that they are quite pretty.

There are also “time attack” and “puzzle” modes which are good for short games – a full game now takes me about 30 – 60 minutes, depending on how well it goes. A very nice game; the first one in a long time that I’ve really loved, and quite addictive.