AWS CEO says using AI to replace junior staff is 'Dumbest thing I've ever heard'
(theregister.com)1649 points by JustExAWS 3 days ago
1649 points by JustExAWS 3 days ago
> When your senior talent leaves to start their own companies, where will that leave you?
The CEO didn't express any concerns about "talent leaving". He is saying "keep the juniors" but he's implying "fire the seniors". This is in line with long standing industry trends and it's confirmed by the flowing quote from the OP:
>> [the junior replacement] notion led to the “dumbest thing I've ever heard” quote, followed by a justification that junior staff are “probably the least expensive employees you have” and also the most engaged with AI tools.
He is pushing for more of the same, viewing competence and skill as threats and liability to be "fixed". He's warning the industry to stay the course and keep the dumbing-down game moving as fast as possible.
Well that's even stupider. What do you do when your juniors get better at using your tools?
The 2010's tech boom happened because big tech knew a good engineer is worth their weight in gold, and not paying them well meant they'd be headhunted after as little as a year of work. What's gonna happen when this repeats) if we're assuming AI makes things much more efficient)?
----
And that's my kindest interpretation. One that assumes that a junior and senior using a prompt will have a very close gap to begin with. Even seniors seem to struggle right now with current models working at scale on Legacy code.
100%, and this is him selling the new batch of AWS agent tools. If your product requirements + “Well Architected” NFRs are expressed as input, AWS wants to run it and extract your cost of senior engineers as value for him.
I think AI has overall helped me learn.
There are lots of personal projects that I have wanted to build for years but have pushed off because the “getting started cost” is too high, I get frustrated and annoyed and don’t get far before giving up. Being able to get the tedious crap out of the way lowers the barrier to entry and I can actually do the real project, and get it past some finish line.
Am I learning as much as I would had I powered through it without AI assistance? Probably not, but I am definitely learning more than I would if I had simply not finished (or even started) the project at all.
I always used to try doing that. Really putting in the work, thoroughly reading the docs, books, study enough to have all the background information and context. It works but takes a lot of time and focus.
However, for side projects, there may be many situations where the documentation is actually not that great. Especially when it comes to interacting with and contributing to open source projects. Most of the time my best bet would be to directly go read a lot of source code. It could take weeks before I could understand the system I'm interacting with well enough to create the optimal solution to whatever problem I'd be working on.
With AI now, I usually pack an entire code base into a text file, feed it into the AI and generate the first small prototypes by guiding it. And this really is just a proof of concept, a validation that my idea can be done reasonably well with what is given. After that I would read through the code line by line and learn what I need and then write my own proper version.
I will admit that with AI it still takes a long time, because often it takes 4 or 5 prototypes before it generates exactly what you had in mind without cheating, hard coding things or weird workarounds. If you think it doesn't, you probably have lower standards than me. And that is with continuous guidance and feedback. But it still shortens that "idea validation" phase from multiple weeks to just one for me.
So: is it immensely powerful and useful? Yes. Can it save you time? Sometimes. Is it a silver bullet that replaces a programmer completely? Definitely no.
I think an important takeaway here also is that I am talking strictly about side projects. It's great as the stakes are low. But I would caution to wait a little longer before putting it in production though.
The biggest blocker for me would be that I would go through a "Getting Started" guide and that would go well until it doesn't. Either there would be an edge case that the guide didn't take into account or the guide would be out of date. Sometimes I would get an arcane error message that was a little difficult to parse.
There were also cases where the interesting part of what I'm working on (e.g. something with distributed computing) required a fair amount of stuff that I don't find interesting to get started (e.g. spinning up a Kafka and Zookeeper cluster), where I might have to spend hours screwing around with config files and make a bunch of mistakes before I get something more or less working.
If I was sufficiently interested, I would power through the issue, by either more thoroughly reading through documentation or searching through StackOverflow or going onto a project IRC, so it's not like I would never finish a project, but having a lower barrier of entry by being able to directly paste an error message or generate a working starter config helps a lot with getting past the initial hump, especially to get to the parts that I find more interesting.
> At least one CEO seems to get it.
> (…)
> I’m not even sure AI is good for any engineer
In that case I’m not sure you really agree with this CEO, who is all-in on the idea of LLMs for coding, going so far as to proudly say 80% of engineers at AWS use it and that that number will only rise. Listen to the interview, you don’t even need ten minutes.
> I’m not even sure AI is good for any engineer, let alone junior engineers. Software engineering at any level is a journey of discovery and learning.
Yes, but when there are certain mundane things in that discovery that are hindering my ability to get work done, AI can be extremely useful. It can be incredibly helpful in giving high level overviews of code bases or directing me to parts of codebases where certain architecture lives. Additionally, it exposes me to patterns and ideas I hadn't originally thought of.
Now, if I just take whatever is spit out by AI as gospel, then I'd be inclined to agree with you in saying AI is bad, but if you use it correctly, like any other tool, it's fantastic.
Imagine you have shit ton of money but only agents that generate 10% bad code? You crushing or beating anyone..
The whole premise is just silly of thinking we don't need juniors is just silly. If there's no juniors, eventually there will be no seniors. AI slop ain't gonna un-slop itself.
>will accelerate that journey of discovery and learning,
Okay, but what about work output? That's seems to be the only thing business cares about.
Also, maybe it's the HN bias but I don't see this notion where old engineers are rejecting this en masse. More younger people will embrace it. But most younger people haven't mucked in legacy code yet (the lifeblood of any businesses).
In the last few months we have worked with startups who have vibe coded themselves into an abyss. Either because they never made the correct hires in the first place or they let technical talent go. [1]
The thinking was that they could iterate faster, ship better code, and have an always on 10x engineer in the form of Claude code.
I've observed perfectly rational founders become addicted to the dopamine hit as they see Claude code output what looks like weeks or years of software engineering work.
It's overgenerous to allow anyone to believe AI can actually "think" or "reason" through complex problems. Perhaps we should be measuring time saved typing rather than cognition.
[1] vibebusters.com
As if startups before LLMs were creating great code. Right now on the front page, a YC company is offering a “Founding Full Stack Engineer” $100K-$150K. What quality of code do you think they will end up with?
https://www.ycombinator.com/companies/text-ai/jobs/OJBr0v2-f...
Notably, that is a company that... adds AI to group chats. Startups offering crap salaries with a vague promise of equity in a vague product idea with no moat are a dime a dozen, and have been well before LLMs came around.
How did they get YC funding? It doesn’t seem like they have even a POC or any technical employees.
>Its not like 2 years ago everyone wasn't saying it would be 10+ years before AI can do what it does now.
So far I don't see that notion disproved. Ai still doesn't truly "reason with" nor understand the data it outputs.
> I think the skills that should be emphasized are how do you think for yourself?
Independent thinking is indeed the most important skill to have as a human. However, I sympathize for the younger generations, as they have become the primary target of this new technology that looks to make money by completely replacing some of their thinking.
I have a small child and took her to see a disney film. Google produced a very high quality long form advert during the previews. The ad portrays a lonely young man looking for something to do in the evening that meets his explicit preferences. The AI suggests a concert, he gets there and locks eyes with an attractive young woman.
Sending a message to lonely young men that AI will help reduce loneliness. The idea that you don't have to put any effort into gaining adaptive social skills to cure your own loneliness is scary to me.
The advert is complete survivor bias. For each success in curing your boredom, how many failures are there with lonely young depressed men talking to their phone instead of friends?
Critical thinking starts at home with the parents. Children will develop beliefs from their experience and confirm those beliefs with an authority figure. You can start teaching mindfulness to children at age 7.
Teaching children mindfulness requires a tremendous amount of patience. Now the consequence for lacking patience is outsourcing your Childs critical thinking to AI.
You should read the story The Perfect Match from the book Paper Menagerie and other stories by Ken Liu, it goes into what you mentioned about Google.
Yes, however Her is a bit more optimistic and doesn't really delve into the data collection and usage aspects, it's more similar to a romance with some sci-fi aspects at the end.
> “How's that going to work when ten years in the future you have no one that has learned anything,”
Pretty obvious conclusion that I think anyone who's thought seriously about this situation has already come to. However, I'm not optimistic that most companies will be able to keep themselves from doing this kind of thing, because I think it's become rather clear that it's incredibly difficult for most leadership in 2025 to prioritize long-term sustainability over short-term profitability.
That being said, internships/co-ops have been popular from companies that I'm familiar with for quite a while specifically to ensure that there are streams of potential future employees. I wonder if we'll see even more focus on internships in the future, to further skirt around the difficulties in hiring junior developers?
He wants educators to instead teach “how do you think and how do you decompose problems”
Ahmen! I attend this same church.
My favorite professor in engineering school always gave open book tests.
In the real world of work, everyone has full access to all the available data and information.
Very few jobs involve paying someone simply to look up data in a book or on the internet. What they will pay for is someone who can analyze, understand, reason and apply data and information in unique ways needed to solve problems.
Doing this is called "engineering". And this is what this professor taught.
In undergrad I took an abstract algebra class. It was very difficult and one of the things the teacher did was have us memorize proofs. In fact, all of his tests were the same format: reproduce a well-known proof from memory, and then complete a novel proof. At first I was aghast at this rote memorization - I maybe even found it offensive. But an amazing thing happened - I realized that it was impossible to memorize a proof without understanding it! Moreover, producing the novel proofs required the same kinds of "components" and now because they were "installed" in my brain I could use them more intuitively. (Looking back I'd say it enabled an efficient search of a tree of sequences of steps).
Memorization is not a panacea. I never found memorizing l33t code problems to be edifying. I think it's because those kinds of tight, self-referential, clever programs are far removed from the activity of writing applications. Most working programmers do not run into a novel algorithm problem but once or twice a career. Application programming has more the flavor of a human-mediated graph-traversal, where the human has access to a node's local state and they improvise movement and mutation using only that local state plus some rapidly decaying stack. That is, there is no well-defined sequence for any given real-world problem, only heuristics.
Memorizing is a super power / skill. I work in a ridiculously complex environment and have to learn and know so much. Memorizing and spaced repetition are like little islands my brain can start building bridges between. I used to think memorizing was anti-first principles, but it is just good. Our brains can memorize so much if we make them. And then we can connect and pattern matching using higher order thinking.
There's this [1] which is one of my favorite articles on that topic; definitely worth a read.
Recognizing the patterns and applying patterned solutions is where I see success in my niche of healthcare interoperability. So much of my time is spent watching people do things,process and how they use data. It's amazing how much people remember to do their job, but me coming in and be able to bridge the doctor and the lab to share data easier is like Im an alchemist. It's really not a problem I've been able to see ai solve without suggesting solutions that are too simple or too costly and in that goldilocks zone everyone will be happy with
What's even better about memorization is that you have an objective method to test your own understanding. It is so easy to believe you understand something when you don't! But, at least with math, I think if you can reproduce the proof from memory you can be very confident that you aren't deluding yourself.
Hmmm... It's the other way around for me. I find it hard to memorise things I don't actually understand.
I remember being given a proof of why RSA encryption is secure. All the other students just regurgitated it. It made superficial sense I guess.
However, I could not understand the proof and felt quite stupid. Eventually I went to my professor for help. He admitted the proof he had given was incomplete (and showed me why it still worked). He also said he hadn't expected anyone to notice it wasn't a complete proof.
Mostly just integer factorisation of large numbers is hard.
There are some other things you have to worry about practically, e.g Coppersmith's attack, and padding schemes (although that wasn't part of the proof I was given)
Haha, well it does depend on the assumption that integer factorisation is hard. Although I'm not sure that being able to do it implies P = NP.
During my elementary school years, there was a teacher who told me that I didn't need to memorize it as long as I understand them. I taught he was the coolest guy ever.
Only when I got late twenties, I realized how wrong he was. Memorization and understanding go hand in hand, but if one of them has to come first than it's memorization. He probably said that because that was what kids (who were forced to do rote memorization) wanted to hear.
You could argue this is just moving the memorization to meta-facts, but I found all throughout school that if you understand some slightly higher level key thing, memorization at the level you're supposed to be working in becomes at best a slight shortcut for some things. You can derive it all on the fly.
Sort of like how most of the trigonometric identities that kids are made to memorize fall out immediately from e^iθ = cosθ+isinθ (could be taken as the definitions of cos,sin), e^ae^b=e^(a+b) (a fact they knew before learning trig), and a little bit of basic algebraic fiddling.
Or like how inverse Fourier transforms are just the obvious extension of the idea behind writing a 2-d vector as a sum of its x and y projections. If you get the 2d thing, accept that it works the exact same in n-d (including n infinite), accept integrals are just generalized sums, and functions are vectors, and I guess remember that e^iwt are the basis you want, you can reason through what the formula must be immediately.
Probably. I hated memorization when I was a student too, because it was boring. But as soon as I did some teaching, my attitude changed to, "Just memorize it, it'll make your life so much easier." It's rough watching kids try to multiply when they don't have their times tables memorized, or translate a language when they haven't memorized the vocabulary words in the lesson so they have to look up each one.
As with most things, it depends. If you truly do understand something, then you can derive a required result from first principles. _Given sufficient time_. Often in an exam situation you are time-constrained, and having memorized a shortcut cut be beneficial. Not to mention retaining is much easier when you understand the topic, so memorization becomes easier.
Probably the best example of this I can think of (for me at least) from mathematics is calculating combinations. I have it burned into my memory that (n choose r) = (n permute r) / (r permute r), and (n permute r) = n! / (n - r)!
Can I derive these from first principles? Sure, but after not seeing it for years, it might take me 10+ minutes to think through everything and correct any mistakes I make in the derivation.
But if I start with the formula? Takes me 5 seconds to sanity check the combination formula, and maybe 20 to sanity check the permutation formula. Just reading it to myself in English slowly is enough because the justification kind of just falls right out of the formula and definition.
So, yeah, they go hand in hand. You want to understand it but you sure as heck want to memorize the important stuff instead of relying on your ability to prove everything from ZFC...
I think we memorize the understanding. For me it also works better understanding how something works than memoryzing results. I remember in high school, in maths trigonometrics, there were a list of 20 something formulas derived from a single one. Everyboby was memorizing the whole list of formulas; i just had to memorize a simple formula and the underdtanding of how to derive the others from the fundamental one on the fly.
You don't need to memorize to understand. You can rederive it every time.
You need to memorize it to use it subconsciously while solving more complex problems. Other ways you won't fit more complex solutions into your working memory,vso whole classes of problems will be too hard for you.
My controversial education hot take: Pointless rote memorization is bad and frustrating, but early education could use more directed memorization.
As you discovered: A properly structured memorization of carefully selected real world material forces you to come up with tricks and techniques to remember things. With structured information (proofs in your case) you start learning that the most efficient way to memorize is to understand, which then reduces the memorization problem into one of categorizing the proof and understanding the logical steps to get from one step to another. In doing so, you are forced to learn and understand the material.
Another controversial take (for HN, anyway) is that this is what happens when programmers study LeetCode. There’s a meme that the way to interview prep is to “memorize LeetCode”. You can tell who hasn’t done much LeetCode interviewing if they think memorizing a lot of problems is a viable way to pass interviews. People who attempt this discover that there are far too many questions to memorize and the best jobs have already written their own questions that aren’t out of LeetCode. Even if you do get a direct LeetCode problem in an interview, a good interview will expect you to explain your logic, describe how you arrived at the solution, and might introduce a change if they suspect you’re regurgitating memorized answers.
Instead, the strategy that actually works is to learn the categories of LeetCode style questions, understand the much smaller number of algorithms, and learn how to apply them to new problems. It’s far easier to memorize the dozen or so patterns used in LeetCode problems (binary search, two pointers, greedy, backtracking, and so on) and then learn how to apply those. By practicing you’re not memorizing the specific problems, you’re teaching yourself how to apply algorithms.
Side note: I’m not advocating for or against LeetCode, I’m trying to explain a viable strategy for today’s interview format.
Exactly. I agree with the leetcode part. A lot of problems in the world are composite of simpler smaller problems. Leetcode should teach you the basic patterns and how to combine them to solve real world problems. How will you ever solve a real world problem without knowing a few algorithms beforehand. For example, my brother was talking about how a Roomba would map a room. He was imagining 0 to represent free space and 1 as inaccessible points. This quickly reminded me of Number of Islands problem from leetcode. Yeah, there might be a lot of changes required to that problem but one could simple represent it as two problems.
1. Represent different objects in the room as some form of machine understandable form in a matrix 2. Find the number of Islands or find the Islands themselves.
This is the approach algomonster use. They give you a way to categorise the problem and what pattern is likely to solve it:
Memorization of, like, multiplication tables gives us a poor view of the more interesting type of memorization. Remembering types of problems we’ve seen. Remembering landmarks and paths, vs just remembering what’s in every cell of a big grid.
I still don’t like leetcode, though.
Fortunately that was not my experience in abstract algebra. The tests and homework were novel proofs that we hadn't seen in class. It was one of my favorite classes / subjects. Someone did tell me in college that they did the memorization thing in German Universities.
Code-wise, I spent a lot of time in college reading other people's code. But no memorization. I remember David Betz advsys, Tim Budd's "Little Smalltalk", and Matt Dillon's "DME Editor" and C compiler.
I would wager some folks can memorize without understanding? I do think memorization is underrated, though.
There is also something to the practice of reproducing something. I always took this as a form of "machine learning" for us. Just as you get better at juggling by actually juggling, you get better at thinking about math by thinking about math.
Interesting I had the same problem and suffered in grades back in school simply because I couldn't memorize much without understanding. However, I seemed to be the only one because every single other student, including those with top grades, were happy to memorize and regurgitate. I wonder how they're doing now.
My abstract algebra class had it exactly backwards. It started with a lot of needless formalism culminating in galois theory. This was boring to most students as they had no clue why the formalism was invented in the first place.
Instead, I wished it showed how the sausage was actually made in the original writings of galois [1]. This would have been far more interesting to students, as it showed the struggles that went into making the product - not to mention the colorful personality of the founder.
The history of how concepts were invented for the problems faced is far more motivating to students to build a mental model than canned capsules of knowledge.
> This was boring to most students as they had no clue why the formalism was invented in the first place.
> The history of how concepts were invented for the problems faced is far more motivating to students to build a mental model than canned capsules of knowledge.
That's something I really like about 3blue1brown, and he says it straight up [0]:
> My goal is for you to come away feeling like you could have invented calculus yourself. That is, cover all those core ideas, but in a way that makes clear where they actually come from, and what they really mean, using an all-around visual approach.
Depends on the subject - I can remember multiple subjects where the teacher would give you a formula to memorise without explaining why or where it came from. You had to take it as an axiom. The teachers also didn't say - hey, if you want to know why did we arrive to this, have a read here, no, it was just given.
Ofc you could also say that's for the student to find out, but I've had other things on my mind
>Memorization is not a panacea.
It is What you memorize that is important, you can't have a good discussion about a topic if you don't have the facts and logic of the topic in memory. On the other hand using memory to paper over bad design instead of simplifying or properly modularizing it, leads to that 'the worst code I have seen is code I wrote six months ago' feeling.
Your comment about memorizing as part of understanding makes a lot of sense to me, especially as one possible technique to get get unstuck in grasping a concept.
If it doesn’t work for you on l33t code problems, what techniques are you finding more effective in that case?
I was part of an ACM programming team in college. We would review classes of problems based on the type of solution necessary, and learn those techniques for solving them. We were permitted a notebook, and ours was full of the general outline of each of these classes and techniques. Along with specific examples of the more common algorithms we might encounter.
As a concrete example, there is a class of problems that are well served by dynamic programming. So we would review specific examples like Dijkstra's algorithm for shortest path. Or Wagner–Fischer algorithm for Levenshtein-style string editing. But we would also learn, often via these concrete examples, of how to classify and structure a problem into a dynamic programming solution.
I have no idea if this is what is meant by "l33t code solutions", but I thought it would be a helpful response anyway. But the bottom line is that these are not common in industry, because hard computer science is not necessary for typical business problems. The same way you don't require material sciences advancements to build a typical house. Instead it flows the other way, where advancements in materials sciences will trickle down to changing what the typical house build looks like.
>If it doesn’t work for you on l33t code problems, what techniques are you finding more effective in that case?
Memorization of l33t code DOES work well as prep for l33t code tests. I just don't think l33t code has much to do with application programming. I've long felt that "computer science" is physics for computers, low on the abstraction ladder, and there are missing labels for the higher complexity subjects built on it. Imagine if all physical sciences were called "physics" and so in order to get a job as a biologist you should expect to be asked questions about the Schroedinger equation and the standard model. We desperately need "application engineering" to be a distinct subject taught at the university level.
You mean like to Software Engineering?
That's a real major that's been around for a couple of decades which focuses on software development (testing, version control, design patterns) with less focus on the more theoretical parts of computer science? There are even specialties within the Software Engineering major that focus specifically on databases or embedded systems.
What I understand from the GP is that memorizing l33t code won't help you learn anything useful. Not that understanding the solutions won't help you memorize them.
> But an amazing thing happened - I realized that it was impossible to memorize a proof without understanding it!
This may be true of mathematical proofs, but it surely must not be true in general. Memorizing long strings of digits of pi probably isn’t much easier if you understand geometry. Memorizing famous speeches probably isn’t much easier if you understand the historical context.
> Memorizing famous speeches probably isn’t much easier if you understand the historical context.
Not commenting on the merits of critical thinking vs memorization either way, but I think it would be meaningfully easier to memorize famous speeches if you understand the historical context.
It's funny, because I had the exact opposite experience with abstract algebra.
The professor explained things, we did proofs in class, we had problem sets, and then he gave us open-book semi-open-professor take-home exams that took us most of a week to do.
Proof classes were mostly fine. Boring, sometimes ridiculously shit[0], but mostly fine. Being told we have a week for this exam that will kick our ass was significantly better for synthesizing things we'd learned. I used the proofs we had. I used sections of the textbook we hadn't covered. I traded some points on the exam for hints. And it was significantly more engaging than any other class' exams.
[0] Coming up with novel things to prove that don't require some unrelated leap of intuition that only one student gets is really hard to do. Damn you Dr. B, needing to figure out that you have to define a third equation h(x) as (f(x) - g(x))/(f(x) + g(x)) as the first step of a proof isn't reasonable in a 60 minute exam.
memorization + application = comprehension. Rinse and repeat.
Whether leet code or anything else.
Mathematics pedagogy today is in a pretty sorrowful state due to bad actors and willful blindness at all levels that require public trust.
A dominant majority in public schools starting late 1970s seems to follow the "Lying to Children" approach which is often mistakenly recognized as by-rote teaching but are based in Paulo Freire's works that are in turn based on Mao's torture discoveries from the 1950s.
This approach contrary to classical approaches leverages torturous process which seems to be purposefully built to fracture and weed out the intelligent individual from useful fields, imposing sufficient thresholds of stress to impose PTSD or psychosis, selecting for and filtering in favor of those who can flexibly/willfully blind/corrupt themselves.
Such sequences include Algebra->Geometry->Trigonometry where gimmicks in undisclosed changes to grading cause circular trauma loops with the abandonment of Math-dependent careers thereafter, similar structures are also found in Uni, for Economics, Business, and Physics which utilize similar fail-scenarios burning bridges where you can't go back when the failure lagged from the first sequence, and you passed the second unrelated sequence. No help occurs, inducing confusion and frustration to PTSD levels, before the teacher offers the Alice in Wonderland Technique, "If you aren't able to do these things, perhaps you shouldn't go into a field that uses it". (ref Kubark Report, Declassified CIA Manual)
Have you been able to discern whether these "patterns" as you've called them aren't just the practical reversion to the classical approach (Trivium/Quadrivium)? Also known as the first-principles approach after all the filtering has been done.
To compare: Classical approaches start with nothing but a useful real system and observations which don't entrench false assumptions as truth, which are then reduced to components and relationships to form a model. The model is then checked for accuracy against current data to separate truth from false in those relationships/assertions in an iterative process with the end goal being to predict future events in similar systems accurately. The approach uses both a priori and a posteriori components to reasoning.
Lying to Children reverses and bastardizes this process. It starts with a single useless system which contains equal parts true and false principles (as misleading assumptions) which are tested and must be learned to competency (growing those neurons close together). Upon the next iteration one must unlearn the false parts while relearning the true parts (but we can't really unlearn, we can only strengthen or weaken) which in turn creates inconsistent mental states imposing stress (torture). This is repeated in an ongoing basis often circular in nature (structuring), and leveraging psychological blindspots (clustering), with several purposefully structured failings (elements) to gatekeep math through torturous process which is the basis for science and other risky subject matter. As the student progresses towards mastery (gnosis), the systems become increasingly more useful. One must repeatedly struggle in their sessions to learn, with the basis being if you aren't struggling you aren't learning. This mostly uses a faux a priori reasoning without properties of metaphysical objectivity (tied to objective measure, at least not until the very end).
If you don't recognize this, an example would be the electrical water pipe pressure analogy. Diffusion of charge in-like materials, with Intensity (Current) towards the outermost layer was the first-principled approach pre-1978 (I=V/R). The Water Analogy fails when the naive student tries to relate the behavior to pressure equations that ends up being contradictory at points in the system in a number of places introducing stumbling blocks that must be unlearned.
Torture being the purposefully directed imposition of psychological stress beyond a individuals capacity to cope towards physiological stages of heightened suggestability and mental breakdown (where rational thought is reduced or non-existent in the intelligent).
It is often recognized by its characteristic subgroups of Elements (cognitive dissonance, a lack of agency to remove oneself and coercion/compulsion with real or perceived loss or the threat thereof), Structuring (circular patterns of strictness followed by leniency in a loop, fractionation), and Clustering (psychological blindspots).
Wait, the electrical pipe water analogy is actually a very good one and it's quite difficult to find edge cases where it breaks down in a way that would confuse a student. There are some (for example, there's no electrical equivalent of Reynold's number or turbulence, and flow resistance varies differently with pipe diameter than wire diameter, and no good equivalent for Faraday's law) but I don't think these are likely to cause confusion. It even captures nuance like inductance, capacitance, and transmission line behaviour.
> Lying to Children reverses and bastardizes this process. It starts with a single useless system which contains equal parts true and false principles (as misleading assumptions) which are tested and must be learned to competency (growing those neurons close together).
Can you provide some concrete examples of it?
It's the core problem facing the hiring practices in this field. Any truly competent developer is a generalist at heart. There is value to be had in expertise, but unless you're dealing with a decade(s) old hellscape of legacy code or are pushing the very limits of what is possible, you don't need experts. You'd almost certainly be better off with someone who has experience with the tools you don't use, providing a fresh look and cover for weaknesses your current staff has.
A regular old competent developer can quickly pick up whatever stack is used. After all, they have to; Every company is their own bespoke mess of technologies. The idea that you can just slap "15 years of React experience" on a job ad and that the unicorn you get will be day-1 maximally productive is ludicrous. There is always an onboarding time.
But employers in this field don't "get" that. For regular companies they're infested by managers imported from non-engineering fields, who treat software like it's the assembly line for baking tins or toilet paper. Startups, who already have fewer resources to train people with, are obsessed with velocity and shitting out an MVP ASAP so they can go collect the next funding round. Big Tech is better about this, but has it's own problems going on and it seems that the days of Big Tech being the big training houses is also over.
It's not even a purely collective problem. Recruitment is so expensive, but all the money spent chasing unicorns & the opportunity costs of being understaffed just get handwaved. Rather spend $500,000 on the hunt than $50,000 on training someone into the role.
And speaking of collective problems. This is a good example of how this field suffers from having no professional associations that can stop employers from sinking the field with their tragedies of the commons. (Who knows, maybe unions will get more traction now that people are being laid off & replaced with outsourced workers for no legitimate business reason.)
> Rather spend $500,000 on the hunt than $50,000 on training someone into the role.
Capex vs opex, that's the fundamental problem at heart. It "looks better on the numbers" to have recruiting costs than to have to set aside a senior developer plus paying the junior for a few months. That is why everyone and their dog only wants to hire seniors, because they have the skillset and experience that you can sit their ass in front of any random semi fossil project and they'll figure it out on their own.
If the stonk analysts would go and actually dive deep into the numbers to look at hiring side costs (like headhunter expenses, employee retention and the likes), you'd see a course change pretty fast... but this kind of in-depth analysis, that's only being done by a fair few short-sellers who focus on struggling companies and not big tech.
In the end, it's a "tragedy of the commons" scenario. It's fine if a few companies do that, it's fine if a lot of companies do that... but when no one wants to train juniors any more (because they immediately get poached by the big ones), suddenly society as a whole has a real and massive problem.
Our societies are driven into a concrete wall at full speed by the financialization of every tiny aspect of our lives. All that matters these days are the gods of the stonk market - screw the economy, screw the environment, screw labor laws, all that matters is appearing "numbers go up" on the next quarterly.
> but when no one wants to train juniors any more (because they immediately get poached by the big ones)
Can we stop pretending that we don't know how to solve this problem? If you hire juniors at $X/year, but they keep getting poached after 2-3 years because now they can get $X*1.5/year (or more!), then maybe you should start promoting and giving raises to them after they've gotten a couple years experience.
Seriously, this is not a hard problem to solve. If the junior has proven themselves, give them the raise they deserve instead of being all Surprised Pikachu when another company is willing to pay them what they've proven themselves worthy of.
> Our societies are driven into a concrete wall at full speed by the financialization of every tiny aspect of our lives. All that matters these days are the gods of the stonk market - screw the economy, screw the environment, screw labor laws, all that matters is appearing "numbers go up" on the next quarterly.
I have been in the various nooks and crannies of the Internet/Software dev industry my whole career (i'm 49). I can't think of any time when the stock market didn't drive software innovation. It's always been either invent something -> go public -> exit or invent something -> increase stock price of existing public corp
> It's always been either invent something -> go public -> exit or invent something -> increase stock price of existing public corp
Yes, but today more and more is invent something -> achieve dominance -> get bought up by an even larger megacorp. That drives the enshittification circle.
> Capex vs opex
That's part of the problem, but I also notice the new hiring managers are incentivized to hire (or replace) employees to make their mark on the company. They then advocate for "their guys" the ones they recruited over the incumbents that are the unwilling dinosaurs in their eyes.
I can’t think of another career where management continuously does not understand the realities of how something gets built. Software best practices are on their face orthogonal to how all other parts of a business operate.
How does marketing operate? In a waterfall like model. How does finance operate? In a waterfall like model. How does product operate? Well you can see how this is going.
Then you get to software and it’s 2 week sprints, test driven development etc. and it decidedly works best not on a waterfall model, but shipping in increments.
Yet the rest of the business does not work this way, it’s the same old top down model as the rest.
This I think is why so few companies or even managers / executives “get it”
> can’t think of another career where management continuously does not understand the realities of how something gets built
All engineering. Also all government and a striking amount of finance.
Actually, this might be a hallmark of any specialist field. Specialists interface with outsiders through a management layer necessarily less competent at the specialty than they are. (Since they’re devoting time and energy to non-specialty tasks.)
While product often does operate in a waterfall model, I think this is the wrong mindset. Good product management should adopt a lot of the same principles as software development. Form a testable hypothesis, work to get it into production and begin gathering data, then based on your findings determine what the next steps are and whether to adjust the implementation, consider the problem solved or try a different approach.
> I can’t think of another career where management continuously does not understand the realities of how something gets built.
This is in part a consequence of how young our field is.
The other comment pointing out other engineering is right here. The difference is that fields like Civil Engineering are millenia old. We know that Egyptian civil engineering was advanced and shockingly modern even 4.5 millenia ago. We've basically never stopped having qualified civil engineers around who could manage large civil engineering projects & companies.
Software Development in it's modern forms has it's start still in living memory. There simply weren't people to manage the young early software development firms as they grew, so management got imported from other industries.
And to say something controversial: Other engineering has another major reason why it's usually better understood. They're held to account when they kill people.
If you're engineering a building or most other things, you must meet safety standards. Where possible you are forced to prove you meet them. E.g. Cars.
You don't get to go "Well cars don't kill people, people kill people. If someone in our cars die when they're hit by a drunk driver, that's not our problem that's the drunkard's fault." No. Your car has to hold up to a certain level of crash safety, even if it's someone else who causes the accent, your engineering work damn better hold up.
In software, we just do not do this. The very notion of "Software kills people" is controversial. Treated as a joke, "of course it can't kill people, what are you on about?". Say, you neglect on your application's security. There's an exploit, a data breach, you leak your users' GPS location. A stalker uses the data to find and kill their victim.
In our field, the popular response is to go "Well we didn't kill the victim, the stalker did. It's not our problem.". This is on some level true; 'Twas the drunk driver who caused the car crash, not the car company. But that doesn't justify the car company selling unsafe cars, why should it justify us selling unsafe software? It may be but a single drop of blood, but it's still blood on our hands as well.
As it stands, we are fortunate enough that there haven't been incidents big enough to kill so many people that governments take action to forcibly change this mindset. It would be wise that Software Development takes up this accountability on it's own accord to prevent such a disaster.
>For regular companies they're infested by managers imported from non-engineering fields
Someone's cousin, lets leave it at that, someones damn cousin or close friend, or anyone else with merely a pulse. I've had interviews where the company had just been turned over from people that mattered, and you. could. tell.
One couldn't even tell me why the project I needed to do for them ::rolleyes::, their own code boilerplate(which they said would run), would have runtime issues and I needed to self debug it to even get it to a starting point.
Its like, Manager: Oh heres this non-tangential thing that they tell me you need to complete before I can consider you for the positon.... Me: Oh can I ask you anything about it?.... Manager: No
Isn't that happening already? Half the usual CS curriculum is either math (analysis, linear algebra, numerical methods) or math in anything but name (computability theory, complexity theory). There's a lot of very legitimate criticism of academia, but most of the times someone goes "academia is stupid, we should do X" it turns out X is either:
- something we've been doing since forever
- the latest trend that can be picked up just-in-time if you'll ever need it
I've worked in education in some form or another for my entire career. When I was in teacher education in college . . . some number of decades ago . . . the number one topic of conversation and topic that most of my classes were based around was how to teach critical thinking, effective reasoning, and problem solving. Methods classes were almost exclusively based on those three things.
Times have not changed. This is still the focus of teacher prep programs.
Parent comment is literally praising an experience they had in higher education, but your only takeaway is that it must be facile ridicule of academia.
Well, at more elite schools at least, the general assumption is that programming is mostly something you pick up on your own. It's not CS. Some folks will disagree of course but I think that's the reality. I took an MIT Intro to Algorithms/CS MOOC course a few years back out of curiosity and there was a Python book associated with the course but you were mostly on your own with it.
When I was in college the philosophy program had the marketing slogan: “Thinking of a major? Major in thinking”.
Now as a hiring manager I’ll say I regularly find that those who’ve had humanities experience are way more capable and the hard parts of analysis and understanding. Of course I’m biased as a dual cs/philosophy major but it’s very rare I’m looking for someone who can just write a lot of code. Especially juniors as analytical thinking is way harder to teach than how to program.
> Now as a hiring manager I’ll say I regularly find that those who’ve had humanities experience are way more capable and the hard parts of analysis and understanding.
The humanities, especially the classic texts, cover human interaction and communication in a very compact form. My favorite sources are the Bible, Cicero, and Machiavelli. For example Machiavelli says if you do bad things to people do them at once, while good things you should spread out over time. This is common sense. Once you catch the flavor of his thinking it's pretty easy to work other situations out for yourself, in the same why that good engineering classes teach you how to decompose and solve technical problems.
The #1 problem in almost all workplaces is communication related. In almost all jobs I've had in 25-30 years, finding out what needs to be done and what is broken -- is much harder than actually doing it.
We have these sprint planning meetings and the like where we throw estimates on the time some task will take but the reality is for most tasks it's maybe a couple dozen lines of actual code. The rest is all what I'd call "social engineering" and figuring out what actually needs to be done, and testing.
Meanwhile upper management is running around freaking out because they can't find enough talent with X years of Y [language/framework] experience, imagining that this is the wizard power they need.
The hardest problem at most shops is getting business domain knowledge, not technical knowledge. Or at least creating a pipeline between the people with the business knowledge and the technical knowledge that functions.
Anyways, yes I have 3/4 a PHIL major and it actually has served me well. My only regret is not finishing it. But once I started making tech industry cash it was basically impossible for me to return to school. I've met a few other people over the years like me, who dropped out in the 90s .com boom and then never went back.
Yea this is why I’m generally not that impressed by LLMs. They still force you to do the communication which is the hard part. Programming languages are inherently a solve for communicating complex steps. Programming in English isn’t actually that much of a help you just have to reinvent how to be explicit
I find Claude code unexpectedly good at analysis. With a healthy dose of skepticism. It is actually really good at reading logs and corelating events for example.
This is also why I went into the Philosophy major - knowing how to learn and how to understand is incredibly valuable.
Unfortunately in my experience, many, many people do not see it that way. It's very common for folks to think of philosophy as "not useful / not practical".
Many people hear the word "philosophy" and mentally picture "two dudes on a couch recording a silly podcast", and not "investigative knowledge and in-depth context-sensitive learning, applied to a non-trivial problem".
It came up constantly in my early career, trying to explain to folks, "no, I actually can produce good working software and am reasonably good at it, please don't hyper-focus on the philosophy major, I promise I won't quote Scanlon to you all day."
How people see it is based on the probability of any philosophy major producing good working software, not you being able to produce good working software.
Maybe because phylosophy focuses on weird questions (to be or not to be) and weird personas. If it was advertised as more grounded thing, the views would be different.
The way you are perceived by others dependa on your behaviour. If you wamt to be perceived differently, adjust your behaviour, don't demand others to change. They won't.
Many top STEM schools have substantial humanities requirements, so I think they agree with you.
At Caltech they require a total of at least 99 units in humanities or social sciences. 1 Caltech unit is 1 hour of work a week for each week of the term, and a typical class is 9 units consisting of 3 hours of classwork a week and 6 hours of homework and preparation.
That basically means that for 11 of the 12 terms that you are there for a bachelor's degree, you need to be taking a humanities or social sciences class. They require at least 4 of those to be in humanities (English, history, history and philosophy of science, humanities, music, philosophy, and visual culture), and at least 3 to be in social sciences (anthropology, business economics and management, economics, law, political science, psychology, and social science).
At MIT they have similar, but more complicated, requirements. They require humanities, art, and social sciences, and they require that you pick at least one subject in one of those and take more than one course in it.
On a related note, the most accomplished people I've met didn't have degrees in the fields where they excelled and won awards. They were all philosophy majors.
Teaching people to think is perhaps the world's most under-rated skill.
Well, yes but the other 90%+ just need to get a job out of college to support their addiction to food and shelter not to be a “better citizen of the world” unless they have parents to subsidize their livelihood either through direct transfers of money or by letting them stay at home.
I told both of my (step)sons that I would only help them pay for college or trade school - their choice - if they were getting a degree in something “useful”. Not philosophy, not Ancient Chinese Art History etc.
I also told them that they would have to get loans in their own names and I would help them pay off the loans once they graduated and started working gainfully.
I would say you have some bias.
yes, sometimes you need people who can grasp the tech and talk to managers. They might be intermediaries.
But don't ignore the nerdy guys who have been living deeply in a tech ecosystem all their lives. The ones who don't dabble in everything. (the wozniaks)
A professor in my very first semester called "crazy finger syndrome" the attempts to go straight to the code without decomposing the problem from a business or user perspective. It was a long time ago. It was a CS curriculum
I miss her jokes against anxious nerds that just wanted to code :(
Don't forget the rise of boot camps where some educators are not always aligned with some sort of higher ethical standards.
> "crazy finger syndrome" - the attempts to go straight to the code without decomposing the problem from a business or user perspective
Years ago I started on a new team as a senior dev, and did weeks of pair programming with a more junior dev to intro me to the codebase. His approach was maddening; I called it "spray and pray" development. He would type out lines or paragraphs of the first thing that came to mind just after sitting down and opening an editor. I'd try to talk him into actually taking even a few minutes to think about the problem first, but it never took hold. He'd be furiously typing, while I would come up with a working solution without touching a keyboard, usually with a whiteboard or notebook, but we'd have to try his first. This was c++/trading, so the type-compile-debug cycle could be 10's of minutes. I kept relaying this to my supervisor, but after a few months of this he was let go.
I make a point to solve my more difficult problems with pen and paper drawings and/or narrative text before I touch the PC. The computer is an incredibly distracting medium to work with if you are not operating under clear direction. Time spent on this forum is a perfect example.
Memorization and closed book tests are important for some areas. When seconds are counting the ER doctor cannot go look up how to treat a heart attack. That doctor also needs to know now only how to treat the common heart attack, but how to recognize this isn't the common heart attack but the 1 in 10,000 not a heart attack but has exactly the same symptoms as a heart attack case and give it the correct treatment.
However most of us are not in that situation. It is better for us to just look up those details as we need them because it gives us more room to handle a broader variety of situations.
Speaking with a relative who is a doctor recently it’s interesting how much each of our jobs are “troubleshooting”.
Coding, doctors, plumber… different information, often similar skill sets.
I worked a job doing tech support for some enterprise level networking equipment. It was the late 1990s and we were desperate for warm bodies. Hired a former truck driver who just so happened to do a lot of woodworking and other things.
Great hire.
Everyone going through STEM needs to see the movie Hidden Figures for a variety of reasons, but one bit stands out as poignant: I believe it was Katherine Johnson, who is asked to calculate some rocket trajectory to determine the landing coordinates, thinks on it a bit and finally says, "Aha! Newton's method!" Then she runs down to the library to look up how to apply Newton's method. She had the conceptual tools to find a solution, but didn't have all the equations memorized. Having all the equations in short term memory only matters in a (somewhat pathological) school setting.
My favorite professor in my physics program would say, "You will never remember the equations I teach. But if you learn how the relationships are built and how to ask questions of those relationships, then I have done my job." He died a few years ago. I never was able to thank him for his lessons.
Being resourceful is an extremely valuable skill in the real world, and basically shut out of the education world.
Unlike my teachers, none of my bosses ever put me in an empty room with only a pencil and a sheet of paper to solve given problems.
> My favorite professor in engineering school always gave open book tests.
My experience as a professor and a student is that this doesn't make any difference. Unless you can copy verbatim the solution to your problem from the book (which never happens), you better have a good understanding of the subject in order to solve problems in the allocated time. You're not going to acquire that knowledge during your test.
My experience as a professor and a student is that this doesn't make any difference.
Exactly the point of his test methodology.
What he asked of students on a test was to *apply* knowledge and information to *unique* problems and create a solution that did not exist in any book.
I only brought 4 things to his tests --- textbook, pencil, calculator and a capable, motivated and determined brain. And his tests revealed the limits of what you could achieve with these items.
Isn't this an argument for why you should allow open book tests rather than why you shouldn't? It certainly removes some pressure to remember some obscure detail or formula.
During some of the earlier web service development days, one would find people at F500 skating by in low-to-mid level jobs just cutting and pasting between spreadsheets, things would take them hours could be done in seconds, and with lower error rates, with a proper data interface.
Very anecdotally, but I hazard that most of these types of low-hanging fruit, low-value add roles are much less common since they tended to be blockers for operational improvement. Six-sigma, Lean, various flavors of Agile would often surface these low performers up and they either improved or got shown the door between 2005 - 2020.
Not that everyone is 100% all the time, every day, but what we are left with is often people that are highly competent at not just their task list but at their job.
I had a like minded professor in university, ironically in AI. Our big tests were all 3 day take home assignments. The questions were open ended, required writing code, processing data and analyzing results.
I think the problem with this is that it requires the professor to mentally fully engage when marking assignments and many educators do not have the capacity and/or desire to do so.
Might be true, idk? For all we know that professor now gives a 2.5-day take home assignments where they are allowed to use LLMs, and then assess them in an 1 hour oral exam where they need to explain approach, results and how they ensure that their results are accurate?
I don't think the 3-day take home is the key. It's supporting educators to have the intention, agency and capacity to improvise assessment.
It depends what level the education is happening at. Think of it like students being taught how to do for loops but are just copying and pasting AI output. That isn't learning. They aren't building the skills needed to debug when the AI gets something wrong with a more complicated loop, or understand the trade offs of loops vs recursion.
Finding the correct balance for a given class it hard. Generally, the lower level the education, the more it should be closed books because the more it is about being able to manually solve the smaller challenges that are already well solved so you build up the skills needed to even tackle the larger challenges. The higher the education level, the more it is about being able to apply those skills to then tackle a problem, and one of those skills is being able to pull relevant formulas and such from the larger body of known formulas.
Agreed coming from the ops world also.
I've had a frustrating experience the past few years trying to hire junior sysadmins because of a real lack of problem solving skills once something went wrong outside of various playbooks they memorized to follow.
I don't need someone who can follow a pre-written playbook, I have ansible for that. I need someone that understands theory, regardless of specific implementations, and can problem solve effectively so they can handle unpredictable or novel issues.
To put another way, I can teach a junior the specifics of bind9 named.conf, or the specifics of our own infrastructure, but I shouldn't be expected to teach them what DNS in general is and how it works.
But the candidates we get are the opposite - they know specific tools, but lack more generalized theory and problem solving skills.
Same here! I always like to say that software engineering is 50% knowing the basics (How to write/read code, basic logic) and 50% having great research skills. So much of our time is spent finding documentation and understanding what it actually means as opposed to just writing code.
You cannot teach "how to to think". You have to give students thinking problems to actually train thinking. Those kinds of problems can increasingly be farmed off to AI, or at least certain subproblems in them.
I meam, yes, to an extent you can teach how to think: critical thinking and logic are topics you can teach and people who take their teaching to heart can become better thinkers. However, those topics cannot impart creativity. Critical thinking is called exactly that because it's about tools and skills for separating bad thinking from good thinking. The skill of generating good thinking probably cannot be taught; it can only be improved with problem-solving practice.
> In the real world of work, everyone has full access to all of the available data and information.
In general, I also attend your church.
However, as I preached in that church, I had two students over the years.
* One was from an African country and told me that where he grew up, you could not "just look up data that might be relevant" because internet access was rare.
* The other was an ex US Navy officer who was stationed on a nuclear sub. She and the rest of the crew had to practice situations where they were in an emergency and cut off from the rest of the world.
Memorization of considerable amounts of data was important to both of them.
Each one of us has a mental toolbox that we use to solve problems. There are many more tools that we don’t have in our heads that we can look up if we know how.
The bigger your mental toolbox the more effective you will be at solving the problems. Looking up a tool and learning just enough to use it JIT is much slower than using a handy tool that you already masterfully know how to use.
This is as true for physical tools as for programming concepts like algorithms and data structures. In the worst case you won’t even know to look for a tool and will use whatever is handy, like the proverbial hammer.
People have been saying that since the advent of formal education. Turns out standardized education is really hard to pull off and most systems focus on making the average good enough.
It’s also hard to teach people “how to think” while at the same time teaching them practical skills - there’s only so many hours in a day, and most education is setup as a way to get as many people as possible into shape for taking on jobs where “thinking” isn’t really a positive trait, as it’d lead to constant restructuring and questioning of the status quo
While there’s no reasonable way to disagree with the sentiment, I don’t think I’ve ever met anyone who can “think and decompose problems” who isn’t also widely read, and knows a lot of things.
Forcing kids to sit and memorize facts isn’t suddenly going to make them a better thinker, but much of my process of being a better thinker is something akin to sitting around and memorizing facts. (With a healthy dose of interacting substantively and curiously with said facts)
> Everyone has full access to all of the available data and information
Ahh, but this is part of the problem. Yes, they have access, but there is -so much- information, it punches through our context window. So we resort to executive summaries, or convince ourselves that something that's relevant is actually not.
At least an LLM can take full view of the context in aggregate and peel out signal. There is value there, but no jobs are being replaced
>but no jobs are being replaced
I agree that an LLM is a long way from replacing most any single job held by a human in isolation. However, what I feel is missed in this discussion is that it can significantly reduce the total manpower by making humans more efficient. For instance, the job of a team of 20 can now be done by 15 or maybe even 10 depending on the class of work. I for one believe this will have a significant impact on a large number of jobs.
Not that I'm suggesting anything be "stopped". I find LLM's incredibly useful, and I'm excited about applying them to more and more of the mundane tasks that I'd rather not do in the first place, so I can spend more time solving more interesting problems.
Also, some problems don't have enough data for a solution. I had a professor that gave tests where the answer was sometimes "not solvable." Taking these tests was like sweating bullets because you were not sure if you're just too dumb to solve the problem, or there was not enough data to solve the problem. Good times!
One of my favorite things about Feynman interviews/lectures is often his responses are about how to think. Sometimes physicists ask questions in his lectures and his answer has little to do with the physics, but how they're thinking about it. I like thinking about thinking, so Feynman is soothing.
I agree with the overall message, but I will say that there is still a great deal of value in memorisation. Memorising things gives you more internal tools to think in broader chunks, so you can solve more complicated problems.
(I do mean memorisation fairly broadly, it doesn't have to mean reciting a meaningless list of items.)
Agree, hopefully this insight / attitude will become more and more prevalent.
For anyone looking for resources, may we recommend:
* The Art of Doing Science and Engineering by Richard Hamming (lectures are available on YouTube as well)
* Measurement by Paul Lockhart (for teaching mindset)
Yeah. Memorization and trivial knowledge is an optimization mechanism.
It is tough though, I'd like to think I learnt how to think analytically and critically. But thinking is hard, and often times I catch myself trying to outsource my thinking almost subconsciously. I'll read an article on HN and think "Let's go to the comment section and see what the opinions to choose from are", or one of the first instincts after encountering a problem is googling and now asking an LLM.
Most of us are also old enough to have had a chance to develop taste in code and writing. Many of the young generation lack the experience to distinguish good writing from LLM drivel.
wanted to chime in on the educational system. in the west, we have the 'banking system' which treat a student as a bank account and knowledge as currency, hence the dump more info into ppl to make them sm0rt attitude.
in developing areas, they actually implement more modern models commonly, as its newer and free to implement newer things.
those newer models focus more on exactly this. teach a person how to go through the process of finding solutions. rather than 'knowing a lot to enable the process of thinking'.
not saying what is better or worse, but reading this comment and article it reminds me of this.
a lot of people i see, they know tons of interesting things, but anything outside of their knowledge is a complete mystery.
all the while ppl from developing areas learn to solve issues. alot of individuals from there also, get out of their poverty and do really well for themselves.
ofcourse, this is a generalization and doesnt hold up in all cases. but i cant help think about it.
a lot of my colleagues dont know how to solve problems simply because they dont RTFM. they rely on knowledge from their education which is already outdated before they even sign up.. i try to teach them to RTFM. it seems hopeless. they look at me , downwards, because i have no papers. but if shit hits the fan, they come to me. solve the prolbem.
a wise guy i met once said (likely not his words). there are 2 type of ppl. those who think in problems, and those who think in solutions.
id related that to education, not prebaked human properties.
If AI is truly this effective, we would be selling 10x-10Kx more stuff, building 10x more features (and more quickly), improving quality & reliability 10x. There would be no reason to fire anyone because the owners would be swimming in cash. I'm talking good old-fashioned greed here.
You don't fire people if you anticipate a 100x growth. Who cares about saving 0.1% of your money in 10 years? You want to sell 100x / 1000x/ 10000x more .
So the story is hard to swallow. The real reason is as usual, they anticipate a downturn and want to keep earnings stable.
Exactly. If the AI can multiply everyone's power by hundred or thousand, you want to keep all people who make a positive contribution (and only get rid of those who are actively harmful). With sufficiently good AI, perhaps the group of juniors you just fired could have created a new product in a week.
even within the AI-paradigm, you could keep the juniors to validate and test the AI generated code. You still need some level of acceptance testing for the increased production. And the juniors could be producing automation engineering at or above the level of the product code they were producing prior to AI. A win win ( more production & more career growth)
In other words, none of these stories make any sense, even if you take the AI superpower at face value.
So to summarize:
My boss said we were gonna fire a bunch of people “because AI” as part of some fluff PR to pretend we were actually leaders in AI. We tried that a bit, it was a total mess and we have no clue what we’re doing, I’ve been sent out to walk back our comments.
Most people don't notice but there has been a inflation in headcounts over the years now. This happened around the time microservices architecture trend took over.
All of sudden to ensure better support and separation of concerns people needed a team with a manager for each service. If this hadn't been the case, the industry as a whole can likely work with 40% - 50% less people eventually. Thats because at any given point in time even with a large monolithic codebase only 10 - 20% of the code base is in active evolution, what that means in microservices world is equivalent amount teams are sitting idle.
When I started out huge C++ and Java code bases were pretty much the norm, and it was also one of the reasons why things were hard and barrier to entry high. In this microservices world, things are small enough that any small group of even low productivity employees can make things work. That is quite literally true, because smaller things that work well don't even need all that many changes on a everyday basis.
To me its these kind of places that are in real trouble. There is not enough work to justify keeping dozens to even hundreds of teams, their managements and their hierarchies all working for quite literally doing nothing.
Its almost an everyday song that I hear, that big companies are full of hundreds or thousands of employees doing nothing.
I think sometimes the definition of work gets narrowed to a point so infinitesimal that everyone but the speaker is just a lazy nobody.
There was an excellent article on here about working at enterprise scale. My experience has been similar. You get to do work that feels really real, almost like school assignments with instant feedback and obvious rewards when you're at a small company. When I worked at big companies it all felt like bullshit until I screwed it up and a senator was interested in "Learning more" (for example).
The last few 9s are awful hard to chase down and a lot of the steps of handling edge case failures or features are extremely manual.
> In this microservices world, things are small enough that any small group of even low productivity employees can make things work. That is quite literally true, because smaller things that work well don't even need all that many changes on a everyday basis.
You're committing the classic fallacy around microservices here. The services themselves are simpler. The whole software is not.
When you take a classic monolith and split it up into microservices that are individually simple, the complexity does not go away, it simply moves into the higher abstractions. The complexity now lives in how the microservices interact.
In reality, the barrier to entry on monoliths wasn't that high either. You could get "low productivity employees" (I'd recommend you just call them "novices" or "juniors") to do the work, it'd just be best served with tomato sauce rather than deployed to production.
The same applies to microservices. You can have inexperienced devs build out individual microservices, but to stitch them together well is hard, arguably harder than ye-olde-monolith now that Java and more recent languages have good module systems.
There are two freight trains currently smashing into each other:
1.) Elon fired 80% of twitter and 3 years later it still hasn't collapsed or fallen into technical calamity. Every tech board/CEO took note of that.
2.) Every kid and their sister going to college who wants a middle class life with generous working conditions is targeting tech. Every teenage nerd saw those over employed guys making $600k from their couch during the pandemic.
On the other hand while yes it's still running, twitter is mostly not releasing new features, and has completely devolved into the worst place on the internet. Not to mention most accounts now actually are bots like Elon claimed they were 3 years ago.
> twitter is mostly not releasing new features
Were they even releasing new features anyways?
I can't think of any new features that Twitter implemented even the 5 years preceding Musk's buyout.
I hope the tech boards and CEOs don’t miss the not very subtle point that twitter has very quickly doubled in size in 2 years and is still growing after the big layoff and they had to scramble to fix some notable mistakes they made when firing that many people. 80% is already a hugely misleading marketing number.
Edit: huh, what’s with the downvote, is this wrong? Did I overstate it? Here’s the data: https://www.demandsage.com/twitter-employees/
Also need to add, that a large part of the 80% that got kicked, was moderator staff. So it makes sense that after they removed too many developers, they ended up rehiring them.
Take in account, Twitter their front end, the stuff that people interact with was only like 15% of the actual code base. The rest was analytics for the data (selling data, marketing analytic for advertisers etc).
But as they are not reintroducing moderators, the company is "still down by 63.6% from the numbers before the mass layoffs".
So technically, Twitter is probably back or even bigger on the IT staff then before Musk came.
Well yeah... computers are really powerful. you don't need docker swarm or any other newfangled thing. Just perl and apache and mysql and you can ship to tens of millions of users before you hit scaling limits.
Amazon has been at the forefront of micro services at scale since 2002.
https://nordicapis.com/the-bezos-api-mandate-amazons-manifes...
> If this hadn't been the case, the industry as a whole can likely work with 40% - 50% less people eventually. Thats because at any given point in time even with a large monolithic codebase only 10 - 20% of the code base is in active evolution, what that means in microservices world is equivalent amount teams are sitting idle.
I think it depends on the industry. In safety critical systems, you need to be testing, making documentation, architectural artifacts, meeting with customers, etc
There's not that much idle time. Unless you mean idle time actually writing code and that's not always a full time job.
I think most people misunderstand the relationship between business logic, architecture and headcount.
Big businesses don’t inherently require the complexity of architecture they have. There is always a path-dependent evolution and vestigial complexity proportional to how large and fast they grew.
The real purpose of large scale architecture is to scale teams much moreso than business logic. But why does headcount grow? Is it because domains require it? Sure that’s what ambitious middle managers will say, but the real reason is you have money to invest in growth (whether from revenue or from a VC). For any complex architecture there is usually a dramatically simpler one that could still move the essential bits around, it just might not support the same number of engineers delineated into different teams with narrower responsibilities.
The general headcount growth and architecture trajectory is therefore governed by business success. When we’re growing we hire and we create complex architecture to chase growth in as many directions as possible. Eventually when growth slows we have a system that is so complex it requires a lot of people just to understand and maintain—even if the headcount is longer justified those with power in the human structure will bend over backwards to justify themselves. This is where the playbook changes and a private equity (or Elon) mentality is applied to just ruthlessly cut and force the rest of the people how to keep the lights on.
I consider advances in AI and productivity orthogonal to all this. It will affect how people do their jobs, what is possible, and the economics of that activity, but the fundamental dynamics of scale and architectural complexity will remain. They’ll still hire more people to grow and look for ways to apply them.
It would be sad if you are correct. Your company might not be able to justify keeping dozens and hundreds of teams employed, but what happens when other companies can't justify paying dozens and hundreds of teams who are the customers buying your product? Those who gleefully downsize might well deserve the market erosion they cause.
This is blatantly incorrect. Before microservices became the norm you still had a lot of teams and hiring, but the teams would be working with the same code base and deployment pipeline. Every company that became successful and needed to scale invented their own bespoke way to do this; microservices just made it a pattern that could be repeatedly applied.
I think that the starting point is that productivity/developer has been declining for a while, especially at large companies. And this leads to the "bloated" headcount.
The question is why. You mention microservices. I'm not convinced.
Many think it is "horizontals". Possible, these taxes add up it is true.
Perhaps it is cultural? Perhaps it has to do with the workforce in some manner. I don't know and AFAIK it has not been rigorously studied.
Looks like the AWS CEO has changed religion. A year back, he was aboard the ai-train - saying AI will do all coding in 2 years [1]
Finally, the c-suite is getting it.
He didn't actually say that. He said it's possible that within 2 years developers won't be writing much code, but he goes on to say:
"It just means that each of us has to get more in tune with what our customers need and what the actual end thing is that we're going to try to go build, because that's going to be more and more of what the work is as opposed to sitting down and actually writing code...."
https://www.businessinsider.com/aws-ceo-developers-stop-codi...
If you read the full remarks they're consistent with what he says here. He says "writing code" may be a skill that's less useful, which is why it's important to hire junior devs and teach them how to learn so they learn the skills that are useful.
He is talking his book. Management thinks it adds value in the non-coding aspects of the product - such as figuring out what customers need etc. I suggest management stays in their lanes, and not make claims on how coding needs to be done, leave that to the craftsmen actually coding.
> Please don't post comments saying that HN is turning into Reddit. It's a semi-noob illusion, as old as the hills.
Theoretically, a large part of Amazon's worth is the skill of its workforce.
Some subset of the population likes to pretend their workforce is a cost that provides less than zero value or utility, and all the value and utility comes from shareholders.
But if this isn't true, and collective skill is worth value, then saying anyone can have that with AI at least has some headwind on your share price - which is all they care about.
Does that offset a potential tailwind from slightly higher margins?
I don't think any established company should be cheerleading that anyone can easily upset their monopoly with a couple of carefully crafted prompts.
It was always kind of strange to me, and seemed as though they were telling everyone, our moat is gone, and that is good.
If you really believed anyone could do anything with AI, then the risk of PEs collapsing would be high, which would be bad for the capital class. Now you have to correctly guess what's the next best thing constantly to keep your ROI instead of just parking it in save havens - like FAANG.
Amazon doesn't really work this way.
Bedrock/Q is a great example of how Amazon works. If we throw $XXX at the problem and YYY SDEs at the problem we should be able to build Github Copilot, GPT-3, OpenRouter and Cursor ourselves instead of trying to competitively acquire and attract talent. The fact that Codewhisperer, Q and Titan barely get spoken about on HN or Twitter tells you how successful this is.
But if you have that perspective then the equation is simple. If S3 can make 5 XXL features per year with 20 SDEs then if we adopt “Agentic AI” we should be able to build 10 XXL features with 10 SDEs.
Little care is given to organizational knowledge, experience, vision etc. that is the value (in their mind) of leadership not ICs.
What do you mean, “Amazon doesn’t really work that way”?
Parent is talking about how C-Suite doesn’t want to trumpet something that implies their entire corporate structure is extremely disadvantaged vs new entrants and your response is “Amazon wants to build everything themselves”?
Amazon isn’t some behaviorally deterministic entity, and it could (and should?) want to both preserve goodwill and build more internally vs pay multiples to acquire.
I guess it could be that people inside are not people they have to compete with, but it doesn’t seem like that’s what you're saying.
Amazon would probably say its worth is the machinery around workers that allows it to plug in arbitrary numbers of interchangeable people and have them be productive.
That's not necessarily inconsistent though - if you need people to guide or instruct the autonomy, then you need a pipeline of people including juniors to do that. Big companies worry about the pipeline, small companies can take that subsidy and only hire senior+, no interns, etc., if they want.
There is no pipeline though. The average tenure of a junior developer even at AWS is 3 years. Everyone knows that you make less money getting promoted to an L5 (mid) than getting hired in as one. Salary compression is real. The best play is always to jump ship after 3 years. Even if you like Amazon, “boomeranging” is still the right play.
that's interesting because that's how the consulting world works too. Start at a big firm, work for a few years, then jump to a small firm two levels above where you were. The after two years, come back to the big firm and get hired one level up from where you left. Rinse/repeat. It's the fastest promotion path in consulting.
But that's fine, that's why I say for big companies - the pipeline is the entire industry, everyone potentially in the job market, not just those currently at AWS. Companies like Amazon have a large enough work force to care that there's people coming up even if they don't work there yet (or never do, but by working elsewhere free someone else to work at AWS).
They have an interest in getting those grads turned into would-be-L5s even if they leave for a different company. If they 'boomerang back' at L7 that's great. They can't if they never got a grad job.
> That's not necessarily inconsistent though
Pasting the quote for reference:
> Amazon Web Services CEO Matt Garman claims that in 2 years coding by humans won't really be a thing, and it will all be done by networks of AI's who are far smarter, cheaper, and more reliable than human coders.
Unless this guy speaks exclusively in riddles, this seems incredibly inconsistent.
There's definitely a vibe shift underway. C-Suites are seeing that AI as a drop-in replacement for engineers is a lot farther off than initial hype suggested. They know that they'll need to attract good engineers if they want to stay competitive and that it's probably a bad idea to scare off your staff with saying that they'll be made irrelevant.
I'm not sure those are mutually exclusive? Modern coders don't touch Assembly or deal with memory directly anymore. It's entirely possible that AI leads to a world where typing code by hand is dramatically reduced too (it already has in a few domains and company sizes)
Might want to clarify things with your boss who says otherwise [1]? I do wish journalists would stop quoting these people unedited. No one knows what will actually happen.
[1]: https://www.shrm.org/topics-tools/news/technology/ai-will-sh...
I'm not sure those statements are in conflict with each other.
“My view is you absolutely want to keep hiring kids out of college and teaching them the right ways to go build software and decompose problems and think about it, just as much as you ever have.” - Matt Garman
"We will need fewer people doing some of the jobs that are being done today” - Amazon CEO Andy Jassy
Maybe they differ in degree but not in sentiment.
> quoting these people unedited
If you're quoting something, the only ethical thing to do is as verbatim as possible and with a sufficient amount of context. Speeches should not be cleaned up to what you think they should have said.
Now, the question of who you go to for quotes, on the other hand .. that's how issues are really pushed around the frame.
I very much believe that anything AWS says on the corporate level is bullshit.
From the perspective of a former employee. I knew that going in though. I was 46 at the time, AWS was my 8th job and knowing AWS’s reputation from 2nd and 3rd hand information, I didn’t even entertain an opportunity that would have forced me to relocate.
I interviewed for a “field by design” role that was “permanently remote” [sic].
But even those positions had an RTO mandate after I already left.
There's what AWS leadership says and then there's what actually sticks.
There's an endless series of one pagers with this idea or that idea, but from what I witnessed first hand, the ones that stuck were the ones that made money.
Jassy was a decent guy when I was there, but that was a decade ago. A CEO is a PR machine more than anything else, and the AI hype train has been so strong that if you do anything other than saying AI is the truth, the light and the way, you lose market share to competitors.
AI, much like automation in general, does allow fewer people to do more, but in my experience, customer desires expand to fill a vacuum and if fewer people can do more, they'll want more to the point that they'll keep on hiring more and more people.
I would bet that anyone who's worked with these models extensively would agree.
I'll never forget the sama AGI posts before o3 launched and the subsequent doomer posting from techies. Feels so stupid in hindsight.
ChatGPT is better than any junior developer I’ve ever worked with. Junior devs have always been a net negative for the first year or so.
From a person who is responsible for delivering projects, I’ve never thought “it sure would be nice if I had a few junior devs”. Why when I can poach an underpaid mid level developer for 20% more?
I've never had a junior dev be a "net negative." Maybe you're just not supervising or mentoring them at all? The first thing I tell all new hires under me is that their job is to solve more problems than they create, and so far it's worked out.
I’ve had interns be a net negative, I’ve had Juniors be a net negative, I’ve had Seniors be a net negative and even managers!
Turns out some people suck, but most of them don’t suck.
The most impressive folks Ive worked with are almost always straight out of school. It's before they've developed confidence about their skills and realized they can be more successful by starting their own business. People who get promoted three times in just 5 years sort of good.
Did their project manager and/or team lead think when they were hired “they are really going to be a great asset to my team and are going to help me complete my sprint/quarterly goals”?
When I ask for additional headcount, I’m looking at the next quarter since that’s what my manager is judging me based on.
I’m a great mentor when given the time. Two former interns for whom I was their official mentor during my time at AWS got return offers and are thriving two years after I left. I threw one in front of a customer to lead the project within three months after they came back after graduating. They were able to come through technically and had the soft skills. I told them my training approach is to “throw them at the bus. But never under the bus.”
I’m also a great teacher. That’s my $DayJob and has been for the past decade first bringing in new to the company processes and technologies, leading initiatives, teaching other developers, working with sales, CxOs (smaller companies), directors, explaining large “organizational transformation” proposals etc. working at startups and then doing the same in cloud consulting first working at AWS (ProServe full time role) and now working as a staff architect full time at a third party consulting company.
But when I have been responsible for delivery, I only hire people who have experience “dealing with ambiguity” and show that I can give them a decently complicated problem and they can take the ball and run with it and make decent decisions and do research. I don’t even do coding interviews - when I interview it’s strictly behavioral and talking through their past projects, decision making processes, how they overcame challenges etc.
In terms of AWS LPs, it’s “Taking Ownership” (yeah quoting Amazon LPs made me throw up a little).
What happens when you retire and there are no juniors to replace you?
That sounds like an incentive issue.
My evaluations are based on quarterly goals and quarterly deliverables. No one at a corporation cares about anything above how it affects them.
Bringing junior developers up to speed just for them to jump ship within three years or less doesn’t benefit anyone at the corporate level. Sure they jump ship because of salary compression and inversion, where internet raises don’t correspond to market rates. Even first level managers don’t have a say so or budget to affect that.
This is true for even BigTech companies. A former intern I mentored who got a return offer a year before I left AWS just got promoted to an L5 and their comp package was 20% less than new hires coming in at an l5.
Everyone will be long gone from the company if not completely retired by the time that happens.
At least one CEO seems to get it. Anyone touting this idea of skipping junior talent in favor of AI is dooming their company in the long run. When your senior talent leaves to start their own companies, where will that leave you?
I’m not even sure AI is good for any engineer, let alone junior engineers. Software engineering at any level is a journey of discovery and learning. Any time I use it I can hear my algebra teacher telling me not to use a calculator or I won’t learn anything.
But overall I’m starting to feel like AI is simply the natural culmination of US economic policy for the last 45 years: short term gains for the top 1% at the expense of a healthy business and the economy in the long term for the rest of us. Jack Welch would be so proud.