joshAg

You're right that as a person moves into management/staff+ that individual details matter less for them, because they begin to deal at a more strategic or operational level, but someone still needs to obsess over the small details (to make things easier, let's assume we're only talking about the details that actually matter and that there's broad agreement what that set is). It's not that those details stop mattering to them, it's that they have to depend on the assumption/promise that someone else is going to mind those details for them, so that they can work on things with a broader perspective.

The problem comes when no one is actually minding those details anymore. If those details aren't actually minded, then the work at the higher levels will be much less useful and effective, and in the worst cases won't matter at all.

It didn't seem like it, because section 2 directly discusses the issue you raised and why individuals aren't in a position to adequately prevent deskilling on by themselves. OK, you disagree with it, but you don't even engage with the actual argument it makes.

I don't personally like LLMs for research assistance (yet?) because i can't get over the hallucinating or rather, waste too much time validating that it's not currently overcast when they tell me the sky is in fact blue.

But, especially as code gets flung over the wall faster and with less care, I do think they are getting to be pretty great at reviewing code for specific things that a linter can't easily catch and for looking for security, implementation, and architectural flaws before I have to look for them. A couple examples of what i mean: 'does the code use knex.raw with a template literal?', 'does the code do n+1 db lookups instead of something better?' 'do all the added/modified tests follow the test case template defined here?'

> According to the empirical literature on deskilling, automation bias, and skill decay, many professionals rely on artificial intelligence much more than is necessary when it is available, and the effects of such overreliance on skill decay are unlikely to be entirely understood by the professionals themselves. I argue that this – what I call the insidious nature of deskilling – supports a normative view, according to which the responsibility for tackling deskilling should not be ascribed to the individual professional but the risks of professional deskilling should be tackled by the professional community instead. Mitigating the risks of deskilling should start from an intra-field analysis of the core skills of the profession that should not be outsourced to artificial intelligence. Then, the individual professional would not be left alone to determine how and when to prevent deskilling during the adoption of artificial intelligence within her profession.

You're lucky. Every single person (n of around 10) I've been unlucky enough to review code for lost between 0.5 and 3 promotion levels of competence when they started using LLM code generation, and it's been worse for the better programmers because they have more capacity to lose skills.

My personal "favorite" was when the lead engineer who onboarded me half a decade prior forgot the written policy he'd put in place of "no raw js dates. use this library for everything date related instead" and sent up an MR that not only used javascript dates, but did complex operations on them (incorrectly at that, because it didn't account for timezones, daylight saving, years that had a leap day, and months that weren't 30 days).

From what I can tell, it's the exact same reason people drive faster than is prudent or use their cellphone while driving. It feels safe and good right up until it isn't and you crash. And because most places don't have anywhere close to adequate specification detail, test coverage, or review coverage, the broken bits aren't even noticed until much later.

> But there was never a general principle about scale and automation articulated in the Constitution because it just wasn't a thing to worry about in the 1700s.

> We're left to hope that courts agree that just because something is okay for one police officer in one place to do, that doesn't mean the police department can perform that same task a thousand times in a thousand places with a thousand machines and still have it be okay.

There are multiple court cases that have done this exactly this. Carpenter v. United States and Chatrie v. United States are the ones you want.

This doesn't follow. We've had code as trusted as that for _decades_. Common criteria and EAL was certified at the end of the 20th century. Before that there was the rainbow series in the US dating back to the 1980s [1].

It's absolutely cool to see this sort of validation process get cheaper and easier, but it means nothing if no one cares enough to do it. EAL1 certification can be as cheap as a beefy server, but it's not commonly done because effectively no one cares.

As microsoft learned with the zune just because it's cheaper or better at the same price doesn't mean anyone will use it. Culturally, we have to make the effort of verifying code worth it.

[1]: https://en.wikipedia.org/wiki/Rainbow_Series

Lemon, it's wendesday

those are ada. Don't worry, they'll forget about ada until the defense contractors pay them to remember

Unless the scantron corporation is so antisemitic they invented a time machine to participate in world war 2, I think you mean IBM.

Think of it like a trip.

When you're learning/internalizing existing knowledge, you tread a defined path skipping unnecessary stops and diversion and heading instead directly to the destination. The destination, not the journey, is the point.

When you're discovering new knowledge in the form of proving/disproving, there's no defined path to follow, so there can be quite a bit of backtracking and diversions and detours into other areas you weren't planning on going initially and while there might be some well-defined paths to follow, you might have to cut your own path through uncharted desert or jungle.

All those diversions and detours make the journey just as if not more important than the destination because they create new destinations of their own for future travel that would not have been spotted or noticed for a while longer (if ever) otherwise.

So to bring it back to math, transitioning from having to develop proofs for theorems to validating/learning extant proofs completely changes the scope of future discovery. Everyone will tread the exact same path to a proof/theorem and then stand in the same place to look for future destinations and then use AI to build them a path to that new destination and then everyone will follow the same path to the new destination and repeat the process, so the chances of finding something curious along the way plummets. And something curious could be an entirely new field of math, or maybe just a new problem that isn't relevant to the intended destination but gives a view of many new never before seen destinations for future trips.

As much as it sucks for the ecosystem that's built itself up around the world wide web, good ad blockers and fingerprinting protection are as important as firewalls and antiviruses now. There's no more babies in this fetid bathwater.

cool. I don't want a crime-free society. It's not that I want crime, it's that at a certain point I'd rather allocate government attention/money/time at issues other than crime because the benefit to that other thing is greater than getting crime asymptotically closer to 0.

Mocks/stubs definitely have a smell to them, but especially if you want to do more than just unit tests can be necessary. I've found that setting up the mainline architecture so that components that are allowed to be mocked have a single access path in the code makes it easy to mock at a level low enough that the only thing being mocked is that component and then preemptively building out those mocks into the test framework works decently well. For me, 3rd party services are usually fine to mock, but things like DBs and redis are usually not. I'd rather spend the time to make a test container the devs can run locally so that they can't skip over checks/constraints and the integrations with services/components we have full control over.

That way you can tell at a glance of the test file change just how bad it is. Seeing new raw mocks (eg sinon in the test file at all) instead of the existing mocks is an instant no, and seeing an existing mock getting added requires at least investigation for necessity.

It has the same failure mode as dealing with TDD by a human engineer, which includes things like mocking the function under test in the test and then testing the mock, asserting only things that aren't actually exercised by the function under test (like asserting the initial user ID is the same as the final user ID for a function that changes name of a group), not validating side effect behavior (or lack thereof) for a function that's only purpose is the side effect (like appending a log line to a log file), and more!

What changes with TDD is that the important part of the review moves from the mainline code to all the TDD tests and the coverage, and you also need to see a test run from before the code changes with all the new/updated TDD tests failing in addition to just a test run after the changes with all the (at least) new/updated TDD tests passing.

may the Sun never set

That Rizzo/Kristol quote hasn't been borne out in studies [1][2], so it's not exactly a great place to start from (ps: as a data point of 1 my car was stolen out of my apartment's gated garage and more cameras would have been completely useless). Extending it to flock is even more erroneous, because it still requires the police/government to actually act on that data. And that's before considering all the privacy issues with storing historical data and the lowering of resources required for tracking someone, which i think are much more important.

But I really want to focus on the idea that more cameras will make the crime stop, because that is especially fallacious. It won't. Not by itself. What will make crime stop is government/community intervention. We could get into a whole broken window vs enhancing economic opportunity vs early targeted intervention approach debate, but the specific type of intervention isn't relevant to my point (so long as it's effective), which is that more data is only useful it it's actually used and not just stored in a warehouse without ever being looked at.

Let me give you more details from the car theft i mentioned before of my car getting stolen in 2020/2021 in San Francisco from of my gated (and security camera-ed) apartment garage.

The car was taken a few days before July 4th. Since I work from home, I didn't notice until I went to use it on the 4th. I immediately reported it to police and was able to use the police report to get the relevant security camera feeds from the apartment. The week before American Thanksgiving (about 4 months later) I get a call from the impound lot: "we've just received my car at the impound lot. You can come get it." That's when the happy narrative unraveled, and I learned what actually happened.

My car got towed up for blocking a driveway more than a day before i even noticed it was missing. When it arrived at the impound lot they noted that it had a license plate for the wrong type of vehicle that had separately already been reported as stolen (same make but a 10 year newer model and a different color). Even though the system flagged the plate as stolen and for the wrong vehicle the VIN was never scanned. I know the VIN was never scanned because there's systems constantly checking impounded car VINs and licenses against all the open stolen car cases, and separate systems that should notify owners when they call in to see if their car was towed/impounded. My report of the stolen car from july 4th should have immediately triggered a match. Instead the car sat in impound lots until they were ready to auction it off, because it was only ever recorded with the stolen license plate. It actually worse than just that one error because a month later (and after the car was reported as stolen) they moved it from the first impound lot to their long term storage lot, so in total they didn't scan the VIN 3 separate times (enter impound lot, exit impound lot, enter long term storage impound lot) even when the system immediately warned them the plate didn't match the car. In order to auction it off they need to get a clean title, which caused them to finally run the actual VIN for the car and not just the stolen license plate. The cross-check system was finally able to work, and they immediately notified me based on the open stolen car report. All this got reconstructed for me because they had to figure out what happened as part refunding the over $10,000 of impound lot fees that had accrued, since they aren't allowed to charge for tows/impoundment if the vehicle is reported as stolen in a timely manner.

Flock provides absolutely nothing that SFPD didn't already have access to while was car was in their possession. When my car got towed for blocking a driveway and when it entered the impound lot their existing systems reported that the license plate was incorrect for the car which should have triggered scanning the VIN (even without a theft report yet, if they had scanned the VIN then it would have triggered a notice to the registered owner). When the car moved from the impound lot to long term impound lot the system again reported that the license plate was stolen and incorrect for the car and at this point scanning the VIN would have alerted them to the open car theft report. All their fancy cross-checking systems failed because SFPD employees were too lazy or overworked or apathetic to follow policy to scan the VIN of the vehicle until they absolutely had to scan it.

[1]: https://www.researchgate.net/publication/233614385_A_Liberal... [2]: https://journals.sagepub.com/doi/10.1177/1462474508101490

i care

> I love alternatives to the big players but why is everything written in TypeScript or Python and takes up a gigabyte of ram.

Same reason everything's an electron app now. First mover matters to the makers and to the consumers more than performance and attention to those details.

This is almost the same as saying "The problem is not the fentanyl, but that everyone keeps getting addicted or dying." In a very literal sense, yes, absolutely. There is a way to safely use fentanyl. But from a holistic point of view, the way to do so is so specific (ie multiple medical professionals prescribing and possibly even administering and monitoring vitals afterwards) and limited that for the general public is much more useful to just say "It's unsafe to use fentanyl unless following instructions from your medical provider." There's absolutely a way to use AI for coding that doesn't result in not actually knowing about the produced code, but it's so damn hard to get that right and you won't even realize you've fallen away from that knowledge until it's too late.

The point about PMs is I think illustrative of this issue. Yes, great PMs who actually understand the product they want to build and can then turn that into something using engineering teams as a black box system exist. But by and large, no they don't. A massive part of why waterfall fell out of fashion is because it turns out most orgs don't have and can't find PMs/PM adjacent people who can build that knowledge, and you can see how agile attempts to correct for this by turning a pipeline into an OODA loop. If you can prevent pipeline flushes, it will beat that OODA loop, but it turns out as an industry we can't actually prevent enough pipeline flushes for that to be the case and we can (for the most part) use that OODA loop to eventually iterate into something a paying customer might give us money for.

Part of the issue is that we're treating the AI like it's just another compiler or static code generator. It's not. The reason they're not is because they require a complete specification of what to output, ie the code. That level of specificity is what allows engineers to mostly stop caring about the assembler and just stay in their higher level code (the main exception being extremely hot loops in places too complex for the compiler to optimize well) and legitimately be able to say they understand the code without ever looking at the compiler/linker output. The entire point of AI for code generation is taking an incomplete specification and turning it into a completed one. If you review and understand every line of output the way almost no one did even before AI was a thing, then you're not going to fall into the trap of not knowing anything about your system anymore. But at the same time, you're not really going to get much benefit from AI either, because you're just replacing time spent coding with time spent reviewing code. It might even take you longer to review than it would to just code it yourself (i think every senior engineer who's mentored a junior dev knows this exact feeling).

To actually get the benefit from AI you have to let go of looking at the code output at all, because looking at that output is the slow part and because just looking and reviewing still won't give you the same knowledge as actually implementing. The passenger aviation industry handles the second issue by preferring/requiring manual control in critical areas (takeoffs and landing) and using simulators to extensively train for manual recovery outside of the abilities of autopilot. For developers the second bit is actually why reviewing AI output is a fool's errand - it will give you the false confidence in your understanding of the system. That doesn't mean we have to embrace vibe-coding or accept slop. It means changing the engineering process from one that deals with a deterministic system to a stochastic one. As an aside, I think this is why upper level managers and executive are leaning into AI code generation so hard - engineering was already a stochastic black box system to them.

That solution already exists actually. You buy a ticket/seat for the infant and use an FAA approved carrier. For example, the nuna pipa rx is FAA approved for this use.

It's not a popular choice because you have to pay full price for the seat, so lap-carrying the baby can save quite a bit of money. Once the baby is 2, you can no longer lap carry them, so that option goes away. There's FAA approved options for small children for whom the lap belt would be inappropriate that are different from the infant seats.

They don't mean ethically. They mean the republicans are the ones in power right now, so going to them is going to be more effective at getting the changes they want than going to democrats.

Because that's how corruption and graft works in the US. Donating to political campaigns doesn't count as bribery. The donation is what gets them access to the candidate, so instead of writing a letter or calling their office you can have 30 seconds to a few minutes of their time at an election campaign fundraising dinner or over a phone call where they want to thank their donors during which you can press them to support whatever you personally want.

They're giving them money in exchange for the opportunity to try to convince the candidate to support what they want.

both. freebsd has init scripts. ubuntu has systemd.

this guide should help make it less likely for sshd or your login shell to get killed: https://ianlpaterson.com/blog/oom-lockout-ssh-survival-harde...

can't believe i forgot to mention them! Updating the parent for visibility

You're right. I'm glad the very next sentence in my comment landed.

The problem with turning it off is that the system and applications have been architected assuming that it will be on, so things like fork/execing a memory heavy processes or allocating memory inside a cgroup (which still pretends overcommit is enabled and there's still no way to disable that assumption) that used to work fine might break with no good way to get them to work again. This comment (and siblings) have more specifics: https://news.ycombinator.com/item?id=27794237#27795199

the system will kill whatever it damn well pleases. You can tune it with priorities to ask it to try to not kill that, and once it kills your sshd once, you'll probably configure it to exempt sshd from being OOM killed at all. That doesn't fix the memory pressure or hanging or stalling, but you'll at least be able to log into the box still instead of dragging out a serial cable.

That's what's breaking the system and causing freezes. You can tune it a bit to minimize when it happens, but not get rid of the issue entirely.

Don't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15

It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind, so your experience might not be as good as you were hoping for.

Making a massive swap space helps a little bit. It's better to just never let your actual memory usage go above 85% to 90%. It's fine to go above if you're trying to optimize a server with a specific set of processes to wring every last bit of efficiency out of it, but not for general desktop computing.

If it really bothers you OpenBSD doesn't allow overcommit at all and Windows handles this situation much more gracefully, so WSL is an option too. If you don't mind Oracle (i do), solaris also doesn't allow overcommit.

Likewise, major technical and security incidents increasing 40% is a loss, and the amount of time employees spent firefighting them rising 70% is a loss.