In late January, I was at DevOpsDays NYC in midtown Manhattan to present Run Your @wn Email Server!

My abstract:

When we’re responsible for production, it can be hard to find room to learn. That’s why I run my own email server. It’s still “production” — if it stays down, that’s pretty bad — but I own all the decisions, take more risks, and have learned lots. And so can you! Come see why and how to get started.

With one command, install famously secure email software. A couple more and it’s running. A few more and it’s encrypted. Twiddle your DNS, watch the mail start coming in, and start feeling responsible for a production service in a way that web hosting can’t match.

Need consulting, coaching, and/or training in the NY metro area? I have some availability in the new year. Here’s what I offer; here’s what people say.

Where else can we meet up in the coming months? See my upcoming speaking engagements and also conferences and meetups I’m thinking about. Or invite me to speak at your company event!

Posted Fri Jan 25 17:53:41 2019 Tags:

Happy 2019! Another three months, another stable branch for pkgsrc, the practical cross-platform Unix package manager. I’ve shipped quite a few improvements for qmail users in our 2018Q4 release. In three sentences:

  1. qmail-run gains TLS, SPF, IPv6, SMTP recipient checks, and many other sensible defaults.
  2. Most qmail-related packages — including the new ones used by qmail-run — are available on most pkgsrc platforms.
  3. rc.d-boot starts rc.conf-enabled pkgsrc services at boot time on many platforms.

In one:

It’s probably easy for you to run qmail now.

On this basis, at my DevOpsDays NYC talk in a few weeks, I’ll be recommending that everyone try it.

Try it

Here’s a demo on Debian 9:

The commands I ran:

$ cd ...pkgsrc/mail/qmail-run && make PKG_RCD_SCRIPTS=yes install
$ cd ../../pkgtools/rc.d-boot && make PKG_RCD_SCRIPTS=yes install

On platforms with binary packages available, it’s even easier:

$ sudo env PKG_RCD_SCRIPTS=yes pkgin -y install qmail-run rc.d-boot

These improvements were made possible by acceptutils, my redesigned TLS and SMTP AUTH implementation that obviates the need for several large and conflicting patches. Further improvements are expected.

Here’s the full changelog for qmail as packaged in pkgsrc-2018Q4.


  • From mail/mess822:
    • The SMTP AUTH patch.
  • From mail/qmail:
    • The SMTP AUTH patch.
    • The qmail-smtpd half of the TLS patch.
    • The RCPTCHECK patch.
  • From mail/qmail-run:
    • Dependency on spamdyke.
    • Dependency on stunnel.
  • From sysutils/checkpassword and sysutils/checkpassword-pam:
    • The setuid bit.


  • mail/qmail:
  • mail/qmail-rejectutils:
    • To let qmail-rcptcheck run under qmail-spp, so that other RCPTCHECK programs can continue to run unmodified.
    • To deprecate qmail-qfilter-ofmipd-queue and qmail-qfilter-smtpd-queue in favor of qmail-qfilter-queue.
  • mail/qmail-run’s defaults:
    • To sslserver (from tcpserver).
    • To listen on IPv6 when available.
    • To auto-enable TLS for message submission, incoming SMTP, and POP3 (as well as remote delivery) when certs are in place.
    • To tag log entries with nbqmail/send, nbqmail/smtpd, etc. (inspired by Postfix).
    • To find tcprules in control/tcprules/* (and auto-migrate from /etc/qmail/tcp.*).
    • To rebuild outdated tcprules CDBs on startup.
    • To delay the SMTP greeting by 2 seconds (a simple anti-spam measure).
    • To check the RBL.
    • To check recipients using qmail’s delivery logic before accepting mail.
    • To record a Received-SPF: header.
    • To skip greylisting (if any) when SPF returns “pass”.
    • To record a Received: header with TLS protocol and ciphers.
    • To let users configure their own ofmipd address-rewriting rules.


  • mail/greylisting-spp:
    • For greylisting.
  • mail/qmail-spp-spf:
    • For SPF checks.
  • pkgtools/rc.d-boot:
    • For starting pkgsrc-provided services at boot on a variety of systems.
  • To devel/syncdir:
  • To mail/qmail:
    • The qmail-spp patch, for flexibly modifying SMTP behavior at runtime.
  • To mail/qmail-rejectutils:
    • Manual pages.
  • To mail/qmail-run:
    • greylisting-spp-wrapper, for whitelisting recipient addresses or whole domains, and optionally omitting IP address from greylisting’s tuples.
  • To mail/qmail and mail/qmail-run:
    • Cleaner uninstall, so people can feel comfortable trying qmail.
Posted Mon Jan 7 13:19:43 2019 Tags:

Yesterday I co-facilitated the Brooklyn instance of Global Day of Coderetreat. Last year, having just moved back to New York, I was disappointed we didn’t have a GDCR instance going on around here. (Adi Bolboacă, who was facilitating in Paris, did me the kindness of connecting me with a participant there for a remote pairing session.) So this year, when I saw Libby Horacek would be organizing and hosting at her company, I offered to try to make myself useful. I think it worked out.

We had an incredible #GDCR18 today! Thanks so much to @8thLightInc for sponsoring, to @schmonz for co-facilitating, and to the participants for being so enthusiastic, thoughtful, and engaged!

I opened the day by playing Presentation Karaoke with the GDCR-issued slide deck, adding a few details about the Code Retreat format, and suggesting three themes for the day: Play, Gratitude, and Community.


At work, we’re responsible for outcomes. We learn when learning is required to solve the problem efficiently (which turns out to be pretty often). Code Retreat is play. We know we’ll delete our code every 45 minutes, so we’re free to try a bunch of new ways of making it.

Kids play to build richer mental models of their world, to grow their explanatory and predictive powers, to acquire problem-solving tools to be synthesized as needed, to gain confidence in more situations, and to ride the positive feedback loop of following their enthusiasm.

As adults, even though we need these things just as much as kids do, we don’t play nearly as much. We need all the chances we can get. Code Retreat is a chance for us to play. If it goes well, we’ll find our thinking refreshed and our enthusiasm for programming renewed.


The name “Code Retreat” has the effect of encouraging people who wouldn’t want to spend a day at something called “Code Retreat” to self-select out. This is probably good. It means we can be pretty sure everyone here really wants to be here. But there are also plenty of folks who’d love to be here and can’t. Sometime today, take a moment to appreciate your good fortune in having the time, energy, freedom, and space to spend a day this way, your own choices in life that have opened you to this opportunity, and the actions of others that helped bring you to it.

My first GDCR arguably set me on my current career path, and inarguably instigated a great deal of learning.


I owe the state of my career in large part to many people who have been incredibly generous with their time, expertise, and reputation. It is the absolute least I can do to ask you to think about ways you can be generous with yours. I’ll do a little of this myself, too.

Today it’s not only a community we’re part of, but a community of communities. A Code Retreat can happen any time, any place; Global Day of Coderetreat is everywhere, right now. We’ll get to say hello to people all over the world (Vienna, London, Atlanta, Montreal, and Seattle, as it happened) who are doing what we’re doing because they care about what we care about.


The first session is for getting our brains familiar with the problem (Conway’s Game of Life) and thinking about pairing. Each of the sessions that follows imposes some constraint likely to change how we think about solving the problem. Of the many, many known options, we chose:

  1. TDD As If You Meant It
  2. Ping Pong Pairing
  3. Baby Steps
  4. Object Calisthenics
  5. Evil Pair

With Baby Steps, I was newly interested to hear whether people noticed that they succeeded more frequently on their first attempt to make a new red test green. My guess is they would. But it didn’t seem so, at least not that they noticed or reported. I still need to try test && commit || revert for myself.

At day's end


Going around the room, every single person had a new trick or tool or shortcut to share. (One had written a full page of new IntelliJ shortcuts to take home. Awesome.)

Kritul Rathod posted his key takeaways.

Someone who’s been pairing all day every day for years with dozens of people came away with a nuanced insight about pair dynamics.

At lunch, I had a conversation with someone who was interested in giving interns the sort of learning experiences I had on my recent coding tour. I certainly don’t know an answer, but I agree it’s important for more people to have experiences like these, and was able to give her some ideas.

After preaching that folks get involved in community-focused activities, I of course found out that more than a few already are, and well beyond my own involvement. Heartening. Maybe I didn’t need to have said anything about that. Or maybe someone else will turn out to have been newly inspired by the idea and the day.


Could this format for learning help your team? I’ll gladly facilitate a Code Retreat (or Legacy Code Retreat) for your company. I offer consulting, coaching, and training in the New York metropolitan area. Here’s what people say about their time with me.

Posted Sun Nov 18 11:57:54 2018 Tags:

On Thursday, October 25 in Manhattan, I presented a Mob Programming Workshop at the first ever joint meetup of CTO School and NYC Lean/Kanban.


Mob Programming brings the whole team together to one terminal, programmer and non-programmer alike, to improve quality and speed of building and deploying software. This group-process may feel counterintuitive, but provides many benefits such as increased empathy for other roles, fewer blocked programmers, and fewer bugs.

The CTO School and Lean/Kanban meetups will be partnering to bring programmers, product managers, and agile coaches to try our hands at solving a problem in small groups by thinking and coding together.

Wondering what this interactive, participatory session will be like? Amitai ran it this summer in Edinburgh on coding tour, and there’s video.

Join Amitai Schleier, a sometimes-programmer originally from the friendly midwest, as we solve a problem in small groups by thinking and coding together. If you want to, you can take a brief turn at the keyboard; if not, no biggie. When we’re done, we think you’ll have a new kind of feeling about code and coding. You might even want to pursue it further.

Three of the four mobs

We did TDD For Non-Programmers (not a coding exercise!) together, then split into four mobs to program FizzBuzz in Python at Cyber-Dojo. All four groups solved it!

Posted Thu Oct 25 22:02:09 2018 Tags:

After my fourth and final tour stop, we decamped to Mallorca for a week. With no upcoming workshops to polish and no upcoming plans to finalize, the laptop stayed home. Just each other, a variety of beaches, and the annual Les Festes del Rei En Jaume that Bekki and I last saw two years ago on our honeymoon. The parade was perhaps a bit much for Taavi.

Looking away

The just-released episode 99 of Agile for Humans includes some reflections (starting around 50 minutes in) from partway through my coding tour. As our summer in Germany draws to a close, I’d like to reflect on the tour as a whole.

Annual training

I’ve made a habit of setting aside time, attention, and money each year for focused learning. My most recent trainings, all formative and memorable:

I hoped Schleier, Coding Tour would fit the bill for 2018. It has.

Geek joy

At the outset, I was asked how I’d know whether the tour had gone well. My response: “It’s a success if I get to meet a bunch of people in a bunch of places and we have fun programming together.”

I got to program with a bunch of people in a bunch of places. We had fun doing it. Success!

New technologies

My first tour stop offered such an ecumenical mix of languages, tools, and techniques that I began writing down each new technology I encountered. I’m glad I started at the beginning. Even so, this list of things that were new or mostly new to me is probably incomplete:

In the moment, learning new technologies was a source of geek joy. In the aggregate, it’s professionally useful. I think the weight clients tend to place on consultants needing to be expert in their tech stack is dangerously misplaced, but it doesn’t matter what I think if they won’t bring me in. Any chance for me to broaden my tech background is a chance for a future client to take advantage of all the other reasons I can be valuable to them.


As Schmonz’s Theorem predicts, code-touring is both similar to and different from consulting.

When consulting, I expect most of my learning to be meta: the second loop (at least) of double-loop learning. When touring, I became reacquainted with the simple joys of the first loop, spending all day learning new things to be able to do. It often felt like play.

When consulting, I initially find myself being listened to in a peculiar way, my words being heard and measured carefully for evidence of my real intentions. My first tasks are to demonstrate that I can be trusted and that I can be useful, not necessarily in that (or any) order. Accomplishing this as a programmer on tour felt easier than usual.

When I’m consulting, not everyone I encounter wants me there. Some offer time and attention because they feel obligated. On this tour, even though some folks were surprised to find out their employer wasn’t paying me anything, I sensed people were sharing their time and attention with me out of curiosity and generosity. I believe I succeeded in making myself trusted and useful to each of them, and the conversation videos and written testimonials help me hold the belief.

Professional development

With so much practice designing and facilitating group activities, so much information-rich feedback from participants, and so many chances to try again soon, I’ve leveled up as a facilitator. I was comfortable with my skills, abilities, and material before; I’m even more comfortable now. In my tour’s final public meetup, I facilitated one of my legacy code exercises for three simultaneous mobs. It went pretty well — in large part because of the participants, but also because of my continually developing skill at designing and facilitating learning experiences.

As a consultant, it’s a basic survival skill to quickly orient myself in new problem spaces. As a coach, my superpower might be that I help others quickly orient themselves in their problem spaces. Visiting many teams at many companies, I got lots of practice at both. These areas of strength for me are now stronger, the better with which to serve my next clients.

On several occasions I asked mobs not to bother explaining the current context to me before starting the timer. My hypothesis was, all the context I’d need would reveal itself through doing the work and asking a question or two along the way. (One basis among many for this hypothesis: what happened when I showed up late to one of Lennart Fridén’s sessions at this spring’s Mob Programming Conference and everyone else had already read the manual for our CPU.) I think there was one scenario where this didn’t work extremely well, but my memory’s fuzzy — have I mentioned meeting a whole bunch of people at a whole bunch of workplaces, meetups, and conferences? — so I’ll have to report the details when I rediscover it.

You can do this too, and I can help

When designing my tour, I sought advice from several people who’d gone on one. (Along the way I met several more, including Ivan Sanchez at SPA in London and Daniel Temme at SoCraTes in Soltau.)

If you’re wondering whether a coding tour is something you want to do, or how to make it happen, get in touch. I’m happy to listen and offer my suggestions.

What’s next for me, and you can help

Like what I’m doing? Want more of it in your workplace?

I offer short, targeted engagements in the New York metro area — coaching, consulting, and training — co-designed with you to meet your organization’s needs.

More at


Yes, lots.

It’s been a splendid set of privileges to have the free time to go on tour, to have organizations in several countries interested to have me code with them, and to meet so many people who care about what I care about when humans develop software together.

Five years ago I was discovering the existence of a set of communities of shared values in software development and my need to feel connected to them. Today I’m surer than ever that I’ve needed this connection and that I’ve found it.

Thanks to the people who hosted me for a week at their employer: Patrick Drechsler at MATHEMA/Redheads in Erlangen, Alex Schladebeck at BREDEX in Braunschweig, Barney Dellar at Canon Medical Research in Edinburgh, and Thorsten Brunzendorf at codecentric in Nürnberg and München. And thanks to these companies for being willing to take a chance on bringing in an itinerant programmer for a visit.

Thanks and apologies in equal measure to Richard Groß, who did all the legwork to have me visit MaibornWolff in Frankfurt, only to have me cancel at just about the last minute. At least we got to enjoy each other’s company at Agile Coach Camp Germany and SoCraTes (the only two people to attend both!).

Thanks to David Heath at the UK’s Government Digital Service for inviting me to join them on extremely short notice when I had a free day in London, and to Olaf Lewitz for making the connection.

Thanks to the meetups and conferences where I was invited to present: Mallorca Software Craft, SPA Software in Practice, pkgsrcCon, Hackerkegeln, JUG Ostfalen, Lean Agile Edinburgh, NEBytes, and Munich Software Craft. And thanks to Agile Coach Camp Germany and SoCraTes for the open spaces I did my part to fill.

Thanks to Marc Burgauer, Jens Schauder, and Jutta Eckstein for making time to join me for a meal. Thanks to Zeb Ford-Reitz, Barney Dellar, and their respective spice for inviting me into their respective homes for dinner.

Thanks to J.B. Rainsberger for simple, actionable advice on making it easy for European companies to reimburse my expenses, and more broadly on the logistics of going on European consulting-and-speaking tours when one is from elsewhere. (BTW, his next tour begins soon.)

Thanks all over again to everyone who helped me design and plan the tour, most notably Dr. Sal Freudenberg, Llewellyn Falco, and Nicole Rauch.

Thanks to Woody Zuill, Bryan Beecham, and Tim Bourguignon for that serendipitous conversation in the park in London. Thanks to Tim for having been there in the park with me. (No thanks to Woody for waiting till we’d left London before arriving. At least David Heath and GDS got to see him. Hmph.)

Thanks to Lisi Hocke for making my wish a reality: that her testing tour and my coding tour would intersect. As a developer, I have so much to learn about testing and so few chances to learn from the best. She made it happen. A perfect ending for my tour.

Thanks to Ryan Ripley for having me on Agile for Humans a couple more times as the tour progressed. I can’t say enough about what Ryan and his show have done for me, so this’ll have to be enough.

Thanks to everyone else who helped draw special attention to my tour when I was seeking companies to visit, most notably Kent Beck. It really did help.

Another reason companies cited for inviting me: my micropodcast, Agile in 3 Minutes. Thanks to Johanna Rothman, Andrea Goulet, Lanette Creamer, Alex Harms, and Jessica Kerr for your wonderful guest episodes. You’ve done me and our listeners a kindness. I trust it will come back to you.

Thank you to my family for supporting my attempts at growth, especially when I so clearly need it.

Finally, thanks to all of you for following along and for helping me find the kind of consulting work I’m best at, close to home in New York. You can count on me continuing to learn things and continuing to share them with you.


Posted Sat Sep 15 09:05:42 2018 Tags: