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.
I recently read through a Hacker News thread discussing the article “Kafka Is Not A Database”, by Arjun Narayan and George Fraser. The opinions behind this topic are fascinating and I enjoyed sifting through comments from both sides of the table. For the purposes of this post, I’ve labeled these two broad groups of thoughts as Team Blue and Team Red.
Team Blue believes that Kafka, a popular streaming platform, has the potential to be the source-of-truth for your data—replacing one of the key responsibilities of conventional databases.
Team Red strongly disagrees.
The following is high-level summary of these opinions.
The difference between the titles Software Engineer vs Programmer vs Hacker vs {other_coding_title} is rooted in a person’s ideals. This difference is succinctly summarized in the wonderful article 3 Tribes of Programming, where the author buckets programmers into three distinct “tribes”:
You are a poet and a mathematician. Programming is your poetry
You are a hacker. You make hardware dance to your tune
You are a maker. You build things for people to use
josephg.com
The author asserts that all coders lean towards one of three tribes—The Poet, The Hacker, or The Maker. Even though a stark contrast is made to separate these groups, these tribes are not mutually exclusive—many programmers are Makers by day, Hackers by night, and aspiring Poets by weekend.
Software Engineer vs Programmer is a false dichotomy I’ve created to separate Makers from Non-Makers. I believe this separation to be relevant because the majority of us are Makers by profession—myself included. Without a doubt, the most accessible path to make a career out of code is the path of the Maker, or the Software Engineer.
If the Maker represents the Software Engineer, who is the Programmer? These are the Hackers and the Poets. These are the coders that code for the raw love of computing, the people who rightfully put the science in computer science. You’ll find these “purist” programmings developing new languages, tweaking assembly, and occasionally scoffing at the work of Makers. Pursuing a career as a Programmer will not be as accessible as pursuing a career as a Software Engineer.
Practically speaking however, this kind of separation is not helpful; everyone writes code for their own reasons. Since the majority of us are Makers, let’s dive into what’s actually important for a Maker to focus on.
Debugging is a critical skill. More important than the skill is the mindset. The debugger’s mindset is the attitude that you must always understand the why behind a problem; any ambiguities or unknowns are unacceptable. This mindset has the potential to carry you from debugging small functions to solving difficult organizational issues.