LeonB

I wonder what the difference is? One (admittedly uninformed) hypothesis is that there might have been more detergent, and the failure was caused by detergent residue. If this was true, they could be (possibly) repaired by rinsing with fresh water to remove said residue and leaving to dry. (Lots of other possible hypotheses and confounding factors)

Ha, well said. Having both of these experiences makes one even more against the tyranny of monopolists.

This fails the asymmetry test. There are effectively infinite variations on any wrong argument, they don’t all need to be tested. There’s no progress gained by having to engage in a war of attrition.

Disney headquarters should be picketed for this, large scale boycotts etc are the only fair response.

In a sane world, companies who sell products to consumers should be terrified of ever being caught doing something as disgusting as this.

But our actual standards are far lower than we would like to admit.

Here’s a technological concept that deserves all the hype in the world and will never get it:

- reliability

I’ve got a small number of links to such things here — (which is how I could track down dogsheep quickly)

https://wiki.secretgeek.net/personal-data-liberation

HN user SimonW who created Datasette gave a talk in 2020 on “dogsheep” his tool for harvesting and processing personal data from a series of third parties.

https://simonwillison.net/2020/Nov/14/personal-data-warehous...

Here is more about dogsheep — (“ Dogsheep is a collection of tools for personal analytics using SQLite and Datasette.”)

https://dogsheep.github.io/

> So no such thing as a good or bad engineer? Just teams then?

Buddy I understood your original points — and once held them myself — but if this reply is how you construe what I’ve tried to share with you, you have not reciprocated with any genuine care in trying to understand the conversation I thought we were having.

Good luck!

I think that success isn’t from individual “great engineers” but from excellent teams and collaborations.

We over emphasise the myth of the solo genius, for example, as it fits neatly into “stories”.

There are many cases where the heroic genius “great engineer” seems to be the solution to all of the problems… until they get sick or fired and suddenly the remaining team becomes far more productive than they were before.

It’s a bit like in “moneyball” — how the talent scouts were looking for batsmen that could hit a home run, but the real value was in the batsmen who could consistently make it to first base.

Attributes like “personal motivation and curiosity” — are also filtered through the interviewer’s perception — they become: “personal motivation and curiosity in a form which I can immediately recognise because it fits the patterns I am predisposed to expect” - and this lead to very narrow selections. By looking for this trait (and believing that you can detect it), what other traits are you missing? (Hint: all of them)

Well said.

Approaching the challenge of looking for a job is similar to the psychology required by salespeople, who face many more “No” responses than “Yes”es.

On podcasts I’ve heard salespeople talking about the need to invert your thnking if looking at success. To treat every “no” as a win. Count the nos, focus on that. The inner game of sales requires different strategies than other parts of your working life.

It is as if, for the sake of professionalism, they deliberately inhabit an impenetrable optimism, but remain detached enough, at a deeper level, that the rejections are understood as just part of a game.

Easier said than done, of course… I wish you luck, and urge you to take one tiny step at a time, even without motivation, as motivation is something that builds up — “motive” being derived from the same roots as “motion” — as those tiny difficult steps at the start, create motion that brings about momentum and motivation all by itself.

I once held opinions like that, but overcame them long ago.

I came to realise that this kind of stereotype was effectively a narrow minded form of gate-keeping that contributed to the myopic tech-bro dystopia that’s been swallowing all that is good in this world.

Additionally — the original poster has been living through some very difficult times, it would be perfectly normal, and not a sign of job fitness, if motivation hit zero during a period like that.

I just urge them and others to ignore what you’ve said, and to look for a broader worldview.

Sheesh! Now I definitely won’t sleep, house as I am in this flimsy house, not in any way robust enough to withstand the inevitable rampaging herd.

Pretty much any human presented with a tiny slither of information immediately asks for and or invents a “narrative” to “make sense” of what occurred.

The less datapoints you have, the easier it is to make a line that fits.

We’re great at pretending to understand, masters at nodding wisely.

Unit tests, functional tests, automated CI/CD, etc all apply when building utilities or system software.

Things like the DORA metrics are very often applied to “things where if they break they break in a big way” - to help teams design toward having the confidence to deploy without causing outages and to have limited impact when something does fail, and faster recovery etc.

At the end of every trading day, news reporters confidently state the reason behind whatever stock rose or fell that day. They must be very wise as they don’t seem to interview anyone before making these proclamations.

Hmmm — isn’t it possible that too much awareness of our pending apocalyptic peril at the mercy of the Yellowstone Caldera is what’s arresting your slumbers in the first place?

Parsing iCal was far more performant than parsing JSON as your parser could simply start at the first byte, and follow the spec — whereas a JSON parser would first need to wait for ten years before JSON was invented.

In the Wild West things were easier —

“Meet me at high noon!”

Was never met with -

“High noon? What time zone?”

If I invite you (who lives in Spain, let’s say) to fly over and enjoy my New Year’s party (in New Zealand) it definitely is not going to occur at “midnight local time wherever you are” - Trust me.

(Actually there’s a famous missing person’s case related to a New Year’s party in New Zealand … I don’t think that timezones were part of what went wrong, but I can’t be sure.)

I’ve been thinking about this since writing the gp comment yesterday and quite like the anchor terminology.

Entity/object and “aggregate root” bring all sorts of complications/ambiguity.

The example you gave of a non-anchor (price was it?) was helpful to clarify.

Examples (and counter examples) are far easier for human brains to understand than “definitions”.

so often the example domain for these sorts of exercise is “a shopping cart website” —- and I find shopping websites such a poor example, because the specifics of how the shopping experience should work at a small Website are very custom to what is being sold, to whom, and why etc.

Other common domains when learning about databases

— “a book lending library” (I found this a good domain when I was learning, but people’s experiences of libraries are very different now…)

- a blog (posts, comments etc…) - but only fools like me write their own blog software now… (and or allow the public to comment? Yuck!)

I’ve written scripts that query outlook appointments and found that their handing of recurring appointments was very odd! Writing a query that simple asks “what am I doing today?” is far from a trivial exercise, as a consequence.

The choices and trade offs around storing every instance of a recurring appointment versus storing just the pattern plus the exceptions, has some pretty weird/nuanced implications. And I think the optimum approach really depends on the way I. Which the tool is used… which you don’t know until after the tool is used! (I guess that lends further proof that the most important aspect of software is that it’s open to being change in unexpected way… as any software worth writing will also need to be modified later.)

Cheers! Keep doing good work!

I found this to be a good introduction and a well-chosen domain to demonstrate modelling.

The term “anchor” feels kind of weird to me, but the explanation is so concrete/grounded (like an actual anchor) that I guess it works well enough.

The concept of defining the attributes via a question is solid, great way to get clarity quickly. Too often we jump to a minimal column/property name without defining what question we’re trying to answer, and thus not shaking loose any ambiguity in the mind of the customer(s).

It’s quite impressive really — crowdstrike were deploying a content update to all of their servers to warn them of the “nothing but nulls, anti-crowdstrike virus”

Their precognitive intelligence suggested that a world wide attack was only moments away. The same precognitive system showed that the virus was so totally incapacitating that the only safe response was to incapacitate the server.

Knowing that the virus was capable of taking down every crowdstrike server, they didn’t waste time trying it on a subset of servers.

When you know you know.

Programming “via” Visualization — doesn’t scale. Great for demos. Good in limited places.

Visualizations “of” a Program — quite useful. Note there lots of different ways to visualize the same program to emphasise / omit different details. The map is not the territory, all models are wrong etc.

I had to do a double take on this minor detail —

The current date is expressed as:

     12:07:2024 AD

I don’t think I’ve ever seen colons used as a date part separator, only as a time part separator (and they tend toward ambiguity even there).

And “AD” is generally superseded by “CE” now, isn’t it?

(I ruin everything by caring about the wrong details! It’s a great game. Try it! You’ll hate it.)

Slickrun on windows was pretty handy back in the day. It was made by Eric Lawrence who also made fiddler. I believe he was an MS Employee on IE, then moved to google to work on chrome and came back to Microsoft to work on Edge. Clever chap.

This works:

    Get-Item | % Name

There would still be some fraud, but since the prices of basic medical care would be considerably lower (as demonstrated everywhere else in the world) the amount of money made from fraud would be considerably smaller thus creating less incentives.

It depends. I don’t tend to end up with deep object graphs that need to be saved/ reloaded.

It might be that we serialize foo and foo has a list of references to its 3 children. The “parent” reference from the child back to foo is marked as do not serialize; an “after rehydration” function on foo could then set the value each child’s parent reference.

But more often — say baz bar and bam reference foo — the speed at which baz changes is different to the speed at which foo changes. The reference to foo from Baz is marked do not serialize. Baz also has a property indicating the ID of Baz. (For IStashy<K> - K is the type used for the keys, the IDs; it might be a string or an int or a guid, I tend to use string. All objects in the system have the same kind of ID, and it is unique per type.)

Generally if cyclic data structures are possible then some part of the cycle will be marked as no serializable and I’ll keep a key reference adjacent to it.

Situations that triggers huge cascading saves — they’re kind of an anti pattern for how I work. If one little change changes everything then perhaps it can be calculated on the fly from a pure function, not persisted at all— or perhaps there’s over-coupling etc.

(Blogpost with an implementation of IStashy is here — https://secretgeek.net/stashy_gist)

(I meant to respond to the gp comment here, soz. I agree with everything the parent comment says.)

> Presumably because loading will break?

I think the object will still load ok, I’m not sure if it would break because it’s been so long since I was in a scenario where I wanted to really delete a property. Normally when I make it obsolete there is also some new property or properties that have replaced it. When loading the object, if the (now obsolete) property is not null, I translate its value into the new property/ies (I.e., “migrate” it into the new properties), then null out the old property value, so that the migration only happens that one time.

I guess using something allegedly “simple”, over a long time, only appears simple because you will slowly internalise any idioms you’re using, and they don’t take much thought anymore.

Looking back — I’ve used this pattern for over 20 years, across various platforms. I’ve had a backing source that is anything from xml files to json to sqlite to in memory (for rapid tests) in a few languages. Things that seem natural or intuitive (to me) at this point are just habits that are rusted on, whether good or bad.

Sometimes I start building fast indexing systems on top of it, or archiving systems or record versioning… and the better tool would be to switch to a db or to a more full featured key value store. But it’s such a lot of fun!