I read a bit of “jQuery in Action” a couple of weeks back.  Actually all I read was the appendix which is aptly titled “JavaScript that you need to know but might not!”  This short chapter very concisely covers JavaScript concepts which should be required learning for all web developers. 

If you are an experienced JavaScript developer (i.e. your JS code does more than trigger alerts, toggle divs and set window locations), you know the language is not particularly easy to get your head around.  In my opinion, most web developers have a poor understanding of JavaScript to the extent that the bulk of their JS code (mine included) is a mere collection of hacked-together, simple statements.  Based on my judgement, the appendix title should read “JavaScript that you need to know but you more than likely do not!” 

Generously, “jQuery in Action” provides a thorough overview of “basic” JS concepts like objects and JSON, functions being first-class objects, controlling what “this” means along with closures.  I’ve really enjoyed jQuery in Action thus far - particularly because the authors ensure that their readers have a firm understanding of core JavaScript concepts which are arguably the necessary foundation to effectively use jQuery.

The next time you find yourself in your local bookstore, sit down in the aisle with a copy of “jQuery in Action” and give the appendix a good read.  It’s 19 pages of pure Javascript goodness.  And who knows?  You might even purchased the copy and read the jQuery parts…

I am relatively new to the Test Driven Development (TDD) scene.  Though I have read up on the subject (specifically Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela), my only hands-on experience is limited to a single, 3-month project where I was the lone developer.  All other information gathered on the subject has been through blog entries, podcasts, ramblings and the occasional demo in the office.  Though I believe I have a good understanding of TDD methodologies, I am far from putting this, dare I say, knowledge to practice.  Good practice, that is…

A spike is a term associated with TDD.  A spike is nothing more than quick coding exercise which validates or invalidates an assumption.  Lasse Koskela says it more eloquently:

A spike is a short experiment with the purpose of familiarizing ourselves with the technology, tools, algorithms, and so forth, that we need for solving the problem at hand.  A spike is  a way to make an unknown known — at least to a point where we know whether it’s worth continuing to dig that way or whether we should start looking for another way.

If you are familiar with TDD concepts, you know that spikes offer no value with it comes to testability, maintainability, etc.  They are merely quick prototypes which I find immensely helpful but should not be considered the focal point of TDD.  Well, my first crack at TDD resulted in roughly 70% spikes and 30% actual tests.  Not too good.

There is no doubt in my mind that I always had the best intension to test-code-refactor, but I wasn’t yet familiar enough with TDD to know I was way off course. There was also no one around to put me on the right track (or keep me honest.) Putting my ego aside, I know I could have used some hand-holding when I was starting off with TDD.

Test Driven Development is a discipline.  Like many other disciplines, TDD requires a teacher, student and practice.  The teacher offers instruction and ensures the discipline is practiced correctly.  The good student gathers knowledge and implements under watchful guidance.  In my opinion, TDD is therefore a seemingly good fit for a team which embraces an Agile approach, collaboration, rapid development and testability.   I’m not saying the lone developer with no prior experience with TDD is not capable of learning TDD on their own. I know some are.  I know guys who have done it.  Simply, I am stating that TDD seems most accessible to the mentored developer working with team members who previously adopted the methodology.  To put it another way, I bet Test Driven Development concepts are best learned through practical, hands-on example.

I haven’t given up on TDD yet.  Who wants to hold my hand?

If I were to guess, I receive 2.25 bookstore gift cards and 1.25 books around Christmas each year. Nearly 100% of the tangible books have been non-technical in nature.  This year’s book — Beer School: Bottling Success at the Brooklyn Brewery — was a present from my soon-to-be sister-in-law. 

As I don’t tend to read much these days, it is taking a while to get through this particular gift, but I would already recommend it. It is a nice combination of beer history, entrepreneurial stories/advice and business/people stuff as told by the Brooklyn Brewery founders, Steve Hindy and Tom Potter, a journalist and banker, respectively, in a surprisingly light and down to earth manner.  Note: If you want to learn how to brew your own beer, you will need to turn somewhere else as this book probably isn’t for you. 

While sharing life and business lessons learned while building a successful brewery in NYC, Tom dedicates an entire chapter to the creation of the business plan where he goes as far as to write: “To the extent possible, avoid the word conservative.”  His rationale is clear and to the point:

When a business plan says that it ‘conservatively’ estimates this or sales will ‘conservatively’ reach that, most readers get a suspicious twitch.  When using the word conservative, you’re trying to feed the reader a conclusion and shortcut the private analysis.  It doesn’t work.  Readers will come to their own conclusions, wherever you try to lead them.  The reader is thinking: Don’t tell me that’s a ‘conservative’ estimate; just give me the facts, and I’ll tell you.

It is a very interesting view and, based on my experience with project estimation, I may start taking Tom’s advice to heart.  I mean, how many times have you provided a detailed work breakdown structure with accompanying dev hours just to have a project manager or someone with “authority” change your numbers solely based on their interpretation of the required effort?  This type of thing happens a lot — especially when you include a word like conservative along with your estimate.  In my experience stating an estimate is conservative is a green light for someone else to rework your numbers any way they wish. 

I know I am taking the original tip a bit out of context, but I think it still applies.  Though we tend to have opinions on everything, we might be better off just providing the facts while trusting the recipient will do with our numbers as they deem most fit. I, for one, know most of the folks which receive my estimates are intelligent individuals and they can certainly come to their own conclusions and agree or disagree with whatever I might provide. 

So, when I produce my next estimate, I’m going to present my numbers and the supporting facts and I’m going to keep my opinions to myself.  Well, at least until my estimate is challenged and I am stuck doing twice as much development in half as much time and then all Hell is going to break loose.  :)

Last week’s post about The Anti-team by Jemery Miller reminded me of a book I picked up a while back: Herding Cats: A Primer for Programmers Who Lead Programmers by J. Hank Rainwater.  In his book, Rainwater offers tips and management techniques on everything from code reviews to managing a distributed workforce.  With good humor, he discusses dozens to topics which relate to a software manager’s every day. 

Per Amazon’s Editorial Review:

While many titles on software engineering and management lean toward the theoretical, this book’s candid and practical focus help distinguish it from the crowd. It also helps that the author is a good writer and mixes quotes from a variety of sources (including Jack Welch and Andy Grove). This is one of the few titles to concentrate on the all-too-common problem of good programmers promoted to project leads, where management and people skills, rather than raw programming chops, will often determine success.

I recommend this book to software development leaders with a request that special attention is given to the section entitled “Recognizing Programmer Breeds.”  Here, Rainwater “stereotypes” developers for the purpose of understanding and identifying ways to work with them.  He groups the breeds into three categories: major, minor and mongrel.  Majors refers to the most common types you’ll find in the workforce.  The minor breed are sometimes seen, but not as frequently as the major ones.  Mongrels, are not very desirable, but the do exist in the workplace, and as a result you need to recognize them.  Mongrels can work out fine, as long as you help them build up their skills to overcome the weaknesses they inherently bring to the coding process. 

As Rainwater notes,

Any individual can be an amalgam of the characteristics identified with a breed — this makes working with that person a challenge but well worth the effort.  Programmers are a wonderfully complex people.  Relish the differences and unique styles of each breed.  You’ll probably recognize many of these traits the next time you look in the mirror.

Here are the developer personality types which Rainwater dissects in his book:

The Major Breeds
The Architecture
The Constructionist
The Artist
The Engineer
The Scientist
The Speed Demon

The Minor Breeds
The Magician
The Minimalist
The Analogist
The Toy Maker

The Mongrels
The Slob
The Intimidated
The Amateur
The Ignoramus
The Salad Chef

You may recognize a few (without having to pick up a copy of his book.)

Update: You’re in luck.  As Jon Rowett points out, Recognizing Programmer Breeds may be found at Apress.com for free.

What is “Rubber Ducking?” The phrase was made famous by Andrew Hunt and David Thomas in the book The Pragmatic Programmer: From Journeyman to Master.  A book, by the way,  which is required reading for all coders.  In fact, it is time I reread it.  You may already be familiar with this term, but in a nutshell, the idea is that simply explaining a problem aloud often helps one come up with a solution on their own. In the words of the Pragmatic Programmer,

Place a rubber duck on your monitor and describe your problems to it. There’s something magical about stating your problems aloud that makes the solution more clear.

This is an effective approach to problem solving.  I’ve actually had a duck work by my side for years now.  He’s a good, patient, loyal duck.  Of course, you don’t need a rubber duck.  Some people use email.   In the process of meticulously documenting their problem, which will ultimately be shipped to all the smartest people they know looking for help, the solution comes to them.  Some people call a colleague into their office, point at the screen and say, “I’d like to get a second pair of eyes on this.”  The request for review comes along with a detailed overview of the problem which, in turn, begets an answer to one’s own question.  As they say in the book, it’s magical.I stumbled upon an Interview with Hunt and Thomas which tells a bit more about rubber ducking.  It’s a quick read and it’s worth a look.

Reading your source code aloud, or explaining it to someone else, has concrete and documented value, whether in a formal setting of code inspections, peer reviews or just chatting with your cube neighbor, said Thomas. “Have you ever done this? You stare at a piece of code for an hour, debug and debug, and finally, in desperation, you pull your friend in from his cubicle. You start to explain the code and how it works, but then …” (smacking his forehead) “Oh, that’s it!”The audience laughed again, and most of them were nodding ruefully. In fact, Thomas said, you can even resort to “rubber-ducking.” “I don’t know why it works, but it works. You put the rubber duck on top of your monitor. Then, when you’re stuck on something, you start explaining what the code does aloud to the duck.” And before you’ve finished the explanation, the solution comes to you. You smack your forehead, and politely thank the duck, he said to general laughter.

Why do I bring this up?  I am currently on a 6-week leave of absence from work spending time with my wife and new born son.  Prior to leaving the office a few weeks back, I dropped my duck off on a colleague’s desk without any advanced warning that a duck-sitter was needed.  I know the sentiment was appreciated, but I’m not positive the significance was understood.  As I mentioned earlier, you don’t need a rubber duck.  All you need is to willingly share your problems aloud.  I was this person’s rubber duck.  They always came up with the answers on their own, but not before giving me the opportunity to listen.  

I hope my duck is getting an earful right now…

* Update: Previously, I incorrectly credited Hunt and Thomas with coming up with the phrase “Rubber Ducking.”  In fact, it was Greg Pugh who coined the term.  Thanks to Ed Davies and his considerate comment for addressing my oversight.