It's Monday morning, and you're gathering for your daily stand-up, huddle, all-hands, or whatever you call your top-of-day meeting. Alice asks Bob how his weekend was.
"Pretty good", he replies.
Was Bob's weekend good? "Pretty good" is a catch-all reply that conveys zero information about the quality of his weekend. It forces us to analyze the inflection of his delivery.
"Pretty good..." ...but it could have been better
"Pretty good!" ...maybe something fun or exciting happened?
"Pretty good. How was yours?" ...it was unremarkable or I don't want to talk about it.
We use these stock inflected responses all the time in social situations. "Pretty good" is an easy phrase to reach for when we don't have a better answer, but we may provide subtle clues about our actual meaning by stressing or deemphasizing certain words. We're putting the burden on the asker to extract more information.
It makes for boring conversation and it makes for TERRIBLE developer communication.
Too often when developers have to pass off a project or some amount of information, we assume that the other developer can instantly read our mind. We trust that our colleagues are smart and capable, and therefore must be able to look through our code and understand everything that we've done without need for further explanation.
"Here you go. Let me know if you have any questions"
Just like "Pretty Good", this stock response puts the burden on the receiver to unearth any incomplete information and ask for clarification. That may work for a simple task or one where you already have significant shared context, but in most cases even if the other developer puts in the time to carefully examine your code, that person still has blind spots that they don't even know about.
I see this ALL THE TIME on development teams that have recently grown beyond 1 or 2 devs.
The original developer on the project has the entire thing in her head. When a bug or new feature request comes in, she knows exactly where to go and the three lines of code to touch that will work magic. She's a powerhouse of productivity, because she doesn't have to spend any time articulating how or why she does what she does.
The second developer is hired and picks things up contextually from the first developer. The two of them develop a shared shorthand that allows them to communicate quickly. They have slightly different coding styles, but they get to know each others' idiosyncrasies and can still get by pointing and grunting at various lines of code. This passes for technical communication for a while.
When the third developer arrives, the "Pretty Good" phenomenon starts to be a problem. The first two developers have a shared context and vocabulary that the third lacks. Each developer approaches their work with their own history but lacking clearly articulated context or methods. More rework and wheel-spinning starts to happen and the codebase becomes more fragmented.
The product manager (or whoever is in charge of product requirements) is used to giving vague requirements to the dev team like "Create an Integration for Service X". The founding developer could take that single sentence and run with it. But now you have three developers. This work item comes to the top of the queue and Developer Three takes it. No one has discussed it beforehand. Developer Three has no idea that there is already a half-implemented framework for building out integrations, so he starts his own integration from scratch.
When he's done, he sees a few methods that look like they could be generally applicable to building more integrations, so he abstracts them into their own module. Now you have two different frameworks for building integrations. Best case scenario, this is noticed when one of the other devs reviews his PR prior to merging. Worst case, there's no routine for code reviews and this competing framework is merged into master. Either way, there's going to be some rework involved now or later.
This is when you have to stop focusing on the productivity of individual developers and start focusing on the productivity of the team. The unit that produces working software is the team. It is made of individual developers, but individual developers come and go. You now have to focus on building a culture of articulating information clearly and proactively, in order to ensure that the individual developers are operating as a part of the whole, rather than as rogue appendages.
We'll look at how to start building this culture over the next few posts.