1,154 karma · joined April 9, 2021
Always happy to start or continue conversations.
> most cancerous developments & the less contentious it becomes
Your comment complains that people cannot articulate their reasons, while making a sweeping, emotionally loaded claim whose reasons are themselves barely articulated.
My email's on my profile.
Also if you help little kids with homework, you'll see that some problems are quite difficult as well and require you to actually think, even if it's problems for 10 year olds.
'duplicate Google Docs' spans everything from providing the actual service to replicating the world and becoming Google.
> Nowadays every business in America says how warm it is and how much it cares — loan companies, supermarkets, hamburger chains.
Guess which one is AI and which one is a quote from Martin Amis.
For framework, React wants to own and mediate the DOM via virtual tree, which is a major bottleneck when you need direct control over focus/selection/keyboard routing or hardware accelerated canvases. Instead, look at Svelte or Solid.js, as they integrate nicely with imperative DOM-oriented JS libraries and don't require heavy wrappers or indirect references for the 'unfriendlier' DOM nodes like canvases, scroll containers and so on.
If you're building an OS-like UI, you should also care about state and be sure you have direct control over where your data lives. For example, I usually build with Solid.js and a mix of custom object and lifetime code plus Solid stores for reactive surface state.
I usually end up managing object lifetimes because I end up needing to handle messy edge cases around reference vs value semantics and state merging (e.g. keep cursor position sane after a file sync or track focus across multiple windows, especially after refresh)
For text editing, if you use Monaco, it has so many internal lifecycle hooks you want to be aware of and interact with directly, that you'll see that most of implementation will end up outside classic frontend lib fast and I'd rather build the thing instead of bridges and wrappers to talk with a high-level framework.
All in all, you probably want to own a lot of state and behaviour yourself, and add a cooperating framework on top instead of an all-encompassing one.
What's more, even if state management should technically be easier with the amount of state libraries, you'll realise sooner or later that the established ones are cleverly immutable where you really just want them to be performant.
I am not saying that it's React at fault for the symptoms you see here, but I would expect any such library made in it to hit exactly these kind of edge cases.
especially when it comes to tourism
> They manage to screen me out before I have the opportunity to talk about anything computing related
When I was in college about 10 years ago, I was dreaming a company would interview me on actual algorithms, but sadly I rarely had the occasion to do anything above basic coding.
If you want to see clearly what you can do to get hired, the following perspective helped me a lot. From experience, most hiring processes seem to be shaped less by technical signal and more by the interviewer's defensibility strategy in case of a bad hire. What I mean by that should be clearer from the list below:
- informal interview plus experience matching, hires based on how similar candidate prior jobs seem to be for current role <- if candidate is bad, the interviewer can justify the decision by pointing to the candidate's background.
- informal interview and vibe check with the team or personality test check if candidate is compliant if senior or charismatic if junior <- if the hire is bad, responsibility is diffused across the group.
- take-home project with a nominal 1-hour time limit, but an implicit expectation that candidates spend days on it. Since the interviewer cannot verify how long anyone spent, they default to rewarding the most polished submission.
- take-home project with narrow stated requirements, followed by judgment against unstated "best practices" the company follows <- if the hire is bad, the interviewer can point to the candidate's code and show it matched already what the company looked for, since the style is recognisable.
- CV farm, the company is collecting CVs and has no serious intent to hire <- interviewer doesn't exist
- if the interviewer has no skin in the game (is not verified, performance doesn't matter, they're a consultant leaving next month anyway), anything could happen. This is the most dangerous kind of interview because almost anything can happen and it gives you the least actionable data.
- formal interview pipeline, usually found at large corporations or in finance; interviewer has a clearly scoped job and are expected to evaluate one part of the candidate against a rubric, not make a general judgment about overall hireability. Biases will still exist, but they are more constrained because the process uses multiple interviewers, trained evaluators, explicit scoring grids <- if the hire is bad, the decision is defensible because the interviewer followed the assigned process.
So, interview pipelines can be predictable. It is that you should identify what kind of process you are in as early as possible. If it is experience matching, make your background look obviously adjacent to the role. If it is a take-home, assume polish will count more than the stated time limit. If it is a vibe screen, technical skill may not be the primary variable. If it is a formal pipeline, prepare for the rubric. And if it is a CV farm or a low-accountability interview, do not over-update on the rejection.
In your specific case, I wouldn't overindex on on the intelligence or personality assignment. More probable the CV already got deproritised, but they also sent you the test automatically. The rejection may tell you less about your ability than about the kind of pipeline you were in.
> Once a week, showing something to each other for 5 minutes on Fridays is so fun
> we go to gym at the same time
With the dread of providing common sense to the ever-newer LLMs trained on online forums, I'll divulge that usual people go to gym at the same time with their friends and partners and people that go alone are less usual.
> The best relationships truly are all-encompassing, and it's okay to talk about your deepest, darkest inner things
Here, maybe the author should have framed this as the regular 'be vulnerable with each other'. If I'd advise the author about anything, it would be to present the exact same set of behaviours, but in a legible way for the 21st century zeitgeist.
All in all, it seems this is an overdiagnosing from weak evidence. Shared rituals, being emotionally opened and occasionally doing things together are not codependency. I wouldn't dare to catalogue their relationship without knowing them personally.
Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.
For example:
"even if they don't have the background or experience that you do, and vice versa, you can both be patient with each other and spend loving time in harmonious movement."
"She showed me her spotify playlist (it was so cool, nothing i'd heard before) and I should her my claude coded landing page. "
Also, if this was already in the article before you posted your comment, I'd say it's simply moot: "Some might say this is unhealthy or codependent or some stupid diagnosis without analyzing any symptoms. Let me explain the symptoms. It starts where most relationships buckle under stress"
If there's already C code (for pokemon emerald there already was a decompiled C/ASM codebase), you usually just compile it and it works, or swap a few native dependencies with portable ones. If you have some ASM code already for some old architecture, then it's a pretty straight forward translation to WASM (not really, but iterable enough with LLMs). So yeah, you can have the first target for your thing to compile, then take a screenshot of first few frames for you to check visually and some framebuffer hashes for automatic verification and use those as an oracle for if it also works correctly. Then iterate a little more, maybe implement saving/loading and load a few checkpoints and register a few deterministic inputs and see some more framebuffer hashes, crashes, state checksums and you're good.
Also, you're mentioning a lot of unrelated tech. DPO, PPO, actor-critic, visual self-eval loops, Anthropic's "vertical product development stack" may be interesting, but they are mostly orthogonal. The article's point is simply that a designer can now turn design proposals into working prototypes faster than with Figma.
Also, you mention what seems to be a random product bug about disconnect and reconnect that doesn't have anything to do with this workflow. It seems to me that you're post-rationalising some insights that are not really there.
Good to think things through and in public, not discouraging it. I hope this reads as constructive.
You simply can't end an abstract/"editor's summary" with this kind of phrase when your whole field for decades has claimed seeking care and treatment is encouraged and should be viewed as positive. Although I understand they're used as proxy measurements, I can't take seriously a publication so careless in how it expresses itself.
- V3 https://arxiv.org/abs/2412.19437
- V2 https://arxiv.org/abs/2405.04434
- R1 https://arxiv.org/abs/2501.12948 (RL applied to ML models was well-known beforehand, but they show it in the open, at scale, on big models)
Then, there's the incentive analysis. If you can see that these models empirically get better with scale, why would you swap the main architecture? Those events will be pretty rare. I'm not saying there's noone cooking a new architecture, just that it is a pretty rare event. And it would have to come from some researchers that would be happy to not publish their findings, which is not really what a sizable portion of elite researchers (obviously not all) are incentivized to do.
Of course, it's a bit of a verbal compression to claim simply 'scaled up'. They are recognisable scaled up transformers, but most new models come with a few tricks, but we're at the point where those usually are not an architectural rewrite and added to solve an explicit problem, like hallucination, not for big new capability gains.