Dependencies Are Someone Else's Code
What did you agree to when you ran the install command?
The idea
Every library you install becomes part of your system, including its bugs, its licence and whoever can publish updates to it.
In the real world
A small utility package changes ownership and a later release adds unexpected behaviour.
Going deeper
Installing a package adds more than its code. It adds that package's own dependencies, its release cadence, its licence terms, and trust in everyone who can publish under that name — a set of people you have not met and who can change.
The cost is ongoing rather than one-off. Every dependency is something to update, to audit when a vulnerability is announced, and to replace if it is abandoned. That is often a fair trade for real functionality. It is rarely a fair trade for something you could write in an afternoon, which is the calculation that gets skipped because installing is so much faster than writing.
Where it stops applying
Writing it yourself is not automatically safer. Hand-rolled cryptography, date handling and parsing are reliably worse than well-maintained libraries, and the effort is better spent on dependencies that carry real risk.
Why it matters
It makes adding a dependency a decision with ongoing cost rather than a free shortcut.
Try this today
Pick one dependency and check when it was last updated and how many people can publish it.
Test yourself
A project pulls in a package to save writing forty lines. What did the project take on that the forty lines would not have carried?
Show the answer
Everything beneath it: the package's own dependencies, its update cadence, its licence terms, and trust in whoever holds publishing rights. Forty lines you wrote have exactly one maintainer and no supply chain.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.