Any and I mean any statistic someone throws at me I will try and dig in. And if I'm able to, I will usually find that something is very wrong somewhere. As in, the underlying data is usually just wrong, invalidating the whole thing or the data is reasonably sound but the person doing the analysis is making incorrect assumptions about parts of the data and then drawing incorrect conclusions.
It seems to be an ever-present trait of modern business. There is no rigor, probably partly because most business professionals have never learned how to properly approach and analyze data.
Can't tell you how many times I've seen product managers making decisions based on a few hundred analytics events, trying to glean insight where there is none.
What are you optimizing all that code for, it works doesnt it? Dont let perfect be the enemy of good. If it works 80% thats enough, just push it. What is technical debt?
If what you're saying 1) is true and 2) does matter in the success of a business, then wouldn't anyone be able to displace an incumbent trivially by applying a bit of rigor?
I think 1) holds (as my experience matches your cynicism :), but I have a feeling that data minded people tend to overestimate the importance of 2)...
In many experience, many of the statistics these people use doesn't matter in the success of a business --- they are vanity metrics. But people use statistics, and especially the wrong statistics, to pass their agenda. Regardless, it's important to fix the statistics.
Rigor helps for better insights about data. That can help for entrepreneurship.
What also can help for entrepreneurship is having a bias for action. So even if your insights are wrong, if you act and keep acting you will keep acting then you will partially shape reality to your will and bend to its will.
So there are certain forces where you can compensate for your lack of rigor.
The best companies have both of those things by their side.
I've frequently found, over a few decades, that numerical systems are cyclically 'corrected' until results and performance match prior expectations.
There are often more errors. Sometimes the actual results are wildly different in reality to what a model expects .. but the data treatment has been bug hunted until it does what was expected .. and then attention fades away.
This is, unfortunately, a feature of a lot of these systems. The sponsors don’t want truth, they want validation. Generative AI means there don’t even have to be data engineers in the mix to create fake numbers.
Don't get me wrong. I've been using Claude Code and Codex CLI for quite some times now and it's amazing what they can sometimes do. (I skipped the "Copilot" phase where AI was just a "better" auto-complete)
Emphasis on sometimes. And you really have to double check everything they do. So much.
And literally this week, Claude turned "dumb". Things I'd expect it to be able to do before, result in stuff I really just throw out the window. I thought I maybe started prompting differently or something so I tried multiple times on the same task. But no, it just went nowhere this week. Codex worked fine on the same problem but it tried to cheat real bad on the test cases. Luckily I caught it but otherwise the tests would've been completely useless. Essentially "always green".
And this is on the "pay-per-token" work account, so I can't simply explain it away with "they're saving on compute for free / bulk pay".
1. also helps you after the first 3-6 months. As in, you can't change the entire code base (if reasonably large). Not even with AI helping you with the tedious bits. Consistency is something that does have value, even if it's not global and even if the consistent thing is not how you would've done/called it. The more consistency you can get, the better, because it helps tremendously. Both you and also an AI. If things are named consistently it doesn't matter whether you call a potato a potato or a potahto. It just matters that you don't call it an orange half the time.
We have a relatively good code base in this regard for example. To find things, I literally just hit the shortcut to open file/class by name, start typing the camel case for what I need and I'm usually there. Like, if I need to know what exactly we do for writing the potahto to the database, I type PoRep and I'll probably see the PotatoRepositoryImpl and I'm where I need to be. Of course not everything is roses. I might want to know what the service layer for the potahto does and start typing PotSer and I find nothing, because half the domain objects call the service layer a service and the other half calls it manager. That's OK. That's called "local consistency" and it happens as a code base grows and ages and different people with different opinions build in it and don't know enough about the magic of consistency and think they know better but can't or don't want to change the existing code base. As long as it doesn't get out of hand, it's not a big deal and you can slowly converge.
2. This is such a big one, thank you! Too many people don't believe in Chesterton's fence. They know so much better! Rewrite everything! And it is OK and good to question why the fence is there! Nothing is worse than "we do it this way because we've always done it that way!".
But also, if you never question the fence's existence, you're stuck forever. This is an anecdote I found very good in this regard.
A group of scientists places five monkeys in a room with a ladder and a banana on top. When one monkey tries to reach the banana, all are sprayed with cold water. Eventually, all of them stop attempting to climb. The scientists then place a new monkey who knows nothing of the water incident. When the new monkey sees the banana and tries to climb, the others prevent them from reaching it. Nobody gets sprayed any longer. The scientists slowly replace any of the original monkeys that were actually sprayed with water with new ones. Eventually there are no monkeys left that experienced the spraying. Yet no monkey ever even tries to get the banana any more.
So, do challenge Chesterston's fence's existence! Try to find one of the monkeys that actually got sprayed with water, so that you may understand why the fence was there. Or in other words ask the other monkeys why the eff you can't go for the banana. And if nobody can tell you other than "coz we've never done it like that", then try it. For all you know, the pesky scientist with the hose is long gone!
I searched for the paper about the monkey experiment a few years ago.
I came to the conclusion that it was false, myth.
Anybody got a trustworthy reference?
I don't know of an actual paper either. It's rather just a really good anecdote that illustrates the point.
The first time I heard this was actually just in person from a trainer at work. He told this over like 10 minutes or even more as an engaging story. The monkeys went "Uuuuh banana!" each time. Until they didn't ;) That's essentially how it stuck in my mind. Through the Uuuuh banana! exclamation.
I wouldn't say more disturbing, really. But more "enlightening".
A shit umbrella is great to have if the alternative is a shit funnel. But how are you gonna appreciate the shit umbrella if it's pitch black, blocks everything at all times?
You're not gonna appreciate it. In fact, you might think some of the things your manager does are the "bad things", when in fact, it's just the umbrella bowing under all the shitload.
If the umbrella is (somewhat) transparent, you, as the manager, gain some legitimacy through transparency. You're no longer the manager that "sits around on his ass all day doing nothing". You're actually doing something for the team and they can "see" it, even though it doesn't affect them.
This reminds me of another recent comment in some other post, about doctors not diagnosing "hard to diagnose" things.
There are probably ("good") reasons for this. But your own persistence, and today the help of AI, can potentially help you. The problem with it is the same problem as previously: "charlatans". Just that today the charlatan and the savior are both one and the same: The AI.
I do recognize that most people probably can't tell one from the other. In both cases ;)
You'll find this in my post history a few times now but essentially: I was lethargic all the time, got migraine type headaches "randomly" a lot. Having the feeling I'd need to puke. One time I had to stop driving as it just got so bad. I suddenly was no longer able to tolerate alcohol either.
I went to multiple doctors, was sent to specialists, who all told me that they could maaaaaybe do test XYX but essentially: It wasn't a thing, I was crazy.
Through a lot of online research I "figured out" (and that's an over-statement) that it was something about the gut microbiome. Something to do with histamine. I tried a bunch of things, like I suspected it might be DAO (Di-Amino-Oxidase) insufficiency. I tried a bunch of probiotics, both the "heals all your stuff" and "you need to take a single strain or it won't work" type stuff. Including "just take Actimel". Actimel gave me headaches! Turns out one of the (prominent) strains in there makes histamine. Guess what, Alcohol, especially some, has histamines and your "hangover" is also essentially histamines (made worse by the dehydration). And guess what else, some foods, especially some I love, contain or break down into histamines.
So I figured that somehow it's all about histamines and how my current gut microbiome does not deal well with excess histamines (through whichever source). None of the doctors I went to believed this to be a "thing" nor did they want to do anything about it. Then I found a pro-biotic that actually helped. If you really want to check what I am taking, check the history. I'm not a marketing machine. What I do believe is that one particular bacterium helped, because it's the one thing that wasn't in any of the other ones I took: Bacillus subtilis.
A soil based bacterium, which in the olden times, you'd have gotten from slightly not well enough cleaned cabbage or whatever vegetable du jour you were eating. Essentially: if your toddler stuffs his face with a handful of dirt, that's one thing they'd be getting and it's for the better! I'm saying this, because the rest of the formulation was essentially the same as the others I tried.
I took three pills per day, breakfast, lunch and dinner. I felt like shit for two weeks, even getting headaches again. I stuck with it. After about two weeks I started feeling better. I think that's when my gut microbiome got "turned around". I was no longer lethargic and I could eat blue cheese and lasagna three days in a row with two glasses of red wine and not get a headache any longer! Those are all foods that contain or make lots of histamine. I still take one per day and I have no more issues.
But you gotta get to this, somehow, through all of the bullshit people that try to sell you their "miracle cure" stuff. And it's just as hard as trying to suss out where the AI is bullshitting you.
There was exactly a single doctor in my life, who I would consider good in that regard. I had already figured the above one out by that time but I was doing keto and it got all of my blood markers, except for cholesterol into normal again. She literally "googled" with me about keto a few times, did a blood test to confirm that I was in ketosis and in general was just awesome about this. She was notoriously difficult to book and later than any doctor for schedules appointments, but she took her time and even that would not really ever have been enough to suss out the stuff that I figured out through research myself if you ask me. While doctors are the "half gods in white", I think there's just way too much stuff and way too little time for them. It's like: All the bugs at your place of work. Now imagine you had exactly one doctor across a multitude of companies. Of course they only figure out the "common" ones ...
One challenge that may sound obvious.. is that super rare stuff gets seen super rarely, even by specalists.
In practice it means you often have to escalate from GP to local specialist to even more narrow specialist all the way to one of the regional big city specialist that almost exclusively get the weird cases.
This is because every hop is an increasingly narrow area of speciality.
Instead of just “cancer doctor” its the “GI cancer doctor” then its “GI cancer doctor of this particular organ” then its “an entire department of cancer doctors who work exclusively on this organ who will review the case together”, etc.
It's horses not zebras until it's actually a zebra and your life depends on it. I think those sorts of guidelines are useful in the general case. But many medical issues quickly move beyond the general case and need closer examination. Not sure how you do that effectively without wasting tons of money on folks with indigestion.
Interesting to read, thank you very much. Are you still eating ketogenic? The bacillus subtilis seems to metabolize glucose, so are yours still alive? And did you try other probiotica beforehand? I am having HIT and eating a mostly carnivore diet with mostly fresh/unfermented meat.
I no longer do keto no. I also started keto after I had gotten better already from the probiotics but not much. I'm not sure where you read about that subtilis can only live off of glucose. I'm having a hard time finding primary sources that actually talk about this but handily Google's "AI mode" also "answered" my search query and it does state it primarily thrives on glucose and sugars but can also break down and live off of proteins and fats.
FWIW, as I understand it, many probiotics aren't going to colonize on their own and "stick around" for a prolonged period of time when you stop taking them, even under good circumstances but you can't quote me on that so to speak. And in the past we would've gotten many of them through one way or another through our diet as well, just not through a probiotic but naturally.
I tried multiple probiotics. Both blends of multiple types as well as things like "Saccharomyces Boulardii"-only preparation. I don't recall all the exact ones I tried though.
depends on what `items` is, no? Is the `.Count` O(1)? Do you really need a variable or is it fine for the (JIT) compiler to take care of it? Is it O(n) and n is significant enough? Maybe you need a variable and spend time arguing about that name. Yes I chose this because almost everyone I know at least would argue you always have to create the variable (and then argue about the name) ;)
fussy about test naming
I get fussiness about test naming. I believe that a good test "name" should tell you enough for you to be able to "double check" the test setup as well as the assertions against the test name with some sort of "reasonable" knowledge of the code/problem domain.
As such both of those test names are really bad, because they can't tell anything at all about whether you're testing for the correct thing. How do I know that your assertions are actually asserting that it "works"?
Instead, I'd want a test named something like this (assuming that that's what this particular test is actually about - i.e. imagine this particular test in the context of a user defined search, where one of the options is that they can specify a project to search by and this particular test is about verifying that we check the permissions the user has for said project. There would be different tests for each of the relevant where clauses that specifying a project in the search params would entail and different tests again for each of the other user specifiable parameters that result in one or more where clauses to be generated):
Every single test case gives you the ability to specify both a good name and clear, concise test assertions. If I see anything but a bunch of assertions related to project permissions for the logged in user in this test, I will fight you tooth and nail on that test ;) I couldn't care less tho if you use camelCase or snake_case or whatever. I just had to choose something to post. I also couldn't care less if you had 17 different assertions in the test (we all know that "rule", right? I think the "test one thing" and "one assertion" is not about the actual number of "assert statements". People that think that, got the rule wrong. It's all about the "thing" the assertions test. If you have 17 assertions that are all relevant to testing the project permission in question then they're great and required to be there. If 1 is for asserting the project permissions and the other 16 are repeating all the other "generic assertions" we copy and pasted from previous tests, then they're not supposed to be there. I will reject such a PR every time.
It matters if there's a lot of churn or the test fails a lot but if its a test that I write and for whatever reason it never fails I think we've just wasted our time on being fussy.
I appreciate neither of those test names are great but it was just a strawman example to show the fussiness.
What I find the most "enlightening" and also frightening thing is that I see people that I've worked with for quite some time and who I respected for their knowledge and abilities have started spewing AI nonsense and are switching off their brains.
It's one thing to use AI like you might use a junior dev that does your bidding or rubber duck. It's a whole other ballgame, if you just copy and paste whatever it says as truth.
And regarding that it obviously doesn't apply to small fixes: Oh yes it does! So many times the AI has tried to "cheat" its way out of a situation it's not even funny any longer (compare with yesterday's post about Anthropic's original take home test in which they themselves warn you not to just use AI to solve this as it likes to try and cheat, like just enabling more than one core). It's done this enough times that sometimes I don't trust Claude with an answer I don't fully understand myself well enough yet and dismiss a correct assessment it made as "yet another piece of AI BS".
That's one of the issues with these if you ask me.
Either you're a hermit, that really can build that hermit cave in the mountains, far off and all the guns they're stockpiling won't really be used.
Or you're way too close to civilization coz you have an actual family and they'd never do / care about any of that "crazy stuff".
And if you're that close to civilization, it's all about who's got the larger stockpile and larger amount of armed thugs. Are you really gonna fight off 30 guys with AR-15s with a family of four, two of which are children to protect your stash of food and gas and generator(s)?
The only way your "prepping alone" is gonna help you is the hermit case, far far out of sight or if it's "not all that bad anyway".
Agreed. And if deletes are soft, you likely really just wanted a complete audit history of all updates too (at least that's for the cases I've been part of). And then performance _definitely_ would suffer if you don't have a separate audit/archive table for all of those.
I've seen a number of apps that require audit histories work on a basis where they are archived at a particular time, and that's when the deletes occurred and indexes fully rebuilt. This is typically scheduled during the least busy time of the year as it's rather IO intensive.
Oldest I've worked with was a project started in ~1991. I don't recall when they started keeping history and for how long and they might have trimmed history after some legal period that's shorter but, I worked on it ~15 years after that. And that's like what, 15,..., 20 years ago by now and I doubt they changed that part of the system. You've all likely bought products that were administered through this system.
FWIW, no "indexes fully rebuilt" upon "actual deletion" or anything like that. The regular tables were always just "current" tables. History was kept in archive tables that were always up-to-date via triggers. Essentially, current tables never suffered any performance issues and history was available whenever needed. If history access was needed for extensive querying, read replicas were able to provide this without any cost to the main database but if something required "up to the second" consistency, the historic tables were available on the main database of course with good performance (as you can tell from the timelines, this was pre-SSDs, so multi-path I/O over fibre was what they had at the time I worked with it with automatic hot-spare failover between database hosts - no clouds of any kind in sight). Replication was done through replicating the actual SQL queries modifying the data on each replica (multiple read replicas across the world) vs. replicating the data itself. Much speedier, so that the application itself was able to use read replicas around the globe, without requiring multi-master for consistency. Weekends used to "diff" in order to ensure there were no inconsistencies for whatever reason (as applying the modifying SQL queries to each replica does of course have the potential to have the data go out of sync - theoretically).
Any and I mean any statistic someone throws at me I will try and dig in. And if I'm able to, I will usually find that something is very wrong somewhere. As in, the underlying data is usually just wrong, invalidating the whole thing or the data is reasonably sound but the person doing the analysis is making incorrect assumptions about parts of the data and then drawing incorrect conclusions.
reply