Changing times

Since joining my current company two years ago I have been on a single project, transferring from a Java server development role to a position that also sees me as the main C# client developer, a situation that I actively pursued. This has helped keep my interest in the project alive(we developers are a fickle bunch who get easily bored) and allowed me to extend and expand my experience practically at the same time.

During this period the project has seen an initial major delivery and a second large delivery, but along with my mutating responsibilities the composition and size of the team has also varied during this period. As the bulk of the development work has been delivered the team has shrunk in size in all areas, development, test and management resources have come and gone, but mostly gone.

The time spent here has given me an opportunity to work with some good people, in terms of both talent and personality. Several of the people I've had the pleasure of working with have made my job better and more enjoyable than it may have otherwise been, and I'm pleased to say that comes from people both above and equal to me, as well as those with more and less experience than myself.

One of the things I have noticed is how specialised our current roles make us over time, and I believe this is something that is getting more pronounced as the breadth of technologies and libraries expand. That's not really news, it's something I've noticed before, along with probably virtually all others in this profession I would imagine. It should have come to be expected to a certain degree.

By specialised I mean that depending on what our current task has involved, or more specifically involves on a regular basis, each of us inadvertently becomes more knowledgeable in those particular areas than those we visit infrequently, we become a domain expert. Again, this is only to be expected, by my point is just how pronounced this knowledge unbalance now appears compared to how I viewed this in the past.

Years ago I knew people (and was hopefully one myself) who were competent in vast areas of a language or libraries, but specialised in a subset of those. Now it appears (at least to me) that the programming domain has grown to such an extent that we are becoming increasingly ignorant of areas in which we have no recent experience. The difference here is that where we once may have "known a little", we now know "a very little or nothing at all".

This is to be expected as the technology expands, but I feel it reveals an underlying problem in recruitment going forward, both in my future roles as an interviewer and an interviewee.

I suspect everyone who has looked for a job in development will have seen plenty of jobs requiring experience in just about everything going in a particular technology, most of which we will be aware of to a certain degree; some we will know inside out, others we've not visited for some time will be "rusty", and the final few we've never knowingly encountered.

As time goes by and technology expands this category of inexperience continues to expand rather than shrink. But here's the thing - if it's expanding for me with over twenty years experience, how are people with just a couple of years able to claim knowledge in these areas?

That's quite simple, just by having a basic understanding. I can probably tell you enough about rewiring a house to make you think I would be able to do it. If I actually did then re-wire the house, you'd probably find you got through a lot of fuses (possibly also a few calls to the fire brigade).

The same is true for the people claiming experience in multiple unrelated categories. I may be able to read an article or overview on a new technology/library/methodology, and this will be enough to get me through that section in an interview, but should I then need to use that skill I'd be starting from scratch - the exact same position as somebody who claimed to know nothing.

This raises two issues itself. 1. How can the interviewer tell how much you actually know from the interview (or indeed experience to a certain degree), but more importantly 2. How much does that actually matter?

The more important thing is to find somebody who has a core competence and who is willing to embrace new concepts, anything else can be learnt. We do it all the time, it's regularly part of the job. The trouble is if we're not learning the right things to tick off the right boxes we appear less skilled.

I'd argue that it is often those who don't appear to know a little about everything who know the most. Good luck making the distinction in one or two hour long segments which need to cover other areas though.

As time goes by I become more aware that many of the most consistently competent developers I've worked with have been focusing on a few key areas. They turn out consistently good code, and most importantly can actually be relied on to deliver.

In contrast I've also worked with a number of developers who have latched onto a wide array of technologies, who would be able to suggest any number of new tools appropriate to deliver a particular solution, but who ultimately turn out code that barely works, is poorly constructed and is over complicated (by either use of too many technologies, patterns, or just generally over engineered). And that's is they manage to deliver anything at all.

The trouble is who is going to look better in the interview?

Seeing through this is an art that is not necessarily possible in a series of interviews, you sometimes just have to go with gut instinct, but one thing that is worth considering is this: A good developer will be able to learn a new skill and apply it to get results as required. A "less capable" developer may know everything about everything, but if they can't deliver on that...

Unfortunately looking at job advertisements it seems this latter class is expanding quickly and being sought more highly.

Perhaps that's why the architecture is now a separate beast to development, they have to go somewhere when they're found out.