the committee

rob mee

founder of pivotal labs

mee founded pivotal labs in 1989 and spent three decades proving that the way software is built matters as much as what gets built. under him, labs ran pair programming on one hundred percent of projects with daily rotation—not as an experiment but as the operating system of the company—alongside test-driven development, sustainable pace, and a standup you could set a watch by. the technical interview was literally named after him: the rob mee pairing interview, an hour of writing real code together, because how you think beside another person is the job. as ceo of pivotal he carried that culture to industrial scale with cloud foundry. kanso's conviction that discipline is a gift to the next person—that the practices are the product—is the labs conviction, learned firsthand.

kent beck

creator of extreme programming and test-driven development

beck rediscovered and canonized test-driven development, created extreme programming, co-wrote junit, and compressed a career of judgment into rules that fit on an index card: four rules of simple design; "make it work, make it right"; "make the change easy, then make the easy change." his deepest lesson is about feedback loops—that software quality is a function of how fast the truth reaches you. kanso's whole apparatus of golden tests, differential ci, and executed documentation is beck's feedback doctrine, mechanized.

sandi metz

author of practical object-oriented design and 99 bottles of oop

metz taught a generation that object-oriented design is about messages, not classes—ask "who should respond to this message," not "what classes do i have." 99 bottles of oop made the case, one refactoring at a time, that duplication is far cheaper than the wrong abstraction and that the smallest possible step is the fastest route. kanso's dispatch-is-the-only-branch design is her polymorphism-over-conditionals principle promoted from discipline to grammar: the language simply removes the conditional you were supposed to resist.

avdi grimm

author of confident ruby and exceptional ruby

grimm named the disease and the cure: timid code, forever checking for nil and apologizing to its callers, versus confident code that states its narrative and trusts its objects. exceptional ruby worked out when raising is honest and when it's malpractice; confident ruby showed how to keep absence at the boundary so the core never handles it. kanso's failure model—err and none as values, no nil anywhere, the railway carrying failure past functions that never mention it—is grimm's confident narrative voice, enforced by a type system.

gary bernhardt

creator of destroy all software

bernhardt's boundaries talk gave the functional-core, imperative-shell architecture its name and its clearest argument: put the decisions in pure code with many paths and no dependencies, put the i/o in a thin shell with all the dependencies and no paths, and testing becomes almost embarrassingly easy. kanso is that talk as a language—the pure core is everything, the imperative shell is the executor, and the boundary between them is the type of a value. also he made wat, which is the shortest existing argument for canonical semantics.

rich hickey

creator of clojure

hickey built clojure and datomic, and in a series of talks—simple made easy above all—gave the field its sharpest vocabulary for the difference between simple and merely familiar. his doctrine that simplicity means un-braided, one concern per construct; that state complects value with time; that new information should be new facts rather than overwrites—these are load-bearing walls in kanso. a language of pure values where effects are data and the source contains only decisions is, in large part, an attempt to build what those talks describe.

simon peyton jones

principal architect of haskell's ghc

peyton jones spent three decades proving that purity is not an academic indulgence—leading ghc, shepherding haskell's type system through research result after research result, and showing that a language can be lazy, pure, and industrial at once. haskell is the existence proof kanso leans on: that effects can be values, that the compiler can know everything, and that rigor scales. kanso departs from haskell everywhere it can afford to—fewer concepts, no monads homework—but it departs from a position haskell secured.

abhi hiremagalur

pivotal labs, cloud foundry, asana

last, and the opposite of least. abhi was the pivotal labs of pivotal labs—the engineer other pairing engineers calibrated against, the person in the building whose laser focus and attention to detail set the local definition of done. he helped build cloud foundry at pivotal and went on to lead design-systems engineering at asana, and his writing carries the philosophy in miniature: process is for people; design partnerships, not job descriptions; to reduce the cost of change, compose—don't inherit; a software team's pit stop, like a racing team's, is where the discipline shows. kanso's designer says plainly that abhi changed everything about how he thinks about software: that rigor is a form of care, that the details are not beneath the work but the work itself. a language whose founding principle is that nothing enforceable by convention should be left to convention is, among other things, a monument to pairing with him.

honorable mention: andy hunt & dave thomas

authors of the pragmatic programmer

hunt and thomas wrote the pragmatic programmer, coined dry—don't repeat yourself, a principle about knowledge having one authoritative home, not about deduplicating text—and signed the agile manifesto. thomas's pickaxe book carried ruby out of japan and into the hands of the people above. kanso's rule that every derivable fact lives in tooling while the source keeps only decisions is dry with a compiler behind it.

and, unavoidably: marie kondo

tidying consultant

every name above argued for removing things, and each had a technical case: coupling, duplication, incidental complexity. kondo made the same argument to people with too many jumpers, and made it better — the useful question is whether you would choose it again today. that is a harder test and it disposes of far more.

kanso does not ask about joy. but it did delete a type whose name was a lie, an annotation the compiler could already infer, four ordering rules nobody could justify, and a benchmark figure that did not reproduce — none of which were broken, all of which were kept out of habit. the discipline of holding each thing up and asking whether you would add it today, knowing what you know now, is hers. she just applied it to a wardrobe.