Tag Archives: Programming

My del.icio.us bookmarks for March 2nd through March 10th

  • Dear ISP, I am not a target market – "Some things should just not be for sale, no matter what assurances are on offer or who they come from. Regardless of how the data is acquired and processed, and despite the powerful ISP friends Phorm has made since the PeopleOnPage days, spyware is spywa
  • Happy now, bitches? – A fair and balanced analysis of yesterdays announcement of the iPhone software developer kit and "enterprise" functionality.
  • Polls say 88% want EU referendum – About a year ago the Daily Mail (I think) published a poll saying pretty much the same thing. But they also asked "Do you understand the Libson treaty?" and about the same percentage of people said "No." (Can anyone find a link?) Is democracy best served

My del.icio.us bookmarks for January 12th through January 16th

  • Apple introduces new Apple TV software, lowers hardware pricing – Now potentially more useful with the movie rentals. But where is the price drop in the UK?!
  • Dell tells customer ‘Mac is good option’ – “Now, it’s possible that the techie was referring to a 1970s rock band, or to an item of waterproof clothing. But we can’t help concluding that he was indeed talking about Apple’s operating system.”
  • Steve Jobs gets cohesive – Some cool stuff from Apple at the MacExpo. I think the Time Capsule is going to be on my shopping list when it ships next month. The movie rentals (when they get to the UK) look interesting but they really need to build their catalogue!
  • How to recognise a good programmer – Great discussion on recognising great developers. The problem would seem to be finding them! Most recruiters just pattern match on CVs which tends to favour the “career” developer.

Blessed is the Tool Maker

In the fifth part of Douglas Adams’ Hitchhiker trilogy, Arthur Dent makes his living among a group of stone-age settlers by utilising the one skill he had that was relevant to that world: sandwich making.

I guess we all have a special skill. But my point in this article is that if you’re a software professional, your special skill (unless you’re stranded on a stone-age planet) should be making software tools.

This realisation dawned on me over a long time. It’s well known that developers range in ability by at least an order of magnitude but less clear why. I’m certainly not qualified to answer that question in its entirety, however I’m convinced that developers can punch well over their weight simply by learning to write software that automates dull tasks, such as writing other programs.

Now a lot of people reading this will be thinking, “What’s the big deal?” Is this not obvious? Does every developer not do this? Originally I thought they did but recently became clear to me that that is not the case.

As is my habit, I had written a small utility program. A colleague was going through the same problem so I shared it with him. Even if we didn’t work for the same company, the script had only taken me a couple of hours to write. I made no claims that it was perfect but I knew that it did most of the heavy lifting required.

Next came the surprise.

A couple days later I conversationally asked how he’d got on with my script. It turns out that it didn’t work straight away; there was a minor bug. As far as I can tell he immediately abandoned my code and spent five hours doing the same thing by hand. He’d not mentioned the bug to me before and, for the record, it took about ten minutes for me to fix the problem that he’d encountered.

So, let’s make things very clear here. This otherwise smart person had done five hours work rather than spend a few minutes looking through a program or, even more bafflingly, ask me a simple question ((There’s an argument that the problem here is his communication skills. I’m not convinced that is the case in this circumstance. He’s normally fine. And I think I’m fairly approachable!)).

What’s the difference? Why do some people go out of their way to write simple programs while others go out of their way to do repetitive, mind-numbing tasks?

I think it’s simple. Writing a program to write another program just does not occur to many people, they have difficulty thinking in abstract terms and, in general, can’t go “meta.”

Looking back to my university days I remember a number of parallels. A number of people had problems with the assembler course, but the most telling in many ways was on our compilers course. A compiler is a literally a program that writes another program, normally from a high level language such as C++ to assembler or machine code, and to do this you need to keep two separate worlds in your head simultaneously. Firstly you need to consider the program that you’re writing, that is you need to remember all the lexical tokens and the grammar as well as the memory you’re allocating and using. Secondly, you need to keep track of what’s going on in the program that the compiler will be writing when it runs, stuff like the stack, the memory that it will need to allocate at run-time. Since both are just computer programs, many, if not most, of the people on the course had some difficulty getting their head around either the concept or at some level of the implementation.

So far you might think that I’m bragging, but really I’m not. There’s another key part of this. It’s not just a matter of building software tools, it’s knowing when it’s not worth the effort. Had my colleague known that it would take me five hours to fix the problem then he would have made the right move (if we discount the possibility that the script could help other people if fixed).

Similarly, on a number of occasions I have spent far longer building a tool than it would have taken to do it by hand. Sometimes the desire to solve a programming challenge means that I lack the perspective to see when it’s not such a good idea to script the task. Tool building is not without risk. Those truly great developers, no doubt, have both the tool building ability and the ability to recognise when it makes sense to do so.

But overall I still think that one very significant factor in making some developers more productive than others is their ability to write software tools, particularly programs that write other programs.

Mirror

This text is taken from the README and explains what mirror does and why I wrote it:

I think that I must have been looking for the wrong thing. When I restructured my web-site it became difficult to upload changes onto the server. What I needed was a program that copied files to the server. While I could find many programs that mirrored a web-site — copied them from the server — I couldn’t find any to do what I wanted.

Being lazy I started to look at other mirror programs with the intention of modifying them. The best candidate, when I tested it, didn’t actually work (no names!) and others had major creeping featurism. All had restrictive licenses.

So I pulled out ‘Programming Perl’ and started coding my own…

It’s not very big or complex, but it does as it says on the box. And as an added bonus it also downloads, just like all the others.

mirror-1.4.tar.gz

If you find another program that does the same job (better), let me know, I’d be interested to learn whether or not I wasted my time!

GIndent

One thing that really bugs me is badly formatted code. I’ve nearly written a PL/SQL indentation program a number of times, but have never actually? completed it.

But this time it’s different. I figured that most of the pretty printers out there are very poorly written and work only on one particular programming language. However, most languages are very similar to one another. They all have comments, blocks and ‘if’ statements.

Mine may not be much better written — you be the judge of that — but it is generic, having the capability of working with multiple languages.

It’s currently nowhere near complete, so I have uploaded my current development version to Sourceforge. You can check out the latest version here,
but don’t expect it to actually work for you just yet. There’s currently a nearly working HTML formatter and a very incomplete PL/SQL module.

How to Do What You Love

Even when I disagree with him, I tend to like Paul Graham’s writing. I like this essay, “How to Do What You Love.” Spending forty or more hours a week at work it’s important to like what you do.

This paragraph rang especially true: “If your work is not your favourite thing to do, you’ll have terrible problems with procrastination. You’ll have to force yourself to work, and when you resort to that the results are distinctly inferior.” I’m procrastinating a lot these days…