Today's coders may know how to whip up a PHP script or a Drupal extension, create a mobile app for both the iPhone and Android, and run DOOM on their car's GPS (which [has been done], it turns out). But there's a lot that their predecessors knew that today's programmers don't.
Some of these skills aren't likely to be needed again, any more than most of us need to know how to ride a horse or (sigh) drive a manual-transmission vehicle. But other skills and "lessons learned" may still or again prove relevant, whether developers are banging their heads against legacy systems, coding for new mobile and embedded devices... or other devices and applications we haven't yet thought of.
Here's what some industry veterans and seasoned coders think the younger generation doesn't know ... but should.
What you don't know about hardware might hurt you
"I see poor understanding of the performance ranges of various components," says [Bernard Hayes], PMP (PMI Project Mgmt Professional), CSM (certified Scrum Master), and CSPO (certified Scrum Product Owner). "For example, rarely is the processor the bottleneck, but so many people look to 'tight loops' to speed up performance when it's often an I/O issue. In a world in which most folks have never intuited systems operations from studying console lights (or more often now, correlating events with signal analyzers), engineers are losing a strong mental model for processor/IO & systems interactions."
Also, says Hayes, "I see people more often having difficulty in thinking through problems caused by buggy hardware, and in general, folks have minimal real understanding of the hardware issues and the implications of the downstream errors that hardware errors can cause. Instead, they tend to feel that 'the driver should deal with that.'"
"When your company builds specialty hardware, you need to be able to learn how each new thing works -- and write some hardware test routines to figure out whether it was built to spec and which bits do what!" says Suford Lewis, a hands-on developer and project leader for 35+ years and past president of the Association for Women in Computing. "Half the fun of my career was moving between technologies and these days when things change so fast, I would think that changing what you are willing to do when a company dissolves from under you would be a downright necessity."
Miles Fidelman, Principal at [Protocol Technologies Group, LLC] and a 36-year veteran of the networking industry, wonders, "Maybe it's a personal gripe, but as far back as 1983, I found serious software engineers who didn't understand hardware. For example, in talking about, say, a simulation algorithm:
Me: How much horsepower do you need? SE: I don't know. Me: Let's see, how many lines of code in your main loop? SE: 10,000. Me: what language? SE: Fortran Me: ok, that's about 10 lines of machine code per line of Fortran, so 100,000 instructions per loop; how many times does the loop execute per second? SE: every 1/20th of a second. Me: OK, so that's 20 x 100,000 = 2mops (which was faster than anything we had at the time), maybe we'd better rethink this.
"I don't think things have gotten any better," says Fidelman.
Programming != software engineering
"Many newer developers have difficulty in depicting and understanding dependencies and diagnosing/debugging them throughout a system," says Bernard Hayes. "Some open source devotees are acquiring this skill as they work on something like mySQL that is complex and deals with many subsystems. And I'm not seeing an intuitive feel for the space/performance tradeoff in implementing algorithms. People have come up in a time of massive memories and high speed systems with respect to most problems, so many coding issues are not as visible.
Chris De Herrera, Founder of [Pocket PC FAQ], says, "It looks like structured software development is going away especially with companies like Facebook and Google that are sponsoring 24-hour coding events where they allow any ideas which may go into their products. I am definitely sure that structured software design including a defined software development lifecycle (SDLC) is critical to reusability and secure design."
Also, says De Herrera, "The use of batch files in Windows is almost gone even though they still can serve a major function. The replacement is Power Shell which does even more. However having batch file experience is an excellent base to build scripting on."
Kris Rudin, Senior Developer and Associate Partner at digital marketing agency [Ascentium] says, "One 'lost skill' that I see all the time with new developers -- how to debug without an integrated debugger. When I started programming (in 1986, just after punch cards, using a mainframe & dumb terminal), we didn't have any IDEs and debuggers, we had to put trace statements in our code to track values and execution.
"Today," says Rudin, there are occasionally times with you can't use the integrated debugger in your IDE (usually with some weird web application frameworks and server configurations), and younger programmers are at a loss as to what to do, and resort to hack-and-slash coding to try to randomly fix a bug, using guesswork. Me, I just calmly put in some code to display output values on the web page, find the bug, and fix it."
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 versus 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."
Parting words
"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?