132 karma · joined January 25, 2013
Successfully burning through cash and tokens, alright, but what have they gotten out of it?
As someone who takes pride in being thorough and detail oriented, I cannot stand when people provide the bare minimum of effort in response. Earlier this week I created a bug report for an internal software project on another team. It was a bizarre behavior, so out of curiosity and a desire to be truly helpful, I spent a couple hours whittling the issue down to a small, reproducible test case. I even had someone on my team run through the reproduction steps to confirm it was reproducible on at least one other environment.
The next day, the PM of the other team responded with a _screenshot of an AI conversation_ saying the issue was on my end for misusing a standard CLI tool. I was offended on so many levels. For one, I wasn’t using the CLI tool in the way it describes, and even if I was it wouldn’t affect the bug. But the bigger problem is that this person thinks a screenshot of an AI conversation is an acceptable response. Is this what talking to semi technical roles is going to be like from now on? I get to argue with an LLM by proxy of another human? Fuck that.
I took out the part about templating because I thought it made my comment too wordy, but ended up oversimplifying.
https://griffindavidson.com/blog/mac-displays.html has a good rundown.
[1]: Assuming you use the `--paging=never` flag in your alias as the README suggests.
Relying on a feature that requires enabling an experimental flag in the latest version of Chrome to work is "leveraging the web" in the worst way.
I've been meaning to give avante.nvim[2] a try since it aims to provide a "Cursor like" experience, but for now I've been alternating between Code Companion for simple prompts and Claude CLI (in a tmux pane next to Neovim) for agentic stuff.
[0] https://codecompanion.olimorris.dev/
Taking your sample code as an example, someone might look at the myapp deployment definition and ask: “does this deployment get created in the default namespace or does it automatically create a myapp namespace? What’s the default number of replicas? Are there any labels or annotations that get automatically added?” Etc.
On the flip side, there’s potential lack of “greppability.” The user may have found a problem with a deployed resource in, say, the development cluster, and go to grep for some resource-specific string in the repo, only to come up empty because that string is not in the source but rather generated at by the templating system.
To be clear, both of these problems can affect any method of generating config, be it yoke, helm, ksonnet, kustomize, or cue. It’s like a curse of abstraction. The more you make things into nice reusable components, the easier it is for you to build upon, and the harder it is for others to others to jump in and modify.
At least with Cue you get properly typed values and parameter validation built in, which puts it miles ahead of “everything is a string” templating systems like the helm templates the article complains about.
I did some searching and it looks like the issue might be fixed in latest nightly. See https://github.com/wez/wezterm/pull/5396
"hidden" in the sense that when I go to chrome://extensions it is not listed.
And as you already mentioned, it's a Chrome API.
(With thanks to @varenc)
I'm somewhat baffled by this statement. If a Go program compared a constant expression float against a runtime computed float, it could have unexpected results, but comparing floats in general is dangerous. I don't see how this language quirk increases that danger in a meaningful way.
You're right that raycasts aren't an edge case in terms of usage, but Juan Linietsky's point is that the inefficient path used for this API call is a rare exception to the efficient paths used by the vast majority of the API.
As someone who did a deep dive into understanding DT's scene-referred modules, it changed the way I think of photo processing. I now have a hard time using any other photo software.
I suppose that given enough time in the same role, one would naturally get so comfortable that they can perform their job more or less on autopilot. Combine that with regular raises and I could see how they might be perceived as an expensive employee who doesn't put forth much effort relative to their peers. That would certainly make me worried about being targeted for layoffs. Is that the kind of logic the author is referring to?
> WARNING: This is a development server. Do not use it in a production deployment. > Use a production WSGI server instead.
I don't expect junior devs to have a sense for what is production-grade and what is not, but if they try to ship software that explicitly warns against being used in production, you've got a real liability on your hands.
I work for a startup with ~60 employees. The DNS was setup through GoDaddy by our CEO over 6 years ago when the company consisted of just founders.
Employee #1 updated GoDaddy to point to AWS for nameservers. We've been managing DNS through Route53 ever since. It's tech debt, sure, but migrating domain ownership to AWS gives us almost no benefits. I guess having more consolidated billing would be nice, but until finance complains at me I'm not bothering to change it.
It would pain me to find out that a candidate would red flag the company based on domain registrar. Then again, I don't know if I'd care to interview someone who makes such large decisions based on small details with no context.