42 ms·
In some respect being a software engineer today is really hard. OTOH you want to do the right thing, so you don't want to invent a solution yourself. So you loo
by mola 3y ago
In some respect being a software engineer today is really hard. OTOH you want to do the right thing, so you don't want to invent a solution yourself. So you look for available resources, you go online. There you're going to encounter either:
1. Spam from junior devs who started a blog so to build a name for themselves.
2. Spam from SEO mills peddling junior level wisdome so they can get ad money.
3. Spam from software vendors that try and convince your that X is the best solution for everything. (Looking at you Confluent)
4. SEO Spam by software consultencies mainly interested in hitting the relevant buzzwords so the suits will find their site.
5. Spam from FAANG employees showcasing their google scale solutions made to attract talent.
What is the engineer to do? Either cargo cult the FAANG engineers, you don't got their scale but atleast these are actual solutions. Or invent it yourself. Which maybe scary after you read all of these conflicting advices.
We really are drowning in spam. Thanks heavens we we employed humanities best to create LLMs so we can now automate this. /s
But seriously, seems like most useful information is siloed in the brains of battle worn engineers who are surrounded by an inflation of junior devs. I have a feeling this field grew too fast and we are losing a lot of wisdom and knowledge.
- packetlost 3y ago100% agree. All the best devs I know literally do not give a flying fuck about blogs at all (with a few exceptions). They read white papers and textbooks from 40 years ago (this is a bit of an exaggeration).
- OmarShehata 3y ago> Spam from junior devs who started a blog so to build a name for themselves. I often find this is the most useful category out of the 5 you listed. Junior devs writing something like "How to setup webpack" often explain things in plain words and just spell out how to get the thing working. There's humility to the post like "I don't know what all these options do, but this is what worked for me". I find that a lot more honest/useful than say category 5 there where I have no idea if what they're talking about will actually work for me or how much effort it's going to take to integrate because the assumption there is you have big teams who can spend all their time maintaining these tools.
- Dudester230602 3y ago> How to setup webpack Half the juniors are creating a problem ("modern" frameworks), the other half is trying to solve it.
- OmarShehata 3y agoI am completely baffled by this comment. You're saying the _juniors_ are creating overly complicated modern frameworks, or are the ones pushing it?? It's clearly the opposite in my opinion. Big companies/teams are releasing tools that may work well for their scale but are overkill for most, and they're championing them as good solutions for everybody, and juniors are the force working in the opposite direction (trying to simplify/untangle all this complexity, they don't have the experience to recognize if it's overkill. They also want to get hired at all the companies that use these tools so they have to learn it).
- wccrawford 3y agoWhile I do think that most of the useful pages either come from juniors or from someone promoting their own product, I think there are a ton of bad pages from juniors that have outright incorrect or dangerous information, too. So it can be hard to tell what advice to use and what not to if you're at a level that you're asking the question in the first place.
- mo_42 3y ago> But seriously, seems like most useful information is siloed in the brains of battle worn engineers who are surrounded by an inflation of junior devs. I have a feeling this field grew too fast and we are losing a lot of wisdom and knowledge. I think knowledge siloed in the brains of people working somewhere successfully is underrated. These people just don’t have time to write a blog or don’t need to due to their success. Maybe also because the topics that make them successful aren’t that consumable compared to $FAVORITE_NUMBER_STEPS to use this new and shiny framework.
- mike_hock 3y ago> you want to do the right thing, so you don't want to invent a solution yourself How is that the right thing? Over 90% of the time, the fastest, most maintainable, and simplest solution is to do it yourself. Yeah sure, there's a few horror stories out there of homegrown database engines that reinvent every wheel of RDBs the wrong way, have been unmaintained for 10 years and the original dev has left. But those are the exception. The things you shouldn't invent yourself, you can count on one hand. And they're obvious. The spam is only the first hurdle. You have to find a solution that doesn't suck. Evaluating whether it sucks would take at least 3x as long as writing it yourself, so you can only give it a cursory glance. There's a chance it sucks in non-obvious ways that you're gonna find out over time, most likely in production, through a slow trickle of WTFs over the months as you work around increasingly weirder bug. There's of course a chance it's good. But you're gonna have to take the risk. Then comes the maintenance phase. Of course it's gonna redesign its interface every month. Until it suddenly gets abandoned and starts to bitrot. Eventually it stops working when you upgrade something unrelated. Then you're not only back to square one but have to find a replacement fast because now you're relying on it. The stuff you wrote yourself 5 years ago, on the other hand, still works exactly like it did when you wrote it with minimal changes.
- ilyt 3y ago> Over 90% of the time, the fastest, most maintainable, and simplest solution is to do it yourself. That's almost never the case. You'd be near-always putting it together with ready made libs or services.
- mike_hock 3y agoYeah. Fundamental libraries at the right level of abstraction, most of which you're probably already familiar with. Those are the obvious things you shouldn't write yourself.
- yodsanklai 3y agoIn my team (big tech company), if there's some new problem to solve, you write a design doc, and validate it with your colleagues. If nobody gets a better idea than you, then you implement what you had in mind. We're not incentized to produce perfect designs, but hopefully something that works and is simple enough that you can implement it within a few months. It's pretty rare that we have to implement entire complex systems from scratch. We also have a lot of internal tools and specific problematics, so I rarely feel the need to look up for an existing solution.
- MaKey 3y agoI find it worthwhile to read a book from time to time (I mostly read books from O'Reilly and No Starch Press).
- thebigwinning 3y agoIt's actually an easy problem to avoid Buy a Knuth book or other core science/math text and read that instead.