The Code Whisperer

Back in my mainframe days of the early 1980s’ I worked on a COBOL controlled circulation system for trade magazines. The software house that wrote the system and provided a bureau service was fun to work for, demanding and I gained a lot of knowledge about software development in a short space of time. The way software houses work doesn’t suit every developer, but if you’re smart, prepared to work hard and have a get the job done mindset you’ll enjoy the experience.

There was a chap there called John. He had been there pretty much since the company was founded, had a brain the size of a planet, a pretty gruff nature but was prepared to help anyone, provided they put some effort in themselves. Asking “what’s the command to do x” would instantly invoke a “read the manual” response. A more considered question, for example “I’ve looked at this and I can’t decide the best way to do it” would release years of wisdom.

The most important thing I learnt from John, was simply if you needed to look something up, read all you can. Now this didn’t mean if you needed to remind yourself of the syntax of a command you didn’t know, but if you had no idea of its existence. This approach gives you a very broad grounding in a subject, beyond a simple need to know basis.

I’m not sure when the computer manual disappeared. They were replaced by a variety of books on how to do things and third party reference books, and these, it seems, has been replaced by the Internet.

I was listening to Joel Spolsky and Jeff Atwood’s first podcast from their new www.stackoverflow.com developer’s website. In it they talk about the demise of the computer book as most questions are asked online and then talk about why this doesn’t always work. In simple terms if someone discovers a problem with software (be it an application, IDE or language) there may not be a solutions, so a posting to a forum could result in a number of “you can’t fix it” replies. The software vendor then, some time later, releases an upgrade, but other people searching for the same problem are likely to see the “you can’t fix it” messages first and unless they dig further may not find the answer they need.

The web’s great for finding resolutions to problems. If it’s a bit of code that can be easily and completely tested go ahead and use it. If it’s opinion or can’t be tested now, as in the scenario above or, for example, a new way of building software or a new architecture don’t adopt it without clarification.

The Golden Rule of Internet Research

Don’t base a decision on one person’s opinion or comment. Clarify everything. Just because it’s written doesn’t make it correct

The last part can also applies to books. I’ve seen mistakes in books, but this is rare. The amount of effort and money required in putting a book on the shelf tends to discourage people who will happily share their opinion on the Internet. I include this blog in this category. Just because I’ve written it doesn’t make it right for you and your development.

I would encourage you to allow your development team time to expand their knowledge by digging a bit deeper in the same way John did. Expanding their knowledge is good for them, good for the team and good for your development. Encourage people to be more self sufficient rather than interrupt their colleagues, maintain a library of books and articles, get a Wiki online for information specific to your development, industry and company.