I am an old school developer. And I have been struggling to land interviews in the modern world. However once I got into the job my performance on the job usually exceeds expectations.
I have tried to think about the issue. My conclusion is that I am a victim of a world where people look for knowledge of specific tools rather than knowledge of a specific subject matter.
Often people are looking for a Delphi Developer, a C Sharp developer or a Python developer. It seems the assumption is if you know a specific tool inside out then you can handle any subject.
I find it rather strange. Suddenly you do not need to know what the Newton-Raphson method is or entails, all you need to know is C-sharp and wallah you should be able to solve a power system stability problem. You do not need to know what a Voronooi polygon is but you should be able to model a mine's ore body because you are a C++ developer.
I tend to approach things from the other side. You need to know the subject matter thoroughly and then know, not just one, but maybe one or two tools that you can use to solve problems in that subject matter. In fact in my world you do not need to know a specific tool, but the available tool's manual and documentation should contain enough information for you to solve the problem with that tool.
In many subject matters there is a lot more than number crunching involved. Every subject matter has a set of theories, concepts and assumptions you make before you arrive at the number crunching. Very often your number crunching choices depend on what you want to optimally solve based on the concepts and theory of the subject at hand.
I think the industry has suffered a lot from this focus on tooling. I have worked on many projects where it was patently obvious that the developer doing the calculations had no idea why they were doing it but had just been told add these numbers.
I have also worked on projects where people think I am genius but the truth is simply that I understand the concepts more than the average developer.
Unfortunately the job market of today people are looking simply for knowledge of a specific tool. I have been to many interviews where if I ask what nature of problems we are going to be solving, people simply can not answer. People will simply be looking for a developer who knows a specific language.
Very often the questions asked to test such knowledge are classroom questions. That is where I have a problem. Classroom questions are usually asked of someone who has been following a specific syllabus and using specific textbooks for the past couple or so of years. The syllabus and textbooks would have prepared them for question worded in a specific way. In some cases the expected answers would have been provided several times. They often determine how well you have crammed or memorized the contents of your course.
Then there is the question of concepts and theories that may be implemented differently by tools. You guessed right. I am talking about object oriented programming. Object oriented programming does not just fall out of thin air, but it follows from object oriented system analysis. Your system must be constituted of objects intended to solve a specific problem optimally.
The objects may even change depending on what what the problem you are solving is. If you are building a house, then you need to have objects called foundation, walls, roof and fittings. If you are decorating a house, then it is much better to have objects called lounge, bedroom, kitchen, study and bathroom. Your objects should simplify how you solve your problem. They do not need to demonstrate how well you know object oriented programming theory.
If your SYSTEM objects are properly designed, you can PROGRAM your system in any language and STILL be able to follow object oriented programming concepts.
I have this one word of advice for industry. Knowledge of languages specifically designed or restricted to object oriented programming, does not equate to knowledge of object oriented system design. In fact application of OOP to an improperly designed system, can actually worsen the original problem that OOP is trying to solve. That is the problem of simplifying system maintenance.
I have worked on systems where every line of code is in an object as per the language specification, but the system has not been upgraded for decades because the objects are spaghetti. I will admit on some of the systems it was because of deliberate obfuscation by coders (a technique which some people use for intellectual property or job security purposes). However in most the problem was that the system was not correctly designed in the first place.
There are concepts that have to do with system design, and that have an important impact on your system objects, but have nothing to do with object oriented programming per se. I will mention system modularization and component standardization. A system module may form an object, a standard component may form a base class. Such concepts do not apply to programming only. For example in construction a roof or a foundation may be system module and a brick may a standard component. In a properly designed house if you change your bricks from say commons to blocks, you do not need to change your roof in any way.
You may not know anything about firing bricks because you have used cement blocks all your life, but that does not mean you do not know how to build a house.
Back to the subject of programming, I maintain that knowledge of of a subject matter is more important than knowledge of a tool. I have implemented algorithms like Newton-Raphson in several languages (Pascal, C, C++, Modula 2) and I have implemented asymmetric key cryptography in the above languages and PHP, but today I probably can't find a job in scientific or cryptographic programming because they will be looking for a C sharp developer. Never mind that such a developer has absolutely no clue what Gauss-Seidel decomposition is.
Never mind that I actually have knowledge of the mathematical formulas behind the stochasticity of the various encryption algorithms.
If they want a Delphi programmer they will probably ask me class-room questions without even bothering to test my knowledge concerning the subject matter of what they want me to do.
This creates a vicious cycle. The hired person will struggle because they don't have enough knowledge of the subject matter. The superiors will most likely conclude that it is because his knowledge of the programming tool is not up to standard. Then they will set out to look for someone with "more" knowledge of the programming tool.
No comments:
Post a Comment