Debugging the Human Layer
How philosophy, radical ideas, and a few humbling books reshaped how I understand software engineering.
I. The Most Dangerous Idea I Ever Learned
I still remember the moment I first read the story of Socrates, as told by Plato. There he was: a man wandering Athens, annoying the powerful, relentlessly questioning everything. But what struck me most was his conclusion: “I know that I know nothing.”
At the time, I didn’t realize it would become a survival skill.
I learned to code on my own, as a kid, without formal instruction or community. For years, I thought being good at programming meant knowing things. Now I know better: it means knowing how little you know, and how fast everything can change. That epistemic humility—that awareness of your own ignorance—is what truly stuck with me. And it’s the thread that ties together my entire journey.
II. Dijkstra, and the First Shock of Radical Thinking
My first encounter with Edsger Dijkstra was jarring. Here was someone who didn't just love correctness—he demanded it. To him, programming was mathematics in disguise. The sloppiness we tolerated was unacceptable. His writing felt like a slap across the face.
But it was also a gift.
Dijkstra taught me to take programming seriously. He showed me that under the hood of our “move fast and break things” culture, there’s a deeper discipline—one that demands clarity, precision, and restraint. He didn’t make me a purist. But he made me humble.
III. From Code to Product: My Second Awakening
My early years were all about code. I loved it, and I thought that was the job. Then I entered the workforce—and everything changed.
Suddenly, my brilliant code wasn’t enough. Features didn’t ship because requirements changed. Deadlines slipped because of unclear priorities. Merge conflicts became emotional conflicts.
That’s when I realized something: building software is not about writing code. It’s about delivering value to real people, within real organizations, with real constraints. And that means dealing with complexity—not just technical complexity, but social complexity.
IV. The Mythical Man-Month: A Book Everyone Quotes Wrong
Reading The Mythical Man-Month by Fred Brooks was like finding the missing manual to software teams. The famous line—“Adding manpower to a late software project makes it later”—is just the beginning.
Brooks was trying to show that software development isn’t like manufacturing. It’s about communication, shared mental models, and the cost of coordination. And yet, the book is constantly misquoted to shut down hiring or collaboration efforts, instead of sparking deeper questions.
V. Conway’s Law: Your Org Chart Is in Your Codebase
Next came Melvin Conway’s 1968 paper, “How Do Committees Invent?”—a short, strange little document that continues to explain why so much software is weird.
Conway’s Law says that systems reflect the communication structure of the organizations that build them. And once you see it, you can’t unsee it. The front end talks to the back end like two rival departments. The database mirrors the ops team’s paranoia. Microservices become miniature fiefdoms.
Understanding this changed how I looked at software architecture—and org design.
VI. Peopleware: Where Everything Finally Made Sense
Peopleware, by DeMarco and Lister, broke me open. It said, plainly: the biggest problems in software are not technical—they’re sociological.
It talked about flow, distractions, toxic management, and the importance of safety and trust. It felt like someone was finally saying out loud the things we all sensed but couldn’t articulate. And for someone with ADHD like me, it gave language to the invisible frictions I felt every day.
VII. Thinking in Systems: Donella Meadows and the Hidden Loops
Donella Meadows’ Thinking in Systems was the last major piece of the puzzle.
Her book introduced me to feedback loops, delays, leverage points, and the subtlety of change. It showed me why naive interventions often backfire. Why “more engineers” doesn’t always mean “faster delivery.” Why teams plateau, burn out, or spin in circles.
This was the moment I realized I wasn’t working on a product—I was working inside a system.
VIII. Modern Software Engineering: Science, Feedback, and Flow
David Farley’s Modern Software Engineering helped me reconcile rigor with iteration. He showed that engineering is not about certainty—it’s about learning. It’s the scientific method under constraints. Test, observe, adapt.
This clicked with my experience. It gave a name to the intuitive loop I’d been building: act, reflect, refactor. And it gave me permission to be curious instead of dogmatic.
IX. Debugging the Human Layer
All of this led me to a simple, hard-earned conclusion:
The hardest bugs are social.
It’s not your code that will sink the project—it’s the trust that was never built, the message that was never sent, the expectation that was never aligned.
Good engineers aren’t the best coders. They’re the ones who can listen, co-create, and build systems—of people, of habits, of care.
Final Thought
We’ve spent decades trying to make software better by writing smarter code.
Maybe it’s time we wrote kinder systems instead.
No hay comentarios.:
Publicar un comentario