If you get laid off, it is your personal relationships that will help you land another good job while everyone else is fighting over the scraps that get posted online.
Still doesn’t make sense if you believe that AI is making a meaningful boost to productivity.
If you are the kind of person who thinks AI will drive down the wages of software engineers that much, you have to think that it is at least a 2x multiplier.
$65k salary all in for a company is easily $100k. So spending anything less than $100k would be what you would aim for.
The mean height for men at 20-29 is 69.2" and 80+ is 67.1" (measured in 2015-2018, the last data I've found) [1], which could be interpreted as shorter people having lower risk of all mortality. One could say that people are just getting taller over time and 80+ y.o. were shorter at their 20-29, but we also have the median height for 20-29 fro 1970s, when 2018's 80+ were 20-29 - it's actually 69.7" [2], men in the US are getting shorter over time, so unless people naturally shrink 2" with age the data points to shorter people having lower risk of death.
"People typically lose almost one-half inch (about 1 centimeter) every 10 years after age 40. Height loss is even more rapid after age 70. You may lose a total of 1 to 3 inches (2.5 to 7.5 centimeters) in height as you age."
So people DO in fact tend to lose about 2 inches at age 80 versus their younger selves.
The actual studies [1],[2] that tried to measure this came to very different rates of height loss though: 3.6 cm and 6 cm from 40 to 80 in men. This does not look like a serious fact.
The difference was 3.6cm in the study that measured 10 more years 30-80. And 5cm in the study that measured 10 fewer years 40-80.
The studies were conducted over different time periods when average nutrition changed, and demographics changed. And the study demographics just vary by location.
Height loss with age is incredibly well documented. Here’s a few more studies.
This is just basic medical textbook information. No one in the world is arguing that this phenomenon doesn’t exist.
I am not saying that. I am saying that the theory about absolute amount of fat being bad for health, as stated by the comment you responded, seems to be supported by data.
> I asked about the specific claim that absolute fat was bad for your heart.
There is no word "heart" or any to this effect in the message you replied to so I did not understand that was what you were doing. I took your question as an attempt to attack the theory on the basis of prevalence of some heart conditions in shorter people.
Some are more common in short people and some are more common in tall people. Hypertension is one of the ones more common in short people and is significantly more common than the rest combined, so your overall chance of having some form of heart disease goes down as you get taller. However, the forms of cardiovascular disease more common in tall people (e.g. atrial fibrillation) are more likely to actually kill you.
In reality most business can do things like cut hours for staff, postpone upgrades or long term maintenance, cut amenities, raise prices etc…
If most businesses were structured in a way that a small decline in customers immediately puts them out of business, any minor economic downturn would be an unrecoverable positive feedback loop for the economy.
I’m not saying a 10% drop won’t put a lot people out of business, but it’s not as much of an existential crisis for the economy as a whole as that story makes it seem.
That’s not what I was saying. I’m saying that we have small downturns where consumer spending drops yet those drops don’t result in crisis levels of small businesses closing. Which it would if most of them were structured like that.
I was going to say that curring hours just offloads the problem onto their employees, but the reality is it does that and creates new problems for the bbusiness.If the employee cannot afford to keep the job, they will be forced to search for a new or additional job. The business is either hiring and training inexperienced people, or dealing with staff who have reduced availability.
They also cannot do much about fixed costs; postponing maintenance typically increases long term maintenance costs; postponing upgrades, cutting amenities, and raising prices may deter even more customers (keep in mind, nearly everyone is feeling the pinch these days). That is assuming that the business isn't doing that already.
All of those things are true. There are downsides to any of the levels they can adjust. I’d there weren’t, they’d already be doing it.
But it’s wrong to model businesses as if they have no ability to increase profit per customer and predict catastrophe from minor reductions in customer traffic.
They can and do figure out how to do more with less.
Sure that’s one of the argument for why they do it but the money doesn’t directly to most small businesses, we do have small downturns, and they don’t result in the majority of small businesses going out of business.
Most small businesses fail because they were never serious businesses to begin with. A business closing down after running for a year with no profit isn’t relevant.
You can’t always tell the difference, but you can filter out businesses that lasted less than a year, temporary businesses that were setup for real estate transactions, and business that never made a profit.
>This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way.
This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM).
Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project.
If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
>What tends to happen is that the EMs and PMs look at who’s free and give that person the task.
The gp you replied to qualified it with "enterprise software" (LOB, CRUD, etc aka "cost center") so your observations where senior -vs- junior engineers being more fungible can be true.
However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.
One way to describe the differences of complexity and criticality in various parts of the source tree is the "core" parts vs the "leaf" parts. E.g. in a game engine or Linux kernel, the deep parts of the engine or os process scheduler where the tight loops are located are the "core" parts. They most likely would be worked on by the most senior people.
But the game engine may have some less complex code for handling text width on a menu for different foreign languages. Or the os needs a new menu option on the installer to ask for the users age. Those would be more "leaf" functionality in the source tree. A junior could get assigned to those parts with less risk. After a few years of experience, he might be trusted enough to work on the deep "core" logic without screwing things up in catastrophic ways for a million customers.
A product with several million lines of source code will invariably have both the "hard parts" and "easy parts" so the new hires and juniors will work on the easier stuff first.
There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
> There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.
By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!
>, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective.
You misread my comment as some dig at CRUD LOB enterprise coders. I used to work on enterprise ERP code with 20000+ tables. Yes, I agree it definitely wasn't simple.
Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.
That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.
Maybe some enterprise software teams can work like that. However, none of the engineering-heavy type of codebases can treat seniors and juniors interchangeably.
All engineers should be spending more time "planning" than "doing".
Even before LLMs, the coding tasks were less than 50% of the time spent on all my Jira boards in the past 15 years. It makes perfect sense that they are assigned based on available capacity. By the time the coding begins, it's already too late to worry about implementation.
You're right that small tasks are trivial enough to be assigned to anyone. That's the point. That's how it feels to work on the "good" projects regardless of complexity. Planning a complex project should result in more tasks, not harder tasks. Your epics and stories can sometimes vary in points, but your tasks should not. A primary goal of the planning phase is figuring out how to keep them as low as you can. The points stop being meaningless when you think this way. They tell you where things are too lumpy. You throw more planning time at those lumps.
If assigning to a senior produces better code, you're not spending enough time planning ahead.
> Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.
That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.
That’s not what I was saying.
I was saying that the perception of management is that the tickets are interchangeable. Not that the tickets are actually interchangeable.
Notice what I said after that. That this usually results in seniors coming in at the end to rescue the project.
> However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.
That's great and all, but that's a small minority of all software written. I'd love to work on projects like that but ultimately I have to pay the bills. Many software engineers are in the same boat I am.
Now I guess I'm just up shit creek because I built a career on SAAS work that was available instead of holding out hope I could get in at my dream job working on game engines or some other non-SAAS product?
Sorry if I sound bitter. I'm variations tired of hearing variations "If you only worked in SAAS you were always close to meaningless and now we've automated you so you don't deserve to earn anything anymore". Feels like every day.
For what it’s worth I’ve not heard anyone ever say anything like that about SAAS developers, it’s a scary time for us all but software dev isn’t going to stop overnight.
Nor have I seen this "punch every hiccup into google" approach. Most errors are things that (a) you've seen before if you have any significant experience and (b) have a pretty obvious cause if you simply read the error message and look at your code.
Sure you might lean more on Google or SO if it's something you haven't seen before, or it's something deep in a stack that isn't code you actually wrote. But as the noob eventually learns when he thinks he's found a bug in a runtime or compiler that thousands of other people are using every day: No. It's probably your code.
I suppose there are people who never advanced beyond the "type (or copy/paste); run; google the errors" loop, but I've never seen anyone with more than a year or two of experience doing that very often.
I'm more likely to have several tabs of the libraries/language docs open than opening Google. And when I do, it would be just a faster way to get to the docs. After a while in a project, my history and bookmarks list is much more useful than a web engine. If it goes into months and years, it's mostly tweaking the code to solve some bugs, meaning a lot of reading of source code.
> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
I would have said the same thing for the first 15 years of my career across several jobs and acquisitions.
Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things.
The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them.
It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.
Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!
Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.
I'm there now. I have a team of low level engineers in Hyderabad and Bengaluru which can be useful but I have to spend a lot of time writing very detailed specifications and instructions to walk them through what has to be done. There are plenty of instances I can point to where it would have been faster for me to implement the solution myself, by hand, no Claude. Now bring Claude into the mix and I do not really have any use for these engineers at all aside from providing operational support during IST.
We're not too much an AI-friendly company yet, so we don't officially have Claude access, but I can tell with certainty that several of my Indian teammates are using Claude anyway. I'm pretty familiar with the style of code it creates. And the comments are decidedly better English, which is a big giveaway itself.
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
Same but with 10 years, and I don't think I would do well in a place like that. That removes you from writing code and there is a similar complaint about relying too much on AI and not writing enough code on your own.
I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.
> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear
I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.
Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.
The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.
I’ve worked at many startups and consulted at many more over the last 20 years. I’ve never seen 2 million lines of code happen that fast at a small startup.
15 devs putting out 400k LOC a year into the same codebase is not normal at all. I’ve never seen anything close to that kind of rate of growth across that number of people.
And 50 engineers is not even remotely close to a small startup. I have worked at a startup that had 50 engineers after a few years, but it was a multi billion dollar unicorn.
How long has your startup been around? I’ve worked at plenty of startups over the past 20 years. Including one that was still calling themselves a startup 10 years out. The org I work at now was a startup before my tech giant employer acquired them. We have a very bloated and very profitable 8 year old codebase that is barely 500k LOC.
I’ve never seen a startup with a multi million line legacy codebase.
In response to a question about a legacy codebase at a startup. That implies that they think whatever they are doing is common. And forking a multi million line codebase and heavily developing it isn’t common for startups.
Let’s say that’s true. That doesn’t mean that we won’t have a higher percentage of bad implementations because more people are rolling their own.