C does exactly what you tell it, no more. Why waste cycles setting a variable to a zero state when a correct program will set it to whatever initial state it expects? It is not user friendly, but it is performant.

deleted by creator

Senior developer tip: squash the evidence.

The early days of the Internet, there was a cottage industry to burn Linux ISOs to CDs and selling them.

I work in Java, Golang, Python, with Helm, CircleCI, bash scripts, Makefiles, Terraform, and Terragrunt for testing and deployment. There are other teams handling the C++ and SQL (plus whatever dark magic QA uses).

I am well aware of learning, but people tend to learn by comprehension and understanding. Completing phrases without understanding the language (or the concept of language) is the realm of LLM and Scrabble players.

About 10 years ago, I read a paper that suggested mitigating a rubber hose attack by priming your sys admins with subconscious biases. I think this may have been it: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final25.pdf

Essentially you turn your user to be an LLM for a nonsense language. You train them by having them read nonsense text. You then test them by giving them a sequence of text to complete and record how quickly and accurately they respond. Repeat until the accuracy is at an acceptable level.

Even if an attacker kidnaps the user and sends in a body double, with your user’s id, security key, and means of biometric identification, they will still not succeed. Your user cannot teach their doppelganger the pattern and if the attacker tries to get the user on a video call, the added lag of the user reading the prompt and dictating the response should introduce a detectable amount of lag.

The only remaining avenue the attacker has is, after dumping the body of the original user, kidnap the family of another user and force that user to carry out the attack. The paper does not bother to cover this scenario, since the mitigation is obvious: your user conditioning should include a second module teaching users to value the security of your corporate assets above the lives of their loved ones.

It looks like it targets JavaScript, the language that least needs it. What is the job security advantage of this tool over a minifier?

I know, but this thread is about projects that don’t want to use GitHub as the center of discussion and use Discord instead. The Discussion tab need to be enabled.

So you are suggesting forum software that supports single sign-on?

We are talking about an open source project, not a high school reunion. I don’t want to hang out with people, I want to have a discussion about a focused topic.

I want to ask a question and get an answer. If the question is not one that anyone online can currently answer, I want to be able to tell at a glance if anyone has talked about my question. If I don’t understand the answer, I want to ask a follow up question.

In the evening, I want to be able to take a look at new posts from that day, grouped by topic, to see if there is anything I find interesting or can weight in on.

With Discord (or any real time chat), it is hard to follow a single topic when more than one is being discussed. It is doubly hard to do so after the fact. I am aware that Discord has a forum feature. I have only seen one server ever enable it and no one posts anything to it.

But a floating point issue is the exact type of issue a LLM would make (it does not understand what a floating point number is and why you should treat them differently). To be fair, a junior developer would make the same type of mistake.

A junior developer is, hopefully, being mentored by more senior coworkers who are extra careful with code reviews and would spot the bug for the dev. Machine generated code needs an even higher level of scrutiny.

It is relatively easy to teach a junior developer to write code that is easy to read and conforms to the teams style guide.

All the time. Causes include:

• Test depends on an external system (database, package manager)
• Race conditions
• Failing the test cleared bad state (test expects test data not to be in the system and clears it when it exits)
• Failing test set up unknown prerequisite (Build 2 tests depends on changes in Build 1 but build system built them out of order)
• External forces messing with the test runner (test machine going to sleep or running out of resources)

We call those “flaky tests” and only fail a build if a given test cannot pass after 2 retries. (We also flag the test runs for manual review)

Out of curiosity, any idea what automerger they use? I have always been on the lookout for one for hobby projects.

Python: You send someone else to rescue the princess on your behalf. That someone else is the C knight.

If you are creating an alternative implementation and leaving the old one in place, you are not fixing a problem, you are just creating a new one (and a third one because you have duplication of logic).

Either refactor the old function so that it transparently calls the new logic or delete the old function and replace all the existing usage with usage of the new one. It does not need to happen as a single commit. You can check in the new function, tell everyone to use it, and clean up usage of the old one. If anyone tries to use the old implementation, call them out in a code review.

If removing or replacing the old implementation is not possible, at least mark it as deprecated so that anyone using it gets a warning.

I have tried GitHub project boards for hobby repos and was disappointed by how bare bones it was. For example, it did not have support for breaking a story into smaller component stories (like a Jira Epic or task with sub-tasks).

My favorite YOLO-Driven Development practice (from a former employer) was Customers as QA. We would write code, build the code, and ship it to the customer, then the customer would run the code, file bugs for what broke, and we would have a new build ready next week.

It provides many benefits:

• No need to hire QA engineers.
• Focuses developer debugging time on features actually used by customers instead of corner cases that no customer is hitting.
• Developers deliver features faster instead of wasting time writing automated tests.
• Builds are faster because “test” stages are no-op.

One time a developer was caught writing automated tests (was not sure in the correctness of his code, a sign of a poor developer). Our manager took 15 minutes out of his busy day to yell at him about wasting company resources and putting release timelines in jeopardy.

That should be a disciplinary issue. The engineers in question should be brought forth in front of management to explain why they thought that this particular change should be exempt from testing and why this was not explained, in detail, in the code review.