throwaway284534

As a narcoleptic I wish that the diagnosis was more accurate, or at least that the insurance companies were more holistic in their coverage of medication. The multiple sleep latency test hardly qualifies as science and has a terrible false negative rate. It’s also expensive so insurance is reluctant to cover it in the first place, and outright hostile to a second attempt.

Any neurologist will tell you that your first night’s rest in a new location will be of a lower quality and depth than at your home. Despite knowing that, sleep studies are performed at the hospital in a room so uncomfortable that it makes the Holiday Inn feel like the Ritz. You’re then hooked up to a dozen different monitoring devices and asked to sleep in an uncomfortable bed with a camera observing your most vulnerable position. You should have no trouble falling asleep!

The second day is peppered with six attempts at napping within a short window, and if you enter REM within a threshold, you’re official diagnosed as narcoleptic. Otherwise you get a consolation prize of “idiopathic hypersomina” i.e. “sleepy person syndrome.” This methodology only selects for the most severe cases of narcolepsy, and as a result, allows insurance companies to gate-keep expensive medication.

I’ve read that a patient’s suspicion of narcolepsy and their final diagnosis is estimated around 8 to 15 years! IMO there is a subconscious characterization of known-unknown diseases as personal failing of the patient’s virtue. Convincing your parents, teachers, and doctors that you’re not just lazy is near impossible until the symptoms become too frequent to explain away. It also stands that doctors cannot be perceived as lacking critical information, therefore it is Not Allowed for their patients to be fatigued unless they’ve earned it, or put through the gauntlet that is our medical system.

Much appreciated. I’m US based, but I travel a lot for work. It’s a blessing to have a wider perspective on gender roles, especially with so much of the journey now in the rear view mirror. AFAIK there’s no lower rung on the corporate ladder than a sad partially-baked trans person. Hormones are cheap but a remote tech job with a decent salary can make a transition affordable without jeopardizing your career, socioeconomic trends withstanding.

Sadly there are many ways to experience negative social expectations at work. Several of my formerly heavy-set colleagues have observed the perception of their competence being a result of their weight loss. Most of the cis men I know use a combination of testosterone, Ozempic, hair plugs, lifts in their shoes, etc.

I don’t blame them; Perception is everything.

If it’s any consolation, I haven’t gotten any favors as a trans woman, even with “passing privilege.” Both myself and the cis women in tech I know all hear the same thing: companies are tipping the scales to favor diversity hires. But in truth it seems to be a marketing tactic rather than a hiring strategy.

It’s quite bizarre at all levels — I often receive invitations from recruiters to apply to “women led startups”, but when I ask why I’m qualified there’s no real explanation other than I’m a woman who owns a computer. The same seems to be true of female founded startups. Doesn’t matter what the role is or what’s being built — Does she use a computer while in an office building? That’s women in tech! The purpose of most of these interviews is really about manufacturing consent: “It’s just too hard to hire women! Just look how hard we’ve tried!” I’m all for incentivizing under represented groups, but it wouldn’t be so bad if the phrase “women in tech” was short hand for “women who have written a lot code” and less about “brave women who uses their yonic powers to guide the brutish male code monkeys.” Attend a FAANG sponsored women centric event and you’ll see that I’m only exaggerating a little bit.

Ironically, my transition has been something like a rendition of Gift of the Magi: The more passable I became, the less experienced I was perceived by my peers. And worse, what was once thought of as confident display of technical ability is now seen as a lack of demure. Insecurity runs deep in this industry.

IMO the hiring problem isn’t about gender or race. It’s the fact that tech doesn’t have the luxury of an economic environment where all the money is imaginary. There’s really no era quite like the last two decades. Tech companies could burn through billions of dollars on intangible assets with no immediate need for deliverables. As the perception of innovation diminishes, companies feigned cutting edge leadership by leaning into the virtues, and as a byproduct, having the employees fight over who’s more oppressed.

I think everyone here has questioned if their skill set is actually worth their salary. “Sure, sometimes it’s a free ride, but those hard sprints are really why I’m paid six figures!” — It’s explanations like that which let software engineers hit the snooze bar on whether their employer’s solvency is transitive of their technical expertise, or rather just two decades of zero interest rate policies. It’s likely a little bit of the former and a lot more of the latter.

IMO most engineers are looking through the wrong end of the telescope, trying to find a job like the dating you do when you’re looking for a comfortable but uncommitted relationship. That time is over and our jobs are now akin to the blue collar trades who’s customers have a clear idea of what they’re paying you for, rather than a vague set of technical skills that might be worth exploring on their dime.

The gist is something like a new cohort of front-end developers and some begrudging back-end folks who never actually learned how anything worked are now trying to inscribe their influence as the new smart people with tools like Tailwind and HTMX.

Wanting to prove yourself isn’t a problem. It’s actually a sign that a developer is starting to form their own opinions. But it becomes toxic when the primary motivation comes from a desire to appear smart instead of actually solving a problem.

You’re absolutely right about typed classes and that’s how React Native does it. Writing and debugging CSS is hard for many of the same reasons that string-based templates exhibit. IMO the developers who push Tailwind are looking through the wrong end of the telescope. CSS is challenging because it’s a combination of declarative aesthetic UI and imperative state management. Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system. Modern CSS is pretty great and learning how it works pays endless dividends.

I hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’re using it wrong; You’re a not as smart as me; I drew you as the Soyjak and me as the Chad. Please won’t somebody tell me that I’m cutting edge?!

I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!”

JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since.

Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test!

It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read.

There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement.

It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.

As a web developer, I’d like to think that we’re effectively alchemists who transmute vague ideas into products held together with absurd magic that’s constantly changing.

Can we get a bill going? I can’t decide between “Webmancer” and “www.izard.com”

Respectfully, those metrics are not proxies for productivity. They don’t seem to be grounded in a statical model either:

>They reduced the code base size by 67% (21,500 LOC to 7200 LOC)

> They increased python code by 140% (500 LOC to 1200 LOC), a good thing if you prefer python to JS

Literally what? So they rewrote their app, which was most definitely in a state of affairs that warranted a refactor, and then concluded it must’ve been the limits of React. Oh, and rewrite the back-end too while we sing the virtues of this library claiming a lower technical investment.

Believe me, I’ve got plenty of gripes with React. It’s very easy to build the wrong things with it. And the ecosystem is an overgrown mess. But I’d still prefer a problem of technical curation over debugging a library which marries HTML and server-side templates with an untyped DOM runtime.

I just don’t buy how this is a productive way to build websites. Having the functionality of HTMX natively supported would be nice but you’d still need much of what React does. HTMX’s docs seem to hand wave away front-end state management as something that no longer applies. Simultaneously, they also assume that every API you interact with will return HTML partials.

What could convince anyone to abandon the rich and bountiful lands of JSX and TypeScript? Who would prefer to move into a write-only and stringly typed HTML that competes with PHP for the slot of least performant debugging experience?

Maybe the answer is in the question…

Lookup a stenographer’s keyboard. There is a learning curve but a chorded keyboard can exceed typical typing speeds. I imagine a T9 isn’t too different in this regard.

That is a wonderful question and is exactly the sort of thing that should be on the Babel website. You’ll find no such explanation or even a summary of trade offs that come with adding Babel to your app.

It’s assumed that if you want to support older browsers, the next logical step is to add Babel…forever. An incredible trick happens here, where the developer thinks they added the magic package which only bears a “tax” on the poor sap who’s stuck on Internet Explorer, presumably running eye watering amounts of polyfills on 32 bit limits of RAM.

In my opinion, the Babel team should start looking for a strategy that aligns with a world of evergreen browsers, and untangle the web of feature polyfills from syntax transformations.

It’s also not too wild to think that Babel is a symptom of a larger problem. JavaScript lacks a versioning mechanism when new features are added. A more self-aware Babel could use their connections with the TC39 team do what all successful JavaScript libraries do: become part of the standard library a la jQuery and CoffeeScript.

Alternatively, reconsider the velocity that Babel introduces to the JavaScript ecosystem. These tools might actually be self perpetuating their existence by making new features so readily accessible.