Communicate to Collaborate

One of the most difficult aspects of any job is working with someone who
communicates through conflict rather than collaboration. They communicate in absolute terms and it may feel that there is no room for discussion or cooperation. This frequently occurs in the dissemination of policy changes from a person in a position of authority or a peer when providing feedback.

The immediate reaction of the recipient of this message is to become defensive and resist. They recipient may feel resentful, frustrated, and respond by lashing out or countering the message they are receiving. The conversation becomes a conflict instead of a collaboration.

Working through a conflict is much more challenging than having a collaborative discussion. Conflict cannot always be avoided, but it should never be the preferred path.

Communication through collaboration will be a much more successful path. This requires more thinking, emotional intelligence, and tact from both parties. The conversation will create a shared understanding as the parties seek to understand each other’s perspective. A resolution will be reached only through this shared understanding. Otherwise, resentment lingers and conflict surfaces.

When communicating at work, or anywhere for that matter, ask yourself how you are working to collaborate and try to actively avoid generating an unnecessary conflict.

Prompt engineering as introduction to AI

I had only read articles and listened to a few podcasts about AI, ChatGPT, and other machine-learning algorithms prior to this past month. I was able to get hands-on experience with ChatGPT 4 while participating in an AI hackathon for work.

Our hackathon idea focused on using ChatGPT to transform a multi-input form entry into a single text input. We would use ChatGPT to extract context and relationships from the text and automatically enter these fields and create relationships in the system for the user.

I was skeptical of ChatGPT’s ability to extract this information. I thought that it would be able to categorize the input, but I was unsure it could extract all the required metadata that was normally tediously entered by the user. I was blown away by what it was able to understand.

ChatGPT operates in a conversational manner. The application provides a prompt on how ChatGPT should respond when given an input. This includes a system message instructing ChatGPT on how it should operate. This is followed by pairs of example inputs and outputs where the input is supplied by the user and the output by the ChatGPT “assistant”. These examples are used to instruct ChatGPT what sort of output is expected for a given input.

Programming typically involves writing high-level code in a procedural way to get the computer to produce a desired result. There are very clear rules on what this code should look like and what it can do.

Prompt engineering is an open-ended narrative. Producing these prompts was a back-and-forth exercise in trying to use prose to instruct a computer how to operate. I had no experience in using ChatGPT so I began playing with different writing formats, styles, and commands to get the desired output. It just felt… fun.

With surprisingly little effort, ChatGPT was able to recognize dates and times, extract the names of people and businesses, infer relationships from the context of sentences, and connect a location to an explicit timezone. It was truly impressive. The majority of the development time spent on our project was on application code calling ChatGPT and taking actions based upon its results. It was impressive.

I left the hackathon with a concrete understanding of a use case that could directly benefit our users. I saw what other teams built for their projects and other ways it could be utilized in different contexts. I feel excited that it can be used to actually help people and confident in my ability to successfully leverage AI.

We plan to share our project results as a way to show what ChatGPT is capable of and hopefully spark some ideas for other potential uses in the organization. Maybe it will get picked up as a feature to be implemented soon!

Step outside your comfort zone

Change is scary. At least, that is what my brain thinks when I think about change. When pushed too far outside my comfort zone I become anxious. Self-doubt creeps in and I tell myself I should not have done something differently or tried something new. My brain lies. Usually, anyway.

This past month I had the opportunity to participate in a AI hackathon for work in Budapest. I signed up without hesitation. AI technology has seemingly exploded within the past six months and has become accessible to those with a basic understanding of it as I had. This would be a great opportunity to learn about AI and learn directly from colleagues using it in production. In addition, my manager is in Budapest and we collaborate with folks in that office so it would be great to connect and network with them.

As the date approached, that resistance to change began to set in:

  • Worry about traveling to a new country where I did not speak the language.
  • Fear that I was not good enough to fit in and participate.
  • Concern that we would not be able to deliver our project and I would be exposed as an imposter.

I was also excited. I was being joined by great co-workers. I wanted to learn more about AI after seeing its applications that truly astounded me. I wanted to travel somewhere that I did not know the language. I wanted to try and build something, even if it was bad or I failed.

My brain lies.

I had a fantastic time. I met colleagues and was able to connect with them in ways that would not be possible strictly through video. I had fun exploring with teammates and will have fond memories of spending time together on this trip. We stumbled at the start of our application building but worked together and had fun building something that actually worked! We learned and grew. Even if we had failed it would have been a great learning experience.

Step outside your comfort zone and try new things every now and again. That is the way we learn and grow. The end result is usually a better you, whether or not it worked out exactly the way you planned.

That Conference 2018


I was able to to attend That Conference 2018 last week thanks to Backstop’s developer training. Why That Conference? Many coworkers have attended over the past several years and raved about how much they learn and also how family friendly and fun the conference has been. Having the opportunity to learn while also brining along my family seemed like the perfect idea for a conference.

We had a great time and I was able to learn and reflect. Below is the list of my thoughts and notes on the sessions I attended.



Opening Keynote – The Origin of Opera and the Future of ProgrammingVideoArticle – Jessica Kerr

I have seen Jessica speak at GOTO Chicago multiple times and I enjoy the energy and insights she brings to topics. This talk was an interesting discussion about how the field of programming relates to the formation of the Florentine Camerata and other similar types of groups in art and how that shapes the conversations, learnings, and research in their fields.

Jessica introduces the idea of symmathesy (sym – together, mathesi – learning) which is defined as “an entity composed by contextual mutual learning through interaction.” She poses the idea that software teams are a symmathesy which is constantly changing due to the people, customers, tools, and feedback loops involved in the process.

She also makes an interesting comment about “10x developers” where a proficient developer is working with developers newer to a system and the challenges that arise from that situation. She proposes that the proficient developer should not make any changes directly to a system where the intent is to transfer knowledge to others. Instead, the newer developers should be driving a pair session with the proficient developer to ensure knowledge transfer occurs.

Jessica brings up several ideas on how to be a better team member. She talks about “generativity” which she describes as “the difference between the team’s outcomes with me vs. without me.” She says that “to become great, put the team first” and that “great developers aren’t born or trained, they’re symmathesized.”

She pushes back on the idea that software is a craft. Instead, she describes it as a necessary skill that we need to achieve the true goal of having an impact on the world. Software is not a craft nor is it art – it is an entirely new thing. Software is more flexible than metal and plastic, has fast feedback loops, the ability to run experiments more quickly than we’ve ever known. She says software is the next thing after art that we don’t fully understand yet.

Finding Your Way to a Microservices Architecture – Dana Hart

This talk was focused on Northern Mutual’s conversion of a web site to multiple SPAs (Single Page Application) driven by multiple microservices. Dana provided some general insights on the process, but it was less prescriptive than I was hoping for. This was a good introductory talk to microservices and described the great benefits they saw in that transition.

Her group in Northern Mutual went from quarterly and bi-quarterly deploys to multiple deploys per day with the new architecture. Wow! That sounds amazing. It sounds like they did a good job in making the transition seamless from an operations perspective. Also, she described how management do a great job in supporting them and how they had to leverage that support to change their processes around change management to support this new model.

SRE-iously! Defining the Principles, Habits, and Practices of Site Reliability Engineering – Victoria Vieldt

I was interested in attending this session since I am very invested in improving operations at Backstop. I was curious how other teams defined the role of an SRE and if there were techniques we could adapt at Backstop.

This talk was less prescriptive in terms of what you should be doing and more of a conversation about what SRE means within an organization. Victoria works for NewRelic and was discussing some of the tools they provide to improve visibility into the state of the application and related metrics. She referenced the Google SRE book and also the SRE workbook which I hadn’t heard of as good reference points on how to implement SRE within an organization.

I am adding the workbook to my “to read” list!

Hacking THAT: Real-World Penetration Testing – Arthur Kay

The title of this talk grabbed me! I have not seen penetration testing practices so I was eager to see the tools of the hacking trade demonstrated by a professional.

The talked focused on a vulnerability analysis of the That Conference staging site. Art described how he would proceed as a hacker to gather data about the job and then what techniques he would use to probe the site for vulnerabilities. He discussed the social engineering side in detail as he described how he would gather data on the individuals running the site to try and determine their usernames, associated sites, and personal details that would paint a better picture of the site. He used networking tools to enumerate the subdomains and web host as potential attack vectors as well.

The meat of the presentation focused on watching the requests the website made and replaying those as different users or with different permission levels to ensure they were locked down sufficiently. Art showed off some tools such as Burp to replay requests with altered payloads and headers. This was an interesting tool I hadn’t heard of before.

In the end, he discovered multiple vulnerabilities that were reported to That Conference and addressed prior to the conference. This was a very interesting talk!


Keynote – The 7 Pillar Developer: A Holistic Approach to Building an Exceptional Career – Cory House – Video

This was my favorite talk of the conference! I strongly recommend watching the video. My summary here will not be able to list all of the great lessons that Cory provides.

Cory talks about how we can change our trajectory in life by changing the systems we use everyday. We are creatures of habit and it takes effort to push it outside our seemingly automated systems. He cites a quote from Hunter S. Thompson:

Beware of looking for goals: look for a way of life. Decide how you want to live and then see what you can do to make a living within that way of life.

He talks about how this quote allowed him to realize that he needed to adjust the goal in his life to find something that made him happy and then engineer his life’s systems to help meet that goal.

He goes on to list the seven pillars he believes makes for an exceptional career:

  • Happiness is an advantage. Being an optimist improves your outlook and the relationships you have with others. Others are drawn to optimists.
  • Be aware of the brain chemicals that generate happiness and the actions that create them.
  • Stop wasting time poorly. Waste time well!
  • Get better at saying no at the things that don’t excite you.
  • “If you want to be an anomaly, you have to act like one.”
  • Specialize. Be remarkable.
  • Stop asking “How can I do it all?” and start asking “What do I want to go big on?”
  • Engineering degree half life – 2.5 years. 10 – 20 hours a week to keep up.
  • Embrace daily learning. Use a growth mindset.
  • Know what to ignore.
  • Learn how you learn.
  • Consider buying time by paying others to teach you.
  • Teach yourself.
  • Learn one thing at a time.
  • Degrees don’t matter.
  • Dress strategically.
  • Increase your luck surface area. Attend conferences, speak, consult, blog/tweet/share, etc.
  • Fool argue, wise people discuss.
  • Keep your identity small.
  • Sit with people you don’t know.
  • Be real. Network with people you like.
  • Buy time, not stuff.
  • Money buys time.
  • Multithread your life. Learn while commuting, exercise while playing with family, etc.
  • Systems > Goals
  • Define what success means to you. Determine the price it costs. Pay it.
  • It’s illogical to envy others. We don’t know the price they paid.
  • Success is personal.
  • Change your systems to change your life.

This session was overflowing with good content and ideas. As I said, I can’t do it justice by attempting to summarize and I believe the takeaways are entirely personal. Please watch the talk, I guarantee you’ll walk away with at least one thing you’ve learned or will want to start working on.

Branching out with Elm: Friendly functional programming for your frontend toolkit – Lauren Beatty

I was interested in attending this session to get some more exposure to Elm. I was curious how Elm compared with React and other more modern Javascript frameworks.

Elm has an interesting way of modeling the application. It is a functional language and one of its strong points is the excellent compiler error messages it generates. I had heard this previously and it was great to see it in practice. The error messages really were helpful!

I left the session with a good basic introduction to Elm and how it can be used to model an application in such a way to prevent errors at runtime. However, I think I would need to do more research to determine how it compares with React and if its popularity has declined as React has taken hold in the community.

Open Spaces

Open spaces are informal sessions led by attendees focused around a single topic. Attendees were encouraged to propose ideas for sessions and set up times to discuss what they felt would be useful to them. Sessions included anything from specific technologies to financial independence to food and drinks.

I attended sessions on Slowly Breaking a Monolith into Microservices which was not that useful and a session on going Independent as a software developer by Cory House since I was so impressed by his keynote. I was a bit nervous attending these types of sessions since the content depended on whoever showed up to the session, but I liked them so much I attended more!


Keynote – Adventure as a career plan: how curiosity and exploration create our best lives, friendships, and careers – Jason Lengstorf – Video

I was less enthusiastic about this talk although it was a very well told personal tale on his journey from angry teenager to developer. He does a good job describing how skills from multiple disciplines transfer to software development and also how to stay resilient in the face of failure.

Jason discusses the idea of seeking vs wandering and how both are necessary to succeed but serve different purposes. Seeking is purposeful and goal oriented whereas wandering expands our horizons beyond our known world and knowledge.

This was a good talk, but I felt the subject matter was similar to Cory’s talk from the day prior and both more broad and narrow so it was less effective for me.

JSON Data Modeling in Document Databases – Matthew Groves

This was a fascinating discussion on how to model document databases. I have limited exposure to document databases but heavy relational database exposure so I was curious what new patterns are used in this new model.

Matthew did a good job of describing the best practices for relational database design and how those translated directly to document databases. The most interesting aspect to me was how to represent foreign keys and relationships. There are multiple ways to represent relationships – normalizing the data into the document or storing a key to be looked up in a future query. Clearly if there is a significant amount of data it does not make sense to normalize the full data into the document.

This was an interesting talk and I want to try and get more exposure to document databases to see how these tradeoffs work with real data.

Open source contributions

I had a small achievement the other day when I made my first effort to contribute to an open source project. We use spotbugs in several of our tools at work to perform static analysis and inform us of potential issues. We had an issue with the tool attempting to process resource files that were included on our CLASSPATH. When spotbugs encountered non-class files, it printed a long stacktrace that did not cause the tool to fail but it certainly appeared so from the output.

I had done some Google searching and discovered an issue had been logged for this problem already. On digging into the code, I felt that I could actually fix the issue myself. A short time later, I had a checkout of spotbugs that I installed locally and verified my fix squelched the verbose output. Great, but now what? We try and give back, that’s what!

I opened a pull request, worked with the maintainers to come up with the best solution, and my change was accepted shortly after. How exciting! It’s just like the feeling of fixing an issue for a user that makes their day better. I was happy to be able to solve my own problem and give back to a tool that we use.

Encouraged by this interaction, I am trying to do the same with FitNesse. An incident logged several years ago has resurfaced and causes an error page when saving in certain circumstances. Instead of logging the issue and leaving it at that, I submitted a pull request that details the original issue and when it was reintroduced. I hope to be able to help out here as well!

I hope I have more opportunities to try and contribute to open source projects that we use. It feels good being part of a community!

Operational Excellence

The idea of moving on a path toward operational excellence has been on my mind lately.

When we encounter failures in production, these should be treated as significant events. A failure that triggered a page to a person on call is even more critical. The way an organization handles these incidents represents their operational response. I have been thinking about the different layers that make up this response. I see this as composed of:

  • Communication
  • Accountability
  • Root cause analysis
  • Prioritization

The organization must achieve the right balance of these elements to respond appropriately.


Documenting the details of an incident is the foundation for addressing the issue. If the appropriate detail is lacking, the operational response is out of balance. Details are required to determine root cause and to prioritize any incident.

Communication begins with the first notice of an incident having occurred. Hopefully this is due to a page or automated response for critical issues. There should be a record that an incident occurred along with all relevant details: who, what, when, where, why, and how.

The fact that an incident has occurred should be visible and communicated to interested parties.

Following root cause analysis, any changes that need to be made to address an issue should be clearly documented and associated with the incident documentation.


Every incident must have a clear owner. The owner is responsible for triage, data collection, and documenting what occurred. Ownership may transfer once data collection makes root cause discovery possible.

The organization must hold the owner accountable for navigating an incident through its lifecycle. Incidents must not fall through the cracks and fail to be investigated.

Root Cause Analysis

Once sufficient data has been collected and attached to an incident, the process of root cause analysis can begin. The most important result of this effort is to provide demonstrable proof of the cause of an issue.

Too often I have seen incidents where a user saw Event X was occurring, they took Action Y, and this solved the incident. Root Cause Analysis requires that we provide evidence that Event X was actually occurring and that taking Action Y directly led to the resolution of the incident. This ties back to the Communication point where we document these findings for future reference.


Operational incidents take priority over other work until the root cause can be identified. This is why ownership is critical so it is clear who owns this effort.

Recurring operational incidents should be prioritized over other work. Recurring issues are a scourge because they lead to alert fatigue and reduce confidence in systems.

Moving Toward Operational Excellence
Current Status

At Backstop, we have a weekly meeting where we review production incidents that have occurred and discuss upcoming maintenance items to be performed. One of the ways we can improve is in our communication. The level of detail that gets recorded as a result of an incident is highly variable depending upon the person that gets paged, the type of incident, what time they were paged, how many times they have been paged that day, etc. Sometimes incidents occur that do not get logged.

Action items from the meeting get assigned, but there is no direct followup to ensure items have been addressed appropriately. Often times, the list of outstanding action items is not reviewed at all.

Ways to Improve

I authored an incident template that lists the details that should be recorded when an incident has occurred. I even wrote a small script to create this documentation based upon the template!

I have also started asking for process changes around the weekly discussion to ensure action items are not lost.

I try to be a voice pushing for root cause analysis when we do not know why an incident has occurred. I ask for details that may be missing on incidents to underscore how important it is to understand why an incident has occurred.