Well, it’s a while since I wrote a blog post so why not kick off with a slight bit of professional heresy. I write software for a living; have done for over 30 years, starting with SCMP microprocessors in my teens (yes, I was THAT sort of teenager…) and working through everything in between until now when I spend my time split between .NET, JavaScript and PHP.
Now, why do I write code? Well, occasionally I do it for fun, but mostly I do it for profit – my clients pay me to do it. Actually, that’s not right. My clients pay me to solve their problems for them using software.
I’ve never been one of the great ‘geeks / hackers’ in life; I’m a radio amateur and electronics whizz, and the closest I ever came was in my teens and early twenties when I was fiddling with low level stuff like analogue to digital converters and the like; but pure software geekery has never been me. I used to say to people that I was a reasonable programmer but an excellent developer; now I’m more likely to say I’m an excellent problem solver.
Don’t get me wrong; I have an active interest in my profession, from the perspective of how I can deliver better service to my clients in delivering what they want from me. And I like to think that I write sound, efficient and effective code. I create data structures, create objects to model those structures and business processes, create code to implement these abstracts and put something on my client’s desktop or web server that allows them, bottom line, to make more money or save more money. I also write code that is easy to follow and maintain, that has sensible variable names, that I document and leave a pile of useful information with my client. And I’m there for them when needed. I love it when I get a call from a client who tells me ‘We needed to add a new feature, so we took a look at the code and documentation and we think we’ve done it right, but next time you’re in, could you give it a quick look?’ – the ultimate accolade for me – I’ve delivered code that others can pick up and run with.
I’m methodical, but don’t have what you could call a methodology; I was recently asked whether I was agile; I almost replied that I used to be but since I tore my knee cartilage a few years back I’m not as nimble as I once was. Do I practice Extreme programming; not really, I’m more Church of England, middle of the road, myself….
I’ve started to notice that there are two broad categories of software developers; those who work for software houses or in large development teams where words like Agile, Extreme, kanzen, dojos, user stories, sensei are the common parlance, and those who work very close with business and organisational problems, where the usual words that define a day at the coalface are fix, solution, feature, document, debug, budget, timescale.
I like to talk to my clients in their language; I’m afraid I still work in a world where businesses have processes, not user stories; where they don’t particularly care what technique I use behind the scenes as long as I deliver working, maintainable and efficient code, to budget and on time. I’m sure that the software house methodologies work effectively but do they provide yet another layer of obfuscation, bureaucracy and abstraction between what we do and what our clients and customers want us to do – solve their problems?
No matter how much we dress things up with Japanese words (and I speak with some knowledge and experience of Japanese culture and management) we must not lose track of what we do and why we do it; we solve problems by developing effective software systems delivered on time and to budget. That is all our clients care about; we’re not ninjas or ronin; we’re professional programmers and problem solvers.
I guess what I’m saying to developers is don’t fetishise what you do to the point where the process becomes more important than the product. It’s rare I have much good to say about Steve Jobs and the slavering behemnoth that is Apple, but he did once say ‘Great artists deliver’. And that’s what it’s all about.