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.
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
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.
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.