Personally, I never really saw the difference between the two; responsibility is heavy. Maybe it’s because I was too big of a fan of Spider man as a kid.

The idea of responsibility as an engineer for me began with two stories I was told long before I even began college.

Made of Iron

There is a ceremony in Canada called the “Ritual of the Calling of an Engineer” where graduating engineers are given an iron ring, and their acceptance of the ring is meant to not only create a sense of pride in their craft, but also serve as a reminder of the responsibility towards the people that are effected by what they create.

The origin of the ring is based on the Quebec Bridge which is known to have collapsed during construction, killing dozens. The story is that iron from the bridge was fashioned into rings and given to the engineers who designed the bridge, to serve as a brutal reminder of what they were responsible for. This same iron was also fashioned into rings for the early versions of this ceremony. To this day, the ceremony is still done and is no longer locked into just being Canadian; if you attend an American university, there are good odds of receiving this kind of iron ring or being eligible to purchase one at graduation, particularly if you major in something like Structural or Civil engineering.

A quick aside: it is unclear if the material used to create the rings ever actually came from the bridge and the mystery is part of the allure of the story.

The O-Ring

The story of the Challenger is one of the most well-known engineering disasters in modern history.

The critical failure were rubber O-rings that were used in the shuttle’s solid rocket boosters to ensure a proper seal on a specific joint. The night before launch, the O-rings lost the required flexibility due to the cold weather. This loss of flexibility meant the O-ring couldn’t do its job and wouldn’t seal the joint properly. There were multiple engineers who recommended delaying the launch that night, but the managers of the project pushed back and ultimately the managers in charge of manufacturing the O-rings themselves reversed the no-go recommendation, approving the launch.

Seven people died only seventy-three seconds after launch.

Engineers and Discipline

The standard discussion surrounding these stories is about how important it is to listen to engineers who flag safety concerns and how organizations need to be structured to enable these concerns to block tragedies. In engineering classes, it becomes a discussion on the importance of voicing your opinions and emphasizing the impact that your decisions can have as an engineer.

I believe neither fully capture the importance of the human element in both stories. In both stories, there are constraints placed on the people involved; there is money to be lost and deadlines to be kept. There is pressure on people’s jobs and productivity to be achieved. In the case of the O-rings, NASA hadn’t had a catastrophe of this magnitude and the launch schedule for this flight had been delayed multiple times already. More, and more pressure.

I think it is very easy for me to sit in my chair and say I would have done better. The same can be said modern day versions of such engineering follies. Cambridge Analytica, the crashes of the Boeing 737, Facebook and Myanmar, etc.

In modern times, the inability to take adequate responsibility and ownership no longer spins tales of organizational complexity. Instead, the discussion revolves around personal greed and self-interest. In a lot of ways, responsibility has evolved. It is no longer an endeavor about doing what is right over what is dangerous. It is now an endeavor of doing what’s right despite standing to profit tremendously from doing what’s wrong.

Needless to say, modern discourse regards LLM models, AI companies, and the process of creating these models. And once more, it is unclear if the responsible shall prevail.

This article is about why it is important to forgive as a general rule, and I do mean that it is important to forgive even without apologies or retributions from a guilty party. I will say before we dive in that I break my own rules all the time, and am welcome to the idea of being called a hypocrite.

Let’s begin with game theory.

Game Theory Optimal

Game theory gets a lot of attention in popular media because of how it plays into poker, behaviors, etc. And it’s almost always presented as some extremely complicated, mathematical analysis tool that geniuses uses to model human behaviors and get an edge. With a name like game theory, it makes sense. The branding is great, it rolls of the tongue, its even got a hint of mystery.

^{Explore interactively →}

The goal of game theory is simply to model behaviors with simple games. The best choices in the game indicate the behaviors that are best for reality. Part of game theory is modeling utility which is a substitute for everything a person could care about from preferences to money, the whole spectrum of reality. Each person is a player, a rational agent, seeking to maximize their utility via some set of actions. Initial forms of game theory were just tables, but this naturally evolved into trees and equations to capture more complex interactions.

One of the first games, illustrated above, is the prisoner’s dilemma. The original prisoner’s dilemma problem is a one turn game where two players either cooperate or defect; cooperate is to not rat out your co-conspirator of a crime, and to defect is to betray your partner in crime and attempt some kind of snitching plea deal. Naturally, if both cooperate, they do better than if they both attempt to betray each other. But there is a snag, if only one person defects, they reap an extreme reward indicative of being able to not go to prison at all while the partner in crime is punished alone.

^{Image © Showtime. Key art via Wikipedia}

The iconic game we are most interested in is the iterative version of the prisoner’s dilemma proposed and studied by Robert Axelrod, likely the reason for the name of the main character in Billions. The story of this research was that Robert Axelrod invited a bunch of game theory afficionados to create strategies in the form of computer programs, and had those programs duel against each other in round-robin tournament formats. The core difference between this problem and the original prisoner’s dilemma, is that the players played more than one turn of the game, so what a player does in one turn can affect future turns. There were a ton of strategies, and those are discussed in depth in The Evolution of Cooperation, Axelrod’s book.

There was a simple strategy that prevailed in the tournaments against far more complex strategies that were known for exploitation. This strategy is known as “Tit For Tat” and was created by Anatol Rapoport.

^{Explore interactively →}

The strategy was made up of two parts. First, cooperate on the first move. Second, do whatever the opponent did last round. When analyzed by Axelrod, he distilled the problem down to four ideas. Tit for tat is nice, retaliatory, clear, and forgiving.

It is nice in that it doesn’t start the fight; it starts by being cooperative. It is retaliatory in that if it is wronged, it will punish in response so that it is not exploited for free. It is clear in that sophisticated programs can easily understand the intentions of the algorithm. And, to the point of the article, it is forgiving. Once the opponent cooperates, it will begin cooperating again.

There are, of course, caveats to the story. Tit for tat was the best performing in round-robin meaning that it was best in overall performance, not unbeatable by every specific strategy. There was also follow up research indicating that for more elaborate scenarios there are variations on tit for tat that are better.

But, the idea is pretty clear. Even without an adult or parent in the room, two rational self-interested agents may become cooperative because it is beneficial for both of them. Chef’s kiss. Fade to black.

Just kidding. If that was the only thing I wrote about, then I’m no better than a Veritasium video from over two years ago.

Exploitation and Punishment

Forgiveness for a Reason

One of the parts of tit for tat that is often glossed over in favor of highlighting the forgiving and nice nature of the algorithm is the retaliation part. Forgiveness doesn’t always come without a cost to the guilty party. The tit for tat algorithm is not preaching a holier-than-thou ideal where you dole out forgiveness for nothing. No, if anything, it is actually brutal in that it’s an algorithm that punches back just as hard as it is punched.

^{Explore interactively →}

It also loses to the most egregious algorithm, which is the one that seeks to defect with no remorse, as it loses on turn one and is never able to catch up.

If anything, this teaches an additional lesson that is a bit less savory; it is simply not an option to forgive those who do not seek to cooperate. Which seems obvious. It probably should be. But in real life, I think this manifests in ways that are a bit more nuanced. Cooperation isn’t truly a one-dimensional action. It’s not simply a choice. People’s actions are based in value systems and with conflicting interests and self imposed constraints. A person may defect and not even realize they are defecting. They are just cooperating with themselves. The analogy really falls apart fast.

Some people will have lives inextricably linked to your wellbeing with value systems that are not completely orthogonal to your own, but they might as well be. (And that’s okay!) But if they differ in direction enough, then you may find yourself in this iterative prisoner’s dilemma with quite an egregious opponent. It may mean that you have to give up on the idea of cooperating with them and seek a different route of behavior. Otherwise, you’re just in a situation where forgiveness just leads to inadvertent exploitation. And we wouldn’t want that.

After all, we have graphs we need to maintain.

The Social Network

^{Poster © Columbia Pictures. Image via Rotten Tomatoes.}

The idea of a social network loosely began in the 1800s, with the advent of modern sociology. Émile Durkheim and Ferdinand Tönnies created models of how human relationships transformed through the industrial revolution where small, rural villages that were tight knit with shared values, kindship, and organic closeness became industrial cities where social ties were based on self-interest, contracts, and other yucky things. The networking part came around in the 1900s with Georg Simmel, who imagined society not as individuals or fixed groups but as webs of people. The term social network was finally coined in 1954 by an anthropologist by the name of J.A. Barnes when writing about a parish on the Bremnes island, in Norway.

There’s a lot more to the history, but possibly the big landmark work was The Strength of Weak Ties by Granovetter in 1973. Its hugely cited and it’s quite the paper. The core demonstration of the paper was that even loose acquaintances, were valuable for things like ... finding jobs. (And the LinkedIn connects go wild!)

Jobs, connections, etc. Valuable things can come from loos ties, all the things that people talk about before networking events.

Something that isn’t talked about as much on social media or at these networking events, is the breaking of network connections. People lose friends. They lose connections to coworkers. They drift apart. Weak ties are easy to break; they also don’t naturally persist in a world rife with conflict.

Yeah, yeah, I’m being heavy handed. Forgiveness does in fact help with that.

Your friends have more friends than you

In 1991, a sociologist named Scott L Feld, observed the friendship paradox. In summary, your friends are likely to have more friends than you. Its mildly unintuitive, and has a lot to do with how popular people have a lot of connections and those people don’t have nearly as much popularity.

In mechanical engineering, a lot of time is spent discussing leverage in the form of gear ratios and moment arms. In a lot of ways, friends and social ties are an individual’s intellectual leverage.

Stemming back to as early as I can remember, every group project I’ve partaken in is a slightly sadistic, slightly masochistic game. For the group projects where a teacher decided the groups, I can’t believe you would do that to me. For every group project I had with friends that carried me, I can’t thank you enough.

It feels a bit silly to have an entire section of this article being about how important it is to have friends that are invested in your well-being and forgive you for your faults and that you in turn forgive for their faults so that you can all grow together, but it feels necessary as an adult. I have friend groups span continents and that is in fact a flex. I’m proud of my friends. I often brag about them. Here’s a famous video of one of them:

I link everyone I know at the first chance I get because it truly is amazing.

And the best part is that he forgives me every time.

(Do Not) Stick to the Status Quo

Most of this article has been about the importance of forgiveness and the value that comes from forgiving. At its core, the idea is that cooperating with people that want to cooperate is valuable and forgiveness enables that.

I do want to add a slight specification. There’s no need to participate in insanity. Just because you forgive, doesn’t mean you have to do the same things over and over. The action space you have in life is far larger than cooperate or defect and you should treat it as such. Being forgiving is a quality that enables you to work with a person again, but that doesn’t mean you have to work in the same way. You’re allowed to change the dynamic so that you don’t have to deal with the same issues of defection again.

And possibly most important to all of this, forgiveness should be something that causes a change in your behavior. You shouldn’t treat relations the same way before and after you are wronged. As a principle, its pretty clear and obvious. It would be insane for a person to keep acting business as usual, maintaining the status quo, after being wronged.

I emphasize this part so much at the end, because this rule is something I have such a difficult time enacting in my own life. Forgiveness with no behavior changes is simply yearning for a time before any wrongdoings and misgivings. I’ve found myself recently in a situation where I tend to be doling out forgiveness rather than apologies more often than not. Lucky me. And in this circumstance, I find it difficult to not wish for the times before the forgiveness was required and yearning for the relations that did not require me to change and alter my behavior to accommodate for previous misgivings.

But alas, that’s life.

It was in a chain that honestly had another really good question and observation about the article, and I felt like there’s something to refine from within the question.

The short answer is: yes, exactly.

The longer answer begins with: partially. There’s certainly value in working towards a goal and treating that goal as a guiding light for the actions you take. I very often have told high schoolers I mentor that they need to have some kind of “ball” that they’re keeping their eyes on; something they’re chasing even if its only passively. The analogy is relatively consistent. If you’re not looking at the ball, there’s no way you’re going to hit the ball. Honestly, you won’t even know when to swing the bat. You’re more likely to just get hit by the ball.

It feels like almost everyone who’s ever become notable or successful has had a goal at some point. Sure, sure, they also likely came from good circumstances or had extraordinary luck, which played a major role in their success, but having the goal was required. The goal makes it so a person can take advantage of situations that will advance them in a general direction.

However, I believe that the issue is that life goals are often moving targets. The most inarguable example of this is the hedonic treadmill. As life get’s better, you will seek more or be less satisfied with what you have. To not fall into this trap requires conscious thought and effort to declare enough is enough. And I believe that’s pretty feasible from a monetary perspective, but I don’t believe it is true from an intellectual or fulfillment perspective. Anything can become boring. The things that interest us when we are young are very rarely the same things that interest us months or years into the future. Passions die out. That has to be accepted. Bands break up, people shift careers.

When taking that into account, it becomes a more specific wording of the overall question. Rather than decide based on where you want to go in the overall picture right now, you can instead work in a way that allows you-in-the-future to have the options that they would desire when they’re picking the direction they want to be in the overall picture. For example, maybe you in the future wants to become a doctor just like how you want to right now (assuming you did), then its ideal that you worked towards becoming a doctor as a goal. But maybe there’s a 5% chance you want to become a lawyer. Probably should make sure that you read a bit more, it’ll help both directions. Maybe there’s a 10% chance you want to become an engineer. Okay, let’s also pay attention in math class. 15% actor. Well drama class is there and we do have to sign up for an elective anyway.

None of these fully detract from each other, after all, every career has some core sets of skills. Also, its far more likely you’re not sure if what you’ll want to specialize in within a larger school of thought: do you want to be an electrical engineer or a mechanical engineer? Will you want to become an engineering manager or an individual contributor? There’s no way of knowing a lot of the specifics in the future nor what your predilections will dictate.

So in some sense, I’m really saying that there are actually a ton of right options early on when uncertainty is at its highest and the trajectory of a person can diverge from expectations rapidly. But so long as you have a general angle in mind, you’ll at least be moving forwards and not staying still. If you’re able to keep moving, you’ll be able to keep monitoring where you see the balls you’re tracking are trending towards, what direction your goals are moving in. You’ll also keep building skills that keep options open that may not even be within your current head space.

You will thank you later

My life is a bit of an example of this. I didn’t really know what I wanted to major in college, but I did know I wanted to play a ton more StarCraft 2 and pursue some sort of Esports career with the game. So in high school, knowing that I was likely going to do something STEM related, I chose engineering as my general direction. For each college I applied to, I queued up a random number generator and had a mapping of numbers to engineering majors. For Berkeley, I was MechE. For UCLA, I believe it was bioengineering. For UC Santa Barbara, it was chemical engineering. For CMU, it was computer science. For UCSD, it was mechanical engineering. For UCI, it was electrical engineering. A complete splattering of options.

I picked UCSD because it had a better StarCraft team than UCLA. I also checked some university ranking that year that had UCSD MechE as better than UCLA. Who knows if that one is remotely accurate, and also who really cares. After all, I was gonna play a ton of StarCraft and be a pro while in school like all the other cool gamer kids at the time.

^{Cover art © Blizzard Entertainment. Image via Wikipedia}

Suffice to say, my life did not pan out that way. I was not expecting to go into industry and pursue start up world ad infinitum. I was also not expecting to sour on the idea of becoming a professor in the first year of my PhD. But alas, there’s no way of knowing the future.

The me-right-now does thank the me-in-the-past for taking the path he did though. There were a lot of things that I became knowledgeable about or skilled in or colored my life in a way that allows me to appreciate life in a very particular way. In spite of all the suffering that happened along the way. There are doors that remain open in a way that I don’t think would have been possible without this path and it does feel that as my life has progressed, I’ve only opened doors for myself and find that I haven’t closed a door of interest just yet.

To go back to the analogy, aside from the punctured balls of dreams past, all of the balls are still within view and within reach. I think me-in-the-past for giving me-right-now the opportunity to swing.

My first interaction with them was early 2025 and at that point I hadn’t been using too many AI coding tools aside from VS Code with Github Copilot and some autocomplete. However, I was doing a lot more fullstack work at the time and thought I understood how frontends and backends worked.

General Workflow

For the uninitiated who haven’t worked with one of these tools before, its basically just prompting an LLM to spit out a website. The harness at the time was ahead of its time and its still really cool.

^{Explore interactively →}

But the REALLY cool part is that right after you prompt, the application immediately spawns within the same tab in your browser and its effectively the full application. The wildest part is both Replit and Lovable have wrote somewhat extensively about how they built their systems, or at least enough that you can do a bit of educated guessing on how it all works.

Isolated Cloud Sandboxes and Floods

The first thing in my mind that made the stack interesting and why it was confusing to me is that they really do just ship a containerized environment that’s completely isolated. 2025-Jerry saw this and was like, no way, that sounds super expensive. The microVM that the container is shipped on is expensive, but more importantly all the time and talent spent on securing the containers looked super expensive.

Even now, several years after they shipped their product, its not quite clear what exactly an LLM can spit out with every prompt and its not quite clear we can build harnesses that handle all LLM silliness; there’s odds of needing to re-prompt or pass through sub-agents or do an amalgamation of post processing to ensure a reasonable output.

In some sense, this wasn’t a new problem Replit faced that other organizations didn’t. After all, CI/CD platforms and code runner platforms are dealing with nearly equivalent security concerns. Effectively all software platform-as-a-service companies that target anyone remotely technical as a customer, has to deal with these issues as impending threats. But the volume, does really ramp up and that has caused a lot of issues. I love pointing it out, but Github is still not dealing with the AI code commits well.

Shout out to this guy

That said, Replit goes a bit in depth on how they do the security for their sandbox in their blog.

The key things, that I didn’t immediately guess, were that they use are Determinate Nix as a package manager, GCP was chosen as infra with Cloud Run as their sand-boxing method, and, perhaps most importantly, EVERY CUSTOMER GETS THEIR OWN GCP PROJECT INCLUDING FREE-TIER USERS. What a wild decision. The decision to do such a thing almost builds in a requirement to use infrastructure as code, and permission management seems like a nightmare to get through. And adding in the idea of autonomous traffic from AI agents, its hard to not see how daunting the system that needs to be created is.

Security Arms Race

As with most software that is powerful and being given out to anyone, the immediate concern I have is “how will I stay ahead of it breaking?” And I don’t mean breaking in the sense of servers error-ing out or frontends having bugs. I mean, what if a person purposefully uses packages that are known supply-chain attacks? How do you stay up to date every day with every bug, to ensure your vulnerability doesn’t endanger the rest of your client base? What happens when someone tries to mine Bitcoin on their Cloud Run instance?

Maybe my concerns are actually just a demonstration that I don’t fundamentally work with consumer software that would glean the eyes of people trying to break into my stuff; generally people want the things to work, or the data isn’t life-threateningly important.

Regardless, I find myself admiring engineers who are willing to make products like this, because every time code is shipped it is done with some amount of bravery and boldness.

So first, let’s just talk about why people go to grad school.

Barriers and Signals

Graduate school for some jobs is required. If you want to become a doctor or a lawyer, you have to go to medical school or law school respectively. In those cases, going to grad school is quite literally breaking down a barrier to entry. Its table stakes.

^{Table stakes. Photo via Wikipedia}

The same could be said for a career switch. Not long ago, an assortment of people flooded into coding boot camps and masters programs in computer science to initiate a career switch into big tech. Again, its table stakes, but in a very different way. For those people, the barrier wasn’t fully constructed.

I think when thinking about how to get a job, its beneficial to think about the other perspective: what a company wants when hiring a new employee. There’s a sort of mythos that’s been created around the process of hiring now because of how obfuscated its become with AI automation across the application, the evaluation, and even the interview process especially around big tech and large organizations. However, the objective of hiring can be boiled down to a company needing a person with a skill set that can do a thing for the company. The hiring process is built around fulfilling this objective and de-risking bringing in a person for that role. I write de-risk because every time a person is hired, there is some level of risk for a company. At startups, especially early on, a bad hire can bring down the entire company.

So for a person who’s sole goal is to get a job offer, the goal would be to create a clear signal that you both:

1. Have the matching skill set that the company is looking for, and

2. Are not risky at all if you joined the company.

^{A game of risk. Photo via Wikipedia}

It then becomes very clear how grad school fits in with this mental model. The credential you receive from grad school is your way of creating a signal that you are the right fit. After all, having an education indicates that you have the ability to learn, and throughout your education you probably picked up a skill or two that is in the skill set that the company is hiring for. In that regard, grad school should be a no-brainer. But it isn’t anymore.

Signal to Noise

Because we’re talking about signal, its immediately important to talk about noise. (Or at least maybe I just think its immediately important because of the engineering/controls background.)

In this case, noise comes from a lot of places. A person’s personality, the way they speak, how their resume looks, and even the way a person dresses can provide noise to the signal. That is all stuff that a person controls though, for the most part, so its not particularly worth talking about.

The thing that’s outside of their control is the perception about their education.

Something that has been mentioned to me a lot, probably more than I’d like, is UC San Diego’s recent issues with math skills in their freshmen class. Now a lot of that is completely irrelevant to me now, given the graduate degree I have, but there are jokes about how it devalues my degree. That’s the problematic noise that comes with education.

^{surely this spaceship library will raise their math ability}

Unsurprisingly, this topic has been researched fairly extensively. In fact, it won a Nobel Prize.

Rat Race Equilibrium

The research paper, titled “Job Market Signaling”, was written in 1973 by Michael Spence. The core idea of the paper is that education doesn’t always increase the productivity of an individual, but it does act as a market signal for employers that the individual is “capable” because only “capable” people can get the degree at a reasonable cost. “Reasonable cost” does a lot of heavy lifting here. There is of course the monetary cost which is what people naturally think of, and the opportunity cost which is usually the second thing to come to mind as a person chooses to do school instead of just getting a job for experience. But there are other costs to consider, like strain to mental health, physical health, and even health of a person’s relationships. All of those are wrapped into the idea of cost.

With that in mind, if a degree is “cheap enough” such that non-”capable” people are able to obtain the degree in large enough numbers, the degree becomes useless as a signal for capability. However, because of the degree’s history as being a useful signal, all people are now forced to obtain the degree just to match the credentialing of everyone else. And thus, we enter into a credential rat race. This topic is discussed pretty significantly in The Case Against Education by Bryan Caplan.

^{Explore interactively →}

Skill Acquisition and Productivity

The idea of “Job Market Signaling” is one that really hinges on productivity not being increased through education, which I’m sure resonates with a lot of people, especially those that hated math from a young age. Formal education, in general, is pretty loss-y in terms of skill and knowledge transfer but its not really guaranteed. I can say though that a lot of the work I did in graduate school, both in classrooms and in formal education have served me very well in my career in terms of being able to look at ambiguous problems and understand how to format them in a way that is solvable through the set of skills I’ve developed.

However, there are a lot of skills I’ve developed outside of the workplace and also outside of education. I actually owe a lot of my productivity to the education I provide myself in my own time. That feels very much like the missing piece in the question of “Should I go to grad school?” There’s an unknowable factor for the me when I try to answer the question for anyone other than myself. I don’t really know your work ethic, your ability to retain knowledge in a formal setting, your ability to transfer skills that maybe nuanced when attempting to transfer them, your motivation to learn material outside of what you directly intend to work on, or, maybe most importantly, the opportunities that may arise for you specifically if you don’t go to graduate school. Sure, I think there’s some expected value from a PhD, but the variation in returns is pretty massive.

Kind of portraying the opportunity cost issue, people have demonstrated that learning on the job can be pretty consistent in providing useful career-oriented skills. In some regards, learning on the job or creating numerous side projects to highlight your skills can be easier to digest and less amorphous for an employer. It also is fairly consistent in the job market to stop caring about a person’s education after they’ve worked a few jobs, as the jobs tend to be a better representation of how someone will work at a new company rather than their education. Maybe its obvious to say, but there are surely ways of highlighting yourself and your capabilities without having to dedicate a line of your resume to a degree. There’s simply cleaner signals that exist.

None of this is to say I don’t recommend going to graduate school. Actually, I’ve recommended it to a handful of students even when they were in high school. There’s one in particular that comes to mind, as I recommended they should go do a PhD while they were still a senior in high school. But even for those recommendations, I acknowledge that I’m mostly guessing at whether they will benefit from the situation and gain the ever sought after “productivity gain.” After all, the world changes a lot.

“Enough” is Enough

The question “Am I working enough?” is very similar to the grad school question. Its about perception: am I exhibiting a signal that says I’m being a productive worker through the amount of time I spend on work-related activities?

Also a question, I am completely incapable of answering for people in most situations. It is an interesting question though, because it comes at a time where perception of effort has seemingly become top of mind on social media. It is fairly easy to scroll through LinkedIn and find posts about companies that expect 60 hour work weeks, or founders of companies talking about how they’ve been so busy “on the grind” for an entire weekend. There’s a glorification of overworking.

This glorification seems pretty natural. After all, if I purchase some micro-SaaS service, I do feel more at ease knowing that the company’s social media says they’re working all weekend because if I experience any downtime, I should be able to expect a quick remedy. So as a customer, I can appreciate the signal. I imagine the same for an investor as well. The only downside there is for potential employees that desire some off-time, but that’s only if options for that exist. If a credential is easy to get, then everyone has to get a the credential. If every company expects 60 hour work weeks, then everyone has to work 60 hours per week.

There’s also the individual incentive that is interesting as well. I imagine I’m not too different from most people in wanting my peers to perceive that I am hard-working and care about my work. After all, I envision myself as someone that’s hard-working. If others were to perceive otherwise, I’m guaranteed some level of cognitive dissonance.

As an aside, there’s probably something to be said about not assigning your value of yourself to perception from others.

Aside from avoiding cognitive dissonance, there’s an argument to be made that perception of how productive you are and perception of how much effort you exert ties into assessment of your performance. This idea has become so prevalent at companies that some entire countries are known for having a culture built around working extra hours.

I will say that these kind of metrics may make sense in certain situations; there are jobs where hours put in linearly correlates with productivity. A taxi driver, for instance, can take more passengers, the more they drive. However, this relationship between productivity and time isn’t true in most jobs in modern society. The amount of crops yielded by a farmer, doesn’t increase solely based on hours put in; in fact, it likely requires a threshold number of hours to get some expectation of yield for crops on a given size of land.

Metrics for Signals and Wins Above Replacement

Not long ago, people tried to measure software engineer productivity based on lines of code committed. The obvious issue is that you can write a lot of garbage code that is completely unmaintainable or broken; the metric can actually negatively correlate with productivity. More recently this has been done with AI usage in the form of forcing engineers to use AI coding tools.

The issue with any of these metrics is that what we really want to know is whether an employee is being more or less productive in quantifiable terms relative to the expected value of a person in their role; effectively, we want to quantify something that is impossible to know.

In baseball, there’s a statistic that attempts to ascertain something quite similar: Wins Above Replacement (WAR). The statistic is attempting to capture how many more wins a team due to a specific player’s performance when compared to a possible replacement. Naturally, this kind of calculation requires a lot of assumptions and adjustments because situations are incredibly nuanced.

^{Explore interactively →}

When thinking of WAR and how it would apply in the workplace, it becomes blatantly clear that metrics like lines of code or AI token usage or hours worked is going to lead to inconsistent results. Every person’s performance hinges on another person and for large projects, it can be nearly impossible to tease out. A “win” in the workplace can be as small as being able to hit a deadline on time. But what if the deadline was placed incorrectly? What if the company goes bankrupt regardless of if this deadline is hit?

Is everyone at a failing company, failing at executing in their role?

Wins Above Myself, Win Probability Added, and Internal Signaling

I had a pretty toxic mindset early on in high school all the way through early parts of grad school. It was a lot of external comparisons, especially in things that I viewed as competitions, regardless of if they truly were competitions. And to be clear, it was mostly toxic towards myself. A lot of thoughts along the lines of“why am I not as good as ___?”

Over time, I’ve noticed my mindset has shifted more towards self-oriented questions. Am I better than I was yesterday? Am I doing better than my average from this past year? Was this decision one that I would make next year given the same information? Did I perform worse than my usual?

Effectively, I stopped trying to think of things in terms of other people’s expectations. For the most part, it never really made sense to think of things in those terms; it became especially clear of that during graduate school. After all, even if I lack some arbitrary perfect level of self awareness, I’m surely more aware of a lot of my capabilities than someone who is interacting with me only a few times in a semester.

Lately, I’ve just tried to think about whether I’m adding win probability to the teams I’m on and whether I’m adding as much as I can. Direction and magnitude. It feels a lot less murky in terms of driving what I do on a regular basis, but also it feels a bit more clear what I should focus my efforts and thoughts on. It also becomes clear when I really don’t need to put in more hours.

Now obviously there’s a caveat here and a pretty significant one at that. If I’m not aligned with the team I’m on in terms of what we need to do to win, or if I end up lacking a lot of self-awareness, then I’m doomed to have a terrible performance.

But I think that risk is a bit more acceptable than needing to ask questions about whether my PhD is worth it or if I should give up sleep to try to squeeze a little bit more work out of my exhausted brain.

I’ve used buttons for a long time, I’ve done short presses and long presses. I’ve made websites with default HTML buttons. Hell, I’ve even put together custom css for styling a button on a website. But I didn’t know how a browser takes code and makes a button. I never had a class on it (turns out it isn’t relevant to a mechanical engineering degree). I also recognize that we are in an age where everyone just talks about vibe coding and I’ll probably never need to know on a fundamental level how a button works.

Anyway, here is everything I’ve learned about buttons this week.

The First Button

Just a few years before I was born, the original HTML was created and it actually had no buttons. It only had the <a> tag. The <a> tag is the anchor tag, which works even to this day to embed links. It wasn’t until around 1992 that HTML+ was created, and along with it, interactive objects and inputs. Forms became possible as a result.

As an aside, I had no idea that Marc Andreesen, of Andreesen Horowitz fame, was part of the team at University of Illinois that created the graphical browser, NCSA Mosaic, that made these forms possible to render nor was I aware that he co-founded Netscape. It suddenly makes way more sense why he’s so successful; he’s the reason we saw the first set of buttons.

Rendering a Button

View the graphic above here.

The actual rendering of a button is actually exactly how you would expect it to work. Your browser takes HTML text, reads it, and then creates a tree of elements (DOM) and then creates nodes whenever it recognizes a tag. It maps those tags with a lookup table thats built into the browser, and then just wires how its supposed to work accordingly. Early versions of browsers used the operating system’s UI to draw the actual clickable button in the styling of the operating system.

Formalization of a Button

Hilariously, a <button> wasn’t fully defined until 1997 along with HTML 4.0, but it effectively became what we see today. The key innovations really are just the ability to click on it with more than just a mouse, and render it without an operating system toolkit. Instead, you can now use CSS and rendering engines instead of calling out to the operating system.

View the more modern interactive here.

Boringly enough, CSS is just another set of text that gets parsed and then creates an appearance based on a tree of style rules (CSSOM). There’s a bunch of traversal-ing that happens through the DOM and through the CSSOM as they combine into a render tree, and a layout procedure that occurs before everything is finally painted into pixels. But even after things are turned into pixels, there’s still some JavaScript thing that runs to connect your button to the planned outcome of that button.

The reason that they are a core feature I wanted to build into nugit is because of how startup culture works. In startups, pretty much everyone is a developer. Your manager is a developer, your marketer is a developer, your CTO is a developer. Everyone is focused on making things happen and building out the functionality of a new system. That means everyone is focused on building.

Reviewing becomes secondary and is a huge context switch cost. The more time spent reviewing means the more time spent not building. But if you don’t review properly you can break production and everyone will hate their lives.

Stacked diffs are effectively a way of just organizing your features as you build them so you don’t have to wait for the reviews before you continue building on top of features you need to create. If there’s changes you need to make early in the stack, you can easily propagate those changes to the downstream branches. This more or less already handled in Github from a coder perspective. The issue is as a reviewer.

A Brief Aside

With respect to video games, I think of stacked diffs as timing a play as a lurker in a tactical shooter like Valorant. Lurkers need to be able to move in parallel with the team, but at their own pace. They have a different set of context and want to move as fast as possible but lurkers heavily rely on your team matching your pace. The key idea is that lurkers are amazing to work with when they’re good at it, but they’re terrible to work with when they’re bad at it. If they go to slow, you just get caught and are ineffective because not enough noise was created to distract for you. If they move to fast, then the round is effectively over before you can make an impact.

The issue with the current workflow for PRs is that the team is moving really fast but no one is matching each others pace so being effective just ends up being extremely painful. It’s impossible to move at the right speed, which makes plays like this impossibly difficult to manifest (for a software team).

Effective lurking feels criminal

How it works in nugit

When building it into nugit, I decided to manifest stack diffs through stacking PRs to take advantage of a Github user’s familiarity with the idea where you can make a PR and have the base be anything, including the default branch.

When you’re reviewing a stack in Github, for a stack of 3 PRs, you have to either have 3 tabs open or navigate in and out of PRs over and over to get context on whats happening. You get the bare minimum context from the Github PR review screen as it is, and this just drastically cranks up the pain. If each PR was isolated it would be fine, but when you’re two PRs deep on your stack and the last PR draws from both the previous PRs in different files, you’ll be hard pressed to easily understand the changes without significant mental overhead.

Stack of PRs are open on the left with file exploration on the right

I added a stack view specifically to cover this situation. You can easily thumb between PRs to be able to see what files are changed between the two while looking at the directory. This gets me 80% of what I want when I first look at a stack. I just want to know what the differences between PRs are in terms of the files they’re effecting, because I already know the code base and can pick out if theres files missing that need to be changed to roll out a described feature.

If you want to try nugit, you can find it here.

We don’t have to discuss the sub 90% uptime

The existing GitHub UI for PRs has largely been unchanged for well over a decade. It works, it’s familiar to people, it’s inoffensive. But it’s just not enough anymore.

Picture a typical week on a fast-moving software startup team—the sort people would call “scrappy.” You’re clocking in Monday morning and building out a feature corresponding to a ticket, test it, and set up the PR by lunch. You ping your manager to review it and they say they’ll review it ASAP. Cool. Time to start the next ticket which involves building a new feature on top of what you built this morning. You knock it out before you clock out for the day and you ping your manager again. They’ll review it ASAP. Fast forward to tomorrow and by end of day you’ve knocked out another two features, each feature extending from the previous.

It’s now the middle of the week and your manager can finally look at your PRs. They find an issue with a function you wrote in the first PR. They message you on slack saying they want the inputs and outputs changed slightly. But PRs 2-4 that you wrote all rely on this function.

Another message comes in and they say “oh also there’s merge conflicts.” Someone else got their PR in before you. Maybe they changed some of the same files? Worse they changed the same functions. And now you have to resolve conflicts for your entire PR stack. You’ve gone from finishing 4 tickets before Wednesday to getting nearly nothing done.

It’s a table flipping moment. Why couldn’t your manager just review faster?

Turns out the manager has been neck deep in PRs from the rest of your team and they’re just barely staying afloat. One of your teammates is a new engineer fresh from college. They don’t even separate different features to different PRs yet. They’re all combined in one. It’s a 4000 line diff. Time your manager spends reviewing code now directly correlates with dissatisfaction with their job and a desire to leave the role.

No one wins in this situation. I’m also not making a novel observation.

Graphite is attempting to solve these issues, but they are no longer opensource. GH Stack is open source but it breaks the usage of the Github UI so utilizing the tool requires a commitment of the whole team.

To fill the void and solve my annoyances, I made something called nugit that builds on top of Github with the goal of integrating seamlessly with existing workflows, so I can benefit from using it on projects I care about. Its open source so anyone can fork it (I won’t be accepting external PRs). Follow its development and my shilling of it here.

I was vibe-coding a CI/CD implementation and ran into an issue. My GitHub Runner had run out of memory while installing some packages. So naturally, I copied the logs into the chat window and immediately the build file has some new lines written that look suspiciously like malware. “free-disk-space” is the name of the action. Its like something out of the early 2010s. But it isn’t malware. In fact, its used in by over 16 thousand people in their repositories to solve the same issue I had with wanting to customize a GitHub Runner.

The typical Ubuntu GitHub Actions runner has up to 31 GB of disk space that is used by unnecessary packages that are not needed for many builds. This action clears up that space within 3 minutes and allows you to install the more storage intensive packages that are needed for your custom builds. Again. 16 thousand developers.

GitHub Actions is has a fairly terrible reputation. It has actually served as the reason for some notable projects, like Zig, to migrate to alternative platforms. The system has an unreasonable number of bugs for a product that is used by millions of developers.

As Zig mentions, the GitHub CEO said “Either you have to embrace the AI, or you get out of your career.” Not exactly kind or supportive words for the developers that are using your platform and are asking for quality of life improvements. It’s reasonable to assume that GitHub just doesn’t care about solving pain points of users.

That lack of care is what brings me to Super Smash Bros. Melee.

Here Comes a New Challenger

Super Smash Bros. Melee was released in 2001. When it came out, it was a popular party game, targeted towards families and children in particular. However, over time, it became a binding force for competition, driven by a grass-roots community of players.

It drew a large and growing viewer-base throughout the 2010s, peaking sometime in the 2010s with over 190 thousand viewers on Twitch. Players were sponsored and their livelihoods were supported in part by the community because of how good they were at the game.

But, just like GitHub Actions, Super Smash Bros Melee was unsupported by the developers. In fact, Nintendo actively tried to shut down tournaments and competitions, attempting to kill the large events that served as the pinnacle of competition. This didn’t happen just once, but multiple times.

Despite this, the community persisted. In fact, they modding the game heavily, adding features like in depth training modes and netcode (yes, I do see the irony in linking to a GitHub repo). These mods became staples of the community.

Incentive Alignment

There is a consistent theme across both of these communities. There’s the obvious: successful developers create things that are valuable to others. There’s even a lesson: even the champions of a product have thresholds for pain tolerance.

But there’s something particular about both of these stories that are notable today. It is common in startup culture to state that if you are solving a real problem, your chances of success drastically improve. The issue is that the converse does not hold true after a certain size. Dedicated communities can form around things, developing their own solutions as they’ve been left by the wayside.

On the surface, that seems like a good thing. But, when a hacked up solution becomes well known and commonly used, the moral of the story seems to become murky. These communities have entrenched these products deeper into their lives and signaled to the companies that they are not going to leave. In turn, the incentive for these companies to improve their products vanishes.

In some ways, it becomes an indicator that the story of “AI is going to replace software engineers” is a farce. GitHub has fully embraced the AI hype machine and somehow they are unable to solve pain points for their users. In a more cynical lens, it indicates that even with tool-assisted, supercharged engineers, GitHub doesn’t plan on improving parts of their product that are deeply meaningful to their users; they may be focused on margins and new flashy developments. The brand and positioning of GitHub feels questionable with that in mind. It doesn’t feel like the bastion for developers and budding engineers to show off their stuff and seek community that it once was.

In the case of Nintendo, the charitable interpretation almost leads to admiration. They are a company focused on providing children with formative life experiences in settings where they will always have fun. They refuse to support a competitive community that seeks glory and victory through hardship and anguish; because when winning matters, losing isn’t fun. Does that excuse them shutting down the joys of a community that aren’t harming people? Probably not, but at the end of the day it is a single game of the plethora of games in Nintendo’s catalog.

Now, what I can say also isn’t fun is thinking that my vibe-coded CI/CD has installed malware because a tool has a suspicious name, or relying on GitHub repos to be able to play a 25 year old game online.