You’ve been there. You’re deep in a debugging session, your terminal is a mess of logs, and you need to know which process is squatting on port 3000. You type lsof -i :3000 and get back a wall of noise. You scroll, you filter, you curse. And then—maybe not today, maybe tomorrow—you write a little script. A one-liner that pipes lsof into ps and spits out exactly what you want. You name it whoport and toss it in your dotfiles.
And then someone says: “netstat and lsof already do that. Why reinvent the wheel?”
They’re not wrong. But they’re missing the point entirely.
Every line of code you write for yourself is a step toward owning your system. The real value of that script isn’t the output—it’s the mental model you build while writing it. You’re not just detecting a port; you’re internalizing how your operating system talks to your processes. You’re turning a black box into a glass box.
This isn’t about efficiency. It’s about understanding. And understanding is the only thing that scales.
Most developers think the goal is to use the most efficient tool. But the most efficient tool for a one-time query is often the one that leaves you with nothing but a copied command you’ll forget by tomorrow. The tool you write yourself—even if it’s slower, uglier, and only works on your machine—leaves you with a map of the territory you just explored.
I saw this firsthand when I wrote a version of whoport. I used lsof and ps, just like everyone else. But by wiring them together, I understood the relationship between file descriptors and process IDs in a way that no tutorial could teach me. The best tool isn’t the one that works fastest; it’s the one that makes you understand.
So the next time you feel the urge to write your own version of a common command, don’t suppress it. That urge is your brain’s way of saying, “I need to own this, not just use it.”
Go ahead. Write the script. Reinvent the wheel. You’ll learn more about the road than you ever would by just riding on it.
FAQ
Q: Isn't it better to just use the existing tools like lsof or netstat?
A: Only if you don't care about learning. The pre-built tool gives you an answer; the custom script gives you a map. The act of building creates mental models that no one-liner can provide.
Q: What's the practical implication for my daily workflow?
A: When you feel the urge to write a custom script, embrace it. It's a sign that you're ready to go deeper. The 10 minutes you spend writing that script will save you hours of confusion later, because you'll actually understand the system.
Q: Most developers argue for efficiency—isn't writing your own tool a waste of time?
A: It's a short-term waste for a long-term gain. The real efficiency isn't in the seconds saved by a pre-built command; it's in the weeks saved by not having to re-learn the same thing every time you debug. Writing your own tool is an investment in your own expertise.