gouggoug

This article is about a weekend project and not a serious product, so what I'm saying below is not criticizing the author's approach — I'm making a point about something tangential.

The post touches on my biggest pet peeves about how many software engineers currently use AI at work: they ask it to "write out a problems.md file describing the problem we want to solve" then lob the output over the fence for the rest of the engineering org to review, often times without even disclosing they used AI to generate it (it's, of course, obvious).

AI can not do the reasoning for us; thinking that because it is great at writing code that works, the same applies to documents whose primary purpose is to demonstrate critical thinking, explore trade-offs, and reason through a problem is absurd.

In fact (or IMO?), this "problems.md" document is entirely unnecessary. In many cases, simply describing the issue and providing the relevant context is enough for AI to come up with a working solution.

AI can not do critical thinking (yet), so don't ask it to (and stop sending your fellow software engineers AI-slop RFCs).

true — they only are immutable by convention and because the git command refuses by default to modify/push an existing tag.

One step further: use `git tag` for what it's for: tagging a given commit with an immutable reference (say, a version number like `v1.0.23`), and generate and publish "build artifacts" (`my-application-v1.0.23.tar.gz`, `my-application-v1.0.23` binary, `my-application-v1.0.23.tar.gz` helm chart, `my-application-v1.0.23` container image, `my-application-v1.0.23` ... whatever binary artifact)

> Nearly half of this year's survey respondents had experienced job insecurity and insufficient wages.

Insufficient wages, really? I understand you might be underpaid compared to your peers, but do developer really suffer from "insufficient wages"?

edit: I assumed this was US centric. It isn't. I could see insufficient wages outside the US.

A good reminder that satire really is an art.

I came here for this comment.

"A file format that corrupts itself a little every time you open it" simply isn't possible.

It's almost like the author is ragebaiting with this AI generated non-sense.

Because most users aren’t computer savvy and victims in a hurry probably don’t have time for a lesson.

On top of that, informing users requires them to open up the website in the first place… leaving it in… the history.

From the linked article, it was a press release, not just to his employees.

> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.

I recently got into 3D printing and, of course, after seeing countless ads on YouTube for OnShape, that was my first choice.

Anyone having used both can share their thoughts about how solvespace and OnShape compare?

On my end I’ve been loving OnShape and find it pretty intuitive. I also tried fusion360 but closed it after 5 minutes, it felt too sluggish.

Let my geriatric self rephrase this for you and make the point more obvious: "[...] who just discovered [insert latest design pattern trend of your choice] and insists on trying it everywhere"

> Is that an easy mistake to make and a hard one to recover from, in your experience?

If you're alone in a codebase? Probably not.

In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes.

In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase.

Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...

Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF)

Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates a resources based on the current time of day...).

With infrastructure, you want predictability and reproducibility. You want to focus more on writing _what_ your infra should look like, less _how_ to get there.

I wish timoni[1] would take off.

It’s based on Cue and doesn’t rely on templating.

[1] timoni.sh

There’s a difference between passively listening to a meeting and actively participating, while being in the bathroom.

I would never do either. But one is less weird than the other.

I wonder who the target is for such language.

What's difficult with programming isn't the language itself, it's everything else: understanding concepts, algorithms, programming patterns, the science.

It feels a bit like trying to reinvent the language of mathematics. It'd be really inefficient writing math in plain English.

This past month, I have spent a decent amount of hours (7+) trying to setup nix on my mac with nix-darwin, and failed.

Most tutorial out there encourage you to download someone else's configuration to get going. I don't want to do that. I want to understand at its core how this thing works.

I've read the official nix language documentation, watched YouTube tutorials, read 3rd party tutorials, and still couldn't get going with a simple configuration that would install a few packages.

The nix language is also really unpalatable to me. But I could deal with that if the examples out there showed a consistent way of doing things – that's not the case. It seems one same thing can be done many different ways – but I want to know and do it the right way. I would generally turn myself to the official best practices documentation, except nix' is very short and doesn't help much.

I really want to use nix. There's no question about its advantages. But nix just won't let me (or maybe I'm too old to learn new things).

That being said, I'll probably give it another try this month...

what are you trying to say here?

> but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs.

I don't have experience in this world, indeed.

But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different.

Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.

Branches are mutable and regularly point to a new commit. Branching is selecting an active line of development, a set of commits that change over time.

That's why git also offer tags. Tags are immutable.

That's an important distinction.

> There's nothing inherently wrong with having per-env branches

There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.

Do you create a branch for each one of them?

Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.

Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)

If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.

You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".

When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.

> Tools are just there, it's people who misuse them.

Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools

Somewhat related...

At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.

For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.

Don't do this.

If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...

I have since edited that starter guide and crossed out this recommendation.

As a bilingual, non-native, English speaker, grug brain is particularly hard to read and understand.

I don’t understand what « grug » is supposed to mean for example.

That being said I still enjoy the blog.

Since when? Where did you get this information from?

People can have opinions and instincts on a subject matter without a formal education in said matter.

The original statement is not just "we do not facilitate copyright infringement". It has a whole lot of other words.

If your original comment is solely about this revised 6 words statement, then, yes, you are correct, the claim is objectively untrue.

I'm no mind reader though, I assumed you were talking about the whole thing ¯\_(ツ)_/¯.

TL;DR: I am nitpicking on the use of "objectively untrue" and the implication this disclaimer serves no purpose.

> The creators knew that when they wrote that disclaimer and we all know that reading the disclaimer.

This is the idea I'm pushing back against.

Yes, you are very likely correct in your assessment that the creators know that their software will be used illegally.

No, you are incorrect, in saying this is 1- "objectively untrue" and 2- implying the statement might _not_ have some protective qualities.

To take a purposefully exaggerated analogy: you can believe all day long someone committed murder, it still doesn't make it true. You can argue all day long the authors aren't being truthful, it still doesn't make it true.

> Yet the disclaimer is still placed there like it has some reason for existing beyond allowing everyone to pretend something that is happening isn’t happening

I'd agree with this, and, add that, at the same time, (assuming the USA here) it's probably placed there for legal reasons (whether it factually matters legally or not is a question for an actual lawyer, which, objectively, I am not).

> I’m just remarking on the silliness of the disclaimer.

It feels a bit silly, yes, and at the same time... needed?

I think it's fair to say that the software itself could/does facilitate illegal uses cases. But with that line of argumentation, then all software facilitates illegal use-cases just by existing.

The statement "We do not endorse, promote, or facilitate copyright infringement, illegal streaming, or piracy in any form", might be poorly written with regards to the fact that just by existing this torrent streaming program _does_ facilitate piracy, but I don't think this was your original argument.

Torrented material is not necessarily copyrighted material.

It's not unlawful to use bittorent.

> "Who cares if the words are objectively untrue? We have plausible deniability now that we said them!"

But they are not "objectively untrue". You can argue all day long that you don't believe the author are being truthful, it doesn't make it true.

edit: that being said, in juxtaposition with a copyrighted Marvel image, I could see it being used in court against the author to prove they were all along catering to piracy.

edit2: clearly, I'm not a lawyer