essay

Saying yes is easy—at first.

It makes you feel better. And it makes you feel like you can do anything! And the person you're saying yes to also gets a happy feeling because you're going to do something for them.

Saying no is hard. It's an admission you can't do something. And worse still, you're disappointing someone else who wants you to say yes.

But here's the thing: none of us is a god. We're people. We have a certain amount of mental resources.

Some people are kind of crazy and can do a lot more than you or I can, but nobody can do it all. And sometimes you can burn the midnight candle for a little while, but you're just building up debt. Every 'Yes' is a loan you have to pay off.

I watched TheOdd1sOut's How to Find Inspiration¹ and remembered the most important lesson I learned from my high school English teacher:

Short is good. Short is hard.

The teacher² didn't exactly put it like that. But he harped on something nobody else did: writing concisely.

Every week we would read a work of American literature. And every Friday we'd turn in a one-pager encapsulating our knowledge of the book. I was an odd duck for how much I enjoyed the game: no playing with margins or font sizes. I had to cram an entire book into one page, double-spaced, with 1" margins, a title line, and a byline.

I remember spending Thursday nights honing my text, usually down to around 500 words. We would get a slight bonus for conveying more with fewer words.

That's surprisingly difficult for teenagers conditioned to churn out a specific word count. TheOdd1sOut commiserates:

Or: Why can't you just merge my ten-line PR already?

I maintain over 200 open source projects. Apparently (this is news to me) I am ranked in the top 200 GitHub users by followers, and there are 18,000 forks and 42,000 stars across my repos.

On an average day, I see between 50-100 emails across my repositories for issues and pull requests, and I filter those down to about 5-10 that I deem worthy of a personal follow-up.

I merge between 5-10 Pull Requests per month, and commit new code or fixes around 166 times per month.

I'm one maintainer, in a tiny corner of the Internet, maintaining a small but broad set of projects from Ansible roles for infrastructure automation to a few small but still-used PHP and Node.js libraries.

Dealing with burnout

There have been a few times I've burned out. That's typical for many maintainers. You either learn coping strategies or burn out completely, and in the best case end up a woodworker or farmer. At least that's what I see most of the time.

Besides being a software developer and photographer, I take a deep interest in spaceflight and love reading about the history and development of air- and spacecraft, with a special focus on early space program development.

A few books I've read in the past couple years have gone beyond being interesting just for their historic content—they gave me a lot of ideas to reflect on in relation to my approach to software development, especially what I'd term 'professional' software development (vs. hacking something together for fun, or churning out brochureware sites or cookie-cutter apps).

One book in particular, Failure is Not an Option (by Gene Kranz, director of Mission Control during NASA's early days into the Apollo era), illustrates high-performing teams operating well under pressure and with high stakes.

There's been a ton of writing about OSS stewardship, sustainability, funding, etc. in the past year, along with story after story of burnout. In this time, I've become very strict in my open source maintainership:

Unless it's generating income, it's for me and I'm not going to spend more than a couple hours a month looking at it—if that.

There are a number of projects that I maintain, which I'm not actively using on money-generating projects. I don't normally touch or even look at the issue queues on these projects until a CI test fails, or unless someone who contributes to my Patreon or GitHub supporters—or who I know from previous contributions—pings me directly about them. Every now and then I'll run through the list of PRs and merge a bugfix or docs fix here and there, but that only happens maybe once per repository per year.

This blog post contains a written transcript of my NEDCamp 2018 keynote, Real World DevOps, edited to match the style of this blog. Accompanying resources: presentation slides, video.

I'm Jeff Geerling; you probably know that because my name appears in huge letters at the top of every page on this site, including the post you're reading right now. I currently work at Acquia as a Senior Technical Architect, building hosting infrastructure projects using some buzzword-worthy tech like Kubernetes, AWS, and Cloud.

It's been just over two weeks since the big one; I had my colon removed and was given in its place an ileostomy, which dramatically changes the way I go number two.

As with most stages of my Crohn's journey, I thought I'd write up this blog post with my experiences—and maybe a liiiiittle sarcasm thrown in—for the benefit of anyone else going through a similar situation.

Bowel Prep

My doctor requested a full cleanout for this surgery, I guess so he wouldn't have to deal with stinky poo while yanking out my guts, and I obliged. Unfortunately, for most Crohnies or IBD patients who have to get a colectomy, they're already not in a great place prior to surgery, and neither was I. I was already underweight and not nearly 100% energy-wise, so having to empty out (same prep as for a colonoscopy) meant I did as much as I could to stay hydrated and not faint.

As a Geerling, when a situation goes upside-down I turn to humor. If you need evidence, go read The Joy of Crohn's. Back? Good.

Take today, for example. Day 3 stuck in a hospital due to complications from having Crohn's disease.

I'm in a bit of an awkward situation: I'm mostly fine, and I can walk around, do most things normally, talk, eat, etc. But I have this one little problem: My poop (due to having Crohn's disease) has gone thermonuclear, and it's now affecting my health.

Apparently I have this thing called CMV Colitis. It's one of a number of ailments that either exclusively affects immunocompromised patients (generally, people with IBD, Crohn's, Lupus, etc.), or makes said patients waaaay worse off than your average person. Like, nearly fatal instead of a low grade fever!

Anyways, picture an average week in a Crohnie's life:

Recently I received an email from an IT student asking the following: I recently submitted a pull request to one of your open source projects on GitHub. What can I do to get this pull request merged? The answer below may sound somewhat like a cop-out, or harsh (especially considering it was to a starry-eyed student trying to dip his or her toes into the waters of open source software contribution)... but I've found that honesty is the best policy, and the best way I can maintain good OSS software is to guard my (limited) time for OSS work vigilantly, and try to not allow sentiment force the merge of any kind of code, no matter how simple/small the change. Here is my reply:

Thanks for the email! I maintain over 100 different open source projects on GitHub, all in my spare time (which can be hard to come by with 3 kids, a full time job at Acquia, and a few other hobbies!). I spend a few hours per quarter on any given project. Some of the more popular projects have dozens of issues, PRs, and new comments that need to be read through to figure out what I need to these few hours on.

After I posted my presentation slides, transcript, and video from my presentation Don't drown in your open source project!, I received two follow-up questions (1, 2) on Twitter that I thought deserved a little better response than what I could do in 140 characters. So, here goes:

Do you ever abandon old projects? Thoughts on right/wrong ways?

Yes, in fact I've abandoned probably a dozen or so projects. The simplest examples: