5 ms·

Yup, I hear you. I try to put my faith on the in-between folks, who say, "we can't prove in a court of law that this is harmful, but in this case there is a pla

Yup, I hear you. I try to put my faith on the in-between folks, who say, "we can't prove in a court of law that this is harmful, but in this case there is a plausible mechanism and the risks don't seem justified. In this other case, there's no plausible mechanism for harm or the benefits outweigh the risks." The people who show some kind of doubt are, as always, the ones to actually listen to.

beat 7y ago
Such a world we live in, where the fools are absolutely certain and the wise are full of doubt.
- codr7 7y ago
  It couldn't be any other way. The more you really learn, the less ignorant and more nuanced you become.
throwaway5752 7y ago
That sort of reaction is exactly why the Overton window works. If Alice says that 2 + 2 = 4 and Bob says that 2 + 2 = 8, then Bob is wrong and the answer is not 6.
tcfunk 7y ago
Sort of a tangent here, but I find very often in the workplace that my managers want me to tell them about how I "know" something will work. I never know if something will work. I can only be mostly sure that it will. It goes against my nature so much to respond to these questions the way that they want.
- crdrost 7y ago
  If it helps you out personally, it may be nice to impose a translation filter between the rest of the world and yourself here? These other folks say “know” when they mean “have confidence in” and they are looking for you to similarly say “know” meaning that. Your internal meaning of knowledge can be much stronger, but they are just asking for you to give your reasons why you think that would be the case. You can feel free to hedge as well. “I think we can resolve all of these things if we just make a UserInteractions table on our end, rather than proxying all of this to the upstream API. We will still proxy the interactions, but our source of truth can be our table.” “How do you know that will work?” “Well, it involves taking on some risks, like when they update things and never tell our source of truth about them, then our two systems are out-of-sync. I think that probably the problem of synchronizing our table with their system is simpler and more tractable than getting their system to behave in a normal way where we don't get successful responses until we're sure that the interaction has happened. It would be different if everything was changing every second of course, but that isn’t what we’ve been seeing happen on our staging server. The rest of it is not too bad, there are three API endpoints which generate these UserInteractions and they all touch it but rewriting them can’t be more than a day’s work, so the only hard problem is populating this UserInteractions table in the first place, but that’s not an ongoing risk, just a one-time cost for a developer to pay. That’s why I’m confident that this is a good choice moving forward.” “How do you know that interaction times won’t suffer?” “Well, I cannot say 100% for sure but usually requests over the local network to the local database are going to be faster than general network requests, unless things are really unusually smooth between the two. But at our present number of users and our projected go-live numbers, I have seen MySQL setups handle that with no problem and if it is a problem then we’ll have to face that scaling difficulty either way, as MySQL is not just used for these UserInteractions but also for X, Y, and Z.” You see? I don’t need to claim absolute knowledge here, I just need to express: 1. There is some sort of cost-benefit analysis of trade-offs happening here, 2. someone has done this analysis, and, 3. more info can become available and I can be held accountable for this trade-off if this choice later becomes problematic. It’s sort of a part of negotiation rather than part of technical responsibility. If you can appeal to an outside authority (“The OWASP security guidelines clearly state...”) or at least an unbiased one (“I ran this by Susan, who is a developer at our contractor that we work with, and she agreed it was worth a shot and gave me some good feedback about a potential pitfall that I should avoid...”) or otherwise communicate that some sort of expertise has peeked in to a problem, then people feel naturally more confident and trusting about it. If you don’t do that then it starts to sound more like “we should do this because I say so” even when the problem is legitimate and painful. I guess I’m saying, think of yourself as a doctor talking to a patient about an upcoming surgery. They are right to have nebulous general concerns and they talk in funny ways that technically do not have much scientific value, but it is important to reassure them when needed, provide them options when needed, and just trust that if they lose trust of you and want to get second opinions, they are acting in good faith and have every right to be concerned about these things that are probably innocuous but have a tiny probability to kill them.
  - beat 7y ago
    I read this, and immediately thought of one of my maxims... "Data duplication is the source of all bugs".
    - crdrost 7y ago
      Your maxim is already in common parlance as Karlton’s principle. “There are only two hard things in computer science: cache invalidation and naming things.” (Some add “and off-by-one errors” but arguably that is the same problem of some ‘cache’ being ‘invalid’ and never suitably repopulated…) With that said downstream caches are often solid, if one treats them as the source of truth. “We just pretend this has not happened until we see it.” Same thing with denormalized data in a database, sometimes that's the only way to build the appropriate index which speeds things up.
      - beat 7y ago
        Yeah, I wrote about that exact thing a while back. https://hackernoon.com/the-two-hard-problems-in-computer-science-2a42ec008eee https://hackernoon.com/the-two-hard-problems-in-computer-sci...
JamesBarney 7y ago
Or sometimes they're just less informed. People who are well-versed with statistics have studied vaccines, gmo, and glyphosate the overwhelming majority all came to the same conclusion and they're confident in that conclusion. Maybe these things are dangerous but there isn't any good evidence they are.

beat 7y ago

Such a world we live in, where the fools are absolutely certain and the wise are full of doubt.

codr7 7y ago
It couldn't be any other way. The more you really learn, the less ignorant and more nuanced you become.

throwaway5752 7y ago

That sort of reaction is exactly why the Overton window works. If Alice says that 2 + 2 = 4 and Bob says that 2 + 2 = 8, then Bob is wrong and the answer is not 6.

tcfunk 7y ago

Sort of a tangent here, but I find very often in the workplace that my managers want me to tell them about how I "know" something will work. I never know if something will work. I can only be mostly sure that it will. It goes against my nature so much to respond to these questions the way that they want.

crdrost 7y ago
If it helps you out personally, it may be nice to impose a translation filter between the rest of the world and yourself here? These other folks say “know” when they mean “have confidence in” and they are looking for you to similarly say “know” meaning that. Your internal meaning of knowledge can be much stronger, but they are just asking for you to give your reasons why you think that would be the case. You can feel free to hedge as well. “I think we can resolve all of these things if we just make a UserInteractions table on our end, rather than proxying all of this to the upstream API. We will still proxy the interactions, but our source of truth can be our table.” “How do you know that will work?” “Well, it involves taking on some risks, like when they update things and never tell our source of truth about them, then our two systems are out-of-sync. I think that probably the problem of synchronizing our table with their system is simpler and more tractable than getting their system to behave in a normal way where we don't get successful responses until we're sure that the interaction has happened. It would be different if everything was changing every second of course, but that isn’t what we’ve been seeing happen on our staging server. The rest of it is not too bad, there are three API endpoints which generate these UserInteractions and they all touch it but rewriting them can’t be more than a day’s work, so the only hard problem is populating this UserInteractions table in the first place, but that’s not an ongoing risk, just a one-time cost for a developer to pay. That’s why I’m confident that this is a good choice moving forward.” “How do you know that interaction times won’t suffer?” “Well, I cannot say 100% for sure but usually requests over the local network to the local database are going to be faster than general network requests, unless things are really unusually smooth between the two. But at our present number of users and our projected go-live numbers, I have seen MySQL setups handle that with no problem and if it is a problem then we’ll have to face that scaling difficulty either way, as MySQL is not just used for these UserInteractions but also for X, Y, and Z.” You see? I don’t need to claim absolute knowledge here, I just need to express: 1. There is some sort of cost-benefit analysis of trade-offs happening here, 2. someone has done this analysis, and, 3. more info can become available and I can be held accountable for this trade-off if this choice later becomes problematic. It’s sort of a part of negotiation rather than part of technical responsibility. If you can appeal to an outside authority (“The OWASP security guidelines clearly state...”) or at least an unbiased one (“I ran this by Susan, who is a developer at our contractor that we work with, and she agreed it was worth a shot and gave me some good feedback about a potential pitfall that I should avoid...”) or otherwise communicate that some sort of expertise has peeked in to a problem, then people feel naturally more confident and trusting about it. If you don’t do that then it starts to sound more like “we should do this because I say so” even when the problem is legitimate and painful. I guess I’m saying, think of yourself as a doctor talking to a patient about an upcoming surgery. They are right to have nebulous general concerns and they talk in funny ways that technically do not have much scientific value, but it is important to reassure them when needed, provide them options when needed, and just trust that if they lose trust of you and want to get second opinions, they are acting in good faith and have every right to be concerned about these things that are probably innocuous but have a tiny probability to kill them.
- beat 7y ago
  I read this, and immediately thought of one of my maxims... "Data duplication is the source of all bugs".
  - crdrost 7y ago
    Your maxim is already in common parlance as Karlton’s principle. “There are only two hard things in computer science: cache invalidation and naming things.” (Some add “and off-by-one errors” but arguably that is the same problem of some ‘cache’ being ‘invalid’ and never suitably repopulated…) With that said downstream caches are often solid, if one treats them as the source of truth. “We just pretend this has not happened until we see it.” Same thing with denormalized data in a database, sometimes that's the only way to build the appropriate index which speeds things up.
    - beat 7y ago
      Yeah, I wrote about that exact thing a while back. https://hackernoon.com/the-two-hard-problems-in-computer-science-2a42ec008eee https://hackernoon.com/the-two-hard-problems-in-computer-sci...

JamesBarney 7y ago

Or sometimes they're just less informed. People who are well-versed with statistics have studied vaccines, gmo, and glyphosate the overwhelming majority all came to the same conclusion and they're confident in that conclusion. Maybe these things are dangerous but there isn't any good evidence they are.