Wenqi He · Research Software Engineer, NCSA, University of Illinois
When I was in college, I started with civil engineering, then bounced to physics and math, and finally settled on computer science. It was a difficult decision—I hated the hype-driven tech culture, but I loved that it was probably the only program outside of math where proof was a basic requirement, not a nice-to-have. (Looking at you, physics!)
I still remember one introductory lecture where the professor pulled up that XKCD comic about purity and pointed at the empty space between physics and math. “We are here,” he said. “We are applied math.”
The truth is, I didn’t hate everything about tech. A software engineer from Facebook once came to teach us how to prepare for algo questions—which I’m still terrible at, though I do enjoy writing and sharing proofs for them. He said that if you actually need to type out the code in LeetCode, you’re doing it wrong. What matters is the thought process, not the mechanical movements of your fingers. “You can literally teach a business major how to do that,” he said.
I thought I was better than business majors until an ethics course we needed to graduate brought me back down to earth. Among all the philosophical concepts—categorical imperative and whatnot—that refuse to stick in my long-term memory, there was one chapter in that textbook I’ll never forget.
It said basically this: software engineering is not a real profession. The field is immature. We don’t have certification or a licensing body. We don’t require passing an exam to be qualified. We don’t have standard practices. We don’t pay nearly enough penalty for the garbage we constantly produce. Imagine if the things we use in our daily lives—appliances, cars, bridges, buildings—were as brittle as the code we write. Imagine if surgeons were as sloppy as we are. Society would probably collapse.
Well. If it wasn’t yet a true profession in the sense that medicine, law, and civil engineering are, then it was our obligation to turn it into one. That realization led me to read Dijkstra and Lamport eventually, and I really admired how they stuck to the formal roots of computing. At the end of the day, computers are discrete mathematical machines, no matter how much Silicon Valley would like you to believe otherwise. People hate math, and you can’t sell things people hate, can you?
Fast forward a few years, and I was reading source code, documentation, man pages, web pages. Learning the latest framework that would be obsolete in two years, memorizing the quirks of some library that only mattered for a month. A world far removed from what I appreciated about computer science: when we proved that there must be at least three machines for a certain distributed algorithm to work, it meant you could tear down the entire universe and build another with different laws, and you would still need three. There is no escape from that necessity.
Snap back to reality and I couldn’t help but feel disappointed. Constant learning, yet nothing of real importance was being learned. I started missing my days as a student. Something felt very wrong, though I couldn’t quite put my finger on it. This feels like a blue-collar job, I thought. No offense to blue-collar jobs.
One day after work in Shanghai, I overheard a conversation floating across the cubicles. “What did you do today?” someone asked. “What else? Hard labor.”
I had never thought of my work that way. And all of a sudden it clicked.
In China, if you go to the countryside, you can see these two- and three-story houses that people built themselves. They just lay down the rebar, pour the concrete, stack the bricks. Everyone builds their house a bit differently—it looks funny, but it gets the job done. You can house your entire extended family in there. It doesn’t leak when it rains, most of the time. Sometimes they put nice shiny porcelain tiles on the side facing the street so it looks fancy, but walk around to the back and it’s just raw concrete and bricks.
I quit my job and started roaming the city. One day I finally realized: writing code is like being a construction worker, minus the physical danger. Construction can be a gig, but it’s never a profession. To have standards, guarantees, predictability—you need civil engineering. And you need math. Even more so when our bricks are made of discrete math, whether or not we want to admit it.
Why math? Why do I keep bringing it up?
I like what Leslie Lamport said in one of his lectures on thinking beyond code: it’s not the content of math that matters—analysis, topology, all of that. What matters is how it teaches you to think. I’m no mathematician, but the most important lessons math taught me were these:
First, clarify. Human language is ambiguous. People use the same word to mean different things. We constantly talk past each other. Most debates lead nowhere because we don’t even agree on basic definitions.
Second, justify. Treat all claims as unfounded by default. Nothing gets accepted at face value. If you’re too lazy to justify something, at least acknowledge it’s an assumption that could very well turn out to be wrong. Or call it an axiom if you’re full of yourself.
Third, simplify. This is the greatest paradox: people are scared of math because of how foreign it feels. It looks complicated, sure, but its goal isn’t to complicate. Quite the opposite—it simplifies the world to such an extreme degree that we can actually fit it in our tiny brains. Math makes complicated things simple, so even though it appears hard at first, it becomes clearer and easier over time. Natural language, on the other hand, might feel easy at first, but because it overcomplicates things with its fuzziness, even simple ideas become messy and difficult over time, until eventually your head explodes.
Speaking of ambiguous language—we’ve been doing exactly that with our own field. For too long we’ve been conflating code production with software engineering, when the difference between repetitive, mechanical labor and critical intellectual work—like construction versus civil engineering—couldn’t be more stark. It would be absurd to call construction workers civil engineers. Yet we call code monkeys software engineers.
I won’t apologize for the derogatory language. To have taste is to discriminate. It’s better to be offended than to miss the reality: thinking is different from doing. Thinking is what we need to turn our profession into a true one. Not to execute and implement, but to envision, plan, design, abstract, reason, critique, reflect, and most importantly, simplify. That’s the key message from Dijkstra and Lamport. What we need is mental control of the entire edifice, not physical control of a single brick.
So when I first saw tools like Cursor and Claude Code generating correct implementations without me having to keep up with whatever the hottest framework or library of the day was, I thought: maybe the day has finally come. Maybe we’re shedding our chrysalis as construction workers and spreading our wings as civil engineers.
I look forward to that future.