The `Planner` and the `Producer`: A tale of coding collaboration.

Prologue: What does your ideal project workflow look like?

How do you prepare to write your first 100 lines of code? What’s the feeling in your gut when you’re refactoring or back-stepping to change key approaches midstream?

When it comes to shaping your code base, we can all muster up examples of established sloppy practice. On the flip side, there’s also no shortage of admirable templates on GitHub that are worth emulating.

This post, however, is not about objectively good or bad practice. It’s about your style when it comes to scoping a project, managing change and uncertainty, and enabling continuous improvement.

Act 1: The Planner.

J.R.R. Tolkien spent over a decade to plan, map and structure his Lord of the Rings Trilogy. The fruits of success for having done so are beyond debate. You might say that once all the blueprinting was accomplished, the novels practically wrote themselves. What emerged was a narrative written off the back of World War I that is still beloved (and bankable!) nearly a century later.

The inherent mathematical nature of code already lends itself to a certain kind of structure. Further, there is a deeper, sought-after level of structure that enables increased efficiency, speed and scalability, which simply cannot be achieved without adequate planning.

This archetype of beautiful code, which is memory-saving, fast to compile, and simultaneously human-readable is what The Planner strives for in every project. Having this person on your team is beyond invaluable, and likewise, not having anyone who thinks like this can be catastrophic.

Act 2: The Producer.

Author Stephen King during interviews has referred to his ritual of the CFD, or the ‘Crummy First Draft’. In the CFD, you write with reckless abandon, test ideas, and spill your story onto a page with no care in the world about how it might look to someone else. You do this, though, with full understanding and intention that once the CFD is complete, the actual difficult work still lies ahead. This approach has led to one of the most productive, accessible and successful writing careers of any currently living author.

With coding, The Producer understands the objective, has a moment of insight, and then codes “in the zone” for three to five hours straight and hands you an output that is miraculously 80% of the way there by mid-afternoon. Of course, we all know the 80-20 rule. To reach full completion—even though the end is now in sight—80% of the team’s effort is still left to go in order to get it there.

The Producer submits his first pull request into the main branch. The Planner takes one wide-eyed look at the state of affairs, begrudgingly reviews the sloppy mess, and sends it straight back to The Producer with several dozen comments and requests for revision (and not without a sufficient level of snark!) before approving and merging.

Act 3: Fairy Tale or Tragedy?

How do we get The Planner to appreciate The Producer’s contribution as something more than careless? How do we ensure The Producer is on board to step out of “the zone” and refactor the code—and even more importantly, ensure that the team has allowed for the time needed to do this—lest we implement some finicky, band-aid solution that almost guarantees we run into larger problems down the track?

We cannot assume that The Producer is inexperienced, and we cannot assume that The Planner is inflexible. Each of these personas represents a completely valid and successful approach to product development. It’s more than possible to have a majority of Producers or a majority of Planners on our team and run a smooth project in either case.

The key is leveraging the strengths of each, mitigating their respective risks, and facilitating meaningful collaboration between individuals whose comfort zones lie on opposite ends of the spectrum.