Reflections on 10 Days of Sharing Ugly Commands

As someone who spends a lot of time with #kubernetes technology and users, I recently embarked on a 10-day journey to share ugly and hopefully helpful commands with the #k8s community. It was an interesting experience filled with valuable lessons and allowed me to connect with like-minded individuals. In this article, I will reflect on my process, challenges, and the outcomes of the #uglycommandparty.

The Guidelines: Sharing the Good, the Bad, and the Ugly

To keep things interesting and practical, I set some guidelines for myself. Each day, I aimed to share a new command that met specific criteria:

1. Freshness: Share something new each day, avoiding repetition, and pulling from an existing library
2. Compatibility: The commands had to be compatible with the two most common shells, bash and zsh, ensuring accessibility for users.
3. Simplicity: I focused on one-liners, turning complex scripts into ugly oneliners (largely due to how RunWhen Local ingests and presents commands).
4. Daily commitment: I shared one new command per day for a total of 10 days.
5. Integration: All commands had to be integrated into our open-source troubleshooting commands library, enhancing its value.

The Process: From Inspiration to Distribution

Throughout these 10 days, my time was allocated to different activities, not all of which went smoothly. Mistakes were made. Lessons were learned. Time was spent with little return.

1. Seeking Inspiration

Inspiration played a crucial role in this project, and it came from various sources. I found inspiration in my daily work experiences, solving real-world problems. Stack Overflow and Reddit were also valuable platforms for discovering issues that I could address. Sometimes, ideas would emerge while my mind danced to trash TV in the background or in a dreamstate.

Optimistically trying to maintain a smooth flow of content, I tried to stay a day ahead, working on the command for the following day while publishing the current day's command. Towards the end, this proved challenging due to conflicting priorities and I found myself scrambling to meet my self-imposed deadlines. Nevertheless, I managed to adapt and deliver valuable commands on time, even if it meant some late-night efforts - except day 10, which was frustratingly one day late.

2. Setting Up Test Scenarios

To validate the effectiveness of the commands, I dedicated 10-20 minutes each day to set up test scenarios. Using a permanent sandbox GKE cluster, I deployed slightly broken manifests that replicated common issues the commands would help resolve. This process ensured that the commands were practical and reliable.

3. Script Creation and Testing

Scripting was an interesting dance between different elements: two shells, my own knowledge, and the assistance of ChatGPT. I leaned on ChatGPT for initial input (it’s pretty good at jq), but let's just say it wasn't always the most reliable source. I often found myself fixing mistakes, rewriting parts of the script, and refining prompts based on what was returned. It was a delicate process that required patience and persistence.

The scripting process usually took an hour or two, depending on the complexity of the command. Once I felt confident in the script's functionality, I tested it with different scenarios to refine its format and output (from multi-line to single-line commands). I then ensured cross-shell compatibility by testing the commands in both zsh and bash, making any necessary adjustments. This phase demanded patience and sometimes required seeking outside help from platforms like Stack Overflow.

4. Integration with RunWhen Local

To optimize the commands for practical use, I integrated them into RunWhen Local. This involved replacing specific parameters with variables and incorporating appropriate escape characters for successful rendering and execution. If it was an entirely new “group of commands”, then this also required some additional rule generation that is built into the RunWhen Local container image (which will be phased out in future releases). This process becomes pretty straight forward the more you do it.

5. Writing and Distributing the Content

The final stage involved crafting articles and sharing the content with the community. While writing articles on LinkedIn, I encountered a few challenges with code formatting. However, once resolved and after linking relevant GitHub gists, the process became smoother. I created (engaging?) memes and utilized a template I had prepared. Adding a paragraph of context to each article helped add some of the “why”.

When sharing the content on LinkedIn, I discovered some useful practices. It was crucial to write an article about the command, followed by distinct content for each group - focusing on fresh summary of its contents. I learned that simply reposting without additional content reduced the chances of survival within the groups. As a result, I am making an effort to vary the post content, which significantly improved engagement.

Additionally, I explored Medium as a platform for sharing my work. Contrary to my initial long-held and incorrect assumption, I discovered that content could be freely accessible, regardless of subscription status. Medium's established style guidelines helped structure my articles effectively. Within a day of my first post, I contributed my work to itnext.io, broadening its reach to a wider audience.

Although Reddit wasn't an ideal platform for sharing this kind of content, I learned valuable lessons about community engagement. Some users provided constructive feedback, while others were less pleasant. I realized the importance of understanding the platform's purpose and tailoring my interactions accordingly. It was a learning experience, and will work towards more meaningful engagement with the Reddit community in the future.

The Metrics: Measuring Success

Success can be measured in various ways, and the metrics I tracked shed light on the impact of my efforts. Here are the key statistics:

• Timeline: The project spanned 10 work days from start to finish.
• Cumulative Impressions: Across articles and posts, I achieved a 2.4% increase in followers, with a notable impression-to-article-view ratio of 17.6% (3616 impressions, 557 views). These are very small numbers….but…
• Direct Reach Outs: Four individuals reached out, indicating that they found the commands useful and wanted to engage further. This feels like a small number, but is high in quality. These connections, in my opinion, were worth the effort and demonstrate the value generated through sharing and collaboration.
• Time Invested: In total, I invested approximately 60 hours in creating, refining, testing, and writing about the commands. It was a significant commitment that proved worthwhile - but I hope the next round takes less time given the lessons learned.

Lessons Learned: From Time Management to Content Creation

Throughout this journey, I learned valuable lessons that will guide future sharing efforts. Here are some key takeaways:

• Time Commitment: I was surprised by the amount of time required for both finding inspiration and implementing the commands. This insight will help me better manage my time in future projects.
• Content Creation: Memes proved to be effective in capturing attention and generating interest (or just kept me entertained?). Going forward, I aim to explore more content formats, such as flow diagrams, to provide greater value and clarity.
• Platform and Distribution: LinkedIn, while not ideal for sharing code, can be leveraged effectively. Writing articles, crafting unique content for each group, and avoiding blind reposts were key strategies for maximizing engagement. Medium, on the other hand, offered a straightforward integration process and helps widen the exposure.
• Reddit Engagement: Reddit's purpose differs from other platforms, and I have learned that it may not be the best channel for sharing this type of content - or at least in this manner. Understanding the community and purpose is crucial for successful engagement.
• Energy Commitment: It took a lot of energy each day to support this effort, and was noticeable across my daily actions. I’ve taken a much needed week off from the activity before continuing on with the next cohort of one-liners.

To wrap up this reflection, my 10-day journey of sharing commands with the Kubernetes community was an interesting and educational experience. It taught me the importance of dedication, adaptability, and effective distribution. The metrics indicated some measure of success, but more importantly, I connected with individuals who found value in this effort. As I continue on this path, I will carry the lessons learned, aiming to contribute meaningfully while embracing that the next wave will carry new lessons.