We write about different projects and topics on this blog. But have you ever wondered what it is like to work, support, and write about all those projects while also being a father of two children? Well, it is “fun” ;)
Before we start, let me add just a quick notice. This post is a bit different from what we usually publish on this blog. It is a bit more personal and almost certainly contains an opinion or two that not all Steampunk members agree with. But that is perfectly fine since they have the right to be wrong ;)
Playing the father role
Being a father is what determines the schedule of all other activities. If I need to take my kids to school and kindergarten because my better half is working the morning shift, I wake up around seven in the morning. I make breakfast for youngsters, do my best to get at least one non-pink piece of clothing onto my daughter, and make sure my son’s kick scooter is working. And we are off. On such days, I usually start working around nine in the morning.
When my wife is working the afternoon shift, I usually wake up around five in the morning and do my best to get the majority of work done by the two in the afternoon when I need to go and pick up the kids. I then spend my afternoon playing with kids outside and reading stories.
I do my best to keep my kids away from computer and smartphone screens. And as you might imagine, this is quite a challenge. We do not own a TV, so at least I do not have to worry about that ;) I do allow kids to play a game for half an hour or watch a cartoon/documentary, but that is about it.
Writing code
Up until recently, I spent my mornings writing code for various projects that the Steampunk team is developing. Most of the code I wrote is automation-related:
- Opera aims to become a TOSCA-compliant orchestrator.
- AWS Ansible Collection is our attempt at creating a set of Amazon Ansible modules and plugins with a consistent API and well-defined behavior.
- The Sensu Go Ansible Collection makes automating all aspects of Sensu Go using Ansible a breeze.
- We have quite a few projects that deal with the bare metal provisioning and Redfish API.
Creating software that solves a specific problem and getting a thank-you from an end-user is what motivates me. Talking to a real person via the IRC, Slack, or GitHub issue is something that I enjoy almost too much ;)
Because most of our projects use various open-source components, interacting with the upstream community is a must. In practice, this means that I have at least three chat applications opened at any time:
- IRC client for talking all things Ansible.
- Slack and Gitter for interacting with people that are too young to know what IRC is ;)
- Microsoft Teams for company-wide communication.
To keep me sane, I disabled all notifications from the applications above. I found the hard way that this is the only way I can get some work done without being interrupted every couple of minutes. Any now you know why my answers are always late ;)
One particularly important aspect of my community participation is filling bug reports and submitting patches for problems I found in upstream projects. I try my absolute best to provide as much information about the issue as possible when reporting problems. Why? Well, let us talk about my next role.
Being a grumpy maintainer
Because most of our work involves working in fast-moving ecosystems, we often need to create custom tools to get our job done. And when we release those tools to the public, someone needs to take the maintainer’s role. I ended up being a maintainer of a Ruby Redfish API client and an Ansible plugin documentation extractor (among other things).
When I am wearing my maintainer hat, my primary task is to balance the feature growth with the increase in the maintenance burden. Adding a well-tested feature is usually not problematic since those tend to address a well-defined use case. What I do require is that the pull request author accurately documents the use case.
Adding bypasses for bugs in the components that software interacts with is entirely another matter. By default, I reject such detours and instruct users to file an issue with the upstream developers. But I am always open to negotiation.
Triaging and fixing bugs is another activity that I probably enjoy more than I should. Being a detective, a victim and a murderer at the same time is super fun ;) But before I can start solving the issue, I need a proper bug report that contains more information than “The thing does not work. You suck.”
All in all, I find that being an open-source project maintainer is not the worst thing that can happen to a person. Having a thick skin helps a lot, and being paid to do it helps even more (thank you, Matej, Gregor, Gregor, and all other bosses I had over the years).
Educating the community and customers
I was writing semi-decent blog posts and manuals about various things for as long as I can remember. Why? Because I found out that explaining things to others forces me to learn about the subject in great detail. And to become internet famous, which I failed miserably ;)
Gradually, my technical explanations and demonstrations found its way into more customer-oriented processes of the company. And then (I am not sure when exactly), my title changed from engineer to evangelist.
I must admit that I was not entirely sure if being an evangelist is what I wanted to do. But during the last few months, I learned that being an evangelist is just debugging on a different abstraction layer. It also helps that I am still allowed to solve a real bug from time to time ;)
So, what do I do as an evangelist? Right now, I am mostly explaining what benefits Ansible and its commercially-supported extensions bring to companies, focusing on the technical aspects. I also do my best to raise awareness about the benefits of high-quality Ansible content. The current situation could be worse, but it could also be much better.
Oh, and I am also working on the content for the upcoming AnsibleFest. I was hoping you could keep your fingers crossed. Thanks ;)
Time for bed
There are a few other things that I help with, like using my analytical brain to streamline our internal processes and write automation helpers using VBA. But I will avoid the details here before any of my bosses starts asking questions ;)
Congratulations on making it to the end of the day with me. I hope you found something interesting in my babblings. I would be very much interested in reading about your workday on Reddit.
Now if you will excuse me, I have a release to make ;)
