Programming Lessons From Linux Geeks in the Trenches

There’s nothing like the school of hard knocks to teach a person a thing or two, and geeks are no exception.

“If you are writing a program that touches more than two persistent data stores, it is too complicated” is one such lesson, for example. “If Linux can do it, you shouldn’t” is another.

Both, in fact, are words of wisdom shared in a recent post entitled “Programming things I wish I knew earlier” by programmer Ted Dziuba.

“I’ve had my ass kicked enough times to step back and think that maybe I should learn how to do things the right way rather than try to bludgeon my way through with raw intellect,” Dziuba explains. “These are the things I wish I had known in the beginning, or at least I wish I hadn’t been too [stubborn] to learn.”

‘Write Meaningful Test Cases’

Dziuba’s hard-won pearls of insight must have struck a strong chord with Linux bloggers, because they were all over the topic in no time, many of them so inspired as to offer up gems of their own.

“Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do,” offered Slashdot blogger Nkwe, for example.

“Write meaningful test cases,” advised kantos, on the other hand. “If your tests only prove the happy path, that’s OK … but if they prove that the happy path is the only path … that is better.”

‘Check Your Ego at the Door’

Of course, “programming is one of those things that humans are not quite smart enough to do,” warned Slashdot blogger Thangodin in a spontaneously offered list of nearly 20 such wise tidbits. “This means you.

“Check your ego at the door,” Thangodin recommended. “In the early ’90s, IBM estimated that 80 percent of large projects in the industry (1 million lines or more) were ‘abandoned in disgust.’ This should give you some idea of what you are up against.”

Linux Girl soon realized she was up against a topic that was begging for more insight. She grabbed her Quick Quotes Quill and headed out into the streets of the blogosphere to learn more.

‘You Realize How Little You Know’

“There are probably three or four things I can describe today that are programming things I wish I knew earlier,” Slashdot blogger yagu told Linux Girl. “Tomorrow there will be three or four more. There isn’t a day that goes by where I don’t learn something new and interesting.”

To wit: “Did you know you can manipulate file descriptors — above and beyond stdin, stdout, and stderr — in sh just like C?” yagu asked. “Learned that recently and it solved or simplified so many longstanding hacks in my queue. Thanks, Cedric!”

Then, too, there are “tools I’d like to have seen earlier,” including vim — “ed was great, vi was way cool, and vim filled in the gaps” — and regular expressions in Java, yagu said. “Who the heck rolls out a language without native regex support?”

Cygwin and wireless drivers for Linux are two other such examples, he added

“All said, it’s fascinating to work in a field where every day the more you know the more you realize how little you know,” yagu concluded.

‘Worse Is Better’

“The biggest thing I wish I knew is, ‘We should forget about small efficiencies, say about 97 percent of the time: premature optimization is the root of all evil,'” Slashdot blogger David Masover offered, quoting computer scientist Donald Knuth.

Masover’s second biggest thing? Richard Gabriel’s “The Rise of ‘Worse Is Better.'”

“Or, in other words: A bad version today is better than a good version someday,” Masover explained.

Of course, “this must be balanced with the idea of paying your technical debt — when you see an opportunity to do something the Right Way and take twice as long, that’s better than doing a sloppy job and ending up taking 10 times as long to maintain it,” he noted. “But it’s far better to do a sloppy job in an afternoon than spend several years never finishing the perfect program.”

Programs vs. No Programs

Before learning such lessons, “I was always frustrated and rarely accomplished much,” Masover admitted. “I would instead rail about the state of languages, frameworks, OSes, and so on.

“Now, while my Ruby scripts aren’t as fast as if I’d done them in C, and my C programs aren’t as elegant as if I’d done them in Ruby, and I haven’t come up with the perfect language that’s the best of both worlds … the fact that I can live with that means that I do actually have C programs, Ruby programs, Java programs, and so on, instead of no programs,” he pointed out.

Dziuba “makes a good argument for not just jumping to new technologies that are supposed to make things easier,” Montreal consultant and Slashdot blogger Gerhard Mack opined. “People are always looking for the magic ‘make my app regardless of my programming ability’ switch, and there just isn’t one.”

‘Ah, the Good Old Days!’

Dziuba’s point about the value of hardware as “one of the best places to put capital to work” resonated with blogger Robert Pogson.

“Some of my earliest jobs consisted of spending 90 percent of my time trying to squeeze microseconds out of the innermost loops of huge number-crunching codes,” Pogson explained. “Those innermost loops can now be done in nanoseconds in the caches of a modern CPU.

“We have caches now that are larger than the main memory in which I used to work,” he added. “Ah, the good old days!”

‘Bloat Extracts an Ongoing Cost’

Slashdot blogger Barbara Hudson, who goes by “Tom” on the site, wasn’t so sure.

“Sometimes the only way to ‘buy your way’ out of a performance problem is to spend the human capital to find the better way,” Hudson countered. “Investment in more efficient code pays an ongoing dividend in terms of quicker execution, higher end-user satisfaction and less resources, whereas bloat extracts an ongoing cost all the way down the pipeline.

“There’s plenty of code out there that can be vastly improved, and the resulting energy and other savings are going to have to become part of the calculus in the ‘green computing’ equation,” she added.

‘Technological Solutions Never Are’

Hudson was another geek who was inspired to offer a list of her own:

• 10. “Perl causes brain damage.”
• 9. “Like me, you didn’t notice Perl causes brain damage because, well, it causes brain damage.”
• 8. “Switching to Python doesn’t fix No. 9, no matter how much you or I wish it did. It might stop further damage, but if it doesn’t, don’t worry — you won’t be in any shape to notice anyway.”
• 7. “There will always be some company angling to be today’s Dr. Evil. It changes over time, so be prepared for disappointments. And to forgive past disappointments. It’s not ‘being fickle’ — it’s being kind, and life is too short.”
• 6. “Technological solutions never are. Everything is just a stopgap.”
• 5. “The real problem is always a people problem (see No. 6).”
• 4. “People will do anything to avoid admitting No. 5.”
• 3. “You are doomed (see No. 4) no matter what you do. Life is unfair. It’s not you — it’s just the way things are.”
• 2.”You will make tow speeling mistakes the one time you don’t hit ‘Preview’ — and your spell-checker won’t flag ‘tow’ (see No. 6).”
• 1. “Trolls have more fun. The biggest trolls — industry analysts — have the most fun. Their stuff doesn’t have to compile. It doesn’t even have to make sense.”
• 0. “The dumber the idea, the more chance you have to sell it if you explain it with 100 PowerPoint slides.”