About Me

Professional

As a Software Engineer, my job boils down to finding repetitive, slow, tedious, and sometimes confusing tasks and translating them into code. Code never gets tired, and always avoids the same mistakes. When I think of developers ‘Working Smarter, not Harder’, I mostly picture developers applying these same skills to their own tasks, their own problems. And when I think of projects grinding to a halt over time, seeing mean time to bugfix creeping up and up, month after month, I mostly picture developers who are unable, or unwilling, to sharpen their saws.

Writing

I’ve had many rewarding experiences working with progressive managers who understand this set of problems. Some of my writing here are informed by those conversations and interactions, and some of my writing is transcription of my feedback to them, to peers, and to other software leaders in my conversations and interactions with them.

I have done extensive work in team building, and the Software Development Lifecycle, including studying under and working closely with two published authors in the Kanban space.

Much of how I think is contained in my posts about Development and DX.

But some of my writing delves into how I learned to learn. Here are a few:

• Learning About Learning
• Float Glass
• The Cobbler's Children Have No Shoes
• Branching Out

Open Source

I am the creator of faceoff, a maintainer of node-config, bench-node, and a frequent contributor to prom-client.

Influences

For distributed computing, I was fortunate to find formal training available in my college curriculum, which I have only realized of late is not an option that was afforded to many of my peers. And while that makes sense for my older peers, I find this somewhat shocking for younger ones who started school after the dawn of this era of Cloud Computing.

For performance, introductory computer classes often struggle with consistent difficulty, and my study buddy and I made a game out of making the easier assignments more difficult by handling larger inputs or returning faster results. My early career featured a good deal of work in making fast applications in ‘slow’ languages.

For human factors, my attention turned from there to effectiveness over efficiency, and the ways in which poor design can make it challenging for users to achieve what they meant or needed to accomplish. Alan Cooper and Don Norman came onto my radar, and I had many chats with peers and acquaintances with forms of color blindness or other visual acuity limitations. While not an expert in accessibility, I know enough to avoid many common mistakes.

For data visualization, long ago in a discussion about how terrible a particular graph was, I was introduced to Darrell Huff’s book, “How to Lie with Statistics”, and that sent me down a rather long road, and probably was part of my influence in human factors in general. Edward Tufte, in addition to his books, used to write/blog online, and I followed him for many of his active years. And while I often wouldn’t otherwise include Richard Feynman in this particular list, his warning about how you are the easiest person to fool, overshadows all when I think of data analysis.

For Software Engineering, I particularly appreciate the works of Kevlin Henney, Michael Feathers, Martin Fowler, Kent Beck, Jim Highsmith (paradoxes versus problems) and a number of mentors I’ve had along the way, as well as many of the people I’ve mentored in turn. Teaching is a form of learning, and we often don’t understand our own ideas without having defended them.

Personal

I am rediscovering the importance and pleasure of Going Outside. I’ve spent an inordinate amount of time on Permaculture, which is at its heart Systems Thinking as applied to gardening. The banner picture is one I took a long time ago at the Japanese Garden at the University of Washington Arboretum.