The video above was recorded as a keynote at RailsConf 2017. It was also presented at the inaugural DeconstructConf, which means the talk's design benefited richly from my fear of disappointing the masterful Gary Bernhardt.
Programmers are really good at talking about what programs are. Most people will invest a decade just to get a handle on the massive compendium of jargon and metaphors we have created for describing the structure and behavior of finished programs.
But you know what programmers aren't so practiced at articulating? How they program.
Specifically, we don't have very evolved ways to convey clearly the details of the countless actions, feelings, and thoughts that go into writing software. We're simply not used to talking about how we code (short of pointing to a prescribed principle or process that we do our best to imitate). My favorite Computer Science professor liked to say, "be wary; any major that has 'Science' in its name, isn't".
Surely, the fact we struggle to ask and answer "how" questions about programming has tremendous implications affecting how we learn programming, the nature of our work, the colleagues we keep, and even impacts broad industry trends. It seems obvious that we should make an effort to get better at understanding, improving, and sharing our various programming workflows. As a humble beginning, this talk lays out an approach for:
- Identifying your unique disposition as a programmer
- Introspecting how you act, feel, and think in a variety of contexts
- Using that introspection to capitalize on or mitigate those actions, feelings, or thoughts
- Sharing your personally-tailored workflow with others, so they might find aspects that would be useful in their own practice
The Searls-Briggs® Type Indicator™
A conceit of the talk is that I'm filling out a goofy little survey that establishes four buckets of, for want of a better phrase, "programmer personality types". The quiz is a bit of a joke and not scientific at all, but despite this was very popular (things that could also be said of its namesake). If you like, you can take the quiz at testdouble.com/salt and have your result e-mailed to you.
In the first weekend after I performed the talk, the quiz had over 4000 respondents, so clearly there is an untapped demand for this sort of inquiry. Here's a breakdown of your predelictions, in aggregate:
Trait #1 - Fearless vs. Sensitive
As you can see, there's a healthy distribution between the two. In the talk, I identify as sensitive, meaning emotions play a really strong role in my work (both helpfully and not), which leads me to more introspection and empathy, but at the cost of lacking much courage under fire—much less excitement amid volatile circumstances.
I'm a bit envious of the majority of respondents who identified with more fearless markers, especially the 67% who prefer to hear all requirements up-front without worry of feeling overwhelmed.
Trait #2 - Inventive vs. Aesthetic
This bucket is a rough analogue for where folks land on the spectrum between order and chaos. Inventive types are the ones who eagerly try out the latest and greatest languages & frameworks, whereas aesthetic-leaners (like me) tend to roll their eyes at how each subsequent cohort of new programmers insists on reinventing MVC every six months.
In the talk, the aesthetic archetype is summarized as valuing consistency and an idyllic vision of how code ought to be structured, even if those ideals are—to an extent—subject to the fashions of the moment. Inventive types, meanwhile, will gladly trade purist ideals for the opportunity to cover a wide breadth of tools & frameworks if it yields more novel interesting experiences while writing software.
Trait #3 - Naive vs. Leery
Being leery myself, I was not surprised to see the majority of respondents rated "Naive". Both are negatively-connoted words, but don't take offense—this bucket measures bad habits at both extremes.
Naive developers tend to assume things like "software is good", "metrics are useful", and "following the process is valuable". Leery developers are more likely to worry software is becoming more fragile over time, that metrics without context lead to abuse, and that rigid processes can create more waste than not.
Trait #4 - Economical vs. Thorough
This was the most extreme result, and a few Test Double agents suggested that the skew is partly because this talk was presented before a predominantly Rubyist audience. Ruby and Rails, each being well over 10 years old, are at a state of maturity where thoroughness is both typical and important to long-term success. Had we presented this at a Node.js or React conference, where a larger proportion of the audience's lived experience was at an earlier stage of the ecosystem maturity curve, we probably would have seen a different outcome.
What this bucket measures is the extent to which a developer insists on baking in code "quality" (whatever "quality" means) even if it slows them down, as opposed to preferring to get code out the door as quickly as possible by shedding affordances like tests and buy-in from others. As with the other buckets, there's no correct answer. Economical developers are who you want for rapid-prototyping or when the code's primary value is to solicit feedback. Thorough programmers, meanwhile, are well-suited for deftly navigating complex systems that can't afford a "move fast and break things" approach.
If this talk resonated with you, I'd encourage you to spend some time tuning the same sort of feedback loops in your own work. After you've had some time to reflect and tweak your process, share it with others! I'd love to hear about it via email or twitter.
If you're at a point in your journey where you need to find an employer who'll trust you with the level of autonomy needed to take these steps, that's, well, why we created Test Double in the first place! We'd be happy to talk to you about joining our team.
A transcript of the presentation follows: