Yeah. Building something and solving your gaps yourself is much better for learning than following a walkthrough.

A walkthrough can be effective onboarding if you’re already familiar with the concepts. Otherwise, it takes the right kind of learning mindset to effectively take away results; not just following along, but internalizing the concepts and constructs.

For beginners, both the language and the concepts are new. Repetition/Multiple occasions help with internalizing.

Zig compiler project is about 600,000 lines of code - roughly the same size as Bun before the rewrite, and I’m clocking 16s to build from scratch with a clean cache, followed by 90ms for each subsequent edit with incremental compilation enabled.

That’s impressive compilation performance. And so most certainly when contrasting it to Rust.

Brb, I am rewriting everything in Zig.

Does Deno fit your needs? It is also a drop-in replacement to a large degree, but is somewhat focused on improving the related tooling environment.

I’m not very involved in the (non-browser) JS ecosystem, but it’s my tool of choice.

Usually, when CI fails, it’s a flaky CI failure or that I have in fact not run it locally.

I guess some context is missing. My build flow seems much simpler. I check the CI steps overview and step log, and then I know what’s wrong. That doesn’t take 20 min. More like ~3 min.

At work, we use Jenkins and the runners are owned infrastructure. If I debug what goes wrong in the CI environment, I go into the pipeline definition, and do the calls locally, just like that, on the command line. No need for complicated environment replication beyond that. dotnet restore, dotnet build --no-restore, dotnet package --no-build, dotnet test --no-build, etc.

If it’s not CI specific, issues show up in the normal local tooling without special env prep.

How long did it take for a [fresh] compile?

Did they not add their thoughts into the commit descriptions?

Something helpful like “I have no idea why this works”

They made the lib example, and it’s the same there. We have certain expectations on interfaces and we have to assess necessity and risk during onboarding and when upgrading versions.

😏

They’re making good, correct arguments, but by not acknowledging and valuing understanding [partials of] your codebase, it ultimately (subjectively) reads like “too far in that direction”. Maybe it makes more sense in a big enterprise setting, but I think we’re talking about software development in general.

Like many software tools, LLMs are a double-edged sword: they make it harder to construct a detailed mental theory of the software, but they allow you to build a partial theory quickly and they can help you leverage that partial theory more effectively. This is a complex tradeoff that I’m still thinking about.

Building a theory model is simple, verifying it is not. If possible, assumption verification, automated tests verifying assumptions, manual review of coverate of tests vs assumptions and cross references are important to validate theories.

In the end, it’s always a weighing of effort, necessity, and more, and weighing factors depend on the environment.

Other people being allowed to write code in your codebase

I work in a small team but on a big and long-running project [ecosystem]. I’m fine with people doing stuff without me in the loop as long as I can depend on them for care, due diligence, and understanding. Even then, I often find it valuable for me and the project to be in the loop to be able to raise concerns, ensure quality and longlevity/maintainability.

I struggle with one colleague in particular, which I can not be sure to be even surface-level correct (they often are, but at times, repeated absolutely obvious wrongdoings), who does not document their understandings intentions or thoughts, and does not seek out understanding from sources or colleagues. Ultimately, we as a team and I personally are responsible for the customer’s product, so this situations is quite frustrating and tense to navigate with some inefficient reviews, concerns, and my other [more productive] tasks.

I don’t think waving away other colleagues’ contributions is constructive and productive for a project and it’s health, but I do try to move myself away from owning or being involved in everything, even at the cost of quality, certainty, and risk.

I would assume even for big teams that split into local and wider teams, it’s a concern you should think about and make conscious decisions about. Teams should own their products, they have to navigate and nurture how they work together, and have to continuously weigh effort and consequence.

they pay you money to adopt their set of engineering values
[…] sometimes you have to write slow code at your job […] Maintaining a theory of the codebase is the same kind of thing.

They certainly don’t pay me to only adapt to their engineering values. This is probably again about huge companies vs smaller teams. For me, they pay me to bring my engineering values. As a lead, I ensure we have, adjust, and follow engineering values.

I always have music running when I’m not in meetings. Genres and platforms change, in phases. I listen to diverse genres.

• https://soundcloud.com/kissaki
• https://stream.nightride.fm/chillsynth.mp3
• radio
• when on my private PC, my personal local music library with diverse music

I’m not sure listing genres even makes sense for me. Deep house, chillhop, synthwave, hiphop, pop, classics, japanese, …

My worst experiences (from the top of my head):

Project participates in Hacktoberfest but doesn’t review nor label-acknowledge PRs.

Project takes PR commits and replaces author when “merging” into main.

Invest a day into a 16 months open thing, create the PR, maintainer a few hours later: “I just implemented this”. Probably an unfortunate coincidence, but feels like sabotage.

Contributing to GitLab, even simple docs, became inaccessible, infeasible. When I see typos or link markup mistakes in docs I create a PR. GitLab has a whole, elaborate onboarding process with guides, ticket creation, talking about yourself, waiting for approval, etc. Then you try to edit and by necessity fork the GitLab repo, but it reaches free account repo limits which produces unclear, confusing, inaccessible issues while trying to make and submit the changes. So you learn about the separate reduced repo you can actually fork and work and submit on. So you do that. Elaborate PR description template, which I remove, because it’s a simple typo/syntax fix. They ask for more or sth. I quit; I close the MR and leave.

If it were critical I would set up an “email me on script run failure” wrap around the individual cron jobs. Simple exit code check, potentially with console output as email body is simple and useful.

I guess I don’t have many hosted side projects. Those I do, I don’t put them on separate domains. I doubt people use or care, so I haven’t added monitoring for individual projects specifically. I guess I could and should do that now that I established my own online monitoring without third-party free tier limitations.

I use Red Sift (free) for certificate monitoring, since Let’s Encrypt dropped expiry warning notifications. Given it’s automated, it’s never been an issue for my self-managed projects, though.

For is-online/is-reachable monitoring, after free services I used became more restricted, and none matched my simple needs, I created Meercat Monitor, which runs on my server and checks some of my and work related projects/services. Simple checks scheduled checks, email notification, and a simple history and status view. Something simple enough and open source so I can audit and manage sources.

You can edit titles here on Lemmy. You can fix the title.

What makes you think it’s a lockfile issue? If they sighted a patch upgrade then updated the lockfiles but then noticed a breaking change, then lockfiles are irrelevant.

If it’s actually like they claim, I understand the frustration. (Not that I know this project in particular or how it gets integrated.) Without clear versioning and/or changelogs/release notes managing upgrades is cumbersome, sometimes impossible.

In some cases I’ve had to ask for clarification in PRs because release notes were not clear, PR was not clear, and resolved ticket was also not clear on the thing or solution.

Apparently they had issues before, so maybe they could have expected “patch may not be patch-only”.

I don’t think there’s a particular need to defuse into a productive discussion. Something like that, with no repro or respect - lock and close.

The first version included a ‘Fuck you’ but they edited it away.

The title is non-telling, the metadata page description is non-telling, no post description. What is this about?

This community’s rule 3:

If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos

Looks like the video itself also has no useful description. Only an unlabeled ad.

Copying the generated AI summary from YouTube from the description section:

The PrimeTime analyzes claims made by Anthropic and Boris regarding the state of modern software development. By examining technical issues with Claude Code, this critique questions the narrative that coding is largely solved, suggesting that the current push toward fully agentic workflows might be misleading and potentially harmful to professional software engineers.

I would expect it to apply to everything. You don’t want to hit the issues in the first place.

It seems like a weighing of (safe) CPU support vs better generated instructions. If you don’t care about a CPU generation, maybe because it’s old enough, or your target environment is restricted/controlled, you don’t enable it. If it’s still out there and you want to or have to support it, you enable it.

I would imagine a “CPU-Workaround-<Manufacturer>-<Generation>” or something, and if you enable it, it completely evades the instruction constellations that cause the issues and uses alternatives instead.

Maybe it could have “evade completely” (same code runs on every CPU) and “generate cpu-checked workaround code branches” (faulty CPUs execute a different branch) as alternatives.

Shouldn’t compilers (in this case LLVM) cover such CPU bugs with flags? So users can commit to either evading CPU bugs or not.

It’d also be a good entry-point and overview of what CPU bugs are out there. Without it, how are you supposed to know about and evaluate them?