According to levels the pay band caps out around $250k and a principal title. It's good but probably not enough for most to put up with the culture long term.
The top universities are not setup to mold intellectually rigorous and curious people. It's setup to make hard working, and increasingly sycophant men.
My lab mate is a former drug addict with two years of art school. Easily more intellectually curious than anyone I met at McKinsey.
How different the world is? But your credentials worship fits right in with this community.
Ideologically aligned if nothing else.
Well we can all at least imagine being some 4.0 Ivy League dude who only interacts with 4.0 Ivy League dudes. He’s not going to think that everyone he interacts with range from merely brilliant to the most studious-enlightened hardworking top of the morning fellow (or whatever adjectives to use). He’s gonna think that some of them are idiots. It’s only human.
I was a B/B- student from a foreign top 100 university. I don't know how I got accepted to a top 5 engineering school in the US. I accepted and ended my PhD with a 3.3. Im not very bright or hardworking.
What did I see at the university? Very hard working people. Very interesting research. Very shallow knowledge outside a narrow domain expertise.
These are the folks McKinsey hires... but these shallow thinkers are sent on 6 week projects for companies in industry they hadn't even heard before.
Once, no one in the team knew what product CompanyX sold... CompanyX is a a top tier multinational consumer product brand that routinely sponsors sports events, including TV ads.
Often the B+ students are way sharper but have poor incentives to work for the As. This creates bad work habits for them.
The As, then, are better at the game. Once you've become a TA and have to grade the exams, you realize how A grades are quite within reach:
For the professors, being an easy grader has almost no downsides. The contrary is a minefield of trouble. "A" students will "ask for clarifications" for any minor mistake, knowing professors will often throw them a point or two.
The exams are, typically, slight variations of problems from assignments. Often, they are the same.
Exams have no curveballs; problems or situations that you have never seen unless you did extra readings. No problem which to solve you must have read more or fully understood the core material.
The TA is primed to give 40% of a problem's points for free - just restate the problem in math and draw a picture and right out the door you get 2 out of 5 points.
Note that, as far as I can tell, this is not generally true for "hot" topics like CS or bio. These programs have so many eager kids that the material is hard. But then these fields get hard working, bright, kids that don't actually care about the material - they go to McK. Within ten years they've forgotten everything and are just consulting parrots.
Is a formal sentence which uses capital letters more sincere in its beliefs?
You can perfectly well believe that thinking that the echelons of academic success is a frictionless gold sieve is just a milquetoast belief. Believing that your beliefs are milquetoast are most often integral to said beliefs.
...what point are you trying to make? you wrote a bunch of words, but they dont seem to be an attempt at communicating anything. certainly not anything that contributes to a conversation.
> Our hope is that these extensions can over time be contributed to upstream OCaml.
Yeah, its more just extensions to support their use cases at scale. Think of it more as bleeding edge ocmal, once they work out kinks/concerns they'll get merged back into the language OR if it remains ultra specific it'll stay in oxcaml.
Python gets forked in other investment banks as well. I wouldn’t say that is evidence of any deficiencies, rather they just want to deal with their own idiosyncrasies.
The main user has been writing extensions to the compiler that they test before pushing for integration like they have done for the past twenty years or so. They publish these versions since last year.
Hardly a failure and certainly not something mandatory to keep things from failing over. Your initial comment is extremely disingenuous.
A different perspective is that JS has made practical application of PLT part of their secret sauce, and deepening into their PLT roots is thickening the sauce.
This is the wrong interpretation of the oxcaml project. If you look at the features and work on it, it's primarily performance or parallelism safety features.
The latter going much further than most mainstream languages.
or you could sell a single broad market etf lol. or buy a short etf.. it hasn't been hard to selectively exposure yourself to dang near any slice of equities since the ETF boom
Short ETFs are usually leveraged and make for a really good way to lose money.
Realistically, timing is the issue. "This is a bubble" is worth ~nothing. "This is a bubble and it will pop in late December" is worth a lot if you're correct.
I was going to agree with you until the implication that it's learning the nitty-gritty details that's important.
I can teach someone the details on the job. Give me a new grad with strong fundamentals, a love of programming, and an interest in the domain and I'll teach them in sixth months whatever they missed in college that's relevant to the job.
However I've noticed that the fundamentals are so watered down, even at top-tier schools, that young devs like that are harder and harder to find.
Maybe it would be simpler to just impose a nominal tax on the total number of job openings a company creates throughout the year. Maybe as a % of the role's salary. You could even rebate it against employer payroll taxes so they get the money back when they actually hire someone.
> We tax things we want people to do all the time.
True. But why not think about ditching those taxes, and replace them with taxing things we don't want people to do? There's a double benefit - tax revenue is raised, and people do less of those things undesirable to society.
For example, "sin" taxes.
For other examples, taxing pollution. Taxing the conversion of forest land to a parking lot. And so on.
Tobacco tax in Australia is an interesting example. A lot of people may have stopped initially but there was a more gradual decrease over time as the tax increases annually by CPI + 5%.
The problem is not everyone will stop and they now face is that at 70% of the price it's encouraging a black market for illegal tobacco with associated crime and a decline in tax revenue.
If the tax works you have to keep continuously increasing it every year. At some point that becomes detrimental (I mean there are good reasons why we don’t ban the usage of fossil fuels entirely..)
To refute the parent, you have to argue that it's a good idea, not just that it's done. It's not hard to find plenty of things that people do which are terrible ideas.
Most economists agree that income tax and corporate profit tax should be eliminated and replaced with capital gains tax. Politically impossible, of course.
You want to incentivize them FILLING job openings. Nobody cares how many jobs are posted. And posting 100 openings and filling 50 is the stated problem trying to be solved here.
The rebating idea resolves this quite neatly though. Make posting a job opening that eventually gets filled free after rebate[1], and posting a "dangling" job opening that never fills incurs tax.
Now, I can think of a dozen loopholes to get out of this[2], but it's not that it's going to disincentivize hiring.
[1] or maybe even better than free (puts a little tax incentive for hiring and keeping people beyond the typical probationary period).
[2] Can job listings be revised? Just recycle the ghost job listing in bulk before the deadline and convert it to a totally different position (Software Engineer -> Cashier) Can they not be revised? That seems like overreaching ridiculous Soviet red tape.
Nothing like this is ever going to happen. It would be incredibly expensive (on both the employer and the government side) to administer, and it would be portrayed as a tax on hiring, because that's exactly what it would be.
Rules about what a job posting can and cannot say can definitely happen, and have happened (see: salary ranges, because of Colorado's requirements). That's what CNBC depicts this proposal as comprising. Unfortunately, under the hood, it's closer to what you're talking about.
Instead of taxing good behavior, we could just criminalize bad behavior. Besides, companies spend billions on advertising. In a weird indirect way, "ghost jobs" are advertising.
How many dependencies does your package.json file declare? Which versions of node/npm does your team use?
If you're on recent-enough versions and are using any popular libraries, you will have seen the deprecation notices pile up during npm install for downstream dependencies.
Dependencies issue is not exclusive to frameworks. If you don't want to reinvent the wheel, there's no way around using packages, even if you go with vanilla JS.
Do you mean your package.json literally has no dependencies declared (or you don't even have package.json)? If so, you're not using frontend tooling like 98% of development teams.
I don't have a package.json. I don't use npm. But I do use React. Yes, I am not like [insert scientifically determined very very high percentage] of teams out there — but that's exactly my point. There are ways to do frontend development without the treadmill.
Thing is, we are the reason for the treadmill being there: we love the new shiny, we call software that is stable "dead", we actively mock software that doesn't have a lot of churn as "not being developed". So I guess we deserve what we get.
Java and .net developers also uses dependencies, and they too need to upgrade their dependencies (and sometimes switch out deprecated stuff). Definitely not a Frontend issue.
I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods...
Even a well-maintained project like React can't escape the squalor of its ecosystem.
I don't always have this option, but usually these days I choose vanilla JS, imported with no build system, do as much as I can with Python/Django on the backend, and opt out of the JavaScript ecosystem entirely. I haven't regretted it.
Some of the problem with React and npm is that they are a victim of their own success.
React lets you suck in 80 components from 15 different vendors and it works. NPM lets you suck in more dependencies than many other systems because it deals with diamond dependencies better than other systems [1]
Because you can mix and match so many widget sets no wonder you will have trouble when those widget sets change.
[1] package A can import version B of package C, package D can import version E of package C -- so long as A and D don't exchange objects from package C there is never a problem, even if they do it might work.
The problem is more cultural than technical. JavaScript folks see the ready availability of dependencies as a feature rather than a risk, including the creation of a plethora of micro-dependencies (such as the left pad fiasco).
React itself is an exception which is well-developed because a competent developer team (Facebook's) depends on it. The vast majority of JS libraries are absolute garbage from idea to implementation to maintenance. Nobody should be depending on these libraries, and yet the vast majority of JS projects do depend on these libraries.
You can certainly run into similar problems in, for example, Python, if you decide to import all of pip with impunity, and there are certainly Python projects with this problem that I've worked on. But Python at least has a core group of commonly used libraries that keep sane dependency trees. You literally can't build modern JavaScript without using some bleeding edge nonsense that won't work in a few years.
Thankfully, as I've said before, you don't have to use the mainstream toolchains. Browsers and standards organizations have been much better about at least not breaking reverse compatibility.
> To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility.
That's a problem with your build system then, not React. There is (or was) indeed a lot of churn in build systems, but you wouldn't have been spared unless you had chosen to not use a build system - which is still possible with React, but not with Svelte, Vue or Angular.
My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
This side conversation started as an objection to the comment, "Whatever framework you choose will be obsolete in 5 years."
The first release of esbuild was November 2020, i.e. it didn't exist 5 years ago. And that release fixed... conditional statements in TypeScript--a pretty basic feature to be broken. Does that sound like something you want to use in production?
So maybe your strategy of only using things that work with esbuild doesn't address the problem as much as you think it does.
You are extrapolating from the past into the future, but a lot has consolidated in the last five years. You used to need babel to use crucial language features that are now supported across the board, at the same time the avalanche of new language features has subsided.
Conditional types (not statements) are not a basic feature.
> You are extrapolating from the past into the future, but a lot has consolidated in the last five years.
I've been writing JavaScript that entire time, and the complete disregard for maintenance has gotten worse, not better.
You seem to be under the impression that because I also write other languages, I haven't been keeping track of what's happening in the JS ecosystem, but you're wrong--I still write JS, because I often don't have any other option.
The fact that I work in other languages means I get to see what I like about better-managed ecosystems. If you're writing JS on both frontend and backend and not using anything else, it's likely that you don't know how bad things are for you because the JS churn has been normalized for you.
> That's a problem with your build system then, not React.
Did you read the sentence that you're "correcting"?
> My current position on build systems is that if it doesn't work out of the box with esbuild, I'm not using it. If it does work out of the box with esbuild, then it's likely also going to work with whatever comes after.
If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. You need to pin your dependencies and use the same versions of the tools as before. It'd be the same thing with libraries if you didn't have a lockfile. Your development tools need one too.
> If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools.
Bold of you to assume I have worked in React for this long and somehow didn't know about this brittle solution to a problem which shouldn't have existed in the first place.
How does your solution handle packages that no longer exist? Let me guess, we back up the packages? Okay, so these packages don't run on new versions of relevant binaries--do we back up the binaries as well? How bad does it have to get before you admit it's a tire fire?
As a BE engineer when that happened, I had just started to become proficient in it, coming from Angular. I threw in the towel and went back to my backend world of peace and happiness. So he's not alone, these deprecations are insane.
I hear from the b/e people about containers, serverless, lambdas, ORMs, queues, schedulers, caches, pipelines (ok, I use these too), databases, API gateways. Oh, but it's podman now, not Docker. And they're moving everything off AWS to Azure. And there's three versions of the API my f/e needs to talk to still in production. And every micro-service depends on a different version of Node. Apart from the one that's in Ruby and the stuff from that department who only use .NET.
I don't believe this promised land of clarity, comfort and purity exists. It's just mess on both sides of the internet connection trying to solve different parts of the problem of turning user needs into money.
More often you inherit a stack and rarely you move away from it. And even if you jump on the latest infrastructure trends, there will probably be enough enterprise customers that they will support it for a while.
The beauty of this is that these technologies all tend to be optional, backwards compatible, and interchangeable. You make your choices when architecting depending on what you want to solve. You can build Hussain Bolt or Frankenstein. On the FE, just the landing page is a mission.
Most likely because you work on apps in active development.
Wait till someone asks you to add some feature in app that was deployed a few years ago and need something new.
Maybe fixing security issues by updating the dependencies? How likely will that happen without you having to rewrite the code of the app?
- they're much harder to learn and understand than the callback hooks from class components
- The built in ones hide all the ways React is managing state for you behind obscure names that don't reflect how or when to use any of them
- The new-ish `use` built-in doesn't follow the same usage rules as the rest of them (you can use it in places you can't use the others)
- the stateful ones create side effects (unless you pretend that state is an argument), so they don't even follow an easy-to-grasp version of the functional paradigm
- they have strange quirks (like you basically have to write your component function to use its hooks before you render anything... so you can't early return)
- the mental model for how to put them together when you're writing custom ones is a little bit funky too.
- the early "advert" for them was that we could put all our domain knowledge together in one place, rather than spread about over multiple callbacks. Given that we usually need to interact with a couple of domains at a time, in time with component lifecycles, I think this makes the code harder to work with rather than easier
You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove.
HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.
But they're not deprecated. Where's the forced churn?
Every place that I've been at has made the gradual shift to migrate stuff away from class components as new stuff gets built or refactored. Seems like a pretty common development habit.
Mea culpa: they’re not being deprecated. But the existence of custom hooks removes the bulk of (if not all of) their utility, and make it much easier to reason about code and make your code well-typed.
I think that's only if you've rehearsed it several times. Although now that I think about it, you will probably have to do it multiple times, so once you get good at it, that may be a reasonable estimate.
My current firm is still on 16 and just trying to make it to 18 because of the deprecations.
All of the WYSIWYG editors that work on 16 are no longer supported. it's a "cross your fingers" in case someone found a security issue (or don't use them)
React 16 is still supported, but it's definitely obsolete.
reply