Hacker News new | past | comments | ask | show | jobs | submit login

The same presumption happens for people, too. Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent. I think a much more productive and healthy attitude is to assume that everyone was doing the best they could, given their resources, knowledge, and deadlines at the time.

That might be a false assumption (look, some people just don't care) but you gain very little by complaining and getting mad at things that already happened.

We love to complain about things our predecessors did wrong, but often, we don't do those things either :)




Agreed.

One example I see all the time is my more liberal/left-leaning friends assuming that their conservative adversaries (especially on the internet) are motivated solely by stupidity.

This trips them up when they are confronted with evidence of intelligence and solid reasoning from the people they had presumed to be capable of neither.

The reverse also happens of course, with the conservative person characterising their adversary as the stereotypical "Dumb Hippy".


Also happens with religion.


There is no similarity between that and religion. Religion by definition is an unjustified belief in supernatural - faith. There is no reason or logical backing for it. It is a malfunction of your reasoning system - perhaps heavy cognitive dissonance.


Here's the thing. Both with the religion argument and in general: even if you're right, your logic is unassailable, and the other person is provably wrong, you will still benefit from not assuming stupidity/broken thinking/etc, and instead seeking to understand the other person's position as thoroughly as possible.

At one extreme, you may discover a flaw in your reasoning. Even if not, you may find that while not entirely sound, there are valuable aspects to the other person's point of view, which can make your world-view more nuanced. Or perhaps you will simply confirm your initial perspective... but even then, you're much more likely to inspire the other person to think on the subject than if you come in with the perspective that they're provably wrong (and perhaps a bit pitiable for it). By seeking to really understand someone, you inspire them to do the same for you.


GP said: "assuming that [others] are motivated solely by stupidity."

You said: "by definition is an unjustified belief ... no reason or logical backing ... malfunction of your reasoning system"

exactly proving the point. You've made a blanket statement regarding anyone who has come to a different conclusion from you regarding the supernatural. It must be stupidity! It can't possibly be justified, or even clear the bar of not-totally-irrational! There's no room to even try to have a conversation, because "by definition" people on the other side are stupid.


No not stupid. I see religion more like a disease. Not many turn religious as adults. 99.99% have it passed down by their parents and their extended family and the culture they live in. They live life without questioning it and can't even see past it. Some people just are lucky to not have it imposed on them or wake up later in their life.


> 99.99% have it passed down by their parents and their extended family and the culture they live in. They live life without questioning it and can't even see past it.

I was raised in a religion that emphasizes understanding the belief system and arguments for it (the focus on valuing the truth was what caused me to ultimately leave, btw.). So I do have first-hand experience of what it means to believe in something for perfectly good reason with strong, consistent arguments. And I have to tell you, while most religious people probably believe for reasons like you just described, I've seen and talked to many self-proclaimed atheists and many refuse to believe for exactly the same reasons - they were raised as atheists. Or they discovered that atheism is what cool people do, or didn't want to stand out from the crowd.

People who don't believe in supernatural aren't inherently smarter than those who do. For many (I suspect most) of them, atheism is a blind faith, the same way Christianity is for their parents.


> "They live life without questioning it and can't even see past it"

I have met very few people like this.

And, again, you are making the OP's point. You have it all figured it out -- you know how wrong everyone who disagrees with you is. Whether you call it "stupid" or "a disease" or "irrational", the point is that you're not attempting to learn from them or understand them, you're simply being dismissive of everyone who concludes differently from you.


Maybe I misunderstand the OP's point but I specifically took issue to this very topic, at the expense of my karma apparently, because religion is differente.

Religion is 'solved' in the sense that they are man made belief systems, all which proclaim to be true, and most holding mutually exclusive claims between each other.

It is not debatable in a way left-right politics and their backers' stances and reasonings are. I'm not hating on them because it is not their fault. I feel for those trapped, I really do.

Given time societies turn (and have already turned in large parts) away from it through education and the undrstanding of the universe and the human condition via scientific method. There is no middle ground in this specific instance.

You would not entertain an alchemist or an astrologist either. Religion will soon join them in that regard in the collective consciousness.


> You would not entertain an alchemist or an astrologist either. Religion will soon join them in that regard in the collective consciousness.

And why do you think people won't entertain an alchemist or an astrologist? Why do you think religion will become similar to those disciplines?

It's not because people are getting smarter. It's because alchemy is not popular, science is! Most people don't understand a thing about either, but they have a firm opinion. That's just blind faith, the only thing that changes over the centuries is the object of faith.

It's completely orthogonal to the discussion about which is right and which is wrong. Most people don't know and don't care, as long as they believe the same thing their peers do, so I wouldn't be quick to judge one group, because the other is not smarter, it just sticks to the currently popular belief.


keep in mind that the article was about people who are not domain experts, seeing things they don't think make sense within a domain, and deciding those things are stupid prior to gaining proper understanding.

I feel fairly confident not entertaining someone who claims to be able to turn a lead brick into gold in their living room, because I know enough about physics and chemistry to understand the energy difference between lead and gold. But I would entertain someone who had nuclear-lab-grade equipment who claimed to be able to convert a small number of atoms. They might actually be full of crap, but my domain knowledge is not specific enough to be able to say.

When it comes to religion, I think the same thing with non-experts happens, and you're doing it. You claim to know all religious are "man made belief systems", "unjustified", with "no logical backing" -- claims that a domain expert can make regarding perhaps a few religions they're intimately familiar with, but not that anyone can actually make for all religions. How many religions have you studied deeply enough to really be able to make that claim? If Christianity is on your list, have you ever read the Didache, or De Principiis? If Mormonism is on your list, do you know about the Seer Stone or Elijah Abel? If Judaism is on your list, are you familiar with the Midrash or Siddur? These aren't particularly obscure references; they're things anyone well-enough versed in any of these religions to say "it's bogus because..." should know about.

If you don't know about those things, but you're sure each of those religions are "man-made", "unjustified", with "no logical backing", you should consider where your certainty comes from and how certain it really is.


Religions that claim to be correct can be disproved by refuting just one of their central claims. It is unnecessary to know everything about all of their other claims.


This requires you to be a sufficient domain expert to be able to:

- identify the central claims of a given religion

- identify the version of a central claim which is actually necessary for the religion

- determine what it would take to "refute" one of those claims sufficiently (rather than, for example, merely calling into question one of those claims, or refuting only one variant of a claim which has other variants.)

I contend that nobody on earth knows enough about "all religions" to be able to make such a claim. I further contend that, of the religions I mentioned above, if you didn't at least recognize the details I named, it's reasonably likely that your expertise is not deep enough to be able to follow those steps. For example, if you have never heard of The Didache, your awareness of Christianity is probably focused on only a small subgroup, whose "central claims" don't necessarily correspond to the claims of the broader religion; refuting one of that subgroup's claims may or may not have any relevance for someone from another subgroup.


I would contend in response that it's unnecessary to play whack-a-mole with countless subtle variations on the same theme if there are refutable core claims shared by a plurality of those variations. For example, the idea of a young earth is easily refuted, as are some sects' claims about the nature of human gender. Other broadly held claims, such as an unerring divine origin of scripture, lack any evidence, and thus can be dismissed, if not strictly refuted.

With regard to identifying essential claims, I'd propose that any claim that is believed by a good number of the sect's adherents is an essential claim, as refuting it invalidates those particular adherents' beliefs.

Beyond that, the question is what epistemological value can be derived from the remaining religions? What reason can be given to accept them? The burden of proof should be on them to demonstrate that they together, or one of them alone, should be accepted as accurately describing reality.

P.S. Thanks for the interesting discussion.


> "it's unnecessary to play whack-a-mole with countless subtle variations"

Sure -- but unless you're reasonably well-educated on a particular religion, how do you know if the variations are subtle or substantial? How do you know if they're "broadly held", particularly among that religion's scholars? (You brought up "unerring divine origin of scripture", which is a common belief of Fundamentalist Christians; do you know how broadly that belief is held by non-Fundamentalists? Do you know what the other common views are among the more populous Christian and Jewish sects regarding the same scriptures? Are you aware that Mormons believe the Bible has been corrupted?)

> "any claim that is believed by a good number of the sect's adherents is an essential claim, as refuting it invalidates those particular adherents' beliefs"

In practice, it doesn't work that way. Every religion I've studied carefully has a lot of inessential beliefs which are nonetheless widely held -- beliefs which, if they were overturned, would not in any way shake the faith of that religion's adherents.

It's common for outsiders to misidentify how popular certain beliefs are, how strongly they are held, and how essential they are. It's also common for outsiders to believe they've refuted something, when in reality they've stated some fact that has been known and accepted for centuries and which is actually the tip of the iceberg for scholarly study within a given religion.

That's why I suggest that, if you haven't heard of some of the specifics I named above, you're probably not capable of actually refuting those religions. It's not that those things are critical, so much as that to identify and address the actual core beliefs in relevant ways requires a depth of knowledge which would also expose you to topics like the Didache, the Seer Stone, or the Midrash. (And I wouldn't dream of making any sort of claim about the refutability of "all" African tribal religions, or "all" eastern religions, because I don't have that sort of depth of knowledge. I can say that I don't presently believe any of them, but that's a much weaker claim than "they're all irrational and a disease".)

> "The burden of proof should be ... to demonstrate that they ... accurately describing reality"

This ties us back to my original contribution to this discussion. How does one demonstrate that their position accurately describes reality, to an audience that thinks they are "motivated solely by stupidity"? How does one demonstrate there is value to be found in their belief system to someone who issues blanket dismissals? How does either party get value out of a conversation if one of them believes it's a monologue -- an opportunity to tell their stupid opponent how wrong they are, with no expectation that they might learn something?

If you begin with the assumption that someone else is stupid and you don't need to listen carefully to them, whether you're talking about their religion or politics or software, then it's unlikely you'll go through the sort of critical thinking process the original article described (and likely you'll "get lazy about challenging your own assumptions".)


Honestly friend you know very little on the subject of religion if you say 99.99% live without questioning.

But let s just say that some of the greatest philosophers were also believers of some sort of diety. As well as some of the greatest scientists.


Sounds like love. Or friendship.


Some of the worst code I've had to work with in my nearly 10-year long career so far was written by one of the smartest programmer's I've met. His problem was that everything because an exercise in designing this all-encompassing abstracted-to-hell-and-back web of interfaces, services, aggregates, domains, etc etc.

Indicative of this was a request to take a table of data that already existed (on a website) and add a button to export a CSV of that data. For anyone familiar with .NET (and I assume most other languages) if you've already got the data in the format you want to export this is literally a 10-minute task, including a unit test or two for the functionality. His quote was something on order of 18 hours which included time to write a set of TableDataExportService methods that would support a whole host of file formats in the future.


I've consumed enough CSV data to be wary of CSV data that was generated in ten minutes - including the unit tests. Are you sure you already have the data 'in the right format', for example? Maybe the data that's presented on the page has already been formatted for localization, so when you use that in your CSV export you put out dates in US or european format depending on the user's preferences, creating some hard-to track-down integration bugs later. Or maybe it only includes the display name for the status code, not the status code itself, so when three months later you change the display code from 'cancelled' to 'removed', all your clients' Excel macros break.

And once you've done that ten minute job on this page, how long will it take you to add it to the other 25 pages which also have tables of data that need CSV export? And when the table format changes to add another column, does the next developer also have to adjust your CSV output code?

Sure, YAGNI, but... there's no excuse to just throw a bunch of CSV-export logic inline into a page that previously had shown no interest in knowing how to format CSV files. Take a little longer, think about where to put the logic. There's a middle ground here.


I started on a project filled entirely with 'senior people' once, and was really pumped about the prospect of doing Serious Programming with serious people, instead of doing a bunch of mickey mouse crap.

Six months later everything was going horribly wrong because there was not a single one of us who was willing to solve a simple problem with simple code. Everybody was engineering the hell out of every single 'solution' and the code was impossible to read.

From this I learned a couple of things. One was that I had not learned as much from my Second System Syndrome as I thought I had. The second was that every project benefits from having people who are entertained by solving 'mundane' problems, to whom you can assign all concerns that are not part of the information architecture.

But the most important is that the best solution is -never- the one that is dazzlingly brilliant. It's often the one that's subtly clever (everyone agrees "that works", but some can wax poetic about how great it is at satisfying the concern), but sometimes it's the one that's dead simple.

Few solutions are easier to replace than the dead simple one.


I don't mean to advocate against YAGNI or writing simple code. I can't authoritatively to your specific example, but what I am suggesting is that you default your assumptions to a view that this developer had some reason for the choices that were made.

Maybe this client was notorious for asking for CSV export but really meant CSV, XLS, XLSX, PDF? Maybe the build and release infrastructure is so slow that any change - no matter how small - needs 3 days to be built, tested, and deployed? Maybe the complexity makes sense in other areas of the system and they decided to adopt patterns across the codebase to aid in teaching/onboarding new developers?

Just to be clear, maybe you will find that the reasons are totally invalid and this is gold-plated-abstracted-to-hell code. (It sounds like you probably will)

But if you assume from the start that everything is an over-complicated pile of junk and you could rewrite it in a day, I think you will find yourself jaded and unhappy with your environment.


YAGNI.

Software should be implemented as simple as possible, and then refactored as necessary when new functionality is required (the only exception is things you are very sure is going to be needed, e.g a password reset functionality on a password dialog).

Anyhow that is my development philosophy.


Yeah this was some of the most anti-YAGNI stuff I've seen.

Which is not meant to detract from the fact that the code was great 99% of the time. It just took 10x longer than it should have and cost 10x as much and half of it was never used.


"A great tailor does little cutting" ;)


> Developers tend to assume that the people that wrote the terribly messy code that you inherited were incompetent.

Don't over-generalize.

There is a messy code and there is a messy code. Changing shared data without synchronization is incompetence, but having a 3-page long for-loop is not. In reality though, once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there.


> once you've cleaned stables a dozen times spaghetti code is the red flag of incompetence and the correlation is there.

Question is, where's the incompetence?

Yup, like any profession, there are developers out there who just suck.

But the same is true of middle and senior company management. Can you honestly say you've never cut a corner because some incompetent manager mismanaged the schedule or customer expectations and then forced you to compromise quality in order to meet an absurd date?

And in any organization with that type of management, those issues are rarely isolated. Any one manager can do a little damage, but when an organization is dysfunctional, well-meaning coders on the ground may be forced to compromise code quality time and time again in order to deal with unrealistic schedules.

Think of it like a professional sports team. Sometimes, yeah, the players just suck. But a bad coach or general manager can have an outsized effect on an organization.

Now, I would never claim that all bad code is a product of bad management. Again, some folks just suck at their job. But speaking as a guy in middle management, I'd be willing to believe at least half of the bad code lying around in the real world is a product of an incompetent management structure.

Getting back to the article, that would represent the kind of hidden incentive that would cause an outsider to assume developer incompetence, even though the reality is very much different.


I absolutely agree that there exists terrible code and that there are incompetent individuals or folks that simply don't care. But if one assumes that as the default response, I don't think that is very helpful.

Even in your example of shared data/synchronization - what if the original developers were told that the code would never need to be thread-safe? Or what if there was a constraint that required this trade-off to be made? It's not so black and white.


Hell, even incompetent looking code (like managing shared resources poorly) can often be explained by a small script done by an amateur turning into a side business and then a full fledged company. Experience and knowledge of an industry beyond software is often many times more valuable than the knowledge of parallel programming. It doesn't mean the code wasn't valuable or good enough at the time, it just no longer meets the rigor and demands, that's why you're employed to work on it. To call everything shitty thats's below your own standards, level of education and experience is a naive view of how software actually exists in the world. Especially when the standard advice given to "idea people" is to learn to code their idea themselves.


It is helpful. It gives you the confidence to change things. It allows you to feel productive. And it's true often enough that it's a reasonable default, IME.


That seems like a dangerous way to feel confident in your own work and abilities to me. Pinning your self worth to comparisons with others is not so helpful, long term, as you might think.


Over-generalizer, know thyself.


I believe that the error the article describes comes from the family of "inside view" errors (see https://en.wikipedia.org/wiki/Reference_class_forecasting). Taking an outside view instead is a very widely applicable principle.


The issue is that, even allowing for good intentions, the fact tends to remain that the code is messy, undertested, and underspecified.

I've worked on a legacy codebase where the developer both admitted that the code was a hack job, got guilty-defensive about it, and then refused to schedule any time to help make progress.

You just want to shake them by the shoulders and be like "Look, it's fine that you did the best you could, but you need to either help clean up the mess or get out of the way."

Chesterton's Fence is wise in moderation--otherwise, it ends up as technological hoarding.


Sure - at the end of the day even the best intentions can result in a poor quality output. I've just found that my own personal outlook is much better if I stop complaining about how some other person messed up and focused on where the code is currently and how we can solve the problems at hand given our new knowledge/resources/constraints.


Oh, on that I agree. I'm just very frustrated with, having taken those steps, being blocked because ~reasons~.


There's also the fact that decisions can be very hard to un-make (even in something as malleable as code). This can lead to a bunch of slightly bad/messy decisions all coming together into something that is unimaginably messy/obtuse.


you make a very valid point!, Thx, :-)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: