Pretty bad, Tal M thought to himself on his first day on the new job. Pretty, pretty, pretty bad.
In all reality, the code and development practices at Tal’s company weren’t that bad. At least, not when compared with some of the monstrosities we’ve all see published here. Sure, they had the base class to end all base classes (basically an IObject), plenty of does-it-all-and-then-some classes (a good old ISwissArmyKnife), and a seemingly endless supply of wrappers and wrapper wrappers, but there was nothing that went completely over the top.
Disappointed that he’d be working at yet another company with a dysfunctional codebase, Tal decided to take a stroll and explore the five floors that the programming department utilized. The first stop on his self-guided tour was a place called the “Developer Resource Center”. Situated between conference rooms 402 and 408, it was mostly an alcove of bookshelves filled tomes such as DOS 4.0 Fundamentals and Mosaic for Dummies. But there was one shelf that caught his eye.
Technically, it wasn’t so much the shelf that drew his attention, but the passive-aggressive sign written in red, 58-point Chiller. Do Not Take Any of THESE BOOKS, Tal read the words in his head. Code Complete 2… Pragmatic Programmer… what the—
His internal monologue was cut off by another stream of thought. Is this why the code is so terrible? Is someone trying to hoard all of the best practices knowledge? Or is this some harebrained scheme to monopolize all local copies of good programming books?
Don’t Touch, Explained
After some investigation, Tal learned why the Developer Resource Center was stocked with so many look-but-don’t-touch volumes. Some time ago, a developer who had long since left the company organized the “Developers’ Book Club.” Though the exact details were lost to time, the idea was that like-minded developers would get together at lunch and discuss things like Code Complete 2: Chapter 16: Controlling Loops. It was supposed to be a great way to learn and reinforce good coding practices.
Unfortunately, the book club never made it past buying that initial stock of books. It was hard to say why, but Tal speculated that the initial organizer got so frustrated with the lack of interest that he gave up and never looked back. Or maybe he got hit by a bus. But either way, the books had been carefully guarded by the ominous chiller sign, effectively preventing anyone from accessing the invaluable knowledge contained within.
Developers’ Book Club 2.0
Not only did Tal hate to see such great books go to waste, but he knew that his fellow developers could really learn a thing or two from the material. At his previous job, he had seen great things happen with similar “light training” programs, and he knew the perfect way to get things going again. Through the Lunch & Learn.
Organizing a Lunch & Learn group at the new job seemed like an all-around great idea. It offered a fairly high ROR (Return-On-Résumé) and would show management that he was very serious about improving not only his skills, but those of his colleagues. After finagling a bit to get the lunch portion paid for, Tal sent an email invitation to the 600 on-site developers for the very first Lunch & Learn and patiently waited two weeks for the event.
No one shows up to the first anything, Tal reassured himself before convening the discussion. Nine attendees aren’t too bad, and these things take time to grow.
As Tal went into his spiel about Lunch & Learns and learning in general, he noticed that the attendees were helping themselves to one, then two, and then three, and even four slices of pizza. Not that it mattered, developers get hungry and there was plenty of pizza to go around.
However, as the 15-minute mark neared and they were finishing their meal, two of the attendees got up and excused themselves. Apparently, they both had to be on an “important 12:30 call” and couldn’t miss it. Then another attendee excused himself. And then another. Before the hour discussion was over, all of four people – Tal included – remained.
Given the low attendance and early leavers, Tal figured that his presentation was below par. For the second Lunch & Learn, he knew he’d have to prepare a bit more and build in as much interactivity/discussion as possible.
Pretty good, Tal was pleasantly surprised that twenty-two developers stopped by for the second Lunch & Learn. Pretty, pretty, pretty good.
But before he even started talking, he noticed that a small clique of developers was leaving with a plate-full of pizza in hand. Apparently, they were just stepping out for a minute, but would be right back. During his brief, thirty-second introduction, Tal saw another handful of other developers leave.
When it came time for discussion, no one had even read the cover, let alone a few pages or a chapter. Fortunately, Tal came armed with Power Point slides and was able something that resembled a conversation going. It was a good start but came to an end prematurely as everyone seemed to have a “mandatory 12:30” they couldn’t miss.
The Final Nail
Hoping to nip the freeloading problem in the bud, Tal’s invitation for the third meeting implored attendees not to dine and ditch, and reminded everyone that the value came in discussion and attending for the full hour. He figured that should shame just about everyone from freeloading.
And he was right: none of the known freeloaders were in attendance and there was only one suspected freeloader. Period. Just a single, suspected freeloader. No one else attended the Lunch & Learn. As for why Tal suspected she was freeloading, she wasn’t actually a developer and instead worked as a systems administrator for the DB2 group.
That was the last Lunch & Learn that Tal organized. Since then, he’s come to learn how deep-seeded the noninterest in improvement had become. Not that it matters, though. These days, Tal finds himself grumbling at the bad — but not quite The Daily WTF bad — code. Pretty bad; pretty, pretty, pretty bad.