Don't consume. Create. Ask questions. Stay curious.
Aleksandra has put into words a worry I've had for a long while: the idea that a large portion of the tech industry has become comfortable simply copying other people, relying on perceived status or authority to validate that pattern, but lacking any means of actually clarifying if that authority is relevant or accurate. In a world of social media thought leaders, it can be easy for one person's "wisdom" to become a best practice through clout and visibility alone. Compound that with a view where certain forms of engineering, or certain skillsets, are seen as more prestigious or more technical (and therefore more valuable) than other forms and you have a culture rife with misunderstandings that end up cross-contaminating code bases.
But I think the issue runs deeper than a simple over-reliance on faux-authority and Stack Overflow. I'd apply the same criticism to npm. How often is the first solution to a technical problem the addition of a new dependency? Yet whilst npm is an amazing, invaluable resource for knowledge sharing – and a huge time saver from a business perspective – I think we lose sight of what we're actually doing. For gigantic projects like Storybook or Jest, simply adding them as a dependency gives you a huge amount of additional functionality with very little risk. They have thousands of maintainers, they're constantly being updated, patched, and stress-tested. But for the little packages, the type libraries and the single-use functions – how rigorously vetted is the code you're using? How many possible security vulnerabilities are you adding? How much additional bloat to your client-side JS might it create? How accessible is the solution it produces? And – possibly most importantly – how much additional functionality is this providing that I don't actually need? Might that make our own codebase more irritating/hard to maintain in the future?
To my eye, the same arguments that Aleksandra has so carefully put together for why you should take technical information on personal websites, Medium, Twitter et al. with a pinch of salt can – and should – be applied to the use of third-party code from any source. Sure, it might solve your immediate problem today, but if you don't fully understand how it does so you can never be sure how many additional problems it might cause tomorrow. What's more, by relying on the gods of npm, you're missing an opportunity to develop your own understanding. As Aleksandra says:
Believe in yourself. Your solutions are not any worse than the ones on the internet.
In fact, in many ways, they are probably better.