It seems that in this industry we’re operating under the false assumption that once we learn (or hear about) a skill, it is with us for good. You only have to look at a typical developer’s resume for an example – it is truly buzzword central. I mean c’mon, just what exactly do you remember about XQuery or iBATIS at this point? I sometimes look at some of my own resumes I have used in the past and can’t help being impressed – if only I were really that awesome :). If you’re honest with yourself you can quickly classify all those skills into 3 categories:
- Stuff you have used recently and know pretty well
- Stuff you used to know pretty well, but haven’t used for ages
- Stuff you’ve had some exposure to, but don’t really remember much about
Only the skills and tech that end up in the first group truly deserve a place in that buzzword list. The problem is that we don’t tend to prune skills/tech off our resumes all that often. More stuff makes us sound more impressive – who wants to mess with that. This would actually have been ok if we made a conscious decision to include neglected and forgotten skills for marketing purposes, but the sad thing is the vast majority of developers/people truly believe that all those skills deserve a place.
The Power Of The Mind
When we want something to be true, we’re really good at convincing ourselves that it actually is. Companies do it all the time, they want to be the market leader so they portray/see themselves as the market leader – the reality of the situation doesn’t matter. The same is true for individuals. We have some minor exposure to a skill and we convince ourselves that we’re better than a total novice. This may be true initially, but without some reinforcement, this quickly ceases to be the case. That however is irrelevant, we already believe we have some level of expertise and so the buzzword list grows. What’s even more interesting are the tricks our mind plays on us when it comes to skills we actually did have some expertise in. You vividly remember when C, Smalltalk or XSLT was your bread and butter, it seems like only yesterday. But, it wasn’t yesterday, it was years ago, sometimes many years – you would be surprised how far those skills can degrade with time. On some level we’re aware of this, after all we’re not stupid, but we tell ourselves that it doesn’t matter, we’re just a little rusty, we can pick it all up again in no time – after all, it’s just like riding a bike. Well, let me tell you something about riding bikes.
Just Like Riding A Bike
I learned to ride a bike when I was very young and spent quite a large proportion of my childhood on one. It was simply the thing that we did during summer. I was pretty good (even if I do say so myself :)), that’s what constant practice will do for you. Then, my family moved to Australia and I didn’t ride for many years, until, during one fateful school camp, mountain biking was on the list of activities we had to participate in. I fully expected to ace that activity, my riding memories were still vivid in my mind. The reality was I sucked rather badly. Oh, I could ride of course, you never forget the absolute basics, but that was the only thing I really felt confident about. I could no longer judge properly how fast I could take the corners without falling over. I couldn’t tell how fast I could safely go downhill, so I took it easy. Riding in a pack with other people seemed scary and unnatural and after only a short while my legs were aching and I was out of breath. Sure, the basics remained, but all the skills, which are built through continued practice and reinforcement, were no longer there. I was essentially reduced to a rank novice.
The Harsh Truth
Every skill is the same, without continued usage and practice they quickly begin to degrade. Your mind begins to page-out the knowledge and experience to make room for other information. Some goes into “long term storage”, some is lost completely, but the net result is you degrade towards ‘noobhood’. The longer you leave a skill untouched, the more you mind will page-out. It takes longer for skills you were more familiar with and some knowledge is reinforced in other ways so that you never really loose it; but the hard-earned expertise, the things that make you more than just mediocre can disappear with surprising speed. This is both sad and dangerous. It is sad because in software, we devote inordinate amounts of time and effort to acquire and master the skills we use in our work. When the pace of our industry forces us into using wholly different sets of skills/technologies all that time and effort begins to go to waste. Previously useful skills get relegated into disuse and only see the light of day in the resume buzzword section. This is especially sad considering that the “useless” old-school skills are often not quite so useless after all. Ruby is all the rage these days, but to make things go fast, what are all the native extensions written in – C, so what’s old-school anymore? It is dangerous, because we absolutely refuse to acknowledge that we may not be as expert in some skills as we used to be. Sure we might loudly proclaim how we have forgotten everything about skill/technology X, but deep down we still believe that we can give these kids a run for their money when it comes to X (I am not precisely sure which kids and what money, but you get the picture :)). This is why we proudly retain X in the buzzword section, but if someone really needed that expertise in a hurry (like your employer for example), would you be able to deliver? I am certain you’ll be able to get it eventually, but so could any other reasonably competent person, there is a difference between that and expert knowledge.
So What Are We Gonna Do About It
We can simply be scrupulously honest and remove all the skills and tech we’re not sure about from the resume. But that actually helps noone, despite what I said above, you with your “rusty” skills, are still better than a complete beginner when it comes to those areas. So, by removing that stuff from your resume you’re actually underselling yourself – it is wasteful and an easy way out. Rather than doing that, why not make sure your hard-earned skills and knowledge never get quite as rusty again.
As developers, we tend to do a lot of practice and self-study anyway, but most of us do it in a very diffuse and unfocused fashion. We learn about the latest and greatest things that strike our fancy and we practice by building stuff that catches our interest. All of that is fine as far as it goes, but we can do a lot better. Here is what I suggest. Engage a in a little self-examination by taking all your skills and sorting them into four buckets:
- Core skills – these are the skills you consider primary to the direction you want your career to go. You want to make sure you become increasingly proficient with these and so should devote the most time to practicing them. There will only be a few of these at most (there is only so much time in a day).
- Supporting skills – these skills support and underpin your core skills. You want to practice these to a lesser extent than the core skills, but you still want to see slow and steady growth. If chosen correctly many of your supporting skills will get a work-out as you practice your core skills, but you should still make sure you devote some time to them exclusively.
- Peripheral skills – these are the skills that you consider valuable and worth maintaining. You’re not looking to grow these skills, but you don’t really want to lose them either. You want to devote enough time to these so that they don’t fall into disuse.
- Misc – this is the bucket for “the rest”. The truth is you can’t be an expert in everything, so this should contain the skills that you believe will add the least value to your development going forward.
You essentially end up devoting you practice and study time to your core, supporting and peripheral skills on a rotating basis, dividing your time between all of them based on their importance. It is difficult to sort your skills in this fashion (and even to work out what constitutes a skill, is building web apps a skill, or should it be specified into building Rails apps or alternatively generalised into being an HTTP protocol expert), so it might be useful to get some help, but it is an exercise that is eminently worth going through. What it gives you is a set of goals and a strategic framework for where you want to take your skills and your career. Rather than being slave to the latest trends when it comes to your practice, it will allow you to have some focus which can only make your self-study that much more productive (you’ll be able to ignore the fads because you know what you need to focus on and work towards). The side benefit of this is that after a while, you will be a lot more confident about the buzzword section of you resume and be able to prune it without making it look sparse.
So, which skills should be your core and which should be supporting? This will be different for everyone, I’ve already told you what I think about fundamentals, so that is something to go on, but ultimately it is up to you to work out what knowledge and skills you want to devote the most time to depending on where you want to take your career. It is perhaps worth exploring this in a lot more detail (it is fine to have a strategic view, but it doesn’t actually tell you what to do :)) and I might do this in a later post. Of course the other side of the coin is this, even if you do work out what skills you want to focus on, how do you actually go about practicing them, do you just write a lot of code? What if some of the skills I value are not coding related? That aspect of it is what I would call the tactical view of your growth as a developer – here it is all about deliberate practice and that is something I will definitely explore further in subsequent posts. Stay tuned.
Images by ItzaFineDay and Pete Prodoehl