Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The distinction you drew between getting something to work and understanding why it wasn’t working is the whole post, and it’s one of the most underrated ideas in development — because the terminal’s real value was never the typing speed or the memorized commands, it was that it stripped away the interface that had been doing your understanding for you. A GUI is a kindness that quietly keeps you ignorant: it handles the processes, permissions, and paths so smoothly you never learn they exist, until the day something breaks and you have no idea where to even look. The terminal just refuses to hide that layer, so you’re forced to actually see it — and “becoming a better investigator” is exactly the skill that outlasts every framework and tool. Great piece.
Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
Thank you, I really appreciated this. “The GUI is doing your understanding for you” is such a good way to put it. That was exactly the idea I was trying to get at.
The biggest benefit really has been becoming a better investigator, not just getting faster at typing commands. Thanks for reading!
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
That’s exactly it — and honestly “becoming a better investigator” is the kind of lesson that quietly outvalues almost everything else, because it’s not tied to any one tool. Commands change, frameworks come and go, but the instinct to stop and ask what’s actually happening instead of guessing transfers to every problem you’ll ever hit. You wrote the version of this I wish I’d read when I was starting out. Thanks for making it.
I help Python and backend engineers move beyond writing working code to designing production-ready systems, making architecture decisions, and growing into senior engineering roles.
The forgotten Vite server sitting on port 5173 is way too relatable 😂 And the sudo part hit home. Making a command work and knowing why it failed really are two different things, and I’ve definitely created a few root-owned files I regret. Great reminder that curiosity matters more than memorizing commands!
Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
Hahaha, that poor forgotten Vite server! I've definitely had my share of those. And yeah, sudo can be a little too tempting when you just want something to work. Then you get to learn a whole new lesson about permissions when you have to clean up the mess.
I think that's exactly why curiosity matters so much. Half the useful stuff I've learned has come from figuring out why something broke in the first place.
The port exercise has one extra step I'd try: write down what I expect the command to show before running it. If the browser works but the expected process is absent, I'd check whether I'm looking inside the right container or host before changing anything. That is the habit I'd bring to a prachub practice question too: make a prediction, inspect the evidence, then explain what changed my mind.
Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
Oh, I really the idea of writing down what you expect to see before running a command. I think it’s so easy to jump straight into trying to fix something without stopping to think about what we actually know versus what we’re assuming.
And the container example is a great one too. Sometimes the problem isn’t what you’re looking for, it’s where you’re looking. lol
Thanks for adding this! I think that little extra step could make these exercises even more useful for people who are learning.
Same lesson shows up in config files. A write-up on Codex CLI 0.162.1 found that since 0.134.0 profiles are separate files picked with --profile review, and a leftover profiles table without the profile line is silently ignored. No error, the old setting just does nothing, so you only find out by asking why.
The port-already-in-use example with Vite really resonated, since that is exactly the moment where knowing ss or lsof pays off instead of closing random windows. One small addition for anyone following along on macOS or Windows: ss is Linux-only, so lsof -i :5173 or netstat -ano on Windows gives the same answer. I also found it helpful to learn that Ctrl+C sends a signal to the process, because that explains why a dev server sometimes lingers when its parent terminal gets killed. Thanks for explaining the why behind commands instead of just listing them.
Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
Thank you! And I really appreciate you adding the macOS and Windows alternatives. It’s easy for me to forget that not everyone has the same tools available.
The Ctrl+C point is a great example too. It’s one of those things we do almost without thinking, but understanding what’s actually happening makes such a difference when something doesn’t behave the way we expect. That’s really what I was hoping to get across with this post. Thanks for adding to the discussion.
Software Developer & Creator focused on building Windows desktop applications, productivity tools, and useful software.
Creator of Task Monitor and FazaFix. Interested in C#, .NET, Windows Development
The distinction you drew between getting something to work and understanding why it wasn’t working is the whole post, and it’s one of the most underrated ideas in development — because the terminal’s real value was never the typing speed or the memorized commands, it was that it stripped away the interface that had been doing your understanding for you. A GUI is a kindness that quietly keeps you ignorant: it handles the processes, permissions, and paths so smoothly you never learn they exist, until the day something breaks and you have no idea where to even look. The terminal just refuses to hide that layer, so you’re forced to actually see it — and “becoming a better investigator” is exactly the skill that outlasts every framework and tool. Great piece.
Thank you, I really appreciated this. “The GUI is doing your understanding for you” is such a good way to put it. That was exactly the idea I was trying to get at.
The biggest benefit really has been becoming a better investigator, not just getting faster at typing commands. Thanks for reading!
That’s exactly it — and honestly “becoming a better investigator” is the kind of lesson that quietly outvalues almost everything else, because it’s not tied to any one tool. Commands change, frameworks come and go, but the instinct to stop and ask what’s actually happening instead of guessing transfers to every problem you’ll ever hit. You wrote the version of this I wish I’d read when I was starting out. Thanks for making it.
The forgotten Vite server sitting on port 5173 is way too relatable 😂 And the sudo part hit home. Making a command work and knowing why it failed really are two different things, and I’ve definitely created a few root-owned files I regret. Great reminder that curiosity matters more than memorizing commands!
Hahaha, that poor forgotten Vite server! I've definitely had my share of those. And yeah,
sudocan be a little too tempting when you just want something to work. Then you get to learn a whole new lesson about permissions when you have to clean up the mess.I think that's exactly why curiosity matters so much. Half the useful stuff I've learned has come from figuring out why something broke in the first place.
The port exercise has one extra step I'd try: write down what I expect the command to show before running it. If the browser works but the expected process is absent, I'd check whether I'm looking inside the right container or host before changing anything. That is the habit I'd bring to a prachub practice question too: make a prediction, inspect the evidence, then explain what changed my mind.
Oh, I really the idea of writing down what you expect to see before running a command. I think it’s so easy to jump straight into trying to fix something without stopping to think about what we actually know versus what we’re assuming.
And the container example is a great one too. Sometimes the problem isn’t what you’re looking for, it’s where you’re looking. lol
Thanks for adding this! I think that little extra step could make these exercises even more useful for people who are learning.
Same lesson shows up in config files. A write-up on Codex CLI 0.162.1 found that since 0.134.0 profiles are separate files picked with --profile review, and a leftover profiles table without the profile line is silently ignored. No error, the old setting just does nothing, so you only find out by asking why.
The port-already-in-use example with Vite really resonated, since that is exactly the moment where knowing ss or lsof pays off instead of closing random windows. One small addition for anyone following along on macOS or Windows: ss is Linux-only, so lsof -i :5173 or netstat -ano on Windows gives the same answer. I also found it helpful to learn that Ctrl+C sends a signal to the process, because that explains why a dev server sometimes lingers when its parent terminal gets killed. Thanks for explaining the why behind commands instead of just listing them.
Thank you! And I really appreciate you adding the macOS and Windows alternatives. It’s easy for me to forget that not everyone has the same tools available.
The Ctrl+C point is a great example too. It’s one of those things we do almost without thinking, but understanding what’s actually happening makes such a difference when something doesn’t behave the way we expect. That’s really what I was hoping to get across with this post. Thanks for adding to the discussion.
@sizzlebop
Now we need to get you into i3 and rice your setup. Trust me. :)
Hi James