I come from the days of yore, where BASIC was still used, 256MB of storage was like 2TB, and 64KB of ram was like 32GB. There's a quiet arrogance in the tech world today. You see it on social media profiles, in job titles, and echoing through open offices: "Software Engineer." But what does it mean to be a software engineer today, when most of the tools we rely on have already been built by someone else? When the libraries are just a package away, and frameworks do the heavy lifting for us, the label starts to feel a bit hollow.
Imagine this: the internet goes down, your package manager is acting up, or you're in a restricted environment. You need to write something as simple as a command-line interface or maybe even a basic web server. Suddenly, the comforting blanket of frameworks and libraries falls away, and you're left with just your wits, the language's raw capabilities, and your hardware knowledge. The feeling can be humbling, disorienting even. You start to understand what software engineering really is: not just using tools but knowing how they work, and how they interact with the hardware beneath.
To build without libraries or frameworks, you need to know more than syntax—you need to understand the why behind the code. You need to understand data structures, algorithms, and design principles. You need to see the bigger picture, to know what problems you're actually solving and how to solve them from first principles. It's like being a mechanic who doesn't just change parts but understands how every piece in the engine contributes to motion.
Take building a web server, for instance. With a framework like Flask or Express, it's a few lines of code to get a simple endpoint running. Without them, you have to dive into the fundamentals of HTTP, handle incoming byte streams, and manage sockets. The beauty here is that, once you do this, you realize why frameworks do what they do—why certain abstractions exist and how they save time. But this knowledge gives you something more valuable: it gives you choice. It gives you the ability to know when to use a framework and when not to, and how to fix things when they inevitably break.
The truth is, many people today are far more library users than they are software engineers. There is nothing wrong with this—libraries and frameworks are incredible tools that speed up development and allow us to focus on solving new problems rather than reinventing the wheel. But there is a difference between knowing how to use the tools and understanding how to craft them. There is value in rolling up your sleeves and learning to work without a crutch—not because you have to, but because the insight you gain will make you a stronger, more capable engineer.
Building without libraries or frameworks isn't a hypothetical exercise. It's the reality behind every new invention and optimization. It's how breakthroughs happen. The next time you find yourself thinking that all software engineering is just gluing APIs together, remember that there's a deeper level to this work. There's a world where you write the API, design the database engine, and implement the communication protocols—a world where "engineer" means understanding the full stack, not just relying on what’s already been stacked for you.
So, the next time you're feeling comfortable in your IDE, challenge yourself: build something with no imports, no dependencies, nothing but the core language. Implement your own sorting algorithm, build a simple UI with raw JavaScript, or write a CLI tool in pure Python. You might be surprised at how much you learn and how different it feels to call yourself a software engineer afterward.
Engineering starts where the libraries end.
Top comments (0)