Scientists don’t have particularly great job security as a group.
14,676 karma · joined September 16, 2009
Email: erik@snowedin.net
!RemindMe 150 years
OK, I'll bite. How is the an abject disaster on the horizon for... let's say, novelists?
I really enjoy the challenge of plotting a course out of a hole like that. However in my experience without management buy-in it just won’t happen. Even if you as an engineer do the planning work to make it as easy as possible to pick off low hanging fruit, you’ll typically be seen as “off task”. You’ll get lip service about how code quality matters, because without that they’ll scare away the other devs. But they’ll be hoping you give up and just focus on delivering what the management team is asking for each quarter.
It takes a ton of patience and management hand-holding, on the scale of 2+ years to shift the culture. And you have to be willing to forgo any chance at personal advancement for that time. Because you’re “off task”.
I think you could take that approach and eventually get an advancement bump around the 3-4 year timeframe but it’s not the fastest way to advance by any means.
And the total failure rate for an endeavor like that is pretty high. Maybe more than half.
Still, it is fascinating work.
If anything Carmack’s response was unconcerned, saying how CS jobs may change.
@dang could we maybe change to “Carmack responds to student concerned AI will make CS jobs obsolete”?
But I haven’t used them personally so I don’t know. Will be interesting to see how folks do with them.
So the USDC dip is certainly not the worst thing to happen to currency holders this decade.
In cases where I want to get ideal performance, I sometimes separate out a plain JavaScript service and wrap it in a React hook.
So for example, let’s say you have a massive array of like 100,000 objects. You presumably aren’t putting that entire array on the screen at once. So you could keep the array in a normal JavaScript class, keep in instance of that class in state, fire events into it, and then query out the slices of data you actually need.
Those smaller slices can be generated each time there is a state change, but you don’t need to re-allocate the big array.
Even if you do need to show the entire array, say as a data plot, you can render directly to a canvas, but still wrap that canvas and the I/O in a React hook. React works quite well with these “plain JavaScript” escape hatches in the rare case they’re needed.
The other place I’ve been using this approach is for drag and drop hooks, where the complexity of managing React renders and coordinating state changes on every mouse move is just too much. Instead I have service class that updates the few DOM nodes that need to be changed every frame, and I only fire off state changes when there are meaningful transitions (hover over something, drop something, etc.)
It’s not that it doesn’t work, it does.
But I’ve found there are basically two scenarios:
1) Simple cases where there’s no risk of contention and you can just operate as if your state variable is up-to-date.
2) Complex cases where you have state changes coming from multiple directions and contention is a concern.
In the second scenario I just go straight to useReducer. It is much more reliable than useState when there is the possibility of contention. And it’s much easier to reason about than having a bunch of setState calls all over.
IMO the setState((oldState) => newState) pattern is a half measure that’s almost never the best choice.
I think this is where your proposition causes me to raise an eyebrow.
If you can stay 100% within your framework then I can accept it will be simpler and more productive than React.
But this architecture of “95% in-framework and 5% JavaScript spaghetti”… I don’t trust that. That sounds like a lot of days burnt trying to bolt that one feature onto a framework that doesn’t support them. And a lot of days debugging into the framework internals to try to understand which possible implementation of that feature won’t blow up by crossing some assumption of the framework. And I’m not sure you can argue as convincingly that’s less effort than the 100% React solution.
IMO the beauty of React is you can do anything you’re asked to do. There’s alway a “React-y” way to do something. That’s because it’s lower level than a framework. It’s just a set of primitives. And pretty well thought out, battle tested primitives at that.
And, when you do it right, you can have a very large piece of software that’s made entirely of small, functional modules. And there are simple rules for following the control flow. Once you understand those rules (and it does take a few years to really grok them) then you can drop in to any module in a massive system and follow the control flow easily.
In a framework you don’t have that. There’s various points where your code calls into some declarative interface the framework has exposed, and then *magic happens* and the wrong behavior pops out on some other end of the application. It’s a debugging brick wall and in my experience it’s a massive time sink. Even in React many third party libraries also put you in this position, but that’s a whole other rant…
But that is React’s superpower: when you use it correctly your time spent debugging any one defect is closer to O(1). With more “black box” frameworks your debugging time can be more like O(n), where n is the size of the codebase.
For small codebases, there’s no difference, or maybe the framework is faster even. But for large codebases I think React has a massive productivity boost there.
And all of this is predicated on that 5% number you quoted. If you can stay 100% within the framework, go for it. But in my experience business needs are always going be pushing 5%, 10%, 20% of the “special requests” and if you don’t plan for that, they can start taking up 50%, 60%, 70% of your time.
I agree with you that it’s not fair, I’m just acknowledging that the adjudication of fairness happens outside the reach of science. It’s a matter of values not evidence.
1) Black people are not actually less “good at stuff”, we just have a habit of defining “stuff” in a way that excludes the things that black people are more likely to excel at.
And, 2) Where black people do statistically worse, it’s not due to any innate difference, it’s because socially accepted “normal” support systems are more useful for people with challenges more common in white populations than challenges common in black populations.
So the idea is, if you change the support systems and measures of success to be more universal, the differences will go away.
And then the metric for whether administrative bodies have succeeded in this is “equal outcomes”. What you call “racism”.
But the inferences on which this affirmative action position are based make rational sense. There’s no logical flaw. There’s no conclusive evidence for these hypothesis either, but they are logically plausible.
The opposite perspective is the same: rational, yet lacking any basis in evidence. That is the perspective that black people, through biology, socialization, and/or culture, are actually “worse at stuff”. And the support systems and performance metrics are fair.
There’s no way to prove something is “fair” or “not fair” in the face of “unequal outcomes”. It just comes down to what you want to believe. There’s no rational basis to come to one conclusion or the other.
I choose to believe that all of the big categories of people are pretty similarly “good at things” but I can acknowledge that belief is a leap of faith. The truth is unknowable.
If anything I expect computers from 1985 to be much better “preserved” than physical history from, say, 885, no?
Granted you have to resist the urge to use them as door stoppers and keep them in a controlled environment. But an archive is a lot cheaper/more stable than a living museum.
Back in the day we used cutesy names for boxes, and we did it for good reason:
Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off.
You would frequently rebalance which services went on which box, in order to maximize performance.
But these boxes weren’t services themselves, they were just the machine some set of services happened to run on.
So we gave them cute names because the hardware was largely meaningless. They had no inherent purpose, so we named them Athena, Zeus, etc so we had something to remember.
These names were largely not used for the services. Maybe you did have your FTP service on Athena, and maybe that was the only service on there. You still served it from ftp.techdazzle.com or whatever.
I feel like people just ported this concept forward into the microservices realm because it’s fun, even though it doesn’t really make as much sense in a cloud environment.
Maybe that’s actually a good thing for some organizations, I know many CTOs spend most of their time trying to make cleaner separations between teams.
But if you want a culture where people understand and evolve the larger architecture from time to time, cute names are going to make that less likely.
Keep in mind I was unable to afford groceries many of these months.
In the end, they cleared out on that date and I never heard from them again. Even though we were quite close at one time.
Money well spent really.
I’ve heard people say “don’t write your own auth” but I’ve also spent a LOT of time hacking auth libraries to fit custom designs, custom flows, etc. And building tooling to integrate libraries with other infra: middleware, test mocks, etc.
My question is this: If you have a full time dev team maintaining an application, is it really that much slower in the long term to maintain your own auth flow?
I’ve basically given up on UI frameworks like Material UI because of this issue… if you’re building something customized, and you have full time devs to support it, the “time savings” of using a library like that is, in my opinion, a scam.
You feel like you’re getting a lot for free because the stuff that works out of the box is very visible. But the months and months of cumulative time spent dealing with the complexity that comes from customization and extension is invisible, because it’s just bugs you fix, or tasks that take a week instead of a day.
My team lost probably a dev month this quarter to react-select because of this. I’ve seen the same happen with Popper, react-table, and dozens of other supposedly helpful libraries.
I’m curious what other folks think about auth specifically though. Does auth fit into this pattern, or is it something that you really can meaningfully outsource to a library?
If you have the posture of “I’ll take anything I can get” I think that actually puts you at a disadvantage in an interviewing situation.
In my experience employers can tell who is actually trying to evaluate fit themselves, and who is just saying what they think needs to be said.
I find it’s easier for both parties to make an offer, if they know the counterparty has done their due diligence.
For me when accepting an offer I’m also doing the same, evaluating whether I think the company has actually vetted me properly and has reason to think I will be a good fit.
There is so much mystery in the hiring process, I really need the other party to be doing their half of the work. And that means saying no to opportunities that don’t feel right.
That doesn’t mean I walk away from anything that’s not perfect. It just means I am looking out for reasons to say no, in addition to the reasons to say yes. I think interviewers pick up on that and it helps me get offers.
In an organization where you have excellent coaching staff, excellent tech leads, and excellent project managers, what would a manager focus on?
I have the same question for “product managers”…
In an organization where you have excellent user experience designers, excellent user researchers, excellent tech leads, and excellent project managers, what would a product manager focus on?
I think both of these roles too often seem to become an overarching “I am the Representative of The Business Goals in All Matters” type role. And… do we really want that?
Or are there better job descriptions for managers and PMs that would create more clarity around what they are responsible for and where they defer to their colleagues?
Genuine question because I am starting a company and I will eventually be hiring for these roles and I would like to have a better job description than the traditional ones.
If a coder can write code, but they can’t do that, they’re useless to the org. It will be faster for me to write their code myself than to maintain what they’ve done.
So really that’s what I’d need from an AI coder. Writing the code is good, but can we talk about it and can you learn the specific architecture principles we have applie in this specific codebase.