DEV Community: Matt Hogg

Vibe Coding Is Bad News For Good Ideas

Matt Hogg — Tue, 17 Mar 2026 00:00:00 +0000

There’s something about reckless “AI” use, and vibe coding in particular, that’s bothered me for reasons I’ve never quite been able to put my finger on until now. Indulge me as I rant about our total disregard for constraints and the good ideas that come from them.

I’ve noticed that the creator of Claude Code, Boris Cherny, is mentioned relentlessly on social media by users with feedback. Cherny has a developer relations role to play, yes, but he’s also actively developing a product. And, boy, do folks have opinions on that product!

I find it cringe that any ol’ terminal jockey can come in from the cold and pitch him their very particular edge case. Cherny likely disagrees with me. Not only does he respond and engage with the feedback he’s also automated the triage—and fixes—for anything posted on Threads, Slack, or Github. OK, then.

I don’t think this is sound engineering or product development. Vibe coders mistake productivity for product. I worry about “AI” boosters bragging about the former instead of focusing on the latter Lately it feels like it’s more about the quantity of ideas done, and not the quality of ideas considered.

This is yet another reminder that using AI doesn’t make the product better, when you don’t have a team that is customer-obsessed / product obsessed.

And a team that is customer/product-obsessed without AI (or very little AI) will still run laps around one with AI…
— gergely.pragmaticengineer.com

Should an implementation be this fast and easy? Should execution be this deceptively cheap? (Psst, it’s subsidized.) It’s not just that we puny humans suffer “brain fry” and can’t keep up cognitively. Throughout the creative process, eliminating the role of constraints and limitations is a tragic misstep.

I have talked to quite a few vibe coding companies who are proud of their super rapid development.

None of them seemed to know what “product development strategy” means or what will happen after you paid them for the first delivery.
— mistakenotmy

Constraints and creativity go hand in hand. Leonardo da Vinci proclaimed, “Art lives from constraints and dies from freedom.” Orson Welles was once heard to say, “The enemy of art is the absence of limitations.” Serial entrepreneur Biz Stone wrote, “Constraint inspires creativity.”

Green Eggs and Ham exists because Seuss’ editor bet him $50 that he couldn’t write an engaging children’s book using only 50 distinct words. It’s now one of the most famous children’s books in the English-speaking world.

Of course, we’re talking about tech that’s predicated on consuming everything and then generating anything we ask for. Shame on me for being so naive, eh? “AI” isn’t remotely interested in constraints. “AI” doesn’t encourage restraint in its use.

When I see vibe coders running wild and loving it, I feel like Dr. Ian Malcolm in Jurassic Park, pounding on the table and whispering, “Your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should!”

For one thing, not every idea is worth pursuing. The vast majority of ideas will be tepid, dumb, dangerous, or hardly worth the effort in a hundred little ways. What does it mean to never say no, fire up a dozen simultaneous agents while you head off to the gym, and build a mediocre app that does everything?

If the effort is zero and you implement every single idea then I’d argue you don’t actually have any meaningful ideas. You have no vision and what you’re building isn’t refined nor intentional. What are you making? Do you know why?

your org rarely has good ideas. ideas being expensive to implement was actually helping
— thdxr

For another thing, people are way too excited about optimizing for a bottleneck that never existed. Our coding capacity was never a problem. I’ve previously argued that a developer’s job is not to write code but this isn’t what I meant! We have many duties before and after the part where we’re typing, and none of that’s solved with vibe coded slop.

The irony is that when we trivialize the technical effort then the entire project is at existential risk. Vibe coding makes things far worse, and we don’t yet know the impact of relying on it as we have been. The developers on your team serve as an intentional bulkhead against bad ideas, and you don’t have a viable business without that. Christopher Fitkin muses:

When building was expensive, that friction acted as a filter (saving companies tons). Now more mediocre ideas get built… and costs tick up, up, up.

I’ve read some effusive posts about vibe coding from former colleagues where the thinly veiled insinuation is, “Just LOOK at everything I can do now that I don’t have developers getting in my way!”

My god, is that what you thought of me and my teams all this time…? We’re indeed a constraint. But do you see us as impediments rather than fellow problem solvers? On behalf of every developer I’ve every worked with, fuck that. Do you think we want to be Debbie Downers when we start chewing on your ask and a million questions and details rise to the surface? Have you ever thought that perhaps it’s the sign of a truly engaged developer who gives a shit? That maybe constraints matter?

The number of times I’ve had jr devs or sr pms basically say how hard could it be? Guys, the code is the easy part. What not to code is the part we get paid for.
— dave_minnigerode

I’m genuinely saddened to think we’re no longer able to entertain even a tiny bit of restraint and collective self-discipline. It’s a shame that we now see constraints as obstacles that have plagued us instead of conditions that shape better solutions.

I consider software engineering to be an act of curation—why not ship one awesome thing rather than 10 tired clichés smothered in defects, security holes, and accessibility problems? I think aviator slash writer Antoine de Saint-Exupéry said it best:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

We’re far from perfection; we’re in the midst of a mass delusion. People are software bonkers and proud of it. I’ve seen former colleagues now openly ponder if maybe traditional requirements are obsolete. Wut. You’ve heard of requirements, right? You know, also known as constraints?!?

Look, I can totally understand how vibe coding can feel empowering. It’s novel tech that seemingly bends space and time to provide you with skills and throughput you’d never have otherwise. That is indeed futuristic!

Everyone who ever cornered a developer at a party to tell them about a great app idea is now able to vibe code it and discover for themselves why the developers they talked to all said the idea wouldn’t work.
— glenatron

But a lot of this is brute force marketing and investor razzle dazzle, obscuring the fact that “AI” is patently bad at good ideas. We’re still going to need humans to supply those.

I’m waiting to see a truly good idea come out of vibe coding. All this limitless firepower and you’ve reinvented accounting software. Yay? Replacing the SaaS product that annoys you the most isn’t innovation. Making yet another to-do app isn’t novel. Building data dashboards doesn’t make you a renegade. Generating your own bespoke software is good for you but it’s very likely not a good idea.

It’s almost as if the lack of constraints isn’t helpful.

It’s entirely possible I’m wrong. Maybe what it means to create software is radically changing. I have serious reservations about code quality and craft, but OK. I’ll cross that bridge when I come to it. I’ll grieve and I’ll adapt.

But other things will change along the way. Right now I’m far more concerned that we’re also fundamentally redefining what it means to just, like, have an idea. This feels like a pretty big prerequisite to all other paradigm shifts that “AI” might signal. I hope we get it right. I don’t have any solutions here. Well, maybe one—I’m sure as hell not going to ask any LLMs for their ideas.

Wherein I Find Myself Writing About Writing

Matt Hogg — Sat, 06 Dec 2025 00:00:00 +0000

Most everyone finds writing to be challenging (especially those who say they enjoy it). This is because writing is an intentional, thoughtful act. This is as it should be, but “AI” has recently exacerbated the misbelief that writing is simply an output. In fact, it’s a creative process that has merit in and of itself.

For some time I’ve been sitting on the idea of writing about my personal rules for the essays I publish. I use this space to work out ideas that get stuck in my head a little too long. I tend to focus more on the human side of software development and such topics should be evergreen and less likely to be ephemeral or trendy.

Your writing is a reflection of your thinking.
– rands

I’m kind of breaking that last rule by writing this essay (and it’s not the first time). As much as I’ve been waiting for the “AI” bubble to pop, I just can’t ignore the damage it’s inflicting before that day arrives.

It’s precisely because I interpret the act of writing as human thought made tangible, after considerable effort, that I find “AI” so inappropriate and unqualified for the task. Writing is thinking. As long as machines are incapable of the latter they should never do the former.

Unfit For The Job

When we understand the mechanics of a Large Language Model (LLM) it’s evident they’re not thinking. LLMs can do certain things quite well enough but we have to know their quirks and limitations and tailor our use accordingly. Laurie Voss reminds us that LLMs are “good at transforming text into less text” which is nowhere near the same thing as writing:

Is what you’re doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it’s probably going to be great at it. If you’re asking it to convert into a roughly equal amount of text it will be so-so. If you’re asking it to create more text than you gave it, forget about it.

There’s no magic here. If I ask an LLM to produce an entire document out of thin air it doesn’t actually do that—it needs excessive prompting and data. The most original writing any LLM has ever produced is still derivative. By definition an LLM will never produce a wholly original idea.

Most of us aren’t inventing cold fusion or faster-than-light travel but I’d like to think at least some of my energy at work is spent on unique or novel ideas. I won’t be getting that from a document my coworker passes to me while mentioning they used “AI” to write it. Laurie Voss again:

LLMs only know what you tell them. Give it a short prompt and ask for long text and you will get endless waffle, drivel, pointless rambling, and hallucinations. There is no way to get an LLM to perform the thought necessary to write something for you. You have to do the thinking. To get an LLM to write something good you have to give it a prompt so long you might as well have just written the thing yourself.

I’m not abdicating this much responsibility (i.e., thinking) to a machine that’s unfit for the job. I likely wouldn’t do so even if the effort were near zero. As it is I have to micro-manage the LLM, validate its output, and also ignore the ethical, environmental, political or economic impacts of it all? Great tool, thank you!

We devalue those jobs traditionally centered around writing—copywriters, translators, journalists, and even developers—only to discover later that these tasks require true skill and humans have to be brought in to fix the machines’ work.

Most people assume LLMs to be more sophisticated than they are (i.e., they turn “text into less text”) because our general perception is that writing—almost all writing—is a chore or an end product. We ignore the complexity—and value—of the process itself and just want a document in our hands as soon as possible.

Side Effects May Include…

The so-called promise of “AI” really capitalizes on this notion and incentivizes us to optimize for the wrong thing. This is affecting us in many ways that have only recently become apparent.

We really don’t have consensus on its utility. The most powerful people in society like “AI” more than the rest of us. A recent study by Dayforce found that 87% of executives are using “AI” regularly while only 27% of employees are. Holy shit! We know that executives are somewhat divorced from reality and don’t really understand the day-to-day of their own businesses. Most leaders aren’t even aware this gap exists at all!

Workslop is on the rise and we hate each other for it. The phrase “workslop” is truly inspired. However, the more we use “AI” to create passable facsimiles of written work the more everyone else has to deal with it. Productivity suffers and resentment festers. The irony is your workslop is consuming everyone else’s time and energy. Even worse, if you do this to your coworkers they’re struggling with how to tell you to knock it off. It erodes mutual trust or respect. Workers haven’t been this annoyed with each other since we started reheating fish in the company microwave for lunch.

“AI” is altering how we communicate. When it comes to language, we’re screwed no matter what. We mimic an LLM’s style (accidentally or not) just because it’s part of the zeitgeist now. We avoid the use of certain punctation or turns of phrase to distinguish ourselves from the machines. Either way, we’ve ceded territory that belonged to us. I, for one, will have my precious em dashes and Oxford commas pried from my cold, dead hands.

“Only AI uses emdash”

Sorry babe, some of us are just literate
– ewdatsgross

It’s fucking lazy. I’m sorry, it just is. I can’t tiptoe around this point. There’s the good kind of lazy and there’s just plain ol’ lazy. Know the difference.

“AI” makes us feel inadequate. When “AI” appears in our software toolbars and panels there’s a heavy insinuation that I don’t know how to do my fucking job. Nowadays I’m not even granted the dignity of a blank canvas. A new document comes pre-loaded with “AI” calls to action (e.g., “Generate document”, “Help me write…”, sparkles everywhere). The iconoclastic designer Mike Monteiro examines this (and more) with zinger after zinger in his talk “How to draw an orange”…

Every single human being has an intrinsic capacity to create—write, draw, sing, dance, glue things to other things—from a very young age. Sadly, a great many people “grow up” and lose this over time. It never goes away entirely, however, and we can reclaim it. It’s just hard-earned.

Choosing Friction Can Be Cool, Man

I don’t always know where I stand, down to the last detail, on appropriate “AI” use but I agree with this sentiment from Frank Chimero:

Where do I stand in relation to the machine—above it, beside it, under it? Each position carries a different kind of power dynamic. To be above is to steer, beside is to collaborate, below is to serve.

Well, if we want to be “above it” that doesn’t come for free. Any degree of creative autonomy (not just writing) comes at some cost but that’s the point. We have to work those muscles continually. We have to do some hard work. A colleague of mine, Jenny, believes we should be choosing friction.

If you can push a button and get a screenplay or a symphony or a painting at the cost of a nominal subscription fee that does not begin to cover the true expense of this technology to the world, if you did not have to at least subconsciously face your mortality and decide that the pursuit of this piece of art is what you want to spend your finite time on, if your desire to speak is not strong enough to overcome the friction of learning how to speak, is it something that needed to be said?

Bravo! Writing is a deliberate decision that reflects and refines our thinking. There’s no optimization for that. Even that work email you’re composing presumably needs to be sent, and therefore friction is a prerequisite. But the process itself has value because proper space was reserved to just think.

Neuroscientist here… creativity is a process. A process. A FUCKING PROCESS. Not an output.

Nobody is gatekeeping the process – AI simply invites you to skip to the end, to the output. Which, as mentioned, is not creativity.
– drrachelbarr

“AI” can really muddy the waters. An LLM can’t think and therefore it’s not a tool that’ll encourage us to think for ourselves, at least not by default. Still, the grifters will pretend otherwise. In the meantime we’re left wringing our hands and having multiple existential crises about it. Cultural norms and beliefs are forming around this, slowly, and not all of them are favorable. We enjoy calling it “slop” for a reason! This feels to me like a very good opportunity to make “AI” utterly gross and uncool.

Do Not Fuck With Miyazaki

We can take our cue from the great director and animator Hayao Miyazaki. In March 2025, OpenAI boasted about its new image generation capabilities by encouraging people to turn their selfies into anime characters according to Miyazaki’s famous style. Everybody did it, had a chuckle, and it was offensive.

Miyazaki’s animation is done by hand. His films require hundreds of thousands of drawings each. He wears a goddamn apron to work! The results are magical and this is precisely what makes him one of our greatest storytellers. Of course, “AI” devoured his entire body of work and now you can skip over all that fluff. Output over process, right? This is the kind of shortcut that Miyazaki has spent his entire career resisting on principle.

Some years ago a few young upstarts showed Miyazaki an AI model that could automate movement for computer generated figures. There’s a deadly pause before he responds to the demo and absolutely murders them with his words. You can watch for yourself—here’s the infamous video.

“Well, we would like to build machine that can draw pictures like humans do.” I’m sorry, what was that? Did they really say that in front of the king himself?!? Get the fuck outta here.

What Only Humans Can Do

Another director, Bong Joon Ho, recently offered another very direct opinion that, um, straddles the line:

My official answer is, AI is good because it’s the very beginning of the human race finally seriously thinking about what only humans can do. But my personal answer is, I’m going to organize a military squad, and their mission is to destroy AI.

I’m not sure about the military squad but I agree that the silver lining could be a greater awareness of our human potential. I’m hopeful but we have to outlast the CEOs, grifters, boosters, and cheapskates to get there.

“AI is clearly sticking around so you have to get used to it” wrong. I don’t have to get used to shit. I am a practiced hater and I can keep this going for decades if I am required to
– cuteosphere

Contrary to what my chosen field and university degree might imply, I very much prefer working with people over machines. In my experience the most challenging part of creativity in group settings is plain ol’ communication, and much of that is written. Let’s avoid shortcuts in our writing that will do more harm than good.

As for my personal writing on this site you should consider this essay, and many more to come, as my act of protest against the “AI” hype. I will happily labor over each word, sentence, and paragraph. Is it hard work? Yep. Is it expedient? Nope. Is it worthwhile? Maybe don’t ask anybody on Hacker News or Reddit. But I’m not writing for them, am I? I’m writing for me and my very human mind.

My Working Principles For Managing Ego, Empathy, And Humility

Matt Hogg — Sun, 23 Nov 2025 00:00:00 +0000

This essay is half of a 2-part series about ego, empathy, and humility for developers and technical leaders. For thoughts on why these principles matter at work, you might also enjoy A Unified Theory Of Ego, Empathy, And Humility At Work.

The ego can be an amorphous thing. Empathy and humility are lofty ideals. So, it can seem daunting to figure out how to manage them at work. The good news is that there many tools in our toolkit to choose from and iterate. The pay off, big or small, will be immediate.

In my previous essay on the subject I kept it theoretical. I made the point that our egos are burdens while empathy and humility are tools for the pursuit of information in the name of solving problems as a group. In this essay I’ll outline the principles that have worked for me when following this premise.

This advice isn’t just for coping with feelings or emotional stress. While that alone would be nice enough, they’re also actionable rules for effectiveness through managing your ego and focusing on empathy and humility. The principles are:

Questions before statements
Strong opinions weakly held
Be your own ~~worst~~ first critic
Act like an apprentice
We are not alone
Accentuate the positive
Always take the high road

Questions Before Statements

Starting with a question instead of a statement will set the tone for the entire discussion that follows. The former will get you key information from the outset while the latter has the potential to put people on the defensive.

I like to open as many conversations as I can with a question that essentially asks, “What am I missing here?” I can eventually make my point but it will be better informed when I do. And that’s if I still need to make my point—the right question will often satisfy both sides and negate the need entirely. And, no, leading or rhetorical questions don’t count! Try to ask genuine, open-ended (i.e., not yes/no) questions.

someone once told me “emotional intelligence is just the art of not saying the first thing your ego wants to” and honestly that just rewired my brain.
– simiianand

When doing code review, for instance, a system like Conventional Comments favors this approach and makes it a truly collaborative exercise. The pull request author has slightly more context than the reviewers (i.e., it’s their work) so ask questions instead of making dogmatic statements and blocking the pull request outright. I’ve found this so effective that I’ve even used similar “prefixes” when speaking face-to-face.

This approach also helps us keep an open mind when working with legacy code. There’s a big difference in utility between complaining, “This code is shit!” versus asking an old-timer, “What led us to implement it this way?”

This is adjacent to the idea of active listening where the goal is “listening to understand” rather than jumping in to make your point. When you do get a chance to speak, all the better if your response is a clarifying question rather than a counterpoint.

Strong Opinions Weakly Held

It’s much easier to default to questions before statements when you have strong opinions weakly held.

This concept, first described by Paul Saffo, is a heuristic for turning an imperfect or incomplete conclusion into something better. We convert uncertainty into certainty but with less bias. If you accept the premise from my previous essay that everything is bigger than you then this is the uncertainty you’re trying to root out.

To do so we must genuinely challenge our own assumptions. No opinion should be so sacred that it can’t be amended when we uncover new information. When we actively try to prove ourselves wrong we can prevent the tight coupling of our identities with our work (a.k.a. ego). Code review is the perfect opportunity to practice this—you’re not defined by your code. Code review helps you become a better programmer, if you let it.

At the end of the day we’re all looking for the best ideas. That’s not likely to come entirely from within every single time, is it?

Be Your Own Worst First Critic

Saffo actively looked for moments to try and prove himself wrong and make his stance more robust. It’s a good idea to be the first critic of your own output—emails, meetings, documentation, pull requests, and so on. You don’t have to be cruel to yourself, but if you poke just a little bit your communications become significantly more efficient.

Was chatting with a Senior Staff Eng[ineer] about how to become better at writing. We agreed that you need to be your own critic first to write well. Again, I saw a similar opinion when chatting with an ex-Meta Distinguished Engineer … He said, “To write well, you need to read well.”
– ryanlpeterman

Before you smash the “send” button ask yourself, “Is what I’ve typed out true?” It’s fine to be subjective so long as all parties recognize it. Otherwise, a little due diligence is in order. Checking yourself before someone else does can greatly improve—or even prevent—your message. To this end I personally make it a habit to draft most of what I write “offline” first, including seemingly inconsequential Slack or Teams messages.

This is harder to do for verbal communication but it’s still worthwhile. In meetings you can take notes while someone else is speaking and try to formulate your thoughts. On video calls you can open a new browser tab and quickly look something up. And you can always pause a moment before answering a question—the silence won’t kill you.

Besides fact-checking yourself it’s also useful to consider what comes next. Whatever you send or say, what’s the most likely response you’ll get? Typically it’ll be a follow-up question or some sort of task. Try to anticipate this, revise your message to account for it, and cut out at least one back-and-forth. One of these statements is more empathic than the other:

“We have a problem!!!”
“We have a problem, but we’re going to…”

Lastly, I can’t stress enough that “AI” will not adequately assess or correct your writing for you. This is a purposeful, thoughtful act and nothing is gained by farming it out it to a machine that lacks context or emotion.

Act Like An Apprentice

Most great developers I’ve met share a common trait in that they love learning new things. Whether it’s tinkering in their off hours or rising to a new challenge at work, it demonstrates humility. I think we should be transparent about this with our coworkers and act like apprentices out in the open.

There will always be something we don’t know. Our skill set is never perfectly complete. Something that’s trendy today could be obsolete tomorrow. It’s best to be candid about it. Others will appreciate your curiosity and might even help you on your particular learning journey.

You can act like an apprentice no matter how senior you are, too. There’s a lot to learn from peers and those junior to you, no matter how much experience you think you have. For example, I perfected my hiring philosophy quite late in my career, based on the insights of great coworkers. They were simply better at it than me and my eyes were open enough to recognize it.

The pursuit of learning isn’t just about skills. You should be actively learning about yourself, too. Seek out constructive feedback and look at criticism as an opportunity to improve. We learn more when we’re wrong (and told about it) than when we think we’re right.

We Are Not Alone

The whole point of practicing empathy and humility is that you don’t work alone in a vacuum.

This means that all of us are leading each other by example whether we realize it or not. So, it’s best to model the behavior we’d like to see and do so as intentionally as possible. This applies for leaders and non-leaders alike. The more we show ownership, take responsibility, admit mistakes, ask for help, or offer support the more others will do the same.

The result will be a prosocial environment that fosters psychological safety. Everyone feels comfortable participating, asking questions, and putting forth ideas. We don’t do this just to be nice. This is how we effectively solve problems in group settings. I’ve seen firsthand the stark difference between my department, where people felt safe with each other, and other departments where people absolutely did not. More importantly, my people could see the difference, too.

Once you have this safety net, you must use it! As my friend Anthony says:

You’re not alone. You have teammates, leaders, tools, and experts—an entire army ready to move with you.

Leaders need to do a little more when modeling empathy and humility. Make sure you’re the one speaking the least. Show vulnerability. Be self-deprecating. Trust your people. Replace “you” with “we”. Foster inclusion by looking for underrepresented voices and make sure everyone at the table has a chance to be heard. Lastly, find peers at your level that you can commiserate with when you need it.

Accentuate The Positive

Managing group dynamics isn’t straightforward. This is especially difficult for a group that may be challenged, stressed, or otherwise under pressure. When we’re heads down trying to get work done it’s very easy to focus on what’s going wrong and not on what’s gone right.

Make it a point to pause often and celebrate victories together, no matter how small they may seem. Often you’ll have to remind somebody of their own accomplishments and break them out of their tunnel vision. A little recognition can go a long way.

This is not something we should rely on only leaders to do. Anyone can recognize a win when they see it, even if it’s strictly from their point of view. These moments should also be celebrated. If anything, gratitude might even land better coming from a peer than from a leader!

You shouldn’t ignore setbacks or failures, of course. They need to be acknowledged openly so that lessons can be taken from them. That in itself is a positive thing.

The golden rule is to praise in public but coach in private. Positive comments should be frequent and seen by the entire group while criticism should be held for 1-on-1 settings. Even well-meaning feedback could be embarrassing if it’s given in front of others, and it won’t stick. If you actually want somebody to correct for something then coach them in private.

Research suggests the ideal ratio of positive comments to criticism should be 5-to-1. You don’t have to walk around waving pompoms all day, but it’s good to be mindful of this balance. Again, it’s not just to be nice. When it comes time to give criticism it’ll be better received because you’ve already worked to build trust and respect with them. An emphasis on the positive mitigates the negative before it arrives.

Always Take The High Road

The sad truth about this essay is that there’s no guarantee that anybody else will play ball with you. We can’t presume that anyone we work with is similarly interested in acting with empathy or humility. You must put away your ego even if nobody else is doing the same.

This means avoiding politics, pettiness, excessive gossip, or improper backchannels. When someone is throwing their ego around, you’ll be tempted to match them and fight fire with fire. Do not engage! Do not stoop to their level! Never take the bait! Hold the line! Always take the high road!

“It costs nothing to be kind!”

I’m sorry but what are you talking about, it’s the most expensive and dangerous thing in the world. That’s why people who remain kind in all circumstances are such heroes, they’re giving of themselves and voluntarily making themselves vulnerable.
– jasonkpargin

I don’t give this advice lightly and I can’t sugarcoat it— it will be exhausting but it’s worth it in the end. It will sometimes feel unfair in practice but empathy and humility always win. Use them even when nobody else is—especially when nobody else is.

I’ve evolved these tips, tricks, and habits over many years. My progression has been so gradual that it wasn’t until recently that I fully realized there might be a unified theory hiding underneath my hard-earned habits.

I hope somebody finds this insightful in some way, but don’t take my word for it. I’m humble enough to recognize that what’s worked for me may not work for you. That’s the beauty of it. Just start by recognizing that everything is bigger than you and we’re all trying to solve problems together. See what techniques you can then come up with to leverage that awareness.

Don’t be afraid to try something or make mistakes. Despite all of the above, I still get it wrong sometimes. I’ve misspoken, had tiny outbursts, and overlooked a detail someone was putting right in front of my face. It’s OK. Humans are not perfectly known quantities, and that includes ourselves.

Trust in your genuine attempts to improve yourself, and trust that others around you will recognize the same. My final piece of advice, therefore, is to make sure you extend some empathy to yourself, too. Do your best, and good luck!

A Unified Theory Of Ego, Empathy, And Humility At Work

Matt Hogg — Sun, 23 Nov 2025 00:00:00 +0000

This essay is half of a 2-part series about ego, empathy, and humility for developers and technical leaders. For advice on how to execute the ideas in this essay, you might also enjoy My Working Principles For Managing Ego, Empathy, And Humility.

In our daily lives empathy and humility are obvious virtues we aspire to. They keep our egos in check. Less obvious is that they’re practical skills in the workplace, too. I think, for developers and technical leaders in particular, that the absence of ego is the best way to further our careers and do great work.

In the simplest of terms the ego is the characteristic of personhood that enables us to practice self-reflection, self-awareness, and accountability for the actions or decisions we take.

However, the ego also motivates us to reframe our perception of the world in whatever way keeps us centered in it. Each of us is perpetually driven to justify our place in the world. This constant self-justification is like an engine that idles for our entire lives, and it requires constant fine-tuning. When it runs amok this is what we call a “big” ego.

Breaking News! Developers Have Egos!

I’m not thinking only of the 10x engineer stereotype, although I’ve worked with such folks in the past. Ego is more nuanced than that. Besides the most arrogant developer in the room throwing their weight around, our egos manifest in hundreds of ways that are much harder to detect.

As developers we’re more susceptible to letting our egos run free. The nature of our work is so technical that to others it can seem obscure, arcane, or even magical. Sometimes we don’t do enough to actively dispel that notion—and just like that half the work of self-justification is already done for us.

Very often it’s not intentional. The simplest example is the overuse of jargon and acronyms. We all do it, but as Jeremy Keith explains:

Still, I get why initialisms run rampant in technical discussions. You can be sure that most discussions of particle physics would be incomprehensible to outsiders, not necessarily because of the concepts, but because of the terminology.

Simply mashing a few letters together can be empowering for ourselves while being exclusionary for others. It’s an artifact—albeit a small one—of our egos. We know what the technobabble means. Our justified place in the universe is maintained.

Sometimes we express our egos more deliberately. Developers have a clear tendency towards gatekeeping. For most, it’s an honest mistake. There’s a fine line between holding others to a certain expectation versus actively keeping people on the outside. When we see ourselves doing this we can correct it easily enough.

Sadly there are developers who seemingly like to gatekeep. They get to feel like wizards in their towers with their dusty books and potions. But, it’s actually self-limiting. Gatekeeping by definition means you’re fixed in place and never moving, standing guard for eternity.

Gatekeeping is always weak, unless you’ve been hired to literally guard a gate.
– shanselman

My point is our egos can “leak” in so many ways that it takes diligence to catch it let alone correct it. The following is a short, incomplete list of typical statements we as developers might say or hear at work. If you parse them more precisely each one is an attempt at self-justification:

“That’s the way we’ve always done it.”
“It’s not that complicated! You just…”
“Yeah, I should be able to finish this in a day.”
“This legacy codebase is an absolute disaster.”
“Assign it to me. Nobody else will be able to fix it.”
“You can’t be a senior dev. You don’t know anything about…”
“Ugh, our morning standup is so useless.”
“This feature is too important to assign to the junior dev.”
“We should start using this new tool in our pipeline.”
“We should never use that new tool in our pipeline.”

Everything Is Bigger Than You

The ego is concerned with the self but very easily becomes something harmful in the absence of new information or context. Indeed, the ego nudges us to self-justify so much that one could argue it actively resists new information when left unchecked.

You may have read one of the example statements above with some familiarity and thought, “But what if I’m right?”

To which I’d say: OK, but should that be your default stance? Why might you feel the need to immediately start a conversation with a self-justification? There are ways to adjust our approach, make our points, and accept new information all at the same time.

In any interaction—be it a meeting, Slack thread, or water cooler conversation—we must remember that the matter at hand is bigger than us in ways we don’t yet understand.

This is a simple enough heuristic but we need the skills to gain that understanding. We need empathy and humility. Empathy is the ability to recognize and comprehend what someone else is thinking or feeling. Humility is a resistance to our “competitive reflexes” through the practice of emotional neutrality and vulnerability. Both serve to counteract the ego.

To make these concepts more actionable I find it simpler to define them in terms of the purposes they serve. Specifically…

Empathy is how we gather new information.
Humility is how we allow information to change our behavior.

This framing also helps remind us what empathy and humility are not. It’s not about putting yourself in another’s shoes, as the saying goes. It’s not about being submissive or a pushover. It’s not about altruism or self-sacrifice. We can easily practice empathy and humility without it ever being at our own expense.

The Pursuit Of Information

I don’t know about you but I go to work to solve problems, be creative, and build shit. I can’t think of a single instance where an unruly ego solved anything I’ve worked on. Ego just makes an existing challenge worse. Solutions require information I don’t have yet.

Empathy and humility are usually top of mind during situations of pain or distress, but they’re really aspects of emotional intelligence that should be activated at all times. Once you adjust your mindset to treat them as basic tools for the pursuit of information you’ll see opportunities to leverage them everywhere.

Early in my career, I thought my job was to find bugs and enforce standards. But when I started asking, ‘What’s blocking you from delivering quality?’ everything changed.
– kato-coaching.com

Developers can apply this mindset with almost anybody they come into contact with. Fellow developers, naturally. But also less technical teammates (e.g., QAs, designers, product owners, stakeholders) who have their own unique skills and context that our success depends on. And of course our users should be at the center of every problem we’re working to solve. Lastly, even executives and upper management have some insight to offer if you dare (but only up to a certain point).

“Be Curious, Not Judgmental”

I’ve been waiting years for a chance to work Ted Lasso into one of my essays. Today’s the day, readers.

The titular character is such an archetype for leadership that my jaw hit the floor when I first watched the show. The example Ted sets has spawned countless think pieces about leadership and management. Suffice it to say he exhibits all of my principles over the series’ 34 episodes. He’s empathy and humility sporting a mustache. He’s the absence of ego personified.

I highly recommend watching the show but to get a taste this 5 minute clip is worth your time. This is the famous “darts scene”…

There’s a common and derisive attitude that qualities like empathy or humility are signs of weakness. You have to get all up in your feelings. Ew! But they require enormous reserves of strength, patience, and determination. It’s those who follow their egos who are weak.

Empathy is exhausting because you have to feel in both directions.
– rands

Letting your ego take control is the easiest thing in the world. Just ask any toddler throwing a temper tantrum. Resisting those impulses and remaining calm, on the other hand, has been a virtue humanity has aspired to for thousands of years. As the Roman emperor and Stoic philosopher Marcus Aurelius wrote: “The nearer a man comes to a calm mind, the closer he is to strength.”

You’re Neither Ted Lasso Nor A Roman Emperor

The practice of empathy, humility, and keeping your ego in check will test you daily. The feedback I’ve received the most from my coworkers is that I’m extraordinarily calm and even-keeled in any situation—even situations where I’d be right to freak out.

Is that just naturally my personality? Maybe in part, but remaining calm is a choice. I’m actively choosing to favor solutions over my own ego. To my colleagues past and present I confess to you now that any time you’ve seen me calm, cool, and collected I was very likely internally screaming.

If this sounds like a lot of work you might be wondering if it’s worth it. I think it is. At the very least your coworkers and colleagues will like you better. That’s no small thing.

That people like working with you is a skill I see many technical people ignore yet it is often the biggest thing holding them back in their careers.
– carnage4life

In all seriousness, the positive feedback I get most about the developers I manage is when they’ve demonstrated empathy and humility while dialing back their egos. This is because they’re people we can work with—literally. Nobody wants to work with a narcissist or a rock star. Nobody is materially impressed by how many lines of code we wrote, or how fast we wrote it.

When people want to work with us—or even look forward to it—that means we have trust and respect. We’ll be on proper footing for working effectively as a group to solve problems. For developers this looks like coaching a junior developer, hopping on a quick call to pair with somebody, or understanding the business value of the next backlog item. For leaders this looks like people who feel empowered to do their work, who can proactively identify issues, or who can rally and adapt when circumstances change.

Anybody can do this! I can’t think of any other career advice that’s as universal as empathy and humility. Everybody is capable of, at any point in their lives, small yet impactful improvements.

So remember—watch your ego and look for opportunities to leverage empathy and humility in the pursuit of information so that you can solve problems together.

In my next essay on this subject I’ll get into the practical. What I like about this advice is that, while there’s much we can do, we don’t have to do it all to see some benefit. We can pick and choose and try something out. We can take your time and grow. Nobody’s perfect, not even Ted Lasso. Even if we take after a character like Roy Kent we can still call that a win. Just watch the show, OK?

How To Care About Your Job When It Doesn't Care About You

Matt Hogg — Mon, 23 Jun 2025 00:00:00 +0000

We all want to do awesome things and make an impact at work. However, what we call “work” is a relationship between employer and employee that’s inherently and persistently designed to benefit the former over the latter. How do we meaningfully contribute, earn a living, and maybe even enjoy ourselves when the organization simply does not care about us?

It’s harsh, but that’s captialism, baby! Any organization (“org”) exists for a purpose that’s greater than the individuals within it (e.g., profit, public service). We are a means to that end. Same goes for anything we personally get out of the arrangement be it salary, experience, foosball tables, or free lunches.

This precarious and lopsided power dynamic manifests itself in our day-to-day in a variety of weird ways we often take for granted. Even if it never gets to something as extreme as layoffs or restructuring we still have to navigate this as best we can.

We need to do our best work possible all while one tiny fact looms in the back of our minds. At the end of the day we’re just line items on somebody’s spreadsheet.

Hundreds Of People In A Trenchcoat

One prevailing assumption that crumbles under the slightest scrutiny is that an org is a cohesive entity. We all know deep down it’s merely a collective made up of people, and yet we overlook this all the time. Heaven help us all if the company refers to itself as family. Ugh!

If an employer ever says “We’re like a family here” what they mean is they’re going to ruin you psychologically
– Kevin Farzad

The head of the collective—executive leadership—isn’t a single brain. It could be 3, 5, or 7 brains all trying to act like a cohesive unit. But if you personally had 7 brains inside your head how do you think you’d come across to others? Companies are not rational actors.

Anything an org does is just an emergent property of humans trying to work together. Organizations, especially large ones, are not optimizing for complete or perfect decisions. They’re optimizing for as much alignment and consensus as they can get to keep moving (sometimes by fiat).

By necessity these decisions will always be suboptimal and that will infuriate workers who care about what they do. Most of these decisions will not make sense because we can’t interpret a collective action as if it came from an individual. Rich Gilbert nails it in his great video “Caring Less About Work can get us what we really want”:

If you’re going to work and and you’re getting frustrated and you’re intelligent and you’re looking around at all the dummies around that are not making the right decision, that is by design.

We can plead, “How could they DO this?” or complain, “This is a dumb decision,” but executive leadership really is at arm’s length to us and our work. Leadership lacks the detail we regularly see in the course of our work and they’re dealing in the abstract. Actions from leadership will therefore often feel extreme, sudden, swift, half-baked, reactive, fickle, or temperamental.

The ultimate effect is that the org doesn’t care about us. One could even argue that it cannot care about us. An org is operating on another plane of reality entirely. Whatever it “does” says nothing about the individuals along for the ride. We’re better off not trying to interpret its actions too closely, lest we break our brains.

Corporate Dick Moves

Most of the time Hanlon’s razor explains the dysfunction we see, but the nature of orgs can also provide temptation or cover for some willful disregard and gaslighting.

A good example of gaslighting might be a lack of true upward mobility. Does the company promote often? Or does it say it will and then take forever to actually do it? How about raises—do they even happen and how are they calculated? Does the company promote from within or does it recruit a higher position with a new joiner?

That’s the carrot, but the stick is far worse! We’re always on the chopping block whether we know it or not. Not even management or the CTO are safe. Layoffs are ever-present and come in several forms.

If we’re unlucky enough to work somewhere that does stack ranking (e.g., Microsoft, Meta, Shopify) we can kinda sorta at least see it coming. Yay? Despite all evidence to the contrary CEOs absolutely love this shit. They definitely do not care who’s let go and for those who remain—until the next quarter—they don’t care about the paranoia or distrust it causes.

When I interviewed at Meta, they had me do interviews with four engineers, seemingly chosen at random from within the company. The last guy had been there by far the longest. I asked him “What’s it like to work there?” and he said “Oh, working here will rewire your brain.”
– Matt Boyd

Maybe stack ranking is too cumbersome… Probably best to just do layoffs arbitrarily. The company doesn’t even need to be in trouble! Entirely profitable companies can do layoffs, often more than once and with impunity. It’s a great flex for shareholders—so trendy that the stock price might go down if CEOs don’t do it. WTF? As Anil Dash notes this is more than just cutting costs:

Big tech CEOs and VCs really love performing for each other. We know they hang out in group chats like high schoolers, preening and sending each other texts, each trying to make sure they’re all wearing the latest fashions, whether it’s a gold chain or a MAGA hat or just repeating a phrase that they heard from another founder.

The “return to office” push is another such trend. There’s no positive intepretation for it that has any basis in our post-2020 reality. Even supposing it’s not a “quiet layoff” it’s still not good. Executives continue to poke this bear—up to a full 5 days a week in a physical office—and when we go along with it then the org knows it can do almost anything it wants to us.

And perhaps the darkest trend in recent times is the holy grail for CEOs—not hiring people in the first place.

when a leader says human workers are a source of “bottlenecks”, and that automation is the source of “solutions”, pay very, very, very close attention
– Ethan Marcotte

If people think “AI” can meaningfully replace human developers, we’re in for a reckoning very soon. For one, we need junior developers and senior developers cannot exist in a vacuum. A generational talent gap is coming. For another, worsening software quality will erode and ruin companies. We’re left to ride this wave until orgs finally comprehend that developers do more than just produce code.

We’re Cogs In The Machine

Ahem, that last section got a little negative! However, a sober acknowledgment of the circumstances around us is the first step in loving our jobs.

Yes, really. We can throw up our hands and lament that we’re just cogs in the machine, but I prefer to turn that idiom on its head a bit. It’s an apt metaphor.

I’m just one gear of many. I have limited capabilities as do my neighbouring gears—I can rotate clockwise or counterclockwise. When I do something my neighbours react in turn, and vice versa. We come in different sizes and shapes resulting in differences in torque transmission, rotational speed, and so on.

My direct neighbours are very obviously cooperating with me as our teeth are interlocking. Conversely, the further away a gear is from me the less direct, and evident, our influence on each other becomes. The overall machine from my point of view begins to act strangely, resists me, or jams up completely.

This actual machine would certainly be useless if it were real. The point is there’s little sense in struggling over the distant cogs but there’s plenty to focus on right around us.

The concentric circles of concern, influence, and control, popularized by Stephen Covey, is a famous framework for personal effectiveness and decision-making that translates extremely well to the context of an org. The org overall is our circle of concern—it completely surrounds us but is so far removed that we can only observe and adapt to it in relatively minor ways.

Think Globally, Act Locally

What this means is we can put the overall organization and its shenanigans in the back of our minds while we optimize our local relationships and maximize our job satisfaction with real people and meaningful tasks. This is within our circle of influence. Namely, this is our manager, our reports, and our peers or teammates.

We should figure out what our manager needs in order to perform their job and then become their ally towards those causes. This feedback loop builds trust very quickly and we’ll feel more empowered. Our boss also acts as a “canary in the coal mine”—if they’re comfortable in the org maybe we can be, too.

Quick note: the advice above only works if our boss is a true leader and has our backs. If they’re driven by ego or more interested in licking executives’ boots, fuck 'em.

If we ourselves have direct reports, then we practice servant leadership and put as much energy into these relationships as we can. Listen to them every day, figure out what they need, and collaborate with them on those actions. I know I became the leader I am today thanks to my reports.

Obviously we spend most of our time with our fellow developers, designers, architects, QAs, product managers, analysts, and so on. These are the people, on a daily basis, that we want to impress and be impressed by. Ideally, they’re just plain fun to hang out with, too!

Never underestimate how much job satisfaction can be derived from the mutual respect and admiration among people who like each other and are operating at the top of their game.

This is the real company that we work for, as it were. It’s a subset of the overall org that we can readily interpret because none of it is abstract. It also means we don’t have to withdraw or disengage under the crushing weight of organizational nonsense. There will always be a venue where we can practice core principles—empathy, support, excellence, collaboration, camaraderie—and that means we can still grow our careers and our networks.

Yep, You’re A Resource—Valuable And Finite

Once we’ve drawn our local boundaries we know where to best apply ourselves. However, we also need to understand our individual boundaries, or rather how much we apply ourselves. This is within our circle of control.

We start by not volunteering at work. We already have a job that we get paid for, so anything beyond that is extra work and in case I haven’t been clear so far—the org won’t care.

Despite our best intentions, such work will be thankless and the law of diminishing returns will slap us in the face so hard we’ll get whiplash. We can do ourselves some serious lasting damage if we don’t exercise a healthy level of self-discipline.

If you push yourself to your limits and burn out for a company, you are trading years of your future productivity for minor gains in the present.
– Max Nichols

This isn’t the same as coasting, holding back, or phoning it in. There are plenty of ways to do a lot of good work within our circle of control. Indeed, it’s the only thing we truly control—applying our skills and abilities and getting direct satisfaction from that.

There will always be times where we feel an urge to do more than asked, show some initiative, or simply seek appreciation from those beyond our circle of influence. We can indulge these urges, if we want, but we must be mindful. Whenever we’re doing extra work it should be clear to us why we’re doing it.

The simplest (and least likely) reason to “volunteer” ourselves is because the org compensates us for it. What? It could happen! Maybe.

Telling my boss “yes,” when they asked if I speak Spanish fluently and following it up with, “but not for free,” has been the highlight of my day, so far.
– Nani 🏹

Alternatively, we can “compensate” ourselves. We can always do extra work as long as we’re getting something out of it. This runs the gamut from acquiring a new skill to optimizing an annoying workflow bottleneck to securing our team’s delivery of a long-awaited feature.

Whatever the reason or result, any extra work is a courtesy we extend to ourselves or our circle of influence. We should always assume that only we (or our teammates) will appreciate it. If that’s not enough to justify the effort then we don’t do it.

This threshold of what constitutes extra work (or if we should do it) will be personal. The calculation will vary per person. Some can tolerate a great deal if the pay is good, while others can’t. Others will risk burning themselves out doing small favors for everybody, and others won’t.

To each their own, I say. We can’t feel guilty or less of ourselves when we see somebody else’s circle of control is different than our own. We can only define it for ourselves and work happily within those confines.

Gee, Thanks…?

We should be careful about counting any vague, top-down forms of recognition as fair exchange for extra work or validation that we’re doing a good job.

If we’re doing great work everyone will know because our circle of influence (manager, reports, peers) will be singing our praises. Word will spread. We don’t need to actively seek out credit or accolades by trying to do more.

Either way, the slippery slope here is that an understanding of your contributions loses valuable detail at the org level. By definition, the wider our reputation the less control we have over its interpretaton. The org doesn’t care about us, so when all is said and done even the brightest star at the company will still be a resource.

If you always deliver, they’ll always lean on you. And the more efficient you are? The more you get exploited.
– WorkWell

This perverse form of “recognition” could backfire on us in several ways. We might become the subject matter expert for some arcane legacy system or a new feature that requires constant maintenance. We risk getting typecast as “The Only Person Who Knows How To Do X”. We’ll get saddled with an additional workload or a new role we don’t actually have the bandwidth for.

Again, we might actually be OK with such recognition—some could be legitimate career opportunities—but let’s not fool ourselves into thinking it’s true gratitude on the part of the org.

Job Seeking As A Hobby

However much we ingratiate ourselves with the org nothing is guaranteed. Despite the many YouTubers who naively pontificate on how to become recession-proof or dodge layoffs whenever the org flinches, no single company is going to save us. We have to be ready to save ourselves, and at any moment.

This means job seeking on a casual and continual basis. Treat it like a hobby. Yes, even if we have a job already. And yes, even if we love that job.

Think of the activities we do almost exclusively when we’re between jobs and do them on a smaller scale more regularly. Keeping our resume up to date, for instance, is far easier if we document our accomplishments as they happen.

We can also practice other activities like staying in touch with colleagues, researching companies and their cultures, attending meetups or networking events, and even doing interviews!

A low key job search can help in a few ways. For one, should we suddenly find ourselves unemployed we’re better prepared. We’ve already done some of the legwork that’d feel much harder to do in the moment. Any practice we’ve done also comes across as confidence to potential recruiters and interviewers.

Second, it’s a chance for introspection and self-awareness. We’ll come to know more clearly what we like or dislike about our current job. It will also help to identify what we’re capable of and what we expect of ourselves or others. Useful for future jobs, yes, but this understanding makes us better at our current job, too.

If nothing else, it might just cheer us up from time to time. I’ve had more than one Very Bad Day that found me cruising jobs on LinkedIn during my lunch break. And at one particularly toxic company I had a draft resignation later open for a couple of months. Whenever the job wore me down I’d edit it a bit more. You know, as a treat! By the time I actually sent that letter it was bulletproof and very satisfying.

Ultimately, proactive job seeking like this provides us with confidence, autonomy, and options.

Sorry, One More Thing About Executives

I’ve tried very hard to describe organizational behavior on its own terms and not as the deliberate intent of specific people.

Just like us, executives have a role to play as part of the org, too. They may benefit from the system more than we do but they’re subjected to it all the same. Your CEO might actually be a nice human being. Most of them are! Elon Musk, on the other hand, is a demon wearing a meat suit. It’s the billionaires—and leaders who emulate them—that we need to worry about.

So, I don’t have any useful advice for Musk, Bezos, Zuckerberg, or Altman. For anyone else in a leadership position I can only hope you looking into every nook and cranny of your org, seeing the people working for you, and doing right by them as best you can.

You Do You

I’ll admit I started writing this while in a somewhat bitter mood. However, it was a good exercise in helping me firm up some positive and actionable lessons. I find it reassuring that how I navigate an org doesn’t have to contradict my personal principles or how I work. In fact, they’re the very tools I need.

I firmly believe that we can find a way to exist—flourish, even—without the org eroding our personal values. We don’t want to be naive, but that doesn’t mean we just give in to cynicism.

I hate my job. The work sucks. The people suck. The pay sucks.
looks up and sees motivational poster on wall
Well this changes everything
– Dr. Bucky Isotope, PhD BOFA Economics

The steps seem simple enough. Make peace with the fact that any org is an irrational entity that always exists on the periphery. Focus our attention and effort on our circle of influence. Maintain rigorous and healthy personal boundaries. Always be ready to move on.

It sucks that we have to do so even if we like where we work or feel like we’re doing well. It’s human nature to worry less about our well-being when the risks or costs are not evident or immediate. However, things are lovely until suddenly they’re not. Protect yourself.

My promise to you is that there will be far more good days than bad days. Ultimately, the fact that your job doesn’t care about you is liberating! It’s not personal. You do you.

My promise to myself is that I’m going to spend less time accommodating the company and more time empowering myself. Less time worried about what the CEO thinks and more time worried about how my coworkers feel. Less energy trying to save the world and more time simply being proud of myself and my work.

Wherein I Find Myself Concerned About Sparkles

Matt Hogg — Wed, 15 May 2024 00:00:00 +0000

This trend of using sparkles (✨) as the visual metaphor when slapping “AI” onto our products has been bothering me lately. It’s not just sketchy to pass off large language models (LLMs) as something magical. There are also deeper implications here about how design plays into Big Tech’s desired narratives.

You’ve seen it, I’m sure. Every company under the sun has aligned on the sparkles to represent their “AI” features: OpenAI, Apple, Google, Notion, Miro, Atlassian, Spotify, Adobe, Grammarly, Zoom, Wix, and more. All the cool kids are doing it.

The emoji itself is decades old and is basically a cultural export of Japanese mobile provider NTT Docomo. Ever since it’s proven to be surprisingly flexible and adaptable—used to convey a wide variety of sentiments like sarcasm, emphasis, positivity, delight, wonder, and magic. Somewhere between 2016 and 2020 this “magic” symbolism was first applied to tech products and that’s where we find ourselves today.

“Dad, why do we use sparkles as the icon for AI?”
“Because ChatGPT came out and designers were amazed, so they chose an icon to show how amazed they were.”
“So the icon isn’t about the AI, but people’s reaction to it?”
“Yep.”
“What about when the next amazing thing comes out?”
— Anthony Hobday

Behind this visual decoration there are still computers doing things for us, albeit inside a non-deterministic black box. It’s fine to be excited about new technology but not at the expense of fully understanding what it can and can’t do. It’s a shame because “AI” is quite good at some things but saving the world is not one of them. Unfortunately capitalism requires outsized and unending growth rather than modest gains over time. As Jordan Rothe puts it:

In short, people expect AI to be magic. While it’s a truly remarkable technology that I anticipate will impact our world in huge ways we haven’t even imagined, it has it’s own limitations and biases and requires tremendous work and data to function; it ain’t magic.

I use quotes around “AI” because they’re in fact LLMs and not actually “intelligent” in the sense Big Tech would have you believe. They’re stochastic parrots—an achievement in autocomplete perhaps but not an artificial brain by any means.

I’ve had to repeatedly explain to more than one excited layperson that they’re projecting an ability onto a system that literally cannot do what they’re excited about (e.g., “Can you believe what ChatGPT can do?!?”).

It’s a profound powerful valuable array of serious tools and we’re determined to embrace it with the same rush and juvenility as “web3”
— Tom Goodwin

There are numerous indications that current progress in “AI” may already be peaking. Also, rumors of “model collapse” are brewing—a shocking but entirely predictable knock-on effect of how LLMs work. This essay isn’t specifically about whether “AI” is a scam, but it kinda is (if we keep selling it this way).

With a better understanding of how “AI” works and its true utility, there are far better and more accurate symbols out there. We could’ve chosen robots (🤖), dice (🎲), or even slot machines (🎰).

Better yet, why not—and stop me if you’ve heard this before—depict the actions these fancy buttons actually do for the user? From the article:

But since hitting the vague sparkles leads to a different action on each service, Saffar wonders whether it could prevent users from creating a mental model of how the product works, set unrealistic expectations, and leave them confused and annoyed.

I’d argue that nobody has that mental model, not even the very people selling this technology. We’re not using a visual metaphor for what the “AI” can do but for what we want everyone to hope it will do.

For most traditional UI icons, the visual metaphor is predetermined and easy to interpret. For instance, the “save” icon used to be a floppy disk (god, I’m old) because that’s where the software would put your file. The path from symbol to action was a very straight line. For sparkles that path is a labyrinth.

I know I’m ranting about this cute little icon but that’s because it’s more than just a user experience (UX) challenge.

When is an icon is just an icon? Never! Design is political. There’s always an underlying agenda that puts forth a certain idealogy or bias, whether we realize it or not. It’s propaganda, but for what? As Ruben Pater writes in his book:

The political system in which the designer works and lives cannot be disconnected from the design she/he creates. A political ideology is continuously being produced and communicated through design. Acknowledging this can give designers more agency in their practice to either serve or subvert the status quo.

Technology is political, too. Much has been said for years about the biases baked into algorithms or models by way of the programmers who created them. The energy consumption required to mine Bitcoin or summarize an article into bullet points rivals that of small countries. Big Tech is downright giddy about the jobs that can be replaced by “AI”.

I have to wonder what narrative is being given to us, and how. At best, it’s misguided techno-optimism in the name of progress. At worst, it’s a deliberate grift. But either way, the purpose of a system is what it does.

These trade-offs are apparently worth it for enough people because it’s happening as I write this. But let’s not dwell on the consequences, right? We can’t neatly summarize all of that nuance in a cute little icon anyway.

Technical illiteracy, marketing hype, copyright infringement, content theft, disinformation, rampant capitalism, environmental damage, societal upheaval, ethics in tech, the future of work—those fun little sparkles are doing a lot of heavy lifting!

My Manager README

Matt Hogg — Fri, 03 May 2024 00:00:00 +0000

This README is an attempt to succinctly explain who I am, how I work, and my personality quirks. For the reader I hope it helps expedite any potential interaction between us. I also hope it helps me triangulate and refine how I present myself in work settings.

In The Beginning...

I've been working in web development since 1999. I was a "full-stack developer" before it was even a phrase—writing "spaghetti code" in ColdFusion or PHP to connect to databases in Microsoft Access while creating gaudy UIs in Flash. We were called "webmasters" back then.

My original passion is frontend development. CSS is my all-time favorite programming language (yes, it's a programming language). My expertise and curiosity is primarily client-side—HTML, accessibility, CSS, responsive design, making delightful UIs and clicky things, etc.

Over my career I've earned responsibility and authority by giving a damn. This means asking questions, showing an interest in a particular problem space, understanding the value or impact of the work, thinking about process for myself or my teammates, and communicating well. I firmly believe exceeding expectations in this way is what's made me a great developer.

This Is Me Now

It's this feedback loop—exceed expectations, gain more responsibility, exceed new expectations, and repeat—that's put me in leadership and management roles since 2015.

I use my own development background as a force multiplier to support, grow, protect, and defend my reports. Because I've been there myself I'm uniquely qualified to coach developers or guide them through any challenge. By combining my experience with the philosophy of servant leadership I firmly believe investing in the individual is what's best for the organization, too.

What I Do For You

As a leader there are numerous things you can expect me to do for you without hesitation. I feel it's important to list them because people can often talk themselves out of asking for help when they shouldn't. I can...

Provide context and perspective about the company at large.
Advise on your individual or team priorities.
Gather and relay feedback on your performance.
Identify and coach for career growth opportunities.
Offer technical guidance by way of pair programming.
Help with rubber duck debugging.
Participate in code reviews.
Find peer support from other developers, teams, and departments.
Communicate with stakeholders or adjacent parties.
Rally on production issues.
Hire your teammates.
Organize regular, recurring 1-on-1 conversations.
Celebrate your accomplishments in public settings.
Listen to your complaints or rants.
Offer my opinions on anything from coding to process.

My Values And Principles

These are the values and principles that I've accumulated through my career and inform my daily interactions.

I work for you. If you think I'm a good leader then you should see the people I work for—my reports! Any success I might enjoy as a leader is a direct reflection of my reports, the feedback loops I maintain with each of them, and their capacity to execute. I am here to help.

Proactive communication. I speak candidly, but factually, and I try to anticipate what people want before they want it. I'm liberal with my status updates and "FYI" messages. When I take an action item I'll tell you when I expect to finish. When you ask me a question I'll provide any supporting links, documents, or other material that I have. When I think my response is likely to generate a follow-up question then I'll answer it before you even have to ask.

We're doing hard things. I'll be asking you to do novel or difficult work. If our problems were simple then they'd already be solved and we'd be bored or unemployed. So, let's embrace it.

I love helping developers grow. This means I'll challenge you to do more than just write code (or code that you're used to). If I ask something of you that you've never done before remember that it's because I have every reason to believe you can do it. Patrick McKenzie said it best:

Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.

Perfection is unlikely. I aim for steady improvement, iteration, and evolution towards an ideal. Progress might be slow or modest—if we're trending ever upward then I'm happy. If we're not but we know what to do about it, I'm also happy. Andy Hunt said this about software, but I think it can easily apply more generally:

No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first.

Zen detachment. I regularly locate myself within the circles of concern, influence, and control. Living in the circle of concern is certainly uncomfortable but it's far better than mistakenly thinking I'm in the circle of control! I jokingly refer to the former as achieving "zen detachment"—knowing what I don't directly control can actually reduce my stress. The latter is just borrowing trouble.

Let's do it. I'm often inclined to "just do it." I'm typically in favor of launching semi-aggressive MVPs, rolling forward, or tolerating short term frustration and growing pains if it means we're on a path to iterate and improve. I don't like to move fast and break things but I'm certainly more pragmatic and less risk-averse than most people. I rely on my coworkers to push back if I'm being reckless.

Work/life balance. As hard as we might work, we're not performing heart transplants or rescuing people from burning buildings. The firmer the boundaries between work and life the better I can focus on both. I care very little about when you clock in/out, flex time, appointments, or time off as long as your work gets done and your team knows where you are.

Make 'em laugh. A sense of humor is actually helpful for getting work done. It's not just about cracking jokes—although I absolutely will do so at the slightest provocation—but also the ability to stop, take a breath, and loosen up a tiny bit. I like how @daisyowl sums up the absurdity of being self-serious all the time:

if you ever code something that "feels like a hack but it works," just remember that a CPU is literally a rock that we tricked into thinking

Empathy and humility are assets. These aren't just personality traits but "skills" that make me better at my job. Ego will always get in the way of solving problems. Empathy and humility are the basis of any interaction I start with someone. Likewise, I assume positive intent from others. If somebody fails to meet that standard I see no reason to lower myself to that level or fight ego with ego. Empathy is not an infinite resource for me but when I'm tapped that's only discussed behind closed doors.

Strong opinions, weakly held. Paul Saffo's mantra is useful for starting with uncertainty and arriving at a conclusion. No opinion is so absolute that it can't be amended in light of new information or fresh perspective. I actively seek out such information to prove my "strong opinions" wrong or see where they start to bend.

Speak up! If I don't say something then I shouldn't be surprised when nothing improves. I make observations, offer suggestions, or ask questions when I have them. They might be dumb. Sometimes I'm genuinely being an idiot, but otherwise it's a tactic. I'm using Socratic questioning to explore solutions and ideas that otherwise could be missed.

Technical hiring is buggy. I have an unorthodox interviewing philosophy based on my experiences when hiring people. It's served me well but it's certainly not the industry standard nor to everyone's liking.

My Communication Style

Communication is a core skill and therefore my communication style merits particular emphasis here.

Inbox Zero. I'm at "Inbox Zero" all day every (business) day. You'll typically get an acknowledgment or response from me within 30-60 minutes. Yes, really. A non-zero unread message count stresses me out more than any lack of focus. I don't recommend this for others, but years ago I made the trade-off to prioritize unblocking my reports even if that means a lot of context switching for me.

Transparency and clarity. I tell you what I know when I know it. I'm candid about what I don't know and what's uncertain or subject to change. I distinguish objective facts from my own personal speculation or interpretation. If I need something from you I state it clearly or otherwise indicate it's "FYI" only.

Asynchronous messaging over meetings over email. I prefer asynchronous messaging (e.g., Slack) 95% of the time because I can get you a response faster than any other method. When that won't work, meetings or ad hoc calls are more effective (i.e., larger groups or Slack threads that approach 99 replies). I do not like emails.

Loud and clear. I overcommunicate by default. This means repeating the same thing across multiple venues (e.g., Jira, Confluence, email, Slack channels, pull requests). My messaging will be as public as possible for maximum visibility. I'm also vocal with my compliments and gratitude. So far nobody has told me to shut up!

Meetings. I appreciate properly organized meetings and decline invites when I can't determine their value. I may have written an essay on this topic because I'm a big nerd.

Personality Quirks

I'm not a corporate robot, so you should probably be aware of certain personality traits or behaviors.

I'm an introvert. I can talk a good game but my social battery drains quickly. I tend to be more forthcoming with people I know well over time. It's also why asynchronous and written communication comes more naturally to me.

If there's a joke to be made I'll probably do it. It's very hard for me to resist making a joke once it pops into my brain. Puns and dad jokes are the lowest hanging fruit but that doesn't stop me. I'm also playful, sarcastic, and self-deprecating in most meetings. Chat sidebars in video calls were a godsend for me because I can wisecrack without derailing the meeting.

I use a lot of GIFs and emoji. Like, a lot. A picture is worth 1,000 words, after all. Also, it's GIF with a hard "G" and I won't be taking questions at this time.

Spelling and grammar matters. One wrong character can alter the entire meaning of sentence. But it's more than that—I'm the guy who edits his Slack messages after the fact because the innocuous typo is staring me in the face and I can't focus until it's corrected.

Watch my language. I use a lot of idioms, analogies, and metaphors in conversation. They are great shorthand for complex concepts but I do tend to mix them or take them too far. Worse than that, using them presumes a cultural or linguistic background you might not have. If my meaning is ever unclear you'd be correct to stop me and ask that I explain it again.

I think out loud. Writing allows me to collect and prepare my thoughts. When I'm speaking I'm often thinking out loud and on the fly. When I do this I'm aware I have a tendency to look around the room and often past you while my brain is working (this is more obvious in person and less so on video calls). I often search on the spot for just the right word which can be disruptive mid-sentence.

I love completing tasks. There are few sensations better than the dopamine hit when I complete a task and cross it off my to-do list. Like, literally the act of crossing it off my list makes me giddy. By extension, I can get pretty enthusiastic about other people's tasks, too.

Some Exceptions May Apply

I do my best with all of the above but I'm only human. I will make mistakes or present the occasional contradiction. I appreciate when people tell me where I'm falling short or being inconsistent.

If we're undergoing an emergency or existential threat that affects our company, teams, or product then the laws of nature may no longer apply. I will swiftly—and temporarily—put aside any of the above during such times. Ideals are nice but they're useless if I don't have a job or a website to work on.

The End...?

This is a living document that undergoes regular revisions as I myself change over time. If you ever find a discrepancy between this README and my actual behavior, I invite you to please reach out and help me improve it. Thank you!

Meetings, Am I Right?

Matt Hogg — Sat, 20 Apr 2024 00:00:00 +0000

Meetings aren't evil in and of themselves. They're fundamentally just people talking, right? And yet we hate meetings with a contempt that often borders on irrational rage. Probably because it's people talking.

Meetings have always been frustrating but I feel like it's become more pronounced in recent years since the rise of remote work during the pandemic.

Technology has made it that much easier to "hop on a call" and suddenly bring our coworkers into our home offices, one meeting immediately after another and without end. We don't even have to get out of our chairs and move to another meeting room! Video calls also carry a cognitive load that is literally exhausting.

“Can you hop on a call?”
Can YOU hop off a cliff?
— The Volatile Mermaid

It's reached such a critical mass that companies like Shopify felt compelled to "delete" almost all meetings sight unseen!

Naturally, as a tech company, Shopify wrote code to do this. A bot went into everyone's calendars and purged all recurring meetings with three or more people, giving them that time back.

Shopify's heart may be in the right place but I can't help but feel they might be looking past the actual problem here.

In a previous essay I advised that "showing contempt or disdain for meetings" is something that developers should try to avoid. Now, I knew it would touch a lot of developers' nerves—ramming a developer into a meeting when they're deep in code is an unforgiveable offense.

Of course, context switching is hard for everyone. As a result, everyone hates meetings. I get it, but I'm not personally opposed to meetings and I don't think they're intrinsically bad. Nobody is going to catch me using one of those meeting cost calculators to smugly point out how my precious time is being wasted.

However, I do think it's extremely easy to run meetings poorly and when it happens the perceived damage can be lasting. Meetings—organizing or attending them—aren't a casual, passive act. They require real effort.

It Takes All Kinds

Some kinds of meetings can't or shouldn't be avoided. Their utility is genuine and we can safely dismiss these as their purpose is self-evident. This includes:

One-on-ones between managers and reports.
Agile ceremonies—as long as everybody understands their purpose!
Planning or designing a technical solution.
An existential crisis for the company (i.e., the site is on fire).
When a Slack or email thread has gone on far too long (i.e., the opposite of "this meeting could've been an email").

So, it's just all of the other kinds of meetings we have to watch out for. How do we identify and attend high-value meetings and also organize them ourselves? Here's what I do.

How To Attend A Meeting (Or Not)

When a meeting invite arrives in my inbox there's only one question I need to ask myself: will attending this meeting bring me value or will I bring value to the meeting?

If the answer is "no" or "I'm not sure" then I decline the meeting. It's as simple as that.

If the meeting has no agenda, appears with less than a day's notice, the organizer obviously didn't check my schedule, or the organizer made no mention of it beforehand then that's gonna be a "no" from me—I haven't been convinced of this meeting's value for myself or others.

If I decline your meeting, it means one of two things: (1) I don’t know why I was invited, or (2) I know why, but I am not buying it.
— rands

How politely I decline is at my discretion. If I care to, I'll let the organizer know I'm double-booked at that time or request more context before I can accept the invite. More often than not, however, I just decline and go about my day. If somebody really needs me there, they'll find me.

Furthermore, this value assessment doesn't stop with the invite. It extends to the meeting itself. Once I've agreed to attend, I must then be present, stay focused and avoid multi-tasking. Before the pandemic I made it a point to never bring my laptop to any meeting. That's not possible these days, so it takes even more concentration to have an effective meeting.

Conversely, I can also "decline" mid-meeting—I can politely leave early once I've extracted or contributed the value that was needed. Even worse, we should all sign off as soon as we've heard somebody suggest we "take that offline" two or more times.

How To Organize Your Meetings

OK, I've drawn some boundaries and I'm defending my calendar, but what about my own meetings? My advice is to embellish (the invite) and empathize (with the attendees).

Embellish The Invite

By "embellish" I mean that I put as much into the invite as I can to set expectations and then I over-communicate the invite itself.

This starts with the meeting title itself. I summarize as best I can and avoid dreadful non-titles like "Quick Chat" that tell us nothing. And a small pet peeve of mine—use proper grammar!

Is it okay to block my calendar off with a meeting title “leave me alone”
— Smoothie King

Next is the agenda, of course. For smaller meetings I'll at least summarize what we're going to talk about. One sentence is better than a blank description. For more involved meetings I'll outline all the topics to cover. Bonus points when I can timebox each agenda item, again, to set expectations for attendees. Anything on the agenda should lead to a result—a question answered, an action item created, and so on.

If I have any links or documents that serve as homework or pre-read material, I include them. I want people in my meetings to hit the ground running and start prepared. There's also a chance someone will pre-read and address part of the agenda ahead of time, thereby shortening my meeting.

My final embellishment is after the invite is sent. I'll advise the same people in Slack to watch for the invite and offer additional context. This might seem excessive but it demonstrates that the meeting, and its attendees, are important to me. And again, there's always a chance I'll start a discussion that gets me what I need and negates the meeting entirely.

Empathize With The Attendees

Demonstrating empathy at work is a true skill, and that includes when I'm organizing meetings.

For instance, the simplest way to show others that I'm trying to be respectful of their time is to use the scheduling/availability tool of my calendar to find a time that works for those involved. Why compound the pressure on my attendees by double-booking them when it only takes me a few minutes to see if they're even free?

Additionally, I prefer to book time that's adjacent to a attendees' existing meetings. This means I'm not adding a context-switching burden for people by dropping a meeting right in the middle of an otherwise empty afternoon, for example.

I'm also very clear about who's a required versus optional attendee and why—heaven is a meeting invite someone knows they can decline without any guilt.

Where applicable, I remind people when a meeting will be recorded. If someone is unable to attend this can give them some relief that they won't miss anything. And quite frankly, there are many meetings I wish I could've watched later at 2X speed if I'd had the chance!

Lastly—and this is a pet peeve of mine—I don't "give people their time back" if the meeting concludes early. Humans don't talk like that! I just thank people for their time and end the meeting.

omg thanks for ending the meeting 4 minutes early and "giving me some time back" -- now I can finally pursue my passions
— sarah

Sorry, Not Sorry...?

I wrote this with some hesitation because it feels a little bit facile. I'm not saying anything groundbreaking here. If you've read this far and think all of this is self-evident—I agree!

The fact remains, however, that for years I've regularly coached people or listened to them complain about their unruly calendars. So, the problem does exist and must be confronted. This is what's worked for me.

Until such time as everyone everywhere magically creates perfect meetings we need to learn how to distinguish the good from the bad, establish some healthy boundaries, and perhaps—gasp!—even talk to each other.

Developers, Your Job Is Not To Write Code

Matt Hogg — Fri, 16 Feb 2024 00:00:00 +0000

This essay is adapted from a lightning talk that I originally presented to coworkers in 2019.

The advice I've consistently given to developers who want to grow might seem counter-intuitive, but it's always held true for me—the first step to being a great developer is recognizing that your job is not to write code.

How do I know this to be true? Well, I've never spent a single minute of a one-on-one with a developer talking about code that they've written! That's just not what I spend energy on when I'm coaching someone. The path to becoming more senior is not through better coding.

Furthermore, your stakeholders—brace yourself!—don't give a shit about your clean code, the developer experience, tooling, or any other tinkering you might do. They'll be equally satisfied with a massive, complex feature or a single line change in a configuration file. All that matters is that you've delivered value.

// Detect dark theme var iframe = document.getElementById('tweet-1607856517109387264-3'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1607856517109387264&theme=dark" }

Similarly, when working on a team you could be the Greatest Developer In The World but if nobody likes working with you or understands what you're doing every day then you're essentially a human paperweight.

So, there must be many more skills required of you than just typing into your favorite IDE. Thinking that "developers write code" is like thinking "carpenters hammer nails"—it's simplistic, naive, and a trap.

// Detect dark theme var iframe = document.getElementById('tweet-1516834079798349824-417'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1516834079798349824&theme=dark" }

A Trap Hiding In Plain Sight

There are obvious signs you might be stuck in this "developers write code" trap. Some of these might apply at one time or another and that's OK as long as you're self-aware. But the more of this you exhibit on a regular basis, the more work you'll have to put in to extricate yourself. These signs include:

Showing contempt or disdain for meetings.
Not checking, acknowledging, or responding to messages.
Not participating in "non-essential" conversations or social activities.
Not tolerating interruptions or context-switching.
Apologizing for delays in planned coding tasks.
Measuring your output solely by counting pull requests.
Not asking questions or thinking critically about the work.
Not contributing suggestions, ideas, or solutions.
Displaying a lack of curiosity in your problem domain.
Worrying about your work at the expense of your teammates' work.

These can be fairly common developer stereotypes. The perception from other people that "developers write code" is also part of the trap. Let's hope you don't work for a certain "genius" CEO who asks you to print out your code for his own personal review!

To truly succeed you'll have to spot these anti-patterns and correct these assumptions for both yourself and others. You really have to own your narrative or someone else will do it for you.

Why It's A Trap

The "developers write code" trap is detrimental to your company, your team, and especially you. It will limit you and ironically make you a worse developer.

Short-term thinking (e.g., "What's my next coding task?") means you're running in place.
You're more likely to be emotionally invested in your code which limits your learning opportunities or potential solutions the next time that code needs to be touched.
You'll be typecast (or extinct) as a specialist developer—remember when we had Flash developers...?
Burnout is more likely because you're a passenger and not an active participant in the work or its destiny.
You won't be given the novel and interesting challenges within your team, technical or otherwise.
There will be fewer career paths available to you because you want to keep your fingers on the keyboard.

So, What Is Your Job Then?

If your job is not to write code, then what is it then? Fair question, and the answer is simple...

Your job is to solve problems.

Yep, that's it.

Obviously, we do solve some problems by writing code. But we also solve problems by reading code, testing code, debugging code, or deleting code (my personal favorite).

But wait, there's more! All of these things are your job as a developer and serve to solve a problem. Go ahead and read through this. I'll wait.

Organizing and attending social events
Volunteering
Suggesting or enacting changes in process
Interviewing candidates and reviewing resumes
Attending conferences
Being someone's rubber duck
Showing people cool stuff you found
Eating your own dog food
Writing documentation
Mentoring and coaching others
Attending meetings
Debugging or tracing code
Chatting in the kitchen/hallway/etc.
Testing code
Testing in production
Prototyping
Giving demos and presentations
Googling shit
Estimating effort
Doing lightning talks
Reading code (PRs)
Attending training
Deleting code
Designing systems and solutions
Finding or reporting bugs
Troubleshooting
Brainstorming
Reading Stack Overflow
Asking questions
Researching
Being a subject matter expert
Keeping up with Slack/email
Unblocking teammates
Talking to stakeholders
Caring about the users
Writing code

Most of these would typically be considered "soft skills" which is a term I despise. They're all equal skills. I don't position writing, communicating, empathizing, helping, or thinking in second place after the so-called "hard" skills.

You need all of it to be effective at your job and climb the ranks. As Tim Ottinger puts it programming is "mostly thinking" and your code is "just the residue of the work". Karl Sutt also has great communication advice that demonstrates how empathy itself is a useful skill requiring genuine effort:

Writing effectively is a superpower, there is no denying it. As a software engineer, you write a lot. Most of the writing you do is for computers. Businesses, however, consist of people.

Go Do Your Job

We all know developers in their default state would much rather be left alone to write code. I've been there, too. Coding is fun! It's comfortable! But I dare say it's too comfortable. Frankly, if you're not challenging yourself you're just doing something that anybody else could be doing in your place.

// Detect dark theme var iframe = document.getElementById('tweet-1591067274492141570-613'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1591067274492141570&theme=dark" }

I encourage you to broaden your understanding of what a "great developer" is and then meet that definition.

Remember that your productivity and contributions are measured by more than just code output. Recognize that there's a long list of skills that are equally valuable and necessary and then pick the next one to get better at. Juniors and seniors alike can do this. There will always be another skill to polish.

Once you realize that you're more than just your code you'll be well on your way to becoming a better developer.

A Technical Interview Doesn't Have To Suck!

Matt Hogg — Tue, 30 Aug 2022 00:00:00 +0000

Countless technical interviews are conducted every day that are little more than theatrical self-sabotage for everyone involved. To say that this process is deeply, truly, fundamentally flawed is an understatement. We need to do better.

What kinds of technical interviews am I talking about? The list of offenses is endless: whiteboard tests in pseudocode, hours-long (or days-long!) take-home tests, sorting algorithm questions, FizzBuzz, LeetCode, asking a stranger to write working code in 20 minutes while you stare at them, asking "gotcha" coding questions with a single correct answer, puzzles, riddles, brain teasers... The mind boggles!

Candidates dread interviews like these. Interviewers aren't exactly proud of themselves, either. At least, they really shouldn't be. Technical interviewing has become so dysfunctional that it's better at assessing a candidate's anxiety than their skills.

So, folks, what the hell are we doing? And can we please get our shit together? Read on.

First, An Anecdote

A couple of years ago I was interviewing for an engineering manager role at a local Toronto startup. A part of this interview involved a coding exercise where I was asked to find the intersection of 2 arrays.

While working out the solution using ES6 array methods like filter() and includes() the interviewers suggested I scrap that approach and do it without ES6. OK... I did my best to oblige with some nested for loops. I was then quizzed on the computational cost of both approaches.

Once we finished I asked the interviewers if it was perhaps a style convention of the company to avoid ES6 in favor of hyper-optimized code. I was floored when they told me, "Oh, no, not at all! All of the developers use ES6 freely. We go with whatever works and is fastest for the developer."

We wasted 45 minutes evaluating things that didn't matter! Why was an engineering manager candidate with 20 years of experience writing basic JavaScript code? Why did the interviewers specify constraints that they themselves don't even follow?

Maybe I shouldn't have been that surprised. Throughout my career I've been in many a bad interview:

I once withdrew from applying at a billion-dollar company when they wanted to schedule a total of 17 hours of interviews!
I once did a take-home test that I was told would then be discussed with me in our interview—it was never mentioned again and I had to do an additional whiteboard exercise!
When I interviewed for my first job out of university I was given a written (!) test which I completed in a room alone. I did get the job, though!

Red Flags, Red Flags Everywhere

We know instinctively that the typical technical interview process is a minefield of issues because we've all experienced it. Any one of these problems alone would be toxic enough, but when they're combined it's a disaster.

A Poor Predictor

First of all, many technical interview techniques simply aren't predictive of a candidate's actual job performance. I mean, how could they be?

We can't adequately assess somebody in just an hour or two. To correct for this interviews are starting to get longer. This is, of course, more expensive for the company to do and also sours potential applicants.

Regardless, we're also getting the format wrong. Solving a problem on a whiteboard is indeed a skill, for instance, but as Quincy Larson points out it has "almost nothing to do with modern software development."

Nervous Candidates

Second, candidates are primed to expect difficult interviews and are therefore nervous. This is bad because we’re not interviewing these candidates at their best. Candidates also feel compelled to furiously study or cram for the interview itself and not the job. It's an industry of its very own.

// Detect dark theme var iframe = document.getElementById('tweet-1482097995512369152-647'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1482097995512369152&theme=dark" }

This is because we make them jump through hoops, obsess about the Almighty Whiteboard, give them "fun" (read: narcissistic and sadistic) brain teasers, or push all applicants (junior, senior, or rock star) through the same funnel whether it makes sense or not.

Nothing Like The Actual Job

Third, technical interviews aren't representative of our day-to-day activities or workplace cultures. We wouldn't trust most code cranked out by a coworker in 20 minutes, for instance.

Fortunately, in our day-to-day we have many guardrails in place to mitigate such a thing (e.g., code review, team leads to pair with, user stories with acceptance criteria, etc.). A candidate doesn't have access to those amenities, and the interview is more unfair and adversarial as a result.

Just imagine if a coworker actually implemented a sorting algorithm on company time! We'd rightly question their sanity. They should Google it and then use a library, and that's what we'd advise them to do. Why does the typical interview not do the same?

// Detect dark theme var iframe = document.getElementById('tweet-1514423070345342979-882'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1514423070345342979&theme=dark" }

For candidates, the very format of most interviews can distort and obscure the company's true work culture. We then lose a vital mechanism for assessing them—would we appreciate working with this person?

Most Companies Are Not Big Tech

Fourth, many interview practices aren't a good fit for most companies. We adopt many a "best practice" from the big tech companies—FANG, FAANG, MAMAA, or whatever we're calling them today—whether it's a good idea or not. The same goes for technical interviews.

Google interviews the way they do because they have to do it at scale—that's hiring many tens of thousands of people a year. The vast majority of companies don't have this problem, and for them the approach should be different:

There's an entire cottage industry writing about FAANG's hiring processes. If you're a startup or even a small company, don't give this much credence because likely the decision they made doesn't apply to you. And the decisions they didn't make is because it doesn't scale. This is their weakness and your advantage.

Our Privilege Is Showing

Finally—and this is the most damning—technical interviews can be racist, ableist, or sexist. There's a bias in place for developers who are women, from an underrepresented group, or who have performance anxiety.

Candidates in these categories already have to overcompensate just to be seen as equals. They can be great at what they do but also have to navigate the prejudices of the strangers interviewing them. This can be exhausting or damaging for the candidates and they'll freeze up. Meanwhile, any interviewer unaware of their own bias and privilege will conclude the candidate isn't a good hire.

Why We Hire Determines How We Hire

That is a lot that we're enabling or perpetuating without fully realizing it! To be clear, anybody who's ever conducted an interview has been complicit in this—myself included.

Much about technical interviewing feels correct, to interviewers and candidates alike, even though it's superficial. Developers tend to prefer objectivity, clear outcomes, and subjects that are easily categorized into neat little buckets. So, when it comes to interviewing developers we just want to know if they can write the damn software or not, right?

There are many people who cling to technical interviews because of a belief that many candidates can't write code. Like, at all. As in, it's "disturbing and appalling" and a "slap in the face to anyone who writes software for a living." Clearly these imposters must be stopped! Dan Kegel writes:

A surprisingly large fraction of applicants, even those with masters' degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. For example, I've personally interviewed graduates who can't answer "Write a loop that counts from 1 to 10" or "What's the number after F in hexadecimal?"

This hasn't been my experience. I'd respectfully disagree and posit that using the interview to test "basic" programming ability isn't a wise use of time. My daily rate is better spent on other activities, but that's just me.

This problem could likely be solved with a phone screen by a recruiter who has a list of rudimentary questions. Instead, we've over-corrected for the problem of assessing competence and aggressively applied that solution to every candidate.

I'm not saying we should do away with coding tests entirely. I wouldn't be so bold as to suggest anything quite so radical. What I would be so bold as to suggest, however, is that maybe we don't need to be so fucking perfect.

For instance, if you're interviewing a junior how much should you truly expect them to know coming in? They're more likely to learn on the job. Your company should provide the space and support for them to grow, and consequently your hiring process should reflect that. If your company doesn't support growth, I might need to write a different essay...

And for seniors, we don't need to thoroughly test their programming ability at a basic level. Their many years' experience, glowing references, or a goddamn conversation with them serves as a reasonable heuristic for that. Do we genuinely think senior applicants are liars and frauds? All of them?

// Detect dark theme var iframe = document.getElementById('tweet-1498659651562336261-302'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1498659651562336261&theme=dark" }

When hiring, the goal is to find valuable additions to your team. That's basically it. As Cher Scarlett rightly points out:

The thing you're looking for, realistically, is the candidate who shows you what you're missing, and that can rarely be figured from a coding exercise, even if it's not done live.

The goal isn't to defend your team from fakers and imposters, or to find the perfect candidate. Doing so only leads to hiring the people that most exactly match your expectations—and your implicit biases. This directly influences the interview format and results in a monoculture within your team.

As hiring managers, we should recognize when we've had a good technical interview when we're surprised by a candidate instead of merely satisfied. Did the candidate tick all of the boxes on your stupid checklist? Or, did you genuinely enjoy meeting them?

Principles For Better Technical Interviews

To foster that kind of serendipity I much prefer to diversify my technical interviewing toolkit by adhering to these 3 high-level principles:

Comfort
No-code
Realism

Comfort

Do what you can at all times to make a candidate comfortable. I can't stress enough how important it is to set expectations and be clear with the candidate about what they're going to experience.

It starts with the invitation to interview. I always indicate who's attending the interview, including their names and titles. I make sure to emphasize that it won't be a whiteboard or live coding exercise. For remote interviews, I strongly suggest the candidate try out our video conference software ahead of time including the camera, microphone, and screen-sharing functionality.

All of this serves to put the candidate at ease as much as possible. A nervous candidate is not a valuable interview because they're not properly equipped to demonstrate their skills and abilities. I'm not just being kind to the candidate, I'm also maximizing the accuracy of the interview.

During the interview I also take steps to put the candidate at ease. This means reminding them that they're doing great, providing psychological safety, or making space for them to take quick mental breaks.

// Detect dark theme var iframe = document.getElementById('tweet-1546797773290446848-783'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1546797773290446848&theme=dark" }

The best way to provide breaks is to split the interview into multiple segments and in between them I ask if they have any questions for me. At the very least I'll allow for a longer amount of time at the end for questions—I'm often surprised how much the candidates' questions reveal about them!

No-code

This essay has really been building up to make this exact point, hasn't it? It's perhaps no surprise, but we've got to stop pinning our all of our hopes on performative coding exercises.

If I only evaluate a candidate's coding abilities then all I know about them is that they can code and little else.

I ultimately don’t care how well someone can simply write code, to be honest. What I do care about: if they're confident in their abilities and aware of their weaknesses, if they show an attention to detail, if they demonstrate problem-solving skills, if they care about the user experience, if they're willing to learn, and so on.

Poorly executed technical interviews don’t assess for these qualities because they're digging in the wrong place. Instead I prefer to rely on realism.

Realism

I like a technical interview to be as close to reality as I can get. This is easier said than done. It means balancing the temptation to inspect a candidate at the finest granularity against the need to see how’d they actually perform in the real world.

I don't want to invigilate a coding exam. I'd much rather look for my next great coworker. I just want to be real and stop with the posturing. We're not inverting binary trees or implementing algorithms from scratch.

All of us look up shit on Google hourly. We talk to our teammates when we're blocked, and help each other get unblocked. We brainstorm problems together and debate possible solutions. We troubleshoot. We apply critical thinking to prioritize work and estimate its effort. And sometimes we throw our hands up in the air and say, "I have no damn clue."

// Detect dark theme var iframe = document.getElementById('tweet-1379195256630095872-857'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1379195256630095872&theme=dark" }

So, I have conversations with candidates on these terms—and I assess their programming ability for free! A candidate will necessarily give me insight into their coding skills over the course of the discussion, and I avoid staring at an IDE and acting as an overpaid human linter.

An additional benefit of realism is that candidates are also evaluating me and my company. Sometimes deliberately so. I need to present the company's culture and ways of working as a differentiator in a vast ocean of coding interviews.

An Interviewer's Toolkit

There are numerous ways to avoid pure coding interviews and their shortcomings. Recall I used the word "toolkit" earlier. I recommend having a variety of interview activities at the ready. To name a few:

Present the candidate with a bug to troubleshoot together. This can be staged for the candidate, or an actual bug that nobody on your team has fixed yet.
Brainstorm the implementation of a new feature. This can be done with design mockups or with an existing feature of your website or application. The candidate plays the role of a dev on the team while the interviewers are role-playing as product managers and the like. Get the candidate to plot out the work needed, the trade-offs of certain choices, the complexities, and so on.
Ask the candidate to open Dev Tools for your website or application and poke around. Let them go wherever their curiosity takes them. The trick to this activity—and what makes it challenging for all involved—is that it's open-ended by design. Take note of what the candidate is drawn to, how they use the tools, how they ask and even answer their own questions, and so on—sometimes they'll even discover a bug! Good candidates can really shine here when they come prepared with notes because they already took a peek before the interview.
Give the candidate a mock pull request and ask them to conduct a code review. They can share their screen and go through it line-by-line and either speak or type their commentary. Interviewers may do some role-play as the “author” of the pull request.

For folks used to typical technical interviews, activities like these will be so frustratingly close to coding only to stop short. This is intentional. Sorry, not sorry. Remember the guiding principles are comfort, no-code, and realism.

It's also good advice to mix and match or otherwise tailor the interview to the candidate or the role being filled. Having a pool of interview activities to draw from makes this easier.

Lastly, at the end of any interview I make sure to ask, "What feedback do you have for us about our interview process?"

This question allows me to iterate and improve on how I interview, but also gives me a glimpse into competitors' interview processes. I'm often surprised at how freely candidates will compare the current interview to others they've done, and what they point out will reveal a lot about themselves.

The Only Winning Move Is Not To Play

So, that's how I see things, but it's been hard-earned. We've dug ourselves a very deep hole, as an industry. It's an uphill battle for any individual to improve things just within their own organization.

As hiring managers, we can only hope our companies give us the leeway to improve the process. For myself, I've arrived at these techniques over years. In some of my roles, I've done this in bits and pieces where there have been gaps. In some roles I've even subverted or danced around heavy-handed or prescriptive HR departments...

A good company is one that asks how you as the hiring manager want to handle it and supports your efforts.

For jobseekers and candidates, it's much more challenging to move the needle. How do you point out the absurdity of it all without getting shown the door? There are ways to decline a technical interview that are constructive and you might even come out of it looking smart!

// Detect dark theme var iframe = document.getElementById('tweet-1461774310868062208-926'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1461774310868062208&theme=dark" }

As a jobseeker, if a particular opportunity smells "off" for any reason be prepared to declare that hiring is broken and stand up for yourself. Tell that hiring manager or recruiter why you don't want to participate in their technical interview.

The worst that'll happen is a hiring manager will choose not to move forward. But maybe a polite refusal will make them take notice and accommodate. Better still, if enough of the talent pool makes proper technical interviewing a factor in their job search, the industry will have no choice but to follow suit.

So, demand better! Hiring managers should elevate their candidates. Jobseekers should draw boundaries that both protect their well-being and foster their potential. Perhaps then we'll all meet in the middle and find the process truly works for everyone involved.

Hacks Are Fine

Matt Hogg — Thu, 08 Jul 2021 00:00:00 +0000

This essay has been adapted from a lightning talk that I originally presented to coworkers in 2019. It was intended as an absurd, tongue-in-cheek thought experiment, but I'd like to think there could possibly be some truth to it...

There's a slight problem with the standard definition of a hack. It says more about why you wouldn't want to use one than why you might. What if—now hear me out—hacks are fine?

A "hack" (also known as a "kludge") is defined by Wikipedia as:

A solution to a problem, the performance of a task, or a system fix which is inefficient, inelegant ("hacky"), or even incomprehensible, but which somehow works.

A definition like this will prime readers a certain way by using more negative words than positive. Also, that little bit of bewilderment at the very end really gets me—somehow hacks work!?! Gosh! My goodness!

So, let's consider several reasons why we maybe shouldn't be surprised by hacks as viable, successful solutions.

Excitement

Hacks can be exciting! Nobody wants a protagonist who has all the time and resources they need at their disposal. That's not good storytelling. Just ask MacGyver here.

Now, I'm only half-joking. You could find yourself working for a company, or on a particular project, where you don't have all of the resources or support you'll need to be effective.

This will force you to get creative and think outside the box. And after a few such challenges in your career, you'll be a better developer because of it.

Pragmatism

When it comes to prototypes, A/B tests, and confirming hypotheses about your product the best way to effectively deliver is actually by writing the fastest, shittiest code you can.

And sometimes you just have to ship it, even for production code. There's often a deadline, at which point nobody really cares that you're a code poet. A hack could be the path of least resistance.

A certain amount of technical or product debt isn't, in and of itself, a bad thing. It's an artifact of a decision that was made to get to an end result. It's evidence of a compromise that was made, or a trade-off that (I hope!) was carefully weighed.

How you track that debt and pay it down is another question, of course...

Critical Thinking

Speaking of trade-offs, hacks are an opportunity for critical thinking. A responsible hack means you've considered things like cost versus benefit or risk versus reward. This is actually a very important learned skill over time.

At the very least, in the short-term a hack might shake loose the ideal solution to a problem you've been struggling with all day. You'll think about it when you go home that evening and maybe even lose some sleep over it. But, in mulling over the hack you'd really prefer to avoid in the morning, you just might come back with a better solution!

YAGNI

You also need to consider the likelihood that You Aren't Gonna Need It (a.k.a. YAGNI). A simpler solution is almost always the better solution, if you can pull it off. Sometimes that might feel like a hack.

I can't be sure, but I think Ron Jeffries might be against premature implementation:

Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them.

Trying to predict the future of your code is ambitious. The odds are low that you'll end up being correct. So, it might be more prudent to hedge your bets with a conservative stop-gap measure that costs you less up front.

Impermanence

In a similar vein, very little of your hard work will live forever. Software can have a very short shelf life whether it's due to redesigns, refactors, business closures or acquisitions, startup pivots, and so on.

I once did some quick math on a napkin and surveyed my previous 9 jobs going all the way back to the late 90s. It's probable that only about 20% of anything I'd ever worked on still existed. Obviously, output from my very first job is gone—so long, Coldfusion!—but so is stuff I worked on just a few years before.

The point being, if perhaps there's a hack in production that you're really not proud of you might not have to worry for very long!

Durability

On the other hand, your hack could last a lifetime.

If that hacky code is working and delivering value then you've created legacy code. Congratulations!

But if that hack doesn't work perfectly, well, I still wouldn't worry much. We can all think of that bug, maintenance task, or tech debt issue that sits in a Jira backlog for months or even years, right? A codebase will always have issues that ultimately never get looked at, which raises the question: if you never fix it, was it ever broken?

// Detect dark theme var iframe = document.getElementById('tweet-501718937420455937-90'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=501718937420455937&theme=dark" }

For instance, I can tell you that one of Canada's most popular websites contains a self-identified hack that's been executed by hundreds of thousands of visitors daily for at least 7 years and counting.

For fun, I recommend searching for terms like hack or FIXME hidden in the comments of your codebases and see what you find.

It's Not Just Software

Speaking of durable hacks, we can broaden the original defintion beyond just software. We're surrounded by many hacks which we take for granted every day.

Advances in science and engineering often progress by way of hacks. The Apollo moon landings are a great example—to get to the moon we literally threw away an entire Saturn V rocket every time. Oh, and if you expected to come home you had to crash a tiny module into the ocean and be rescued. And yet, there are footprints on the moon!

And let's not forget what a central processing unit (CPU) truly is:

// Detect dark theme var iframe = document.getElementById('tweet-841802094361235456-424'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=841802094361235456&theme=dark" }

The scientific theory of evolution by natural selection is the ultimate hack. Evolution does not prematurely optimize! Natural selection works with whatever's at hand and the smallest change that works well enough is the winner. You, reading this right now, are the result of an innumerable series of tiny hacks.

That said, the human body is still a hot mess:

Our eyes are wired backwards.
Our spines were never meant to be vertical.
We put food and air down the same hole.

And then there's childbirth. The pelvis and birth canal are narrow because we grew to enjoy walking on 2 feet. However, our brains are also big and, like, really smart. So, babies come out when they do because their heads wouldn't fit if they waited any longer! Babies also have soft skulls to facilitate this, and can only come out head-first and facing backwards. Consequently, newborns still develop as if they're in the womb—the so-called 4th trimester.

OK, OK, But The Software!

Sorry! That was a bit of a tangent.

If you employ a hack, don't be so ashamed. Don't be too proud, either. Above all, don't be lazy—be certain and deliberate about why you're using a hack. Remember there are times you shouldn't use a hack (i.e., extending or tacking onto an existing hack).

If you discover a hack, try to reserve judgement. Consider why it might be there... Is the developer going for a moon shot? Do they think they're MacGyver? Is YAGNI a consideration? Use the hack as an opportunity for dialogue and empathic code review.

So, I guess I'm ultimately pleading for ambivalence and nuance—hacks can be evil, lazy, clever, useful, or anything in between. Hacks are just... fine. But since hacks are all around us, and constantly so, it's to our benefit to accept their utility and consider them an essential skill in any developer's bag of tricks. Maybe.

Images, in order of appearance, are courtesy of xkcd.

Legacy Code May Be The Friend We Haven't Met Yet

Matt Hogg — Sun, 06 Jun 2021 00:00:00 +0000

In web development it’s a common trope that working with legacy code is considered boring, painful, or even beneath us. Only the shiniest new framework or tech stack will do! The truth, however, is that legacy code is impossible to avoid. But don’t worry, that’s actually a good thing.

React has been all the rage for about 7 years, but it's in use on only 2% of all websites. The story’s the same for Vue and others. For all their hype, the opportunity to work somewhere that’s using React or Vue in the wild is incredibly niche and privileged!

You Can Run, But You Can’t Hide

WordPress, on the other hand, serves up 42% of the web. jQuery is an outcast nowadays, but is still found on a staggering 78% of all websites. Or maybe you’ve heard of COBOL? About 80% of the code running the world—that’s payroll systems, ATMs, traffic lights, and so on—is written in COBOL. That’s over 220 billion lines of COBOL, and nobody ever talks about it.

// Detect dark theme var iframe = document.getElementById('tweet-1203430051615662080-665'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1203430051615662080&theme=dark" }

Hell, if one wanted to make truly serious money it’d be far better to be a COBOL programmer yanked out of retirement. React seems downright quaint by comparison.

Given numbers like these, it’s quite impossible to shape our careers to avoid legacy code.

Any given company might be splitting their aging monolith into microservices, stitching a bunch of microservices back together again, migrating tech stacks or CMS platforms, acquiring smaller companies and their code, relying heavily on some random internal tool that a developer hacked up as a favor to a coworker, and so on.

Even the youngest of tech startups will have a problem with legacy code—they just won’t realize it right away. The greenest of greenfield projects will quickly wither.

So, legacy code is everywhere and runs for years (if not decades) making trillions of dollars a year and delivering value to users. The fact that it does so, and without fanfare, should give us pause. If legacy code is so successful, why do we have such contempt for it?

Too Scary, Too Profitable

Dylan Beattie has the perfect definition for legacy code to help us answer this: “Legacy code is code that’s too scary to update and too profitable to delete.”

He also makes the observation that writing new code is more exciting than reading old code. And Joel Spolsky expands on that idea when he claims, “It’s harder to read code than to write it.” He goes on:

Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

That’s quite the combination, isn’t it? We’re expected to poke at code that’s “too scary to update” and might fall over if we look at it the wrong way. But... We didn’t write this code... Can’t we work on this killer feature instead? Can we delete this code and start over? This isn’t the luxury and glamor of web development that we were promised!

Let’s be frank—everyone in our line of work can write net new code. That’s the bare minimum expected of us, in this humble author’s opinion. It’s a far more valuable and marketable skill to read, interpret, and understand code. This is the challenge that legacy code puts to us.

And, as is often the case when something is scary, this says more about ourselves than it does about the code. We need to face this head on, stop projecting our foibles onto inanimate codebases, and genuinely improve ourselves and the industry.

Challenge Accepted

Legacy code really is an opportunity and a proving ground for us to perfect many skills and talents. To list just a handful:

Useful and efficient troubleshooting techniques.
A heightened sense for patterns or antipatterns.
New languages or tech stacks that they don’t teach in school.
Strategies for pragmatic, effective unit testing.
Battle-hardened architectural decisions and strategies.
Smarter or more robust bug fixing skills.

That’s not to say any of the above comes easily. We just might have to break the code to understand it—deliberately or otherwise. And likely more than once. And sometimes on production.

And yet, we can probably trust legacy code more than we’d guess! Joel Spolsky again:

The idea that the new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it.

It is patently absurd, isn’t it? There’s a hubris that’s plainly on display and driving our contempt for legacy code. Even worse, it could be silently influencing the technical strategy for many organizations. Spolsky one last time:

[W]hen you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.

Which brings us to one of the most important skills that legacy code can teach us: empathy.

We must remember that almost every codebase we might encounter was without a doubt built with the best of intentions. Decisions were made at a given point in time according to the constraints, assumptions, and best information available. But it never feels like that many years later, does it? While very easy to overlook, understanding these circumstances can help us better interpret the code we're looking at.

And there's a corollary here that might be worrisome to any of us who've tried to tailor our careers to avoid any encounters with legacy code.

// Detect dark theme var iframe = document.getElementById('tweet-1361314511043629059-774'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1361314511043629059&theme=dark" }

There are rockstar developers creating legacy code right this very moment. It doesn't matter if that code is lovingly crafted using the latest tech stack and best practices—in a few years a group of total strangers will beg their manager to print out the entire codebase and set it on fire.

Right now, somebody somewhere is cursing a line of code that one of us has written. So, whether we're inheriting it or producing it, we can't escape legacy code.

Innovate Or... Why?

Much is done in the name of innovation. We trip over ourselves chasing the shiny and new on a never-ending conveyer belt of frameworks and tooling. And then we snipe at each other on Twitter to justify the energy we've spent staying up to date, or we feel guilty for failing to keep up.

Companies undertake massive overhauls of their codebases, also for innovation's sake. They may fall short of their ambitions or ultimately succeed—only to do it all again years later.

So do we embrace legacy code with open arms and avoid modernizing? Or vice versa? No, of course not. But at this point it should be obvious that when it comes to code—old or new—there are many influences at play and most of them aren't technical.

Let's recognize that legacy code and unbridled innovation are at opposite ends of a spectrum, and that we can learn, improve, and extract value from the gap in between. Legacy code will always be with us and a healthy attitude about it favors developers, companies, and the entire field of web development.