Ben Hughes

Something about the “non-programming programmer” articles gets under my skin. Sure, I can reverse a string without using in-built language features; hack together a recursive Fibonacci algorithm; and solve FizzBuzz. In fact I just did them to make sure. But it seems extremely limiting to use these as a screening process, particularly if they’re being done on paper.

There’s an elitism, a snobbishness here that I don’t like. There’s an assumption that people who don’t think in a certain way aren’t real programmers.

I had a working solution to each of the problems in a minute or so, but that included at least one incorrect iteration per problem. I know that the most efficient way for me to work is to roughly hack out the code then refine it. That’s one of the reasons I like TDD so much - it makes my iterations quicker and more accurate. Writing code on paper is something I’d probably not enjoy, even for these simple examples. Rather than quickly iterate, I’d have to plan up front. Which of course I can do, but it’s sub-optimal.

If writing code is going to be a part of the interview process, it should be done in whichever IDE the applicant is comfortable with. But even then it should only be one factor in the evaluation. Even for a straight up code monkey job, a developer’s capacity to learn, explore and communicate are at least as important as how quickly they can solve trivial puzzles.

Chase Jarvis has recently driven home the old addage that the best camera is the one you have with you. For a long time I’ve been saying something similar about exercise: the best routine is the one you do regularly.

The underlying message is that its better to execute something imperfectly than to not execute at all. Or to state it more simply: delivery matters.

It’s a constant frustration to me how many people don’t give enough weight to delivery. They feel that it’s just one of the many requirements of a project, along with proper architecture, project management, reporting, testing and documentation. While all of those things are important, and often aid the production process, they don’t make a damn bit of difference if you don’t deliver a system that meets the core business need.

For a lot of ’successful’ projects these important, though secondary, aspects are missing. And because we agree that they are important, there is a tendancy to over-inflate their importance in an attempt to ensure that they are done in the future. While this is admirable, it’s unrealistic. What it doesn’t consider is how many projects had all these things in place, but never saw the light of day.

Often you need to take short term productivity hits to ensure long term viability. Focusing on delivery doesn’t mean that you can’t, or shouldn’t, improve processes. But you have to do it whilst still delivering, even if it’s at a slower rate.

A perfectly designed, archtected, managed and tested system is worse than useless to your clients if it doesn’t help them meet their business needs.

So please keep striving for improvement, but remember: the best system is the one you actually deliver.

Posted via email from Ben’s Stream

My site has a customised Wordpress install, a custom domain, email addresses at that domain and now a subdomain for my life steam. And other than the domain name itself, I don’t pay for anything. It’s taken me a while to work out how to get this all up and running. This post will briefly cover the services I use and the downside of going with an “almost free“ web presence.

For the core website, there’s a lot of free blog hosting options like Wordpress.com, Blogger and Posterous. I didn’t go down that route in part for historical reasons and in part for the  flexibility of being able to customise Wordpress. Instead, I went with the free web hosting service Freehostia, which provides basic php and mysql support. Freehostia also gives you control of the DNS config, allowing you to buy a domain elsewhere and associate it with the site. There are other comparable free services if you hunt around.

Read the rest of this entry »