As a leader, you may have grown accustomed to a variety of conveniences when it comes to communication. You rarely get interrupted during meetings, your ad hoc Slack messages receive prompt responses, and your under-researched opinions influence people more than they really should. Unsurprisingly, not everyone enjoys these conveniences.
As a leader, you must be generous with your communication. Here are some ideas.
This post’s goal is to provide you with a deeper intuition behind two of the most common software messaging patterns—queues vs. pub/sub. This is a deep topic which deserves thoughtful attention when designing software. This article is structured in three parts:
After a year of persistence, you finally host the grand opening to your water park. The park has a wave pool, a water slide, even a gentle lazy river. The park kills it in its debut.
Word spreads and the park gets more crowded by the week. No big deal. With the extra ticket sales, you can comfortably hire contractors to start work on a new water slide.
You do your best to hire a set of trustworthy and knowledgable contractors. Despite providing them with a blueprint and a clear set of tools, you start noticing that the new slide is being constructed in ways you didn’t expect. You realize this is an inevitability.
On a busy July 4th weekend, a small boy hurts his knee going down a slide. After examining the situation, your team notices that one section of the slide is built too steeply. You instruct your workers to quickly make safety adjustments while you handle the upset parents.
As the lawsuit settles down, you check in with the fix. You realize that two key contractors have been bickering. One contractor insists the slide be built steeply for maximum fun. Another contractor insists it’s a careless rookie move. You do your best to work things out, but the relationship sours and your first contractor sends you a resignation letter. To make a bad situation worse, there’s zero information left behind on how the slide was built.
Despite the incident, the water park continues to do well. One day, you receive an email from a wealthy family looking to plan a 6-month stay at the park. They’re offering you a lot of money, but it comes with a special request. The family loves amusement parks and wants you to build three new rollercoasters before they arrive. You have no idea how to build rollercoasters. Nevertheless, opportunity is opportunity and you sign the contract. You quickly hire a theme park designer and a team of rollercoaster contractors.
You notice that the water slide safety issue is still unresolved. Your contractor tells you that they attempted a few repairs. Strangely however, every time an issue is repaired, a new issue pops up. Your contractor recommends that a brand new slide be built. It will be newer, better, safer, and more fun.
As work continues, your water park contractors become increasingly irritated with the ongoing rollercoaster construction. The amusement park contractors don’t know anything about water parks. You try to get both groups to talk more, but the process is excruciating. One day, the last water park contractor leaves.
Suddenly, your simple park has turned into a stressful amalgamation of amusement. The roller coaster deadline is slipping, kids continue to go on water rides that barely work, and your shiny new slide is half-done, collecting dust.
Any analogy to “architecture” or “construction” misses the mark in capturing the essence of software engineering. The key characteristic of successful software is pervasive chaos. Software engineering is managing this chaos.
“The 25 Micro-Habits of High-Impact Managers” is a wonderful article highlighting wisdom from various managers across various industries. The article also reinforces an important universal idea—the details always matter. I subscribe to this idea and believe it can be easily re-applied to individual contribution.
At any given company, the criteria for promotion can be bland and frustratingly opaque—consistently deliver value turns into create impact for your team, which quickly evolves into create impact for multiple teams, and somehow leads to create impact for the entire company and drive its future. These large expectations are difficult to break down. It’s easier to start with the details (“micro-habits” if you will) and see where that takes you.
Before continuing, I highly recommend reading, “On Being A Senior Engineer“, which provides a holistic set of expectations on what it means to be “senior.” With these expectations in mind, the following is an opinionated list of micro-habits exhibited by high-impact software engineers. I’ve broken them down into 4 themes, each with 5 habits.
Software engineering decision-making is a stressful and time-consuming process. When the stakes are high, you will be met with opinionated programmers, insurmountable organizational constraints, and unfortunate baggage from old projects. Consensus is difficult.
In a previous post, “Staff Software Engineer Responsibilities“, I mention that the act of “Transforming Competing Opinions Into Decisions” as one of a Staff Engineer’s primary responsibilities. I note that prolonged technical debates are a risk for organizations and that Staff Engineers must “push through friction” in order to arrive at decisions. However, once you feel the friction, it’s never clear how you’re supposed to push through it.
This article presents a generalizable 6-step outline to help engineers drive consensus. This is a set of heuristics, not an algorithm.
“Runtime” and “Runtime Environment” are some of the most overloaded terms in software development. It’s confusing for everyone; this word means many different things in many different contexts. This post’s goal is to provide you with an intuition behind the many use-cases of “runtime.”
Company culture. Extremely important, impossible to define.
Impossible to define doesn’t mean impossible to understand. A surface-level understanding of culture is available via Glassdoor and company onboarding documents. However, a deep understanding of culture is only available via experience.
This article focuses on a set of values often associated with software engineering culture. Instead of the discussing the values themselves, I discuss the activities which measure them.
The path of the Staff Software Engineer represents the career progression of a technologist. Senior Engineer leads to Staff Engineer which leads to Principal Engineer which hopefully leads to a comfortable retirement. Unfortunately, Staff Software Engineer responsibilities are often poorly defined by management. The goal of this article is to give clarity to these responsibilities so aspiring Staff Engineers—and their managers—can perform their jobs more effectively.