Fritz Hut | Thoughts & Commentary

Art, culture, and the conversations that matter.

Archives (page 6 of 12)

Why Your Team’s Code Review Culture Is a Better Indicator Than Your Code

I’ve seen codebases that could double as a Jackson Pollock painting. That team shipped on time, no stress fractures. Then there was the immaculate codebase—perfect indentation, a monument to engineering—that took six months to add a single button. The difference wasn’t the code. It was how the team talked about the code. Your review culture is the canary in the coal mine, and most of you are ignoring it while you bicker about linting rules.

The Code Is a Mirror, Not the Problem

Walk into any startup and the sad symphony starts: “We have to refactor the authentication module” or “The frontend is a disaster.” Nobody ever says “Our review process makes people want to quit.” But that’s the real bottleneck. Code is a fossil record of human interaction. When I see a pull request that’s been marinating for two weeks with fourteen comments about variable naming, I don’t see a bad developer. I see a team that’s learned to weaponize feedback because nobody taught them how to actually collaborate.

Developers discussing code at a desk

Let’s be blunt: bad code often comes from good people stuck in a broken system. When reviews are a gauntlet of nitpicking instead of a conversation about design, you get defensive programmers who stop taking risks. They start writing the safest possible code, not the best possible code. That’s how you end up with a codebase that reads like a legal contract—technically correct, spiritually dead, and impossible to change without a team of archaeologists.

How Review Culture Predicts Your Next Three Months

Here’s a quick test. Pull up your last five merged PRs and count the comments. Sort them into buckets: architecture, logic, readability, style. If more than 30% are about style, your team is bored or scared. Bored teams bike-shed because there’s no real technical challenge. Scared teams bike-shed because it’s easier to argue about tabs versus spaces than to question a design decision that might piss off the senior dev. Either way, you’re not reviewing code—you’re performing a ritual that makes everyone feel busy.

Team looking at a code review on a monitor

I once consulted for a company where the review process was so toxic that developers waited for the reviewer to go on vacation before merging anything. The codebase? Gorgeous. Clean architecture, perfect test coverage, documentation that could win a poetry prize. But the product was stagnating. Because the review culture optimized for safety, not progress. Every PR was a thesis defense. Every comment was a passive-aggressive essay. The team wasn’t building software; they were curating a museum.

Contrast that with a team I know that ships features twice as fast with half the drama. Their code is messier. Sometimes a function does two things. Occasionally a TODO lives for a month. But their review comments are things like “This approach might race with the payment processing—what if we queue it?” or “I tried this pattern last sprint and it bit us; here’s a link to that incident.” The conversation is about behavior, not aesthetics. That’s a team that understands code is a liability, not an asset. You want that team.

The Silent Signals in Your Review History

Your git history is a therapy session you didn’t know you were having. Look at the time-to-merge. Look at who reviews whom. Look at the language in rejected PRs. I’ve seen teams where junior developers only ever get reviews from other juniors, while the architects rubber-stamp each other’s work. That’s not mentorship—it’s a caste system with merge conflicts.

Pay attention to the emotional bandwidth of your comments. Are people saying “I don’t understand this; can you explain?” or are they saying “This is wrong”? The first invites a conversation. The second shuts it down. I’ve worked with brilliant engineers who left companies not because the code was bad, but because every code review felt like a performance review. When feedback is consistently framed as judgment instead of curiosity, you don’t have a technical problem. You have a culture problem that happens to express itself in JSON.

Frustrated developer reviewing code alone

Why “Best Practices” Are a Band-Aid on a Bullet Wound

Every few months, someone on Hacker News decides that the answer to terrible reviews is a better linter or a stricter CI pipeline. That’s like fixing a bad marriage with a louder dishwasher. Tools don’t fix trust. I’ve seen teams with zero automated checks run circles around teams with twelve-stage CI pipelines, simply because the first team talks to each other before writing a line of code.

The real best practice is psychological safety, but nobody wants to put that in a README. It sounds soft. It sounds like HR nonsense. But in practice, it’s the difference between a team that can debate architecture passionately and a team that silently resents each other while pretending to care about semicolons. The former ships. The latter writes beautiful, unshipped code.

You Can’t Automate “Don’t Be a Jerk”

I don’t care how many GitHub Actions you chain together. A machine won’t tell you when your feedback is demoralizing. It won’t notice that a developer hasn’t opened a PR in two weeks because their last one got torn apart. It won’t see that the only reason your senior engineer approves everything is because they’ve checked out and are polishing their résumé. These are the metrics that matter, and they’re invisible to dashboards.

Start measuring what your review process does to people. Track how often PRs are abandoned, not just merged. Look at the ratio of questions to commands in comments. Ask your team anonymously if they’d rather refactor the billing system or go through another review cycle. If they pick billing, you’ve got a problem that no amount of code coverage can fix.

The Fix Is Simpler Than You Think

Here’s the uncomfortable truth: you can turn this around in a week. Not with a new tool, but with a new rule. Make every review start with one thing the reviewer learned or appreciated about the change. It sounds stupid. It feels forced. But it forces the brain out of critique mode and into collaboration mode. Suddenly, that “inefficient loop” becomes “I like how you handled the edge case here—could we apply the same approach to the loop to avoid the nested iteration?” Same technical feedback, completely different human experience.

Next, ban the word “just” from reviews. “Just use a map here” or “Just refactor this” is condescending, even if you don’t mean it that way. It assumes the solution is obvious and the author is lazy. Replace it with “What if we tried…” and you’ll see a shift in how people respond. These aren’t fluffy soft skills—they’re technical management techniques that directly affect how quickly and safely your codebase evolves.

Finally, rotate reviewers deliberately. Pair senior folks with juniors not for mentorship theater, but so the seniors have to explain their assumptions out loud. You’ll be amazed how many “obvious” design choices turn out to be just habits when someone asks “why” with genuine curiosity. That’s how you prevent architecture astronauts from calcifying the codebase.

FAQ

What if my team is remote and we can’t have face-to-face code discussions?

Remote isn’t the problem—lazy async communication is. If you’re leaving a comment that’s longer than three sentences, get on a call. A five-minute video chat can resolve what would take two days of threaded GitHub comments. The goal is to ship, not to create a paper trail of your correctness.

How do I convince a senior developer that their review style is damaging?

Don’t make it personal; make it data-driven in a human way. Show them the time-to-merge on PRs they review versus others. Ask them how many of their comments are blocking versus advisory. If they’re good, they’ll adjust. If they’re defensive, you’ve got a bigger problem than code review—you’ve got an engineer who can’t handle feedback themselves, which is a performance issue, not a culture issue.

Should we just stop doing code reviews if they’re so toxic?

No, but you should stop pretending they’re about finding bugs. Code reviews are primarily about shared understanding. If your team already communicates well, you can shift to lighter-weight processes like pair programming or post-merge review for low-risk changes. The ritual of blocking a PR for every tiny change is a relic of a manufacturing mindset that doesn’t fit modern software.

Our codebase is genuinely bad. How do we fix it without making reviews even more painful?

Stop trying to fix it all at once. Pick one module or service that’s actively causing pain and agree as a team to refactor it with a higher tolerance for mess in the short term. Make the review criteria explicitly about behavior and risk, not style. When the team trusts that reviews aren’t a trap, they’ll actually want to improve the code instead of hiding from it.

Standups Are Just Mini Performance Reviews and I’m Tired of Pretending They’re Not

Let’s stop kidding ourselves. Most standups are just status reports wearing an Agile hat—a trench coat, maybe a fake mustache. We stand in a circle, or huddle in a video grid of half-frozen faces, and recite task lists nobody actually asked for. The scrum master nods along like a dashboard tracking CPU load. The product manager types furiously, probably tallying who said “blocker” three times. And the engineers? We check out the second someone starts describing a Jira ticket number like it’s a war story.

The Ritual That Ate Itself

Standups started with a decent idea: sync the team, surface real problems, keep things moving. But somewhere between the first daily and the thousandth, they mutated into a bureaucratic checkpoint. I’ve watched teams burn fifteen minutes detailing yesterday’s work, today’s plan, and what’s in their way—while the actual work stalls because nobody wants to say the uncomfortable thing out loud. Standups became a theater of productivity, where the performance matters more than the outcome.

Here’s the core problem: when standups are status reports, they serve managers, not teams. Information flows upward, not sideways. I don’t need to know that Dave refactored the authentication module unless it breaks something I’m building. And Dave definitely doesn’t need my ten-minute monologue about debugging a CSS grid issue. We’re not updating a Gantt chart. We’re supposed to be collaborating. But collaboration needs vulnerability, not bullet points.

Team standing in a circle during a morning meeting

When “What Did You Do Yesterday?” Becomes a Weapon

I’ve seen engineers prep for standups like they’re defending a thesis. They craft narratives that make their work sound impressive, hide the messy parts, and avoid admitting they spent three hours fighting a YAML indentation error. This isn’t their fault. The format punishes honesty. If you say “I struggled with something dumb,” the room goes quiet. The product manager starts recalculating deadlines. The tech lead files a mental note about your competence. So you learn to say “made progress on” instead of “banged my head against.”

This turns standups into a subtle interrogation. Status-report standups create a culture where visibility trumps value. People optimize for sounding busy rather than being effective. They break tasks into smaller pieces just to have something to report. I once worked with a developer who would deliberately save a finished pull request for the morning so he could announce it at standup. The dopamine hit of acknowledgement was real. The team’s throughput? Not so much.

The worst part is how these standups erode psychological safety. When every day is a mini performance review, nobody admits they’re stuck until it’s too late. Blockers become confessions. And the most valuable conversations—the ones where someone says “I have no idea what I’m doing”—never happen in the circle. They happen in Slack DMs afterward, when the cameras are off.

Developer looking frustrated at a laptop screen

The Real Engineering Problem Is the Social Contract

Engineering culture treats standups as a technical process when they’re actually a social ritual. We obsess over the format: should we go left to right? Alphabetical? By ticket status? None of that matters if the underlying agreement is broken. The social contract of a standup should be: “We’re here to unblock each other and align on the most important thing.” Instead, the contract is: “We’re here to prove we’re working.”

Signs Your Standup Is a Status Report in Disguise

You can spot the sickness easily. If your standup has any of these symptoms, it’s already dead:

  • People talk to the scrum master or manager, not to each other.
  • Updates are detailed enough to fill a timesheet.
  • Nobody interrupts with “wait, can we pair on that?”
  • Side conversations about actual work happen only after the standup ends.
  • Quiet engineers say “no blockers” every day because it’s safe.

What’s funny—and by funny I mean infuriating—is that we know this. Every retrospective, someone mumbles that standups feel like a waste. Then we tweak the format: fifteen minutes max! Walking standups! Async standups in Slack! But we don’t change the fundamental purpose. It’s like optimizing a function that returns the wrong value. The bottleneck isn’t the ceremony; it’s the expectation baked into it.

Async Standups: The Coward’s Escape

Some teams flee to asynchronous standups, posting updates in a Slack channel. I get the appeal. No scheduling, no awkward silences, no pressure to perform in real time. But here’s the ugly truth: async standups are just status reports with extra steps. You’re still broadcasting what you did to an audience that mostly doesn’t care. The difference is that now there’s a paper trail. Managers can scroll back and compare Tuesday’s output to Wednesday’s. It’s a surveillance tool dressed as flexibility.

Async standups also kill the one thing that could save synchronous ones: the spontaneous interaction. When someone says “I’m wrestling with the API rate limit,” another engineer can jump in with “oh, I fixed that last sprint, let’s talk after.” That moment can’t happen in a text thread because nobody reads those threads. They skim, they react with an emoji, they move on. You’ve replaced a flawed human interaction with a flawless data entry system.

Team looking at sticky notes on a whiteboard

What Actually Works (No, Really)

I’m not saying kill all standups. I’m saying kill the status-report version. The alternative is a standup that focuses on coordination, not accounting. Here’s what that looks like in practice:

Walk the Board, Not the People

Forget “what did you do yesterday?” Start from the rightmost column of your board—the work closest to done—and ask: “What’s blocking this from shipping?” Then move left. This shifts attention from individuals to flow. It’s immediately obvious if something is stuck because nobody’s touching it. And it stops people from narrating their personal Jira diary.

Make Blockers Emotional, Not Administrative

A real blocker isn’t “waiting for Dave to review my PR.” That’s a coordination delay. A real blocker is “I think our caching strategy is fundamentally broken and I’m afraid to touch it.” Encourage that language. If your team can’t say “I’m scared” or “I’m confused” in a standup, you don’t have a standup problem—you have a trust problem. Fix that first.

Kill the Round-Robin

Not everyone needs to speak. If two engineers are pairing on a feature, one update covers both. If someone’s work hasn’t changed since yesterday, they say “same as yesterday, no new blockers.” That’s five seconds. The goal is to leave the standup with a clear picture of where the project is stuck, not where everyone’s hours went.

Use the 80/20 Rule for Time

Spend 20% of the standup on status and 80% on the one or two items that need immediate coordination. If that means the standup ends in seven minutes, great. If it means three engineers stay behind to debug a deployment issue while everyone else leaves, even better. The standup is a catalyst, not a container.

The Culture Fix Nobody Wants to Admit

Here’s the part where I sound like a grumpy engineering coach: standups are broken because your management culture is broken. If managers demand daily visibility into individual output, standups will always be status reports. You can rename them, restructure them, hold them in VR—it won’t matter. The root cause is a lack of trust. Managers don’t trust engineers to be working. Engineers don’t trust managers to understand the work. And standups become the battleground where that distrust plays out.

The fix isn’t a new agile framework. It’s a hard conversation: “We’re going to stop reporting status to each other and start coordinating work. If you need to know what I did yesterday, look at the commit log.” Some managers will twitch at this. That’s fine. Twitching is a sign of life.

FAQ: Because You’ll Ask These Anyway

“But my team is remote. Don’t we need standups for connection?”

Connection comes from working together on hard problems, not from hearing each other’s to-do lists. If you want connection, schedule a weekly coffee chat or a no-work-allowed hangout. Using standups for social bonding is like using a fire extinguisher for a pillow fight. Wrong tool, messy outcome.

“What if the team likes status-report standups?”

Ask them if they like the standups or the structure. Often, people mistake routine for value. Try an experiment: cancel standups for a week and replace them with a fifteen-minute coordination slot focused only on blockers. Then retro it. Most teams discover they were clinging to a habit, not a help.

“How do I convince my manager to let go of daily status?”

Stop framing it as “let go.” Frame it as “replace with something more effective.” Offer a two-week trial where you replace standup status with a shared dashboard or an end-of-day summary bot. Show that the information still flows, just without the ritual overhead. If the manager resists, you’ve learned something important about their need for control—and that’s a different problem entirely.

“Aren’t you just describing a different kind of standup?”

Yes. I’m describing a standup that does what it was supposed to do: align the team on the work, not on the workers. If that sounds radical, you’ve been in too many bad standups. The ceremony isn’t sacred. The outcome is.

So here’s my plea: the next time you’re in a standup and someone starts reciting ticket numbers like a grocery list, stop them. Gently, maybe. Ask: “Is there something we can help with, or is this just an update?” If it’s just an update, skip it. The team’s collective brainpower is too expensive to waste on verbal Jira exports. Let’s treat engineering culture as the real technical problem—and debug the hell out of it.

How Most Engineering Dysfunction Starts Before Anyone Writes Code

Two engineers arguing in front of a whiteboard filled with messy diagrams

I’ve sat through enough sprint planning sessions to catch the stench before the first pull request even hits the repo. The real screw-up in engineering teams isn’t a busted algorithm or some memory leak. It’s the invisible gunk—assumptions, office politics, and flat-out laziness—that hardens weeks or months before anyone types git init. We obsess over linters and test coverage while the foundation is made of Swiss cheese, glued together by a product manager’s wishful thinking and an architect’s midlife crisis.

Here’s the part nobody says out loud: if your engineering org feels like a dumpster fire, you probably struck the match during planning, not during the sprint. The code is just the crime scene. The actual murder happened earlier, in a conference room that reeks of stale coffee and broken promises.

The “Requirements” Document That’s Really Just Fan Fiction

Most so-called requirements docs aren’t requirements at all. They’re a pile of fuzzy business wishes, user stories written by someone who’s never met a user, and acceptance criteria that basically say “make it work good.” I’ve seen 40-page PRDs that spend 10 pages on the color of a button but never define what happens when the primary API returns a 500. That’s not planning. That’s creative writing with a project management tool.

The dysfunction takes root the moment engineers nod along to a spec that’s got more holes than a block of Emmental. Why? Because saying “looks good” in the meeting is easier than spending an hour wrangling edge cases with a product owner who just wants to update their roadmap slide. Fast-forward three sprints, and you’re refactoring the entire authentication flow because nobody asked what “user” actually means when you’ve got multi-tenant accounts. Classic.

Technical Strategy by Hype Cycle

Engineering leadership picks technology the way a teenager picks a prom outfit: whatever’s shiny and racked up upvotes on Hacker News. Microservices? We’ll do that. Event sourcing? Why not. Kubernetes on bare metal, managed by a team that can’t even keep a cron job running? Ship it.

The tech itself isn’t the problem. The problem is that the decision gets made in a vacuum, usually right after a CTO watches a conference talk and feels insecure. The architecture gets sketched as boxes and arrows on a diagram that looks like a subway map drawn by a lunatic. Nobody stops to ask, “Do we actually need to solve this, or are we just bored?” By the time the code gets written, the team is already locked into a complexity death spiral. The real requirements—sub-100ms latency, zero data loss, actual uptime—never made it into the conversation. The dysfunction is baked into the architectural DNA before the first Docker container gets built.

A frustrated developer staring at a complex architecture diagram on a monitor

Team Topology as an Afterthought

Conway’s Law isn’t a suggestion. It’s a threat. If your org chart looks like a feudal hierarchy with overlapping fiefdoms, your software will look exactly like that. I’ve consulted for companies where two teams owned adjacent parts of the same feature but literally never spoke to each other. They communicated through Jira tickets and passive-aggressive comments in a shared Slack channel. The integration points were a disaster because the contract between their services boiled down to “whatever we feel like deploying today.”

This starts months before anyone writes a line of code. It starts when a VP splits a team based on headcount instead of actual system boundaries. Or when they hire a “Principal Architect” who locks himself in a room for six weeks and emerges with a 200-page design document nobody else had a say in. The dysfunction is social, not technical. You can’t fix it with nicer pull request templates. You fix it by admitting that how people talk to each other is a first-class architectural concern.

The Invisible Tax of “Temporary” Decisions

Every engineering org has a graveyard of temporary decisions that turned permanent. The weekend prototype now handling production traffic. The database schema that was “just for the MVP” but now has 50 tables and zero foreign keys. The authentication hack everyone swore they’d replace within a quarter—it’s been three years, and the CTO still gets paged when it breaks.

The dysfunction here isn’t that people take shortcuts. It’s that the organization has no way to pay back technical debt. The planning phase treats these decisions like they’re free, as if a “quick and dirty” solution won’t rack up interest. When the real coding starts, the team is already carrying a backpack full of rocks, and nobody budgeted time to take them out. The result is a codebase that’s 40% workarounds for earlier workarounds. That’s not bad engineering. That’s bad planning wearing the mask of pragmatism.

How to Spot the Rot Before It Stinks

You don’t need a crystal ball. You just need to stop lying to yourself during sprint zero. Here’s my checklist for sniffing out pre-code dysfunction:

  • Ambiguous language: If the spec uses words like “flexible,” “scalable,” or “resilient” without concrete numbers, you’re already hosed. Demand percentiles, throughput, and actual error budgets.
  • No failure modes: If the design document doesn’t have a section called “How This Can Break,” it’s a fairy tale. Real engineers think about the unhappy path first.
  • Hero culture: If the plan depends on one person who “knows the whole system,” you’re building a single point of failure, not a piece of software.
  • Date-driven deadlines: If the launch date was set before the scope was defined, the code is going to be a hostage situation, not a craft.

A team of engineers in a tense meeting, looking at a timeline on the wall

None of this is rocket science. It’s just that most orgs are too busy cosplaying as “agile” to actually have the hard conversations. Standups become status theater. Retros become blame sessions. And the real technical problem—the one between our ears and inside our org charts—gets ignored because it’s uncomfortable.

FAQ

Why do smart engineers keep falling into these traps?

Because intelligence has nothing to do with it. The traps are cultural and institutional. Most engineers are trained to focus on the code, not the system that produces the code. Add a layer of middle management that rewards consensus over correctness, and you get a recipe for collective self-deception. It’s not a bug; it’s a feature of how companies are structured.

Can a good engineering manager fix pre-code dysfunction?

Yes, but only if they’re willing to be the unpopular one in the room. A good EM has to say “no” to unrealistic dates, push back on half-baked requirements, and protect the team from the organizational chaos. That takes political capital and a spine. Most managers prefer to keep their heads down and hope sprint velocity will magically fix everything. It won’t.

What’s the single biggest red flag during project planning?

When nobody can clearly articulate the problem the project is supposed to solve. If the conversation is all about the solution—“We’re going to use Kafka!”—without a tight definition of the actual user pain or business need, run. The code hasn’t been written yet, but the dysfunction is already fully operational.

Why Your Sprint Is Already Screwed Before the First Line of Code

The Real Bug Is in the Room, Not the Repository

I’ve been at this long enough to know that most engineering trainwrecks don’t start with a null pointer or a memory leak. They start with a vague nod in standup, a ticket that reads like a ransom note, and a product manager who thinks “just make it work” counts as a technical spec. By the time anyone opens an editor, the dysfunction has already set like cheap concrete. We obsess over linting rules, test coverage, and whether we should use tabs or spaces, while ignoring the bleeding obvious: the way we decide what to build is fundamentally snapped in half.

I’m Fritz, and I treat engineering culture as the actual technical problem. Not the soft-skills nonsense HR peddles, but the hard, repeatable failure patterns that show up long before an IDE is even warm. If your team lives in a permanent state of firefighting, blown deadlines, or shipping features nobody asked for, stop pointing at the tech stack. The rot goes deeper. It’s almost always cultural.

The Ticket That Lied to You

Let’s start with the artifact that’s supposed to connect business needs to technical execution: the user story. In theory, it’s a neat, atomic chunk of work. In practice, it’s a cryptic haiku scribbled by someone who hasn’t talked to a real user since the Obama administration. “As a user, I want a dashboard so I can see my data.” Cool. What data? Why? What decision does it drive? What’s the acceptable latency—two seconds, or two minutes while I go make coffee? That ticket is a Rorschach test. Every developer reads it differently and fills in the blanks with their own pet assumptions.

The dysfunction here is the illusion of clarity. Someone barfed a few words into Jira, threw story points at it in a planning poker ritual that feels more like a séance, and called it a day. The real requirements—the edge cases, the performance constraints, the actual user workflow—are buried in someone’s skull or a five-month-old Slack thread nobody can find anymore. This isn’t a communication gap. It’s a systematic refusal to do the hard thinking before the work starts. Engineers plug the holes with guesses. Those guesses turn into technical debt before a single commit exists.

Estimates as a Weapon of Mass Delusion

Ah, estimation. That ritual where we ask developers to predict the future using gut feeling, peer pressure, and a deck of cards, then act personally betrayed when reality doesn’t cooperate. The dysfunction isn’t that estimates are wrong—of course they’re wrong, we’re building things nobody has built before. The problem is that the org treats them as commitments. A rough guess gets rebranded as a deadline, the deadline morphs into a death march, and soon your velocity chart is being weaponized to flog the team in some quarterly review.

This sets up a perverse game. Developers pad estimates to buy themselves air. Managers slash them in half to look good to their bosses. The final number is political fiction, divorced from any engineering reality. Nobody asks the hard questions: “What’s the riskiest piece of this?” “What can we drop if time gets tight?” Instead we get “How many points is it?” as if complexity can be reduced to a Fibonacci number. The real technical problem is that we’ve built a culture where looking predictable matters more than being effective. And that culture doesn’t start in sprint planning. It starts with how leadership reacts when someone brings bad news.

Architecture by Anecdote

Here’s another classic: the senior dev or tech lead who designs the whole system from their personal collection of war stories. “We’re doing microservices because at my last job the monolith was a flaming dumpster.” Never mind that your startup has three engineers and one customer who barely logs in. “We need a queue-based event system because that’s what the big players do.” Congratulations, you just tacked on six months of infrastructure work for a problem you don’t have, may never have, and probably shouldn’t want.

I call this architecture by anecdote. Decisions happen not by looking at current constraints—team size, traffic, business model—but by cargo-culting some FAANG company’s blog post from 2017. The dysfunction? Nobody feels safe pushing back with actual data. The default move is to over-engineer, because it feels safer and looks juicier on a resume. The result is a sprawling system nobody fully understands, built for a scale you’ll never reach, while your actual product-market fit remains a distant fantasy. The worst part? This gets celebrated as “forward-thinking.” It’s not. It’s resume-driven development, and it’s a cultural cancer.

The Meeting That Should Have Been an Email… But Wasn’t Even That

Meetings are the exhaust fumes of bad process. When you see a calendar choked with “syncs,” “alignment sessions,” and “working groups,” you’re staring at a system that has abandoned written, asynchronous communication entirely. The dysfunction: decisions get made verbally, in real time, and leave behind zero artifacts. So the same decision gets re-litigated every Tuesday because nobody remembers what was actually agreed upon—or worse, the one person who wasn’t in the room blocks everything later because they were never looped in.

This imposes a silence tax. Engineers who can’t or won’t thrive in rapid-fire verbal cage matches get sidelined. Ideas that need quiet, written exploration never surface. The team’s collective memory turns into a five-round game of telephone. The fix isn’t yet another recurring meeting. It’s a bloody-minded commitment to writing things down—design docs, decision records, async video updates. But that takes a cultural shift that treats writing as a core engineering skill, not a distraction from “real work.”

The Hero Complex and Its Body Count

Finally, we need to talk about the hero. The engineer who pulls all-nighters, single-handedly wrestles a production outage into submission at 3 a.m., and gets showered with public praise in the #general channel. The dysfunction here is that the organization rewards firefighting over fire prevention. The hero becomes a bottleneck and a single point of failure, but they’re celebrated because they “get things done.” Meanwhile, the quiet engineer who spent two weeks building proper monitoring, writing runbooks, and simplifying the gnarly bits gets a lukewarm performance review because their impact isn’t dramatic enough for a slide deck.

This selects for exactly the wrong behaviors. It broadcasts to everyone that the path to glory is to let things break and then swoop in with a cape. It actively discourages the unsexy work that stops incidents from happening at all. The most damning part? This hero culture is often cultivated by engineering managers who don’t know what a healthy system looks like. They see a calm, boring on-call rotation and assume nothing is happening, rather than recognizing it as the ultimate success signal. This is a cultural failure, plain and simple. It’s set in stone long before any postmortem doc gets written.

So next time your sprint goes off the rails, don’t just stare at the code. Look at the ticket that kicked it off. Look at the estimate that lied straight to your face. Look at the architecture decision made over a rushed coffee chat. Look at the meeting where the real requirement was mumbled, misunderstood, and lost forever. That’s where the bugs actually live. The compiler can’t catch those. No linter will ever flag “culturally accepted insanity.”

Frequently Asked Questions

Why do engineering teams keep making the same process mistakes?

Because we optimize for local comfort, not global outcomes. Teams settle into broken patterns because it’s easier in the short term—easier to nod along in a meeting than to write a clear spec, easier to pad an estimate than to challenge a ridiculous deadline. The pain of the dysfunction is diffuse and delayed; the pain of fixing it is immediate and personal. Until leadership treats process health as a first-class metric, the path of least resistance leads straight to chaos.

How can I tell if my team’s dysfunction is cultural or just a skill gap?

If a single sharp hire could fix it, it’s a skill gap. If you’ve hired smart people and they’re still producing garbage, it’s cultural. Look at what gets rewarded and punished. Are people celebrated for saying “I don’t know”? Are postmortems actually blameless, or do they turn into quiet finger-pointing sessions? Do decisions get written down anywhere? If the environment punishes transparency and rewards heroics, no amount of training will help. You could parachute in a world-class architect, and they’d burn out inside a quarter.

What’s the one thing I can do today to start fixing this?

Start writing. Before any non-trivial piece of work, force a one-page design doc. Not a novel—just a tight explanation of the problem, the proposed fix, the alternatives you considered, and the risks you can already see. Share it asynchronously, let people rip it apart in comments, and actually resolve those comments before a line of code gets written. This single habit surfaces ambiguous requirements, forces decisions into the open, and leaves a paper trail. It’s not a silver bullet, but it’s the closest thing I’ve found to a circuit breaker for pre-code dysfunction.

A team of people sitting around a table, looking at papers, illustrating a planning meeting that might already be off-track

Close-up of a stressed person rubbing their temples in an office, depicting the consequences of bad process

A messy whiteboard covered in sticky notes and diagrams, symbolizing the chaotic thinking before code is written

The Meeting Before the Meeting Is Where Your Project Actually Died

Look, I’ve been in this game long enough to know that most software disasters aren’t caused by bad code. They’re caused by the 47-minute Zoom call that happened three weeks before a single line was typed. The one where someone said, “Let’s circle back on the requirements,” and everyone nodded like dashboard bobbleheads. That conversation? That’s where the dysfunction planted its flag.

Two people talking in a modern office

Engineering dysfunction isn’t a technology problem. It’s a people problem wearing a Jira hoodie. And until we start treating cultural rot with the same rigor we apply to a database migration, we’ll keep shipping garbage and calling it agile.

The Pre-Code Graveyard

Walk into any engineering org and you’ll find the same damn pattern. The project kicked off six months ago. The roadmap looked gorgeous. The kickoff meeting had snacks. But now, two sprints before launch, the team is paralyzed. The backend team hates the frontend team. The product manager is rewriting user stories at 10 p.m. And nobody can explain what “MVP” means anymore, because it’s changed twelve times.

You know what went wrong? Nothing happened during development. Everything went wrong before it. The code is just the corpse.

The Blame-Sharing Ceremony

Every organization has a ritual I call the Blame-Sharing Ceremony. It usually starts with a stakeholder saying, “We need to move fast.” What they mean is, “I already promised this to a customer, so your estimates are now my hostage.” The engineering manager, terrified of looking “not technical enough,” commits to a deadline that was pulled from a motivational poster. Then the senior dev, who saw this coming a mile away, says nothing because they’re busy updating their LinkedIn profile.

This is not a communication breakdown. It’s a cowardice pipeline. And the output is a codebase that smells like fear.

The Architecture Astronaut Landing

Then comes the architecture review. Someone who hasn’t written production code since the Obama administration slides into the meeting with a diagram that looks like a plate of spaghetti and says, “We should consider an event-driven microservices approach.” For a cron job. For a single script. That sends one email a week.

The team, now trapped in a sunk-cost fallacy, spends three weeks building infrastructure that will never scale because the product won’t survive long enough to need it. The dysfunction here isn’t the complexity. It’s the total detachment from business reality. Engineers love to build engines, but nobody asked if the car needs to move yet.

A whiteboard covered in complex diagrams and sticky notes

The Real Technical Debt Is Behavioral

We love to talk about technical debt like it’s some inevitable byproduct of speed. But most technical debt isn’t from rushing. It’s from deciding things badly when you had all the time in the world. Choosing a NoSQL database because it was trendy, not because you needed flexible schemas. Splitting into microservices because Netflix does it, not because your team of four can operate them. Writing an abstraction layer so generic it can “support any future use case”—and then never having a second use case.

Those decisions weren’t made in a coding frenzy. They were made in a conference room with a projector and too much confidence.

The “Yes” Culture Tax

One of the most expensive words in engineering is “yes.” Yes, we can add that feature. Yes, we can hit that date. Yes, we can support that edge case. Every “yes” without a corresponding “no” is a withdrawal from the team’s credibility account. Over time, you end up bankrupt. The product becomes a feature junkyard. The team burns out. And management wonders why velocity dropped.

It didn’t drop. It was never real to begin with. The estimates were fiction. The commitments were political theater. The dysfunction was hiding behind a burndown chart that lied as smoothly as a sales deck.

How to Smell the Fire Before the Smoke

The good news? This stuff is detectable. If you know what to sniff for, you can spot a doomed project before the repository is even created. Here’s my personal checklist of pre-code red flags:

  • The requirements document is over 20 pages. Nobody read it. Everyone skimmed it and nodded. You’re building on quicksand.
  • “We’ll figure out the details in the sprint.” Translation: we haven’t done the thinking, but we’re already late, so let’s pretend agility is the plan.
  • No single person can describe the user’s problem in two sentences. If the problem isn’t sharp, the solution will be a blob. A very expensive blob.
  • Estimates are given in hours, not days. That level of false precision means someone is trying to control something they don’t understand.
  • The word “just” appears in every planning meeting. “We’ll just add a flag.” “We’ll just refactor that later.” “Just” is a four-letter word for “I don’t want to think about it.”

The Meeting That Should Have Been an Email (But Wasn’t)

Here’s a classic scenario. A stakeholder wants a “simple dashboard.” The product manager says, “Sure, we’ll scope it.” They call a meeting. In that meeting, someone mentions “real-time updates.” Another person says, “We should probably support mobile too.” By the end of the hour, the “simple dashboard” is now a cross-platform analytics suite with role-based access control. Nobody asked if the user actually needs any of that. Nobody asked what problem it solves. The scope expanded because people were in a room and felt they needed to contribute something.

This is how projects die before a line of code. The meeting wasn’t a planning session. It was a brainstorming epidemic. And the cure is someone saying, “Stop. What is the one thing that would make this useful?” That person? Usually not in the room.

A team sitting around a table, looking frustrated

Fixing It Before It’s Broken

So how do you kill dysfunction before it hatches? You don’t need a workshop or a framework. You need to act like an engineer even when you’re not in front of a keyboard.

First, make decisions reversible. If a choice can be undone easily, don’t spend two weeks debating it. Pick one and move. The real damage comes from locking yourself into a bad choice because you treated it like a permanent tattoo.

Second, ban vague nouns. “Performance,” “scalability,” “quality”—these mean nothing without a number. If someone says, “We need it to be fast,” ask: “What is the acceptable response time under what load?” If they can’t answer, they don’t know what they want. Don’t build it yet.

Third, reward the person who kills bad ideas early. Most cultures celebrate the hero who ships a messy feature on time. Celebrate the person who says, “This feature doesn’t make sense,” in week one. That person saved you months of pain. Buy them a coffee. Give them a raise.

Writing Code Is the Last Resort

I’ve come to believe that writing code should be a last resort, not a first reflex. If you can solve the problem with a conversation, a configuration change, or by simply deciding not to do something, do that. The best engineering I’ve ever done involved deleting requirements, not implementing them. That’s not laziness. It’s discipline.

When you treat code as precious, you treat the decisions around it as critical. And you make sure those decisions aren’t made by a room full of people who are afraid to sound stupid.

FAQ

Why do teams keep falling into these pre-code traps even with experienced engineers?
Because experience doesn’t inoculate you against social pressure. It’s easier to nod along in a meeting than to be the one who says, “This doesn’t make sense.” That takes emotional energy, and most people run out of it by 2 p.m.

What’s the single biggest predictor of project failure before coding starts?
Ambiguous ownership. If you can’t name the one person who will be dragged out of bed at 3 a.m. when the thing breaks, you don’t have a team. You have a committee. And committees don’t ship, they socialize.

Can this cultural dysfunction be fixed from the bottom up, or does it require leadership buy-in?
Leadership buy-in accelerates everything, but bottom-up change is possible if you’re stubborn. Start with your own projects. Ask obnoxiously clear questions in planning meetings. Refuse to estimate until you understand the problem. People will either follow you or get out of the way. Either outcome is progress.

Why the 10x Engineer Myth Persists Despite Zero Evidence

Every few months, some tech CEO tweets about 10x engineers and the entire industry loses its mind. The replies split into two camps: wide-eyed founders asking how to hire one, and exhausted seniors explaining that the concept is statistical garbage. Neither side changes their mind. The thread goes viral. We do it again next quarter.

Let me save you some time: there is no peer-reviewed evidence that 10x engineers exist as a distinct, identifiable category of person. The original study everyone cites—Sackman, Erikson, and Grant, 1968—measured variance in programmer productivity, not a bimodal distribution of normal engineers and superhuman ones. Some people were faster than others. That’s it. That’s the whole finding. We turned “sometimes people differ” into a recruiting philosophy.

People collaborating around a table with laptops and notes

The Origin Story Is Embarrassing

The 1968 Sackman study measured 27 programmers doing debugging and coding tasks. The best performed about 10x better than the worst on some metrics. But the study had methodological problems that would get it rejected from a undergraduate journal today: tiny sample size, artificial tasks, and no control for experience. Sackman himself warned against generalizing the results.

We ignored him. We’ve been ignoring him for 55 years.

The tech industry took “there’s variance in a small sample doing artificial tasks” and transmuted it into “there exists a rare breed of engineer worth ten normal ones, and you should restructure your entire organization to find and retain them.” This is not a scientific conclusion. This is a management wish dressed up in a lab coat.

Why Managers Need the Myth

The 10x narrative is a management convenience store. It sells everything a struggling CTO wants to buy:

It Justifies Hiring Freezes

Why hire five competent engineers when you could hire one 10x engineer? The math works out! Except it doesn’t, because that one person gets sick, gets bored, gets a better offer, or simply doesn’t know everything. But as a budget line item, “one expensive genius” looks cleaner than “a team of people who collaborate and cover each other’s gaps.”

It Explains Away Bad Culture

When your best people keep leaving, you can tell yourself they weren’t 10x material anyway. The real ones would thrive under any conditions! This is the engineering equivalent of the just-world fallacy: if someone burns out, they clearly weren’t built for greatness. No need to examine your 2 AM Slack culture or your meeting-heavy sprints. The problem is the people, not the system.

It Flatters Decision-Makers

Every manager wants to believe they have a special eye for talent. The 10x myth says: yes, you can spot greatness. You’re not just hiring—you’re curating. That’s a much better story than “I hired someone with a good GitHub profile and they turned out fine, like most people do.”

Person working intensely at a computer with code on screen

Why Engineers Need the Myth

Here’s the uncomfortable part: engineers aren’t victims of this nonsense. We’re co-authors.

The 10x label is identity armor. It lets you believe your bad habits are actually efficiency. Don’t write tests? You’re moving fast. Refuse to document? You’re coding, not writing prose. Can’t onboard new team members because “they’ll slow me down”? That’s not a collaboration failure—that’s protecting velocity.

I’ve worked with self-identified 10x engineers. Here’s what they actually were:

  • Fast typists who produced code quickly and bugs at roughly the same rate
  • Solo operators who hoarded knowledge and couldn’t be replaced without months of pain
  • Domain experts who were fast because they’d been in the codebase for five years—not because of innate ability
  • Career hoppers who burned bright for 18 months and left before the maintenance debt came due

None of these people were 10x. They were 1x people in environments that happened to reward their specific style of work. Put them in a different system—one that required coordination, or long-term maintenance, or mentoring—and they looked painfully average. Sometimes below average.

The Actual Science Says Teams, Not Heroes

Research on software productivity consistently shows that team quality and process matter more than individual star power. Google’s Project Aristotle found that psychological safety and conversational turn-taking predicted team performance, not individual IQ or expertise. A 2013 study by Prechelt found that while individual performance varies, the gap shrinks dramatically when you control for task familiarity and tooling.

The variance Sackman measured? It collapses when you give people proper environments, clear requirements, and reasonable deadlines. The “10x gap” is mostly a measurement of how badly we set people up to fail.

But “invest in better processes and tooling” is a boring slide deck. “Find the chosen one” is a hero’s journey. We keep picking the story over the science.

Group of developers working together around a monitor

What Productive Teams Actually Look Like

I’ve been doing this for twenty years. The best teams I’ve worked on had zero 10x engineers and plenty of 1x engineers who:

  • Wrote things down so decisions didn’t live in one skull
  • Reviewed each other’s code without ego, which caught bugs before they became outages
  • Pair-programmed on hard problems because two brains beat one brain almost every time
  • Left at a reasonable hour and still shipped excellent work because they weren’t running on caffeine and anxiety

These teams were consistently outperforming the “genius” teams. Not because they had better individuals, but because they had better systems. Engineering culture is a technical problem. The 10x myth is a bug in how we think about productivity.

The Real Cost of the Myth

Believing in 10x engineers doesn’t just waste hiring budget. It actively damages organizations:

It creates single points of failure. When one person is “the genius,” the bus factor drops to one. They go on vacation, everything stalls. They quit, everything collapses. This is not a strength dressed as a risk—it’s just a risk.

It discourages collaboration. If you believe productivity is an individual trait, you structure rewards around individual output. Code reviews become obstacles. Documentation becomes overhead. Mentorship becomes charity. Every hour spent helping someone else is an hour you’re not being 10x enough.

It drives out diversity. The 10x archetype is specific: young, male, obsessive, willing to sacrifice health and relationships for code. If that’s your hiring profile, you’re not selecting for ability—you’re selecting for a particular life situation that enables obsessive work. Surprise: that profile excludes a lot of excellent engineers who have kids, or boundaries, or different working styles.

So Why Does It Persist?

Because it’s a good story, and the tech industry runs on stories. The 10x engineer myth persists for the same reason most bad ideas persist: it serves someone’s interest. Managers get a simpler hiring problem. Engineers get an identity badge. Companies get an excuse for not investing in boring structural improvements.

The alternative—admitting that productivity is mostly about environment, process, and team dynamics—requires admitting that your org’s problems might be your problems. That’s a lot less fun than waiting for a savior to walk through the door.

Stop waiting. Fix the system.

FAQ

Q: But I’ve definitely worked with someone way faster than everyone else. Isn’t that a 10x engineer?

A: No, that’s someone who’s fast. Variation exists. Some people type quicker, some people have more experience with a specific stack, some people just think in a way that fits a particular problem. That’s a 2x or 3x advantage on a good day, and it’s task-dependent. The 10x claim isn’t “some people are better”—it’s “some people are categorically different, and you should restructure your org around them.” That’s the part with zero evidence.

Q: What about open-source maintainers who do massive amounts of work alone?

A: Good example, actually. Look closely at those maintainers. They’re fast because they wrote the codebase, they have no onboarding overhead, and they make decisions unilaterally. That’s not 10x ability—that’s 10x context and 10x freedom from coordination costs. Put them in a different project and they’re mortal again. The speed comes from the situation, not the soul.

Q: Isn’t it better to hire one great engineer than ten mediocre ones?

A: This is a false choice. Nobody’s arguing for ten mediocre engineers. The real question is: do you hire one expensive person and bet everything on them, or do you hire a few good people and build a system that makes them effective together? One of those strategies has redundancy, knowledge sharing, and weekend coverage. The other has a single point of failure and a very impressive LinkedIn profile.

The Oasis Reunion Is a Masterclass in Nostalgia Economics — And That’s the Real Performance

When Sixteen Years Becomes a Cultural Event

The Oasis reunion announcement last August didn’t just break the internet. It broke ticketing systems, parliamentary committees, and the collective patience of British music fans watching prices climb toward the five-hundred-dollar mark. But here’s what matters more than the chaos: we’re witnessing something genuinely rare in rock history. A sixteen-year gap between breakup and reunion. No top-ten UK chart act has ever waited longer. Not the Beatles. Not Led Zeppelin. Not the Stone Roses. That specific timeline changes what could have been a simple cash grab into something more architecturally interesting.

That gap matters because it’s not just time. It’s an entire era. Oasis split in 2009 when streaming was barely a thing, before social media weaponized fandom, before the industry hollowed itself out on touring revenue. The brothers didn’t reunite at some nostalgic sweet spot five or seven years later. They waited until everyone involved had aged enough to make this feel like a genuine rupture in continuity rather than a victory lap with last year’s choreography.

The Commodity Question Nobody Wants to Answer Directly

Let’s address the obvious tension. This is simultaneously art and commerce. Pretending otherwise is intellectual dishonesty dressed up as purity. Oasis wrote extraordinary songs between 1994 and 1997. That’s documented, achieved fact. The reunion tour sells out stadiums because those songs mean something real to millions of people. Also legitimate. But then we have dynamic pricing algorithms, UK CMA Investigation into Ticketmaster Dynamic Pricing, and North American tickets hitting four hundred and fifty dollars on the primary market alone.

The Competition and Markets Authority opened a formal investigation in October 2024. The Oasis sale sparked it, not as coincidence but as catalyst. Live Nation’s system looked at demand curves and optimized for extraction rather than access. Parliamentary inquiries followed. The Guardian’s chief music critic noted something equally damning: The Guardian Oasis Reunion Tour Review described the setlist as a museum exhibition of lad-rock artifacts. Zero songs from post-1997 across the first ten shows. Not one track from the catalog after the Gallagher brothers’ best year.

This is the revealing part. The tour isn’t selling you Oasis as a living artistic entity. It’s selling you a specific version of Oasis, frozen in 1997, commodified and optimized. That’s not inherently disqualifying. Museums do this constantly. But museums don’t use algorithms to charge different customers different prices based on predictive demand modeling.

What Gets Left Out Says Everything

Liam Gallagher’s solo album “As You Were” dropped in 2017 and became a critical success. His subsequent work maintained serious artistic credibility. Noel Gallagher’s High Flying Birds catalog is genuinely experimental. Both are conspicuously absent from pre-show playlist rotations. The Reddit community tracking this detail at r/oasis, nearly nine hundred thousand members deep, noticed immediately. They’re obsessing over what gets performed and what doesn’t because the setlist is the text. The message is the medium.

What gets excluded from a reunion tour tells you precisely what the reunion is designed to be. This one says: we are selling you 1997. We are not selling you what happened after. We are not selling you the work you might have discovered when you were too young or too uninterested to follow real-time. We are selling you the version of yourselves you want to remember. The version before complications. Before doubt. Before the brothers became solo artists with their own credible trajectories.

That’s a specific artistic choice, and also a specific commercial calculation. The genius of dynamic pricing is that it makes this calculation invisible. You don’t feel the algorithm. You just feel the price shock and assume it’s supply meeting demand. The price justifies itself through its own existence.

Nostalgia As Infrastructure

Here’s what confuses everyone about this moment: nostalgia isn’t a dirty word in art criticism. It’s a tool. Scorsese weaponizes nostalgia. Wong Kar-wai constructs entire films from it. There’s nothing inherently wrong with a band reaching back to their strongest material and performing it with full production value. People came to hear those songs live. That’s an exchange with real cultural weight.

The problem isn’t the nostalgia. The problem is when nostalgia becomes infrastructure for price extraction. When the emotional resonance of 1997 gets weaponized by algorithms to determine what you can afford. When the absence of newer material becomes a feature rather than a limitation. The Oasis reunion tour is asking audiences to pay premium prices for a museum exhibition. That’s the honest transaction. But the pricing mechanism never actually makes that explicit.

Imagine if museums charged variable admission based on demand modeling. If your biometric data suggested high willingness to pay, the Rembrandt cost more. That would be dystopian. Nobody would accept it. Yet this is exactly what’s happening in venues worldwide, normalized because it hides inside the language of market efficiency.

The Performance That Matters Most

Sixteen years is long enough for context to matter. When Oasis split in 2009, they were unfinished business. When they reunite in 2025, they’re historical artifact. The brothers have lived separate lives. They’ve made separate art. They’ve aged differently and changed. The reunion isn’t the same as the original because nothing is the same as the original. That’s not a failing. That’s just time doing what time does.

The real artistic question isn’t whether they should have reunited. It’s what they’re choosing to perform and why they’re making those choices. A sixteen-year gap creates artistic permission to evolve. Instead, they’re curating a museum exhibition. Maybe that’s the right call. Maybe audiences want exactly that. But the performance deserves scrutiny beyond nostalgia, and the pricing deserves scrutiny beyond economics. Both reveal something about how we’ve decided to experience art in the 2020s.

What’s your take? Is the reunion a legitimate achievement in rock history or a textbook example of commodified nostalgia dressed in premium pricing? And more specifically, does the absence of post-1997 material feel like creative vision or commercial limitation? How we answer those questions determines what we accept from artists going forward.

MoMA’s Basquiat Retrospective: A Reckoning With Genius, Money, and What We Owe Dead Artists

The Scale of the Question

MoMA opened its doors to over 200 Basquiat works in late 2025, and the art world did what it always does: immediately split into camps. One side sees a long-overdue institutional validation of a visionary who died in 1988 at twenty-seven. The other sees a calculated move designed to capitalize on a secondary market that has grown 22 percent year-over-year. Both are right, which is precisely why this show matters.

This retrospective ranks among the largest solo exhibitions of Basquiat’s work ever mounted in North America. That’s not hyperbole. We’re talking about a scale that lets you track his evolution from raw street urgency to sophisticated conceptual rigor across entire galleries. The sheer amount of material here forces a different conversation than smaller, curated shows allow. It’s harder to cherry-pick a narrative when you have this much work in front of you.

But here’s where the tension starts to feel real. MoMA reported over 3.2 million visitors in 2024, with blockbuster retrospectives like this one driving roughly 40 percent of those attendance spikes. The math is inescapable. Museums need bodies through the door. Artists need institutional platforms. The market needs validation. And somewhere in that triangle, the work itself gets squeezed.

The Authentication Mess Nobody’s Talking About

Before we get too comfortable praising the institution for finally giving Basquiat his due, let’s talk about the elephant in the room: the Jean-Michel Basquiat Authentication Committee was dissolved in 2012. Years of disputes followed. In 2022, the Supreme Court of New York ruled on authentication practices and estate governance issues that would make your head spin if you spent five minutes reading the legal filings.

What does this mean for a retrospective featuring over 200 works? It means provenance suddenly matters in ways that casual visitors might not immediately grasp. Every piece in this show carries its own small history of verification, dispute, or acceptance. Some of these works have been questioned. Some have been fought over by collectors, estates, and researchers. The MoMA curators presumably did their homework, but authentication remains contested territory, and that adds an uncomfortable layer to the whole enterprise.

This isn’t to say the show is riddled with fakes or that MoMA is being reckless. It’s to say that the institutional confidence radiating from a retrospective this size obscures ongoing debates in the field. When you package 200 Basquiats under a prestigious roof, you’re making a statement about authenticity whether you intend to or not.

The Market Question That Won’t Go Away

In 2017, a single untitled Basquiat from 1982 sold for 110.5 million dollars at Sotheby’s. It remains the auction record for any American artist. That number exists in the cultural air now, a kind of gravitational force pulling every Basquiat conversation toward money talk. You can’t really escape it, and anyone who pretends they can is being naive.

Art market analysts at ArtTactic Art Market Reports documented a 22 percent year-over-year increase in Basquiat secondary market sales heading into 2025. Some of that surge is organic collector interest, sure. But some of it is speculative energy. The kind that asks: what does a major institutional retrospective do to valuations?

Here’s what nobody wants to admit openly at dinner parties: the museum exhibition and the auction house are locked in a feedback loop. A retrospective boosts cultural capital. Cultural capital attracts collectors. Collectors drive prices. Higher prices attract more speculative interest. The museum gets credit for elevating an artist. Everyone wins except the conversation itself, which gets flattened by all this momentum.

The question isn’t whether MoMA is intentionally collaborating with the market to inflate Basquiat prices. That’s too conspiratorial and probably unfair. The question is whether it’s possible to mount a show this ambitious without contributing to a speculative environment. I don’t think it is.

Why You Should See It Anyway

And yet. And yet and yet and yet.

Over 200 works in one space lets you see patterns that smaller exhibitions hide. You can watch Basquiat’s engagement with text evolve from aggressive, declarative statements to something more ambiguous and layered. You can see how his color palette shifted. How his relationship to the figure changed. How he moved between pure abstraction and representational imagery, sometimes in the same painting. These are conversations you can only have when you have volume and proximity.

There’s something worth defending about giving an artist this much institutional real estate, market implications notwithstanding. Basquiat died at twenty-seven without ever seeing a retrospective of this scale. He never got to walk through a museum and see his entire trajectory laid out. That’s gone now, obviously, but the retrospective itself becomes a kind of conversation with what he might have become if he’d lived. That matters.

The show is also a gateway. If you’ve never sat with Basquiat’s work seriously, if you’ve only encountered it through Instagram or auction house press releases, this is your invitation to form your own opinions. Bring your skepticism. Bring your market cynicism. But bring yourself, too, because the work is still capable of refusing easy categories.

The Uncomfortable Truth

So is MoMA’s retrospective a triumph or a posthumous cash grab? It’s both. It’s neither. It’s an institution doing what institutions do, mediating between artist legacies and market forces and public access, all simultaneously and with no clean way to separate one from the other.

The real question isn’t about MoMA’s motives. It’s about what we choose to do with the access we’ve been given. Are we going to let the market narratives swallow the work whole? Or are we going to treat this show as an opportunity to reckon with what Basquiat was actually trying to do, beyond the auction house drama?

You can check the MoMA Exhibition Archive for details. Go with questions. Go skeptically. Go ready to argue. The work demands nothing less, and frankly, neither should we.

The Strike That Nearly Was: What Broadway’s 2025 Contract Fight Reveals About Theater’s Broken Economics

September’s Narrow Escape

In September 2025, the lights of Broadway almost went dark. Not metaphorically. Literally dark. Forty-one theater houses sat on the edge of a full shutdown as Actors’ Equity Association negotiated with the Broadway League over contract terms that would define working conditions for the industry’s most visible performers. The stakes felt apocalyptic because they were. A strike during the fall season opening would have obliterated one of the few remaining moments when Broadway still commands genuine cultural conversation.

But then something remarkable happened. They reached a deal. A last-minute agreement that averted catastrophe and handed Equity members a 14% wage increase across three years, pushing the Broadway minimum from $2,418 to roughly $2,757 per week by the contract’s end. Relief flooded the industry. Producers exhaled. Theater blogs declared victory for labor. The narrative wrapped itself up in a neat bow.

Except the story that actually matters didn’t make the headlines. The near-strike exposed something far more damning than any picket line could have. It revealed that Broadway’s economic foundation is rotting from the inside.

The Illusion of a Boom Year

Start with the topline numbers because they’re seductive. The 2024-2025 season generated $1.87 billion in total grosses. Read that figure at a cocktail party and watch people’s eyes widen. Broadway is thriving. Broadway is back. Broadway is the last bastion of live performance in an age of screen addiction.

Dig one layer deeper and watch that narrative collapse. Sixty percent of productions failed to recoup their capitalization costs. That’s not a minor correction. That’s not a statistical wobble. That’s six out of every ten shows losing money. Let that sit for a moment. An industry generating nearly two billion dollars in revenue while the majority of productions hemorrhage cash is not a sign of health. It’s a sign of profound structural dysfunction.

The mathematics are particularly brutal when you consider what it costs to mount a Broadway production in 2025. Capitalization budgets have exploded. The economics demand massive advance sales just to break even on opening night. Which means producers need stars. Celebrity names that move the needle before a single review publishes. Which means the economic pressure filters down through the entire system, creating a perverse incentive structure where household names command premium salaries while ensemble members and understudies scramble for survival.

The Equity Member You Never Think About

Here’s where context becomes devastating. According to a 2025 Princeton University study on arts labor, the median annual income for Equity union members across all performance contracts remained below $25,000. Read that alongside the Broadway minimum wage triumph and feel the cognitive dissonance snap into place. Broadway contracts represent less than 8% of all Equity work. The overwhelming majority of professional actors earning union scale are pulling together a living from regional theater, touring productions, commercial work, and whatever survival gigs keep them housed between contracts.

A 14% wage increase on a Broadway contract that represents less than 8% of your work might buy you a nicer apartment for three months per year. Or it might buy you nothing at all if you’re not cast on Broadway that particular season. The near-strike negotiation captured the headlines. The structural problem that makes most theater jobs economically nonviable barely registered as a conversation. This is not a failure of the negotiators. It’s a failure of the industry to ask itself harder questions about sustainability.

Equity members were right to fight. The wage increase matters. But it matters primarily to the relatively small cohort of performers who actually land Broadway contracts. For the rest of the union, the economy remains a precarious scramble punctuated by periodic victories that feel hollow when you’re calculating whether you can afford health insurance for the next quarter.

Celebrity Casting as Economic Necessity and Industry Scourge

The 2025-2026 season crystallized the problem nicely. Productions starring major film actors like Anne Hathaway in ‘Smash: The Musical’ accounted for a disproportionate share of advance ticket sales. This is not surprising. It’s also not particularly interesting as cultural observation. What’s interesting is recognizing this as a symptom rather than a cause.

Broadway’s reliance on celebrity casting isn’t some passing fad driven by nostalgia or lazy audience taste. It’s an economic inevitability created by production budgets that have become structurally unsustainable without the guarantee of opening-week sales that only marquee names can deliver. A producer cannot afford to gamble on an unknown actor of extraordinary talent when the show needs to clear a seven-figure deficit before the reviews even run. The system incentivizes risk aversion at the precise moment when risk-taking creates art worth experiencing.

This creates a secondary economy where A-list film actors capture disproportionate compensation while everyone else competes for scraps in an overcrowded labor market. It’s not because casting directors prefer celebrities. It’s because the math demands it. You can argue about whether this is good or bad for Broadway as an art form. But you cannot argue that it’s sustainable as currently constructed. Eventually the audience interest in seeing celebrities on a Broadway stage will plateau, the metrics will stop working, and the entire edifice will require rebuilding.

What the Near-Strike Actually Exposed

The September negotiations succeeded because neither side benefited from a strike. But examining why both sides wanted to avoid shutdown reveals the actual crisis. The Broadway League Industry Statistics show an industry where 60% of shows fail financially. That’s not a healthy market correcting for duds. That’s an industry fundamentally broken at the production level. Producers can’t afford strikes because they’re operating on razor margins. Equity members can’t afford strikes because too many of them are already economically precarious.

The real conversation we should have had in September is uncomfortable. It asks whether the current model of Broadway production is viable at all. It asks whether capitalization costs have spiraled beyond rational investment parameters. It asks whether an industry that generates $1.87 billion in revenue while losing money on six out of ten shows has a mathematics problem or a philosophy problem.

The contract that was negotiated was the correct one given the constraints of the system. Equity members deserved that wage increase. But the near-strike was a warning light that we collectively ignored. The system isn’t broken because of labor disputes. It’s broken because it has become fundamentally misaligned with the economics of sustainable production. The next near-strike, and there will be one, may not end as neatly.

Color Field Painting Is Having a TikTok Moment and the Gatekeepers Are Panicking

The Numbers Don’t Lie, Even If They Puzzle the Institutions

Here’s what happened: somewhere between a studio walkthrough and a satisfying time-lapse of paint pouring across canvas, Color Field painting became the TikTok equivalent of a sleeper hit. The #ColorFieldPainting hashtag accumulated over 870 million views by early 2026, which is to say the movement that dominated American abstraction in the 1950s and 60s is now, inexplicably, getting more eyeballs than most contemporary art being made today. The creators pushing this trend aren’t museum professionals or art historians. They’re 20-somethings filming themselves staining raw canvas with translucent washes of fluid acrylic, channeling Helen Frankenthaler and Morris Louis through their phone screens.

The establishment response has been predictably fractured. Some curators see a genuine renaissance brewing. Others treat it like a kitschy fad that’ll evaporate once TikTok’s algorithm pivots. But the data suggests something more structural is happening. The Helen Frankenthaler Foundation reported a 212% spike in website traffic between January 2025 and January 2026, directly attributable to social media virality. That’s not a marginal bump. That’s institutional infrastructure struggling to absorb genuine public interest in a previously insider conversation.

Meanwhile, Golden Artist Colors reported a 40% year-over-year sales increase in fluid acrylics during 2025, with company representatives explicitly crediting the Color Field trend on social platforms. Art supply companies don’t make claims like that lightly. They track the material reality of what people are buying, what they’re making, what’s actually moving through their systems. The medium itself is experiencing a genuine surge.

The Secondary Market Doesn’t Care About Your Authenticity Concerns

Here’s where it gets interesting: Sam Gilliam, a Color Field painter whose work has historically occupied a strange blind spot in the movement’s canon, watched his mid-career pieces appreciate an average of 28% in 2025. Not Rothko. Not Louis. Gilliam. A figure whose absence from major institutions was less about quality than about curatorial gatekeeping and the persistent racism that shaped post-war American art history.

The secondary market doesn’t negotiate aesthetics. It responds to demand signals. When collectors start hunting for Color Field works beyond the obvious titans, when auction houses see real bidding wars over artists who’ve been unfairly sidelined, that’s capital flowing toward correction. It’s crude, sure. It’s also honest in a way that art world consensus-building rarely is.

This creates a productive tension. The same TikTok creators filming liquid abstraction are inadvertently rewriting which artists matter and why. They’re not citing the canon. They’re building their own adjacencies, their own genealogies. Some of that will be garbage historical thinking. Some of it might actually be more rigorous than the version they inherited.

The Washington Color School Finally Gets Its Moment

The Smithsonian American Art Museum is mounting a major exhibition dedicated to the Washington Color School legacy in 2026, examining the movement’s overlooked significance and regional specificity. This is institutional energy that wouldn’t exist without the viral moment preceding it. Whether you want to credit TikTok or argue that curators were always planning this reassessment, the timing is too convenient to ignore.

The Washington Color School represents something the current moment desperately needs: a movement that was genuinely radical in its minimalism, that refused the psychological intensity of New York School painting, that asked whether abstraction could be joyful and decorative and conceptually rigorous all at once. It was sidelined not because it lacked merit but because it didn’t fit the narrative of artistic progress that critics and institutions decided to champion.

What’s happening now is a slow unwinding of that curatorial logic. TikTok creators making process videos aren’t reading academic articles about postwar abstraction. They’re just responding to the visual pleasure of stained canvas, the meditative quality of pouring paint, the basic human satisfaction of making something that reads as intentional through accident. That’s actually closer to what Color Field was always about than much of the theoretical apparatus that subsequently calcified around it.

The Authenticity Police Are Exhausting and Missing the Point

Every discourse like this produces its constituency of worried gatekeepers: people insisting that true understanding requires rigor, that mass appeal dilutes significance, that democratizing access somehow diminishes the work itself. They’re wrong in interesting ways.

Yes, a TikTok creator doing a 60-second studio video isn’t engaging with Color Field painting at the level of, say, Michael Fried’s theoretical work or the way Louise Bourgeois thought through abstraction. Fine. But they’re not claiming to be. They’re inviting thousands of people to develop taste, to experience the sensory reality of this work, to potentially care enough to move deeper into it. That’s not a lower register of engagement. It’s a different one. Sometimes different is actually what movements need.

The infrastructure now exists to follow that spark. A kid in Ohio sees a TikTok of stained canvas, orders supplies, starts experimenting, gets curious about the history, eventually visits a museum or reads something substantive about Frankenthaler’s technical innovations or seeks out the Smithsonian’s 2026 exhibition. That pipeline seems more likely now than it did two years ago. Whether it produces better understanding or just more coffee table books about abstraction remains to be seen.

What This Actually Reveals About How Art Moves Now

The Color Field renaissance is less about the internet discovering late modernism and more about a fundamental shift in how cultural authority operates. TikTok didn’t create a new audience for abstraction. It just bypassed the middlemen who typically gatekeep that conversation. Museums, galleries, critics, academic institutions: they’re no longer the sole arbiters of what matters or why.

That terrifies people whose entire professional identity is built on scarcity of taste. It should. But it also opens possibilities. Secondary markets are correcting years of historical oversight. Institutions are finally examining movements they’d categorized and filed away. Younger artists are engaging with Color Field not as historical obligation but as active tradition. Is some of this superficial? Absolutely. Plenty of the TikTok engagement will be forgotten in six months. But the 212% spike in foundation traffic, the 28% price increases, the institutional reassessments: those suggest something more persistent is gestating.

The question isn’t whether TikTok’s version of Color Field painting is authentic or rigorous enough. The question is whether we’re finally ready to have public conversations about abstraction that don’t require institutional permission to start. Everything else is just noise.