Last week, I gave a talk at a Cursor community event about AI and how it's changing the way we build software. The event went great, and after the talk, quite a few people came up to me for 1:1 conversations.
One particular guy caught my attention. He wasn't a technical person, but he asked me something interesting:
"With so many tools and technologies available today, how do you even navigate all of this and pick the right ones?"
He thought it must be overwhelming. Then he smiled and said that with so many options available, he hopes many great things be built.
I thought about it for a second and smiled too, and before I could answer, he had to leave... but his question stuck with mi.
A few days later, sitting in a library looking for something to read, I ran into an answer: UNIX Network Programming by W. Richard Stevens. (Great book btw, give it a read!)
90s tech, limited memory, limited processing power, limited bandwidth and limited tooling... etc.
Yet somehow, we got things like UNIX, TCP/IP, early operating systems, incredible mathematical breakthroughs, massive engineering projects, and some of the most elegant pieces of technology ever built.
What if the things that limited us were also the things that forced us to become better? What if greatness isn't always created by having more, but by being forced to do more with less?
The guy assumed more tools meant a better shot at greatness, but the book in my hands was proof of the opposite.
We usually think of limitations as something to overcome: less money, less time, fewer resources, less knowledge. All of it standing between us and what we want to achieve.
A limitation doesn't just take something away. It also takes away what could have been.
And maybe that's exactly what we need. Because when everything is available, when every direction is possible, every tool is at hand, every approach is open to us, it sounds like freedom.
You give someone unlimited resources and they can spend a lifetime deciding what to do with them. Give them nothing and the question suddenly gets simple:
That question changes how you think. You stop searching for the perfect tool, because it doesn't exist, and start building with what's in front of you. You notice details that would otherwise stay invisible, not because you're more observant by nature, but because you no longer have the luxury of not noticing.
Maybe that's the real gift of limitation. Narrowing down your options but also sharpening your attention.
Perhaps that's the paradox: the fewer doors we have, the more clearly we see the one we're standing in front of.
Let's take a look at Stevens' book for a moment. The book is essentially a walkthrough of the sockets API: socket(), bind(), listen(), accept(), connect(), read(), write(), and close().
