Presentation was part of DevOps Enterprise Summit - Virtual 2022. Abstract Change is something we must continually navigate. In a large organization, change can be further challenging based on the number of people that must have a shared understanding in this navigation. This can be complicated with organizational boundaries that can limit consistent horizontal communication, allowing costly variance or great ideas only surfacing within a smaller team or organizational boundary. We must improve how we stay connected.
Below are resources and references from my Regex Express talk. Learning Resources RegExr: Interactive editor which visual signals matching, details on the matches, cheatsheet notes, ability to save favorite expressions. Rubular: A simple interactive editor that signals expression matches on a selection of text and is paired with visible quick reference. Rexegg: A full site of content dedicated to all things with regular expressions. This includes both basic to complex topics, making it a good resource for a large spectrum of learning.
This talk was presented at New Relic’s FutureStack 2022 conference, which focused on sharing lessons learned when dealing with some of the sociotechnical challenges in system observability within a large organization. This walks through some practical examples with how we focused on cultural aspects of learning and sharing approaches, while also including concrete examples in how we scaled and seeked ways in balancing consistency and autonomy in the usage of New Relic.
Abstract Our systems are continually evolving, spurring the necessity to focus on how we can introduce changes which minimize the risk of a “big bang” event. By examining how traffic flows through your distributed systems, you can find ways of testing and evaluating gradual changes. By understanding different ways of managing your traffic, you build new options for evolving and testing your systems. In this talk, we will cover approaches applied at Cerner Corporation when evolving their service ecosystem by leveraging different traffic management patterns.
Abstract Documentation is a valuable means of scaling knowledge through your teams. Teams are continually challenged to do more, with less. However, making lean maintainable documentation is a challenge, especially when documentation systems are not aligned to your development toolchain. Any point of friction in maintaining your documentation increase your probability of having out-of-date and untrustworthy documentation. In this talk, we will explore how you can start managing your documentation like code.
We live in a complex and fast-growing industry. While other engineering disciplines have been around for 100s of years, software engineering is still in its infancy and changing often. We are asked to share ideas to influence change, but this can be challenging in this rapidly growing field. This requires conveying thoughts to different audiences which may also vary on their technical vocabulary. It may be easy to reference a software engineering principle or law that can elegantly describe a technical scenario, but it may be ineffective when conveyed to others who are not aware of that concept.
Slides In this talk, we will discuss how to introduce and grow chaos engineering in your organization. This includes how to effectively communicate this approach with leadership and related teams, strategies on how to start small and expand into more risk adverse environments, and valuable lessons learned on making it effective within your systems. Approaches will include specific examples of how teams have applied chaos engineering at Cerner Corporation, a healthcare technology company.
When I began my career in software engineering, I was fueled by the joy of programming and working through unique problems knowing that an answer would be discoverable through my trusty debugger and perseverance. As my career grew in the field, I began to learn more of the challenging constraints with large systems, human organizations, and complexity that seemed untamable. Through additional exposure to these larger problems that no longer could be tackled through the use of my beloved debugger, I began to see how it required different care and feeding at both the personal and team level to overcome these challenges.
QCon San Francisco 2019 recording Slides Get the 8.5 x 11" PDF hand-out QCon SF 2019 Recap: Blog post that summarized my experience at the conference and all of my notes. This guide includes a second page, to convert the guide into a paper airplane.
One of the most powerful things we can do is make a decision. With the ever growing landscape of technology choices, we are faced with making a decision on a frequent basis. While decision making is not something we view as a core activity of engineering, it is the one thing we are doing at all levels of our architectures. This type of activity not only deserves our focus, but should also be considered as part of our craft that we pursue with improvement.
Meetings, the human ritual of synchronous communication. They are considered the cornerstone activity of keeping teams aligned on their mission. As engineers, we encounter meetings routinely in order to facilitate team work in software development. While meetings are a core ritual to team work, we many times find meetings drain our efficiency of software development. As a result, we perceive meetings as a negative exercise, only hindering us from our larger goals of software creation.
The most valuable asset in an organization is the people. Without people, you don’t have an organization (excluding robots). In the world of software development, many forces get applied to the people within your team which harm or degrade their quality of life. Fixed deadlines, the presence of Murphy’s Law in production environments, compilers which don’t understand your intentions, or just dealing with humans that don’t understand your code is working as designed.
If you are building Java Virtual Machine based services, a core measurement of your success is performance. The act of measuring and analyzing how your code is performing becomes an essential activity in all phases of your development. This skill becomes even more critical once you are required to troubleshoot and evaluate your service in a unique production environment. Understanding what operations are consuming most of our CPU time, as well as, what areas of your code are wasting resources will greatly improve your ability to diagnose a sluggish JVM.