1. 89
  1.  

  2. 33

    I’m not a huge fan of the article, but I do see the point they try to make. I’d say most tech content is badly contextualized and motivated.

    I’ll give my favourite example: Docker scale talks. The worst one (and I’ve seen a couple) was a very good talk by a Google developer on how they allocate and run seven-figure numbers of docker containers in their ecosystem. Super interesting talk, given at a conference that wanted to be “the first conference for beginner developers”. The amount of time I’ve spend in the pause to talk to people that absolutely wanted to try all that out and telling them that they are not Google was terrible. Good content though. But none of the audience would ever need to apply it, unless they are working at GCE, AWS or Azure.

    Similarly, I’ve seen a talk by Google SRE “for all audiences” that started with setting up an SRE team of at least 3 people in all major timezones. PHEW.

    My takeaway from my years in this industry is how bad this industry is at evaluating solutions and budgeting how many solutions you want to have in a product. There’s value in restraint.

    Still, all effective developers I know first reach to the internet for inspiration and are incredibly good at establishing that context by themselves.

    1. 13

      My takeaway from my years in this industry is how bad this industry is at evaluating solutions and budgeting how many solutions you want to have in a product. There’s value in restraint.

      I think this is because most of the industry never needed to manage spendings in a company. In addition, most of us didn’t get trainings or classes on this.

      You mention it’s hard to know which technologies are matching a company’s needs, but that’s also true for finance. Sometimes, spending 200k$ on prototyping is a drop in the ocean compared to the expected ROI, whereas sometimes 50$ of EC2 per day is a lot, and it’s not always easy to grasp if you never studied economics.

      Maybe that’s something that’s missing in the space, like “finance for IT teams”, that goes beyond the basic of direct ROI and depreciation.

      1. 4

        I fully agree with you there! That’s also why I don’t want to put that on individual engineers or even teams. This behaviour is rarely asked for, therefore the skill is low.

      2. 4

        As far as I can tell, the problem “at scale” is much worse (and considerably deeper) than the article can tell. It’s not just that industry is ridden with superstitious gossip; the “science” that it supposedly rests on is too. Logic, empiricism, skepticism, statistical literacy, and historical awareness all can help… but ultimately there’s no easy way out of this bad situation, because the objects of our study are themselves almost entirely artificial. Lies repeated often enough and loudly enough can indeed become truths. So can less deliberate falsehoods, and of course the many kinds of claims and assumptions which cannot easily be assigned a truth-value. It’s not a special problem unique to our special field, either; brave people in economics and the social sciences have had to face this lack of foundations for longer than “computer science” has even existed.

        Here’s a practical book and a much more theoretical one. Both are well worth reading. Good luck out there!

        1. 4

          The amount of time I’ve spend in the pause to talk to people that absolutely wanted to try all that out and telling them that they are not Google was terrible. Good content though. But none of the audience would ever need to apply it, unless they are working at GCE, AWS or Azure.

          I will never ever need to excavate the side of a mountain but I would still attend a talk about how someone built this monster:

          https://www.youtube.com/watch?v=i0QUDtqJwGQ

          I feel playing thought police at a conference fits in the “ego driven content creation” we’re discussing here. Just relax and let other folks enjoy what they like.

          1. 10

            The amount of time I’ve spend in the pause to talk to people that absolutely wanted to try all that out and telling them that they are not Google was terrible. Good content though. But none of the audience would ever need to apply it, unless they are working at GCE, AWS or Azure.

            I feel playing thought police at a conference fits in the “ego driven content creation” we’re discussing here.

            You are misusing (and watering down) the term “thought police”. (You aren’t alone.)

            In George Orwell’s 1949 dystopian novel Nineteen Eighty-Four, the Thought Police (Thinkpol) are the secret police of the superstate Oceania, who discover and punish thoughtcrime, personal and political thoughts unapproved by the government. The Thinkpol use criminal psychology and omnipresent surveillance via informers, telescreens, cameras, and microphones, to search for and find, monitor and arrest all citizens of Oceania who would commit thoughtcrime in challenge to the status quo authority of the Party and the regime of Big Brother. - Wikipedia

            Engaging in open discussion – even if challenging or critical – with others at a conference is nothing close to being the “thought police”. It doesn’t match any aspect of the description above.

            1. 2

              I’d like to redub some enterprise software tutorial audio over this digging video. https://www.youtube.com/watch?v=PH-2FfFD2PU

          2. 9

            I fully understand your view and have similar feelings.

            Yes, your article is quite abstract and it „lacks“ concrete examples. But problem with examples is that people start arguing about particular examples and nitpicking, while ignoring the main idea. So sometimes it is better to keep it abstract.

            1. 12

              This reminds me of a non snarky version of https://christine.website/blog/experimental-rilkef-2018-11-30

              1. 7

                Honest question: looking at your content with fresh eyes, don’t you think you kind of fit the case? :)

                IMO it’s ok for people to have opinions, demonstrations, tell stories, but I 100% agree there is way too much authoritative writing going on. I think it’s a good reflection of a certain aspect of our field: filled with ego.

                1. 9

                  Removing ego from writing is something that is annnoyingly difficult to accomplish. At some level the feedback cycles of “this post did good, I feel good about that” is kinda drug-like. Trying to remove a lot of authoritative and egoic language is something that has been worked on, but at some level it becomes difficult to write non-egoic sentences about this line of work. In writing this paragraph it is hard to avoid words like “I” and other references to the ego (which is why this probably sounds a bit stilted and awkward). It’s plausible that a lot of the cultural egoicism that is bleeding through in how things are being written. It’s ingrained at such a deep level that it can be difficult to separate things from the egoic language. It is an interesting thing to try and do (though the word “it” is probably being used to replace first person pronouns a bit much), but it makes me take about 5x as long to write what feel like basic statements about my experience of reality.

                  I will try working on it though.

                  1. 3

                    You could have written simply “I’ll try better to write in a non-authoritative voice” X)

                    I’m not saying you have to change anything; I just wanted to know if you thought your own writing (not always! you’ve had many personal pieces not advocating anything) at times was reflective of what was being criticized.

                    It’s very good I think though if you’ve already more or less found this in yourself and you’re trying to improve. I know a lot of people will go forever not doing this. :/

                    1. 4

                      It’s an ongoing struggle between trying to be concise and wordy. The non-egoic side of my writing has this flowering poetry like quality that is slightly difficult to work into explaining technical minutae. I’m working on it though :)

                      1. 3

                        I think it’s still possible to write in mostly active voice (using “I” and avoiding “to be” verbs) without sounding overly authoritative or making yourself the focus of the article. Writing in passive voice feels less authoritative, but almost as if the writer is trying to avoid taking ownership for their ideas. In some cases, I would argue that passive voice feels more authoritative and egoistic because, by avoiding the pronoun “I”, the content reads as if it applies to everyone. “It is difficult to…” sounds like the author tried to make a universal truth, while “I have found it difficult to…” seems more humble and personal. Passive voice can also be more tiring to read.

                        I’m honestly not sure that it’s bad to write blog articles from an authoritative standpoint. In my opinion, it’s the reader’s obligation to verify that the information presented makes sense for their particular situation. That said, writing that feels too author-centered is not enjoyable to read.

                2. 4

                  I wrote something similar a few years back, though not necessarily about tech. My blog isn’t worth reading btw and I barely update it. This just reminded me of it.

                3. 7

                  I agree with the premise of this post, it resonates with my technological transition over the years. I think that you realize this, the fact that you shouldn’t trust online sources as undisputable truth, once you get deeper into topics and research them, and when you become a creator yourself and are corrected by the online community. The world of tech is overwhelming and it’s not surprising that initially we’d rather consume and trust rather than take a critical view.

                  1. 10

                    “But how do you know appeal to authority is bad?” “Because Carl Sagan said so!”

                    1. 7

                      That’s just a quote. She could have left it out and the point would still stand intact.

                      Appeal to authority is flawed because we are talking about engineering. And in that context, appeal to authority is the conceptual opposite of science. As an engineer, you do something because you have technical knowledge and you can predict the results running the numbers using algorithms based on scientific knowledge. This applies to a codebase or a programming stack. If you use it because you have technical motivations to do so, you are aware of the advantages and disadvantages. From the moment you start using this because “Facebook|Google|Netflix|amazon” did it and they must be right”, you are putting the technical aspects of your choices to a secondary plan, and walking right into the pitfalls.

                      1. 4

                        I don’t know if in this case the irony was deliberate, but it reminds me of the beautiful (and quite intended)

                        Isn’t it rather amusing that to this day the most serious philosophers, however strict they may be in questions of certainty, still call on what poets have said in order to lend their ideas force and credibility? And yet it is more dangerous for a truth when a poet agrees than when he contradicts it. For as Homer says: “Many lies tell the poets.”

                      2. 5

                        Weirdly I have the complete opposite experience. I work with highly opinionated language (python) so I guess that plays into it but I’ve never met or worked with someone who would use any of these arguments:

                        • I don’t know. It was in some article.
                        • I don’t know. I copy-pasted it from X.
                        • I don’t know. I was doing it in my previous project.
                        • I don’t know. Someone told me so.

                        In my experience it’s the opposite - everyone is really opinionated even about minute details to the point where learning to let it go and move on was the skill that saved me the most time.

                        I see OP is from Poland and me being from Lithuania and worked with Polish developers I can see that this might be a cultural issue. Poland and Lithuania kinda boot-strapped themselves into this medium and prioritized end-results (just make it work) rather than understanding of the medium itself. That’s what I’ve seen more than 5 years ago - today I’d say that both of these regions caught up with modern software culture, for the most part.

                        1. 2

                          Wait… Python is a highly opinionated language? In what way?

                          1. 1

                            I think OP is talking about PEP 8 and the culture around it.

                            1. 1

                              import this
                              :)

                          2. 5

                            I agree with the general premise that you should either be deliberately consuming or creating, and that creating is better if you can manage it. I also agree that the essay was far too non-specific.

                            Part of the problem is that a lot of people who spend the majority of their time consuming actually believe they’re creating. Sure, they may be copying a bunch of stuff down from SO or following word-for-word famous-person-x, but that’s only in the service of actually creating something, er, greater. Sometimes they actually get that thing created, sometimes not. Rarely is it anything truly creative. Turns out if you don’t up your game and master working across genres (no matter what field you’re in), most anything you do is derivative. In fact, part of truly being creative is a deep appreciation for how derivative most everything in your field is. That’s the bar you have to work past.

                            Instead of offering specific advice on being creative, perhaps I can add advice on how to know if you’re being creative. If you pick some general foundational rules that are your own, then develop on those rules until you end up somewhere that you might find uncomfortable and might require personal change, you’re being creative. Creativity takes you and your audience to new, interesting, and perhaps uncomfortable spots. There should be some surprise involved, even on the part of the creator.

                            Most of tech content is bullshit because too many practitioners just want to fill-in-the-blanks. To them, technology isn’t a place you create, it’s a place where you follow the rules in order to engineer something that’s just another version of a thing that’s been around forever, only shinier. Thought leaders and authors know this, so they provide a constant stream of how to do stuff you’re already doing only with more coolness.

                            And if I read one more essay about “How I used K8s to generate random numbers!” or the like, I’m going to start making funny faces at the monitor. (grin)

                            1. 5

                              I like the spirit of this article, but I can’t help but think it’s too nonspecific to make a good case for itself. The author seems to be crafting a definition of “bullshit” technical content that is primarily something like “too much appeal to the authority of prestigious programmers, and not enough independent thinking”. This is all well and good - of course it’s better to have an objective argument for a technical decision than the word of some authority that it’s a good one, and it’s good for programmers to think independently about the problems they have at hand. But what does that entail in practice, with respect to specific classes of programming problems? That’s the difficult thing for a programmer to know, and this article says nothing about how one might go about making such determinations. How can you tell if any specific tutorial you’re reading “contains harmful mistakes”, so that you can know to ignore that tutorial? How can you determine if the architecture of a piece of software you work on is “entirely fucked up” because of incompetent senior engineers?

                              Incidentally, one of the more specific and therefore potentially-applicable pieces of information, was a limited defense of authority: “Dan Abramov telling you how to use React”. As it happens, I didn’t know who Dan Abramov was and had to DuckDuckGo the name. Turns out he works at Facebook and is one of the creators of the Redux library for managing state in React apps. I have nothing against Abramov or Redux. But how can this author know that Abramov specifically is an authority who is definitely right, but tech content coming from people who aren’t of his special class of expert need to be treated with more skepticism than it currently is?

                              1. 3

                                this article says nothing about how one might go about making such determinations

                                I would argue that if you have a method for making determinations then you are no longer thinking - you are just applying a method. And the article, as I read it, advocates for thinking on principle.

                                In my view, thinking and applying a methodology are polar opposites. It’s exactly at those points where method fails us, or where we abandon method, that we are forced to think.

                                1. 2

                                  But how can this author know that Abramov specifically is an authority who is definitely right, but tech content coming from people who aren’t of his special class of expert need to be treated with more skepticism than it currently is?

                                  I think this is where the article went wrong. Yes, appeals to authority are a fallacy when considering logical syllogisms. However, in the real world, relying on external authorities is the only way to know anything of practical consequence.

                                  The useful skill that junior developers often lack is the ability to distinguish who is an actual authority on a subject. As a member of the React core team, Dan Abramov has authority on the subject of React that Joe Blogger does not. That doesn’t mean he’s always right about React. But having an authority to rely on will gradually help you sift the wheat from the chaff in online discourse until you’ve internalized ways of independently evaluating claims yourself.

                                2. 3

                                  Nice to see someone think for themselves.

                                  1. 3

                                    Well, “90% of anything is crap”, according to Theodore Sturgeon. I think is a useful rule of thumbs. But I would argue though that too much idiosyncrasy and “I listen to my own experience” is not perfect either. The lessons you learned through your own questioning and experience may not be as broadly applicable as you imagine, and the experience of others may well contradict your own. The anecdote given by another commenter on Google engineer talking about scaling to a crowd of beginner is a good example of this.

                                    Karl Popper theorized that we gain confidence in an hypothesis as it get tested across dimensions, and as we generalize its context. Does the advice apply to the small startup as well as the bank as well as Google? Is it true in greenfield as well as brownfield codebase? 100 users and 1 billion? The reason the advice is bad can be because it is false, but it may be that it is not applicable to your context. Your own experience and hard learned lesson may be a poor advice to somebody else, even to future you!

                                    A lot of advice should be rejected outright because it is just some guy thinking without checking the facts. This is very common, and why it is wise to check what one do, rather than what one say. Then, a whole bunch of advice are, sadly, wrong conclusion from real fact, and those should at least be looked at, to see if you can find the real lesson hidden behind the error. Then some advice are real hard earned wisdom that don’t apply to you… yet. They are not crap, just a poor fit right now. And it may well be that some day you’ll find yourself discovering that in your new situation, they are right!

                                    1. 3

                                      Most music on soundcloud is crap. Most art is crap. Most movies are crap. Making good stuff is hard and rare because it’s hard. There’s the hobby side of things “I made pong in vimscript” which behaves more like art. Then there’s the $job side which is more bound to the business than to the art. The point is to reduce cost or produce more (which is cost). We don’t have a ton of fundamentals (like steel or atoms) so it’s very abstract. We have benchmarks and maybe some mathematical proofs (which are usually reduced or theory). It’s very hard to tell better from worse.

                                      When the rules don’t work for you anymore, you’ve ascended. This isn’t a superior position. You’ve gotten off the training wheels and now you have to be more independent which is more work. You don’t need the rules. The rules have holes. Great. You still need rules and they are going to come from you I guess. Or you need to keep looking. You needed the rules as a beginner, otherwise you would repeat all of history as self discovery. I threw away an actionscript 2.0 book after hitting some really horrible code and had a similar revelation as the article. “The teacher doesn’t know everything”.

                                      1. 3

                                        This is actually a pretty powerful insight from someone who’s been professionally programming for only 3 years. Huge respect!

                                        1. 3

                                          when this is […] documentation saying that this is the only way to use its API, then yes, you probably should agree with it

                                          Unless it’s PHP documentation!

                                          Yes, the SQL Injection page finally mentions prepared statements now! …very briefly, without even an example. The only defensive code example is still using settype to force a variable to be numeric before concatenating it into a query.

                                          1. 3

                                            Very meta.

                                            1. 2

                                              I’m putting this in a bit of a black-and-white manner, but I don’t take any proposal without a case study seriously. If someone believes they invented something better, they can prove it to me by showing the application also. New language / tool / workflow / design pattern? Show me the application of it in a non-trivial project. Give me a paper, not a blog post.