As part of a continuing series*, O’Reilly requested “pearls of wisdom for programmers” from leading practitioners of the craft, publishing the responses. The end result is the O’Reilly Commons wiki, 97 Things Every Programmer Should Know.
The contributions that appear in the final, published book are freely available as are sixty-eight further contributions that didn’t make it.
This from Don’t Just Learn the Language, Understand its Culture:
Realizing how interwoven foreign words and phrases gave [James Joyce] new ways of expressing himselfÂ is something I’ve kept with me in my programming career.
In their seminal book, The Pragmatic Programmer, Andy Hunt and Dave Thomas encourage us to learn a new programming language every year. I’ve tried to live by their advice and throughout the years I’ve had the experience of programming in many languages. My most important lesson from my polyglot adventures is that it takes more than just learning the syntax to learn a language: You need to understand its culture. â€¨[â€¦]
Once you’ve learned the ropes of a new language, you’ll be surprised how you’ll start using languages you already know in new ways.
Some might argue thatÂ Finnegans Wake is unreadable, while others applaud it for its stylistic beauty. To make the book a less daunting read, single language translations are available. Ironically, the first of these was in French. â€¨Code is in many ways similar. If you write Wakese code with a little Python, some Java, and a hint of Erlang, your projects will be a mess. If you instead explore new languages to expand your mind and get fresh ideas on how you can solve things in different ways, you will find that the code you write in your trusty old language gets more beautiful for every new language you’ve learned.
I guess another could beÂ Don’t Rush?
*Other books in the series (full-content wikis):Â 97 Things Every Software Architect Should Know andÂ 97 Things Every Project Manager Should Know.
I’ve written about design patterns a couple of times in the past, but today I discovered anti-patterns: design patterns that “may be commonly used but [are] ineffective and/or counterproductive in practice”.
One of the “key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea”:
Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results.
The seven types of anti-pattern, with some examples:
- Organisational: Moral hazard,Â insulating a decision-maker from the consequences of his or her decision.
- Project management: Groupthink, whereby members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking.
- Analysis: Bystander apathy, when a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people.
- Software design: Gold plating, continuing to work on a task or project well past the point at which extra effort is adding value.
- Programming: Cargo cult programming, using patterns and methods without understanding why.
- Methodological: Golden hammer, assuming that a favorite solution is universally applicable (See: Silver Bullet).
- Configuration management.
The three virtues of a programmer, according to Larry Wall (in Programming Perl):
- Laziness The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it.
- Impatience The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.
- Hubris Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about.
According to Philipp Lenssen (of Google Blogoscoped), good programmers are not just lazy, but dumb, too.
This also puts me in mind of Jason’s thoughts on simplicity (via Kottke) as his company, 37signals, approaches its 10th anniversary.
I’m reminded of what we’ve always known to be true: simpler is better, clarity is king, complexity is often man-made, and doing the right thing is the right way to do things.
“Open source software development is the ultimate self-service industry”, says Jeff Atwood in an article looking at possible reasons for theÂ OpenOffice.org project’s dwindling development community. However, it’s Atwood’sÂ thoughts on self service supermarket checkouts that I found most interesting:
What fascinates me about self-service checkout devices is that the store is making you do work they would normally pay their employees to do. Think about this for a minute. You’re playing the role of the paying customer and the cashier employee. Under the watchful eyes of security cameras and at least one human monitor, naturally, but still. We continue to check ourselves out. Not only willingly, but enthusiastically. For that one brief moment, we’re working for the supermarket at the lowest possible pay scale: none.
That’s the paradox of self-checkout. But to me it’s no riddle at all: nobody else in that store cares about getting Jeff Atwood checked out nearly as much as Jeff Atwood does.
On the topic of open source development communities, I also found this quote to be quite poignant:
If you’re having difficulty getting software developers to participate in your open source project, I’d say the community isn’t failing your project. Your project is failing the community.
Roger Alsing used a genetic algorithm to create a brilliant approximation of da Vinci’s Mona Lisa using only 50 semi-transparent polygons, evolving over approximately a million generations.
You can see the end result, after 904,314 generations here, but even after roughly 100,000 generations the image is impressive. I loved scrolling through the pictures, slowly seeing the finished article appearing.