Personal experience on this. My degree (physics) was nearly completely orthogonal to my career (software engineer).
But I have no doubt it helped me get not just my first job, but also subsequent ones, probably due to 'his code/tech talk could be better, but he seems smart and has a physics doctorate from a prestigious institution'.
Think software hiring+quality would be much better if we had an apprecticeship culture, instead of based on perceived prestige from excelling at University.
I agree but the very employers who are the literal gatekeepers to a good job often use credentials as signals right from the start, which contributes to the credentialling arms race that I think we've been going through.
Apprenticeships and trade schools will become a strong alternative path as soon as employers accept them to be. Moreover, often times the credential itself isnt the big deal, just its viewed as a competition and someone who got a good GPA from a top school seemingly displayed an ability to do well in that competition.
I wish it were different, but I don't see employers changing their game anytime soon.
"Non technical management - this should speak for itself. I've done it before to much regret."
I wouldn't put this as a con, I've seen lots of engineers turn into terrible managers, because the skills are completely orthogonal, they also then lose touch with the tech - because that's what happens if you stop coding for even a few months.
Vice versa, I've worked with lots of good non technical managers, who respect and defer to you for technical decisions, planning etc
And of course the other way round, also seen good technical managers and bad non technical ones.
In summary, technical experience of a manager is not an indicator for me, what is are the human factors, do they micromanage? Are they happy to cede control and delegate? Do they give realistic deadlines instead of death marches?
The ways engineers are terrible managers non-technical managers are often terrible too. In addition to that, they also know less about work itself and are more likely to be insecure about that. They cant distinguish between good and bad engineers replacing various signals for that and are easy to manipulate by charismatic but not too good engineers. The lack of knowledge shows up in small things and big things and overall bluffing. So you get same problems plus some more.
Non technical here does not mean "does not have technical school". If that person took effort to learn, then he can be technical without degree etc obviously.
"The ways engineers are terrible managers non-technical managers are often terrible too. In addition to that, they also know less about work itself and are more likely to be insecure about that."
I would put that as another human/personal trait, the ability to openly acknowledge ones limitations and delegate/defer when someone else has more expertise than you. For example, when making a technical decision, deferring to the tech lead & individual contributors.
If anything, a technical manager whose tech skills are/have slipped away is more likely to be insecure than someone non technical.
Technical manager needs to defer decisions too. No amount of knowledge makes it good idea to micromanage or not to build consensus with those he manages.
However, he still have better ability in deciding who to defer/trust to, better sense on bullshit vs reality, better idea about nuances of decisions and knows words people use. That shows up in how meetings are moderated, people know it and also some will always try to game the manager. Non technical manager is reduced to parroting sentences and attitudes he does not understand fully. Knowing something is not a disadvantage, ever. Not knowing something is.
Every manager needs to make some decisions too. And in there, knowledge helps. Knowledge that slipped away is better then no knowledge and worst then relevant knowledge.
I'm not sure it's easy for a software engineer to develop a model, it's quite an orthogonal skill, you need a solid grasp on mathematics and especially statistics.
It's not easy, but there are capable developers that are proficient in data science and it may be cost effective to hire one such (high cost) programmer than one (average cost) data-scientist and another (average cost) programmer.
True, but those software engineers exist, and FAANG and FAANG-adjacent companies offer the work opportunities, prestige and salaries to attract those "twofer" engineers.
Must have been really exciting time to be particle physicist in those days. SLAC & other colliders enabled a revolution in physics, culminating in the formulation & verification of the standard model - a truly unparalleled feat of scientific progress.
Minor clarification. The standard model does not describe gravity. It ignores it, which is fine at LHC energies because it's orders of magnitude weaker than the other three forces.
At the planck energy scale, this is no longer the case, the relativistic mass of particles becomes so big that gravitational interaction is too strong to be ignored, and the SM loses it's ability to predict how particles interact, decay, combine etc
> the relativistic mass of particles becomes so big that gravitational interaction is too strong to be ignored
It's not relativistic mass that's the key factor: relativistic mass is frame dependent, and it's not the source of gravity. The relevant factor is stress-energy: energy density, momentum density, pressure, and other stresses. The key factor at the planck energy scale is that the density of stress-energy is high enough that we can no longer have confidence that classical General Relativity is an accurate description of gravity; we expect to see quantum gravity phenomena at that stress-energy density.
I always understood that the Stress–energy tensor in general relativity has a momentum component, so two electrons whizzing past each other at near the speed of light would exert a stronger gravitational pull between them, in all frames of reference, than if the electrons were 'at rest', relative to each other? I admit I didn't study GR so happy to be corrected!
> I always understood that the Stress–energy tensor in general relativity has a momentum component, so two electrons whizzing past each other at near the speed of light would exert a stronger gravitational pull between them, in all frames of reference, than if the electrons were 'at rest', relative to each other?
The stress-energy tensor does have a momentum component, but remember that all components of a tensor are frame-dependent. So is "gravitational pull". Obviously the trajectories of two particles passing each other at relativistic speeds will be different from the trajectories of two particles at are at rest relative to each other at some instant; but the difference is not quite as simple as "more gravitational pull", although the two particles having relativistic velocities does mean that the center of mass energy of the system is larger than it would be if both particles started out at rest.
(Actually, the electromagnetic interaction between electrons is so much stronger than the gravitational that the gravitational effects are negligible in the scenario as you state it; but we could eliminate that issue by considering, say, two neutrons instead. My comments above assume that the scenario has been modified accordingly, which is why I said "particles" instead of "electrons".)
Indeed, I've never in my career (in high level businesses, I.e. Finance, advertising) seen such a thing as a proper 'specification'.
It's more the business has a high level, rough idea of a change/feature to improve the business, and we figure out together the exact details, some of which surface during implementation, and then verify it gradually in the wild.
We could have spent x10 time instead drawing up a formal spec up front, but it would have so many assumptions baked in, that it'd get invalidated in the wild anyway.
So the people designing the spec don't have enough information about the problem space. As the programmers begin working, they explore the problem space, extract the information they need to understand a solution, and then they can actually solve it. Bit of a Schrodinger's cat situation... The solution must remain undefined until observed.
Imagine that's part of the challenge. Since python is dynamically typed/duck typed, it's hard to audit all usages of a variable. I.e. If I see a py2 string declared, how can I be 100% sure I don't break downstream components by making it a bytes or py3 unicode string? Some might be using it as the former, others the latter.
You'd need insane test coverage, of all possible code paths, to be 100% confident.
I was responsible for the Python 2 to 3 migration for various code bases at work. I used 2to3 to check for issues, but did most of the code rewrites by hand.
Most of the conversion difficulties were related to Unicode/text/binary string handling in Python 3, and 2to3 didn't catch all of them. This was the biggest challenge of the entire process. Stuff would fail in production because due to improper string handling. Python 2 was remarkably permissive (i.e. loosy goosey), whereas Python 3 is stricter and arguably more correct, but this strictness has a cost.
The other class of problems is the restructure of certain std libs, like urllib. We took the opportunity to move away from "urllib" to "requests".
This site [1] was invaluable in understanding the migration issues.
All in all, apart from breaking Unicode issues, the migration process was fairly easy.
That's the energy scale where the force of gravity becomes strong enough to influence subatomic particle interactions.
Currently, our model of nature at subatomic scales (the 'Standard Model') does not include gravity. This is fine for LHC energy scale, because gravity is so weak compared to the other three forces (electromagnetism, strong & weak nuclear force), that it can be ignored. The mass of quarks, electrons etc is tiny, you can make precise predictions on stuff like 'particle X will decay into particles Y & Z at this likelihood', without accommodating gravity.
But at the planck energy scale, gravity is too strong to be ignored, and the Standard Model breaks down, it can't make predictions. So this is why the planck scale is where you're 100% guaranteed to see 'new physics'.
EDIT: think the reason gravity becomes stronger at higher energies, is because the _relativistic mass_ of particles increases with their velocity.
So if you bang two electrons a&b together at nearly the speed of light, the effective mass of electron a from the frame of reference of electron b will be orders of magnitude greater than the 'rest mass of electron a'. Because strength of gravitational interaction is proportional to mass of particles involved, electron b will feel stronger gravitational pull of electron a (and vice versa).
So if the electrons are traveling at planck scale speeds, the strength of gravitational interaction becomes comparable to the electromagnetic interaction between them. Then all standard model predictions of how the electrons interact goes out of the window, because SM cannot model gravity.
But I have no doubt it helped me get not just my first job, but also subsequent ones, probably due to 'his code/tech talk could be better, but he seems smart and has a physics doctorate from a prestigious institution'.
Think software hiring+quality would be much better if we had an apprecticeship culture, instead of based on perceived prestige from excelling at University.