Thankfully there’s AI as an excuse, that way they grumble about it but don’t want to know how you did it
On a serious note, if you can’t look at the diff and make sense of it, you’re doing something wrong.
deleted by creator
Why was this made with AI instead of a meme generator? Poor Tom got the Uncanny Valley filter.
“The problem just went away.”
As a fellow dev used to say, “Any problem that goes away by itself can come back by itself.”
thats a problem for future me
Not if the the layoffs continue
“I can’t select the proper option in the dropbox, it doesn’t exist anymore” -> sends me a screenshot of the missing item
get on website, the item is right there for me to select
log into database, there’s nothing wrong, everything is as should be
recieve new message: “I can select it now, thanks for your prompt fix!”
thanks man, I did nothing
a while ago, during a game jam, while i was making some of the worst gdscript i have ever seen, i have encountered a bug
after adding a print to see the value of a variable, the bug disappeared. Confused, i commented out the line i just added. The bug was still fixed
i removed the comment. The bug reappeared
printing to a console could enforce a flush, sync thread or other shenanigans.
usually setting a breakpoint would have the same effect and gives me the suggestion of a threading issue.
the problem wasnt that the print statement fixed the bug
the problem was that even if i removed the print statement and added a comment on that line, the bug would also be fixed
My favourite: The code does not work. You make a change, it breaks more. You undo that mistake: it now works.
I’ve had:
Code is broken. Make change
Code broken worse. Undo change
Code still broken. Revert to previous version
Code works. Check code- it has the change you just made that didn’t work
Good ol’ cache.
Or in the silliest circumstances wrong development environment.
My worst one, have working code, make a change, it broke. Revert it, still broken…
The issue was that all icons and stuff randomly got a wrong size in the GUI. Just had to restart the machine to fix it, but I was really pulling my hair out when I somehow broke things backwards in time.
Yeah, that’s classic
It’s fun when I just try to compile it again and it works fine. I’m sure that’s a good sign.
Nondeterministic compile. LLM compiler?
Often this is because some part of either the IDE or the build chain failed to clear some part that needed to be cleared. Especially for large projects and on older machines, compiling takes a while. Usually only small changes are made during programming, so to optimize the work flow it tries to only re-compile what absolutely needs to be recompiled. This speeds up the process, allowing for iterative development without waiting a long time.
I remember working with Java on my old Pentium 1 system and it taking easily 45 mins to compile something. That’s where the xkcd 303 got its origins. https://xkcd.com/303/
But sometimes this fails in some way, which can lead to very bizarre results. Often causing headscratches figuring out what went wrong, assuming the fault to be in what the developer did. A quick way to check is to simply delete the intermediate compiler result (often the obj or bin dir, or both) and do a whole fresh compile. Sometimes it’s enough to simply compile again, often when the error was caused by some race condition in the build process. For example something being flagged as needing cleanup, but the build being done before the cleanup was done. A recompile at that point will probably work as the cleanup has most likely happened.
Sometimes shit’s just cursed and there is no explanation, probably angered some coding god somewhere. Perform the proper ritual and you’re good to go.
Oh yeah, I was mostly just kidding with the LLM compiler bit. I’ve run into issues with incremental compiles working on the JVM ecosystem myself (mainly Kotlin though, as my work in the ecosystem took place early this decade). Still didn’t want to clean build every time though, because on an M1 Pro it was about 5 minutes to build some of our backend services from scratch and I tend to like a really rapid feedback loop for testing, changing code, recompiling, re-testing.
These days my docker container reloads the entire project when I edit any file, but it takes 10 seconds since there’s no need to compile anything since it’s Python. Pure bliss in comparison (the development pace that is; I actually liked Kotlin more as a language even though Python is fine)
Android had a quick deploy feature where you could push minor changes like text or layout updates to the phone while testing without having to actually rebuild it. Like press button and a couple seconds later it updates.
It without fail over years and years of trying to use it, always failed frequently, and you’d end up with unexpected behavior or crashes. For a time anyway, they tried to default it to on.
Im not sure what the current state of it is today, I just stopped bothering to test it out.
Yep, a clean build often got rid of the weirdest bugs I had, because some shared memory was misaligned, because, as you said, because of compile optimization, some parts didn’t know about the changes
Ive had some build bugs where a clean build didnt fix it, restarting the IDE didn’t fix it, but rebooting the computer did.
I imagine some long running process even after the IDE is closed had been corrupted or something.
This phenomenon was around eons before LLMs. You have to figure out how conditions are different when the problem happens in the wild and when you fail to duplicate it.
I was mostly kidding. You can always run into weird caching issues and I’m sure there are other issues I haven’t thought of.
Docker builds in particular feel like a double edged sword. On the one hand, the entire team has the same build environment regardless of their machines. On the other hand, if docker’s cached old versions of packages in a preliminary step (e.g sudo apt-get install whatever) and something has a bug, you might run into issues till you clear the cache and rebuild then.
Tbh I’ve never used Docker, but the idea that it’s a perfect bulletproof solution to environmental issues has always seemed overly rosy to me.
It’s very far from a bulletproof solution and it can cause its own issues, but if used properly, there are a lot of issues that it can help prevent.
Put it this way: Production is on the Eclipse Temurin flavour of JDK, but your new developer downloads the Oracle one off java.com instead. Ideally both should function the same, they implement the same Java spec after all! But there might be a bug in one or the other that changes how something works.
Now you could just provision machines with a particular environment setup, and not let your developers install random-ass packages, but most smaller companies I’ve worked for don’t really practice that for developers (less technical employees are another story). You get full admin access to your machine and you can customize your environment.
Instead, your new developer builds the same docker container that runs in your kubernetes cluster. Same base image, same dependencies installed, etc. Day one and the project builds fine (assuming the code itself works).
However, it’s not perfect. For one, sometimes an older version of a distro won’t support a newer version of some really low-level dependency for some weird-ass reason. It’s a fixed bug in newer versions, but your new employee decided to install Debian Stable on their machine so now they have to install docker from somewhere other than the main Debian repo. Another issue is the caching I mentioned beforehand.
If you’ve never used docker before, I’ll give you a quick rundown on how building a docker image works, just in case.
Generally you first pull from a base image. Depending on your use case, it might just be ubuntu 24.04, or maybe you take an image that already includes the toolchain you need (e.g a jdk image for java stuff). Your base image itself could also be based on another image, with extra stuff added. There could be tons of layers, the ‘base’ image is just the last layer you import from elsewhere before you start doing your own stuff. Then in the dockerfile, you can use different commands to build your own custom image, such as copying files from some directory on your system to the new image (like your code), or you can literally run bash commands as well. Say you used a Debian or Ubuntu base and you need some library from their repo, you just sudo apt-get install it. Or similarly you install your npm or pip or whatever packages before building. The thing is, and you can disable this, to save time, and bandwidth, docker will cache the results of each step and use cached versions up until the first step where it detects changes (usually to the files you copy to your image). But if you want it to be performant, you do all your dependency installs before your filesystem stuff so those steps don’t get re-run each time you change your code. So the first time you build an image on a particular computer, it pulls the dependencies and then until you do a clean build it might never pull them again. That’s where you can run into issues.
And yes, you can just include the dependencies in a base image that gets built automatically in the CI and only add the code and compile steps in the image you build on the local machine. But you still have to pull the new base image!
I appreciate the info and the time and effort you took to pass it along. I certainly might get around to using Docker. If you work with node you might be interested in create-api-lite, an npm package (which I haven’t used yet) that generates a basic node project structure, including dockerfile.
Oh I keep the hell away from all things javascript as much as possible, I’ve only had to work with node in a couple of projects, mostly did bugfixes to other people’s old code and migrated some APIs away from node to Kotlin as that was the company’s main tech stack and we didn’t have a single backend engineer who wanted to do Node, those APIs were built by someone who’d long left.
These days if I create a new API for a personal project, it’s going to be in Rust and for professional projects it depends on what I’m being paid to use. And for personal projects, since Rust is so heavily focused on the one single build environment that is Cargo, I don’t really see the need for docker - usually the pain points are people not having postgres or openssl installed on their machines, but you can just stuff it in the readme that it’s necessary, and you get build time errors rather than runtime errors if they’re not present. I always prefer build time errors myself.
For work I still use docker, but my main client has a fairly robust setup, where I don’t really need to worry about much, but when there is an issue, I’m usually the person who fixes it because the CTO is busy and most internal employees’ time has been scheduled already, whereas I get the “oh we need this today, can you do it?” stuff
I’ve literally experienced the “I changed/edited/deleted this comment and now my code works” before and it floored me. I can’t for the life of me remember what happened specifically I just remember being scared. It shouldn’t do that, and since it did something I deeply don’t understand happened behind the scenes.
That’s usually (in toolchians that aren’t broken) a caching issue. IE what you see in your editor isn’t what actually got ran, even if you told it to recompile.
Nowadays the answer is probably a 5,000-word essay that no one has (or will) read
Written by AI. Also read by AI. Humans need not apply.
Humans are for the bills to pay.
Remember the
humanbills.
Iteration X.
Changed a comment.
with a language like rust this actually hardly ever happens
You don’t know how fucked up my
build.rscan get
wait ppl dont have a local git repo that always do a commit everytime you press ctrl+s?
