Never popular, but very useful
"I observe two main areas of neglect among younger programmers but the skills that I am citing were never wildly popular, only very useful," says Suford Lewis.
What I learned vs. what I teach
Jim Peters, a Worcester, Mass.-based programmer and web developer who has been teaching these subjects in a vocational technical high school for several years, offers some observations comparing what he was taught versus what he discovered he should be teaching today: "It's no longer about processing data or writing your program from a blank slate. It's about teaching the novice how to use the interface first, then getting them familiar with they need to add to the generated code. Once you're by that, you can start to teach them how use the programming language to help them get the task done."
For example, says Lewis, "Careful design and thorough specification: the 'think about it first' method. So many times I have seen software from single programs to large systems developed with insufficient attention to what was requested -- and what the requestor actually meant by it! At the single program level, this takes the form of dashing off the code and fixing it at random until it seems to execute okay. Modern tools make this so easy that few software engineers actually spend much effort trying to figure out what the problems are, let alone thinking about it in detail before starting. This is the 'No time to do it right, plenty of time to do it over' method. It always takes longer. It's hard to resist the pressure of those who demand 'Why aren't you coding yet?' but one should.
"The code produced could fail as soon as it hits a case that was not in the test set, and it is unlikely that it will be easy to understand when someone else has to fix or modify it," says Lewis. "Even if your code editor automatically makes it structured, if there are no comments about why something is done a particular way or what a routine is supposed to do or a variable to mean that the next person to wrestle with the code will have a tough time. I used to put in comments to help think out the process. I stopped assuming I would always remember every line I wrote after my first year."
"Whatever happened to drawing flowcharts?" asks Paula Lieberman, a systems engineer who's also been a software test engineer, tech writer and market researcher. "One of the most common failings of software engineers and coders I've seen over my entire career in high tech is a lack of exception handling. Most developers outside of computer security specialists seem rarely to consider, 'What if the user makes a mistake, what if someone is intentionally trying to break or break into the system, what if someone is clueless and doesn't do things the way the developer automatically assumes users do things?'" Also, says Lieberman, "Flowcharts help with the "just what is it that you're trying do?" view. Lists of requirements don't show interdependencies and how things fit together. Flowcharts are a visual systematic approach, in a world where particularization seems to have eclipsed looking at software from a systems perspective."
Working within network and performance constraints
Ben Summers, Technical Director at ONEIS, a U.K-based information management platform provider, points out that "habits learned when writing web applications for 14.4kbps dial-up telephone modems come in rather handy when dealing with modern day mobile connections. When you only had couple of Kbytes per second, and latencies of a few hundred milliseconds, you were very careful to minimize the size of the pages you sent, and just as importantly, minimize the amount of back and forth with the server."
With today's mobile connections, says Summers, "the latency is much worse than using a telephone modem connection, and that's compounded by error rates in congested areas like city centers. The fast 'broadband' headline speeds are pretty irrelevant to web applications. It's the latency which determines how fast the response time will feel, and tricks learned when phone modems ruled the world come in awfully handy. As a bonus, when someone uses your app on a fixed connection, it'll feel as fast as desktop software!"
The sounds of failure
Today's techies have a tin ear for failure. "I'm not seeing an understanding or awareness of the sounds computer systems and electronic equipment tend to make and how that relates to failure risks, like people being able to hear or otherwise sense when the engine oil in a car needs to be changed," says Bernard Hayes. "I can hear and am sensitive to the sounds of arm motion within my hard drive and can tell when it needs to be defragged. About six months ago, I could hear that my four-year-old disk drive on my seven-year-old laptop was about to fail, so I took care to duplicate everything and have copies about. I was thus not at all surprised when the disk failed about two weeks after I become aware of the risk."
"Activities like hearing a noisy voice or copying Morse Code are not in the realm of most RF engineers," says Carl Mikkelsen, whose 45 years of experience covers high voltage vacuum FETs, TTL, broadcast engineering, programming language design, compiler writing, laying the framework for EMACS, image processing, graphics, font rendering, six patents, and real time mechanotronics. "We have such good digital modulation and error corrections that we expect all communications to be clear and error free. Unfortunately, you can't make a digital transmitter with a spark gap and a bit of crystal. Ham radio operators keep this barely alive."
"Assembly language, interrupt handlers, race conditions, cache coherence," says Jude Miller, long-time system consultant and industry curmudgeon.
Other low-level skills that today's engineers aren't getting, according to Carl Mikkelsen: "programming tight loops, computational graphic approximations like a circle algorithm, machining cast iron, designing CPU instruction sets, meeting real-time constraints, programming in the inefficient zone - recovering some of the last 30% of potential, and analog design, such as audio amps."
Pete Kaiser, an independent consultant and 50-year veteran of the industry, doesn't so much see lost individual skills as "overall shrinkage -- many of the 'experts' I hear and see in the trade press seem to have much narrower, shallower perspectives compared to the people I worked with in my days as an active developer of software and hardware in the 1960s, 70s, and 80s. I read about people who know everything about the APIs to Microsoft Windows VSS -- but who have no idea what a log-based file system is. Or who can tell you to buy more RAM for your servers, but have no idea of the design principles behind why a 4GB Linux system may outperform a 16GB Windows system for some purposes. They're ecstatic about Microsoft's Aero interface for Windows, but have no concept of how little GUIs have changed since the 1980s. So they have nothing to contribute to thinking about where to go from here, or whose feet to hold to the fire.
What do you think? Are the coding skills of yesteryear a lost art that should be revived? Or are they actually not very good coding practices in a modern environment?
This story, "Lost Programming Skills" was originally published by ITworld.