yoyonamite
yoyonamite on Hacker News
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"
I think it might actually be worse. I don't think the judiciary can enforce any of their court orders.
This sounds like a potential conflict of interest:
PROJECT ANNOUNCEMENT: Inspection of USAID's Oversight of Starlink Terminals Provided to the Government of Ukraine
May 14, 2024
https://oig.usaid.gov/node/6814
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?
If you don't mind me asking: Do you see a solution, technical or otherwise, to this problem?
My guess is there are limits to knowledge transfer that's difficult, if not impossible, to overcome.
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.
My guess for the small companies that don't hire is that it's the incentives. If my outcomes as the hiring person are that a bad hire is a large negative, a no hire is a very slight negative, and a good hire is a slight positive (possibly even neutral), I'm going to prefer no hire most of the time. I believe this is a fairly common decision matrix.
For example:
bad hire lowers managements' opinion of my performance and can be costly to team morale, especially if company culture makes firing difficult
no hire can be blamed on lack of qualified developers rather than a competency issue
good hire is nice, but if current development team can push back on workload, that benefits the company much more than the development team
TripleBytes' placement rate was 40% in 2018 [
https://techcrunch.com/2018/02/28/triplebyte-has-raised-more...]
I'm not sure how to reconcile a recruiting company well-known for doing rigorous technical screening having a 40% placement rate, most candidates being a clear yes or a clear no, the hiring process being completely fine, and the hiring process not producing many false negatives.
What was the placement rate for the candidates that you put forward? Based on your statements, I would expect this number to be very high, but from my understanding of the industry, including recruitment companies that do technical assessments, I would be surprised if it was that high.
ah, okay. I think I misunderstood. I was thinking about the case where the data is stored in the cookie itself (i.e. an encrypted cookie), and you would need a way to verify that the contents weren't altered. If it's storing a session id, then there isn't a reason to also sign it. Sounds like they conflated the two approaches.
Isn't signing the session cookie to prevent cookie tampering? You can send a random string, but you would need to persist the random string somewhere in order to verify against it later
Would you be willing to provide examples of specific issues? I don't want to assume I know where the difficulty lies, and I'm interested in seeing where people have issues.
Is there a specific example of what didn't work? It's been awhile since I've used react and bootstrap, but I remember that passing refs to the Bootstrap javascript directly (e.g. `tooltip = new bootstrap.Tooltip(ref, options)`) worked
I still reach for Rails a lot for prototyping. If the application can leverage Rails core functionality and the bigger gems in the ecosystem, I find it the quickest to prototype in, and the point of a prototype to me is to optimize for speed and customer feedback, often as the only developer. In many cases, the prototype needs to be re-written anyways when core assumptions don't survive encounters with the customer.
I think the reason this productivity exists is the all batteries included approach. For example, if I build a Rails gem, I can include data persistence through ActiveRecord and that code becomes less code that the developer using my library would have to write. Multiply that out by the various core libraries and the time savings can become significant.
I would also point out that for very early stage startups, the biggest problem is speed of development with only one to two devs. If they can't get the features out to reach product-market fit, it doesn't matter how good the performance of their application is.
One thing 37Signals is very good at is limiting the scope of what they're trying to accomplish and market those limitations as a strength. Instead of doing that, it sounds like they tried to compete directly on features against competition that could outspend them.
Is there a plan to address notification fatigue? It's less of an issue with calendars because calendar events tend to be important and synchronous. I'm worried that aggregating more data sources would add a lot of noise, but I can see a lot of value in being able to surface high priority items.