Specific Skills vs. Concepts and Background

Specific Skills vs. Concepts and Background

Is knowing obscure features of a programming language really good for maintenance?

If you can’t find someone that can answer the questions you are asking about obscure language features, maybe you shouldn’t be using them.  A goal of good design and implementation is for the code to be maintainable.  If people see an obscure feature and don’t understand it then that makes the code harder to maintain.  I would think that companies want to avoid this.  So why does lack of knowledge of this become a reason not to hire someone?  I would argue that you shouldn’t hire someone that sees no problem using them or even likes using them. 

I once was told that code should be written so that a mediocre programmer can understand it.  This is a bit harsh, but has some truth.  The easier code is to understand the easier it is to maintain and test.

To build on this, aren’t languages just tools to be used? 

What’s more important, knowledge of specific tools or a good foundation in software development?  As an example, knowing the foundations and concepts around building a data warehouse is far harder than knowing enough of a language to implement it.  Someone with a solid foundation in software development will be productive in a new language in a couple of months.  Being able to understand the concepts and issues around a data warehouse for large amounts of data will take far longer.  Any engineer with a solid background can jump from C++ or C# to Java very easily.  With the amount of information on the web I have never been slowed down very much by having to look up an API reference.  I have actually often thought that asking a person how to do something and giving them tools to figure it out is far more interesting than expecting them to know it up front.  I have done something like this before when interviewing a candidate.  To go back to my example, if you were to search on how to build a data warehouse you would be reading for a while, even if you know what a data warehouse is.  However searching for a reference to the map object of a language would take much less time to grasp and use that information.  This assumes you know what a map is.  Even going as far as which container performs better, so you use the correct one for your problem, is fairly easy to get from a quick search.

Having said all this, coming in and using a completely new paradigm of programming is not quite that simple.  If I’m an Object Oriented programmer, it will be harder to jump into functional programming.  I believe that with a solid background, the engineer can understand the new paradigm.  However, getting used to thinking like that will be harder.

Dan Johnson

Principal Level Hands on Software and Data Engineer

9 年

Another one, “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”― Brian W. Kernighan

回复
Dan Johnson

Principal Level Hands on Software and Data Engineer

9 年

Just heard a great quote from OSCON, "Don't write interesting code, write boring code that does interesting things." This sums up what I think in one line.

回复
Michael Woodside, PMP CSM

Software Engineering Senior Manager at Dell EMC

9 年

Excellent article Dan. You mention several great points that I agree with totally. I found the article very useful.

要查看或添加评论,请登录

Dan Johnson的更多文章

  • Simple Failure Subsystem Flow for Larger files.

    Simple Failure Subsystem Flow for Larger files.

    This is a series of S3 buckets using events to fire off Lambda functions for orchestration. We use S3 buckets instead…

    1 条评论
  • Agile Culture

    Agile Culture

    Agile Development comes down to corporate culture. For a development company to develop software with agility means the…

    1 条评论

社区洞察

其他会员也浏览了