Workflows, by Justin Searls
Abstract
Rails fits how DHH works perfectly. Minitest embodies Ryan Davis's exacting opinions. Katrina Owen's talks show her favorite way to refactor.
Most developers aren't so lucky. We adopt workflows created by others to find a close (but never perfect) fit for our own strengths and weaknesses. We compromise.
No longer! This talk will teach you to design a workflow optimized for your productive flow by showing how I did it for myself. We'll look at how each step in my coding technique was tailored to address my anxieties and leverage my gifts. You'll leave equipped to create your Rails way.
Details
This talk will weave two parallel threads. First, the promise of the abstract: how to experiment with and formalize a personal workflow that optimizes for one's own creativity & productivity. The second thread, to keep the conversation grounded, will demonstrate each step of my own personal workflow as I develop a feature in a Rails application. The concrete requirements and code examples from the second thread will push the narrative in the first thread forward. Ultimately, the talk will close out with both a successfully-completed feature and a clear checklist of how an attendee would go about designing a workflow that's best suited for their personal traits and interests.
Here's something of a high-level outline of the themes from that first thread above; the second thread (of the evolution of a single Rails feature) will exist to keep the conversation moving forward:
- Introduction: what do we mean by "workflow"?
- Illustrate the problem that having a step-by-step processes solves. If you're handed a blank editor window, what prompts you to know what to do next? How much of that is implicit vs. explicit in your mind?
- Examples of well-known tools (e.g. Rails) and approaches (e.g. Sandi's POODR) and how folks align themselves as tribes underneath one or several banners
- Demonstrate pain and friction caused by being told one must follow, say, The Rails Way or practice TDD to be a "good" software developer. (i.e. it sapsvour intrinsic motivation when we have our autonomy robbed from us)
- Feature requests: how we translate them to implementation in our minds, how we (perhaps viscerally) react to them, and how to break ground on new, from-scratch work
- Owning your design: how to balance idiomatic code with personal flair, framework types and custom objects, and conventional vs. custom organization techniques
- Getting unstuck: each of us knows best where we're most likely to hit a dead end, so we can place escape ropes along our path that help us recover quickly from where we're most prone to failing
- Sharing with others: the problem with personal productivity is that it doesn't automatically translate to our colleagues; how to tailor your favorite way of doing things so that it interfaces well with the team & how to normalize on a unified approach among team members to the extent it's useful to do so
- Finishing strong: our work is never done when the code merely works; based on one's personal proclivities & blind spots, we can make sure we prompt ourselves to tie a bow around every feature to set it up for lasting success (think: documentation, testing, automation, marketing the feature to the team, or shepherding it on to production)
To assure you, the reviewer, that I've already put in a lot of the work for this talk, the feature I keep referencing is already implemented and with careful step-by-step commits (I had this talk in mind as I was writing it). You can find the feature (warning: identifying information) here
Pitch
When we discuss "workflow", we often emphasize "work" at the expense of "flow", because the work is what we share in common whereas flow is deeply personal. This is not surprising to see at technical conferences, because they're an opportunity to come together and move the collective craft forward (e.g. by sharing frameworks or popularizing design patterns). Additionally, there's a bias in technology to prefer the objective over the subjective.
However, over the years—perhaps as talks became more polished and prominent developers gained more notoriety—the community has, sadly, sorted itself into leaders and followers. Leaders share what seems to work for them, and there's nothing wrong with that. But the people in the audience are often left to assume that their role is merely to consume the tools, norms, and practices that
leaders produce. The fact that there are a variety of tribes to which one can swear loyalty perhaps placates us by giving us the illusion of control over how we work.
I think as a community, we can do much better to help developers self-actualize by demystifying the process of making a custom tool, identifying a design pattern, or designing a development technique. This talk is a concrete way that I intend to make good on the promises I've made to the community in the past year (warning, identifying information) here and here.
It was only when I realized that I was allowed to create my own workflow—even inside a relatively prescriptive framework like Ruby on Rails—that I became self-actualized as a software developer. My sincere wish is to help other people reach that same milestone in their journey.