There are a great many computer programmers who are self-taught, and there is nothing wrong with that in and of itself. These folks, typically Millennials who grew up in a world where computers of one type or another were everywhere, have an almost instinctive feel for logic and languages. But a piecemeal approach to learning to program is a dangerous approach if it is not employed in conjunction with a structured methodology. Many major programming errors—ones that result in huge costs to businesses and people—occur because of amateurish programming, programming done by programmers who are intelligent, but not professional. That is, they are bright, hard-working, usually effective, thorough, and dedicated, but far too often have learned their trade haphazardly, without any formal thought or planning.
As an educator, I am frequently shocked at the basic mistakes even experienced programmers make, often because their “training” has consisted almost entirely of grabbing answers off the Web, from sites like Quora, Stack Overflow, and various technical communities. Don’t get me wrong—these are fabulous resources. But they provide opinions and answers to specific questions from individuals, and this is not even remotely the same thing as training.
Flimsy Foundations
In a recent Python Programming course I was supervising, one student, a senior programmer in a large firm, made it clear with his questions that he did not have the slightest understanding of whether and why it was important to know the amount of space a language reserved for floating point numbers. He had never encountered a case where it mattered. Well, of course it matters! He and his employers were fortunate that he had never run across a programming challenge where he could have corrupted a large value or wasted reams of memory by storing 8-bit values in 64-bit spaces, or vice versa.
Many times I have seen programmers mucking about with SQL while knowing nothing at all about RDB design, and then scratching their heads when their “improvements” slowed the system to a crawl. And virtually any experienced software engineer can cite instances where an up-front understanding of underlying software architecture would have cut hardware costs and sped up application performance by several orders of magnitude.
The Cost of Easy Answers: Disasters Caused by Amateurish Programming
This lack of in-depth knowledge is a real problem, with real consequences.
A bit of sloppy programming appears to have caused at least 21 suicides in India last year. It seems that in the Indian educational system, test results have a profound effect on the future of students, since India’s higher education system does not have the capacity to educate all the students who are qualified. A suboptimal score eliminates students from consideration for admittance to many institutions, and students who fail to achieve the necessary scores often feel, right or wrong, that they have no future. In early 2019, approximately 1 million students took compulsory government-sponsored placement tests, and 350,000 failed. The number of failures was far higher than expected, was unlike any previous result, and was, it turns out, wrong. But before the error was identified and publicized, at least 21 students committed suicide. A government committee set up to investigate the situation concluded that errors in the software, coupled with failed attempts to rectify the errors, were to blame.
There are many similar cases. In 1990, more than 50 percent of AT&T’s network crashed, and 75 million calls failed to connect, because of a standard software update that had an undetected bug. We have no idea how many emergency calls went unanswered and how many died as a result.
In 1978, the Hartford Coliseum collapsed due to a glitch in the CAD software used to design the roof. If the roof had fallen just six hours sooner, hundreds or thousands would have died.
There are endless cases where amateurish errors on ecommerce sites—poor user experience (UX) design, sites unable to handle peak traffic, a simple failure to debug, the accidental use of test code in a production environment—have confused or driven away customers and cost sales from hundreds to thousands of dollars.
Pseudo-Training
Clearly, one of the major causes of poor programming is the phenomenon of “pseudo-training.” When enterprises allow untrained or minimally trained “programmers” to develop code, the coders all too often figure out how to solve a particular problem by finding code examples or answers online, at one of the many excellent technical communities that are available free.
But Q&A is not training. Lacking a more robust understanding of the software frameworks employed or the possible side effects of certain coding practices, such programmers create apparent solutions that pass routine QA but fail in the long run. And even if the software works, performance suffers due to poor underlying architectural design.
What’s to Be Done?
A large part of the solution is for enterprises to provide real training that delivers architectural understanding and expert guidance in the application domain. In-depth coverage, comprehensive hands-on labs, and personal facilitation help programmers develop the thorough, practical competence that saves time and boosts the quality of work product. That is why real training focuses on all three of those elements in every course, whether the course is delivered live face-to-face, remote-live, or via facilitated on-demand streaming.
Conclusions
We laugh out loud at the idea of a self-taught medical doctor or self-taught structural engineer or even a self-taught beautician (the chemicals used in coloring hair can be dangerous!). But we allow self-taught or mostly self-taught programmers to create computer code that does everything from keep our money secure to assure that the car stops when we step on the brake. This is not a good idea.
Even the best, brightest programmers in the world need formal training and mentoring from real subject matter experts and trained technical educators. The pseudo-training that is so useful for answering certain questions on the Worldwide Web is no substitute for actual technical training.
Excerpt from white paper “The Problem of Pseudo-Training” by Hands On Technology Transfer, Inc. For sources and a complete version of the white paper, visit: https://www.traininghott.com/White-Papers/Problem-of-Pseudo-Training.htm.