At my first real software internship, the highlight of the summer was a 24-hour hackathon. My team and I sat in a conference room for way too many hours, hacking together a prototype. I barely remember the end goal. A chat something?
What I recall most was the feeling of trying one JavaScript library after another, failing to get basic tabs to work. I felt helpless!
Clearly I needed more JS experience and should’ve asked for help, but there’s a different point I want to emphasize: the shift from being a library user to being a library writer.
What is a library?
You’ll see different terms depending on the person, language, and ecosystem: library, package, crate, SDK. These all represent code which is already written in your language which you can pull in freely to your project. I prefer the term library because it’s timeless, and would make Andrew Carnegie proud (I hope!).
The size can vary anywhere from a small date/time utility to a massive framework like React. Each of these is a library and was written by someone with a keyboard like you and me.
The code itself typically lives on GitHub, but could be anywhere, and a built/packaged version of that code lives in an online package index. For JavaScript, this is NPM, in Python it’s PyPI, in Rust it’s crates.io.
It’d be easy to get lost in the licensing details or best practices, but others have covered this better and more deeply than I will.
I’m going to make the case for why you should write your own, and how it will transform your relationship with your code.
You’ll feel more confident in your stack.
The vague uncertainty and powerlessness I felt during the hackathon? I had no idea what I was doing.
Each JavaScript library I found on the internet, each example I stumbled through, all I could think was “I hope this one works.” I was at the whim of what was published, potentially incomplete, years prior.
After you’ve written even one library, your thinking shifts to: “I understand the general shape of what’s happening here.”
When you see an import, you’ll know roughly what that maps back to on the file system, and how they exposed that set of symbols (functions, classes, etc) publicly.
You don’t need to be able to regurgitate the pseudocode behind the scenes. Just knowing you can navigate their repo turns what used to be a black box into just another piece of code in your system, this time written by someone else.
Once the black box feeling dissolves, something interesting happens: you start forming opinions. You start noticing which libraries feel intuitive and which feel clunky. That’s discernment, and it naturally leads you to the next question: what makes a good interface in the first place?
Your discernment around other libraries will increase.
The conventional wisdom for picking a library is to check their GitHub stars (a popularity contest for nerds), version number (be wary of anything below 1.0!), and how recent its commits are. This is all valid, but I’d encourage you to go one step further: look at their examples and see if they match your mental model of the problem you are trying to solve. This forces you to think through what you need the library for in the first place. Sometimes you'll think “uhhhh this looks more complicated than I expected,” other times "ah perfect, they make this super easy."
A library is ultimately a contract: when you ask for X, it will do Y or give Z. A good one will do this with minimal friction.
When I pull up the docs for a new library, my first thought is about their interface. What functions and classes they expose, how they fit together. And to be honest, I often look for a bit of awe, a sense of “how did they do this?!” (I wrote about this in Rust’s Axum.)
I’m not saying every library you use needs to be fancy, elegant, or clever. But there’s a sense of “does this match what I was expecting it to do?” that’s always worth asking yourself.
The moment you can recognize a clean interface in someone else’s library, you’re ready to design your own.
You’ll learn to design interfaces.
You may recall when you wrote your first function and called it. Code reuse! Writing a library is exactly the same, just with harder interfaces and more pomp and circumstance.
Each time you think “this function could really use another parameter,” that’s interface work. Each time you realize a function printed an error rather than throwing or returning an error to the caller, that’s interface work.
Designing a usable interface is as much art as science. A good one will hide most of the details and expose a small surface area of knobs for the user at the right time. This will feel difficult and awkward at first, but with time you’ll get the hang of it.
Once you’ve designed your first library interface, you’ll start to notice places within your projects where a harder interface is more useful. The voice I often hear is “hmm this file shouldn’t need to know about this,” and it’s a sign my interface could be stronger.
At this point, the difference between “code I wrote and am now reusing” and “code someone else wrote and I’m now reusing” starts to go away.
It’s all just code, available for your next idea.
It’s empowering.
This is the real reason. Everything else about saving time and not reinventing the wheel is valid and probably what you should tell your manager.
There’s a deeper truth here. Early on in your career, you will use libraries to build applications. You may even have users, and hopefully your code is solving a problem for them.
When you write a library, your users are other engineers like yourself. If your goal is to build an app that changes the world, this isn’t the fastest path. But if you’re driven to feel like a real engineer, someone fully in control of their tools and their craft, this is the way.
Some people may say writing a library will take 10 pounds off and make people laugh harder at your jokes. I can’t speak to that, but it will give you something equally elusive: agency. The agency I was severely missing sitting in the conference room praying one of the libraries I found would finally work. No more fingers crossed that the next one will magically work. You get to be the person who writes the thing others depend on.
This post is about libraries, but this is also why I started From Scratch Code. This skill set we share, which is sometimes valued by the job market and sometimes not, is something no one can take away from you. Why not use it to add to the canon of code in the world?
Writing a library is the best first step to own your craft deeply. If you want to get started and aren’t sure how, I’d love to help.
Subscribe & Save [on nothing]
Want a software career that actually feels meaningful? I wrote a free 5-day email course on honing your craft, aligning your work with your values, and building for yourself. Or just not hating your job! Get it here.
Build [With Me]
I mentor software engineers to navigate technical challenges and career growth in a supportive, sometimes silly environment. If you’re interested, you can explore my mentorship programs.
Elsewhere [From Scratch]
I also write essays and fiction about neurodivergence, meaningful work, and building a life that fits. My novella Lake-Effect Coffee is a workplace satire about burnout, friendship, and a coffee van. Read the first chapter or grab the ebook.
Top comments (0)