Is Programming A Generic Skill?

Writing

In my last post about the most powerful developer tool ever made I had a person leave a comment that said this:

I could not agree with you more. Google is your friend! I actually landed my current job because of Google. In my interview I was asked the question, "How would you rate your skills in C#, 1-5?" I replied "4", even though I had never seen a line of C# code. He asked me why I rated myself a 4 and I told him, "Programming is a skill, once you know how, everything else is just syntax and I can just Google the rest."

This comment had me thinking for a few minutes. Sure, knowledge of your programming language and environment are very important, but overall, is programming a generic skill that easily translates between platforms, languages, and toolsets? My first response was “kinda”, object oriented programming is a generic skill. If you know how to write good object oriented software, then you are likely to be able to easily translate that skill into another, demonstrably similar, language.

A Rose By Any Other Name

For example, if I were to be an awesome Java developer (which I am not) who can write great OO code, then I would very likely be able to turn around and write great C# code. I’d have to do quite a bit of searching, and trial and error to find out the particular way to connect to a database, search a string, write to a file, etc… but over the course of a few weeks I could become extremely productive in the alternative platform. As Thoreau said:

Every artizan learns positively something by his trade. Each craft is familiar with a few simple well-known well established facts-not requiring any genius to discover but mere use and familiarity. You may go by the man at his work in the street every day of your life.- And though he is there before you carrying into practice certain essential information-you shall never be the wiser.

There are simple well-known facts at play here, but these are both incredibly similar platforms. They practically share the same syntax, both are object oriented, they are both garbage collected, etc… The similarities go on and on. But if you came from a language which wasn’t so similar, then would we be in the same situation? Is it just syntax at that point? Absolutely not.

There are really two different ways that languages differ. First is in syntax, second is in paradigm. In terms of syntax and paradigm C# and Java are basically the same. Even C# and C++ would be considered very similar in terms of syntax and paradigm, but if a C++ programmer came into C# they could probably get around but would likely perform tasks in sub-optimal ways until they learned the ropes. Obviously the reverse is also true, but to a more extreme degree.

If you were to drop a C# developer into the world of Scala they would feel comfortable with the syntax but the shift to a more functionally oriented language would probably give them trouble for quite a while until they learned the ropes. Going further and putting the developer into a functional language like F# would push them even further, and without proper training and exploration they would probably be solving problems in entirely backwards ways because they are still thinking in their old paradigm. In F# though we still have the object oriented tools available to us, and therefore the C# developer would likely be able to at least fumble their way through a problem. However, if you took a C# developer and dropped them into the world of Haskell they would be a fish out of water. The software would be as foreign to them as a brain would be to a cardiac surgeon.

Making The Switch

Does this mean that the comment on my previous blog post wasn’t true? Absolutely not. In fact, he is almost certainly correct in the vast majority of cases. Object oriented programming dominates the development industry right now and moving between C++, C#, Java, PHP, Delphi, VB.NET, etc… are all extremely similar. Once you’ve learned how to develop in one, you can be fairly comfortable in the others in a matter of days or weeks. It isn’t even that far of a jump to go into object oriented dynamic languages like Ruby, Python, or Grooby. You just have to forget everything you were taught about the importance of type safety! If you are looking for a tutorial, look no further!

The bigger jump is when you look at the next generation of languages coming down the pipe and you start to think about the paradigm shift that would accompany languages like F#, Scala, Erlang, Clojure, etc… These languages, should any of them become mainstream will represent a shift in the fundamental way in which many programmers develop. In fact, many of us are already starting to make this shift if you are working in a OO language such as C# that is slowly starting to push more and more functional concepts into it.

Don’t Forget About the Libraries

Libraries can’t be discounted completely though. I wrote it off as earlier in this post as simply googling for a snippet of code to write to a file or parse a string, but the reality is that libraries that come with languages drarwf the languages themselves by many times. Over time a developer becomes familiar with his/her platform of choice and their productivity can rise substantially. The real question is how long does it take to get to this point? I for one subscribe to the idea that libraries are like spoken languages. The English language may have tens of thousands of words, but any individual usually only uses a few hundred in every day conversation. Those few hundred can take a different amount of time to learn, depending upon the person and the environment.

One thing is for sure though is that a developer writing C# in one shop and a developer writing C# in another shop can be exposed to two entirely different parts of the framework. A good example of this is that I went in for an interview once where the interviewer asked me to tell him how to connect to a database, fire off a query, and then read the results out. Well, I had just come off a two year project where we used a heavy abstraction on top of the data layer that mapped all of it into classes for us. I honestly couldn’t remember what the classes were called, and so I told him that. I explained that I hadn’t needed to use those classes in quite a while, and I made a few guesses about their names. Right now I am using them on a daily basis, and I wish I wasn’t, but I could name all of them off to you and probably even enumerate all of their methods! The point is that library experience is important, and learning tools is important, but they will only take you so far. The rest is up to you and your search engine.

Summary

So does out programming experience translate across languages and platforms? We better hope so, at least to some degree. Otherwise all of those pointy haired guys out there who are looking for the 20 year old guy with a year of experience in the tool du jour would be right! Ugh, that would be the most depressing thing ever. But I don’t think that is the case, I think that good developers span languages and platforms and they are the ones that are always searching for a better way to do something. They are always trying to be more efficient, more productive, and do more with less. They are always looking for a sharper tool. Are your tools getting dull?

Comments (6)

  1. I agree: It’s easy to move from one language to another if they share the same paradigm; but to sift to a new paradigm takes more work.

    I am in the same position as the commenter from the previous post. I got a job programming C# when I had never seen the language before. But I was able to demonstrate in the interview that I knew the basics of OO programming, and to show experience in learning new languages quickly.

  2. I think it is a transferable skill once a programmer knows a variety of languages – In some cases I find myself using techniques usually more suited to SQL or Haskell in C# and whilst applying another language approach all the time would be sub optimal, knowing which approach fits the problem-language domain is useful.

    It would be worrying though for people to be complacent – I work with a lot of people who learnt VB and then C# and find things out via Google without much out of time research or book reading – they call themselves C# developers but acually by a C# developers standards, they are useless, even given a couple of years professional development in the language.

  3. I think a language means a coding style.
    Changing from one to another often accompanies with problems that coding in the old way and cannot properly use the advantages the new language provide.
    Which leads to so-called "ugly code".

  4. Well I’m kind of impressed my comment warranted an entire blog post.

    The point I would like to make is: I do in fact think that programming is a skill.

    We are not like normal people, we don’t think the same way. I work at an engineering firm and I know several engineers that claim "Intro to Programming" was their hardest class.

    I’m not that great at math, so I know I wouldn’t be a very good engineer, but I’ve always had a great ability to look at code and just "see what its doing in my head".

    The "skill" I’m referring to, is the ability to identify the problem that you need to solve and using your resources to figure out the best way to solve that problem.

    For example do a quick search on "Repository Pattern C#", I’m certain you will find thousands of different ways to implement this pattern, some right and some wrong. The true skill is looking at all the different ways people are doing things and take whats best from each approach to find the best solution for your needs.

    How often can you honestly say that you googled some code, Copy and Pasted and it magically worked? Not very often…

  5. @RauhR Yep, thanks for the inspiration for the blog post! I thought it made for a great, thought provoking blog post.

    And yes, I completely agree with you that "problem solving" and reasoning is the real skill programmers needs…

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All