Slipping out of software development

Tags:

By Chris Douce

I haven't been working in the field of software development for a number of years now. During this time, all the coding I've done has been some PHP development on a research project and migrating five or six small C++ programs to Java. When I say small, I mean programs ranging between one hundred and five hundred lines long, nothing substantial. The programs didn't do much either: they were designed to exercise different OO features and might be used as experimental materials for a small project I'm involved with.

The thing that struck me about doing this small programming task was how much time it took me. I struggled a bit for the first couple of hours. I quickly realised that I was 'rusty'. I could barely remember the Java syntax (which reminded me of the Shneiderman/Mayer model, which was one of the first psychology of programming papers I read) and had to constantly refer to documentation and websites for help. Programming began to take on the form of a process of re-learning how to do stuff.

Here's another dimension to this: just before starting to compile this article I downloaded a web development IDE (so as to not blind myself with too many angle brackets). I visited the vendors website (which I hadn't visited for a couple of years) and was surprised to see that everything had changed. The original product I was once familiar with had morphed into something else with loads of new unfamiliar functions.

These two points made me think of things from the side of technology recruiters (a subject that is related to one of the 'connected links' that features within a later part of this newsletter). How might my skills be interpreted by a recruiter. Although I might be able to say, 'yeah, I've used C++, I've four or five years experience of using it...', I am likely to be asked (as I have been asked before) 'but when was the last time you have used it?'

One of my long standing interests in this area of the psychology of programming is that of memory. We use different types of memory whilst we code: different types of short term memory (spatial and articulatory), long term memory where we hold facts about how things work, and autobiographical, which is facts about stuff what we did.

I guess my own long-term memory for programming can be divided into two main areas. The first is memory that relates to skills, such as knowing how to do stuff in a particular language or a product. The second relates to knowledge of systems that I have worked on. What I mean is that if I'm sat in front of the code for a project that I worked on five years ago, I'll probably remember quite a lot of what goes where, and also remember why I coded things in particular way. But might this be something unique to me? I doubt it. Perhaps it might be useful to understand more about the notion of developer skill degradation (and if there is such a phenomenon).

I guess technical (and software development) skills exist in hierarchies. At the top there's operating systems, followed by how to use integrated development environments (where menu options and compiler options can move around), followed by programming languages. Another dimension is the notion of software development frameworks or libraries. Knowing such products, of course, enables developers to gain huge productivity boosts.

Early in my studies, I discovered a whole vein of research where cognitive psychologists were trying to understand the nature of expertise through specialist domains, such as chess. Computer programming was one of those domains too. Not so long ago a colleague mentioned in passing that expertise is something that takes ten thousand hours of study or work to acquire (don't ask me for a reference for this, since I don't have one!)

I've lost count of the number of times bloggers and writers have compared the activity of software development and design as a craft skill. Perhaps computer programming expertise ought to be conceptualised less in terms of individual products (such as languages), but instead in terms of sets of tools?

I guess this short collection of (quite random) paragraphs is ultimately asking a number of questions. These might be: how is technical expertise perceived by others? Do developers tire of developing? Is there such a thing as a career ladder for engineers who don't wish to move into management? My final questions are, 'what does it actually mean when you say that you're rusty?' and 'how long does it take for an experienced developer to get moving again?'

Recent comments

No comments available.