1. 33
  1.  

  2. 21

    Just a list and no explanation, quite uninteresting.

    1. 8

      Hey, so thanks for the criticism (I think). This is the 4 year old party I was talking about. It’s a fun format of rants in a list. I agree it’s not for everyone. https://spaceninja.com/2015/12/07/falsehoods-programmers-believe/

      1. 8

        I think people have the same problem with every list of this genre: There’s no explanations and no suggestions.

        There are, implicitly, problems to avoid, but even that has limits, in that it assumes the programmer is trying to write the most generally applicable software, possible or otherwise. For example, from “Falsehoods programmers believe about time”: “The system clock will never be set to a time that is in the distant past or the far future”. Depending on the software, and how you define “the distant past or the far future”, you can assume this if you document it as a requirement. Kerberos does precisely this as part of its security model.

        So in treating these things uniformly as “falsehoods” these lists assume that engineering trade-offs don’t exist, or that making such trade-offs is incorrect somehow.

        1. 1

          Well the statement that it will “never be set to a time in the distant past or the far future” is a falsehood. If Kerberos engineers had not considered this then their spec would have a gaping hole in it. So it sounds useful to me. The idea that the statement is carte blanche useless because in one extremely niche scenario you can as a working model assume that the time is not in the distant past or far future is pretty contrived. People will still violate the spec, you’ve just made it a scenario you don’t have to concern yourself with.

          I do think lists of “Falsehoods” are “Brains not included”, you have to use your own mind and knowledge to consider how these scenarios may apply (or not apply), and that doesn’t mean they aren’t useful. For example in this article I noticed at least 3 things in our application that I hadn’t considered. Pretty useful stuff.

          1. 1

            The idea that the statement is carte blanche useless because in one extremely niche scenario you can as a working model assume that the time is not in the distant past or far future is pretty contrived.

            I said the exact opposite: The statement isn’t completely true because of examples like Kerberos, so pretending that it’s necessarily a falsehood is wrong.

            1. 0

              I’m pretty sure you didn’t say the exact opposite, and I don’t even know what that means for this statement. Kerberos does nothing to protect you from getting distant past or future, it just means you are violating the spec by doing so.

        2. 4

          Almost all of the “falsehoods programmers believe” articles share this problem, though: they’re just a long list of stuff labeled “this is wrong”, but with no explanation of why those things are wrong, or what someone should do instead. This makes them extremely unhelpful.

          1. 4

            I strongly disagree that they are unhelpful to everyone, though I do think they are less accessible to beginners. Some of these falsehoods don’t have a thing you can do instead. Some of them don’t have a good explanation as to why it is false. That doesn’t mean it’s not useful to know that it’s a potential pitfall when you hear it. Some of these you will do knowing they are a falsehood because there is no “good option”. In life we don’t always have a clear and obvious best option, but having a heuristic around risks is still useful.

            https://github.com/kdeldycke/awesome-falsehood

            1. 1

              The typical list-of-bullet-points “falsehoods” article, though, doesn’t provide enough information for anyone to decide “this has no good option, I’ll pick the least worst based on tradeoffs”, because it doesn’t say why the things in its list are wrong. If people were doing comparative explanations of why certain assumptions cause problems, and going over the tradeoffs involved, that would be useful. But they’re not: they’re just posting a list of “this is wrong and no, I’m not telling you why or what you could learn about the problem domain to let you make better choices”. Many of them verge on, or simply are, pure self-congratulatory “I know more trivia about this than you do”.

            2. 3

              Well-structured articles of this type imply underlying situations and behaviors by the order in which elements are listed, so that if you’re following the list, you end up with a general understanding of the landscape being described. This one mimics the structure only shallowly, though: you don’t, by reading it, get an understanding of how search is actually used or what kinds of problems you run into (although search is a pretty diverse space & depending on your data set & your user base’s needs, completely different behaviors are appropriate, which makes it a poor fit for this kind of list).

              I’m sort of tempted to write a different version of this list, keeping the “falsehoods programmers believe” format, to illustrate this point. When such a list is well-written, an intelligent reader (even one with no deep knowledge of the subject) ought to require no explanation for each point, because the order of the points has led them to update their mental model incrementally such that each point can be justified based on a generalization of the unstated logic behind the previous points.

              This one doesn’t do that, but instead just sort of skips around. The points that are obvious to people outside of search are things like “users will not expect search to act like google” – in other words, sort-of-cheap-shots about end users that don’t necessarily apply outside general-audience systems & don’t really need to be said in the situations where they do apply. Other points (like “search is not a database”) are deeper & really do need to be said, but probably ought to be contextualized so that they’re understandable.

              1. 1

                Well-structured articles of this type imply underlying situations and behaviors by the order in which elements are listed, so that if you’re following the list, you end up with a general understanding of the landscape being described.

                I’m not sure that I’d agree with that. Or, at least, I’d dispute how many “well-structured articles of this type” are in existence.

                I’m sort of tempted to write a different version of this list, keeping the “falsehoods programmers believe” format, to illustrate this point. When such a list is well-written, an intelligent reader (even one with no deep knowledge of the subject) ought to require no explanation for each point

                This reminds me of “well-written code doesn’t need documentation because it’s self-documenting”. Which is something that’s perhaps true in theory, but which I’ve always found to be false in practice.

                A little while ago I tried taking a different approach to this sort of article, to show what it would look like: the “truths programmers should know” isn’t a list of bullet points, and does go into detail on the problem domain to explain what’s going on and why common assumptions about it might fail. I don’t see why other “falsehoods programmers believe” articles couldn’t be written the same way.

                1. 3

                  I’d dispute how many “well-structured articles of this type” are in existence.

                  For sure, they’re a rarity. “Falsehoods programmers believe about names” does this, though.

                  This reminds me of “well-written code doesn’t need documentation because it’s self-documenting”. Which is something that’s perhaps true in theory, but which I’ve always found to be false in practice.

                  I wasn’t going for that take at all.

                  Communication isn’t really a matter of conveying meaning by encoding that meaning (since that kind of communication can only express trivial truths), but by creating an environment that constraints somebody’s existing world model in such a way that the only way to process the message produces a change to the model. A teacher isn’t telling a student a sequence of facts, but asking a question in such a way that answering the question requires them to independently reinvent the theory behind the answer, and a good teacher knows how to do this incrementally so that each discovery is low-effort.

                  In other words, this kind of article oughtn’t be a literal list of falsehoods so much as a tour through the intellectual space of the subject being described by way of iterative violations of successive models.

                  Doing this requires us to begin with an understanding of what the reader already thinks (in the case of names, that one can implement a name form as two input fields that take ascii text, or in the case of time, the idea of newtonian universal time.) Each ‘falsehood’ in the list causes the reader to transform his mental model of an appropriate implementation in a predictable way, and so the order is determined so that it leads the reader from the most obvious model to the most correct model with a minimum of effort on the part of the reader, while still making the reader actually determine both the reasoning & the solution themselves.

                  This is a hard thing to do with search, compared to names or time. Everybody with a CS degree was at one point asked to deal with name records in a naive way as part of some class assignment, & everybody except the sentinelese has basically imbibed newtonian time. Relatively few people think even shallowly about search implementations, so there aren’t obvious-but-false starting points that are easily identified: the points OP rejects are actually more nuanced than what J Random Hacker would probably come up with immediately. And, on the other side, there isn’t a maximally-flexible ending point: ultimately, you need completely different kinds of search systems for different types of data & different types of users (something management learned the hard way when they tried to force patents, trademarks, chemical, and scholarly journals to all use the same underlying search engine!)

            3. 4

              That there’s an equal, large number of upvotes for the article and your comment is itself interesting. Does that mean the content was interesting to half with others wanting different style? Or interesting to most of them who then agreed that it could be better after seeing your comment?

              If anything, it reminds me of the old strategy of having high-level points people can optionally drill down into. They expand, link, pop stuff up, whatever. Some people also did two versions of an article: a short one (eg executive summary) and long one (full details).

              1. 5

                Agreed. I’d rather have a list of only five items with a thorough discussion about why this is, than a way too long and boring list that I’m not going to dig through anyway.

                1. 4

                  If you find it uninteresting then you possibly aren’t in the step of implementing or pushing against implementing search in your application. This is a healthy sane checklist of things to consider.

                  1. 8

                    If you’re pushing against search and bring up a “falsehood”, any good project manager would ask “why?” So having an explanation would help a lot.

                    1. 1

                      Sure, but this article would be a bajillion pages if they felt obligated to describe every one of these, many of which are obvious on a very small amount of reflection.

                      1. 1

                        Exactly. Just think about it and use your brain, don’t expect everything served on the silver plate. If you wanted this checklist with explanations, it would be at least 200 pages long book.

                2. 5

                  If you haters actually got what you were asking for, you would also hate that. Maybe just skip on over articles like these from now on instead of actively discouraging anyone from ever creating checklists, god forbid. You’re going to walk into the airline industry and go “No explanation why I should verify that the door is closed, quite uninteresting” and then fall out of the plane when you get up to get coffee. There’s a downvote button for a reason. You can downvote without shutting down all discussion about the article.

                  Meta, perhaps we should have a tag for lists so that people who don’t like lists can avoid them. Personally I love lists, they are clear, efficient, and to the point. No dancing around the important stuff.

                  1. 2

                    Nobody’s shutting down discussion about the article, and nobody’s being an asshole except you. Some people are criticizing the form and content. Like people do on every article.

                    If you haters actually got what you were asking for, you would also hate that.

                    We have seen lists with explanations and people absolutely love them: https://lobste.rs/s/txtwkf/falsehoods_programmers_believe_about

                    1. 2

                      I didn’t ever claim you, or others were being an asshole. I did rightly claim that you hated articles like these, a hater is one who hates, not one who is an asshole. Sure you like lists with full explanations but I’d argue that’s an entirely different kind of article. It’s astronomically more laborious to make and I’d argue no more useful.

                      Buildings do not move

                      In Zürich, a 6200 ton building was moved by 60 meters to make way for railway tracks

                      A single example or explanation of a failure case is not useful. This particular explanation is extremely misleading, and would take at least two paragraphs to sufficiently explore. A building moved 60 feet once, that’s definitely going to be the scenario I run into. The whole point of these is that providing a specific counterexample is not sufficient to show that you aren’t going to hit it. A trailer home can move very easily. A tiny home may be moved at will. Some people have addresses but do not have homes, but they will list themselves as living in a particular building that does not exist and then will move that building around wherever they happen to be. You can’t just avoid having to use your brains, and it’s an unreasonable burden to people who make attempts to have exhaustive exploration of things that can go wrong. The article you linked has a total of 10 examples. That’s not super useful.

                    2. 1

                      I don’t know who you are, but thank you so much for this comment. The paltry upvote I gave you was not enough.

                    3. 4

                      Falsehoods Writers Believe About Readers:

                      • Repetition is funny.

                      • Repetition is tolerable.

                      • Repetition doesn’t lead to readers closing the page.

                      1. 2

                        Customers would never try to hack you through your search bar

                        Oh dear. Oh dear oh dearie me….

                        https://www.stuff.co.nz/national/politics/113109311/no-further-police-action-on-budget-leaks

                        1. 2

                          All customers want their misspellings corrected

                          and

                          It is possible to create an algorithm to handle all misspellings

                          Has burned me personally at work lol.