CTOs noticed it. When product pipeline is empty, because engineers finished all the outstanding tasks, the engineers are awarded with more work: "The new software engineer is a product leader. Someone thinking about what the product is, not just how it works", or, in other words, engineers are going to be tasked with putting more content "the what" into the product pipeline.
Has that not been what a senior SWE is? You’re making it sound like engineers need to be asked to implement features rather than contribute to design. At my company, if you are not coming up with new features or applications, your days are numbered.
Nobody wants to hear anyone's opinion but their own, we have a poverty of effective communications.
Nobody wants to communicate because it is pointless to communicate: what you say will be misunderstood, it will be repeated incorrectly and attributed to you, people will play games with your messaging and with you for trying to communicate.
The management bully game activates, and they all participate in keeping the engineer down.
This is normal at every engineering organization, it is lord of the flies.
And this is how we educate people, This situation is created. All because we refuse to recognize that learning how to debate controversy and learning how to manage disagreement is completely unrecognized as a valued skill.
So we avoid controversy and any disagreement is an opportunity to bully and force one's way. Which is completely avoidable, with basic effective communications training. Debate to understand, disagree to learn.
This sounds like dysfunction. As engineers, we're not necessarily any more correct than anyone else. But we do have a seat at the table, and good organizations at least listen.
They should think about what happens when expectations are so high that a single dev must deliver and maintain multiple products. What stops that single dev from leaving and offering the same product on his own.
Yep there is the grind em to be so efficient they may as well start on their own. And now the sales and marketing side of things can ne assisted with AI, albeit not as good as pros but better than a dev and no AI to help.
Allowing non-technical PMs to ship code is fine if they’re the one getting called up in the evenings and weekends when it breaks. Maybe it’s a good exercise to show how much has effort must be applied to each commit.
Copyright issues don't seem to be addressed by any large language model provider.
If an LLM is trained on GPL code then that code has become an intrinsic part of the model (because if it hasn't then what was the value of training on it). So shouldn't that model now also be licensed GPL?
And how do I know the LLM output is not reproducing substantial chunks of GPL'd code, making my code GPL?
Or alternatively. LLM is not human. Non human generated content has no copy right protection. Meaning all generative model output is automatically public domain.
My worry is that AI will make these companies product-obsessed, the public will mistake the output for AGI, and the real engineering underneath will keep getting overlooked.
> AI makes it cheap to write code. That is not the same as it being cheap to ship it, or to maintain it. One participant put it cleanly: cognitive debt is the new technical debt.
It being expensive to ship or maintain software still sounds like technical debt, no?
For cognitive debt, I'd expect something like context switching and reviewing large amounts of code being exhausting.
Decoded: it's next to useless, it's damaged pace, and it isn't value for money. It's boiling the ocean.
Implicitly they've woken up to the value proposition which was latent in their tech hires: detailed knowledge of their code and systems. They've just tossed that away, and even worse they've smooged it into unfathomable information systems which probably share aspects of it with their competitors.
CTOs / CEOs have demonstrated how completely useless they are pretty much across the board over the last few years. Groupthink and bandwagons, zero innovation or use of brain.
CTOs were told that the companies shares will be sold off if they can't produce AI results, and that the CEO will be deposed for "not having an AI strategy", so they should kindly shut up and go along with the flow.
There were some good insights in there. I like the idea of changing the hiring interview process to focus on testing code review ability. I feel like this would have been useful even before AI.
A candidate who can identify tradeoffs present in some code and make insightful comments is a really effective way to test someone's knowledge, intelligence and taste.
It's actually brilliant because it provides the company with a way to actually improve their engineering posture since the company could land on a candidate who is more skilled than the engineers doing the interviewing.
Most leetcode tech interviews are a series of puzzles which most company insiders can solve but they never include problems that the candidate could solve but which the interviewer could not.
Leetcode interviews are horrible because they test a tiny subset of moderately difficult questions under time constraints and ignore a much larger set of problems that are much more complex. There is an incorrect assumption that someone who can solve extremely complex problems can also solve moderately complex problems under time constraints. This is absolutely not the case. It's almost mutually exclusive in fact since people who work on complex problems don't have the time or interest to practice solving simpler problems so they can never solve those fast enough to compete with fresh university grads who have been practicing those for years and don't know anything else.
On a different topic, I was sceptical of this comment:
"I honestly think you can have a fifteen thousand line PR and say, I need a human to review these three lines."
15k lines is a lot of code. I could destroy any software project, irreparably with 15k lines of code and not one engineer out of hundreds would recognize it unless they read carefully. You can absolutely destroy a codebase with 15k lines of code, without any obvious backdoors or malicious code. How would I do it? I would invent counter-productive abstractions and write a lot of unit tests for them to lock down the design... Then I would watch other engineers build on top to further lock it down... Let the flawed design accumulate debt for a few years until the entire codebase becomes slow, insecure and totally unmaintable. Nobody would ever remember that I'm the one who set the project on a bad course. Nobody ever suspects the person who invents the complex abstractions and who everyone comes to with questions.
So my view is that every single one of these 15k lines needs thorough analysis. Each of those 15k lines represent the branches from which the next generation of twigs will sprout.
Considering all the possible levels of abstraction software can represent, I'm imagining it as a fractal. The worst case - a mistake can be introduced by generative AI at any of the abstraction levels at any moment. Meaning, at worst case the whole thing has to be in the head of at least one person to validate the result against. The moment a project is growing beyond a single person capacity to hold it in one head possibility of plausibly looking error introduced at any abstraction level is added to the usual multi-engineer coordination costs.
As a former CTO, nothing is less likely to make me believe a claim than prefixing it with "CTOs agree..."
Also when you add: "at other companies. We at ACME Corp. have got everything under control."?
Exactly, this is an advertisement for their CTO dinner clubs.
What CTOs did not notice yet is that cheap code exposes inefficiencies elsewhere.
Migrating Spring Boot apps from 3.x t 4.x is now easy given all the tooling available.
But the administrative load can't be reduced by faster code delivery and that's the new bottleneck.
CTOs noticed it. When product pipeline is empty, because engineers finished all the outstanding tasks, the engineers are awarded with more work: "The new software engineer is a product leader. Someone thinking about what the product is, not just how it works", or, in other words, engineers are going to be tasked with putting more content "the what" into the product pipeline.
Has that not been what a senior SWE is? You’re making it sound like engineers need to be asked to implement features rather than contribute to design. At my company, if you are not coming up with new features or applications, your days are numbered.
It has been my experience that nobody wants to hear the software engineer's opinion as to what will improve the product however.
Nobody wants to hear anyone's opinion but their own, we have a poverty of effective communications.
Nobody wants to communicate because it is pointless to communicate: what you say will be misunderstood, it will be repeated incorrectly and attributed to you, people will play games with your messaging and with you for trying to communicate.
The management bully game activates, and they all participate in keeping the engineer down.
This is normal at every engineering organization, it is lord of the flies.
And this is how we educate people, This situation is created. All because we refuse to recognize that learning how to debate controversy and learning how to manage disagreement is completely unrecognized as a valued skill.
So we avoid controversy and any disagreement is an opportunity to bully and force one's way. Which is completely avoidable, with basic effective communications training. Debate to understand, disagree to learn.
This sounds like dysfunction. As engineers, we're not necessarily any more correct than anyone else. But we do have a seat at the table, and good organizations at least listen.
They should think about what happens when expectations are so high that a single dev must deliver and maintain multiple products. What stops that single dev from leaving and offering the same product on his own.
Yep there is the grind em to be so efficient they may as well start on their own. And now the sales and marketing side of things can ne assisted with AI, albeit not as good as pros but better than a dev and no AI to help.
Allowing non-technical PMs to ship code is fine if they’re the one getting called up in the evenings and weekends when it breaks. Maybe it’s a good exercise to show how much has effort must be applied to each commit.
CTOs… the real experts on technical debt (not really)
CTOs told the, reporters, who know what technical debt means (not really)
Copyright issues don't seem to be addressed by any large language model provider.
If an LLM is trained on GPL code then that code has become an intrinsic part of the model (because if it hasn't then what was the value of training on it). So shouldn't that model now also be licensed GPL?
And how do I know the LLM output is not reproducing substantial chunks of GPL'd code, making my code GPL?
Or alternatively. LLM is not human. Non human generated content has no copy right protection. Meaning all generative model output is automatically public domain.
Maybe this, but multiply by N licenses. Any given output may have ideas from all of them.
Law is probably going to take a while to catch up here.
My worry is that AI will make these companies product-obsessed, the public will mistake the output for AGI, and the real engineering underneath will keep getting overlooked.
Isn’t engineering always overlooked? It’s like a means to and end to non-engineers.
The best case for engineering is always: nothing went horribly wrong in public.
> AI makes it cheap to write code. That is not the same as it being cheap to ship it, or to maintain it. One participant put it cleanly: cognitive debt is the new technical debt.
It being expensive to ship or maintain software still sounds like technical debt, no?
For cognitive debt, I'd expect something like context switching and reviewing large amounts of code being exhausting.
Decoded: it's next to useless, it's damaged pace, and it isn't value for money. It's boiling the ocean.
Implicitly they've woken up to the value proposition which was latent in their tech hires: detailed knowledge of their code and systems. They've just tossed that away, and even worse they've smooged it into unfathomable information systems which probably share aspects of it with their competitors.
AI destroyed their value.
CTOs / CEOs have demonstrated how completely useless they are pretty much across the board over the last few years. Groupthink and bandwagons, zero innovation or use of brain.
CTOs were told that the companies shares will be sold off if they can't produce AI results, and that the CEO will be deposed for "not having an AI strategy", so they should kindly shut up and go along with the flow.
What’s the point of paying people a ton of money and giving them lots of power if they simply follow a script given to them by others?
Sounds like they’re followers and not leaders. So what are they getting paid for?
There were some good insights in there. I like the idea of changing the hiring interview process to focus on testing code review ability. I feel like this would have been useful even before AI.
A candidate who can identify tradeoffs present in some code and make insightful comments is a really effective way to test someone's knowledge, intelligence and taste.
It's actually brilliant because it provides the company with a way to actually improve their engineering posture since the company could land on a candidate who is more skilled than the engineers doing the interviewing.
Most leetcode tech interviews are a series of puzzles which most company insiders can solve but they never include problems that the candidate could solve but which the interviewer could not.
Leetcode interviews are horrible because they test a tiny subset of moderately difficult questions under time constraints and ignore a much larger set of problems that are much more complex. There is an incorrect assumption that someone who can solve extremely complex problems can also solve moderately complex problems under time constraints. This is absolutely not the case. It's almost mutually exclusive in fact since people who work on complex problems don't have the time or interest to practice solving simpler problems so they can never solve those fast enough to compete with fresh university grads who have been practicing those for years and don't know anything else.
On a different topic, I was sceptical of this comment:
"I honestly think you can have a fifteen thousand line PR and say, I need a human to review these three lines."
15k lines is a lot of code. I could destroy any software project, irreparably with 15k lines of code and not one engineer out of hundreds would recognize it unless they read carefully. You can absolutely destroy a codebase with 15k lines of code, without any obvious backdoors or malicious code. How would I do it? I would invent counter-productive abstractions and write a lot of unit tests for them to lock down the design... Then I would watch other engineers build on top to further lock it down... Let the flawed design accumulate debt for a few years until the entire codebase becomes slow, insecure and totally unmaintable. Nobody would ever remember that I'm the one who set the project on a bad course. Nobody ever suspects the person who invents the complex abstractions and who everyone comes to with questions.
So my view is that every single one of these 15k lines needs thorough analysis. Each of those 15k lines represent the branches from which the next generation of twigs will sprout.
> Two years ago, the mandate was simple: spend on AI, no questions asked. That era is over.
2 years is an era now?
When it comes to AI, it really does seem so.
Considering all the possible levels of abstraction software can represent, I'm imagining it as a fractal. The worst case - a mistake can be introduced by generative AI at any of the abstraction levels at any moment. Meaning, at worst case the whole thing has to be in the head of at least one person to validate the result against. The moment a project is growing beyond a single person capacity to hold it in one head possibility of plausibly looking error introduced at any abstraction level is added to the usual multi-engineer coordination costs.