Agentic tools made me faster. My team didn't get faster. Here's where I think the gap comes from.
Agentic tools made me faster. My team didn't get faster. Here's where I think the gap comes from.
On the slow, quiet privatization of expertise in the age of useful tools.
Keying equals() and hashCode() off an ID field is such a common Java pattern that it reads as correct — but identity is external and referential, while equality is structural, and conflating them can quietly cost you real money.
We built continuous integration and delivery around our code, but coding itself is still edit-then-compile-then-see. Relational databases figured out atomic, non-disruptive change decades ago — what if languages worked that way too?
Enterprises burn enormous resources rewriting applications from scratch every few years, mostly to reimplement business rules that never actually changed. The waste starts the moment business logic gets lost in translation to a specific technology stack.
UML was built for a mutable, object-oriented world that functional programming and agile prototyping have both left behind. That doesn't mean modeling languages are obsolete — it means we still haven't found what replaces UML.
Functional languages treat the unit type as barely more than void, yet it demonstrably contains exactly one value — which makes it stranger, and more useful, than it first appears. There isn't one unit type. There are infinitely many.
Teams don't scale horizontally past a certain size, and developers can't type any faster either. If seniority is mostly a matter of recognizing patterns, the patterns — not the typing — are what's worth automating.
If the graph structure of types looks exactly like the graph structure of values, the same reduction rules and evaluation techniques should work for both — which means type inference and expression evaluation can become the same operation.
RDF triples are an elegant knowledge representation, but they leak the moment a statement relates more than two things. Extending triples to tuples fixes the leak and produces a graph model that unifies data and logic under one traversal semantics.
From discovering the Semantic Web as a better domain modeling tool, through the limits of Java and the revelation of Scala's functional programming, to the decision to start building a language of my own.
SQL and spreadsheets solve a huge range of real-world problems with nothing but basic data manipulation operators, while general-purpose languages drifted toward hardware concerns and left ordinary users behind. What would a language look like that stayed in that intersection?
Software's constant reinvention leaves an industry fragmented by language barriers and impedance mismatches. Scala showed that unifying existing ideas beats inventing new ones — starting with treating logic and data, and types and values, as fundamentally the same thing.
Types and sets both group things, but sets are defined by a membership relation attached to values, while types have to be predefined before any value exists. What happens when you try to bring membership back into a type system?
Lists, options and single values are usually treated as unrelated container types, but they're really the same value at different multiplicities. What happens if a language makes multiplicity a first-class, explicit part of every type?
A confession about what actually made OOP so seductive — not that objects modeled the real world well, but that the 'new' keyword felt like creating life, and that's a hard thing for any developer to give up.
Moving data into memory to process it is such a basic assumption that no one questions it — but moving logic to where the data already lives would be far more efficient, if only we had a language that made it practical.
OOP promised that state and behavior belong together because that's how the real world works. In practice most codebases separate them into data-only POJOs and logic-only services — so where exactly did that promise break?
We keep attacking software complexity with new libraries, frameworks and tools, and it keeps growing anyway. Maybe the fix isn't fighting it or hiding it behind magic — it's letting the machine write the repetitive parts for us.
On why software development expertise takes years to acquire, and whether the parts of it that are purely technical could be captured in a model instead of relearned by every developer.