Posts

Documenting Repairs # Life is busy. Outside of the typical workday, a recurring time investment of mine revolves around repairing mechanical things. Things that are not of the software world, but things that naturally decay and fail based on environmental factors. As we age, it is easy to accumulate more things, which require maintenance or diagnosing to repair. This spawns growing TODO lists, and scheduled reminders on things to inspect and replace. While this blog has been a place where I have previously shared notes and thoughts about software development, I thought I would start adding notes on random things I have had to diagnose or repair. Some of these things are quite simple and thought it would be of value to share as I couldn’t find anything online and answered my problem.

DevOpsDays KC returned this week since 2019! It was awesome to see so many faces I hadn’t seen in years. It was a nice two days, at the Madrid Theathre, local food trucks for lunch, and great discussions.

I wanted to discuss a term that I found memorable recently: ground truth. It resonated with me when I first heard it, as I’m routinely in discussions where we are articulating technical problems and how we plan to solve them. This act of describing the problem to an audience with varying levels of understanding can be challenging. We often have limited time in how we bring people to shared understanding. This restricts our ability to sufficiently describe all the history and contributing factors of that problem. By having a close understanding to what is occurring, the better we can articulate this understanding with others. In this post, I will dig into the term “ground truth” and some considerations in the words we use when sharing this understanding.

Over the last year, I have found myself trying to establish new routines. With working more from home, I wanted to make subtle changes in different aspects in my life. For example, I previously used to enjoy podcasts on my drive to work. Now, I focus on listening to these while I do chores around the house. In this blog post, I will share how I found an effective way of establishing a new habit through something simple which happens to have science behind it. I hope this is helpful if you are looking at ways to be effective in new habit building too.

These last two days were KCDC in Kansas City for me. This was my first in-person developer conference since late 2019. While there were still restrictions (wearing masks), it was a fantastic time to see people again. I was able to meet up with past colleagues and discover new people at lunch and through talks, an experience that immediately filled a void in my life. While I have participated in other virtual conferences since the pandemic started, the in-person session was a great experience. Everyone I talked to also shared the same feedback.

Diagraming is a powerful way of communicating ideas to others. In this past year, I have found how much I have missed the time of just working with a group and using a whiteboard to convey our ideas. In the past few months, I have referenced past diagrams or shared recent examples which included a few properties in the diagram that I believe are useful. In this short blog post, I will share some thoughts on the power of diagrams which use simple universal symbols.

Earlier this year, I shared a communication approach I was trying with my team, called a CHANGELOG. I have been applying this approach for the past six months and have learned a few lessons along the way. This post will recap some of these lessons learned, so it may better inform you the benefits and the costs of applying it.

Two years ago, I worked on a guide that I called the Hitchhiker’s Guide to Meetings. This guide highlighted many of the lessons I had learned over the years involving meetings at work. I have found having this guide to be a helpful reminder on things to continue to practice with the goal of optimizing time in meetings. With this year’s change of virtual meetings being the primary means of engagement, I wanted to make an update to this guide to highlight some of these newer lessons with the virtual format.

I recently listened to a talk that reminded me of some core lessons on how we can view “human error,” and how it can help us both with our work and personal lives. From that talk, the content from The Field Guide to Understanding ‘Human Error’ by Sidney Dekker is referenced. This book continues to grow as the cornerstone reference on building a safety culture. I wanted to share a short blog post as a refresher on this content, and how we can improve our systems by not looking at “human error” as the cause, but as the symptom of a larger problem.

Introduction # I recently tried a new experiment at work which I’m calling “The CHANGELOG.” My goal with this experiment is to improve the communication within my team and with all the product groups I routinely work with. I thought it would be helpful to share some of my notes here on what and why I decided to do it.

Time is a one of your most valuable assets. As engineers grow with their skills and past contributions, they get invited to participate in more meetings within their day. These meetings get scheduled in time slots that show as available on their calendar, or sometimes even when they are already shown as busy - posing as a conflict. This can commonly result in their day being broken down into many different meetings, with small windows of free time on their schedule. These windows of “free time” are then utilized as their primary time to work on the problems they were planning to solve for that day. This can often result in frustration, where people are do not feel like they are getting enough time to work on their assigned problems, but rather attending meetings that may or may not relate to their problem of interest.

This was my first time attending QCon, and I was really impressed with the quality of the conference. I have been a long time consumer of content on InfoQ, so it was great to be there in person and meet more practitioners that are working on interesting problems. This blog post will be a brief recap of my experience and the notes I took from the talks I attended.

The Talk # Back in June, I gave a talk at Cerner’s DevCon conference on decision making, called: Decisions: The Pursuit of Options. The talk has been published on YouTube for your viewing pleasure:

This post is the second part of my series that breaks down my guide on decision making. I wanted to briefly share our natural tendency to favor novelty and how that can introduce challenges when assessing technology in our systems. The goal is to ensure we are aware of this attraction, understand its power to feed learning, and to make sure we balance our motivations with safe introductions of technology.

I recently built a guide on decision making, which included several different elements on how we form ideas and decisions. The purpose of this guide was to highlight common areas that typically cause strain on us humans when we are in the act of technical decision making. I plan to author another series of blog posts, that take each part of this guide, and expand it with some added dialogue. For this first post, I’m going focus on Murphy’s Law and its influence on our ability to make technical decisions.

Over the past few weeks, I have been on a hiatus from my normal work at Cerner. During this time, I have been working on several home repair and improvement projects. While I have been doing this work, I was reminded of something that I like to do which helps illustrate progress achieved in projects. In this short post, I will share a few things that I think are important to capture which leverage the power of contrast to highlight progress. By sharing the story of progress in your projects, you can help connect team members to purpose and their larger impact.

Last week, I had the honor of attending a preschool class to share the topic of software development. In order to explain this subject matter, I decided to prepare a few items and have them paired with a theme. I thought it might be worthwhile to share what I used, as it seemed to work well, and I found it exciting to see young minds interested in the topic. Since this was going to be a short exercise (20 minutes of their time), I wanted everything to be simple with no electronic screens. As a result, I built some quick posters that I could use to illustrate my points, a Beaglebone computer so they could see the internals, and a craft that would connect the topic to something they could apply with their own creativity.

Here is a short post on the importance of thanking people, and a common way I achieve this through email. This is also the final part of my trilogy on guidance with email (Email Trilogy blog series).

I previously posted a set of design principles about building presentation slides. In this post, I shared how you can improve the effectiveness of your visual aides, by authoring your own images. This post is going to be a simple starter of how I began including images in my presentations and notes.

I previously posted a short set of notes of how I apply my simple process of digesting emails. However, I think there are some other important rules of when to produce email. In this short post, I will share a couple things to keep in mind before you send an email.

The pptx Language # A few months ago, I was speaking with a senior member of our engineering leadership team, and he stated that the only language he has been coding in lately, is pptx (referring to the file extension of Microsoft PowerPoint). While this statement was delivered with humor, I found it to be true with many engineers. As they grew with experience, so did the amount of time they spent giving presentations. By presentations, I simply mean sharing or pitching their ideas to larger audiences (their team, group, organization, or even the entire company). With this increase of sharing ideas, they many times are also working on presentation material (i.e. slides), which is often considered an unpleasant activity. I have noticed this in my own career, where I am routinely spending time building presentation material, which doesn’t deliver the same feeling of joy as compared to writing code. However, as I have spent a extensive amount of time both building presentations and witnessing them, I find these to be a powerful moment where you can help inform and learn from your technical ideas.

Over the course of my engineering career, I have seen and participated in different types of team traditions. Team traditions can help build the identity or brand of a team, which is generally helpful in supporting the overall health of the team. By having a team which has a unique and strong identity, it many times indicates a strong connective bond between the team members. As the lifespan of a team grows over time, traditions can continue to form which further crystalize these unique elements of their identity.

As I talk with other engineers, I have found a common question that typically arises on “How do you make time to stay current on technology?” Other flavors of the same question are, “What podcasts do you listen to?”, or “How do you find technical articles that are good to read?” While I seek these same things, I find that many times people do not often talk about how can they optimize how their brain can process the things they have been learning. Meaning, not where can I find yet more information, but how can I optimally use this information in my life. In this short post, I will share something that has worked for me in my life, which I didn’t intentionally seek, but found that it produced an optimal setting for me to reach a creative thinking period in my mind.

As I have explored ways to be more productive, I generally find that everyone has a way in which they process their emails. Given that email is such a common element of communication that everyone deals with, and it has been around for a long time, there are generally several different ways of optimizing this continuous amount of content. Here is my process of how I manage my email at work, which I realize is quite simple. Perhaps you can share with me how you do it better, and I can further improve my approach: