The programming secrets today's coders have forgotten

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.


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, PMI Project Managmement Professional, certified Scrum Master and 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 analysers), 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 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 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 and 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, 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."

Find your next job with computerworld UK jobs