I’ve always written a lot
I’ve been writing on my website, on and off, for nearly half my life. When I started, as a teenager freshly dropped out of college into my first job, I tried to write so far-flung friends and family could read it and get the references, and so that if the occasional internet stranger ran across it, they’d get a rough idea. A key learning, early on, was that my best posts included both (1) what happened and (2) how I felt about it. But the benefit I sought was primarily my own: to clarify my thinking, to remember my feelings, to document the significant-seeming rapids of my turbulently flowing life for my friends and my future self. While my writing was publicly available, if other readers were finding it, I was unaware of them; and in any case, I was convinced that people who didn’t already know me could not possibly find anything of value in my words.
I kept writing, sometimes every day for half an hour, sometimes not at all for long stretches. There was a period from late 2008 to early 2013 when this site was offline and I didn’t write. It was a relief to bring it back up (including all the drafts I never published), and a further relief to get them out of a database and into revision control. Feeling safer about my words not being lost has been (as I suspected it might) a contributing factor to my writing more often this year. Another contributing factor has been Erik Dietrich. He’s been writing on his website for a long time too, and a ever-growing audience values his voice. So thrumpteen weeks ago, when Erik offered some simple guidance on how to make my blog more valuable to me by making it more valuable to readers, I listened.
I’ve always read a lot
Of his suggestions, one that sounded most actionable was to publish new posts on a regular schedule. But I didn’t see why that was important. When I run across a post I like well enough that I’m interested to see what its author says next, I subscribe to the site’s RSS feed. My feed reader is rss2email, so whenever I feel like catching up on blogs, I simply switch to my email’s “Feeds” folder and read whatever catches my eye. Given this reading workflow (see also my coding and podcasting workflows) and my being a fast reader, it’s easy to be an opportunistic subscriber. My investment in flow is self-reinforcing, because the wide-ranging ideas and information I gather from my readings further increase the area under the remainder of the curve.
As I heard myself explaining all this to Erik, I realized just how atypical a reader I am. Most people don’t chase the dragon of consuming their entire Twitter feed or subscribing to every blog they’ve ever liked. My reading habits are weird even to most of my RSS-reading fellows, let alone reasonable people who have a more casual relationship to everything they could possibly be reading on the internet. The way I consume, I don’t care about anyone’s publishing cadence, other than to miss them when they haven’t posted for a while.
My experience may not be universally representative
But it doesn’t matter that I don’t care. Lots of readers do. Lots of folks open their browsers and go to a handful of sites to see what’s new. Readers who are not like me — which is to say, nearly all readers! — add a site to their reading rotation if and only if it pays off: if they can expect to keep getting something valuable, and if their expectation keeps being met.
Now I understood Erik’s suggestion as not only actionable, but also sensible. And I loved the idea of returning to a disciplined practice (as I’d had when I started my online journal at 19) about writing. I wasn’t confident that my well of topics wouldn’t quickly run dry, because I’d never been conscientious about filling it. But I’m a pretty opinionated dude, and my line of work regularly stimulates thought, so I figured I could probably figure out how to keep the topics coming. (Lesson learned from software development: if I want to start solving the problem in front of me, I’d better stop trying to solve problems I’m not having yet.)
Try and see
So I acquired myself the habit of writing and publishing one new post every week. This week was a little tricky, so this post was started in a car, mostly finished at a coffeeshop, and published from the guest room at a friend’s house. That’s what it took to put together my 27th weekly post in a row? So be it. In 2014 I wrote a total of 15 and wished for better; in 2015 I’ve already written 33 posts. I still carry around a low-grade, back-of-mind fear that some future week I’ll have nothing to say, but it no longer feels like an imminent threat.
I’ve always found writing to be rewarding, but painful. The process is becoming less painful for me; I’m hopeful that the results are becoming more rewarding for you. In any case, expect me to keep at it.
Plot twist: I’ve actually been writing two new things every week! Give a listen to Agile in 3 Minutes, my micropodcast about thinking and doing business effectively.
When I’m programming, I can usually sense when I’m off track, and have accumulated a bunch of tricks to direct my flow. When I’m podcasting, I envision automating some of the manual steps to make the production process smoother, but it doesn’t feel like flow yet. Every time I make it all the way to the end of my checklist, I feel a sense of relief. Here’s how the sausage gets made each week.
Choose the topic
Before there was a show, to convince myself I had enough to talk about, I made a backlog. Once there was a show, listeners started contributing suggestions for topics and other improvements. (You can too.)
Sometimes I look at the backlog. For instance, a couple nights ago (having shipped 22: Control), I knocked off the top item from the list of possible site enhancements: “Add enough iTunes-specific metadata to get listed in the iTunes podcast directory”. By the time “23: Whatever It’ll Be About” comes out next week, the show will have begun to expand its audience beyond a small set of motivated Agilists who are also podcast-app devotees and RSS fanatics. Being in iTunes will help more people discover Agile in 3 Minutes.
So far, I haven’t looked at the backlog for the purpose of choosing my next topic. I’ve just been choosing whatever topic is already appearing on my mind’s horizon after the previous week’s writing session. I have been peeking to remind myself of the ideas folks have expressed interest in, in case any of them ought to influence the week’s writing.
I don’t believe learning is linear or orderly, but I do believe there exist more and less digestible orderings in which the Agile memeplex can be unfolded. When I choose a topic, I’m intending to improve the chances of a rewarding learning experience for folks who are following along in sequence.
That’s why, thus far, I haven’t talked much about what to go do. I’ve talked mainly about what needs to be true in our heads for Agile to make sense to us, so that it can be of use to us, so that it can help us be effective in our work.
While an episode may follow logically from the previous, and contain brief echoes, it must also stand on its own. One reason: I hope listeners find particular episodes worth sharing, and I hope recipients who aren’t familiar with the show will find those episodes worth their time. Another reason: I hope Agile in 3 Minutes will grow to become a reference, such that for any given topic, listeners can expect to find a 3-minute treatment. So I consider each episode fully responsible for carrying its own meaning because it might be heard in any order (including none) and it might form someone’s first impression.
I begin writing, once the topic is decided, by quickly jotting down all the ideas that come to mind. Word associations, other associations, sentence fragments, previous writings of mine to revisit and try to steal from. Then I follow some of those ideas a sentence or three, maybe a paragraph, not worrying about whether I’ve said the same thing badly or twice. Just keep saying until I run out of steam, then riff-fill on the next thing and the next thing. This loosey-goosey phase stops when I’ve written enough words to constitute an episode. If only they were the right words!
Every episode starts with a question, but I don’t always know the question before I start writing. Every episode has a title; I always start with a working title, and usually don’t need to change it. For the question, I tend to wait to see what I’ve written, because it tells me the hidden question I’ve been asking myself. That’s almost always the one I want to ask you.
How do I get to that point? Write and revise, write and revise, all the while asking myself more questions. Which concepts are holding together nicely? Which ones don’t quite follow in my mind? Which need more help if they’re to follow in yours? How does the whole thing follow from last week? What have I overexplained? Can I explain something better by way of my own experience, possibly my experience making the show? Is there an analogy to be made? Are there enough examples? Might a bit of self-reference kick the whole thing up a notch? Am I having fun writing this? Is there a grin on my face because I’m already looking ahead to reading it?
With rare exceptions, I don’t try to prepare more than one episode per week. It takes my best energy and self-awareness to dig deep for my best ideas in my best words in my best order. If I want the output to keep being any good, I need time to recover between attempts. Exceptions: I wrote the first two so there’d be enough show to announce, and I wrote 11-13 so I could go on vacation (which I then needed!) without impact to the weekly cadence. In the other direction, since the show began, I’ve missed only one week: Episode 5 was delayed by a bout of bronchitis, and you can hear the urgency to get back on schedule in my still-recovering voice.
You can hear me talking a bit about this writing process at 42:24 of Agile for Humans 013. In short, I mash my thoughts and feelings, stir, pour through a fine sieve, and chill for several hours. I’ve just thought of a fun way to make my work visible. Next time I’m ahead of schedule, I’ll try it.
I travel for work every week, so I bring my USB microphone, pop filter, headphones, laptop, and iPad. I set them up in my hotel room, turn off the climate control, unplug the fridge, and wait for outside noise from the street and neighboring rooms to die down. I read the script off the iPad, through the pop filter, into the microphone, into QuickTime Player. If it’s a good read, I plug the fridge back in.
I open Audacity, import the audio, chop leading and trailing space, run the Compressor and Noise Removal filters, and export to AIFF. Using a shell script wrapper around LAME, I compress and tag the MP3, then delete the intermediate audio files.
Using a custom ikiwiki template, I write show notes in a mostly declarative format, usually with at least one link to the C2 wiki and another to Wikipedia. I also define lots of tags, even though the Agile in 3 Minutes website doesn’t make use of them yet, because otherwise at some point when there are lots of episodes and I want to provide a tag cloud for navigation I’ll have to assign lots of tags on lots of episodes. I hate grunt work, so I do a little of it every week. Also grunt work: manually create an HTML container so Twitter can show an inline audio control when anyone posts a link.
git add the MP3, the show notes, and the HTML container.
git push. Ikiwiki puts the episode on the front page and
adds it to the archive and the RSS feed. Easy!
I post the episode to Twitter and other social media. I post it to Twitter several more times over the course of the day, 2-3 hours apart, with a variety of quotes pulled from the episode script.
More automation would help me sustain my pace. If all I had to do each week besides write the script, record the read, and jot some show notes were to push a button to do everything else, that would be really fun — I’m a programmer, I think grunt work being done by code I wrote is fun! — and would let me focus even more on the writing that makes the show what it is. So anytime there’s a little slack in the production schedule, I’ll be looking to automate one more step.
Do you know a cool writing or audio-production trick? Got ideas for the show? Let me know in the comments.
Julio Merino recently described his coding workflow and invited others to describe theirs. My previous workplace development environment looked a whole lot like Julio’s, but my current one necessarily looks pretty different. Having needed to revisit some of the reasons for my preferences, I can more readily distinguish my current nice-to-haves from my can’t-do-withouts.
|Build Radiator||Standalone VM with a custom
|Backlog||Markdown files in Git||Rally|
|Architecture||CLI/GUI client/server||web services|
||IBM Rational Software Architect (Eclipse-derived)|
I had been an
nvi fuddy-duddy until my teammates finally prevailed on
me with their fancy colors and configs. Thanks, guys.
Mere strong preferences
I grew up as a computer user on classic Mac OS and NetBSD. When Mac OS X Server 1.0 came out, all clunky and expensive, I bought it just to have it; when the Mac OS X Public Beta came out, I knew my worlds would usefully merge, and I could look forward to not having two computers on my desk. As a developer, when I don’t have these at hand, I sometimes fumble to compensate:
pkgsrc (”package source”) gives me an easy way to install most any other tools I might need on any Unix variant with any level of system access. I gave a lightning talk about it at CodeMash 2013.
On my own time, I choose a Unix-centered environment whenever possible, to which the two open-source projects I spend the most time with (pkgsrc and ikiwiki) happen to lend themselves very well. I’m sure there’s cause and effect in both directions.
When I’m stuck on Windows, where I don’t feel as comfortable or productive, I usually wind up arranging for a Unix environment, and using it from time to time to keep myself from getting sidetracked too often figuring out how to do some small thing.
When I’m stuck with a weird revision control system, I often use Git in parallel. The administrative overhead of syncing with the source control system of record is more than paid for by the speed and clarity of diffs, which I check quite often as I go along.
When I’m programming, I’m more attuned than usual to bottlenecks in the flow of my work, because I’m more accustomed than usual to having the agency and the means to ease them. I’ve learned that while not having Unix tools is often a bottleneck, it’s not always so, and I can wait until I’m having that problem to do something about it.
In software development, there’s a problem I always have: I make lots of decisions, some of them are bad, and I need to know about those ASAP. So I don’t wait until of-course-I’m-having-that-problem-again to do something about it. Unless the code’s getting thrown away in a few minutes, I always start by arranging for a fast red/green feedback loop.
It doesn’t have to display actual red and green, or use an established testing framework, or finish before I can blink. It does have to start with a keystroke, finish with a clear indicator, and return me to my context. These affordances ensure that I’ll reliably make at least one decision well: whether to run the tests. Because I’m sure I will, it’s worth the marginal effort to add more tests as I go. And because I’m sure those tests are the fastest way to catch my mistakes, it’s worth the marginal effort to start with tests and use them to drive my design decisions.
It’s not about tools
I don’t worry about optimizing test speed until I’m adding tests often and running them often and the run is starting to feel slower. I don’t want to solve it before it’s a problem (it might never be), or after it’s a hard problem (I don’t care for those).
It’s about flow, both kinds — my state of mind and my delivery of outcomes — because they’re tightly linked. If I let problems grow large, they’ll impede my flow later, so I avoid knowingly creating future hard-to-ease bottlenecks. If I let myself be bothered by problems that aren’t yet impeding me, they’ll impede my flow now, so I avoid any further worrying about future bottlenecks.
My coding workflow is continually being optimized for speed and predictability. I look for the present bottleneck, work to ease it, and repeat. Every time I pay for smooth, my investments yield strong returns.
I’m finally coaching! Considering I was hired as a consulting coach in January, started with a client in February, and landed with a team in March, that’s an odd thing to say, isn’t it?
What do I mean by “coaching”?
”Coach” (the role) includes teaching, training, mentoring, and any other kind of situationally called-for behavior, but aims to center on coaching. “Coaching” (the activity) means helping people and teams become more themselves. I recently discussed this topic with Zach Bonaker and Ryan Ripley on Agile for Humans 013, and I’ve got a blurb about how I and others see what I do.
Others use the word differently. For instance, some say “coach” to mean “consultant who will tell us what to do.” I don’t want to do that, and I don’t think it has much to do with coaching. To take another example, I often hear a distinction made between “process coach” and “technical coach,” with which I have at least three beeves:
- I’m not coaching processes or techniques. I’m coaching people.
- As a coach, I’m more effective when I consider the whole system.
- In Agile software development, process and technique are intertwined.
Why did it take so long?
I was brought in as a hands-on technical coach, as a deliberately influential member of the team. I liked the sound of that, especially after so much time off. Let’s get paid! Let’s go to offices and work with people! Let’s see if I can earn trust, influence and be influenced, help a few people who wish for better to get it.
It was a slow start, for a variety of reasons: two weeks to get new-hire oriented at my consultancy, more than that to arrive at clarity about which client team to place me with, much more than that to get me a development-capable machine with a development-ready environment. During those months, when the only way to learn the domain and the codebase was to bother someone who was trying to get their work done, I tried pairing a couple times and decided to stop. (I hate wasting anyone’s time.) Until I could acquire the local knowledge on my own, I looked for other ways to start helping the team, such as:
- Hands-on classroom sessions for an hour every afternoon, alternating between exercises to build new code skills (TDD, refactoring) and legacy code skills (characterization tests, refactoring). After a while, not seeing how to apply what they’d learned to their production codebase, the team lost interest and we stopped the sessions.
- Whole-team programming for a full two-week iteration. It wasn’t textbook mob programming, or even close, but it was a start at learning to work together more effectively. They were nearly as productive as they’d been the previous iteration, plus key knowledge spread to many more brains, plus everyone on the team was animated and engaged in the problem-solving. But under perceived pressure to maximize velocity, the team decided they couldn’t afford to continue working in this way.
One obstacle was the sheer size of the team (at its largest, about a dozen). With a team that size, it’s hard enough to have a direction, let alone try to change it. Another obstacle was the frequency with which members joined or departed, constituting a new team.
How can I tell I’m coaching?
I’ve lost trust by trying to help in ways that haven’t helped, earned some back by finding ways that have been desired. I’ve found ways to offer potential value to the team without asking more than they’re willing to offer. I’ve listened, asked questions, and offered suggestions in conversations with and without keyboards, in groups and one-on-one. I’ve identified feedback loops in need of repair — several of which involve me — and have been repairing them.
In short, I’ve tried a bunch of things that didn’t work, and found a few that are (for the moment) working. I’ve danced insensitively, and learned some signals to be more attentive to. I’ve improvised ineffectively, and learned some new moves to try.
I know I’m coaching because, as the team’s needs have not yet been primarily technical, I haven’t been doing much “technical coaching.”
I know I’m coaching because I’m sometimes aware when I’m failing, when I’m succeeding, and when I’ve learned something.
I know I’m coaching because I’m sometimes aware when people want what I’m offering, and when they want me to be offering more.
I know I’m coaching because I’m not even sure “coach” is a thing anymore. Maybe nothing exists but people, the actions we take, the behavior patterns we choose, the capabilities we grow, and the environments we design. Some of what I do each day could be called coaching, some programming, some teaching, some delivering. My job is to catalyze mutually desired improvement, and I’m finally, perhaps, beginning to.
How do I feel?
This work is exactly what I wanted. I’m finally wrestling with all the challenges I hoped and wished this job would consist of. What’s more, I’m being supported in ways I’d learned not to hope or wish for. As a new coach, I’ve leaned heavily on Pillar folks and other coaches at the client, all of whom have lent their expertise and experience to help me when I’ve asked. I’ve been very lucky to have such easy access to terrific consultants, to know I’ve got the backing of program management, and to bring my whole self — because the work needs me.
I would have regretted not doing this. I also would have regretted doing it badly. But I seem to be getting the hang of it.
It’s everything I wanted, and then some.
I’m pretty sure my claims in How to develop software, How to develop humans, and How to efficiently learn a programming language hold true for people who aren’t me. This how-to is similar, yet different, in that I don’t know enough to suggest anything you should believe or could try. All I know is what I believed, what I tried, and whether it worked. If something about my story helps you, I’d love to hear about it.
Why did I want to try coaching?
I’m not the most gifted programmer or project manager, and I have an academic background in neither. Of necessity, I’ve picked up some tricks that help me deliver results. I’ve built up skill at choosing the work that’s most needed, how to make it most predictable, and how to care for people.
As a perfectionist, procrastinator, and introvert, my at-work effectiveness does not come naturally to me. It has been, and continues to be, acquired through intellection; it is performed, when I manage to perform it, through intellection. The downside is that whenever I don’t have quite enough attention and energy, my effectiveness drops off pretty steeply. The upsides are that my best work is consistently trustworthy and valuable, I habitually observe and adopt techniques to make it more so, and I can almost always understand, verbalize, and demonstrate why I choose how I choose and why I do how I do.
I’m not singularly talented, but I compensate by being wily and by raising my team’s level of play. I’m no Michael Jordan, but maybe I could hope to become a Phil Jackson.
This isn’t the first time I’ve thought these thoughts in this order. I began to piece them together a couple years ago while leading a software team in a difficult environment, during which I felt both pride and pain while delivering exemplary work.
How did I give myself a chance?
A senior manager observed my frustration, suggested I’d do well at coaching software teams that needed to improve (of which there were many), arranged a test of our hypothesis (which went quite well), and set a move in motion. The new role represented for me not only an escape from chronic work-pain, but also a route to being appreciated, for my value could only become more significant and more evident. I had a lot riding on the move. So when a meddling middle manager blocked my transfer out of the department, he soon discovered that his authority stopped short of keeping me there.
Our plan, had it come to fruition, would have served my needs wonderfully. The team I would have joined was already 100% dispersed, and the teams I would have coached were all far from New York. Anticipating no further need for me to live far from Bekki and pay dearly for the privilege, I moved to Indiana. I would have had the chance to learn, under favorable and safe conditions — salary and benefits, an environment I knew well, plentiful obvious improvements to be made — the basics of how to be a coach.
But now it was time for Plan B. Having lowered my burn rate considerably, and having done enough coaching to validate pursuing more coaching, I could afford to wait up to 10 months for the established Agile consultancies to decide I’d help them serve their clients. (If I couldn’t make that happen in time, Plan C was to get another remote programming job, for which I began collecting links to promising remote-friendly employers.) To raise my profile, I sought to involve myself in conferences, conversations, blog posts, Twitter, LinkedIn, you name it.
A few months into my experiment, with several consultancies interviewing me, I warned each of them to see hiring me as a risk — because while I’d done a little coaching, and a lot of being a coach-ish teammate, I’d never been hired to be a coach — but that it’s a smart bet that’ll pay off for them. All of them thanked me for being honest; some of them continued to interview me in depth; and all of them ultimately decided they’d like to talk to me again after someone else had taken that risk.
When did I get that chance?
All of them, that is, except one. A couple months from bottoming out my savings, having just taken a practice interview for Plan C, I heard from Pillar. Like the others, they thanked me for being honest. Unlike the others, they didn’t need someone else to go first. Was I still available? How soon could I start?
How did I feel?
Jackpot! I get a chance to find out whether I can do this.
Crackpot! I have no idea whether I can do this. I haven’t done paying work of any kind in over nine months. I haven’t worked with the client’s primary programming language since 2003.
If I let the self-doubt stop me from accepting the job, worst-case scenario is I’m filled with regret and Plan C takes too long to work. Very not great.
If I accept but the self-doubt proves correct, worst-case scenario is I flame out in a few months and buy Plan C a little time. Somewhat not great.
If I accept and I figure out how to do a good job, jackpot.
How’s it working out for me?
I accepted, of course! Come back next week for the rest of the story.