The really good stuff is hidden in the articles

My team always—at least initially—thinks my instructions or suggestions for process improvement are a little hard to follow. This is likely because I am never afraid to say...

"My last idea could have been better. Let's try this instead."

Teams hate change!

Anyway, this is a real example of hard to follow instructions...

"I said 'Never name your classes after the pattern itself.' 

But then someone pointed out 'What about Factory classes?' 

'Oh, ok, ALWAYS name classes after the pattern.' Except for Singleton or Façade, and maybe a few others. 

Ok then, NEVER name after the pattern, except when you do, sometimes, and then ALWAYS name those, unless otherwise noted."

Actually, it is a good example of what can happen if you take something out of context.

Always read any article fully—especially those from sarcastic folk like me. Otherwise, some tongue and cheek beginning may completely skew your understanding of the author's true perspective.

For several years, I worked in the newspaper industry. In journalism class, they taught us to summarize the important parts in the first few paragraphs, because busy people seldom read a full article. Likewise, they taught us to put the important stories in the front of the publication, because really busy readers never make it to the back.

To many newspaper editors today, that translates to...

"If the news item could potentially offend an advertiser or a politician that our publisher likes, bury it deep in the story—or bury the story deep in the paper."

The rambling I quoted about patterns actually makes good sense in context, and is from Elegant Code—one of my favorite coding blogs. Check it out when you have a moment.

And learn the lesson of always reading full articles before forming an opinion.