What Software Developers Might Learn From The US Marine Corps

by Jodson Graves

I. Two Cultures at the Crucible

I am not a developer. I want to be clear about that before anything else, because the observations that follow come from outside the guild, and outside is a specific kind of seeing. You notice what insiders have stopped noticing. You admire what insiders take for granted. And sometimes you see a danger that the people closest to the work cannot see precisely because they are closest to it.

I am a former United States Marine, trained at the Defense Information School in communication strategy and operations. I have spent more than a decade studying biblical linguistics, tracing the etymology of words that civilizations built their moral frameworks on. I run translation operations across six languages. I attempted to build local pharmaceutical production infrastructure in West Africa to break the cycle of extractive foreign aid. I failed at that, learned from it, and kept building. I lead the Network Theory Applied Research Institute today, a nonprofit developing community-owned infrastructure as an alternative to the extractive platform economy. My work puts me in daily contact with developers — good ones, serious ones, people of genuine skill and dedication. This essay is written in respect of that dedication and in concern about what that dedication, shaped by a particular culture, is producing.

The Marine Corps gave me a framework for thinking about leadership. It is called JJDIDTIEBUCKLEE — an acronym containing the fourteen leadership traits every Marine is expected to develop: Justice, Judgment, Dependability, Initiative, Decisiveness, Tact, Integrity, Endurance, Bearing, Unselfishness, Courage, Knowledge, Loyalty, Enthusiasm and Empathy. These are not suggestions. They are not a values poster in a break room. They are a formation system — a structured answer to the question of what kind of person should be trusted with authority over other people's lives. It is a warrior's ethos, shaped by millennia of warfare near and far.

Developer culture has its own formation. It follows a pattern that this essay will trace through the history of craftsman traditions that shaped every technological civilization before ours, and into the specific crisis that now confronts not just developers but all of humanity.

The Bronze Age craftsman stood at the furnace and shaped civilization without knowing exactly where they were leding us. The developer shapes civilization knowing it, with tools of incomparably greater reach. That knowledge is the burden history has placed on the guild. This essay is about whether the guild's ethos is adequate to carry it.

II. What Developers Do Well

Honest criticism begins with honest respect.

Intellect is the most obvious strength of the developer. The autodidactic drive in developer culture is extraordinary. Developers study obsessively, build personal projects without pay, contribute to open source repositories that serve millions of people who will never know their names. The depth of technical knowledge that serious developers accumulate is comparable to the most demanding craft traditions in history. A senior architect who has spent twenty years understanding distributed systems at a profound level is not unlike the master stonemason who understood load and stress and material in ways that no blueprint could fully capture. The knowledge lives in the hands and in the judgment, earned through repetition and failure and the mentorship of those who failed before them.

The good developers genuinely love the work. This is rarer than it sounds. Most of human labor throughout history has been performed by people who would have preferred to be doing something else. Developer culture, at its best, produces people who think about the problem on the weekend not because they are compelled to but because the problem is genuinely interesting to them. That energy has built remarkable things, particularly in the open source tradition. The ethos of scratching your own itch — identifying a problem, building a solution, releasing it for others to use and improve — is one of the more admirable cultural exports of the developer world. It maps directly onto the Marine Corps trait of initiative: seeing what needs doing without being told.

Endurance shows up in the capacity to debug systems for hours, to hold a complex architecture in working memory across days and weeks, to push through the frustrating middle sections of a project when the initial excitement has faded and the completion is not yet visible. The crunch culture that has exploited this endurance is a separate and serious problem, but the underlying capacity is real and deserves acknowledgment.

These are genuine virtues, not performances. They are not marketing. They are the reasons developer culture has produced things of real value and will continue to. Naming them clearly is not a setup for dismissal. It is the foundation on which an honest comparison must be built.

For more on developer culture see Pekka Himanen's The Hacker Ethic

III. Where the Comparison Gets Honest

JJDIDTIEBUCKLEE is not a checklist for personal excellence. It is a framework for what you owe other people. That is the distinction that matters when you hold developer culture against the mnemonic, because the traits where developer culture underperforms are almost entirely the relational ones — the ones that locate a person within a community of obligation rather than within a project of individual mastery.

Bearing is where things diverge most visibly. The Corps invests heavily in how a leader presents — composure under pressure, the ability to project calm authority in a room that is frightened or confused, the discipline of physical and emotional presentation as a form of service to the people who are looking to you for direction. Developer culture often inverts this deliberately. Hoodie aesthetics, studied irreverence, and anti-formalism are worn as badges of authenticity. There is something genuine in that refusal of empty performance. But there is also a cost — a culture that conflates informality with substance can produce leaders who cannot hold a room when it matters, who mistake the absence of pretense for the presence of gravity.

Unselfishness is the deepest fault line. The mnemonic demands that leaders subordinate personal gain to the mission and to the people depending on them. Developer culture frequently celebrates individual genius — the 10x engineer, the founder mythology, the cult of the brilliant lone architect whose vision everyone else exists to implement. Platform capitalism built by developers has extracted from communities at a scale that previous extraction methods could only dream of. The attention economy, the surveillance economy, the gig economy — these are not the work of obvious villains. They are the work of talented people operating within a culture that never asked them to measure success by what their work did to the communities it touched.

Tact — the ability to communicate difficult truths without creating unnecessary enemies — is genuinely underdeveloped in a culture that valorizes bluntness and brands frankness as a virtue without distinguishing it from social intelligence. The Corps teaches that tact is not dishonesty. It is the skill of remaining in relationship with the people you need to influence. A culture that has no patience for tact is a culture that can only lead people who already agree with it.

Justice and Loyalty, held together, reveal something important. Developer loyalty tends to flow toward the product, the codebase, or the founding idea. Marines learn that loyalty flows in both directions — up to the mission and down to the people under your command. Most developer culture understands upward loyalty instinctively. The company, the product, the vision. Downward loyalty — to the users, the communities, the people whose lives are shaped by what you build — is structurally absent from most of the incentive systems that govern how developers work and what they build.

Moral Courage is perhaps the most urgent gap. The Corps treats courage as extending far beyond physical bravery to include the willingness to tell a superior officer they are wrong, to refuse an unethical order, to stand in a meeting and say that what is being proposed will harm people. Developer culture has physical safety and social comfort that Marines never enjoy. But the institutional moral courage to challenge the direction of a platform, to refuse a feature, to whistleblow a harm — this is rare in dev culture and punished when it appears. The people who have done it are remembered as cautionary tales more often than heroes.

Decisiveness may be the sharpest operational contrast. The Corps trains decision-making under uncertainty with incomplete information, because the alternative — waiting for perfect information — gets people killed. A decision made now with seventy percent confidence is almost always better than a perfect decision made too late. Developer culture has a pronounced tendency toward analysis paralysis, toward bikeshedding and RFC processes that defer accountability indefinitely, toward architectural debates that outlast the relevance of the problem being solved. This is not stupidity. It is the natural product of a culture that has been rewarded for precision and punished for premature commitment, applied in contexts where that calculus has stopped working.

None of these are character deficiencies in individual developers. They are cultural formation gaps — the predictable result of a guild that cultivated the craftsman virtues and skipped the communal ones. To understand how that happened and why it matters so much now, you have to go back to the furnace.

IV. The Craftsman in History

Civilization has always run on craftsmen. Not on kings, not on generals, not on philosophers — on people who knew how to do a specific thing at a level of mastery that no one else around them could match, and who transmitted that knowledge carefully to the next generation.

The Bronze Age did not happen because of imperial decree. It happened because someone learned to smelt copper and tin at the right temperature, in the right ratio, and then taught someone else. The furnace tender was civilization's hidden engine. The pyramids required not just laborers but a deep knowledge class — stonemasons who understood load and stress, surveyors who could hold precise angles over vast distances, rope-makers whose materials had to perform under forces no one had calculated formally. Medieval Europe's cathedrals were the accumulated work of guilds that preserved technical knowledge across generations, developing solutions to structural problems that would not be formally theorized for centuries after the buildings were already standing. The Industrial Revolution ran on millwrights and toolmakers and instrument craftsmen whose precision made everything else possible.

Craftsman culture across all these eras shares recognizable traits. It is local — skills were transmitted in workshops, through apprenticeship, through physical proximity over years. It is independent — the craftsman's identity is bound to mastery, not to an employer, and this independence was both the source of quality and the basis of dignity. And it is closed — guilds, trade secrets, and professional insularity were not merely selfishness. They were how knowledge was preserved and quality was maintained before institutions existed to do that work. The journeyman system, where a craftsman traveled to learn under multiple masters before earning the right to establish their own practice, was civilization's distributed knowledge network before networks existed.

These traits carry both virtue and limitation, and honesty requires holding both simultaneously. The closure that protects craft knowledge also produces gatekeeping. The independence that sustains quality also produces insularity. The local rootedness that builds community also produces parochialism and resistance to knowledge that arrives from outside the tradition. Craftsman cultures have always had to be understood on those terms — admirable and limited in the same motion, serving civilization while also sometimes standing in its way.

Developer culture is a craftsman culture. It exhibits every one of these traits with remarkable fidelity — the local transmission through bootcamps and mentorship and pair programming, the independent identity bound to mastery of specific stacks and languages, the guild insularity visible in credentialism and in-group language and the hierarchy from junior to senior to principal to architect that maps almost directly onto apprentice, journeyman, and master. Open source is developer culture's commons, the equivalent of the guild's shared technical knowledge. Proprietary shops are its closed workshops. The conference circuit is its journeyman system.

This inheritance is not a criticism. It is an explanation. Developer culture behaves like a craftsman culture because it is one — the most recent in a long line that stretches back to the first furnace.

V. Automation's Long Shadow

What has shadowed craftsmen throughout history, in every age and every tradition, is automation. This is not a modern anxiety. It is an ancient one, and societies have grappled with it for as long as there have been machines that could do what human hands previously did.

The political response to labor-displacing technology predates the Luddites by centuries. Guilds that regulated the introduction of new tools were not simply conservative institutions protecting privilege — they were civilization's mechanism for managing the speed of disruption against the human capacity to absorb it. Apprenticeship laws, trade protections, licensing requirements — many of these were forms of managed transition, ensuring that the embodied human knowledge of a craft tradition was not simply discarded faster than it could be reformed into something new.

Every automation wave in history has followed a recognizable pattern. A new technology displaces human labor in a specific domain. The people whose labor is displaced experience real suffering. Society, through conflict and negotiation and sometimes through violence, develops mechanisms to manage the transition — to slow the pace enough for communities to adapt, redistribute some portion of the productivity gains, create new forms of work from the residue of capability that the machine has not yet reached.

This pattern has held across the mechanization of agriculture, the introduction of the power loom, the electrification of manufacturing, the automation of clerical work. Each time, the machine consumed the physical or repetitive dimensions of craft while leaving the cognitive and creative residue to humans. The weavers displaced by mechanical looms had grandchildren who became something else. The pattern was brutal for individuals and generationally survivable for communities because the residue of human capability kept reforming into new kinds of work that machines could not yet do.

Developers exist squarely within this tradition, both as craftsmen who have faced automation threats to their own guild and as the people who built the automation that threatens others. They are simultaneously the furnace tenders and the furnace builders — a position that has given developer culture an unusual and not always comfortable relationship to the history of labor displacement.

VI. The Inversion — When the Furnace Faces Itself

Here is what makes this historical moment genuinely unprecedented.

The Bronze Age craftsman at the furnace was never threatened by the furnace itself becoming a craftsman. The loom weavers displaced by mechanical looms were not replaced by looms that could also design fabric, manage client relationships, negotiate contracts, and train apprentices. Throughout the entire history of automation, the technology has consumed the physical and repetitive dimensions of craft while the cognitive, creative, and relational residue remained irreducibly human. That residue was always where the next generation of craftsmen reformed themselves. It was the floor beneath every displacement.

Robotics combined with general-purpose artificial intelligence does not observe that floor.

For the first time in the history of automation, the technology threatens not just the physical execution of craft but the reasoning, the problem-solving, the architecture, the judgment that made craftsmen indispensable in the first place. The residue that has always been humanity's refuge is now the frontier of the machine. And the craftsmen most directly in the path of this new wave are the very people who built it — the developers whose guild culture produced the tools now being turned on the guild itself.

This is not irony in the literary sense. It is a civilizational inflection point. Developer culture produced the automation zenith now aimed at developer culture — and through it, at nearly all of us. The knowledge worker, the analyst, the writer, the researcher, the logistics planner, the customer service professional, the medical diagnostician — the residue of human cognitive capability that automation has always respected as its limit is now the explicit target of the most rapidly developing technology in human history.

The historical tools for managing automation's threat to craftsmen and communities assume that human knowledge accumulates faster than machines can be built to replace it. That assumption has now been reversed. There is no guild regulation for a large language model. There is no apprenticeship system that produces human expertise at the pace a model can be retrained. There is no journeyman network that distributes human capability faster than cloud infrastructure can distribute machine capability. The mechanisms civilization has developed over centuries to protect communities from the worst consequences of technological displacement were all built on a foundations that no longer hold.

This does not mean defeat. It means that the response required is of a different order than anything the craftsman tradition has produced before.

VII. Statecraft

What is needed is not regulation alone, though regulation matters. It is not open source licensing alone, though open source matters. It is not cooperative ownership alone, though cooperative ownership matters. It is a transformation in how developers understand their social location — not as builders who deliver products to a market but as participants in a civilization that will either remain human in character or will not. And it requires society to stop being a passive consumer of technology and become a demanding, informed, organized participant in how technology is governed.

That is not natural in a culture that has been trained to receive technology as magic — to marvel at the product without asking about the architecture, the ownership structure, the incentive design, the accountability mechanism, the exit plan. Technological literacy is no longer a professional credential. It is a civic requirement, as fundamental to self-governance in this century as basic literacy was to self-governance in the centuries after the printing press.

That parallel is not accidental. The printing press did not save humanity from concentrated information power by itself. It required a civilization-scale decision to universalize literacy — to build public schools and public libraries, to treat the ability to read and interpret text as a commons rather than a privilege. That decision was contested. The people who held power through information scarcity did not welcome it. It took generations and it took conflict and it took the accumulated pressure of communities that refused to remain dependent on intermediaries to interpret the world for them.

The digital revolution has produced the most powerful information and coordination infrastructure in human history, and has largely kept the literacy required to govern it inside the guild. The abstraction layers that make technology accessible to ordinary people are the same abstraction layers that make it incomprehensible to them as a system of power. Most people can use a smartphone. Almost no one understands what the smartphone's software is doing with their attention, their data, their social relationships, and their sense of reality. That gap is not an accident of complexity. It is a structural feature of a technology economy that profits from dependency.

Closing that gap requires developers to become something craftsmen have rarely been asked to be: partners with society rather than providers to it. The distinction matters enormously. A vendor optimizes for the client. A partner shares responsibility for outcomes. Throughout the digital era, the dominant relationship between developers and the communities their technology affects has been vendor and consumer — and that relationship has allowed enormous harm to accumulate behind the abstraction of the platform, the algorithm, the model, as though these were natural phenomena rather than choices made by people who could have chosen otherwise.

Partnership looks different. It means developers sitting across from firefighters and farmers and teachers not as consultants but as neighbors, asking what problems actually need solving before writing a line of code. It means communities owning the infrastructure that serves them — not as charity from the technology sector but as a structural correction to a structural problem. It means the formation that the Corps demands before it grants authority: you do not get to shape lives at scale without first being accountable to lives at ground level.

VIII. The Work Is Already Happening

Transformation at civilizational scale sounds abstract until you meet Grace Graves.

For three years, the secretary and treasurer of the Network Theory Applied Research Institute has funded the work herself. Not venture capitalists, not a local, state or federal grant. Grace is my wife and also a US Marine. While she provided the funding, I researched and developed the Institute's programs and policies, and oversaw the work. Not a foundation with a program officer and a theory of change document. Two people, holding the line, because we believed the work was real and necessary. Only in the last six months has a single volunteer-turned-donor joined Grace in financial commitment, and in the last year, I was joined by Calvin Secrest a fintech, backend developer with 15 years of experience. The programs being built — COER for community emergency response, Agrinet for agricultural systems, LBTAS for trade assessment, SoHoLINK for community compute, NTARI OS for cooperative infrastructure, and more. These programs exist because a small group of people refused to wait for permission or resources to do what needed doing.

This is not a startup story. There is no exit. The Municipal Counter-Automation Strategy is not a product roadmap — it is a framework for returning technological agency to the communities that need it most, applied program by program, institution by institution. COER applies it to emergency response management, working directly with fire departments to build systems those departments own and control rather than licensing from vendors whose interests are not aligned with public safety. Agrinet applies it to food systems, where the combination of automation and platform monopoly threatens to remove the last forms of human-scale economic participation from rural communities. SoHoLINK creates community compute marketplaces where the infrastructure value stays in the community rather than flowing to distant shareholders. NTARI OS gives communities the foundational infrastructure layer to run any of it without depending on a platform that can change its terms of service unilaterally and end everything built on top of it.

These programs are not waiting for the transformation to happen. They are the transformation, in its early and most difficult stage — the stage where the gap between what is possible and what is resourced is widest, where the people doing the work are doing it on conviction and personal sacrifice before the broader recognition arrives. Every significant cooperative infrastructure project in history has had this stage. The question is always whether enough support arrives in time to carry the work past it.

IX. The Rest of the World Is Not Waiting

While the United States — the country that built the internet, that produced the developer culture that constructed the global digital infrastructure — struggles to reliably recognize its own voters, other nations are experimenting with Consul Democracy, with participatory budgeting, with digital cooperative governance, with community-owned communication infrastructure as a civic right rather than a commercial product. The tools of democratic participation are being built and deployed in places that did not invent them and are not waiting for the inventors to lead.

This is not a reason for despair about what is possible here. It is a reason for urgency about the gap between what is possible and what is being done. The knowledge exists. The technical capacity exists. The moral tradition — from the Corps, from the craftsman guilds, from every community that has ever organized itself against a power that could not see its faces — exists. The Municipal Counter-Automation Strategy is viable not because it is untested idealism but because it applies lessons from the history of cooperative infrastructure to the specific conditions of the current automation wave, with programs grounded in real community needs and real technical capability.

What has been missing is the decision by enough people to treat this work as the civic priority it actually is, at a scale commensurate with the threat. The rest of the world is making that decision in various forms, with various tools, at various levels of sophistication. The question is not whether it can be done. The question is whether the communities that most need it will choose to do it before the window in which they still can closes around them.

X. The Formation That History Is Asking For

The Bronze Age furnace tender shaped civilization without knowing it. The developer shapes civilization knowing it, with tools of incomparably greater reach and speed, and that knowledge is the burden that history has now placed on the guild.

The Marine Corps framework is not the only way to think about what that burden requires. But it offers something that developer culture has not yet built for itself: a clear answer to the question of what kind of person should be trusted with authority over other people's lives. Not the most talented person. Not the most efficient person. The person who has been formed — who has internalized justice, judgment, dependability, initiative, decisiveness, tact, integrity, endurance, bearing, unselfishness, courage, knowledge, loyalty, enthusiasm and empathy not as a personal achievement but as an ongoing obligation to the people depending on them.

Craftsman culture has always produced people of extraordinary individual capability. What it has not reliably produced, in any of its historical forms, is people formed for collective responsibility at civilizational scale. That gap did not matter much when the craftsman's reach was local and the consequences of getting it wrong were bounded. It matters enormously now, when the craftsman's tools shape the information environment, the economic conditions, and the governance capacity of the entire human species.

The transformation required is not the replacement of developer culture. It is its completion — the addition of the relational, communal, morally formed dimension that craftsman culture across all its history has tended to leave out. Developers partnering with communities rather than being captive to serving markets. Communities developing the technological literacy to be genuine partners rather than passive consumers. Institutions and funders and leaders recognizing that the cooperative infrastructure work happening right now, underfunded and understaffed, is the most important technology work of this generation.

The Corps would say that formation has to happen before the crisis, not during it. The crisis is not coming. It is here. The furnace is running. The question is who is going to tend it, who it is going to serve, and whether the people closest to it have been formed for the weight of that responsibility.

The Network Theory Applied Research Institute is a 501(c)(3) crafting a partnership between developers and communities. Our mission is supporting the public development of the internet. We're developing multiple free software solutions you can learn about at NTARI.org. Join the Software Development Service at ntari.org/sds and gain access to resources for developing and marketing community solutions. Support our research and development at ntari.org/donate. Contact: info@ntari.org