Anyone who has had a glass of wine with me at the end of a long work day will have listened to me complain about the technical level of the people playing IT professionals.
Yes, "IT Professional" is a broad group of people now with lots of different specialised roles. This happens as a profession grows and as it grows, we start to see the holes in the entry level criteria that are leaving us with inexperienced professionals producing what can only be inexperienced code.
That's fine, right? You throw in a senior engineer to vet what they produce before it hits source control or worst case production. You give them bench or training allowances to go off and take courses, read books and teach themselves.
This is where it falls down. Teaching yourself something is a highly developed skill. Universities do not teach higher grads exactly how to develop a case management system with a specific tech stack with the exact restrictions and requirements as they will need for a specific client. No, they teach concepts and they teach you how to learn on your own and do it fast.
The ability to understand complex software concepts improves with time and experience. So does the ability to pick up a concept and hone it based on reading, watching talks and trying it out. Both of these skills come quickly to good developers. There are many non-degree qualified engineers that I have worked with who are brilliant. The one thing they do better than a lot of others is to pick up a concept and actually learn and understand it.
Going and reading about something and implementing it does not mean that you have done it properly. The eternal error I see in software engineering is that a developer learns how to build one thing and as they change technologies or languages, they build exactly the same thing.
They miss the intricacies, beauty and benefits of the language they are using. They even miss the point completely when they solve different problem domains with the same solution. It won't work. Everything I have built is slightly different than everything else I have ever built. There are shared patterns and solutions but they are unique and require bespoke solutions. I'm not saying they need the wheel invented each time. In fact, I'm the first to argue that unless you are in R&D or seriously cutting edge, then almost everything you need is already done or the pieces exist to allow you to solve the problem quickly.
Recently, I'm seeing developers walk off and read about something and try it out. They then come back and tell me they understand it and have solved all the problems that us senior devs have been thinking through for the last few days. At first, I was super pleased. Yay, they have saved me time and given us a new perspective then I hear the explanation or solution and it's not quite right.
The concept has been explored and the idea implemented. It uses the right terms but in the wrong ways. It sets out the process or structure but only in a superficial way. It is so specific that it can not be generalised because instead of giving a solution, it has gotten to a solution without the understanding of the problem or the solution.
Now, I'm left trying to work out what was missed and I'm coming up with two things that are shining above everything. There is a lack of understanding of the problem being solved and a massive misunderstanding of the underlying pattern or technology being used to solve it.
There is no lack of enthusiasm or effort expressed. It is instead a knowledge gap.
At this point, I have to stop and start at the beginning again explaining what we are doing, what we want to do and how we might go about coming to a way of solving it. I don't want to say they wasted their time but maybe there is education in learning that throwing it away and starting again is also a skill. The big problem is that I can explain it to a person but without the foundation then I can't understand it for them.
There are basic concepts that you should have when you walk in to a software job. Liking tinkering with your PC at home is not enough. You need to understand computer science concepts. We need to have a common language. I have zero issue to helping a juniour understand a concept but I can't be explaining things to them that they should have found out about in first year computer science.
As our industry matures, we must start accepting a certain entry level of competency. Enthusiasm and over-confidence is not going to compensate for not understanding polymorphism or the difference between a has-a or is-a relationship between classes.
I can teach that too you but I shouldn't have to.
No comments:
Post a Comment