As someone that recently went through an introductory Japanese course in Japan, I don't find this much different than how it's taught. Or maybe I'm missing something?
It seems like the article is trying to make the case that in romaji, you can split the letters and isolate the vowel (e.g. the asterix in the article's conjugation).
But we were simply taught to change from the う- row to the い- row (u- row to i- row). I switched to Japanese to illustrate that you can make that statement even without romaji. In that case, it seems like basically the same thing?
As an anecdotal point, my class was mostly non-english speakers and I didn't find the above to be a sticking point for my classmates. The real sticking points were messing up the ichidan verb exceptions (ichidan verbs that look like godan) and conjugating the correct form for the different grammar points. Te and ta form were also a bit tricky. But the article doesn't seem to offer anything new to help there.
I don't use VSCode, but I've heard that the default model isn't that great. I'd make sure you're using something like Opus 4.5/4.6. I'm not familiar enough with VSCode to know if it's somehow worse than Claude Code, even with the same models, but can test Claude Code to rule that out. It could also be you've stumbled upon a problem that the AI isn't that good at. For example, I was diagnosing a C++ build issue, and I could tell the AI was off track.
Most of the people that get wowed use an AI on a somewhat difficult task that they're unfamiliar with. For me, that was basically a duplicate of Apple's Live Captions that could also translate. Other examples I've seen are repairing a video file, or building a viewer for a proprietary medical imaging format. For my captions example, I don't think I would have put in the time to work on it without AI, and I was able to get a working prototype within minutes and then it took maybe a couple more hours to get it running smoother.
Why is it silly? Is it reasonable to hold the opinion that DOGE should not have been given access to these systems (note: this doesn't mean that the opposite view isn't also reasonable)? If it's a reasonable position to hold, then getting access to these systems can be reasonably construed as an attack, can it not?
I don't really think this argument merits a comparison to "technology is the mark of the beast" or that the only people that can be opposed to DOGE suffers from "personality derangement" or "glorifies bureaucratic power"
It's because people ended up with models that were thousands of lines and difficult to reason about. Out of curiosity, did you end up running into this issue and how did you deal with it?
Good code to me usually comes down to things like state management, code organization, ... Having code that reads like prose isn't a high priority to me, but I'm familiar with that style and I can see why people like it. I just wish they'd realize they're expressing an opinion on style instead of a fact.
I think every subreddit should have created a community on a reddit alternative, like lemmy, kbin, etc. and actively promoted it as a "temporary" replacement. This way, Reddit waiting out the blackout risks losing marketshare to the alternative.
Right now, that risk is very low because the alternatives didn't seem to have picked up enough critical mass, especially outside a few big topics like technology or news. Without an alternative picking up steam and stealing eyeballs, Reddit doesn't have an incentive to come to the table and can easily wait this out.
I'm not affiliated with Gimp and don't know why they didn't support fat binaries in the end; but I did look into compiling Gimp as a Universal Binary on my own at one point. My experience matches those of another comment, which is that not all dependencies supported compiling to fat binaries (i.e. you couldn't just add a bunch of flags and get a fat binary at the end). The only solution I thought of was to compile for both platforms and then lipo all the built files. The main problem is I couldn't figure out a strategy to do this without making the build scripts into a gigantic mess.
Getting a Silicon build of Gimp wasn't actually that difficult. I know at least one other person besides myself that had gotten a build working from source and published how to do it in some form. The problem is that the CI system Gimp used for the Mac build did not have ARM runners, yet. This meant that to produce the production build required cross-compiling from an Intel Mac. While I'm sure it's possible to accomplish this, it was quite tedious and I gave up. As an example, one problem was that the Gimp build process builds tools that need to be run on the system doing the build and just splitting out those parts from the parts that need to be compiled for the target system was tedious.
> Honestly, if someone showed up with a gap in their resume and claimed that they were doing start-up, open source, etc. for an interview, I'd dig deep into that hard.
This is just as, if not more toxic than the advice that you're opposed to. I've had similar experiences with interviewers for non-technical questions, and it comes off as aggressive, antagonistic and traumatizing; especially in your example where they left it off their resume as a gap. The interviewee's perspective might have been to say that they've been spending some of their spare time keeping their skills sharp and now you're hammering them to see if a project left off their resume qualifies for some "high bar," while all they see is a negative and dismissive attitude.
Personally, I would much rather be programming my own projects or doing leetcode than play video games, but I wouldn't judge someone negatively if they told me they played games on their own time.
The majority are simply going to follow popular opinion regardless of the merits, and developer efficiency is often not that important. I also think the efficiency gains are bigger for smaller and inexperienced teams.
Also, people are getting used to app-like experiences and designers are designing for it. Building an app-like experience is more natural as a Single Page Application, which basically means taking on the modern frontend stack. There are places that push against this, but to do so requires buy-in to the engineering side over product and design. Even then, the engineering side has to be knowledgeable enough to not follow popular opinion and come to the determination that Laravel/Rails/Django is actually the right tool, which isn't always the case.
True liberation is non-attachment. By attaching yourself to doing something that you love, you may be setting yourself up for disappointment.
Is this really what I love? Is my solution actually helping anyone? Will I have to make compromises to better monetize my solution? I've been working on this project for a year and don't feel like I've made a meaningful innovation.
Some people go down this path and everything works out well but not everyone.
I've never been involved in the game industry but it sounds believable to me. It's not a given that having a CS degree means a person can code, which is one of the reasons we code test in interviews. And I imagine the game industry requires higher coding ability. There are also people that want to be in the game industry no matter what. They would rather be a tester in games than a programmer outside it.
I think there are ways to do this correctly but it has to be more static pages with JS enhancement and/or making certain sections standalone "single page apps". It sounds like you're halfway in-between and that leads to the sorts of issues you're talking about. Being halfway in-between does mean that you're also halfway to an SPA, so maybe just commit fully to that direction?
Personally, I find webpacker to be straightforward and not that magical relative to the asset pipeline.
I think a core problem is that the incentives are to give a quick diagnosis and prescription, and if that diagnosis is wrong, move on to the next diagnosis / prescription, repeat. This is in contrast to my experience with a functional doctor, who laid out a logical plan, testing to verify hypotheses, and only after all the pieces fit together, decided on a treatment strategy.
Of course, for the majority of cases, the mainstream approach works well or well enough, but it's definitely frustrating when you fall outside of it. I think some people don't even know they're falling outside of it (e.g. long-term gastrointestinal problems), as in they've given up figuring out the root cause and have learnt to deal with their symptoms. I think the number is non-trivial (1%+?), but I can't think of any way to prove that.
I do think it's important to think critically and not just do something for the sake of doing it. Testing well is not easy to get right. If your tests are constantly changing, then the tests are probably too coupled with the implementation. However, I think it's safe to say that the user wants some level of consistency in the product. If your tests captured what needs to stay consistent, you should theoretically see less churn in the test code.
There are other ways to get a stable system. It seems like the code that you're working on doesn't see much code churn and you have a good understanding of the system. This is definitely a situation where I see testing not being as valuable.
I think one of the big reasons testing is considered a good practice is we're relying more on dependencies that need to be updated somewhat frequently, and semver is not taken as seriously, especially in certain web ecosystems. There's a decent chance you don't work in such an ecosystem where it's not an issue, but that's the biggest reason for me to advocate for testing.
The other big reason is that it's easier to make changes in a codebase that you aren't familiar with when tests are available. This is especially true with software that may have non-obvious corner cases.
It seems like the article is trying to make the case that in romaji, you can split the letters and isolate the vowel (e.g. the asterix in the article's conjugation).
But we were simply taught to change from the う- row to the い- row (u- row to i- row). I switched to Japanese to illustrate that you can make that statement even without romaji. In that case, it seems like basically the same thing?
As an anecdotal point, my class was mostly non-english speakers and I didn't find the above to be a sticking point for my classmates. The real sticking points were messing up the ichidan verb exceptions (ichidan verbs that look like godan) and conjugating the correct form for the different grammar points. Te and ta form were also a bit tricky. But the article doesn't seem to offer anything new to help there.