pages tagged pillarYareev's schmonz.comhttps://schmonz.com/tag/pillar/Yareev's schmonz.comikiwiki2023-12-19T15:13:11ZWhat I'm Doing Nowhttps://schmonz.com/2017/04/17/now/Amitai Schleier2017-04-17T21:53:37Z2017-04-17T21:46:09Z
<h2>I’m working on…</h2>
<p>Things other than work.</p>
<p>I’m grateful to Pillar for their part in
<a href="https://schmonz.com/2015/01/09/two-engagements/">two formative years</a>
that have
<a href="https://schmonz.com/2016/03/03/why-i-went-to-fat-camp/">changed how I feel about myself</a>,
<a href="https://schmonz.com/2017/01/05/new-years-slack/">how I prioritize</a>,
and how best to incorporate
<a href="https://schmonz.com/coach/">my work</a>
into my life.</p>
<h2>I’m spending time on…</h2>
<p>Converting health intentions back to health habits.</p>
<p>Publishing guest episodes of
<a href="https://agilein3minut.es/">Agile in 3 Minutes</a>, most recently
<a href="https://agilein3minut.es/35">35: Define</a>.</p>
<p>Making guest appearances on other podcasts, most recently Agile for Humans
<a href="https://schmonz.com/talk/20170313-agile-for-humans/">058 with Llewellyn Falco</a>,
<a href="https://schmonz.com/talk/20170410-agile-for-humans/">061 with GeePaw Hill</a>, and
<a href="https://schmonz.com/talk/20170417-agile-for-humans/">062 with Lisa Crispin</a>, as well as
<a href="https://schmonz.com/talk/20170320-agile-path/">S1E1 of The Agile Path</a> and the
<a href="https://schmonz.com/talk/2017-agile-path-safety-retro/">accompanying retrospective</a>.</p>
<p>Designing material for
<a href="https://schmonz.com/2017/03/16/how-to-meet-me-spring-2017-edition/">upcoming conference appearances</a>,
starting with this week’s
<a href="https://schmonz.com/talk/2017-aatc/">Agile Alliance Technical Conference</a>.</p>
<p>Rediscovering <a href="https://schmonz.com/tag/music/">my digital piano</a>.</p>
<p>Preparing, even though I can’t know exactly how, for my priorities to soon change.</p>
<h2>I’m looking forward to…</h2>
<p>Reaping health benefits from health habits.</p>
<p>Deepening relationships with family, friends, and colleagues.</p>
<p>Doing short-term, high-value consulting, coaching, and training in the New York metropolitan area (or remote).</p>
<h2>I’m traveling to…</h2>
<p>See my <a href="https://schmonz.com/speaker/">speaker</a> page.</p>
<hr />
<h3>What’s this?</h3>
<p>It’s a
<a href="http://sivers.org/nowff"><code>/now</code> page</a>.</p>
<p><a href="http://nownownow.com">nownownow.com</a>
is a directory of people with <code>/now</code> pages.
<a href="http://nownownow.com/p/JtD5">I’m listed there</a>.</p>
How to meet me (spring 2017 edition)https://schmonz.com/2017/03/16/how-to-meet-me-spring-2017-edition/Amitai Schleier2018-04-14T22:00:32Z2017-03-16T13:58:48Z
<p>There’s a link in the sidebar where you can
<a href="https://schmonz.com/link/coffee/">buy me a fancy coffee</a>,
but I’d much rather treat you, dear reader, to the beverage of your choice.
Here are some upcoming chances for us to do that:</p>
<p><strong>Boston</strong>, April 19-21: <a href="https://schmonz.com/talk/2017-aatc/">Agile Alliance Technical Conference</a></p>
<p><strong>New York City</strong>, April 28-30: <a href="https://schmonz.com/talk/2017-agilecoachcamp/">Agile Coach Camp</a></p>
<p><strong>New York City</strong>, May 1: <a href="https://schmonz.com/talk/2017-basd/">Big Apple Scrum Day</a></p>
<p><strong>Ann Arbor</strong>, May 4-5: <a href="https://schmonz.com/talk/2017-aab/">Agile and Beyond</a></p>
<p>Hope to see you. If not one of these, then another time.</p>
PillarCon 2017: Fundamentals of C and Embeddedhttps://schmonz.com/2017/02/18/pillarcon-2017-fundamentals-of-c-and-embedded/Amitai Schleier2017-03-07T16:14:00Z2017-02-19T00:07:16Z
<p>At the second annual
<a href="http://pillarcon.com">PillarCon</a>,
I facilitated a workshop called
“Fundamentals of C and Embedded using Mob Programming”.
On a Mac, we test-drove toggling a Raspberry Pi’s onboard LED.</p>
<ul>
<li><a href="https://pillarcon2017.sched.com/event/98X6">Abstract</a></li>
<li><a href="https://github.com/schmonz/c-embedded-fundamentals">Materials</a></li>
</ul>
<h2>Before and after</h2>
<table class="img"><caption>Before: ACT LED off</caption><tr><td><img src="https://schmonz.com/2017/02/18/IMG_8084.JPG" width="200" height="200" alt="Before: ACT LED off" class="img" /></td></tr></table>
<table class="img"><caption>After: ACT LED on</caption><tr><td><img src="https://schmonz.com/2017/02/18/IMG_8085.JPG" width="200" height="200" alt="After: ACT LED on" class="img" /></td></tr></table>
<h2>Retrospective</h2>
<table class="img align-right"><caption>Noteboard: takeaways from Fundamentals of C and Embedded</caption><tr><td><img src="https://schmonz.com/2017/02/18/IMG_8083.JPG" width="400" height="300" alt="Noteboard: takeaways from Fundamentals of C and Embedded" class="img" /></td></tr></table>
<p>Here are the takeaways we wrote down:</p>
<ul>
<li>Could test return type of <code>main()</code></li>
<li>Why wasn’t <code>num_calls</code> 0 to begin with?</li>
<li>Maybe provide the mocks in advance (maybe use
<a href="http://www.throwtheswitch.org/cmock/">CMock</a>)</li>
<li>Fun idea: fake
<a href="https://en.wikipedia.org/wiki/General%2Dpurpose%20input%2Foutput">GPIO</a>
device</li>
<li>Vim tricks! Cool</li>
<li>But maybe use an easier editor for target audience</li>
<li>Appropriate amount of effort; need bigger payoff</li>
<li><a href="https://en.wikipedia.org/wiki/Mob%20programming">Mob programming</a> supported the learning process/objective</li>
</ul>
<p>My own thoughts for next time I do this material:</p>
<ul>
<li><strong>Keep:</strong> providing multi-target <code>Makefile</code> and prebuilt cross compiler</li>
<li><strong>Try:</strong> providing the mocks in the starting state</li>
<li><strong>Keep:</strong> being prepared with a
<a href="https://schmonz.com/2015/08/19/life-hacks-for-the-test-infected/">test list</a></li>
<li><strong>Try:</strong> using a more discoverable (e.g., non-modal) text editor</li>
<li><strong>Keep:</strong> being prepared with corners to cut if time gets short</li>
<li><strong>Try:</strong> providing already-written test cases to uncomment one at a
time (one of the aspects of
<a href="https://schmonz.com/2016/06/18/training-tdd-for-embedded-c/">James Grenning’s training course</a>
I especially loved)</li>
<li><strong>Keep:</strong> mobbing</li>
<li><strong>Try:</strong> knowing more of the mistakes we might make when cutting corners</li>
<li><strong>Keep:</strong> delivering a visible result</li>
<li><strong>Try:</strong> turning off the PWR light (if possible) so we can more easily
see when the ACT light turns on and off</li>
</ul>
<p>Participants who already knew some of this stuff liked the mob programming
(new to some of them) and appreciated how I structured the material
to unfold.
Participants who were new to C and/or embedded (my target audience) came
away feeling that they needn’t be intimidated by it, and that
programming in this context can be as fun and feedbacky as they’re
accustomed to.</p>
<h2>Play along at home</h2>
<ol>
<li><a href="https://wiki.netbsd.org/ports/evbarm/raspberry_pi/">Install NetBSD 7 on Raspberry Pi</a></li>
<li><a href="https://www.netbsd.org/docs/guide/en/chap-fetch.html">Fetch the NetBSD source tree</a>
(or <a href="https://github.com/schmonz/c-embedded-fundamentals/blob/9bdd1d2d8839a6a65523c4cdbef68e9f3705707e/Makefile#L37">let the <code>Makefile</code> do it for you</a>)</li>
<li><a href="https://www.netbsd.org/docs/guide/en/chap-build.html">Build the cross compiler and a complete NetBSD for the target system</a>
(or <a href="https://github.com/schmonz/c-embedded-fundamentals/blob/9bdd1d2d8839a6a65523c4cdbef68e9f3705707e/Makefile#L40">let the <code>Makefile</code> do it for you</a>)</li>
</ol>
<p>Then follow the steps outlined in the
<a href="https://github.com/schmonz/c-embedded-fundamentals/blob/master/README.md">README</a>.</p>
<h2>Further learning</h2>
<p>You’re welcome to use the workshop materials for any purpose, including
your own workshop.
If you do, I’d love to hear about it.
Or if you’d like me to come facilitate it for your company, meetup
group, etc., let’s talk.</p>
<ul>
<li><a href="https://schmonz.com/2016/07/08/how-to-learn-c-part-1/">How to learn C (Part 1)</a></li>
<li><a href="https://schmonz.com/2017/02/16/how-to-learn-c-part-2/">How to learn C (Part 2)</a></li>
<li><a href="https://agilein3minut.es/32">Agile in 3 Minutes 32: Mob</a></li>
</ul>
How to learn C (Part 2)https://schmonz.com/2017/02/16/how-to-learn-c-part-2/Amitai Schleier2017-02-17T00:08:32Z2017-02-16T23:56:35Z
<h2>Previously</h2>
<ul>
<li><a href="https://schmonz.com/2016/07/08/how-to-learn-c-part-1/">How to learn C (Part 1)</a></li>
</ul>
<h2>Give assignments</h2>
<p>Since July, when I wrote Part 1, I
<a href="https://schmonz.com/2016/08/18/new-name/">got married</a>,
<a href="https://schmonz.com/2016/09/11/refactorings-for-web-hosting/">joined a C-based project</a>,
rolled off,
<a href="https://schmonz.com/2017/02/02/settling-in/">joined a new project, and moved house</a>.</p>
<p>One of the recommendations in Part 1 was “take assignments.”
The reason I’m finally back for Part 2 is that I’m
<a href="https://schmonz.com/talk/2017-pillarcon/">running a workshop on Saturday</a>.
If you’re having trouble making time to learn something, try committing
yourself to teach it.</p>
<h2>Trust your doubts</h2>
<p>I’m supposed to deliver two hours of hands-on “Fundamentals of C and Embedded.”
Having worked in C professionally for some weeks — and embedded systems for zero — I certainly don’t know any <em>more</em> than the fundamentals.
It could be the case that I know less.</p>
<p>I don’t have to be an expert at C or embedded to deliver what I’ve promised.
I <em>do</em> have to be an expert at noticing, of all the things I don’t know, what’s bothering me the most right now.
Over and over again.</p>
<h2>One question at a time</h2>
<p>Even though a Raspberry Pi is a general-purpose computer, in the workshop we’re going to treat it as an embedded system.
By that, I mean that even though we could easily develop software directly on the Pi, we’re going to pretend we can’t.
Or another way: even though it’s actually reasonably quick and cheap, we’re going to pretend it’s slow and expensive to deploy and test on the “target” system.</p>
<p>As I was preparing the workshop, here’s what I didn’t know that bothered me the most, in order:</p>
<ol>
<li>Can I write C to drive some visible feature of the Pi?
See whether I can get the onboard LED to toggle.
Result:
<a href="https://gist.github.com/schmonz/c8a8d38019823462781e6d68126bac93">it works</a>.</li>
<li>Can I cross-compile some C code? Try adapting
<a href="https://github.com/schmonz/c-roman-numeral-kata">Roman Numeral Calculator</a>
to optionally target the Pi.
Result:
<a href="https://github.com/schmonz/c-roman-numeral-kata/commit/5193bfe7d0e2409f7f88110c531af0025efd04c4">it works</a>.</li>
<li>Can I link with one implementation of an interface for the host and
another for the target?
Yes: the native Mac build prints “gonna toggle the LED” and the Pi
build really toggles it.</li>
<li>Can I instruct the Pi build (and not the native Mac build) to depend
on that cross compiler, and to rebuild it if it’s missing?
Yes (and I’m glad I kept my notes and got it right on the first try).</li>
<li>Can I link with real system calls for the target and custom fakes for
the host?
Yes, and this supersedes what I learned in (3): with fakes for
<code>open(2)/ioctl(2)/close(2)</code>, I can get rid of the fake implementation
of <code>led_toggle()</code>.</li>
<li>Can I now write microtests for <code>led_toggle()</code>?
Yes, and in so doing I found and fixed some behavior that didn’t meet
my expectations.</li>
<li>Am I now qualified to run a workshop that claims we’ll “test-drive a
Raspberry Pi from a Mac”?
I believe so.</li>
</ol>
<h2>Conclusion</h2>
<p>Am I <em>ready</em> to run the workshop?
Not quite.
I want to make sure that in our two hours as a
<a href="https://agilein3minut.es/32">mob</a>,
test-driving C in Vim, we get the satisfaction of toggling that LED.</p>
<p>How fast we get there depends on how well we test-drive (our company
prides itself on this), how well we know C (depends on who shows up),
and how well we can deal with Vim (same).
It’s possible that our pace won’t be fast enough; I’ll want to have
thought about how to speed us up.
It’s also possible that we’ll blow right through it; I’ll want to have
thought about what more we could do with our time.</p>
<p>I’m still no expert in C or embedded systems, but the state of my
knowledge is no longer the bottleneck to delivering a valuable version
of this workshop.
Wish me luck!</p>
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>
Agile Testing Days 2016: DevOps Dojohttps://schmonz.com/2016/12/07/agiletd-2016-devops-dojo/Amitai Schleier2023-04-22T11:55:21Z2016-12-07T09:01:44Z
<p>At
<a href="http://www.agiletestingdays.com">Agile Testing Days</a>,
I facilitated a workshop called
“DevOps Dojo”.
We role-played Dev and Ops developing and operating a production system,
then figured out how to do it better together.</p>
<ul>
<li><a href="http://www.agiletestingdays.com/session/devops-dojo/">Abstract</a></li>
<li><a href="https://schmonz.com/2016/12/07/agiletd-2016-devops-dojo/slides/">Slides</a></li>
</ul>
<p>We wrote down our takeaways on the
<a href="https://schmonz.com/2016/12/07/agiletd-2016-devops-dojo/slides/#23">final “Retrospective” slide</a>.</p>
<p>You’re welcome to use the
<a href="https://github.com/schmonz/devops-dojo">workshop materials</a>
for any purpose, including your own workshop.
If you do, I’d love to hear about it.</p>
<h2>Some firsts</h2>
<p><img src="https://schmonz.com/smileys/prio1.png" alt="{1}" /> I’ve spoken at several instances of
<a href="http://pkgsrc.org/pkgsrcCon/">pkgsrcCon</a>
(including
<a href="https://schmonz.com/2008/06/15/pkgsrccon-2008-the-wrapper-framework-then-now-and-soon/">twice</a>
in nearby
<a href="https://schmonz.com/2013/04/05/pkgsrccon-2013-rehabilitating-pkglint/">Berlin</a>),
but that’s more like a hackathon with some talks.
Agile Testing Days was a proper <em>conference</em>, with hundreds of
people and plenty of conferring.
If someone asks whether I’m an “international speaker”,
or claims I am one,
I now won’t feel terribly uncomfortable going along with it.</p>
<p><a href="https://twitter.com/carlosble/status/806250754336030721"><img src="https://schmonz.com/2016/12/07/agiletd-2016-devops-dojo/400x300-CzBguACXAAMn0-q.jpg" width="400" height="300" alt="Two WeDoTDDers" class="img" /></a></p>
<p><img src="https://schmonz.com/smileys/prio1.png" alt="{1}" /> I met a fellow
<a href="https://twitter.com/WeDoTDD">WeDoTDD</a>
practitioner,
<a href="https://twitter.com/carlosble">Carlos Blé</a>
of
<a href="https://twitter.com/codesaidev">Codesai</a>.
(Here’s
<a href="http://www.wedotdd.com/interviews/companies/7">their WeDoTDD interview</a>
and
<a href="http://www.wedotdd.com/interviews/companies/3">Pillar’s</a>.)
Carlos and I have both
<a href="https://schmonz.com/2015/08/05/confessions-of-a-twitter-completionist/">relied on Twitter</a>
to build our careers.
Who knows, maybe we’ll give a talk together about it.</p>
<p><img src="https://schmonz.com/smileys/prio1.png" alt="{1}" /> At the Tuesday morning
<a href="http://leancoffee.org">Lean Coffee</a>,
I found a bug in myself (<em>not</em> a first).</p>
<p><strong>What I expected</strong> from many previous Lean Coffees:
I’d have to control myself to not say all the ideas and suggestions that
come to mind.</p>
<p><strong>What happened</strong> at this Lean Coffee:
It was very easy to listen, because I didn’t have many ideas or
suggestions, because the topics came from people who were mostly
testers.</p>
<p>Conclusions I immediately drew:</p>
<ul>
<li>Come to think of it, I have not played every role on a team. I don’t
know what it’s like to be a tester. Maybe my guesses about what it’s
like are less wrong than some others, but they’re still gonna be
wrong.</li>
<li>This is evidently my first conference that’s more <em>testing</em> than
<em>Agile</em>. Cool! I bet I can learn a lot here.</li>
</ul>
<p><a href="https://twitter.com/lisacrispin/status/806632387920752640"><img src="https://schmonz.com/2016/12/07/agiletd-2016-devops-dojo/400x300-CzG74ZOXgAEcPtF.jpg" width="400" height="300" alt="Four Yorkshiremen" class="img" /></a></p>
<p><img src="https://schmonz.com/smileys/prio1.png" alt="{1}" /> <a href="https://twitter.com/mheusser">Matt Heusser</a>
invited me to perform in the Late Night Cabaret with Bob
(<a href="https://twitter.com/lisacrispin">Lisa Crispin</a>’s spouse)
and Jack
(<a href="https://twitter.com/janetgregoryca">Janet Gregory</a>’s).
We did the
<a href="https://en.wikipedia.org/wiki/Four%20Yorkshiremen%20sketch">Four Yorkshiremen sketch</a>
as
<a href="https://www.youtube.com/watch?v=26ZDB9h7BLY">popularized by Monty Python</a>.</p>
<p><img src="https://schmonz.com/smileys/prio1.png" alt="{1}" /> Thanks to
<a href="https://twitter.com/t_magennis">Troy Magennis</a>,
<a href="https://twitter.com/mgaertne/status/758673541642477568">Markus Gärtner</a>,
and
<a href="https://twitter.com/CatSwetel/status/758676635000406016">Cat Swetel</a>,
I decided to
<a href="https://twitter.com/schmonz/status/759484222864183296">try a new idea</a>
and spend
<a href="https://schmonz.com/2016/12/07/agiletd-2016-devops-dojo/slides/#3">a few slides</a>
drawing attention to the existence and purpose of Agile Testing Days’
<a href="https://en.wikipedia.org/wiki/Code%5Fof%5Fconduct">Code of Conduct</a>.
I can’t tell yet how much good this did, but it took so little time that
I’ll keep trying it in future conference presentations and workshops.</p>
<h2>Some nexts</h2>
<p><img src="https://schmonz.com/smileys/star_on.png" alt="{*}" /> My next gig will be remote coaching, centered around what we notice as
we’re pair programming and delivering working software.
I’ve done plenty of
<a href="https://schmonz.com/coach/">coaching</a>
and plenty of
<a href="https://schmonz.com/2013/10/17/working-from-everywhere/">remote work</a>,
but not usually at the same time.
Thanks to Lean Coffee with folks like Janet and
<a href="https://twitter.com/alex_schl">Alex Schladebeck</a>,
I got some good advice on being a more effective
<a href="https://agilein3minut.es/15">influencer</a>
when it takes more intention and effort to have face-to-face interactions.</p>
<ul>
<li>Alex: For a personal connection, start meetings by unloading your
“baggage” — whatever’s on your mind today that might be dividing your
attention — and inviting others to unload theirs. (Ideally, establish
this practice in person first.)</li>
<li>Janet: Ask questions that help people recognize their own situation.
(Helping people orient themselves in their problem spaces is one of my
go-to strengths. I’m ready to be leaning harder on it.)</li>
</ul>
<p><img src="https://schmonz.com/smileys/star_on.png" alt="{*}" /> As I learn about remote coaching, I expect to write things down at
<a href="http://shapemywork.com/">Shape My Work</a>,
a wiki about distributed Agile that
<a href="https://twitter.com/onealexharms">Alex Harms</a>
and I created.
You’ll notice it has a Code of Conduct.
If it makes good sense to you, we’d love to learn what you’ve learned as
a remote Agilist.</p>
<p><img src="https://schmonz.com/smileys/star_on.png" alt="{*}" /> I found Agile Testing Days to be a lovingly organized and carefully
tuned mix of coffee breaks, efficiency, flexibility, and whimsy.
The love and whimsy shone through.
I’m honored to have been part of it, and I sure as heck hope to be back
next year.</p>
<p>We’d be back next year anyway; we visit family in Germany every December.
Someday we might choose to live near them for a while.
It occurs to me that having participated in Agile Testing Days
might well have been an early investment in that option, and the thought
pleases me.
(As does the thought of hopping on a train to participate again.)</p>
<p><img src="https://schmonz.com/smileys/star_on.png" alt="{*}" /> I’m in Europe through Christmas.
I consult,
<a href="https://schmonz.com/coach/">coach</a>,
and train.
Do you know of anyone who could use a day or three of my services?</p>
<p><img src="https://schmonz.com/smileys/star_on.png" alt="{*}" /> One aspect of being a tester I <em>do</em> identify with is being frequently
challenged to explain their discipline or justify their decisions to
people who don’t know what the work is like (and might not recognize the
impact of their not knowing).
In that regard, I wonder how helpful
<a href="https://schmonz.com/2015/10/07/agile-in-3-minutes-the-book/">Agile in 3 Minutes</a>
is for testers.</p>
<p>Let’s say I could be so lucky as to have a few guest episodes about testing.
Who would be the first few people you’d want to hear from?
Who has a way with words and ideas, knows the work, and can speak to it
— in their unique voice —
to help the rest of us understand a bit better?</p>
Automation for web hostinghttps://schmonz.com/2016/11/23/automation-for-web-hosting/Amitai Schleier2016-11-26T06:17:23Z2016-11-24T00:35:52Z
<p>My first job was in
<a href="https://en.wikipedia.org/wiki/Information%5Ftechnology%5Foperations">Operations</a>.
When I got to be a Developer, I promised myself I’d remember how to be good to Ops.
I’ve <a href="https://schmonz.com/coach/">sometimes succeeded</a>.
And when I’ve been effective, it’s been in part due to my firsthand knowledge of both roles.</p>
<h2>DevOps is two things (hint: they’re not “Dev” and “Ops”)</h2>
<p>Part of what people mean when they say
<a href="https://en.wikipedia.org/wiki/DevOps">DevOps</a>
is automation.
Once a system or service is in operation, it becomes more important to engineer its tendencies toward staying in operation.
Applying disciplines from software development can help.</p>
<p>These words are brought to you by a Unix server I operate.
I rely on it to serve this website, those of a few friends, and a
<a href="https://agilein3minut.es/">tiny podcast of some repute</a>.
Oh yeah, and my email.
It has become rather important to me that these services tend to stay operational.
One way I improve my chances is to
<a href="https://schmonz.com/2016/09/11/refactorings-for-web-hosting/">simplify what’s already there</a>.</p>
<h2>If it hurts, do it more often…</h2>
<p>Another way is to update my
<a href="https://github.com/schmonz/dotfiles/blob/master/pkgcomp-autopackages">installed third-party software</a>
once a week.
This introduces two pleasant tendencies: it’s much…</p>
<ol>
<li>Less likely, at any given time, that I’m running something dangerously outdated</li>
<li>More likely, when an urgent fix is needed, that I’ll have my wits about me to do it right</li>
</ol>
<p>Updating software every week also makes two strong assumptions about safety (see
<a href="http://modernagile.org">Modern Agile’s</a>
“Make Safety a Prerequisite”): that I can quickly and easily…</p>
<ol>
<li>Roll back to the previous versions</li>
<li>Build and install new versions</li>
</ol>
<p>Since I’ve been leaning hard on these assumptions, I’ve invested in making them more true.</p>
<p>The initial investment was to figure out how to configure
<a href="http://pkgsrc.org">pkgsrc</a>
to build a complete set of binary packages that could be installed at the same time as another complete set.
My hypothesis was that then, with predictable and few side effects, I could select the “active” software set by moving a
<a href="https://en.wikipedia.org/wiki/symbolic%5Flink">symbolic link</a>.</p>
<p>It worked.
On my
<a href="https://schmonz.com/2006/06/29/installing-netbsd-on-powerpc-mac-mini/">PowerPC Mac mini</a>,
the best-case upgrade scenario went from half an hour’s downtime (bring down services, uninstall old packages, install new packages, bring up services) to less than a minute (install new packages, bring down services, move symlink, bring up services, delete old packages after a while).
The worst case went from <img src="https://schmonz.com/smileys/alert.png" alt="/!\" /> over an hour to <img src="https://schmonz.com/smileys/thumbs-up.png" alt="{OK}" /> maybe a couple of minutes.</p>
<h2>…Until it hurts enough less</h2>
<p>I liked the payoff on that investment a <em>lot</em>.
I’ve been
<a href="https://schmonz.com/2015/11/04/incremental-effort-incremental-payoff/">adding incremental enhancements</a>
ever since.
I used to do builds directly on the server: in place for low-risk leaf packages, as a separate full batch otherwise.
It was straightforward to do, and I was happy to accept an occasional reduction in responsiveness in exchange for the results.</p>
<p>After
<a href="https://schmonz.com/2013/05/27/remembering-textpattern/">the Mac mini died</a>,
I moved to
<a href="https://schmonz.com/2015/11/25/equipped-to-podcast/">a hosted Virtual Private Server</a>
that was much easier to mimic.
So I took the job offline to a local
<a href="https://www.virtualbox.org">VirtualBox</a> running the same release and architecture of
<a href="http://www.netbsd.org">NetBSD</a>
(<a href="http://wiki.netbsd.org/ports/i386/">32-bit <code>i386</code></a>
to begin with,
<a href="http://wiki.netbsd.org/ports/amd64/">64-bit <code>amd64</code></a>
now, both under
<a href="http://wiki.netbsd.org/ports/xen/">Xen</a>).
The local job ran faster by some hours (I forget how many), during which the server continued devoting all its I/O and CPU bandwidth to its full-time responsibilities.</p>
<p>Last time I went and improved something was to fully automate the building and uploading, leaving myself a documented sequence of manual installation steps.
Yesterday I
<a href="https://schmonz.com/2016/11/23/schmonz-software-rebuild.txt">extended that shell script</a>
to generate another shell script that’s uploaded along with the packages.
When the upload’s done, there’s one manual step: run the install script.</p>
<p>If you can read these words, it works.</p>
<h2>DevOps is still two things</h2>
<p>Applying Dev concepts to the Ops domain is one aspect.
When I’m acting alone as both Dev and Ops, as in the above example, I’ve demonstrated only that one aspect.</p>
<p>The other, bigger half is collaboration across disciplines and roles.
I find it takes some not-tremendously-useful effort to distinguish this aspect of DevOps from
<a href="https://schmonz.com/2016/03/09/agileindy-march-2016-bdd-for-everyone/">BDD</a>
— or from anything else that looks like healthy cross-functional teamwork.
It’s the healthy cross-functional teamwork I’m after.
There are lots of places to start having more of that.</p>
<p>If your team’s context suggests to you that DevOps would be a fine place to start, go after it!
Find ways for Dev and Ops to be learning together and delivering together.
That’s the whole deal.</p>
<h2>Here’s another deal</h2>
<p>Two weeks from today, at
<a href="http://www.agiletestingdays.com">Agile Testing Days</a>
in Potsdam, Germany, I’m running a
<a href="http://www.agiletestingdays.com/session/devops-dojo/">hands-on DevOps collaboration workshop</a>.
Can you join us?
It’s not too late, and you can save 10% off the price of the conference ticket.
Just provide
<a href="https://schmonz.com/talk/2016-agiletd/">my discount code</a>
when you
<a href="http://www.agiletestingdays.com/registration/">register</a>.
I’d love to see you there.</p>
Agile Coach Camp 2016https://schmonz.com/2016/10/16/agile-coach-camp/Amitai Schleier2023-12-19T15:13:11Z2016-10-17T00:12:37Z
<p>There was an
<a href="http://agilecoachcamp.org/">Agile Coach Camp</a>
two years ago in Indianapolis — I could have been making crucial
career-changing connections, then sleeping in my own bed! — but we were
out of the country that weekend.
It was, unquestionably, a missed opportunity; perhaps
<a href="https://en.wikipedia.org/wiki/Open%5FSpace%5FTechnology%23Guiding%5Fprinciples%5Fand%5Fone%5Flaw">what happened was the only thing that could have</a>.
Things worked out anyhow.
Pillar
<a href="https://schmonz.com/2015/01/09/two-engagements/">gave me the work</a>,
and I’ve been
<a href="https://schmonz.com/2015/09/02/how-to-get-hired-as-a-coach/">trying to</a>
<a href="https://schmonz.com/2015/09/09/how-to-get-decent-at-coaching/">make the</a>
<a href="https://schmonz.com/2015/10/07/agile-in-3-minutes-the-book/">most of it</a>
<a href="https://schmonz.com/speaker/">ever since</a>.</p>
<p>I’m mildly amused at the timing of my first Agile Coach Camp.
Before I started down the coaching path, I imagined that sustaining it
— and myself — would mean I’d need to alternate between “doing it” and
“helping others do it”, like it
<a href="http://agilemanifesto.org">says right there in the Manifesto</a>.
So far, I’m not wrong.
At my request, I’ve just swung my professional pendulum most of the way
back to “doing it”, recharging my coaching energy and developer cred on
a team of fellow consulting-minded XP developers.
We’re embedded at a client, working to
<a href="https://twitter.com/schmonz/status/785564180514471936">influence the outcome of a change-the-world project that’s in the news</a>.
(Interested? Hit me up.)</p>
<p>Maybe this mental context switch is why, when only a handful of Campy
Coaches self-identified as “technical”, I was primed to figure out how
I might be able to share with the rest of them a tiny experience of
software development work.
En route to St. Louis, I’d already been revisiting this old thought:</p>
<blockquote><p><a href="https://twitter.com/schmonz/status/787256956285255680">People who haven’t done it have no way of knowing the extent to which
programming consists of making decisions. (It’s a very large extent.)</a></p></blockquote>
<p>The first time I wrote these words down was
<a href="https://schmonz.com/2014/04/01/my-superpower/">when I resigned from Morgan Stanley</a>.
Three years ago, despairing at how few around me shared my values, I
<a href="https://schmonz.com/2013/12/13/global-day-of-code-retreat/">discovered the Software Craftsmanship community</a>.
(If they sound like your people too,
<a href="http://globalday.coderetreat.org">Global Day of Code Retreat</a>
is this Saturday, and I highly recommend participating.)
I’ve had cause lately to reflect on how much
<a href="https://schmonz.com/2016/08/18/new-name/">my life</a>
<a href="https://schmonz.com/2016/03/03/why-i-went-to-fat-camp/">has improved</a>,
including how
<a href="http://www.wedotdd.com/interviews/companies/3">my role in the community</a>
has changed; if I hadn’t, spending a long weekend with Agile friends in
the venue’s main meeting room surely would have started the gears turning.</p>
<p><img src="https://schmonz.com/2016/10/16/IMG_3855.JPG" width="400" height="300" alt="the Morgan Stanley room" class="img" /></p>
<p>I came up with a few ways to offer folks an introduction to important
stuff that might normally make them uncomfortable:</p>
<ol>
<li><a href="https://twitter.com/ahmedavais/status/787312303976755200">Mob Programming ESPECIALLY for Non-Programmers</a>, during which we
used Vim to write C and almost got one FizzBuzz test to pass</li>
<li><a href="https://twitter.com/schmonz/status/787370782645063680">Test-Driven Development and Pairing for Non-Techies</a>
with
<a href="https://twitter.com/MarkBalbes">Mark Balbes</a>,
during which we “test-drove” and “refactored” a bit of prose
(<a href="https://web.archive.org/web/20230321132408/https://agileoutloud.wordpress.com/2018/05/11/tdd-by-storywriting/">Zach Bonaker’s writeup</a>)</li>
<li>”Show Me The Tech”, in which anyone interested to try/see/discuss any
technical practice could
<a href="https://twitter.com/schmonz/status/787682390374096896">pull me aside</a>
anytime
<a href="https://twitter.com/schmonz/status/787695479941312514">for 15 minutes</a></li>
</ol>
<p>The feedback I received suggested that this is a direction I might want
to keep going:</p>
<blockquote><p><a href="https://twitter.com/schmonz/status/787720856461979648">Closing circle at #ACCUS. My key learning: I can do a lot to help
non-developers better understand the work, and it’s needed and
wanted.</a></p></blockquote>
<p>Thank you to
<a href="https://twitter.com/TheAgileFactor">Jason Tice</a>
for giving us this
<a href="http://openspaceworld.org/wp2/what-is/">Open Space</a>,
and to everyone who joined me in finding meaningful ways to fill it.</p>
Training: TDD for Embedded Chttps://schmonz.com/2016/06/18/training-tdd-for-embedded-c/Amitai Schlair2017-05-22T21:12:09Z2016-06-18T15:29:02Z
<p>This week I ran a workshop. Last week I was in one.</p>
<p>For as long as I can remember, and probably longer, I’ve had a self-directed drive to learn, strong enough to be salient to observers. Lately I’ve become aware that I also have a periodic need for tiny doses of structured learning. Last week made this the third consecutive year I’ve taken some kind of training course. I observed the new pattern when I added <a href="https://wingman-sw.com/training/remote-delivered-tdd">James Grenning’s TDD for Embedded C</a> to <a href="https://schmonz.com/resume/">my résumé</a> and realized that if a recruiter or hiring manager saw nothing but the top three “Education” items, they’d get a remarkably accurate impression of me. I <a href="https://schmonz.com/coach/">coach</a>, I lead, I <a href="https://agilein3minut.es/about">Agile</a>, I solve problems, and I test-drive my code.</p>
<p>But not totally accurate. I don’t C.</p>
<p>Not much, anyway. I can think of a total of five bits of code I’ve ever written in C:</p>
<ol>
<li>A program to generate the Fibonacci sequence (iteratively and then recursively)</li>
<li>A <a href="https://en.wikipedia.org/wiki/Java%5FNative%5FInterface">JNI</a> library allowing Java programs to create a “link” (symlink on UNIX, shortcut on Windows)</li>
<li><a href="https://github.com/NetBSD/src/commit/d6fee2e18390c6d36b24859ae7ee948f2e08be5e">A <code>case</code> statement</a> in the <a href="http://wiki.netbsd.org/ports/macppc/">NetBSD/macppc</a> bootloader to allow system administrators to configure kernel behaviors (just like they already could on NetBSD/i386)</li>
<li>A bugfix for a <a href="https://en.wikipedia.org/wiki/Load%20balancing%20%28computing%29">load-balancing</a> appliance’s web admin GUI that wouldn’t display a particular table in (and only in) Internet Explorer if (and only if) the appliance lacked hardware <a href="https://en.wikipedia.org/wiki/SSL%20acceleration">SSL acceleration</a>, traced to some uninitialized <a href="https://en.wikipedia.org/wiki/automatic%20variable">automatically allocated</a> strings in the C <a href="https://en.wikipedia.org/wiki/Common%20Gateway%20Interface">CGI program</a> that emitted JSON for the <a href="https://en.wikipedia.org/wiki/Dojo%20Toolkit">Dojo Toolkit</a> GUI</li>
<li><a href="http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=5da229aa51adcec27b109ebe2e696f7426cbd781">A <code>for</code> loop</a> that instructs ikiwiki, when run as a post-commit hook in a website repository, to do nothing whatsoever when the triggering event was a <code>cvs add <directory></code> (because that acts immediately on the repo, does not constitute a commit, and justifiably confuses ikiwiki if not filtered out)</li>
</ol>
<p>I’m pretty sure that’s everything.</p>
<h2>What I hoped for</h2>
<p>Last week’s course was designed for people who’ve been developing for embedded systems in C to become acquainted with Test-Driven Development in general and/or in that context. I, on the other hand, am <a href="https://schmonz.com/2015/08/12/tdd-saved-my-brain/">very comfortable test-driving</a> and I wanted to become better acquainted with C. I knew I wasn’t in the course’s target (ha!) audience — but I also knew that someone skilled with TDD can exploit its fast feedback to <a href="https://schmonz.com/2014/01/26/how-to-efficiently-learn-a-programming-language/">learn a programming language quite quickly</a>.</p>
<p>With this in mind, I signed up for the course as <a href="https://schmonz.com/2015/07/29/enthusiasm-engineering/">an act of self-engineering</a> designed to focus 3 days x 5 hours of my attention on the material I wanted to be learning. And I enlisted a pair partner to <a href="https://agilein3minut.es/9">help me stay focused and un-stuck</a>.</p>
<h2>What I did</h2>
<p>During exercises, my remote pair and I used <a href="https://screenhero.com/">Screenhero</a> to share screen, mouse, keyboard, and voice. We didn’t use any particular pairing style, other than a little <a href="http://c2.com/cgi/wiki?PairProgrammingPingPongPattern">ping-pong</a> to get rolling. My pair had written some C++ somewhat recently, and often had better guesses than mine about how to say our next idea in C. We both understood when and how to test our guesses as quickly as possible.</p>
<p>During the TDD lectures, we each muted our Screenhero to avoid echoing the incoming audio at each other. I generally continued working on the day’s exercise. Sometimes my pair would join me. Without sound, I’d wiggle my mouse cursor (Screenhero gives each user their own cursor) to indicate I wanted the keyboard.</p>
<p>Because my pair and I had similar levels of skill with TDD (good), C (meh), and pairing itself (good), I didn’t notice silence slowing our pace much. I did, however, notice it constraining the flow of humor.</p>
<p>Each evening, since we hadn’t gotten all the way down the exercise’s <a href="https://schmonz.com/2015/08/19/life-hacks-for-the-test-infected/">test list</a>, I’d continue working (solo) until we had. The following morning, I’d review with my pair.</p>
<p>We’d been doing the training exercises online in <a href="http://cyber-dojo.org/">Cyber-Dojo</a>, which is very convenient for getting started, especially when the instructor provides ready-made exercises with test-driven supporting code and well-thought-out test lists, along with all the needed tools. Once the course was over, I knew that to sustain my momentum, I’d need to be able to edit, build, and run tests in my usual development machine — and pronto. The day after the course, I created a local git repository, added all three exercises as we’d done them, installed <a href="http://cpputest.github.io/">CppUTest</a>, debugged the exercise builds on my particular host OS and compiler, and committed the fixes to <code>makefile</code>s and code to make the tests green. Then I dumped the next few things I know I want to try, in a sensible order, to a to-do list.</p>
<p>Now that I can run the tests from my usual editor with my usual keystroke, and won’t forget my next goal, I’m confident that my learning will continue.</p>
<h2>What I got</h2>
<p>I wanted to learn some C. I got what I wanted.</p>
<p>I also got geek joy. When we figured out just enough about bitwise logical operators to test the right thing, make it pass, then refactor to more expressive symbols, that was a programmer’s high. I’ve always wanted to understand this stuff. Given a goal, a fast feedback loop, and a pair, I was able to start understanding it.</p>
<p>The joy was greater because it was shared. Usually I’d consider it risky to pair remotely for three days with someone I’d never met. But if that pair is someone who works for <a href="http://www.pillartechnology.com/">Pillar</a> and thinks learning about TDD in C sounds awesome? I had no doubt in my mind we were gonna have a good time together, and we did.</p>
<p>Some of the joy was meta-joy. Since TDD is a great way to learn design and domain concepts, and I’ve used it to learn one programming language, I hypothesized that it might be a great way to learn another, and that sure feels true. I love it when a mental model holds up!</p>
<p>I’m also feeling joy in my self-mastery: knowing what I wanted to learn, knowing what I needed to <em>start</em> and <em>continue</em> learning it, and arranging to get what I needed. (I talked about when and how I learn, among other things, on <a href="https://schmonz.com/talk/20160616-developer-on-fire/">this week’s Developer on Fire</a>. I’d love to hear what you think.) And getting better in general at knowing what I want — like spending more of my time programming — and arranging to get it.</p>
<h2>What’s next</h2>
<p>There’s a particular refactoring direction I want to take one of the exercises. If it works out the way I hope, I’ll learn some C. If it doesn’t, I’ll learn some C.</p>
<p>We didn’t get to deploy to hardware. I’ve got a <a href="https://en.wikipedia.org/wiki/Raspberry%5FPi">Raspberry Pi</a> and an <a href="https://en.wikipedia.org/wiki/Arduino">Arduino</a>, never used. I’d like to test-drive a “Hello World” and see it run, then test-drive the basic use of a device-specific hardware feature and see it work. That’ll teach me some embedded basics. Once I’ve done that, I’ll have a better idea what I need to learn next.</p>
<p>Many NetBSD kernel drivers can be recompiled, with no source changes, into standalone userland programs. (<em>See also</em> <a href="http://rumpkernel.org/">rump kernels</a>.) This means test failures can crash the process, but never the kernel — so automated test suites can be run freely and frequently, and it might be possible and sensible to test-drive new functionality into the NetBSD kernel. I’d like to try. Maybe I’m closer than I think.</p>
Path to Agility 2016: Shoestring Agility in a Velcro Organizationhttps://schmonz.com/2016/05/26/path-to-agility-2016-shoestring-agility/Amitai Schlair2016-11-12T01:39:43Z2016-05-26T19:09:28Z
<table class="img align-right"><caption>Gesticulating</caption><tr><td><a href="https://www.flickr.com/photos/cohaa/26832083743/in/photostream/"><img src="https://schmonz.com/2016/05/26/26832083743_43eeb410c4_o.jpg" width="200" height="301" alt="Gesticulating" class="img" /></a></td></tr></table>
<p>At <a href="http://www.thepathtoagility.com/">Path to Agility</a>, I told
stories of “Shoestring Agility in a Velcro Organization”.</p>
<ul>
<li><a href="http://www.thepathtoagility.com/breakout-16/">Abstract</a></li>
<li><a href="https://schmonz.com/2016/05/26/path-to-agility-2016-shoestring-agility/slides/">Slides</a></li>
</ul>
<p>The stories are also available in written form as the
<a href="https://schmonz.com/tag/tdd-in-context/">TDD in Context series</a>.</p>