1. Library
  2. Language as Proxy for Taste

Language as Proxy for Taste

3 mins
Light Mode
Beautiful Craftsmanship
Enough Talk. Let's Look at Code
So What?

Most developers agree that code will be increasingly written by agents. If that’s true, then familiarity with a specific programming language's ecosystem will stop being a criteria for hiring software developers.

I ran this idea past a few friends who have hired lots of software engineers, and they disagreed.

The theme that kept coming up: The clearest window into an engineer’s taste is the language they build in.

Every language carries its own ethos, a philosophy of how software should be written. A Python developer values readability. A Rust developer values discipline and efficiency.

These preferences aren’t trivial. They reveal how someone thinks. It’s the kind of craftsmanship they aspire to as a builder. The languages you’ve built in signal who you want to be as an engineer. Like the stickers on your laptop, they tell your story before you even open it to show a demo.

Beautiful Craftsmanship

Every programming language encodes a set of values. Spend enough time building in one, and those values shape your sense of taste. What you optimize for, what you tolerate, and what you find ugly.

When engineering managers talk about “culture fit,” they’re often circling this idea: Does this person’s taste align with how we build things here?

Enough Talk. Let's Look at Code

Two snippets that count the frequency of words in a string: one in Python, one in Rust:

from collections import Counter

def word_count(text):
words = text.lower().split()
return Counter(words)

It’s beautiful because it looks like pseudo-code. A non-programmer could read it and get the gist. It trusts the standard library instead of reinventing the wheel, confident that the built-ins are good enough.

use std::collections::HashMap;

fn word_count(text: &str) -> HashMap<String, usize> {
let mut counts = HashMap::new();
for word in text.to_lowercase().split_whitespace() {
*counts.entry(word.to_string()).or_insert(0) += 1;
}
counts
}

Every allocation is explicit. Resource usage is tightly controlled. Nothing is left to chance.

Sure, these are toy examples. Python and Rust were built for different kinds of work. In the craftsmanship analogy, it’s more like comparing wood to bronze than comparing two statues. But the point stands: each carries a worldview about how things should be built.

So What?

When a team lead looks at the languages a developer has built in, they’re not just gauging how productive that person will be. They’re trying to understand the tribe that person identifies with, and whether it matches the tribe the company is building.

That tribe says more than knowledge of a library, linter rule, or test framework ever could.

In a world where AI systems can translate ideas into code across any language, taste becomes the more important filter for choosing teammates.

Programming languages may fade into invisible layers between us and our agents. But their ethos will outlive them. They’ve been quietly training us all along. Not in how to write code, but in what we find beautiful.

Content from the Library

Podcast

High Leverage Ep. #6, Async Runtime For Rust with Carl Lerche of Tokio

On episode 6 of High Leverage, Joe Ruscio sits down with Carl Lerche, Principal Engineer at AWS and creator of Tokio. Carl shares his journey from Ruby and Rails into Rust, and explains why memory safety, fearless concurrency, and async runtimes matter for modern infrastructure. The conversation dives deep into the origins of Tokio, lessons from building foundational open source software, and how Rust’s guarantees are shaping the future of systems engineering. Want 10% off your ticket to TokioConf? Use the discount code: Heavybit10

Podcast

Open Source Ready Ep. #16, Building Tools That Spark Joy with Mitchell Hashimoto

On episode 16 of Open Source Ready, Brian and John sit down with Mitchell Hashimoto, founder of HashiCorp, to discuss his journey after leaving the company and his latest passion project, the open source terminal emulator Ghostty. Mitchell shares the accidental origins of Ghostty, his pragmatic approach to technology, and his thoughts on the current state of open source business models. Lastly, they explore the complexities of AI development and the trade-offs of foundation governance.

Podcast

Open Source Ready Ep. #13, Why Microsoft Chose Go: A Deep Dive with Thorsten Ball

In episode 13 of Open Source Ready, Thorsten Ball of Sourcegraph joins Brian and John to unpack the real-world engineering decisions behind language choices, like Microsoft using Go for the recent TypeScript compiler rewrite. Explore the importance of continuous learning in tech, the benefits of knowing multiple programming languages, and how AI agents are poised to reshape developer workflows.