The likely return of expert authority

Post Reply New Topic

I like Haidt quite a bit. Something from game theory that might be relevant is that in some models cooperation beats out parasitism and predation when it aggressively excludes them, but loses to them otherwise. So a 'heterodox academy' might benefit from entrance criteria that emphasize honesty and reciprocity more and raw performance less (versus the current system).

If you mean using compartmentalization/modularization to avoid getting mixed up about entanglements in the design process, that definitely works as long as you don't mind the performance penalty.

Sometimes at my old job we went in the other direction; for example not using kinematic mounts on most of our microlithographic products because the performance penalty (lower rigidity) caused more misalignment than the fixturing issues the kinematic mounts were there to avoid.


I like Sowell's adage that 'there are no solutions, only trade-offs.' If you're rounding to avoid a cognitive or computational limit, then your alternatives are to break the full-precision dataset into simplistic pieces and process them in sequence or parallel; or search for patterns distributed across the full dataset that can be recognized on a small computational budget. All three methods fail on some datasets.

The way I'm using it - when all else fails disassemble piece by piece, keep doing so until the problem goes away, then put back whatever gave you the problem, see if you can isolate the variable, etc..

It's probably a bit of a stretch in the sense that Ship of Theseus is the question of whether, if you've replaced everything on an old car, if it's still the same car. I think I use it more due to all of the labor that's involved - it's a bit like completely disassembling and reassembling a car or boat in some cases.

That's how pseudoscience works, not real science. That's the method used by everything from climate deniers, to young earthers, from creationists to flat earthers.
Just what sort of science do you think is based on that shoddy method?

So you were thinking of occult entanglements that show up as surprise failures when you run your app and are hard to track down. So for example one function sporadically passing malformed arguments to a child function, which has a bug that prevents it from returning an error; and maybe the consequence is data corruption that doesn't immediately break anything. Is that what you meant?

(I was thinking more of the engineering equivalent of the n-body problem, when there are simultaneous feedback loops that aren't linear and trying to compute the interaction of any two variables in isolation will give you an incorrect answer. Or 'pick-up sticks' scenarios where changing one variable imbalances others and you have to make slightly adverse or counter-intuitive changes to other variables to free up the first.)


I thought it made sense. It's just that I'm not a developer and had to look up the reference. The articles that came up in a search were about test-driven development, which is relevant enough.

I think one of the scariest things I can tell myself when I'm programming in Angular and something untoward happens is 'Wait... that's not in my code'. I've had it happen once, thankfully only once, where there was a typescript component, or it's html, that had something blown in it from the background and like a lot of things of that sort are it can be like grapping with a kind of anti-magic. I was telling my coworker who got me the job several years back that doing something new is building 80% of it from what you know and then stubbing your toes the rest of the way - especially for high liability apps with compliance concerns.

Another fun one that just took a while because it was constant experimenting - setting up an access/refresh token schema between .Net Core and Angular and getting everything I needed to run through .Net Core Identity on the back end. You'll find that in some scenarios there seems to just be no one talking about straight-forward implementations, whether StackOverflow or in the tutorials, you at least have some kind of starting point, you can maybe spend a day or two trying to Frankenstein a bunch of tutorials together just to get your groundwork laid (and being these are proprietary packages it's not about knowing or not knowing how to code - it's product knowledge). After that though it's on your determination to just hit it with a wrench until it works, and in that situation after I got a really good triage of what solutions didn't work I eventually had specific enough questions to find some more out-of-the-way discussions on tokens and principals that actually had something close enough for me to walk it in the rest of the way.

I had an experience as well with trying to connect an Angular app to Azure AD and Graph, lets just say trying to get my app white-listed was an adventure. Got great documentation at least on the angular packages from that exercise, thankfully it turned out we didn't need to go through Azure AD, but again that sort of thing and a lot of things CORS-related for major outfits seems a feather in the cap if you can nail it.

The next great thing I'll probably be doing in the coming months is learning implement webhooks, particularly between a local server and something like Stripe, Paypal, etc. , there's certain kind of reporting that can't just be pulled over the API (these reports take a couple minutes), I could stagger cron jobs to request, get the id, and try again but the webook way of having their server prompt mine with the data sounds better. I've already needed to implement SqlDependency and SignalR in my projects in a few places so this seems like the same concept just cross-server.

Overall though with this kind of coding, particularly if you don't have a team that can instruct you, yes thankfully there's a lot of online support for the relatively small stuff but for the bigger things eating a good bowl of concrete every now and then, or lots of it when you're doing all your R&D to get up and running, is pretty common.

There was a test set at ITT that was used to test junctor boards and switching matrices.  Every now and then, it would seize up and the screen would fill with random characters.  The operator would have to shut it down and restart it.  This was deemed not severe enough for intervention by the designer, and only because it happened no more than once per shift.

Then I was assigned to supervise that workstation.  The problem really annoyed me so I spent most of one lunch break to track it down.  The problem turned out to be a single 4k EEPROM (that's right ... a 4096 x 8-bit device) that when it ran for a while, it would get warm enough to flip a single bit, changing "CHR$(27)" to "CHR$927)" and crashing the program (that's right ... BASIC).

At first, my supervisor was ecstatic -- she hugged me and called me her hero.  The next day, she called me into her office to inform me that the senior engineer who designed the test set had filed a complaint against me for violating security protocols, and that if I ever did it again, I would be dismissed.

I quickly found another job and resigned.

Effing politics...

Thankfully at the current job none of my work enemies have been programmers, or at least not programmers good enough to be a threat.

Seems like a reliable ground rule though - if you don't have talent stab in the legs those who do so you can still win the race.

Back then, since personal computers were still a novelty, engineers were expected to program them, as well -- there were no dedicated programmers (at that place, anyway), just engineers.

But yeah, to this day, I believe that the senior engineer saw me as a threat to his uniqueness (a.k.a., job security), and acted to impugn my credibility to save his own.  If only he had shown respect for my 1337 H4X0R skilz, he would not have pwned me.

By the way, those "security protocols" I allegedly violated only required pressing Ctrl-C at the main menu.

Another really fun example of coding woes:

- You use async/await and promises in Angular to keep things happening in the right sequence.

- You use a try/catch/finally block the way you'd use it in most other contexts.

- You have an error occur in the try/catch block that completely gets ignored and goes right through.

- You have a client whose lost three customers because something they did cracked up at the terminal and it's a sales environment - any error is money lost.

- You go back on Google, look at the the tutorials, there's nothing wrong in what you wrote - some other process, probably another Async/Await happening at the same time, is changing the behavior - No tutorial for that problem.

- To actually fix the problem now you have to go to deeper layers and other modules, with a high likelihood of breaking it again somewhere else and causing a problem somewhere else with your 'fix' since it's already a tight area. Good likelihood no one wants to pay for the time it takes for this to be done right, which means it's mostly going to be volunteering your own free time.

Only solution - either beat yourself in the face with a brick until you fix the problem or the client will gladly beat you in the face with a brick because you're a screw up and you damaged their income.

Would it be your bosses fault at all for giving you so much work on such tight deadlines that something like this would bounce out somewhere or that you've been working well past your range of knowledge all the while doing that while the client, non-programmers, managed the project and constantly changed things to where the programming is tangled because of it? Well - that depends whether he's willing to admit it, whether you weren't already a big part of how he hasn't already been sued.


It's a good reminder to me too in the work world - you don't have to be incompetent in the work world to deserve an arse beating. Unlucky is plenty good enough.

^^

Also I did get it patched without having to take the whole system apart albeit it's a bit duct-taped, ie. I threw a BehaviorSubject in my error handling service and then threw that in the try catch to then trip a true/false and bypass the if statement which would kick the next process in. I think it's a bit tacky as a solution but when a try/catch fails outright, even throwing an error on certain conditions within it, that's just obnoxious.

I probably shouldn't be bringing this much shop talk in here but - it's a vent.

I hope so.

And I don't think that experts are 'better' than anyone else. Or even that scientists know everything about science.

But they have more expertise in their respective specific fields than other people do and it's healthy to acknowledge that.

[opinion=mine]

If everybody understood, respected, and appreciated what it takes to be a genuine "expert authority" on any given topic, we would not still be going through increases in coronavirus cases two weeks after every major event or holiday (i.e., Memorial Day, Independence Day, Labor Day, Hallowe'en, et cetera).

[/opinion]

Last edited by Fnord on 25 Nov 2020, 10:11 am, edited 1 time in total.

I don't blame the experts on that, I blame it on humans being game-theoretic apes. Actually caring about things that make sense is a sign of weakness.

On experts - just have to make sure that anything that starts looking like a Levitical priesthood to people has really tough internal standards, otherwise everyone's cousin wants to ride the gravy train or get power because they were just a bit more 'awesome' than the people around them.

The Druids I believe had initiations where if people wanted in they'd often not survive the tests, and they had pretty extreme penalties for internal infraction. We might have to get a bit of that back.

Yeah, waiting for a fix can be like sleep(∞); With opensource software I usually submit a bug report and then give up and work around it. On rare occasions I might know enough to hack it, or just want the fix really badly (as happened once with GCC, in a part of the optimization-selecting code that's full of bitwise operations used to cram multiple flags into one byte so that it could run on an old VAX, resulting in a lot of toe stubbing). But on the other extreme, one lab equipment vendor worked with me to set up a remote desktop session and teleconference with their US-based tech-rep and the Indian developer who wrote the code, and they had a fix less than 24 hours after my first call. The hardest part was convincing the tech-rep that I had a real bug rather than an IBCAK error, and after that he was apologetic and helpful.