Most tech content is bullshit
aleksandra.codes
aleksandra.codes
When I left O'Reilly Media in 2005 we were just ending a period where many programmers worked with a set of physical O'Reilly books on their shelf. And everyone at O'Reilly could see that their business was being eaten away by free. Stack Overflow didn't exist yet but we could feel it coming.
At the time, we hoped that UGC would have some sort of wisdom of the crowd thing that would lead to high quality. I remember this sort of was true in the PHP documentation. The official documentation was always deeply flawed, but the comment thread attached to that documentation generally had the right info.
But that was a precursor to our current situation. To get correct info you had to read a lot of conflicting info and synthesis it yourself.
So I think we are seeing as good as the free ecosystem can get and what's sad is that we seem to have lost the paid ecosystem. It's not nearly as strong as it used to be.
What people probably don't know about O'Reilly back in the day is what went into a book.
The author was almost always a subject matter expert already. And their editor was also a subject matter expert. Then the book would go through tech review and those people were generally also pedantic luminaries. Then the book would be published and bugs would come into an errata tracking system. The vast majority of those bugs would get fixed between printings.
And then, on top of all that, there was a tech support number. And if the code in the book wasn't working for you, then you could get a live person to try to work through it with you.
That all costs a lot of money, but when you split the cost out across consumers it was only $30 or so per book.
I value my time. And there are many, many places where I wish I could pay for quality. Tech content is one of them.
I'm a big fan of books because that is where a lot of experts seem to prefer to publish their knowledge, and it's usually worth the price. Of course that's not always the case, but I feel like I get much higher quality content from books than Medium articles.
Stack Overflow is great for quick reference to small questions.
The only ones I can say, that I’ve also read, are YDKJS and Secrets JavaScript Ninja (work in web, but willing to read anything, good information is good information regardless of the tech).
Effective Java by Joshua Bloch
Practical, actionable guidelines. The first edition was the best, the second was diluted somewhat by having to cover generics, in the third he admits that he doesn't really use Java much anymore... Despite that, it's well-written and still a good book.
The Linux Programming Interface by Michael Kerrisk
Covers some of the history of the Linux/Unix API, describes it in detail, has plenty of examples, compares different APIs that do similar things so you can make an informed choice (e.g. System V vs. POSIX message queues).
If any book in this list stands out for me, it's probably this one. It might be partly due to the surprise factor of how enjoyable and well-written a 1000+ page, near-reference book is.
Programming in Haskell by Graham Hutton
An intro to the language and how to approach problem solving from a functional P.O.V. Not as comprehensive as some other intros to Haskell, but Hutton is a good writer and educator, making it a good read.
Designing Data-Intensive Applications by Martin Kleppmann
Provides an overview of a number of topics related to databases, distributed systems, consensus, etc. Lots of references (many of them online) if you like that in a book. Enjoyable to read.
Parallel and Concurrent Programming in Haskell by Simon Marlow
Probably a must-read if you're into Haskell; probably too esoteric if you're not... Well written.
Type-Driven Development with Idris by Edwin Brady
Describes a programming language similar to Haskell, but strict by default and with dependent types designed-in from the start. Also describes techniques for leveraging the type system to construct functions (the type-driven part of the title). Well written.
Hacker's Delight by Henry S. Warren
Low-level bit twiddling. 'Nuff said.
What does he uses now?
Thanks for the rec!
I wrote two of the chapters in the SRE book but I have very mixed feelings about them. I'm glad that I got a chance to talk openly about some of the work I've been doing for the last decade, but I felt that, in the end, I couldn't devote to my chapters as much time as I would have liked, so I don't feel as proud about them as I would have liked. Boy, this really took soooo much time!
I don't know what I'm trying to say, I guess just that I find seeing someone praise the book interesting. What were your favorite chapters?
Despite that, I still recommend it to anybody new to DevOps/SRE/Cloud Engineering/whatever you call it, with a grain of salt that you don't operate at Google scale so you shouldn't implement it as is. Just reading the principles chapters helps a lot to talk the same language.
I've heard great things about it, definitely need to add it to my queue.
The SRE book is also interesting. There was a conference recently where one of the authors gave a talk [1] about training. Really encouraged me to at least get the PDF.
I had a Safari Books subscription for a little while, but I got rid of it. I can't remember the exact pricing, but IIRC it was around $250 / year for the cheap option that let me "borrow" 10 books a month. The problem for me was that I'd typically buy 2-3 books per year ($100-$150) and I owned more than 10 books total, so the subscription seemed like a bad deal by comparison. The "unlimited" (with limited downloads IIRC) was $500+ / year. That's a lot of books.
O'Reilly could have been the Spotify of tech books, but old school publishers were too scared to reassess their pricing. When the cost of distribution plummets, but results in a worse (ie: more expensive), product for your customers, it's not a shock to see those businesses struggle IMO, especially when the competition is free and "good enough".
If a publisher had insanely high quality articles on everything, behind a paywall, I'd subscribe to $15 a month pretty quickly.
Every hour saved would pay for itself many times over.
The problem is having a wide enough array of content that such a site becomes the single go to. O'Reilly had that catalog, but I think the tech world had gotten much more complicated since then.
But I’m unsure how impactful revenue wise for an author can make or how sustainable is it long term.
Most of the books I see on Unlimited are either older books (there are some good gems), books that are already freely found on the internet or books that are scrappily put together.
So maybe the economics would disincentivize authorship.
The "like spotify" was more in reference to pay once, get everything imaginable.
This also explains the difference between publishers and distributors, and the dissimilar risks they accept.
I'd suggest something more like Netflix as a model; they are primarily a distributor and only very rarely a publisher; their library has a selection of standard classics, recently(ish) popular content for which the original publisher has more incentive to license than sell direct, plus rotating items of interest to keep the catalog feeling fresh for ongoing customers.
(note that even so-called "Netflix Original" content is mostly produced by other companies).
It's been thought of, of course. The search history of "Netflix for e-books" is in practice a mixture of junkyards like Scribd and "what-if" questions on Quora. There's likely a causality dilemma with achieving the catalog scale necessary for success, mediated by the conservative strategies and revenue fears of existing publishers, all of whose investors/owners are entrenched incumbents that see their businesses as perpetuities (steady, low-margin cash printers) rather than growth ventures.
Basically, they won't do it, until they see it can be done.
Really, there's not much of a reason to have physical programming books anymore; it's just not practical, whatever the level of quality you get elsewhere. And you seem to have left out official documentation and stuff, which is getting really good imo.
The only reason for having a physical programming book is for totally timeless ideas, like algorithms and data structures textbooks, or introductory books to concepts like compilers.
So, if you’re only looking at a book along one dimension which is “getting the most recent fashion status” in a fast-changing industry, then paper books aren’t appealing. But that’s the saddest dimension to evaluate a book on.
For me it comes down to scale. The chances I find precisely what I'm looking for on stack overflow is much higher than even the best curated content of all kind, just because SO is much bigger.
I can't talk about book publishers like O'Really, and probably the market for books shrank. But I have several competitors that sell self published ebooks.
The plethora of free content you find online is not always a good thing for everyone. As the author of the article says, most tech content is bullshit. Most people don't care, but there are plenty of people that realize that and are willing to pay.
I’ve never been so productive as I was in those days. Good quality documentation and no distractions. A golden age that we didn’t even know we were in. The modern development paradigm is a dumpster fire in comparison. Thanks for the good work you did back then producing those materials.
Having been involved in publishing tech books, that is a beautiful way of describing tech reviewers.
I too miss the paid ecosystem. And not just in tech books. Music too. Paying someone for curation had definite value to me.
It may well be a bad habit, but I frequently don't learn new technologies through a concerted effort. Instead, there's just something I want to do, and I google it, and after doing that a bunch I eventually learn a lot.
And yes, books not being searchable is basically THE reason I never use programming books.
The problem is that "timely" bit.
A good book take 3-6 months to write, edit, review, and publish.
In that time we could have as many releases with the info in the book radically out of date.
Only solution is to go online, but that doesn't help the traditional write/edit/review cycle much.
Things change so fast, I don't see much option to Stack Overflow... Not really.
Nowadays anyone can publish a book on Amazon, digitally and get published. It's reflected a lot in their Kindle bookstore.
Sometimes, having a good barrier to entry, brings out the best and the most dedicated.
The only issue? They don't have actual experience to back this up. Because not only is most tech content bullshit, the small percentage that isn't BS may not apply to their situation. You may not be working on soft real time systems. You may not be working with big data. You may not be running a company.
I should know—I'm certainly guilty of assuming that because I read about software development, I'm a better software developer. When really there's a big big big difference between reading about development and actually practicing the craft. Especially if you've only been programming casually. There's a massive difference between writing code for fun and writing code that needs to be a value-add for the company.
Quiet, or at-arms-length, dismissal hurts self-confidence and reinforces this blogpost-driven defense mechanism.
They also often drive away any possibility of meaty conversation because everyone worth hearing from is drowning under a sea of underinformed responses written in a way that sounds like a convincing in-depth discussion to the even less informed passerbys.
I'm no sage, but it doesn't take a genius to see when Hacker News and /r/programming get swept away by a new silver bullet in software development. Then we all have to wait years before the enthusiastic youngsters are ready to hear a realistic conversation about the prima facie limitations of the new magic beans.
I try to take their opinions with a grain of salt and find my own balance of considerations/tradeoffs. A common sentiment between them that I agree with is that software is a lot of commercial software is often an order of magnitude too slow in important places and that object oriented programming is almost always taken far too far.
I also look up to a few senior programmers I work with who have in-the-same-ballpark values as them.
On a whole, I think reading and listening to them has made me a better developer than if I just fumbled around to draw my own opinions completely from scratch.
I think being that type of young dev is probably fine so long as you keep your dogmatism and humility in check, and ensure your mentors are a spread of different individuals.
I think that's better than other young devs not seeking out information to try and grow.
I have a fair amount of respect for game developers. However at the same time I feel they can make the assumption that all development should follow their practices. That everybody should be writing in C++/Zig/Jai/Rust, using data oriented programming and avoiding objects like the plague. That if other developers were just smart enough they'd make everything ridiculously fast and awesome. Not every game developer thinks this way, obviously, but there is a subset.
The problem with this line of thinking is that it assumes all developers have the same priorities. In actuality game development is an extremely rare area where there are close-to real time requirements. Not painting the screen every 1/24th of a second is a disaster in game dev. Meanwhile GitHub uses Rails in all of its object oriented, garbage collected, interpreted horror. And nobody cares!
I suspect if a troop of elite game developers were dropped into your average web development job, they'd spend an unreasonable amount of time optimizing perf, only to have their lunch eaten by someone who focused on user facing issues. Not that web development is hard or anything. It's just a different set of requirements.
Watching jblow et al is definitely great! But there might be a point where you're put on a team using OOP and asking them to refactor to DOP with bulk allocation because you gotta get that cache utilization will just earn you stares and no buy-in. Or you might be running a startup and realize that all the time you spent getting all requests under 100ms could have been spent writing features.
I believe a lot of people (myself included) don't realize they read a lot of blog posts and articles about a topic they are interested in, but have no time trying out, and feel they know something about the subject when most of these articles are copying each other to gain popularity.
There are very effective ways to get high quality recommendations, with minimal effort on your part. Want to get good medical advice? Find two highly regarded medical specialists and ask them independently for a diagnosis and treatment plan. Not two doctors next door. Not two doctors who published random blogs. Two doctors who are highly regarded by their peers and by the wider industry.
Want to get good financial advice? Do the same thing with financial advisors. Looking for good fitness advice? Do the same with fitness trainers or nutritionists. Looking for good software engineering advice? Do the same thing with developers.
Eventually the day will come when you have learnt and grown so much, that you are just as capable as the "highly regarded" experts. When that day comes, feel free to debate the merits of their arguments. But until then, don't try to be an expert at everything. Don't feel pressured to derive every single thing from first principles. That's just not scalable.
The number one characteristic that makes a developer great is their critical thinking ability. These developers don't blindly adopt tools and business processes based on popularity. They are always able to justify their decisions with strong arguments which convincingly explain why their chosen option is better than all the other possible options. This applies to every decision they make.
Writing software is more like chess than checkers - You need to consider every reasonable option many steps ahead.
IMO software development is a complex area - Following common industry patterns and best practices without thinking about whether or not they actually apply to your particular use case is almost always the wrong approach. There are nuances in essentially every single software project which would warrant deviating from industry norms in at least some ways.
To always follow best practices blindly without questioning them or adapting them to your use case is in itself a terrible practice.
Also, the problem with trusting experts in complex domains is that the line between an expert and snake oil salesman is incredibly blurry. Sometimes even moderately skilled insiders with domain expertise don't know how to tell apart an expert from a conman.
The software industry has grown extremely fast and now the situation is that there are a huge number of highly vocal novices who pose as experts and who are silencing the real experts.
Having worked in the blockchain space... I have seen seen the future and it looks nothing like you think. When a company has too many conmen. The most rewarded skill becomes conmanship.
I struggle to think of a single blockchain project which is not at least partly a scam. You can start at the top with Bitcoin.
Bitcoin handles 3 to 4 transactions per second max (this is tiny), consumes the electricity of Ireland but it's the most valuable blockchain. I get it, PoW is more decentralized. But is it worth the entire electricity of Ireland? No. Even Ethereum aren't deluding themselves about this; that's why they're moving to PoS. But even Ethereum is kind of scammy... How many times did they say that sharding would be ready soon? Seems like years ago now.
Lightning network is brittle and not practical. In real life, most financial transfers are unidirectional so you constantly have to re-open new channels after they become depleted. Also it locks up most of your funds. Also Lightning requires high availability - Without it, scammers can roll-back channels to an earlier state. Lightning is so complex that if something does go wrong, it will be extremely challenging to understand what went wrong.
And no, Bitcoin is not more valuable because it costs more money to run. If a car consumes more fuel than all other cars, that car is clearly less valuable than the others. If I can complete the same work twice as fast and same quality as someone else, then I should get paid twice as much. Economic value is rooted in efficiency, not in inefficiency. Technology which does basically the same thing but which does it more cheaply should be more valuable. Why are the top 2 projects both PoW?
I could go on about pretty much any cryptocurrency project from the top 100. Just because some project has been legitimized and is valuable, it doesn't mean that it's not a scam.
I don't think that's true. Lots of global warming sceptics point to some subset of experts who are themselves sceptics. Even subject matter experts have biases. If we ignored those, we'd probably still be unlikely to find many global warming sceptics who had done their own in-depth research. It seems to me that most people in this category (whether it's global warming scepticism, anti-vax, 5G death rays or something else) merely seek to confirm already held beliefs and end up rejecting the opinions of actual experts in favour of misinformation from the kinds of people the blog post is talking about.
Beyond that there are also people with deeper issues than just a disregard for subject matter experts. If you look to extremes (e.g. flat Earth believers), some won't change their mind even when they do the experiments themselves and find proof to the contrary.
Yes, this is exactly why you should:
1. Consult more than one expert, until you've found a clear majority. And then trust in that majority
2. Pick either a couple experts who are the most highly regarded in their field. Or use random sampling to pick a couple experts from among a pool of equally qualified experts
As you yourself pointed out, people who fall for fallacies often form their own judgement first, and then cherry-pick experts to lend more support to their argument. This is precisely the danger in telling lay people to trust in their own judgement.
Cherry-picking of experts is the opposite of expert-guided decision making, because the cherry-picking part is being driven by lay judgement, not expert recommendation. A truly expert-driven approach would rely either on the most highly regarded experts, or random sampling from a pool of equally qualified experts. This leaves minimal room for cherry-picking and confirmation bias.
Knowledge from experts should feed into "think critically and figure it out", rather than replacing either with the other.
Software has an added bonus of the "works or doesn't" test, so it's easier to (in)validate the results of that thinking than, say, something on the scale of a planet and decades.
This is true, but I think the new problem that our industry is facing now is "How much effort and how many resources are required to make this software work" - This leaves a lot of room for manipulation and people do exploit it in most companies (especially large corporations). These are many tech companies these days where it takes 20 developers to produce results which could in fact have been done by just 1 developer in the same amount of time. I'm not exaggerating the numbers here.
I think the problem lies in perverse corporate incentives (or rather, the absence of meaningful incentives) and the way in which it affects how people pick their battles. Most employees pick all the wrong battles for all the wrong reasons.
The more money a company has and the more solid their monopoly is, the more employees will be focused on internal politics rather than value production.
Goddamn but that's a good observation. Upvotes to you!
This is a tangent, but I'm currently in the situation where I really need to find these two doctors, after years of suffering from a rare (combination of) medical issues. I've been searching for a doctor who has experience with treating my (or similar) conditions, for decades now, and I just can't seem to find it. Meanwhile, my problems become more and more disturbing, with me being unable to work anymore in the near future.
So please, if you know how to find the "highly regarder medical specialists", please tell me. Especially if it would take "minimal effort", because I'm steadily losing strength and soon the minimal effort will be the most I can exert.
In your case I would ask doctors for doctors recommendations, and test alternatives - through recommendation only - outside of the common doctor. The former since doctors know other doctors, the latter due to most alternatives being non invasive, and with no side effects except the perpetual disappointment you've experienced so far.
The real kicker is it seems to be self-fulfilling. If experts are no longer trusted or respected, the market / margin for expertise shrinks. You get lots of self-proclaimed experts to fill in the gaps with less investment (lower margin == lower investment, clickbait), and then the individual is justified in thinking most expertise is crap... because it is now crap (advertiser supported business model).
Maybe we wake up some day and say "Holy shit, it's all just bullshit!" and then expertise can again attract an audience that's willing to pay for it.
Old books that are still read will continue to be relevant while the current NYT best seller is more likely to fall into obscurity.
> Looking for good software engineering advice? Do the same thing with developers.
Which brings us back to the OP:
> Most tech content is bullshit
So we've now come full circle. Hence I would point you to another post that came out recently that would be useful to understand what you wrote: https://nibblestew.blogspot.com/2020/04/your-statement-is-10...
50 years ago was the beginning of Unix sure but programmable computers were already 25 years old by then, and the concepts were even older.
Except that the "subject matter experts" have a horrible track record. Also, global warming proponents misrepresent the skepticism. Nobody is really questioning the warming of the earth. People are questioning how much man is responsible for it. After all, the "globe" has been warming for thousands of years before industrialization. There are "subject matter experts" who believe the warming is mostly a natural phenomenon. There are even fringe "subject matter experts" who believe the earth will cool. You aren't a cynic, you are just agenda driven.
> Want to get good medical advice? Find two highly regarded medical specialists and ask them independently for a diagnosis and treatment plan.
Where and which ones? The one's that say you don't need to wear masks or the one's that say you need to wear masks?
I won't bother with the rest. All you are saying is believe and trust authority. But the problem with that was a time when "experts" believed in global cooling, medical experts believed in blood letting, political experts believe in racism, financial experts believe in subprime loan derivatives, etc. Blindly believing authority also tends to cause a lot of problem. The problem with the "experts" in your list is that it has become so politicized and corporaticized that one has to be skeptical by default.
https://en.wikipedia.org/wiki/Brandolini%27s_law
https://news.ycombinator.com/item?id=23417790
The value of a healthy established pedagogy, curriculum, and canon is that these distribute the bullshit-sifting role and guard and promote the jems.
But seriously I hate working with non self critical developers because it’s exhausting trying to refute what they say. Although “asking questions” can help.
You can read an article, and figure out if it is crap for yourself.
But then you can check your work by reading the discussion around it (like HN comments). Look at the top (and bottom) comments. Match your thoughts against the opinions and comments of other critical thinkers.
A lot of critical thinking has already been done for you.
This doesn't always work, but a good comment/upvote/moderation system can be a surprising bullshit filter.
My comment does NOT apply to automated systems, or systems were money/seo/gaming have a payoff for someone. So please ignore this for facebook, for anything with sponsored results, for product reviews, or for wikipedia pages of wealthy or prominent individuals.
[0] https://blogs.oracle.com/javamagazine/book-review-archive
I remember times when we had slow internet and/or only subset of blogs we read from time to time. Most of development was done by reading books, specification of devices for writing drivers and so on.
Now, literally everyone is trying to do SEO and use lots of words in articles, kind of creating content, but in reality copying from someone else and modifying a little and trying to get lots back links. I remember when Quora had quality content, now everything is sales pitch. I feel like people are not trying to create quality content, they are trying to sell and to sell you need more back links.
Whenever I Google for something in hot new languages or frameworks, I have to sift through 10s of Medium articles from beginner developers who are trying to establish themselves as industry experts.
I don't want to read some junior developer's Medium post full of animated GIFs and a pseudo-tutorial that is really just entire source code files embedded as GitHub gists one file at a time. I just want to skip to the documentation and get to work.
Maybe I'm so used to it for programming queries, but I've gotten back into electronics and ham radio after a long time, and have always dreamed of owning a decent oscilloscope. Googling 'good digital hobbyist oscilloscope' just now was a frustrating waste of time. It's just pages and pages of regurgitated specs and affiliate links, no useful _actual_ reviews or anything...
Take this top 10 result. It's on Medium which is new and hip and nice so must be of high quality...
https://medium.com/@Amyperlman/best-buying-oscilloscope-for-...
Oh cool, hmm ok - what else does the author write about? "Things to consider before buying a camera for hunting" - "Drug Rehab for Married Couples" - <<Several>> Reviews for a particular line of vaccum cleaner, Baltimore Security Cameras and Interior Design in India. I mean sure they could genuinely have diverse interests and a chaotic and international personal life - but these articles are just keyword stuffing for another bunch of 'content' that will helpfully let you 'check the price on Amazon' for just about anything...
This and the fact that Google search is actually as dumb as a sackful of hammers.
Don't get me wrong, for the longest time Google's results were "good enough", but Google has no real concept of the quality of a result (they've tried and it worked for a while - e.g., PageRank). Still, fundamentally their algorithms aren't smart enough to figure out whether any given piece of content is intrinsically worthwhile.
That's really important in a world where most content is, regardless of Google's guidelines, primarily written for the benefit of GoogleBot, to harvest clicks or drive traffic.
Unfortunately Google has literally zero incentive to change this situation (because they're making an insane amount of money off the back of the status quo), so they won't[1].
Logically then, the time is ripe for a new search engine to disrupt but the problem - that of determining intrinsic worth - is really hard to solve, so as yet nobody has, and Google still reigns supreme as the most popular search engine.
[1] It is also possible that I'm being too harsh here: they might be trying to change it - perhaps because they're worried about eventually being disrupted - but, as noted in the following paragraph, the problem is REALLY hard.
Our current solution is to rely on magical black box algorithms to give us the diamonds, but it's been creaking for a while.
I'm not sure how to make this better: one person's turd is another person's diamond, and people trying to game the system will always be a problem.
2) Get a subset of blogs to follow and stick to it. If you want to search in specific sites google has "site:" operator, you can search on specific sites.
3) by following 1 and 2 you can easily stop visiting shitty blogs made only for SEO, when they won't see any traffic they will fold because they will see no one is caring about what they write.
I am in process of implementing that. Got some books from humble bundle in topic that I am interested in, so no browsing crap until I get through those.
I'm not saying everyone should be an expert, but I would want the whole spectrum of experience represented. Now I don't invest time in meetups any more.
Do you think it would be possible for us to have any transparency into how hard a web page has been 'advertised' and use that to inform our decision processes? I've no idea what that would even look like.
That's the real problem. There is a market for short-form clickbait crap. One can make a living writing that. There is not much of a market for long-form accurate technical material.
Marketing is fact mixed with coercion.
But this is about plagiarism.
The author of the article, in just under 800 words, is addressing the "copypasta" nature of a specific discipline: programming. I like the author's characterization of lazy or necessary plagiarism as "consumer" mentality. That's an interesting twist.
Was this not the 1970's American Auto Industry attempting to implement Japan's earliest implementation of lean manufacturing? Is the same to be said of any "ripoff" product that cheaply imitates the original: e.g., an off-brand version of an Eames Lounger, or cheaply made webcam off Amazon which is a faulty copy of a Logitech?
His observation is a reflection of complex constraints, and while I completely agree individuals should strive for a deep understanding and mastery of what they spend their lives doing, as it benefits us all directly or indirectly by making us conscious citizens (my opinion), I think this is a largely metaphysical reflection lacking contextual nuance rather than a call to action: we've all been in the shoes of his hypothetical individual committing the sin of programmer consumerism, and for good reason.
However, I do appreciate the clarity his transformation applies to a scenario we are all intimately engaged in.
[1] "We know they are idiots, the question is, 'What kind of idiots?'"
What’s the main problem with this in the tech community? We need a lot of credible content that is downright technical. It hurts our community if we let the modern condition permeate into this domain too much.
None come immediately to mind but I've definitely come across some before on the web. Basically they kind of go "here is my problem, here's what I tried first, that didn't quite work so I tried that, but then I learnt about super_mega_amazing_tech and I wrote my code like this and it seems to work."
I find those kind of things quite interesting to at least skim through if not read in full if it's well-written.
The people actually doing the work don’t have time to talk about it and the people spending all their time talking about it aren’t doing the work.
Of course there are exceptions but I’m extremely skeptical of a lot of stuff I read.
Also that the HN bubble will always make readers feel behind when in reality 90% of the industry hasn’t even begun to catch-up. I felt behind with K8S in 2016, for example, not realizing we were just seeing the wave form when I felt like it was cresting.
I think that's a really sad and cynical view. I assume you don't spend 16 hours a day writing code. I assume you have hobbies and other interests. For some people, educating others about their favorite topics is their hobby. Writing about their projects is their hobby.
Here are entire blogs by people who are "doing":
https://perspectives.mvdirona.com
https://www.allthingsdistributed.com
Those are just a few I can think of in one minute. If I went through my RSS feeds and bookmarks I could find more.
He gets paid to write, yes, but that doesn't mean he's not also an engineer. I've worked with him, he does quite a lot of heavy engineering and then writes about it. His writing is so good sometimes he gets paid for it.
But OP said that tech blogs aren't written by implementers, and that's not at all true.
Not usually. Usually the way it works is the person who wrote the code and developed the technology decides to write a blog post about it and then writes it. Then they pass it around to their peers and other leadership for comments and edits.
Then, at least at Netflix, the next step was usually to publish it yourself on the tech blog. Sometimes if it was a big new tech it might get reviewed by PR or legal but not often.
At the other tech companies I don't know what their process is after that.
But what I do know is that I know a lot of those authors personally and they are definitely implementers.
It doesn't matter if it's sad and cynical, it matters if it's true.
That there is a certain number of engineers who have a mix of talent and resources (=time), so that they can exercise software engineering and high quality technical writing?
They are an exception. Almost all the engineers I know (with one exception), who also have a regular life (roughly 40 hours engineering/week), have little time to dedicate to technical writing. As a consequence, it's not unreasonable to state that, in general and in practice, software engineering and (regular) technical writing are mutually exclusive.
It's a fascinating experience. How being a good writer and software engineer go hand in hand. If my library is not easy to understand, my book won't be succesful. I'm constantly going back to edit the library to make sure the book / related concepts can be grokked.
I feel this is a fairly general truism. Great software engineers are often technical writers. Both involve understanding what the 'reader' expects to see, needs to understand, and how the whole narrative/program fits together cohesively. I'd encourage anyone who wants to up their software engineering game to work on their writing skills first.
What I meant is that in real world, due to times constraints, they are. As a sibling poster commented, working as a hobby ends up being a work in itself, so doing both things ends up being, effectively, overtime.
And as a consequence, all the general considerations about overtime apply.
For some people, their hobby is technical writing.
Saying that they are mutually exclusive would be like saying that being an engineer and doing puzzles is mutually exclusive because they both require a lot of mental effort.
Or being an engineer and a musician are mutually exclusive. It's a silly thing to assume that technical writing is somehow different from any other hobby.
Not only this, but the most accurate business advice tends to be too boring to attract views and clicks anyway.
Link-sharing sites favor controversial opinions and stances that make the reader feel superior to their peers, so that's what the content producers deliver.
This is one of the most poisonous attitudes I have ever seen when it comes to tech content, and unfortunately it is really prevalent in the largest tech companies.
No wonder nearly all the documentation created by the tech giants is complete garbage and often out of date, with almost zero regard for people who actually read the documentation.
A natural consequence of documentation being a "good beginner task" in open source or being assigned to whoever cannot get out of it on the project team.
There are plenty talented, productive people also writing articles and giving talks. Hell, most of what I watch/read (not just skim) is content either from the main drivers of a given tech or people who are experts.
It isn’t that hard to differentiate.
I have a tendency to drop my nuggets of wisdom/analysis in chatrooms in Discord and Slack (and IRC prior) and let others adopt/evangelize them on their own if it makes sense for them to. I'm ok being in the background while my true value is appreciated by those who matter for my own career.
Paradoxically when NOT doing work I share less
Do you code 16 hours every day? Or do you do other things with your time in addition to coding? It's possible to spend your "free time" writing about coding instead of writing code. Humans can do both well if they choose to.
I can't really agree with this. I think it's worth noting that writing about something you have just learned is a really good way to solidify that knowledge, especially if you are able to get feedback from others. So a lot of people deliberately set aside the time to do it, even if it comes at the expense of greater levels of productivity.
How would you feel if I write a cookbook the first time my bread rolls didn't catch fire? ... to solicit feedback?
I think this depends on what you're learning and how you've learned how to learn. As a beginner, I don't have any business going right to the master to ask about how I can improve my skills, so that I can "level up" and get the best results right away. Then again, we Western folk like pills and magic solutions for everything. We want results now, now, now.
If you're a white belt, go chat with a yellow or orange belt. If you're a blue belt, go chat with the purple belt. You don't walk up to a black belt and ask about the best way to tie your belt. No, you go ask the other white belts who have been at it for a little longer than you have, the people who have a couple of stripes on their belt. These people are closer to where you are in the given moment. They were in your shoes not too long ago, so they can help translate your mistakes, and help make sense of what you're thinking, asking, or learning.
When you see a really great photograph that touches you in ways you cannot describe, you're not seeing the product of an expensive camera, or a filter, you're seeing the result of someone who has taken hundreds of thousands of really shitty photographs over the course of their lifetime. You're seeing the results of maybe decades of practice. If this person writes a tutorial about taking photographs, can you learn from it? Sure. But they're not going to make you a better photographer by osmosis, you've got to go take a lot of pictures and read the beginners tutorials along the way.
So yeah, if I've been burning my bread rolls for months, I'd love to know that one thing you did to not set the house on fire every time you put rolls in the oven.
I think it's useful to share my experience on this: there isn't a whole lot of content on it and I think people could benefit from it. It's also helpful for myself, because writing it down clearly means I understand it better too now.
My background here is that I've been programming in Go for over 4 years and have worked with the Go ast package before (though not the analysis framework). I'm hardly a renowned expert on it, but I'd like to think that I have enough background/experience to know what I'm doing and communicate that information others.
Then a more senior coworker came over to join the convo and mentioned a few similar words that were clearly jargon related to compilers etc. He spoke with such confidence that I didn't want to admit I didn't know about them, but figured I shouldn't be ashamed at not knowing stuff. I asked him what it meant and he said he didn't really know and wasn't entirely sure. ¯\_(ツ)_/¯
One person did a double-take, looked at me, and said, "You can understand those?" I knew exactly what he meant, and consoled him by saying "only about 2/3rds," at which point all of the tension drained out of his shoulders. I had communicated that yes, some of it is just bullshit not fit for consumption, and that he was not an idiot.
As a Feynman dilettante, if you can't have a human conversation about a subject (note: conversation, not 'curing cancer'/winning the Nobel) then you don't really know the subject. Or perhaps more generously: It doesn't matter if you know it because you can't pass that knowledge on. You are dead end as far as human progress is concerned.
I suspect Tech people feel this more than pure researchers, because we know that in a couple years we will be focusing on something else, and 5 years at most we will be gone. If we haven't passed on our knowledge, then there will be consequences that are readily apparent. In academia you get so many opportunities to connect and if you connect with 5 people, you probably feel like your work is done, and you forget about people like me who regret ever encountering certain teachers because they set me back or in one case, put me off a course I believed I would stay to the end.
Me, I have 10-15 people not of my choosing and I have to connect with 2 and 1/2 of them. It's a tempest in a teapot.
Most people are playing fake it till you make it most of the time (until shit hits the fan, then incompetence becomes dangerous and you get to see who's been swimming naked)
Was your role or the senior person's role related to compilers? You don't have to authoritatively know something to talk about it, and I never assume anyone knows anything authoritatively if they talk about it nonchalantly.
So true.
I think this is just personality trait of people who are over-confident. I started out profesionally at roughly the same time as another dev in a non tech company. Pretty much the only devs in the company.
Technically, I was more skilled and had more engineering mindset. Both of us were savvy on biz side.
However, I was more reserved and less cowboy solutions than him. He was a nice guy and a friend but the difference in personalities were stark when it came to technical things. (This was a mature, real business who previously had outsourced the only dev system they used(ERP)).
He jumped so quickly from doing technical to just talking technical and his career climbed. All the while, I'm wondering how the heck can he take that position when he doesn't know shit about the tech. Turns out if you drift towards management, nobody gives a shit if what you're talking about is a good idea or feasible - the people above you in non-tech companies generally know less than shit.
Now an engineering manager at Bezos company.
When an developer lacks some productivity, political, or teamwork skill, they sometimes simply don’t know that they are missing that skill (or they think it is a worthless skill), and can’t understand why someone else gets promoted over them.
In this case, you could ask the other dev, because if he has a skill that you are lacking, he should be able to recognise your lack of that skill. This sounds a bit Dunning-Kruger but it usually isn’t. The issue is more about deliberate blindness (e.g. considering technical skills are king and politics as valueless), and usually a wilful disdain for recognising the hidden skills of others (“how did that idiot get that promotion” - maybe that idiot has some skill you struggle to recognise?)
If you think you might have engineers blindness, and are in a big enough organisation then:
1. try to look at “successful” idiot/wanker/useless engineers and see what things they are good at. Try to look at those you might disdain (sales/marketing/exec) and try to see where their value comes from. If someone can get their mind to be non-judgemental about others and be interested in the unobvious skills of others, they learn a lot (in my experience).
2. Look at what holds back other engineers, and look within yourself to see if you have any similar pattern.
Disclaimer: I would definitely call myself an engineer type. The above took me decades for me to recognise, and I still can’t do politics (but I now recognise the value, and I am learning to see when someone is good at it). And it is quite possible none of this applies to you: I am likely to be misreading you completely.
edit: this was ~10 years ago at this stage. I've stayed hands-on technical by choice(in various roles) while the other jumped to "pseudo-leadership (incl. Thought Leadership©").
edit edit: By no means was he an idiot. Just cavalier.
It is about maintaining an open mind. How can you tell the difference between someone who has valuable 3_048 metre advice versus someone who has highly negative value at 3km?
I have remained in a developers rôle for my working life so far.
I wish I could find the anecdote where this guy recognised that this one woman was always on successful projects within a business. He didn’t know what she did, but he recognised that if she was involved then somehow the project was successful (I think surprising him because many software projects fail). I wonder why he didn’t ask her what her secret was? At least he was open minded enough to see she had some magic, even if he couldn’t directly learn her presumed skill.
Thanks for reply - I’m still working on my own blindnesses - I can say trying to be non-judgemental and looking for hidden skills in others has really helped me.
> I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: “I don’t quite see what she adds to a project; she’s not a great developer or tester or much of anything.” With a little investi- gation, I turned up this intriguing fact: During her 12 years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn’t obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talk- ing to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn’t recognize the role of catalyst as essential to a project.
---------
I don't think engineers blindness is the cause in the majority of cases, and that woman would be put on a PIP.
To get ahead things like unethical behavior, lying and corruption matter far more than competence, teamwork and making real contributions. A lot of people simply can't stand to admit this.
You should really understand the problem you're trying to solve. Once you understand the problem, evaluating a solution is not so hard.
And implementing a solution without understanding it is negligence that will bite you in prod sooner or later.
There are entire channels devoted to making YouTube videos that show you how to solve a very specific error message for a certain combination of Framework X and Library Y.
This content is obviously great for SEO but the people making it often record it 30 seconds after finding the solution themselves and because it's video it can't be maintained, it just rots.
Often I'll get to work in the morning and see 5 new GitHub issues where people are making the same hyper-specific mistake. Why? They are all misled by the same new blog post or video.
That said, I love how passionate developers are about teaching each other. No other industry shares knowledge as rapidly, excitedly, and broadly as we do. Even if there's a lot of bullshit, I find the whole scene very energizing.
If blind acquiescence to random blogs and forums is a sin, then so is blind acquiescence to one's own limited experience. Most categories of software problems have already been solved. Being a "creator," in the truest sense of the word, is therefore rare. Most of the time, when we endeavor to "create" instead of "consume," we are just reinventing the wheel. That's often a good use of time, but it can also lead to bad code.
Instead of abandoning "consumerism," I try to challenge others to refer to prior art. It is only by filtering through books, documentation, and yes, random tech blogs, that we can get a sense of how much of what we're doing truly needs to be "created."
As a result, nowadays, most blog posts are written by people who are seeking a job in that area, not by people who have experience working in that area.
I mean I'm sure that I would have experience about different topics. But I rarely have the time to write about it. Customers and their projects keep getting in the way.
So if someone has time to write one 2000 word blog post every 2 days, ask yourself: Why does that person have so much time for writing? Aren't they working?
Also, if the internet is 95% articles by job seekers, then I'm better off distrusting everyone instead of expanding the trust that only 5% deserve to the other 95%.
I guess if better off means not finding anything good but no crap either, instead of only finding some good and lots of crap.
If seeking validation is the prime motivation to contribute to a discussion, at the very least I think HN is the least guilty of this amongst most forums.
In programming, at least the code needs to work. Maybe it is a bad pattern or anything - but the barrier of entry is non-trivial. For anything else (e.g. politics), a lot of people have opinions, with their strength being not much correlated with their knowledge of the subject.
Looking back, it seems Feburary/March/April covid-19 experts' expertise had the same (or worse) predictive power as random programmers on HN.
Please tell me you did this on purpose.
https://www.nytimes.com/2000/02/03/technology/suddenly-every...
https://web.archive.org/web/20181018000000/https://www.nytim...
There was also a strong politics subreddit full of group-think but that wasn't what most people went there for I'd say. It was one of three subreddits if i recall.
The site definitely changed when users could create their own subreddits as that opened the board to just about every kind of person or group on the internet.
I believe sites would do best to specialize even at the cost of growth. I'm happy when hackernews sticks mostly to tech and doesn't silo us into specialized and moderated subreddits.
We're also all driven to correct the things we see that aren't quite right.
This comment has been a little of column A and a little of column B.
So less about being validated for our experience, more about trying to avoid being dragged into court/relied on for evidence in a future court case.
No, in all seriousness I think this is one true factor. But I feel like this isn’t a bad thing on its own. The issue arises when authors don’t disclose their knowledge or competence. Saying stuff like: this is what I assume, this us what I don’t know etc. or just posing plain questions.
There's another dimension to this too, which is that writing blog posts and coming off as knowledgeable can directly translate into career opportunities. As long as you aren't too wrong, there's a material incentive to putting stuff out there.
I think IANAL is a popular term on HN because HN originated in a country with a terribly litigious culture, and because HN is primarily populated by people who can at least afford lawyers.
If I'd "talk to a lawyer" as often as HN comments recommend people do then I'd have no money (or time) left to eat. The whole thing is about covering your ass.
I suppose that is validation in a way, but not to feed my ego.
In some places, throwing out opinions to stimulate discussion is perfectly reasonable. In others, it's simply noise and misinformation.
This is a feature; not a bug given the way our quasi-free-market founded on protection of trade secrets over actual marketwide innovation that lifts everyone else.
I try guiding anyone who'll listen how to do things I'm well versed in; but there is only so much one can do in a day.
However, I will expand on a specific pattern of bullshit that is common in the tech world: over-complication for the sake of some sort of "theoretical purity". I think Redux is a good example of this. I think Redux can be used well, but it became the "recommended way to do global state in React" and IMO way many more code bases have become an incomprehensible nightmare because of Redux than have been helped by it.
Similarly, and I'm probably dating myself, but anyone remember the original Enterprise Java Bean specs, and the laughably bad "Pet Store" demo app from the early 00s? It was as if you took a collection of "architects" with no real world experience, and certainly no regard for performance, and had them create the most elaborate Rube Goldberg machine possible.
We specifically have info in our docs on when it actually makes sense to use Redux [2] [3], but that doesn't change the flood of Medium blog posts out there.
I created the Redux Style Guide docs page [4] to try to give some clarification on our actual current recommended patterns and usage practices, and our Redux Toolkit package to simplify common Redux use cases [5]. Unfortunately, there's only so much we can do - a lot of people never even look at the actual docs.
[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[2] https://redux.js.org/introduction/getting-started#should-you...
[3] https://redux.js.org/faq/general#when-should-i-use-redux
Some of the reasons she mentioned are legitimate (meaning, they are good reasons to follow random blog posts and stack overflow answers), like having no time, or it is comfortable. Some are not exactly good reasons, but happens often since we are humans (we are lazy, we don’t believe in our selves).
I also would like to add one more legitimate reason: it is not that important. Like it is an edge case, a temporary code, a piece of software where the highest performance isn’t necessary.
I think it is important to maintain an attitude of always having a critical mind while reading tech content. And understanding her point that something being published does not mean that something is right. But, once that’s your default attitude, it is ok to accept that, sometimes, you can critically conclude that it’s ok to just follow that tutorial and copy that code without much thought.
If that is challenged in the future, it is also ok to answer that you did just because you copied someone on the internet. As along as you accept that this is not a strong reason, and recognize that it might have been a misjudgment on your part.
I thought that I knew it all pretty well, but I found plenty of places that I needed to recalibrate, as I reviewed my materials.
I am now a great deal more confident in my grasp of the technology; thanks to my class.
I do a lot of writing, cast as a "teaching" exercise; even though no one cares. Doing this helps me to understand the material much more comprehensively.
When I teach, I then have a Responsibility. It is even more important to know the material than if I am developing a shipping application.
Speaking of "shipping"...
I write every line of code as "ship quality" code; even if I never have any intentions of shipping it (like test harnesses). That also helps me to make sure that I know what I'm doing. I heavily document my code, because explaining the code is like a built-in "self-peer-review." It helps me to see the code through fresh eyes.
I also write about my personal processes and approach to engineering, as that helps me to focus and make sure that I am speaking from a position of knowledge and experience.
I don't claim expertise I don't have, but I am constantly trying stuff I don't know how to do (I write about that here: https://medium.com/chrismarshallny/thats-not-what-ships-are-...). That's how I learn new stuff.
"The most erroneous stories are those we think we know best -and therefore never scrutinize or question." -Stephen Jay Gould
Vast majority of my blogposts that have reached HN front page were ... inflamatory and controversial. The (IMO) wise content that isn't steering up the argument seems rather ignored.
... or it was about Rust. I love Rust, I really do, but I feel some of the things I wrote weren't really thaaaat worthwile, and it's just jumping on Rust bandwagon. SWE is mostly driven by fashion and trends, and not by merits.
I have a lot that I wish to share, but don't have to write it down in well-structured way.
The more you know, the more you realize the that right answer to everything is "it depends". And it's really hard to turn subtle context-dependent knowledge to something more universal that benefits broader reader. It's good to seek after most knowledgeable and skilled people you can find at your job and pick their minds whenever possible asking about opinions, experiences, and so on. The context is already there.
And in SWE as in anything complex it's just hard to verify any theory. Nothing is reproducible, really comparable. What worked for me don't have to work for you, and we don't even know why. Everyone, even if well informed and experienced, has just a fraction of the picture and is trying to deduce the whole as best as they can.
Then there's a whole thing that ... people in SWE aren't as smart and knowledgeable as they often think they are. Being Senior Software Engineer doesn't mean anything anymore. Oh, you did two bigger projects, and you think you know a lot, hmm? Even after a lifetime of practicing the craft, keeping up with the tech, languages, tools ... there's still so much to learn. And a big part of SWE is not the tech itself but psychology, management, business, social skills... .
My advice for people that are looking for great content ... "you have to dig through a lot of dirt to find a couple of gold nuggets", and "weird&niche" is efficient way to get familiar with new stuff: You're not going to learn a lot of if you only travel the mainstream paths. Learn Haskell, Forth, Lisp, write some side-projects using some really weird and niche tech just to get familiar with it and gain some new perspectives. You'll talk with people who have some interesting opinions and learn things that will be surprisingly useful even on the mainstream path.
On the other hand reading something explained in OCaml, Scheme, Erlang, Julia, D or similar niche and not hyped language can be of very high quality. C also tends to be good. Interestingly, C++ is also slowly becoming a niche high-quality language recently.
The nature of niche languages is people who like them run to the next niche when the next niche springs from the aether. And when their blogs and youtube channnels die, so will they wither on the vine.
There has always been higher quality documentation for Python things than most languages, because as a community, Python encourages quality documentation by providing tools to help developers write it more efficiently. There are quite literally entire platforms that teach a complete beginner who has never written a line of code how to write javascript, for free.
There's a difference in having good documentation, and someone reading the documentation to you. Sounds like you're equating the latter with the former.
You realize C++ has been around since 1979, right?
Sorry, I just don't agree with this. Of course you need to vet the solutions you find online, but chances are you will find solutions that have already worked through bugs and edge cases you would only learn the hard way if you went forward naively.
I have seen new libraries becoming popular not because they solved their target problem better in a measurable way than the existing ones, but because they used [insert fancy tech that is hype right now].
I have seen articles reposted in tech newsletters that were completely bullshit. The last one was about manually cleaning up some weak references because that would magically help performances, without any data to back that up.
Performances in general is HARD. There are very few general truths that hold true and many rules of thumb that change rapidly as mobile platforms evolve. Most of the performance optimizations I used to make 5 years ago just don't matter anymore. Measuring the bottlenecks is not that hard but still very rarely made, even in performance articles.
On one side there are blogs that just post content to keep momentum, say csstricks.com, and don’t care to fix their errors even after you report them.
On the other side there are absolute noobs that post unresearched content just because some VIP tweeted that you don’t need to be an expert to blog.
Well, that’s what you get: Bullshit everywhere.
Then of course you get awful StackOverflow “top” solutions that are straight up “worst practice”
This needs to be clarified. If taken literally then people will never improve and Joe average will continue to post bullshit on the internet.
Most solutions are probably comparable to much of what is on the internet, but that doesnt make it ok. We need to filter what we see on the internet. If you learn a new concept that's good, and maybe it's what you need. The key is to keep trying to do better while looking out for fads.
I've seen a lot of change over the years regarding big new paradigms. Some I tried, some I tried and passed on (Java) only to see them fade. Maybe I'm ready to start a blog ;-)
This advice seems weird to me. I've been a professional software developer for a decade, and probably 95% of the time it doesn't matter if you're doing things in the most ideal way. The important thing is that it works, is reasonably performant, and is reasonably maintainable. If you can get that in 20 minutes from stealing somebody else's solution, it's probably better in the long run than spending 4 hours figuring out a slightly better solution. Maybe the hard part is identifying the 5% of the time when it does matter that you do something the most ideal way?
There must be a limit to this nonsense. So we’re just going to drop this into our stack because that’s what everyone else is doing?
It's why we're not all writing our stuff in Lisp. ;-)
Fuck everything about that.
My friend from middle school, Mike 'the douche' W. is now the MAYOR OF A FUCKING CITY. Just no.
BECOME an authority on a given subject (takes a little longer, is much more valuable long term.) This also means you have to pick your battles... life is only so long, pick your shit and get good at it.
All that being said, community knowledge is a GOOD thing. We don't exist in an isolated state, the tech. community in particular. There's no one person who knows how all this shit works anymore, so thoroughly documenting what we do know, and sharing it globally is also incredibly valuable in a communal sense. None of us makes this stuff happen, whether you like it or not, we're all working as a team.
Oh, and also, passing on some wisdom here... never trust a contractor with clean boots.
Unfortunately, as I discovered better ways of doing things, I still didn't start blogging about them. I probably should.
It's unfortunate that to have any sort of success as a software developer you must write about your opinion on frameworks, languages and techniques even if you know little about what you're talking about. Many developers and engineers blog because that's just what you do, not because they have anything important to say.
That makes the action prestigious in itself.
Maybe all blogs should say this lol
If everything on the web were to be bespoke items, built from scratch, things would stop up. Simply too resource consuming.
For many, the process is to simply copy something that works, and use it until it breaks - and then look at the needed upgrades / reasons to why things failed.
I have also worked with several people whose skill was sounding clever. One liked to read MSDN magazine, and then regurgitate the talking points to the CEO and CTO, who liked to trot him out in front of potential investors and customers. The content was just advertising Microsoft products utterly inappropriate for our startup, and eventually the company died after failing to deliver feature after feature because of vast over-engineering.
There are communication skills and then there are programming skills. Being good at either one is rare. So statistically if you meet someone who is good at talking or writing about coding then, absent any other evidence, that actually tells you nothing about whether or not they can code. Script kiddies are still alive and well, and some of them are Blog Kiddies now.
Yet, though it is a small intersection, it is not empty.
An old friend of mine has a tendency to dig deep through searches and while I tend to fire a few searches and then start doing it myself. There have been many examples when he came up with something he found online, which was even better than the thing I started building.
So while it contributes to my programming skills to get some practice, I think you have to find the optimum between building mediocre results yourself (using your own amount of limited time) and not being afraid to get your hands dirty (as opposed to the 'someone else has built it' attitude). In the end, both skills reinforce each other: The better you are at programming, the better you can judge a solution you find online, and the better you are at searching, the faster you can find something that is actually good.
Way to often I heard "Google uses Hadoop, so you need to use it to" for companies with data good for an old laptop.
Now I hear a bit of "appeal to authority" when it comes to monorepos.
For possibly the least bullshit content you'll ever read, I defer to HN user RobertoG's comment from ~2 months ago: https://news.ycombinator.com/item?id=22792243
This blog post shoots itself in the foot with its conclusions:
> Realize that there's tons of misconception in the world. People and their solutions aren't flawless.
Therefore, any solution you come up with yourself is likely to be flawed and full of misconceptions. Might as well use someone else's code / misconceptions / flaws.
> Adapt solutions to your particular use case. <snip> Always analyze it before you decide to use it.
Who has time for that? We're all too busy being distracted by contentless-content. Or you could just say something like: it seemed appropriate at the time.
> Believe in yourself. Your solutions are not any worse than the ones on the internet.
This is the real kicker. My solutions probably aren't any better either. On the whole half of all people engaged in a profession or job-role are below average. You'd probably do just as well to outsource all of your decisions to either someone else or the crowd.
> Being a developer is about constant learning.
That's very idealistic. Maybe some / many people just want to go to work, do the minimum possible, and get home, and for a lot of people that's probably okay.
> People sometimes use libraries without a more profound understanding.
Correct me if I'm wrong here, but isn't at least part of the reason for using libraries that they abstract away the need to have a profound understanding of the topic?
If your documentation sucks, your thing sucks. And as time goes on whether you like it or not, the collective record of community supporting itself IS part of the documentation.
What happens when Google or Microsoft buys Stackoverflow and drives everyone away from it, and it eventually goes dark? What happens when all of those blogs start to disappear as people move on to the next thing (Ruby/Rails...), what happens when google just wakes up one morning and declares that they're tired of groups and are going to delete them all like they've done with a dozen other failed projects?
I don't always go on a blog post searching for THE truth. I go to get someone's view on something. Maybe get excited by the journey or what was achieved. Learn about the use case. And somehow, in some cases, because they are less biases junior developers that write actually have interesting insights.
If I want the dry and no BS info, I'll go read the source, or the doc. If I go on a blog post to read about X, Y or Z, I don't just swallow it and take it at face value, I just hope to find something that will interest me to learn more about it.
And yet, I agree that a lot of what I see lately is marketed to no end, and it becomes harder and harder to separate actual value, from tooling marketing.
The words of George Carlin ring in my ears:
> Bullshit is everywhere. Bullshit is rampant. Parents are full of shit, teachers are full of shit, clergymen are full of shit, law enforcement people are full of shit. > The entire country is completely full of shit
A bit hard to get around the whole thing when up to senior engineers seems to enjoy this type of content.
And thats why I am enjoying HN and more unfiltered channels like /g/. You can have a somewhat anonymous review/judgement/comment on topics which you would never came across on these blog posts.
Engineering is not only about hard science, but also about processes. The way processes evolve is often based on empirical data rather than hard science.
Now, that does not mean that one can just forget about science entirely. As engineers, we should try to use a logical, rational, data-oriented mindset when making decisions.
If the reason a decision takes place is only because an authority said so, with no real reasoning behind, that would dogmatism: strongly held beliefs that will not be rationally discussed.
We should always keep an open mind and understand that a large part of our knowledge is simply a local maxima in our way to a deeper and better understanding of things, and dogmatism puts a stop to that process.
I've pulled whatever hair out that I have on a Friday night trying to figure out something with a solution or approach unpublished elsewhere when I could be watching Doctor Who or getting fat on fat free ice cream and sedentary on my couch instead. Sometimes spending that personal time experimenting pays dividends in the form of a working solution. Other times it builds grit.
The reality is most tech content is written by people with relatively little experience. People with lots of experience tend to have way more on their plates to bother writing blog posts or (tech) books.
Also the market is stacked against content for advanced users. Whether you are for ad impressions, visitors, likes, subscribes, book sales, you want to produce content that sells to masses of people and making it advanced is definitely going to cut your readership.
There is still a lot of value browsing through it. The reason is that since finding good information is difficult, the nuggets of wisdom make up for the lost time reading cruft.
I'd probably share a lot more, but it's not about not having time to share, as much as not having the time to bring the quality up to a level I'm willing to attach my name to. I suspect many are in the same boat.
I like your suggestion to motivate people to start thinking about what they are going to use and why.
When we have team refinements at work we learned to question everything. There are some senior developers that get most things right, but not every time. Sometimes some junior dev just throws an idea that turns out to be way better.
This is why I think the process of coming up with a solution is much more important than the solution itself.
With that being said - please remember that there is a fine line between valuable skepticism and just being annoying :)
I often check documentation of even well-known functions like printf() to remind me of details that I might have forgotten or remember inaccurately.
My takeaway is the same as the author's — rational approach is king, things should not be taken for granted and "best practices" might be good ideas, or they might just be the current fashion du jour.
Think for yourself.
I think this point is well made. It is a good caution when consuming content on the internet to always be assessing. I seek to understand how something works before I use it.
Yet here's my question: Does this mean I should not be writing for my personal blog?
Writing helps me work out, articulate and understand better the tech that I am working with. And it might help others to work it out as well, even if it's not perfect.
Thus I want to voice my contrary opinion that it is okay to "consume" and not "create" for non-core parts of your project. Need to do dump an arcane data structure to a remote logging tool? Go ahead and copy paste that StackExchange snippet kings!
Also, IT is fashion-driven and largely ahistorical. I have worked with people who don't know who Alan Kay is, for example, or have never heard of Prolog.
I think we are in an alchemical phase and (hopefully) transitioning to a chemical phase of knowledge. (Alchemy was mostly bullshit too, but there was a hellofa bull in there, eh?)
Just crazy that I would spend hours working on it to get it to work, I was always weirded out by it. This guy was sort of famous. Smaller bits of code were always fine and he had some pretty cogent insights on things, but big bits of code was just not working without significant rewrites.
To be fair perhaps this was a different time and things not working reliably was more widespread, I reemmber this article I wrote for SitePoint in 2008 https://www.sitepoint.com/rewrite-web-chickenfoot/ (please excuse me if too much bullshit, but I was less old) got a remark from the editor that testing took longer than normal, which I was of course surprised by because such is the time-honored reaction of a programmer when the code works on their own machine.
If it were, then none of this would exist.
But that there are some many tech companies taking so many different approaches (the majority bullshit) stands as evidence that there must be some acceptable amount of bullshit an organization can handle.
Textbook code is nice, but shipping and improving product is nicer.
The "most popular" (and maybe click-bait like) the content, the more crap you'll get. Especially when people think they know the subject but they don't.
Most common offender nowadays: ML and Data Science. I've found articles with glaring errors, techniques that don't make sense, very shallow tutorials, etc (Disclaimer: nobody is immune from making mistakes, not even me)
And then you get "oh but you start training and then your loss go to zero, right?! This means it works, right?" Yeah. No.
If your training loss goes to zero, your are probably overfitting or the problem you're trying to solve is too simple. If your testing loss goes to zero, you're probably doing something wrong. Or my favourite: your loss is very low but what you're trying to predict has result A 99% of the time and result B 1% of the time. What's your loss if you only predict result A?
I mean, if even the myths about /dev/random and /dev/urandom keep circulating around, can you imagine about other stuff?
It’s human nature to focus on the more immediate, tangible outcomes - eg going through a pytorch tutorial - over spending time trying to really understand the problem they are trying to solve. Great teachers try to guide their students there, and great students are perpetually calling themselves out mentally to try and stay on the track of understanding rather than rote repetition. But it’s very hard.
[0]: http://www.ams.org/publicoutreach/feature-column/fc-2016-06
With the crazy boom in developers, you got a whole generation of mediocre devs without any tradition to build on, surrounded by silly opinions and fads to learn from.
Now replace "developers" with any information age occupation , this remains true.
I do think it was well-written and the writing kind of saves the content. Besides there's absolutely nothing wrong with looking good. We might need a bit more of that in tech. So I'd encourage her to continue blogging.
Turn up your BS filter and let it roll.
vs
"We have two ears and one mouth so that we can listen twice as much as we speak."
Henry Ford