On Personal Skills And How Even Riding A Bike Is Not Like Riding A Bike

RidingIt 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:

  1. Stuff you have used recently and know pretty well
  2. Stuff you used to know pretty well, but haven't used for ages
  3. 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

  • Liked the post, and agree with your Harsh Truth. Unfortunately, employers want to hire people who are expert in dozens of things, or at least expert in the employer’s hand-selected set of skills (just look at how vertically-oriented some of the job requirements are). I suspect many fallen-by-the-wayside skills are left on a resume simple to prevent the resume from being put in the “do not consider” pile. Most programmers or engineers I know who are worth their salt can recover and polish up those old skills and still be a profit-earning employee while doing so.

    • Hey Mark,

      That is true, I guess what I am trying to say, is that there is value in keeping even the old skills in use rather than having to quickly get across them again when you have to, it doesn’t just have to be playing with the latest and greatest when it comes to practice.

  • Maureen

    Recently found your blog and believe you have some good ideas that make the reading interesting.
    I am experienced software developer who is currently job searching and in the town I live in the employers want 5 yrs experience in skill or technology x or they don’t look at your resume.

    It’s a constant battle for developers to stay current on the latest technology.

    With this job search, I’m tailoring my resume as a generalist able to learn new technologies quick but as it’s an employers market, not getting much interest.

    I decided 5 yrs ago to get a commerce degree and look for roles as a business analyst because you are paid well and don’t have to learn the latest technologies every 18 months.

    Business skills + technical software knowledge is a good combination for me at least.

    • Another way to approach this problem is rather than trying to just keep up with the latest technologies, become more of an expert in an established one, that will likely keep you more employable than jumping from tech to tech, but it is certainly less interesting.

      Unfortunately being a generalist doesn’t differentiate you from pretty much every other developer out there, everyone is a generalist or at least claims to be one. Differentiating yourself is the key to getting some interest from employers when it is an employers market.

  • pradeep

    Really awesome post by you again, sure i will be changing my resume and will concentrate in my core skills , peripheral skills and supporting skills . Expecting more such posts from you.

  • Heh, nice that you’re touching on this. Something I’ve thought about a lot.

    As a career generalist, I certainly have a string of buzzwords, many of which are basically irrelevant. Sure, I was once a pro at XSLT, XQuery, X**. I’ve written largish scripts / apps in Python and Ruby and I’ve written some decent Java in the past, but I’m really a high performance LAMP, JavaScript hacker, Drupal expert and Scrum master / Sales engineer. Yeah, I know my core.

    But looking at myself as a job candidate, I would know that someone who has demonstrable experience in several relevant languages / frameworks means they are not bound to their tools, but learn quickly and recognize patterns. This to me is worth a lot.

    I don’t think any employer is dumb enough to expect the list of buzz words on a resume to mean a lot, so I separate mine into Wizard, Experienced, Limited (or some such distinction). This gives people a sense of the breadth of my experience, but also that the core skill *they* require is in my Wizard list :)

    • Hey Jacob,

      You would be surprised just how ‘dumb’ many employers can be :). It is often not even a matter of dumb, sometimes it is simply misunderstanding.

      I think separating your skills like this, is always a wise thing to do, it leaves a lot less room open for misunderstanding.

      • This sort of “misunderstanding” is pretty much inevitable when you have non-technical managers writing the job-orders, and non-technical HR people doing the screening. You wind up with job-orders for people who are skilled in cereal-port control, Sea Plus Plus, and the Eunuch’s Operating System. Even if it were all properly spelled, some of them will require that you have not only all the right skills, but have used them in the right combo — if you’ve done serial ports in C++ under Windows, disk control in C++ under Unix, and serial ports in Python under Unix, you still might not be seen as fitting the above job-order.

        • Hey Dave,

          Which in my humble opinion points to the fact that we need more technical people in management positions/leadership positions. Unfortunately many technical people aren’t really interested in becoming managers which is a bit of a dilemma. How do you get managers who really “get it” when the people who do get it don’t want to become managers? I’ve been thinking about this a lot lately, I should write it up.

  • Really wonderful post! Couldn’t agree more on what you’ve written!

    Honestly (and sadly enough), however, I believe that not many people really DO want to focus on building their skills. I’ve come across many developers who keep looking for some sort of comfort zone and love to stay there for as long as they possibly can! They are very disciplined in trying to restrict their skills ONLY between 9 and 5 and safe within the walls of their offices!

    However, the few population of developers who do focus on Deliberate Practise towards their skills definitely would love your post! Yes, riding a bike is not like riding a bike. Your example is great!

    Great post Alan! :-)

    • Sadly you’re right, I like to think the best of people in our profession and prefer to believe that any self-respecting developer will always continue to build their skills, but of course realistically speaking, there are plenty who don’t.

  • Ahmed

    Hi Alan,
    Fantastic essay as usaual.
    One of the topics no one is talking about alot is , “deliberate practice for developers”.
    I wish you right about this topic and your experience in learing Ruby.

    • It is infact one of the things I plan to cover at some point, soon :).

  • hi alan,

    i really enjoy reading your posts and i would like to give you a bonus through flattr (http://flattr.com/) – do you know that service?

    kind regards,

    • Hi Peter,

      I’ve never heard of it before, but sounds like a really cool concept. For the moment, the fact that you enjoy my posts is enough, my blog doesn’t really cost me much financially right now, although if it continues to get bigger like it has been, I will seriously have to consider a better hosting solution :). But, we’ll cross that bridge when we come to it, for now I hope you’ll simply continue to enjoy what I write.

      • it’s not just that you get the money, it’s also about contributing micropayments to all the other stuff that you like to consume.

        • Yeah, I’ve actually had more of a think about it since you’ve pointed me at it and I like it even more the more I think about it – seriously considering signing up at this point.

  • I recently removed all reference to which skills were used on which jobs, from my resume. Instead, in the Summary section up top, I have a line for each major skill category, like Languages, Systems, and Other. There are several I’ve worked in, and of course many I learned in school, that restricting it to one line each, forced me to omit. It also freed up room to make my resume attractive in other ways. (For details see http://davearonson.com/AronsonSoftwareEngineerResume.pdf .)

    As Neal Ford said in his Railsconf keynote, restrictions are often liberating.

  • It is true that non-technical HR and managers will often just look for the buzzwords while trying to recruit developers and that is what makes them write as many of them as possible in their CV. However that works just for the initial screening. Once you are through and have to face a technical interview with the developers, I figure, both parties understand what the work is about, what are the skills required and if those skills are actually available with the developer. So as Jacob has mentioned, we should keep the skills in the CV for the initial screening but we should also mention the level of expertise that we currently possess with those skill sets. That should make the HR happy as well as the team who will interview you and with whom you are going to work with.

  • We often get swayed by other factors such as what is being demanded from us or what could help us achieve a short term objective and then when you loose direction its easy to forget about your core skills and ambitions and you get on with day to day stuff, just my view

  • Pingback: Mark Freedman’s Blog » Blog Archive » The Re-Education of a Software Developer()