• Stuff you must know: your tools

    Fri 21 May 2010

    Few programmers have in-depth knowledge of the primary development technology that they have chosen to work with. Programmers work with Java, C#, C++, VB.NET and PHP and other languages in blissful ignorance of key concepts, features and functions of the programming language, the libraries, the API’s, the object models, the frameworks and the virtual machines that they code with every day.

    In five years of searching for programmers I’ve made alot of phone calls to job applicants to find out about their skills and experience. During the phone interview I ask key questions aimed at quickly identifying if someone doesn’t know key areas of their primary development technology – things that someone with in-depth knowledge would know. If they can’t adequately answer the questions then it’s fairly safe to say they don’t know their primary development technology in depth. The vast majority of programmers that I speak to do not know their primary development technology in depth.

    It’s disturbing that so many programmers don’t have in-depth knowledge of their primary development technology. What happens when they are working on the same code base as other developers who know more? Nothing good. The programmers on the team with stronger technical knowledge implement features and functions into the code base, designing and constructing conceptual models and solutions that are a complete mystery to less knowledgeable programmers. The programmers with weaker knowledge flounder and spend ages trying to grasp the code that they are looking at. Eventually the weak programmer gives up and asks a more knowledgeable programmer what this code does, or they go and try to fill the gaps in their knowledge or they bulldoze in and try to make changes without really grasping quite how this section of code works, breaking it, adding bugs and generally wreaking havoc.

    Worse is a scenario in which the team has no programmers with in-depth technology knowledge of the primary development platform. In this scenario the code base is all built using the basics of the development technology, using just enough of the features and functions to get by. Few of the advanced features are used, features designed to make things faster, easier to maintain, easier to build, simpler, more robust; instead things are hacked together in the hard way, the long way, the slow way and the wheel is re-invented.

    Some might object to this line of argument and suggest that in today’s world, programming is about Googling. You don’t need to know things in advance, if you find something you don’t understand just look it up. These programmers operate on a “need to know” basis – they learn when they need to know something specific. This iterative, just-in-time approach to learning builds up knowledge by bumping into unknown features, functions, objects, methods and properties and then looking them up on Google. Such programmers iterate through a constant roadblock/learn cycle. The iterative learning programmer only knows stuff that they have been forced to learn after finding it in use somewhere. The down side of iterative learning is that a programmer can’t set out to take advantage of features and functions that they have never seen before; they only ever have a subset of a technologies full capabilities available to them. They don’t know the full picture of what can be done.

    Why are so many programmers comfortable with having only partial knowledge of their primary development technology? It depends on who the programmer is, and their attitude:

    1. The programmer who just isn’t into it. This programmer doesn’t love their job and isn’t interested in making the effort to thoroughly understand the technology that they program all day. They learn the minimum required to keep their job. There is no hope of getting them to learn their primary development technology in depth. They just aren’t interested.

    2. The competent, workman like programmer. They might be good, competent, excellent or even superb programmers within the bounds of what they already know. Probably however they are mostly ordinary programmers. Through the course of their career they have been constantly learning new things iteratively, picking up new languages as they need to and learning just enough to get by, adding progressively to their knowledge. Over time they have fallen into using their primary development technology and learned it on the job. When they see some new object, method or property they learn enough about it to add it to their repertoire. They have found that this approach has always been good enough, so there’s no great incentive to push harder. These guys are pretty happy with the status quo and can’t really be bothered to take the time to make learning a separate activity from programming.

    3. The enthusiastic, passionate, uninformed programmer. These guys love programming and are very enthusiastic and passionate. They code away madly using the same iterative learning approach as other programmers, firing up Google when they see code that does stuff that they don’t understand. But when you scratch the surface you find that whilst these people are passionate, code at home, have personal projects, and love their work, they still don’t understand key concepts, features and functions of their primary development technology. These guys have the most to gain from learning their primary development technology in depth. There are lots of programmers like this who love to code but still don’t know stuff that they should know. Why has their passion not translated into expertise? A great question. Perhaps they don’t know how or what to learn, and perhaps no-one has yet pointed out to them that they should be learning this stuff. Perhaps they are sufficiently inexperienced to think that the only job of the programmer is to write code.

    It’s the enthusiastic, passionate, uninformed programmer who is both the greatest waste of talent and who also has the greatest potential. If these guys direct their passion towards systematically and thoroughly learning their primary development technology, they can become the very best sort of developer: enthusiastic, passionate, expert and informed.

    But what to do? How can a programmer develop an in-depth understanding of their primary development technology? It’s pretty simple, and mainly about pulling the finger out and making the effort. Here’s how:

    • Set a personal goal of thoroughly understanding your primary development technology.
    • Make time in your day and week to apply yourself to learning.
    • Make a list of the things that you have heard of but don’t understand.
    • Read the features list of your chosen development technology, identify things that you don’t know.
    • Whenever you find a term or a concept you don’t understand, work hard to learn it. Leave no stone unturned. Understand everything you read, and if you don’t understand it, work until you do.
    • Re-learn/research what you think you currently know, make sure you really understand it.
    • Read the reference manual from start to finish; don’t just skim across it, thoroughly understand everything described.
    • Go through every object and every method of the API, make sure you understand them all. Look at the release notes and the list of new features every time a new version of your development technology is released.
    • Discuss new concepts with other developers, try to understand it they way they do.
    • Organise a weekly lunchtime discussion meeting in which the development team discuss one key concept, ensuring that everyone on the team understands it well.
    • Practice - implement your new learnings in code.

    Is it reasonable to expect programmers to know their primary development technology in depth? Absolutely. Do you expect a builder to understand all the tools in their tool van? Do you expect a surgeon to understand all the instruments on the silver trays in the operating theatre? Of course. It’s your duty as a professional programmer to thoroughly understand this stuff and if you do not, then you are letting your employer down, your teammates down and yourself down.

    andrew.stuart@supercoders.com.au

    Copyright © SuperCoders 2010 - 2011 All Rights Reserved.