Most tech content is bullshit

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.

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.

[1]: https://en.wikipedia.org/wiki/Yogi_Bear

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.

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.

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.

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. ¯\_(ツ)_/¯

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.

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?

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.

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.

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?

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.

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

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?

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