Home > Articles > "Pretty Good"

"Pretty Good"

Want to receive these updates in your inbox? Sign up for my mailing list using the form on the right. (or below if you're reading this on your phone)

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.

Ben Wilhelm

Do you want to introduce an Agile workflow to your team, but you're not sure where to start? I can help.

Sign up for my free 5-day email course detailing a minimal agile setup for small to medium teams.
"What we got from Ben was more than just expertise: it was expertise plus organized thinking, clear communication, good humor, and an obviously habitual willingness to listen before advising. We recommend him without reservation, and look forward to the next time we work with him ourselves."

Work with Me

You want to ship quality software consistently? You want to confidently tell your stakeholders when you'll reach the next development milestone? You want a tight-knit, self-organizing team that takes initiative so you can focus on long-term strategy?

I want these things for you too. I've helped other teams achieve them and I can help you.

For your convenience, I'm offering my best consulting services as low-risk, fix-priced packages. If you don't find a package that meets your needs, drop me a line at [email protected] to discuss a custom engagement.

1-Hour Strategy Call

Sometimes you just need the right advice at the right time. A Strategy Call can be just the ticket.

Find Out More

Individual Coaching

I'll meet with you 1:1 each week to help you build and execute a plan for improving your team's output.

Find Out More

Full Team Consulting

I work directly with your entire team to build routines that deliver results.

Find Out More