pages tagged workflowYareev's schmonz.comhttps://schmonz.com/tag/workflow/Yareev's schmonz.comikiwiki2019-03-12T00:17:15ZTraining: Personal Kanbanhttps://schmonz.com/2019/03/11/training-personal-kanban/Amitai Schleier2019-03-12T00:17:15Z2019-03-11T16:47:24Z
<h2>Habits can change</h2>
<p>I have a habit I like very much: incorporating some professional training every year.
Last year my needs led me to go on a
<a href="https://schmonz.com/2018/09/15/coding-tour-summer-2018-conclusion/">coding tour</a>.</p>
<p>I also have habits I don’t like very much, particularly about how I allocate my time.
So when I heard
<a href="http://personalkanban.com/pk/">Personal Kanban</a>
training was coming to New York, I needed to allocate only a small amount of time to deliberate.
<a href="https://twitter.com/ItsUnderstood/status/1096513337506975744">Sue Johnston helped</a>,
too.</p>
<p>20 minutes in, I could tell my learning would be in good hands with
<a href="https://twitter.com/Sprezzatura">Tonianne DeMaria</a>
and
<a href="https://twitter.com/ourfounder">Jim Benson</a>.
The ideas I was hearing were ones I knew and cared for, and they were being used in the service of people being whole people.</p>
<h2>Emotions contain information</h2>
<p>One such idea: a leading indicator for software quality problems is the emotional state of the developers.
(For me, this connects directly to
<a href="https://twitter.com/GeePawHill">Michael D. “GeePaw” Hill</a>’s
formulation of
<a href="http://geepawhill.org/my-agility-1/">made-making-maker</a>.)
If we’re uncomfortable with what we just delivered, that’s a signal.
If we ignore our emotions and the information they contain, we’re likely to experience them again, more painfully.
Or — check this out, fellow humans! — we could help each other observe and value our emotional signals.</p>
<p>Another such idea: in Lean manufacturing, where work is standard, variation is desirable to reduce.
In Lean software development, where work is knowledge, variation is desirable to <em>understand</em>.
Can we learn to expect where it comes from?
If so, our planning will improve.
(Can we differentiate “accidental” and “essential” variation?
If so, we can drive down the former and our planning will further improve.)</p>
<h2>Lean in code and class</h2>
<p>What does the application of Lean principles to software development look like?
Perhaps the best known example thus far is
<a href="https://agilein3minut.es/32">Mob Programming</a>:
when the whole team works on the same problem on the same computer, we get single-piece flow, a WIP limit of 1, just enough decisions made just in time, shared context, and easy predictability.
I had enough to say about mobbing, it seems, to be called “the Mob Programming guy” in our class.
In response to
<a href="https://en.wikipedia.org/wiki/Pomodoro%20Technique">Pomodoro Technique</a>,
I also offered what I might call “Inverse Pomodoro”: when you <em>are</em> being pulled away, write down your next thought before you lose it. Then it’s waiting for you when you come back.
When my work is programming, I do it
<a href="https://schmonz.com/2015/08/19/life-hacks-for-the-test-infected/">like this</a>.</p>
<p>What does the application of Lean principles to teaching look like?
A couple
<a href="http://www.bigapplescrumday.org/">Big Apple Scrum Day</a>s
ago,
<a href="https://twitter.com/ryanripley">Ryan Ripley</a>
and I did an entirely audience-driven talk where folks told us what they were wondering about and
<a href="https://schmonz.com/2017/05/01/basd-2017-t-shaped-people/">that’s what we talked about</a>.
Jim and Tonianne did this for two whole days, relating each idea back to previous ones, often via previous visuals.
As a result, I found myself relating familiar ideas in new ways.
If I hadn’t encountered most of them previously, I might well have been overwhelmed.
It was plenty to take in as it was.</p>
<h2>Insights</h2>
<p>Hearing about Jim and Toni’s working relationship, I realized: I’d pay someone to irregularly but periodically wipe my kanban board (and absorb my reaction).
I tend to habituate quickly to my board and forget I have agency to rethink everything about how it works.
When it’s been cleared, I’ve been reminded.
After several emptyings, I might even find myself less attached to my backlog.
Might be nice.</p>
<p>Hearing about Personal Kanban in the service of whole people, with health explicitly non-negotiable, I was reminded of a hypothesis:
<a href="https://schmonz.com/2017/01/05/new-years-slack/">a balanced life is a small-batch-size life</a>.
Mine hasn’t been so balanced lately.
Returning to visualizing my work — everything I need to do to have the life I want — will help.
I’m eager to get to my office, lay out a dozen stickies with fresh design considerations, and build myself a fresh board.</p>
<hr />
<h2>Previous trainings</h2>
<ul>
<li>2018: Schleier, <em><a href="https://schmonz.com/2018/09/15/coding-tour-summer-2018-conclusion/">Coding Tour</a></em></li>
<li>2017: Larsen, <em><a href="https://schmonz.com/2017/12/29/training-agile-fluency-game/">Leading Agile Adoptions with the Agile Fluency Game</a></em></li>
<li>2016: Grenning, <em><a href="https://schmonz.com/2016/06/18/training-tdd-for-embedded-c/">Test-Driven Development for Embedded C</a></em></li>
<li>2015: Weinberg and Derby, <em><a href="https://schmonz.com/2015/06/17/problem-solving-leadership/">Problem Solving Leadership</a></em></li>
<li>2014: Cockburn, <em><a href="https://schmonz.com/2014/11/05/assumption-carpaccio/">Coaching in an Agile Context</a></em></li>
</ul>
New Year's Slackhttps://schmonz.com/2017/01/05/new-years-slack/Amitai Schleier2017-01-07T15:51:47Z2017-01-05T17:42:06Z
<p>Last night, mere moments from letting me
<a href="http://mail-index.netbsd.org/pkgsrc-changes/2017/01/05/msg151138.html">commit a new package</a>
of <a href="http://search.cpan.org/dist/Test-Continuous/">Test::Continuous</a>
(<a href="http://c2.com/cgi/wiki?ContinousTesting">continuous testing</a>
for Perl), my computer acted as though it knew its replacement was on
the way and didn’t care to meet it.
This tiny
<a href="https://support.apple.com/kb/SP677">mid-2013 11” MacBook Air</a>
made it relatively ergonomic to work from planes, buses, and
<a href="https://schmonz.com/2013/10/17/working-from-everywhere/">anywhere else</a>
when I lived in New York and flew regularly to see someone important in
Indiana, and continued to serve me well
<a href="https://schmonz.com/2014/02/10/my-thirty-fifth-solar-orbit/">when that changed</a>
and
<a href="https://schmonz.com/2015/01/09/two-engagements/">changed again</a>.</p>
<p>The next thing I was planning to do with it was write this post.
Instead I rebooted into
<a href="https://www.amazon.com/Disk-Warrior-Mac-select-Version/dp/B00RYGM48E/ref=as_li_ss_tl?ie=UTF8&qid=1483639092&sr=8-1&keywords=diskwarrior&linkCode=ll1&tag=schmonz-20&linkId=9c3d1c544398a645823f8d104de2341e">DiskWarrior</a>
and crossed my fingers.</p>
<p>Things get in your way, or threaten to. That’s life. But when you have
<a href="https://www.amazon.com/Slack-Getting-Burnout-Busywork-Efficiency-ebook/dp/B004SOVC2Y/ref=as_li_ss_tl?_encoding=UTF8&qid=1483639181&sr=8-1&linkCode=ll1&tag=schmonz-20&linkId=d8b7d849eee0620cd34dcaa6ae3abc5d">slack time</a>,
you can</p>
<ol>
<li>Cope better when stuff happens,</li>
<li>Invest in reducing obstacles, and</li>
<li>Feel more prepared for the next time stuff happens.</li>
</ol>
<p>Having enough slack is as virtuous a cycle as insufficient slack is a vicious one.</p>
<h2>Paying down non-tech debts…</h2>
<p>Last year I decided to spend more
<a href="https://schmonz.com/2016/03/03/why-i-went-to-fat-camp/">time and energy improving my health</a>.
Having recently spent a few weeks deliberately not paying attention to
any of that, I’m quite sure that I prefer paying attention to it, and am
once again doing so.</p>
<p>Learning to make my health a priority required that I make other things
non-priorities, notably
<a href="https://agilein3minut.es/">Agile in 3 Minutes</a>.
It no longer requires that.
I’ve recently invested in making the site easier for me to publish, and
you may notice that it’s easier for you to browse.
I didn’t have enough slack to do these things when I was
<a href="https://schmonz.com/2015/09/23/my-podcasting-workflow/">writing and recording a new episode every week</a>.
Now that enough of them have been taken care of, I feel prepared to take
new steps with the podcast.</p>
<h2>…And <a href="http://c2.com/cgi/wiki?TechnicalDebt">tech debts</a></h2>
<p>Earlier this week I noticed a broken link in a comment on
<a href="https://schmonz.com/2016/09/11/refactorings-for-web-hosting/">Refactorings for web hosting</a>,
so I took a moment to check for other broken links on this site (ikiwiki
<a href="http://ikiwiki.info/ikiwiki/directive/brokenlinks/">makes it easy</a>).</p>
<p>Before that, I inspected and minimized the differences between “dev” (my
laptop) and “prod” (my server, where you’re reading this), updated prod
with the latest ikiwiki settings, and (because it’s all in Git)
<a href="https://git-scm.com/book/en/v2/Git-Branching-Rebasing">rebased</a>
dev from prod.
In so doing, I observed that more config differences could be easily
harmonized by adjusting some server paths to match those on my laptop.
(When Apple introduced
<a href="https://en.wikipedia.org/wiki/System%20Integrity%20Protection">System Integrity Protection</a>,
<a href="http://pkgsrc.org">pkgsrc</a>
on Mac OS X could no longer install under <code>/usr</code>, and moved to <code>/opt</code>.
With my
<a href="https://schmonz.com/2016/11/23/automation-for-web-hosting/">automated NetBSD package build</a>,
I can easily build the next batch for <code>/opt/pkg</code> as well, retaining
<code>/usr/pkg</code> as a symlink for a while.
So I have.)</p>
<p>I’ve been running lots of these builds in the past week anyway, because
a family of packages I maintain in pkgsrc had been outdated for quite a
while and I finally got around to catching them up to upstream.
Once they built on OS X, I committed the updates to the
<a href="https://schmonz.com/2013/01/22/codemash-2013-your-dev-toolbox-everywhere/">cross-platform package system</a>,
only to notice that at least one of them didn’t build on NetBSD.
So I fixed it, ran another build, saw what else I broke, and repeated
until green.</p>
<h3>…And taking on patience debt telling you about more of this crud</h3>
<p>Due to another update that temporarily broke the build of
<a href="https://en.wikipedia.org/wiki/TMDA">TMDA</a>,
I was freshly reminded that that’s a relatively biggish liability in my
server setup.
I <a href="https://schmonz.com/2007/01/14/qmail-smtp-auth-ssl-tls-patches/">use TMDA to send mail</a>,
which is not mainly what it’s for, and I never got around to using it
for what it’s for (protecting against spam with automated
challenge-response), and it hasn’t been maintained for years, and is
stuck needing an old version of Python.</p>
<p>On the plus side, running a weekly build means that when TMDA breaks
more permanently, I’ll notice pretty quickly. On the minus side, when
that happens, I’ll feel pressure to fix or replace it so I can (1)
continue to send email like a normal person and (2) restart the weekly
build like a me-person. If I can reduce the liability now, maybe I can
avoid feeling that pressure later.</p>
<p>Investigating alternatives, I remembered that
<a href="http://www.spamdyke.org">Spamdyke</a>,
which I already use for
<a href="https://en.wikipedia.org/wiki/Anti%2Dspam%20techniques">delaying the SMTP greeting</a>,
blacklisting from a
<a href="https://en.wikipedia.org/wiki/DNSBL">DNSBL</a>
as well as <code>To:</code> addresses that only get spam anymore, and
<a href="https://en.wikipedia.org/wiki/greylisting">greylisting</a> from unknown senders,
can provide
<a href="https://en.wikipedia.org/wiki/SMTP%20AUTH">SMTP AUTH</a>.
So I’ll try keeping
<a href="https://en.wikipedia.org/wiki/stunnel">stunnel</a>
and replacing <code>tmda-ofmipd</code> with a second instance of <code>spamdyke</code>.
If that’s good, I’ll remove <code>mail/tmda</code> from
<a href="https://github.com/schmonz/dotfiles/blob/master/pkgcomp-autopackages">the list of packages I build every week</a>,
then build <code>spamdyke</code> with OpenSSL support and try letting it handle the
TLS encryption directly.
If that’s good, I’ll remove <code>security/stunnel</code> from the list of packages
too, leaving me at the mercy of fewer pieces of software breaking.</p>
<p>Leaning more heavily on Spamdyke isn’t a clear net reduction of risk.
When a bad bug is found, it’ll impact several aspects of my mail service.
And if and when NetBSD moves from GCC to Clang, I’ll have to add
<code>lang/gcc</code> to my list of packages and instruct pkgsrc to use it when
building Spamdyke, or else come up with a patch to remove Spamdyke’s use
of anonymous inner functions in C.
(That could be fun. I recently
<a href="https://schmonz.com/2016/07/08/how-to-learn-c-part-1/">started learning C</a>.)</p>
<p>I could go on, but I’m a nice person who cares about you.</p>
<h3>That’s enough of that. So what?</h3>
<p>All these builds pushing my soon-to-be-replaced laptop through its
final paces as a development machine might have had something to do
with triggering its misbehavior last night.
And all this work seems like, well, a lot of work.
Is there some way I could
<a href="http://agilemanifesto.org/principles.html">do less of it</a>?</p>
<p>Yes, of course.
But given my interests and goals, it might not be a clear net improvement.
For instance, when
<a href="http://agileotter.blogspot.com">Tim Ottinger</a>
drew my attention to that <code>Test::Continuous</code> Perl module, being a pkgsrc
developer gave me an easy way to uninstall it if I wound up not liking
it, which meant it was easy to try, which meant I tried it.
I want
<a href="https://schmonz.com/2015/07/29/enthusiasm-engineering/">conditions in my life to favor trying things</a>.
So I’m invested in preserving and extending those conditions.
In
<a href="https://www.destroyallsoftware.com">Gary Bernhardt</a>’s
formulation, I’m aiming to maximize the
<a href="https://schmonz.com/2013/06/10/area-under-the-curve/">area under the curve</a>.</p>
<h2>No new resolutions, yes new resolvings</h2>
<p>I’m not looking to add new goals for myself for 2017.
I’m not even trying to make existing things “good enough” — there are
too many things, and as a
<a href="https://schmonz.com/2015/08/12/tdd-saved-my-brain/">recovering perfectionist</a>
I have trouble setting a reasonable bar — I’m just trying to make them
“good enough enough” that I can expect
<a href="https://schmonz.com/2015/11/04/incremental-effort-incremental-payoff/">small slices of time and attention to permit small improvements</a>.</p>
<p><a href="http://jessitron.com">Jessica Kerr</a>
has a thoughtful side blog named
<a href="http://tistil.tumblr.com">True in software, true in life</a>.
Here’s something that’d qualify:</p>
<ol>
<li>When conditions are expected to change, smaller batch size helps us adjust.</li>
<li>Reducing batch size takes time and effort.</li>
</ol>
<p>Paying down my self-debts (technical and otherwise) feels like
<em>resolving</em>.
I have, at times, felt quite out of position at managing myself.
Lately I’m feeling much more in position, and much more like I can
expect to continue to make small improvements to my positioning.</p>
<blockquote><p>When you want the option to change your body’s direction, you take
smaller steps, lower your center, concentrate on balance. That’s
#Agile.<br />
—<a href="https://twitter.com/schmonz/status/805228859507544064">Moi</a></p></blockquote>
<p>My current best understanding is that a balanced life is a
small-batch-size life.
If that’s the case, I’m getting there.</p>
<h2>Further repositioning</h2>
<p>This coming Monday, I’ll be switching to one of these
<a href="https://support.apple.com/kb/SP748">weird new MacBook Pros</a>
with the row of non-clicky touchscreen “keys”.
If my current computer survives till then, that’ll be one smooth step in
a series of transitions.
(In other news, Bekki defends her dissertation that day.)</p>
<p>The following Monday, I’ll be starting my next project, a mostly-remote
gig pairing in Python to deliver software for a client while encouraging
and supporting growth in my Pillar teammates.
I’ll be in Des Moines every so often; if you’re there and/or have
recommendations for me, I’d love to hear from you.</p>
<p>The Monday after that, we’ll pack up a few things the movers haven’t
already taken away, and our time in Indiana will come to an end.
We’re headed back to the New York area to live near family and friends.</p>
<h2>No resolutions, yes intentions</h2>
<p>For 2017, I declare my intentions to:</p>
<ol>
<li>Continue to improve my health and otherwise attend to my own needs</li>
<li>Help more people
<a href="https://schmonz.com/2016/10/16/agile-coach-camp/">understand what software development work is like</a></li>
<li>Help more people feel heard</li>
</ol>
<p>I hope to see and hear you along the way.</p>
My speaking workflowhttps://schmonz.com/2016/05/25/my-speaking-workflow/Amitai Schlair2017-02-07T23:05:49Z2016-05-25T14:46:43Z
<h2>Previously</h2>
<ul>
<li><a href="https://schmonz.com/2015/09/16/my-coding-workflow/">My coding workflow</a></li>
<li><a href="https://schmonz.com/2015/09/23/my-podcasting-workflow/">My podcasting workflow</a></li>
<li><a href="https://schmonz.com/2015/10/14/my-writing-workflow/">My writing workflow</a></li>
</ul>
<h2>What I’ve been up to</h2>
<p>I’ve done very little writing lately. If it weren’t for my
<a href="https://schmonz.com/tag/not-talk/">guest appearances on other shows</a>,
I’d be doing zero podcasting. I’ve been traveling frequently for work and a
<a href="https://schmonz.com/2016/04/06/work-not-done/">whole bunch of conferences while effortfully maintaining new food and exercise habits</a>.
That’s all I’ve had time for.</p>
<p>After this week’s <a href="https://schmonz.com/talk/2016-path-to-agility/">Path to Agility conference</a>,
I’ll be traveling less and working from home more.
I expect to be writing regularly again, starting now.
Since I’ve been <a href="https://schmonz.com/speaker/">speaking regularly</a>,
I’ve been incrementally improving how I present and publish.
And since I’m about to take a break from conferences, here’s what I’ve
figured out so far.</p>
<h2>Notice CFPs of interest</h2>
<p>”CFP” == Call For Proposals. Or sometimes Papers, but I haven’t written
any of those, and am intimidated by the title.</p>
<p>I mainly become aware of conferences when
<a href="https://schmonz.com/2015/08/05/confessions-of-a-twitter-completionist/">someone I follow on Twitter mentions them</a>,
or sometimes when
<a href="https://schmonz.com/2015/06/24/agile-roots-2015-shoestring-agility-in-a-velcro-organization/">someone I meet in person recommends them</a>.
Last year I assembled a list of “2015 conferences I may want to attend”.
I found it so useful that I
<a href="https://gist.github.com/schmonz/8fe378c219e56f2250e1">did it again this year</a>.
Suggestions and corrections welcome!</p>
<p>Recently I became aware of the
<a href="http://www.techspeak.email/">Technically Speaking</a>
and
<a href="http://theweeklycfp.com">The Weekly CFP</a>
newsletters (probably via Twitter) and subscribed.</p>
<p>It’s also possible to bypass the usual talk submission process by
receiving a personal invitation to speak. I’ve been invited a few times.
When this happens, it’s very flattering, and it drives home the
continued need for me to participate in the usual process. I’ve had lots
of talks rejected. If I hadn’t kept at it, gotten some acceptances, and
made the most of them, the folks who’ve invited me to speak to their
audiences wouldn’t have known I had anything to offer.</p>
<p>Moral of the story: keep submitting, keep presenting, keep practicing.</p>
<h2>Write an abstract</h2>
<p>I have not, by any stretch, mastered the art of writing a winning
abstract. I do know what I like as an attendee. What draws me in? Among
other things, I look for a story from personal experience. That helps me
understand how being there might change my own story.</p>
<p>We discussed this on <a href="https://schmonz.com/talk/20160420-agile-for-humans/">Agile for Humans 032</a>.</p>
<h2>Save a copy</h2>
<p>If an abstract is accepted, I might want to submit it to more
conferences. If an abstract is rejected, I might want to tweak it and
submit it to more conferences. Either way, I don’t want to rely on
being able to pull a copy out of a submission system. I do my writing
in my personal wiki (an <a href="https://schmonz.com/tag/ikiwiki/">ikiwiki</a> instance, naturally), then
submit a copy.</p>
<h2>Rejected? Try again from the top</h2>
<p>Program committees and organizers don’t usually have time and energy to
give personalized feedback. If my talk was rejected, it’s up to me to
figure out what that might mean and what I might want to do about it. I
might try to find someone who gives talks and get their personalized
feedback. Or maybe it was one of the many perfectly good talks that get
rejected all the time, and submitting verbatim to another conference is
worth a shot.</p>
<h2>Accepted? Publicize</h2>
<p>I write a very short page linking to the conference, my session, and
where to buy tickets (if they’re still available), and I tag the page
<a href="https://schmonz.com/tag/talk-pending/">talk-pending</a>. That automatically adds it to the list of upcoming
appearances on my <a href="https://schmonz.com/speaker/">speaker page</a>, and also (via
<a href="https://schmonz.com/2013/06/10/area-under-the-curve/">rss2email</a>)
turns it into an email message, which gets sent to
<a href="https://schmonz.com/2016/02/22/my-new-mailing-list/">my low-volume mailing list</a>.</p>
<p>Sooner or later I’ll mention the talk on Twitter, etc., as well.</p>
<h2>[Talk planning goes here]</h2>
<p>I have no profound thoughts about how to put together a winning talk.
Have experiences, figure out what’s interesting about them, extract the
story arc.</p>
<h2>Write slides</h2>
<p>I’m not, as yet, attempting to design
<a href="https://vimeo.com/145917204">fast-paced, visually arresting slides</a>.
I’ve been trying to keep it simple for myself instead.
After several iterations, I’ve landed on a comfortable setup for writing
and publishing decent web-based slides.</p>
<p>I used to use <a href="http://meyerweb.com/eric/tools/s5/">S5</a>.
No special tools: write HTML, get slides. I was happy with it. Here’s a deck from
<a href="https://schmonz.com/2013/01/22/codemash-2013-your-dev-toolbox-everywhere/slides/">a lightning talk a few years ago</a>.</p>
<p>Last year, after <a href="https://schmonz.com/2015/01/01/happy-new-year/">migrating this site to ikiwiki</a>,
I was finally able to write new posts in Markdown.
I wanted to be able to write slides in Markdown too.
<a href="http://remarkjs.com">Remark.js</a> does that.
The easiest way to get started was to use it exactly as directed, then let
<a href="http://ikiwiki.info/plugins/rawhtml/">ikiwiki’s rawhtml plugin</a>
preserve it for publishing.</p>
<p>The third time I published Remark.js slides, I noticed it was my third
local copy of an old version of Remark.js. So I put it in a central
place, adjusted the three references, and upgraded to the latest version
— with git commits at each step, just in case I broke something. (I
<a href="https://schmonz.com/2015/04/29/signal-and-static/">love having my site in git</a>.)</p>
<p>This reduced duplication would certainly simplify my next slide-writing
experience. To simplify it further, I wanted to extract the shared HTML
and CSS. So I wrote a
<a href="http://ikiwiki.info/plugins/contrib/remark/">plugin for ikiwiki</a>
that provides the standard Remark.js template and styles, along with
ikiwiki-idiomatic ways of overriding the template and styles.</p>
<p>Now I write <code>my_slides.remark</code> just like I’d write <code>my_blog_post.md</code>.
I locally preview the same way, too: commit, triggering an incremental
render. Quick and easy.</p>
<h2>Finished? Publish</h2>
<p>When the talk’s over, I:</p>
<ol>
<li>Squash unneeded intermediate commits</li>
<li>Write a very short post linking to the abstract, slides, and any
other related information</li>
<li>Replace the very short publicity page with a redirect to the new post</li>
<li><code>git push</code></li>
</ol>
<p>This used to be a less streamlined process. Now I do it immediately
after the talk.</p>
<h2>Further improvements</h2>
<p>It’s a very common ikiwiki configuration to allow anyone to web-edit any
page. That’s not a smart thing to allow for pages that are
JavaScript-powered web slides. My site happens to be safe because I
disallow web-editing, but if I want to stop carrying around a local
copy of my code — and I do — then I need to make the plugin safe for
inclusion in ikiwiki. That will require more thinking and doing.</p>
<p>At some point, it may become important to me to make fancier slides than
Remark.js can produce. To do that, I’ll have to develop a new skill.</p>
My writing workflowhttps://schmonz.com/2015/10/14/my-writing-workflow/Amitai Schlair2016-11-12T01:39:43Z2015-10-14T14:16:23Z
<h2>Previously</h2>
<ul>
<li><a href="https://schmonz.com/2015/09/16/my-coding-workflow/">My coding workflow</a></li>
<li><a href="https://schmonz.com/2015/09/23/my-podcasting-workflow/">My podcasting workflow</a></li>
</ul>
<p>Now that <a href="https://schmonz.com/2015/09/30/habit-forming/">it’s a weekly habit</a>, when I
set about writing one of these here blog posts, it’s not usually
happening <a href="https://twitter.com/neil_killick/status/652897091975409664">in the heat of a ranty
moment</a>. I
have to decide what to write about. That decision is based partly
on what I’ve written recently, in case there’s a logical sequence
waiting to be followed (like this one); partly on what’s happening
with me in work or in life, in case I need a new direction; and
partly on which of the available options leads me first to an idea
about how to write about it. I wasn’t setting out today to write
up another workflow. A fortuitous input led me there.</p>
<h2>Fortuitous</h2>
<p>A fellow participant in June’s <a href="https://schmonz.com/2015/06/17/problem-solving-leadership/">Problem Solving
Leadership</a> wrote me recently.
I had told him during PSL that one of my goals there was to be less
comfortable, because <a href="https://schmonz.com/2015/07/29/enthusiasm-engineering/">I default to
comfort</a>. He hadn’t shared that
goal at the time, but recently attended a training session that
perhaps changed his mind. “One thing I got out of it,” he wrote,
“is that uncomfortable leads to growth.” So he had a question for me.</p>
<h2>Have I been less comfortable?</h2>
<p>Yes, in at least one way: since April, when I started my current
streak of <a href="https://schmonz.com/2015/04/01/to-scale-agile-delegate-risk/">one new blog post</a>
and <a href="https://agilein3minut.es/1">one new podcast episode</a> every week, I’ve
been uncomfortable every week.</p>
<h2>One weird trick for writing faster and better</h2>
<p>I have a hard time writing when I’m not clear on who I’m writing
<em>for</em>. One trick I discovered in the early days of my online journal
was to pick someone to write <em>to</em>, and immediately the words would
come. Simply by emailing me a question and being his specific self,
my PSL classmate solved my problem this week.</p>
<p>Would you be willing to ask me a question, either here as a comment
or privately (by <a href="mailto:schmonz@schmonz.com">email</a>, <a href="https://twitter.com/schmonz">Twitter
DM</a>, etc.)? You’ll be doing me a favor!</p>
<h2>Another weird trick for writing at all</h2>
<p>Bring only my iPad (no phone, no laptop, yes <a href="http://www.ianker.com/product/98AP9804A-BTA">Bluetooth
keyboard</a>) to a public
place where people are having conversations and caffeinated beverages
are available (coffeeshop, bar, etc.). Turn off WiFi and cellular
networking. Insert earbuds. Open the <a href="https://coffitivity.com">Coffitivity</a>
app, just in case individual conversations are distinct and salient,
just loud enough to make it fruitless to attend to any of them.</p>
<p>In short, be <a href="https://schmonz.com/2015/08/05/confessions-of-a-twitter-completionist/">disconnected from
Twitter</a>, from the
folks in my immediate vicinity, and in general from the option to
do other things (or no things). Open
<a href="http://www.textasticapp.com">Textastic</a> or
<a href="http://agiletortoise.com/drafts/">Drafts</a> or even <a href="https://en.wikipedia.org/wiki/Notes%5F%28application%29">Notes</a>. Sip awake juice. Listen for the
faint signals in my brain, and write them down. Listen some more.
Write some more.</p>
<p>I need this hack because it’s easy for me not to focus on one thing
at a time, because I want my writing to be extremely clear, and
because writing while unfocused goes even more slowly than usual
and the outcome is crap. As a <a href="https://schmonz.com/2015/08/12/tdd-saved-my-brain/">perfectionist and
procrastinator</a>, I need to engineer
an environment in which it’s easier to focus than to not focus. You
might think a quiet hotel room would do the trick, and sometimes
it does, but it also affords me lots of options that aren’t writing.
I don’t want to have those options until I’m done with the hard
parts.</p>
<h2>A WIP-limiting, flow-enhancing trick from programming</h2>
<p>As I code, when I notice I’m about to gloss over something important,
I drop an <code>XXX</code> (and maybe a few more words of breadcrumb) as a
reminder to come back and think about it. I have the corresponding
habit of finding and fixing all new instances of <code>XXX</code> before
committing the change to source control. This trick lets me safely
<a href="https://schmonz.com/2015/08/19/life-hacks-for-the-test-infected/">complete my current
thinking-in-process</a>
before picking up a new line of thought.</p>
<p>As I write, I often think of references (previous posts, podcast
episodes, tweets) I’d like to link to. I drop an <code>XXX</code> and keep
writing. This interdisciplinary hack works especially well now that
<a href="https://schmonz.com/2015/01/01/happy-new-year/">my writing also gets committed to source
control</a>.</p>
<h2>A focusing trick from <a href="https://agilein3minut.es/">Agile in 3 Minutes</a></h2>
<p>When I can write an outline first, and maybe even choose a title,
the writing seems to go more smoothly. Sometimes that works. And
sometimes the only way to find out what I’m trying to write about
is to have written it.</p>
<h2>What’s my next source of discomfort?</h2>
<p>The process of writing still induces discomfort for me; no matter
how many consecutive weeks I keep doing it, I’m guessing that’ll
never completely go away. But it does seem to be getting better.</p>
<p>I try to finish my two weekly writings in my two or three evenings
a week when I’m away for work, so that I don’t have to spend any
of my precious minutes at home on that stuff. I often (not always)
succeed. The during-travel-evenings-only timebox has pushed me to
be more disciplined, but also to feel more pressure, but also also
to notice that the feeling of pressure neither helps me get my
writing done nor brings out my best thoughts. These last few weeks
I’ve been practicing feeling less pressure and more pleasure. So I
think that creating, following, and addressing my discomfort here
has begun to pay off.</p>
<p>That means I’m ready to add something new. I’ve got something in
mind that I’m uncomfortable just thinking about. I’m looking forward
to seeing how I’ll learn to address it, and to sharing my learning
with you.</p>
My podcasting workflowhttps://schmonz.com/2015/09/23/my-podcasting-workflow/Amitai Schlair2016-11-12T01:39:43Z2015-09-23T04:00:00Z
<p>When I’m programming, I can usually sense when I’m off track, and
have <a href="https://schmonz.com/2015/08/19/life-hacks-for-the-test-infected/">accumulated a bunch of
tricks</a> to <a href="https://schmonz.com/2015/09/16/my-coding-workflow/">direct
my flow</a>. 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 <a href="https://schmonz.com/2007/11/16/explosion-at-the-poem-factory/">how the sausage gets
made</a> each week.</p>
<h2>Choose the topic</h2>
<p>Before there was a show, to convince myself I had enough to talk
about, I made a backlog. Once <a href="https://schmonz.com/2015/07/15/introducing-agile-in-3-minutes/">there was a
show</a>, listeners started
contributing suggestions for topics and other improvements. (<a href="https://agilein3minut.es/support">You can too</a>.)</p>
<p>Sometimes I <a href="https://agilein3minut.es/backlog">look at the backlog</a>. For
instance, a couple nights ago (having shipped <a href="https://agilein3minut.es/22">22:
Control</a>), 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.</p>
<p>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.</p>
<p>I don’t believe learning is linear or orderly, but I do believe
there exist more and less digestible orderings in which <a href="https://flowchainsensei.wordpress.com/2015/09/25/my-definition-of-agile">the Agile
memeplex can be
unfolded</a>.
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.</p>
<p>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.</p>
<h2>Write it</h2>
<p>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 <a href="https://agilein3minut.es/about">expect to find a 3-minute treatment</a>. 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.</p>
<p>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!</p>
<p>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.</p>
<p>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?</p>
<p>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.</p>
<p>You can hear me talking a bit about this writing process at 42:24
of <a href="http://ryanripley.com/013-agile-for-humans/">Agile for Humans 013</a>.
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.</p>
<h2>Record it</h2>
<p><a href="https://schmonz.com/2015/09/23/yeti-and-quietcomfort.jpg"><img src="https://schmonz.com/2015/09/23/my-podcasting-workflow/300x400-yeti-and-quietcomfort.jpg" width="300" height="400" alt="Audio equipment in its natural traveling habitat" title="Audio equipment in its natural traveling habitat" class="img" /></a></p>
<p>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.</p>
<h2>Postprocess it</h2>
<p>I open <a href="http://audacityteam.org">Audacity</a>, 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
<a href="http://lame.sourceforge.net">LAME</a>, I compress and tag the MP3,
then delete the intermediate audio files.</p>
<h2>Describe it</h2>
<p>Using a <a href="http://ikiwiki.info/ikiwiki/directive/template/">custom ikiwiki
template</a>, I write show notes in a mostly declarative format,
usually with at least one link to the <a href="http://c2.com/cgi/wiki?">C2 wiki</a> and
another to <a href="https://en.wikipedia.org/wiki/">Wikipedia</a>. 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 <a href="https://schmonz.com/2015/08/26/audio-in-a-tweetshell/">show an inline audio
control</a> when anyone posts a link.</p>
<h2>Publish it</h2>
<p><code>git add</code> the MP3, the show notes, and the HTML container. <code>git
commit</code>. <code>git push</code>. Ikiwiki puts the episode on the front page and
adds it to the archive and the RSS feed. Easy!</p>
<h2>Share it</h2>
<p>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.</p>
<h2>Improve it</h2>
<p>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.</p>
<p>Do you know a cool writing or audio-production trick? Got ideas for
the show? Let me know in the comments.</p>
My coding workflowhttps://schmonz.com/2015/09/16/my-coding-workflow/Amitai Schlair2016-11-12T01:39:43Z2015-09-16T04:00:00Z
<p>Julio Merino recently <a href="https://medium.com/@jmmv/my-coding-workflow-f26f81235752">described his coding
workflow</a>
and <a href="https://twitter.com/jmmv/status/641138163163922432">invited others to describe
theirs</a>. My
previous workplace development environment <a href="https://schmonz.com/2013/10/17/working-from-everywhere/">looked a whole
lot</a> 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.</p>
<h2>Development environments</h2>
<table>
<tr>
<th>When?</th>
<td>Then</td>
<td>Now</td>
</tr>
<tr>
<th>Team</th>
<td>Remote</td>
<td>Local</td>
</tr>
<tr>
<th>Role</th>
<td>Developer, etc.</td>
<td><a href="https://schmonz.com/2015/09/09/how-to-get-decent-at-coaching/">Coach</a></td>
</tr>
<tr>
<th>OS</th>
<td>Unix</td>
<td>Windows</td>
</tr>
<tr>
<th>Build Radiator</th>
<td>Standalone VM with a custom <code>cron</code> job</td>
<td>IBM uBuild</td>
</tr>
<tr>
<th>Backlog</th>
<td>Markdown files in Git</td>
<td>Rally</td>
</tr>
<tr>
<th>Source Control</th>
<td>Git</td>
<td>AccuRev</td>
</tr>
<tr>
<th>Architecture</th>
<td>CLI/GUI client/server</td>
<td>web services</td>
</tr>
<tr>
<th>Language</th>
<td>Perl</td>
<td>Java</td>
</tr>
<tr>
<th>Editor</th>
<td><code>vim</code></td>
<td>IBM Rational Software Architect (Eclipse-derived)</td>
</tr>
<tr>
<th>Pairing</th>
<td><code>tmux</code></td>
<td>same desk</td>
</tr>
</table>
<p>I had been an <code>nvi</code> fuddy-duddy until my teammates finally prevailed on
me with their fancy colors and configs. Thanks, guys.</p>
<h2>Mere strong preferences</h2>
<p>I grew up as a computer user on classic Mac OS and
<a href="http://www.netbsd.org">NetBSD</a>. When <a href="https://en.wikipedia.org/wiki/Mac%5FOS%5FX%5FServer%5F1%2E0">Mac OS X Server 1.0</a>
came out, all clunky and expensive, I bought it just to have it;
when the <a href="https://en.wikipedia.org/wiki/Mac%5FOS%5FX%5FPublic%5FBeta">Mac OS X Public Beta</a> 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:</p>
<ul>
<li>Unix</li>
<li><code>vi</code></li>
<li>Git</li>
<li><a href="http://www.pkgsrc.org">pkgsrc</a></li>
</ul>
<p>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 <a href="https://schmonz.com/2013/01/22/codemash-2013-your-dev-toolbox-everywhere/">gave a lightning talk about
it</a> at CodeMash
2013.</p>
<p>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 <a href="http://ikiwiki.info">ikiwiki</a>) happen to
lend themselves very well. I’m sure there’s cause and effect in
both directions.</p>
<p>When I’m stuck on Windows, where I don’t feel as comfortable or
productive, I usually wind up <a href="https://schmonz.com/2006/06/13/pkgsrc-on-windows/">arranging for a Unix
environment</a>, and using it from time
to time to keep myself from getting sidetracked too often figuring
out how to do some small thing.</p>
<p>When I’m stuck with a weird revision control system, I often <a href="https://schmonz.com/2013/03/10/permanent-cvs-temporary-git/">use
Git in parallel</a>. 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.</p>
<h2>Must-haves</h2>
<p>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.</p>
<p>In software development, there’s a problem I <em>always</em> have: I <a href="https://schmonz.com/2014/04/01/my-superpower/">make
lots of decisions</a>, 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 <em>always</em>
start by arranging for a fast red/green feedback loop.</p>
<p>It doesn’t have to display actual red and green, or <a href="https://schmonz.com/2014/01/26/how-to-efficiently-learn-a-programming-language/">use an
established testing
framework</a>,
or <a href="https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric">finish before I can
blink</a>.
It does have to start with a keystroke, finish with a clear indicator,
and <a href="https://schmonz.com/2015/08/19/life-hacks-for-the-test-infected/">return me to my
context</a>. 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.</p>
<h2>It’s not about tools</h2>
<p>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).</p>
<p>It’s about <em>flow</em>, 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.</p>
<p>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 <a href="https://twitter.com/schmonz/status/605826934564462593">pay for
smooth</a>, my
investments yield strong returns.</p>