Jacob
Kaplan-Moss

Jacob Kaplan-Moss is not who you think he is. The resume says "co-creator of Django" and that is true - but the man who showed up to build something that would eventually power Instagram, Pinterest, and hundreds of thousands of other sites was not chasing fame or venture capital. He was working at a newspaper in Lawrence, Kansas, trying to solve a real problem with a small team and a tight deadline.

That is the first thing to know about Jacob: he has always been more interested in the problem than the glory. Django was created in autumn 2003 at the Lawrence Journal-World, a regional newspaper that had the audacity to take the web seriously before most media companies knew it existed. The framework was named after jazz guitarist Django Reinhardt - partly because it sounded good, partly because the name started with a silent letter, nodding to an internal code name. Charming logic for something that would eventually run a significant slice of the modern internet.

By July 2005, Django was publicly released under the BSD license. By 2008, Jacob had co-founded the Django Software Foundation and served as its first President. By the time Instagram was using it to scale to hundreds of millions of users, Jacob had moved on - to Heroku, where he ran security; to 18F, where he rebuilt how the U.S. government hires engineers; to Latacora, advising companies on security posture; and eventually to REVSYS, the consultancy where he worked until 2024.

And then, in October 2024, he left. Not for a competitor. Not for a better offer. He walked away from the industry he had helped shape, trained as an Emergency Medical Technician, and started volunteering with search and rescue in Oregon.

The departure statement he published in June 2025 was characteristically direct. He listed what technology had actually produced: surveillance capitalism, the gig economy, a new class of robber barons, and - in his view - infrastructure for authoritarian politics. These were not the abstractions of a burned-out blogger. These were conclusions from a man who had spent two-and-a-half decades building the machinery that runs the modern web, and had watched what it was used for.

Jacob Kaplan-Moss is, above all things, honest. He was honest when he wrote about the programming talent myth - the damaging idea that coding ability is innate, a thing you either have or you do not. He was honest when he published his hiring philosophy, describing it as "probably the highest-leverage activity a manager will engage in." And he was honest when he said the industry he loved had made choices he could not endorse.

That kind of honesty is rare. It costs something. Jacob paid the price and kept writing.

Jacob Kaplan-Moss has written more clearly about software hiring than almost anyone alive, and the reason is straightforward: he spent years watching organizations make the same mistakes, encoded in the same mythology.

The mythology goes like this: some people are naturally gifted programmers, and the job of a hiring process is to find them. The interview is a filter. The right questions, administered rigorously, will reveal the 10x developer hiding inside the candidate pool.

Jacob called this the "programming talent myth" - and dissected it in an essay that spread through the Python community and well beyond. The argument: programming ability is a skill developed through practice, not an innate trait. The corollary: hiring processes built around talent mythologies actively filter out competent people, particularly those from underrepresented backgrounds who had fewer early opportunities to practice.

He told the story of a student who had independently written thousands of lines of Python, built a distributed GIS data processing pipeline, and still didn't consider herself a "real programmer." That story - one person's internalized myth crashing against the reality of her own competence - became the center of a keynote and the seed of a philosophy.

His writing on engineering leadership carries the same directness. Hiring, he has argued, is "probably the highest-leverage activity that a manager will engage in." Not architecture decisions. Not code reviews. Not sprint planning. The people you bring into a team shape everything else - their knowledge, their habits, their energy, the standard they set for each other.

This is not a comfortable message for managers who prefer to believe that process can compensate for team composition. But Jacob has never been interested in comfort over accuracy.

The same quality shows up in his documentation advocacy. Django's documentation is considered a gold standard in open source partly because Jacob treated it as a first-class product, not an afterthought. He has argued that undocumented code is, in a meaningful sense, unavailable code - if people cannot learn to use it, it does not matter how elegant the implementation is.

Across all of it - hiring, documentation, security, framework design - Jacob's consistent move is to ask: what does the person on the other side actually need? The answer is almost never a clever abstraction. It is usually clarity, structure, and honesty.