diatone

It’s a classic failure mode of the software engineer to decide to change something to be “faster,” before even checking to see if and when performance could become a problem.

I personally bucket this skill under napkin math and it is extremely good at guiding technical choices (YAGNI etc)

Given the volume of bots they tend to be remarkably good at detecting bots

source: I work in a team that uses this kind of bot detection and yes, it works. And yes we do our best to keep false positives down

Bingo, if the meeting is geared for openness but people aren’t open, now you’ve got conflict. Of course if people aren’t open you might run into trouble anyway but there’s a grey area there

Ahh, it gets really interesting when you read code that does have named variables… and they’re misleading.

A strength of functional idioms is that they expose the structure of the code in a way that a name - even a well chosen name - can only hope to achieve. Often, succinctly and comprehensively. At that point you stop caring so much about variable names. They’re still there but you need them less

That’s odd, unlike the USA, Australia is in fact a country the size of a continent…

Yep this reads like someone who tricked out their car, blows out the clutch because it has too much horsepower, then starts pining for the days when they didn’t need a double clutch. You never needed a double clutch!

As an aside I’m surprised that people struggle with vendor management and config management for neovim. Like are people picking unstable packages, or is their config wired up in a super brittle way? If you’re gonna invest in your own tooling, surely it’s your job to set it up to be stable over $TIMEFRAME ? Speaking as someone who’s used pretty much the same Neovim config for a few years with maybe half a day messing with it since setting it up

You’re not going to like this but: it’s a matter of perspective. You’re right and wrong at the same time. Call that classist if you want

How long are these Q&A sessions, would you say the work of ICs getting blocked isn’t worth having the manager be able to eg: advocate for that work upwards?

It depends!

I’m sure you mean well but reading GP’s post I’m convinced that the laziest and least trustworthy language to use is actually, “you’re sloppy.”

Good idea to think in systems and figure out how to lift the quality of the team but it’s okay to give direct feedback. Especially if the feedback is like GP’s in that it kicks off a constructive conversation, which iiuc is exactly what your final sentence there is waxing on about…

Edit; to be clear I’m suggesting to not aim to avoid conflict. Certainly don’t stoke it for no reason but there is a healthy kind of conflict and how it is engaged with, which builds trust, deepens human relationships, and leads to growth for everyone involved. Psychological safety etc

Not exactly a watertight metaphor as https://en.m.wikipedia.org/wiki/Hypochondriasis and anxiety exist, but I certainly agree that it’s possible to lie or mislead with statistics.

It’s interesting in this example that the docs try to show that a for loop is useful, when there’s already an idiomatic approach here:

``` const result = items.map( i => i.length ? i.toUpperCase() : ‘<empty>’) ```

I think things get interesting here when different kinds of iterators come into play (eg generators, async-await for loops, non-array iterables). Shame the landing page doesn’t touch on that at all.

Hamilton Helmer describes a moat as "persistent differential returns." Or in other words, it's something that lets you keep making more money than your competition. There are many kinds of moats but they all end up giving you that outcome.

This website is a fantastic resource: https://7powers.com/

Not true; UX designers typically are responsible for advocating for a robust, intuitive experience for users. The fact that kernel updates don’t have a user interface doesn’t make them exempt from asking the simple question: how will this affect users? And the subsequent question: is there a chance that deploying this eviscerates the user experience?

Granted, a company that isn’t focused on the user experience as much as it is on other things might not prioritise this as much in the first place.

To adjust an old joke about economics:

“Two open source maintainers are walking along the street when one says:

Look! A repo exposing an API allowing unprivileged deletion of users!

The other replied: that vulnerability clearly cannot be real, as someone would have fixed it already.”

Good idea, generalising: it’s sampling mappings from arbitrary domains to a binary range (the message appears, the message does not appear). This gets more complicated when your range isn’t binary but the underlying intuition, to take an informed statistical approach, is a necessary evil for tests to keep pace with a program as its complexity grows.

Just like many other industries. I recently learned about inspectors who sample cacao beans at the warehouse for the many ways they can go wrong before being processed.

As someone who really appreciates strong examples to motivate learning generalised approaches to work, a variation of this article could be a great motivation to introduce people to parameter based testing, or (closely related) fuzzing.

> There is definitely value in endurance. Examples abound: whether history, religion, etc.

This is spurious. What about history or religion shows that for profit companies should last a long time?

Or they’re successfully excluding you from a target audience due to lack of fit, saving money. Everyone wins

> I find it impossible to believe that some prefer the imperative loop/conditional nesting approach.

Yeah, there’s your problem. This is in fact possible!

Gamblers fallacy

The irony here is that there are many domains using statistical methods, that bound the complexity and failure modes of statistical methods successfully. A lot of people struggle with statistics but in domains where the glove fits I think AI will slot in all across the stack really nicely.

Ehhh it’s a spectrum. First you innovate, then you commercialise. Even Google took a few years to successfully monetise and they weren’t the first mover in web search. LLMs have been around for, what, coming up on three years? Probably two to four more years to see results.

Exactly right. I’m not against competitor analysis here. But let’s at least compare against a basket of structurally similar offerings instead of cherry picking companies whose rake happens to be an order of magnitude lower in percentage terms.

My point, which hasn’t really been addressed, is that “more” isn’t a meaningful term when comparing card networks and software app stores, because the markets are structurally different.

Apples to oranges. Card networks have more than three stakeholders to work with per transaction, apply fees indiscriminately from milk to digital music subscriptions, and operate at truly staggering volumes.

I’ve certainly had off days reviewing someone’s work and only realised certain feedback later. If I happened to surface that in a meeting with others, and got labeled a sociopath for it, I’d be concerned for sure.

I can’t speak to your personal situation or experience, but it’s important to caution against labelling people sociopaths because there are many variations of this scenario where that’s simply not the case. It can and will damage relationships.

Great book recommendation that covers this topic and many more like it: Turn the Ship Around, by David Marquet. Highly influential for me when I started managing (and remains highly influential!)

https://davidmarquet.com/turn-the-ship-around-book/

Be careful not to burn bridges so quickly.

This isn’t particularly helpful advice in domains where unknown unknowns really do appear. Not everything can be surfaced at design time. Having said that, design time is the perfect time to align on rules of engagement for surfacing and managing unknown unknowns.

It’s also possible that it occurs in genuine miscommunications. It happened to me two weeks ago when my team lead had a different interpretation to a doc I wrote than what I intended. Shit happens. There are mechanisms a team can put in place to mitigate these eg: forcing user stories to be clearly enumerated and matched to parts of the design; third party review; definitions and glossaries; office hours for document review. But it does happen.

If this hypothetical scenario comes up with genuinely avoidable issues, is not due to miscommunication, then this seems like a culture problem. If a person’s approval was explicitly requested, given, and rescinded for political or personal reasons, yes that’s when management needs to step in and navigate the team out of those fucked up dynamics.

Yep delegation works. It works especially well when it’s matched to the scope the person is capable of exercising competently at, and when the boundaries and context of delegation is crystal clear. I’ve seen mismatches on both sides fail - too little context, employee drifts off into niche useless work (eg: green light to rabbit hole on impactless pet project) or lacks the tools available to succeed (eg: missing stakeholder or path to achieve traction). Too few boundaries, employee goes for grand ambitious changes and gets upset when their expectations don’t match reality (because they weren’t realistically set by the manager).

Agree, there are pointer-centric patterns of computer use. Usually visual things: art, design, some CAD, marketing, and of course the GUI patterns of personal computer use that most people have been taught