Ah, I thought there would be a male bird involved still, but I guess that example just explains ovulation. Still quite optimistic that everyone shares the same understanding here, though…

Yeah, I virtually only use --force for moving tags around (which one could definitely argue isn’t really a thing you should be doing regularly either)…

Yeah, we always try to automate as much as possible with generic language build tooling and scripts, so that ideally the call in the runner is just a single command, which can also be triggered locally.

Unfortunately, if you want to be able to re-run intermediate steps, then you do need to inform the runner of what you’re doing and deal with the whole complexity of up-/downloading intermediate results.

--force-with-lease* 🙃

This post made me realize, I’ve only ever heard “the birds and the bees” referenced, but never actually how it’s applied during sex ed.

But uh, turns out this does not make any sense in that context either. It’s just two separate examples to explain sexuality, so bees pollinating flowers and birds laying eggs. They’re just used as examples, because they’re visible in nature and somewhat resemble the mechanics of sex.

https://en.wikipedia.org/wiki/The_birds_and_the_bees

My thinking was that bees are the ones that pollinate, so male.

But they certainly don’t pollinate birds, so I don’t know where that was going either. 🫠

Where I live, we have a food that’s basically flatbread with toppings. One of the popular toppings is apple slices and raisins, which looks just like an apple pie. And we do like to joke that pizza is simply the tomato variant of it, too. 🙃

I have caught myself genuinely thinking that management needs to unearth more budget, if they so desperately want us to use these AI tools, so that we can onboard another person to compensate for the productivity hit.

Unfortunately, they believe the opposite to be true, that we just need to use AI tools and then our productivity will be through the roof…

I have not looked into these myself yet, but Apertus is supposed to be fully open: https://programming.dev/post/36791696

And I recently heard of StarCoder, which was also said to be like that and which is optimized for coding assistance: https://github.com/bigcode-project/starcoder

I also always find that outsourcing is risky, whether it’s to other devs or to some AI, because it requires that you understand the problem in whole upfront. In 99% of cases, when I’m implementing something myself, I will run into some edge case I had not considered before and where an important decision has to be made. And well, a junior or LLM is unlikely to see all these edge cases and to make larger decisions, that might affect the whole codebase.

I can try to spend more time upfront to come up with all these corner cases without starting on the implementation, but that quickly stops being economic, because it takes me more time than when I can look at the code.

The crush probably had some incriminating evidence they needed to be disposed of for sure.

Yeah, but still not in agreement with the people who live/d there…

Hopefully, they live in the middle of nowhere or those kids are in for a rude awakening at midnight…

You know how the US likes to obliterate countries for oil? Yeah, our power companies like to do that for coal.

I really hate, how it will gladly generate dozens of lines of complex algorithms, when it doesn’t find the obvious solution right away. Particularly, because you will readily find colleagues that just do not care.

They probably stop reading the code in detail when it’s sufficiently long enough. And when you tell them that what they’ve checked in is terrible and absolutely unreadable, they don’t feel responsible for it either, because the AI generated it.

You often just want to go with what’s popular, since hardware vendors will only provide APIs for select languages.

Well, and depending on the field, you may need to get certifications for your toolchain and such, so then you have to use what’s popular.

In my corner of the embedded world, it feels like everyone is practically jumping to integrate Rust. In the sense that vendors which haven’t had to innovate for 10+ years will suddenly publish a Rust API out of the blue. And I’m saying “out of the blue”, but I do also regularly hear from other devs, that they’ve been pestering the vendors to provide a Rust API or even started writing own wrappers for their C APIs.

And while it’s certainly a factor that Rust is good, in my experience they generally just want to get away from C. Even our management is well aware that C is a liability.

I guess, I should add that while I say “jumping”, this is the embedded world where everything moves extremely slowly, so we’re talking about a multi-year jump. In our field, you need to get certifications for your toolchain and code quality, for example, so lots of work is necessary to formalize all of that.

Yeah, particularly the broadcasting really irks me.
That is an opinion you can hold for yourself and then make compromises as you encounter reality. I do expect programmers to hold strong opinions.

But when you broadcast it, you strip yourself of the option to make compromises. You’re just saying something which is going to be wrong in one way or another in most situations. I do expect programmers to be smarter than that.

I mean, for me, it’s also mostly a matter of us doing embedded(-adjacent) software dev. So far, my company would hardly ever choose one stack over another for performance/efficiency reasons. But yeah, maybe that is going to change in the future.

Large shared codebases never reflect a single design, but are always in some intermediate state between different software designs. How the codebase will hang together after an individual change is thus way more important than what ideal “north star” you’re driving towards.

Yeah, learned this the hard way. Came up with an architecture to strive for 1½ years ago. We shipped the last remaining refactorings two weeks ago. It has been a ride. Mostly a ride of perpetually being low-priority, because refactorings always are.

In retrospect, it would’ve likely been better to go for a half-assed architecture that requires less of a diff, while still enabling us to ship similar features. It’s not like the new architecture is a flawless fit either, after 1½ years of evolving requirements.

And ultimately, architecture needs to serve the team. What does not serve the team is 1½ years of architectural limbo.