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.
How many technical articles have I read with solid React or JavaScript advice, but where every code snippet misuses <div> elements or ignores accessibility issues? On the one hand, for those coming to the article to solve a JavaScript problem, these issues aren't really a problem, but on the other how many devs will have scanned the article, copied the code, seen it work, and simply moved on. To be clear, I don't think that the problem there is with the article (unless it claims to be brilliant HTML or fully accessible, of course). I don't think we should penalise a great JS developer for sharing useful information in an incomplete way. In fact, to the contrary, I am an advocate for learning in the open, sharing your knowledge as it grows. No, the fault here is with the person that blindly copy-pastes the code, that doesn't dig deeper or try to consider how to improve it first.
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.
