Paul Graham’s essays offer a unique lens on hacking that goes beyond the typical image of a “techie breaking into systems.” As someone who’s been coding for a while, I really connected with his view of hackers as makers. In Hackers and Painters, he compares hacking to painting, and honestly, that metaphor fits. Hacking isn’t just about solving problems with brute logic; it’s about creativity. You start with an idea, sketch out some code, and refine it until something elegant emerges. This is exactly how I’ve approached projects—whether it’s writing a new script or debugging someone else’s code. It’s not always clean, and sometimes it feels more like art than science.

One part of Hackers and Painters that really hit home for me was when Graham talks about coding as “sketching.” In college, I was taught to meticulously plan every line of code before I touched the keyboard (This is an exaggeration but the point stands). The idea was that you’d avoid errors by having everything perfectly mapped out. But in reality? Coding almost never works that way. I’ll write code, test it, break it, and then fix it—just like a painter adjusting brushstrokes until the picture looks right. Debugging isn’t the final step like we’re often taught; it’s more like the process itself. I felt validated reading Graham’s take, especially when he says hackers should think of code as something malleable, like a pencil sketch you can change. For me, this is a more honest reflection of how we work—whether you’re building a web app or a machine learning model.

But Graham’s Good Bad Attitude raised some interesting questions for me as a coder who also understands the importance of boundaries. He argues that being disobedient—challenging norms—is essential to being a great hacker. And while I get that rule-breaking is sometimes part of the process (like when you find an unconventional solution to a bug or bypass a limitation), I’m cautious about how far that should go. Sure, we all love a good hack, like bypassing some API rate limit or finding a faster way to sort data, but that doesn’t mean breaking every rule is beneficial. Graham romanticizes the idea that hackers thrive on disobedience, but not all rules are made to be broken, especially when you’re dealing with security, privacy, or real-world consequences. A balance between creativity and responsibility is key in my experience, and I think he glosses over that a bit.

Graham’s perspective reminds me of Steven Levy’s Hackers: Heroes of the Computer Revolution, which I read when I was getting into programming. Levy highlights the early hackers as these rule-bending, basement-dwelling rebels who fought against corporate control to make computing more open. While Graham also celebrates this rebellious spirit, his take feels broader. Instead of framing hackers purely as people fighting “the system,” he sees them more as artists—people who build and create for the sheer joy of it. I appreciate that expansion because it reflects my own experience as a developer. I don’t always feel like a rebel; sometimes I’m just driven to make something cool, something that works better or looks cleaner.

Take What You Can’t Say, for example. In this essay, Graham talks about how societies always have unspeakable truths—ideas that everyone’s afraid to question. For hackers, this is incredibly relevant. We live in a world of tech constraints, whether it’s software patents, licensing, or “this is the way we’ve always done it” mindsets. Hackers, in Graham’s view, are the ones who question these limits and push past them. I’ve felt this when working with closed-source software. There’s always that temptation to poke around, see how things work under the hood, and maybe tweak something you weren’t “supposed” to. This hacker mindset—to question and explore—has led to some of my most creative moments in programming.

One of the best examples of this hacker spirit comes from the open-source movement. Graham touches on this indirectly when he mentions the importance of intellectual curiosity and the drive to figure things out. The first time I dove into the source code of an open-source project, it felt like I’d unlocked a whole new world. You’re not just a passive user anymore; you’re an active participant, able to dig into the guts of a program, improve it, or fork it entirely. That’s the kind of “maker” culture Graham is talking about—a culture where you can bend the rules of software and build something completely new from it.

At the same time, Graham’s idealized hacker—especially in Good Bad Attitude—feels a little off to me. He’s right that questioning authority is central to hacking, but there’s a difference between creative problem-solving and hacking for hacking’s sake. Don’t get me wrong, I’ve definitely hacked just to hack a few times but I’m not saying I was in the right in those situations. A few times, I’ve seen people in the community treat hacking like a game, where breaking something is the goal, rather than improving or creating something. That’s where I disagree with Graham’s idea that rebellion is always a good thing. Just because you can break a system doesn’t mean you should. Responsible hacking means knowing when to push back and when to build something better.

Finally, Graham’s portrayal of nerds and hackers in Why Nerds Are Unpopular is something I could relate to. His insight into how nerds (and hackers) are often unpopular because they care more about mastering their interests than fitting into social hierarchies really hit home. When I was deep into coding in high school, I wasn’t thinking about popularity—I was more interested in figuring out how to write better code or build cool stuff with Python. Hackers, as Graham describes, aren’t necessarily looking for social validation. They’re motivated by curiosity and the joy of making things. This fits with how I’ve approached programming—coding for the sake of learning and creating, not for external recognition.

In the end, Paul Graham’s view of hackers as makers resonates with me, especially when he ties hacking to creativity and curiosity. But I’m also aware that there’s more to it than just breaking rules or being a rebel. Good hacking, in my experience, is about pushing boundaries thoughtfully and building things that matter. Graham’s essays expanded my view of what it means to be a hacker, but they also reminded me that with great power comes great responsibility—especially when your code can change the world.