|
|
|
|
|
|
by onion2k
1458 days ago
|
|
|
The problem with dev.to, and pretty much every blogging platform like it, is that it encourages the mindset that the articles about problems you have yourself are the best articles to learn from, and that things that aren't directly applicable to other people won't get promoted. That leads people to think they should write boring, generic things about language fundamentals in order to become 'famous'. People end up rewriting the language docs in their own words. How dull. The reality is that most interesting dev articles are about relatively unusual problems that a dev solved in an innovative way. You can learn a lot about dev work from those (approaching problems, thinking about things, some cornercase dev tools, algorithms, etc) even if you can't cut and paste code from them into your own project. This exposes a further problem though - you can't write those articles until you're sufficiently experienced to face those problems, and knowledgeable enough to solve them. If you're a new dev starting out with ambitions to be a 'thought leader' and wanting to get to the top fast, you're bound to end up writing another "Why Array.pop is the best array method ever!" article. |
|
|
It used to be that well-researched people and passionate people blogged about technical topics they knew very well, and when they blogged about unfamiliar topics they usually declared that upfront.
Nowadays there are an order of magnitude more grifters churning out a massive amount of blind-leading-the-blind garbage to "build a presence", and they usually pose as experts even though they barely know the topics. As an example, whenever I try to compare two similar technologies/libraries I'm not familiar with, I can almost always find one or more Medium or whatever articles on the topic, but 80+% of the time it's quite clear the author basically wrote the useless crap of an article after reading the READMEs, or slightly better, the bare minimum example projects.