Software is built by people who share specific cultural assumptions, communication patterns, and values. The culture is mostly invisible to its participants but substantially shapes what gets built, how it gets built, and which problems get attention.
I want to think through what the actual cultural patterns are and what they shape.
The dominant cultural patterns of contemporary software work
Several patterns characterize the cultural environment most software work happens within:
1. Novelty preference. The culture rewards adoption of new technologies and approaches. Established technologies are often treated as boring or legacy regardless of their actual capability.
2. Optimization focus. Substantial cultural attention to optimization — code optimization, workflow optimization, productivity optimization. The optimization often consumes more time than it saves.
3. Public production. Increasing pressure for software work to happen in public — open source contribution, blog writing, conference speaking, social media engagement. The public production substitutes for private work in many cases.
4. Methodology religion. Strong adherence to specific methodologies (Agile, microservices, specific testing approaches). The methodologies are often defended as values rather than evaluated as tools.
5. Conference and content economy. Substantial cultural attention to software conferences and content creation. The conference and content circuit shapes who gets attention regardless of actual technical contribution.
6. Tool fetishism. Cultural fascination with software tools that often exceeds any productive benefit from the tools themselves.
7. Burnout normalization. Working patterns that produce burnout are treated as normal or even admirable in significant portions of the culture.
These patterns shape what gets built and how. They also shape who succeeds in software work and what kind of careers are possible.
What the novelty preference produces
The cultural preference for novelty over established technology has substantial effects:
Underutilized established technology. Technologies that work well but are not currently fashionable get less use than their capabilities warrant. PHP, traditional relational databases, server-side rendering — all genuinely capable technologies that get less attention than newer alternatives.
Constant technology churn. Teams adopt new technologies that fade within a few years, requiring constant retraining and migration.
Reduced depth. Practitioners spread shallow attention across many technologies rather than developing deep capability in fewer.
Resume-driven architecture. Technology choices reflect what looks good on engineer resumes rather than what serves the project.
The culture-driven novelty preference produces substantial cumulative cost across the industry. The cost is invisible because it is so widely distributed.
What the public production pressure produces
The pressure for software work to happen in public has shifted what gets built:
Performative work. Substantial portions of "open source" contribution and "thought leadership" content function as personal branding rather than substantive work.
Reduced private capability development. Time that should support deep skill development goes toward public visibility instead.
Career paths through visibility. Public visibility increasingly substitutes for substantive technical capability in career advancement.
Cultural homogenization. The visibility-focused work tends toward cultural conformity. Distinctive technical perspectives that do not perform well publicly receive less attention.
The public production culture produces specific outcomes that the previous private production culture did not. Whether these outcomes are net positive is contested.
What the methodology religion produces
The strong adherence to specific methodologies produces:
Methodology cargo culting. Adoption of methodology forms without understanding their underlying purposes. The forms continue to be performed even when they no longer serve the original purposes.
Methodology debates that substitute for substantive technical work. Substantial energy goes toward defending or attacking specific methodologies. The energy could go toward actual technical work.
Reduced methodology evaluation. Methodologies are treated as values rather than tools. Their actual outcomes get less evaluation than they should.
Professional identity construction through methodology adherence. Practitioners increasingly identify as "Agile" or "TDD" or other methodology adherents rather than as engineers solving specific problems.
The methodology culture produces specific patterns that affect both individual practitioners and the broader industry.
The cultural inheritance question
Software culture has historical roots that shape contemporary practice. Much of contemporary software culture inherits from specific subcultures of earlier eras:
- Open source culture from 1990s and 2000s
- Startup culture from 2000s and 2010s
- Conference and content culture that emerged with social media
- Specific methodology cultures (Agile from 2000s, lean from 2010s)
The inheritance affects what assumptions seem natural and what alternatives seem strange. Understanding the historical origin of cultural patterns helps recognize them as choices rather than necessities.
The cultural variation question
Software culture varies substantially across geographies, industries, and organizational types. The dominant culture I have described is one particular version — primarily reflecting contemporary US-based commercial software work.
Different software cultures exist:
- European software cultures that emphasize different values
- Academic software cultures with different reward structures
- Government software cultures with different constraint structures
- Specific industry software cultures (finance, healthcare, embedded systems) with different priorities
- Open source community cultures with their own dynamics
The "software culture" I have described above is not universal. Different cultural contexts produce different outcomes.
What practitioners can do
For practitioners aware of cultural patterns and wanting to navigate them deliberately:
1. Recognize the cultural pressures as choices rather than requirements. Many cultural patterns can be opted out of by individual practitioners.
2. Choose technical depth over visible novelty. The deeper capability typically produces better long-term outcomes despite less immediate cultural validation.
3. Resist methodology religion. Treat methodologies as tools to be evaluated rather than values to be defended.
4. Maintain private capability development. Not all valuable work happens in public.
5. Resist burnout normalization. Sustainable work patterns produce better long-term outcomes than burnout patterns.
None of these requires leaving the broader culture. They require deliberate engagement with cultural patterns rather than passive adoption.
The longer view
Software culture continues to evolve. The dominant patterns of 2026 differ from dominant patterns of 2010 which differed from dominant patterns of 2000.
The patterns are not inevitable. They reflect specific choices by practitioners, organizations, and the broader industry. Different choices produce different cultures.
For practitioners interested in shaping software culture rather than passively reflecting it, deliberate engagement with cultural patterns is necessary. The patterns continue because practitioners participate in them; they could change if practitioners chose to participate differently.
A closing observation
I find software culture interesting partly because it is so consequential and so largely invisible to its participants. The cultural assumptions shape what gets built, how careers develop, what kinds of work are possible.
The cultural critique I have offered is not pessimistic. Software has produced extraordinary things despite its cultural limitations. The cultural patterns can be navigated deliberately by practitioners who recognize them.
For practitioners aware of cultural patterns, the deliberate engagement produces better outcomes than passive participation. The work continues; the culture continues to shape it; individual practitioners continue to make choices about how to engage.
The choices matter. They shape both individual careers and the broader industry trajectory.
