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.
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:
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
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.