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.
