A Little Bit of Knowledge

A couple of years ago, I decided to get better acquainted with basic software programming, as a means of better understanding the challenges faced by my developer colleagues.

This had an unexpected effect. Since then, I've become a bit of a weekend addict. As Professor Richard Dawkins has noted, there is something incredibly satisfying about stringing together a bunch of conditional statements against a set of inputs and desired outputs - and then seeing the result pop up in front of you.

When it all works, it's a lot of fun. But I'm starting to suspect that in addition to the thrills described by Dawkins, there are other benefits that occur when someone from the corporate, or 'sales and marketing' side of the house starts playing with conditional statements on the weekend.

One of them is a more tangible level of respect. I've always had a ton of respect for developers, but that respect has sharpened now. I now also have an increased level of understanding of the challenges.

One example: I used to get exasperated whenever developers would talk about not being able to find a bug that was holding up delivery.

I would say, "Why can't you find it? Why is this so hard?"

Not any more. Developers, you are forgiven. Now, I too have sat for hours some weekends staring blankly at the screen in front of me - only to have it dawn on me that I didn't close a statement properly or call the right resource, after the hundreth walk through the code.

Lesson One: Bugs happen - we're only human.
Lesson Two: Code review should be done by someone other than the guy writing the code.

I also have learned the hard way why developers often insist on writing solutions from scratch. Yes, mash-ups can be fun - but they can also be unpredictable, and pieces of seemingly stable code can interact in weird ways.

And sometimes, unexpected updates (from the developers of one side of your code mashup) can destroy everything you've written (just ask a Facebook Apps developer) and take your project into a direction you never intended to go. No, it isn't always a good idea to 'buy it'.

Lesson Three: If it's fundamental to the business, write it yourself.

Documentation? Guys and girls, please spend all the time you like documenting your code - I get it now. Those little comments are worth their weight in gold - the more the merrier. Dev wikis, toolkits and forums can expand your developer network exponentially - providing the documentation is there.

Lesson Four: Documentation is as critical as the code to success.

The other benefits are a greater understanding of the way developers work. I now understand the requirement that when you're faced with something hard, you really need to bolt yourself down for 18 hours (or 36 hours) and have someone feed you Coke and pizza - because when you're working towards the middle of two ends of a two thousand line piece of code, it can be really hard to 'pick up the thread' (that's a developer pun) if you stop.

Lesson Five: Create a workplace for coders that is free from distractions.

One other thing I've learned is that coding and rocket science are similar in that they are not necessarily difficult (having worked extensively with both rocket scientists and coders, I feel qualified to make that statement) - but they do require a ton of knowledge. The more up-to-date and extensive that knowledge the better. Fewer things will blow up.

Note: If you can find a development manager capable of winning respect based on their past experience, willing to 'manage' rather than code, and willing to share knowledge with your young team and mentor them, I suggest that you pay them very very well. There is no greater value.

Lesson Six: Experience is critical. Put a "hands off" grown-up in the room with your young wizkids.

Finally, a word on testing. Too many people think quality assurance (QA) testing is finished once you've fired up a clean VM image and tested your software. This is BSQA - if you're not testing your code in the real world, with real users, on real machines, you're fooling yourself as to its quality and value to end users.

Lesson Seven: Real coders test on real machines using real users.

I should emphasize that my own coding efforts remain just a hobby (my stuff sits on an outside hosting company server, not at the company) - and my understanding remains a helicopter-level appreciation at best. But the experience has been very valuable and has given me a greater appreciation of the depth of skills we have at our company.

And as for the aphorism "a little bit of knowledge is a dangerous thing", my response is this: a little bit of knowledge is only dangerous when the person with that little bit of knowledge remains ignorant of the sheer amount of knowledge that exists outside that subset.

In my case, I believe my little bit of knowledge has led me to an enhanced understanding and greater appreciation of the scale of knowledge we have in our organization, the real time required for quality work to be done, and the kind of specialized skills that are needed to create great software.

And that's a good thing.