472 karma · joined February 14, 2022
I respect the candidates who stand for something and can pragmatically navigate the social space of work at the same time. I find that people who just want to shut up and lick boot don't end up being very creative problem solvers. It's easy to say for me as a small biz; different atmosphere in larger corps, but I can't subscribe to the reality presented by the cynical grandparent post here. I think we can be better than this.
Spoiler warning for those that havent played--
I forget the details exactly, but one scene stuck with me. It was a screen in one of the labs, where an experiment was running over and over. It was an uploaded consciousness of one of the test subjects, stuck in an interview room. He kept realizing he was trapped in a simulation and would start panicking. The computer would reboot him, trying another sequence to get him to not realize he was an AI. I think you as the player are given the option to turn him off forever, iirc.
Jokes aside, Figma's stack is super inspiring, and y'all's articles on sync engines heavily inspired my work on LegendKeeper. I appreciate the work you do!
What's the ideal flow on the user-end? Scorecard seems great on the developer side.
To speak on yjs: We use yjs over at LegendKeeper. We're not a huge app, but our users do worldbuilding for D&D, and have amassed over 30+ million collaborative documents, ranging from rich text to fantasy maps to fantasy timelines. Is yjs technically overkill when you have a central tie-breaker? Sure, but the DX is fantastic, and personally I love the idea of my application being truly local-first, even if our core value prop is not necessarily tied to being offline. It also gives me a legacy support plan for our users in case I ever get hit by a bus. :)
On the tech side, you save a lot of cognitive overhead when you can just do:
applyUpdate(docA, update1) applyUpdate(docB, update1)
and now docA and docB are in the same state, no matter what the context. For centralization, adding in a "well, they'll converge once we add a third party" absolutely increases the cognitive complexity of reasoning about your code, and limits your ability to write clean tests. Centralization buys you a lot, too. I don't think one is correct over the other.
There are tradeoffs. There's a memory and CPU cost, and yes, sometimes the "Technically merged state" of a yjs-prosemmirror document is not what's expected. Over seven years and 150,000+ users, we've never had a single person complain about it.
"Back in my day, laptops were about TECHNOLOGY! Where's the conservative stickers!?" Ok, put some "conservative stickers" on your laptop and submit a pic to the site-- no one's stopping you.
I was born in early 90s; all laptops in my memory have weird, silly stickers on them.
Getting some work experience and then starting my own thing was a better fit for me.
Just started my own business instead.
React DevTools have gotten quite good; it’s not hard to catch 99% of perf issues anymore. Inexperienced devs will write bad code in any language; have your experienced devs teach them, or just don’t hire juniors.
I agree that closures in React are annoying though.
Design tokens aren't concerned with implementation. (CSS vars, constants, etc.). Design tokens are an abstraction for standardizing and communicating the values in your design system, regardless of where they show up. Yes, you might implement your design tokens as CSS variables, but not necessarily.