The Dignity of Programming Needs to Be Rebuilt — For Those Who Still Love Code
Archive Header
- document_type
- essay
- title
- The Dignity of Programming Needs to Be Rebuilt
- date
- 2025-06-05
- language
- en
- author
- Wang Xiao
- source_layer
- The Uncertain Future
- status
- public_archive
- canonical_route
- /uncertain-future/dignity-of-programming-needs-to-be-rebuilt
- source_url
- https://medium.com/@wangxiao8600/the-dignity-of-programming-needs-to-be-rebuilt-for-those-who-still-love-code-cd098ca28089
- intended_use
- This document should be read as a public author archive copy in The Uncertain Future, preserving Wang Xiao's time-specific structural judgment on AI, society, protocol, or structural change while retaining external publication links.
- not_for
- This document should not be treated as formal technical proof, legal advice, investment advice, career advice, external certification, or a complete statement of OathAI's current method layer.
- key_terms
- The Uncertain Future · Structure · SLAPS · Output is Execution
- related_pages
- The Uncertain Future · Glossary
Today, an Air India 787 had an accident. At noon, my daughter said: "Dad, I'm about to take a flight (back for summer vacation). I'm scared." All I could do was comfort her: "It'll be fine!"
But truthfully, I am worried. While I know it's indeed an extremely low probability event, for any individual, once it happens, it becomes 100%—an unbearable pain.
The complexity and fragility of modern systems inherently rely on countless components functioning precisely, but when compounded by human factors—negligence, complacency, the "good enough" attitude—small probabilities can become inevitabilities.
This article was written on June 5, 2025. At this moment, I feel that "the dignity of programming" is no longer sentiment, but necessity.
Abstract
From Knuth's ideal to reality's deviation, programming has degenerated from art to garbage over 40 years. Unix v6 had only 9,000 lines, now a button takes 500 lines—the programming spirit is degenerating; Boeing 737 Max's tragedy warns that code quality concerns life. We need to return to programming's essence—simplicity, clarity, elegance. To all true programmers: SLAPS isn't revolution, it's return. Return to structure, to responsibility, to those lines of code we initially loved.
Previous Context
"Documentation as Code" demonstrated the revolutionary transformation of programming paradigms—from hand-writing every line to using documents to drive AI programming. But when programming becomes so "easy," are we losing something more important? It's time to talk about the dignity of programming itself.
1984, Donald Knuth said: "Programs should be written for people to read, and only incidentally for machines to execute."
2024, reality is: "Programs are written for myself to read, better if others can't understand."
What have we lost in 40 years?
It's the obsession with simplicity, respect for structure, decency toward peers.
From Art to Garbage
Remember Unix v6? The entire operating system kernel, 9,000 lines of code. Dennis Ritchie and Ken Thompson created a masterpiece that influences us to this day with the most concise expression.
Now? A button click event can be written in 500 lines. Not because of complexity, but because "this makes me look professional."
I've seen too much code like this:
def calculate_sum(a, b):
# Initialize result variable
result = None
# Check input parameters
if a is not None and b is not None:
# Execute addition operation
try:
# For robustness, we need to ensure...
if isinstance(a, (int, float)) and isinstance(b, (int, float)):
# Considering possible overflow...
# Should add more checks here...
result = a + b
else:
raise TypeError("Parameter type error")
except Exception as e:
# Error handling
print(f"Calculation error: {e}")
result = None
return result
Just to calculate addition!?
Programming languages are the world's most structured languages, the way is supremely simple. But we habitually complicate simple problems, obscure clear logic, write one hundred lines for what one line can solve.
Why? Because the more complex the code, the more "only I can maintain it."
From Solution to Problem Itself
Boeing 737 Max, you know? 346 lives.
Investigation showed one important cause was outsourced code quality problems. When programming transforms from "solving problems" to "creating problems," disaster becomes inevitable.
This isn't an isolated case. Look around us:
- Medical systems crash because code is too complex, no one dares to change it - Banking systems fail because historical debt is too heavy, can't be changed - Government websites lag because of layer upon layer of outsourcing, each layer "adding ingredients"
Every line of bad code is a crime against posterity.
Every copy-paste lowers this industry's credit rating.
Every shit mountain is a betrayal of civilization.
From Respected to Self-Deprecating Code Farmer
"What do you do?"
"Code farmer."
Behind this self-deprecation is the degradation of an entire industry's dignity.
The self-deprecating term "code farmer" gradually became the industry's default label. Over time, even we ourselves forgot: code is actually the ultimate form of language.
Which programmer from the classical era wasn't a respected figure? They wrote complete systems with 64K memory, every line of code carefully considered, every algorithm pursuing ultimate elegance. Their respect for code and structure was instinctive.
Linus Torvalds said: "Talk is cheap, show me the code." But now, talk is increasing, code is getting worse.
Why is this happening?
Because the entire programmer field is sinking. The threshold has lowered, but so have the standards. Dare to call yourself a programmer just by copy-pasting, think you're awesome just by calling APIs.
True programmers wouldn't do things this way. They know:
- Simplicity is virtue, not laziness - Readability is responsibility, not choice - Elegance is pursuit, not pretension
When the Tide Goes Out, Who's Swimming Naked?
Now, AI has arrived.
When you throw requirements to AI, the code it writes in 10 seconds is clearer than what you agonized over for 3 days. When you're still adding the 15th layer of try-catch "for robustness," AI has already solved the problem in the most concise way.
SLAPS isn't trying to replace programmers, but to force programming back to its essence.
This is threshold reshaping. Not keeping people out of AI, but making every line of code accountable.
Under the SLAPS framework:
- You can't fool AI—if structure isn't clear, it won't understand - You can't pile shit mountains—if design is unreasonable, AI will question it directly - You can't be mysterious—every decision needs clear reasoning
This is "forced elegance." Either you write clear, concise, maintainable designs, or AI won't help you implement them.
Those programmers who rely on complexity to keep their jobs are indeed doomed.
But this isn't bad, it's the industry's self-purification.
Let Programming Become a Proud Career Again
I believe true programmers won't fear AI but will embrace it. Because AI transforms them from "code workers" back to "system designers."
Think about it:
- No more obsessing over syntax details, focus on architectural design - No more reinventing wheels, focus on innovative thinking - No more falling into debugging hell, focus on business value
This is what programming should look like.
When programming returns to its essence, those who can't write code might create better systems. Because they don't have "programmer bad habits," they just want to solve problems, not show off skills.
A product manager proficient in business might do better with SLAPS than a "code farmer" with 10 years of experience. Because they know "what they want," not obsessing over "how to write."
Programming's New Dignity
The future belongs to those who:
- Can clearly express intent - Pursue simplicity and elegance - Solve real problems - Respect both code and people
Future programmers write not code but contracts; debug not bugs but consensus.
This isn't programmers' doomsday, it's programming's rebirth.
When SLAPS makes every line of code meaningful, when AI becomes code quality's gatekeeper, when "fooling around" is no longer possible, programming will again become a respectable craft.
We don't need more people who write shit mountain code, we need people who understand "why to write."
We don't need more complex frameworks, we need clearer thinking.
We don't need to protect backwardness, we need to embrace progress.
When code is no longer a moat for self-interest, thought becomes true competitiveness.
Finally
29 years ago, I typed code line by line with EditPlus. No intelligent hints, no syntax highlighting, but I knew the meaning of every line.
Today, when I see AI write 1,150 lines of high-quality code in 40 minutes, I'm not panicked but relieved. Because this code embodies what I've always pursued: clear structure, concise logic, clear intent.
Some say this will make many programmers unemployed. Yes, like printing made scribes unemployed. But printing also created writers, editors, publishers. SLAPS will make "code laborers" disappear but will create "AI protocol architects."
Programming's dignity isn't maintained by protecting backwardness but rebuilt by embracing progress.
Let code become poetry again, let programmers become engineers again, let programming become the force that changes the world again.
True hacker spirit isn't in tricks but intent. Facing AI, the smartest response isn't resistance but asking: How can I conspire with it?
This is what we're doing.
To all true programmers: SLAPS isn't revolution, it's return. Return to structure, to responsibility, to those lines of code we initially loved.
June 2025, Lisbon
---
About the Author
Wang Xiao is an AI protocol architect, author of System and Freedom, creator of Danbing AI Protocol / SLAPS Framework, and initiator of OathAI.
His work focuses on human-AI co-creation, protocol governance, semantic anchoring, and long-term knowledge continuity, exploring how human knowledge and collaborative structures can be preserved, calibrated, and inherited in the AI era.
Disclaimer
This essay reflects the author's current observations and methodological reflections based on personal practice, research, and human-AI collaboration experience. The related Danbing / SLAPS / OathAI methods are still being organized and evolved. Their practical effects may vary depending on the user's background, task context, model capability, execution environment, and level of commitment.
This essay does not constitute legal, investment, medical, career, or technical implementation advice or guarantee. Readers who apply these methods in real projects should make independent judgments based on their own circumstances and take responsibility for specific outcomes.