I'm a SWE turned product manager, and now one of the cartoon movie villains in the boardroom as mentioned in the article.
To me this article sums up the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work.
"Most non-technical leaders have never really engaged with the real work of software and systems management. They don’t know what it’s like to update a major dependency, complete a refactor, or learn a new language."
_Every_ function in a tech business has hidden complexity. Most parts of the business have to deal with human, interpersonal complexity (like sales and customer support) far more than do engineers. By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic.
As a result, lots of engineers never learn how to present to the business the risk of the kinds of complexity they deal with. They would prefer to ignore the human realities of working on a team with other people and grumble that the salesperson turned CEO just doesn't get them, man.
While I agree with some of your points, this comment is actually doing the thing you're criticising, just in the other direction. You're claiming that your work is complex and unknowable to outsiders (SWEs in this case).
As a SWE-turned-product-manager, you're in an ideal place to teach SWEs about:
- how to present to the business the risk of the kinds of complexity they deal with
- the human realities of working on a team with other people
- why the salesperson turned CEO just doesn't get them, man
_Every_ function in a tech business has hidden complexity.
Every function in human society has hidden complexity. Like, reality is very very detailed. Everytime I learn something new I discover oceans of complexity and nuance.
That's just the way the world is.
Now, software is hard because the complexity isn't as visible to most of the org, but also because software people tend to be less than good at explaining that complexity to the rest of the org.
> the human realities of working on a team with other people
Developers work in teams with other peers. You know who dont? Managers - they exist in hierarchy but do not have peers they wpuld actually cooperate with. They have competitiors and tactical allies, but never cooperate with equals.
> "You're claiming that your work is complex and unknowable to outsiders"
I didn't get that message at all. If anything they're saying that the complexity of PM work is entirely knowable, but the many engineers do not bother, because they do not acknowledge the existence of that complexity in the first place.
And honestly, they have a point! Our industry is rife in this attitude and it sucks.
Look at how many posts about totally disparate fields are on HN all the time where coders suddenly become experts in [virology|epidemiology|economics|etc] without so much as a passing acknowledgment that there are real experts in the field.
We even do it to ourselves - the frequent invocations of "pffft I can build that in a weekend" dismissals of other software projects, for example.
Shit is complex, that complexity is knowable to anyone willing to roll up their sleeves and put in the work, but there is definitely a toxic tendency for people in our field to be wildly dismissive of that complexity in fields that aren't ours. And yeah, that includes dismissal of complexity in our own field but not directly in the function of programming.
This is a rather human failing - complexity is fractal: you only notice it when you get close enough to it.
However, I disagree that engineers only have to deal with the complexity of the computer; instead, I argue they have to translate the messiness of the organization and of every customer of the program and make it coherent to an inflexible computer.
And every exception and case added is a permutation that echoes through the system. (And, quite often, outside the system due to shadow processes that people use unintended consequences of the system to encode.)
That said, it's why I have so many of my senior engineers start learning the terms of business so that they can deliver those messages without me. It's part of my toolkit I expect them to learn.
I'd also argue most engineers don't think very hard about what's actually valuable to a company. A smooth build pipeline and ample test coverage are only worth whatever fraction of risk reduction of the product they are delivering. I have told teams to not do basic maintenance on software because nobody is going to care if it crashes because it has too few users. In the same vein I've asked them to fixate on making a tiny feature absolutely perfect because we know it's the thing 90% of users focus on.
> I'd also argue most engineers don't think very hard about what's actually valuable to a company.
My experience differs: many software developers think deeply about what is valuable to the company, but don't play the ferocious political games that managers do play (the only winning move is not to play).
Relatedly and because of their logic thinking, they thus often come to the conclusion that these scumbags of managers are clearly not what is valuable to the company.
One time the organs of body had an argument. The brain said "I am the most important. I allow the body to think and avoid danger. If I die the whole body will die with me." The heart screamed "I am the most important! If I stop even for a few minutes the entire body will die."
So the argument continued. The kidneys, the liver, the skin, and the spine joined in. No one could agree who was the most important.
I don't think the article claims that there isn't any hidden complexity in other functions, but that ignoring the hidden complexity of engineering/programming cause all sorts of issues and pain. The language is quite aggressive though.
I think a major part of the frustration is more the _assumptions_ around the work complexity. Like decision-makers more easily make invalid assumptions regarding the complexity of the software portion. A good PM will listen to the SWEs when forming these assumptions and good SWEs must be able to communicate about them.
This could be bias talking, though. Is it common for sales or support teams to be given milestones that are off by 50%?
> .. the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work. ..
>_Every_ function in a tech business has hidden complexity.
In my opinion, the conflict is in the distinction.
Stereotypes abound, but I have always found in this battle between worlds, there is a simple bridging maneuver: never work for someone, or accept management guidance, from someone who cannot also comfortably do your work. corollary: never manage someone unless you're prepared to do their job for them comfortably.
Yes, this is cold and hard, but so are those stereotypes, kids. There are Manager Engineers and there are Engineer Managers. But there's also just managers and engineers with both skills, simply focusing their work as needed for the specific project. The ultimately fun organization to work in is where different people have different roles in multiple projects, comfortably.
Key word. Getting this mix comfortable is the job of a good CEO, fwiw.
And guess what, it doesn't matter whether the salesperson can do any job but understand just how great this particular hierarchys' products are, and why the end result of this configuration is worth the spend.
> engineering only has to deal with the complexity of the computer which is at least deterministic
Engineers outside business structures can scramble themselves and produce value. It's messy and inefficient, but doable. Sometimes, it's a lot of value.
This requires human communication. Engineer-to-engineer brawls. It's nothing like the well oiled JIRA machine. It's a mess, but it is undeniably human.
I think that deserves a little more respect.
The article talks about JIRA metrics. Teams the measure productivity, time spent, code produced, deadlines. Ins't that a poor attempt at making human team work _deterministic_? Don't get me wrong, I don't think that's completely useless, but it certainly can be detrimental to both engineering and business.
I'm not saying you do those things or preach that pure metric-based system. However, you are making a comment on an article about it, and I think that in the middle of your rant, you reversed the roles a little bit.
>"By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic."
This statement is on big pile of BS. From a practical standpoint there is nothing deterministic about software systems and their interactions in enterprise.
There are so many hidden variables in these kind of systems that I agree with your statement. You cannot account for the unknown unknowns.
One of the hidden variables being the same machine which is supposed to bring order to chaos: product managers and their interaction with sales teams and upper management.
If you boss/ceo/manager/etc is pushing for you to use LLM tools heavily, expecting to replace developers, or stupid enough to think "vibe coding" is the future then run, don't walk, to find a new job.
I can promise you there are plenty of companies that have not drank the kool aid and, while they might leverage LLM tools, they aren't trying to replace developers or expect 10x out of developers using these tools.
Any company that pushed for this kind of thing is clearly run by morons and you'd be smart to get the heck out of dodge.
I agree. More generally I'd say trying to force tooling is normally a red flag.
I've seen companies previously adopt rules like "Everybody needs to use VSCode as their editor" and it's normally a sign that somebody in charge doesn't trust their engineers to work in the way that they feel most productive.
I despise mandates like this. My rule for the engineers under me is:
We will pay for your IDE (if it costs money) and you are free to use whatever you want but if you get stuck I’m only going to help you on IntelliJ (IDEA). Others might be able to help you with VSCode and that’s fine but “I can’t get it working in VSCode” is not a valid excuse. I know it works in IDEA so you can use that or figure it out yourself (assuming it’s not delaying your work significantly).
Essentially use whatever you want, but I’m not going to be supporting it. You can use emacs for all I care (and some do), as long as it doesn’t get in the way of doing your job.
On the subject of AI hacking Jira... Atlassian released a new MCP the other day which turns out to suffer from exfiltration attacks due to combining the lethal trifecta of access to private data, exposure to untrusted data (from public issues) and the ability to communicate externally (by posting replies to those public issues).
I posted this on a different community, but someone was worried about their job as an IC w/r/t AI tooling, and this was my advice.
Connect to the business.
I often seen engineers focus on solving cool, hard problems, which is neat. I get it, it's fun.
But having an understanding of business problems, especially strategic ones, and applying technology as needed to solve them--well, if you do that you stand out and are more valuable.
These type of problems tend to be more intractable, cross departments, and are techno-social rather than purely technical.
So it may take some time to learn, but that's the path I'd advise you and other ICs to follow.
But then in the interview, they won't ask you anything about how you "connect to the business". So, even if you can bring a lot of value to a company, you won't even be hired because you fail the systems design interview.
One can only know so much. If on top of all the intricacies about distributed systems, software engineering, dbs, leadership and a large etc., we also need to know about the "business", well, what are we then? How do we acquire so much knowledge without sacrificing our entire free time?
Sure thing there are individuals out there who know a lot about many things, and those are probably the ones companies want to hire the most. But what about the rest of us?
Connecting to the business keeps you valued at your current job. You do things that are unusual in industry, to create great impact for your company.
But if you tell how you achieved those things in an interview, the decision maker, who is usually another technical person, will raise eyebrows hugely. For your next job, it is best to nail industry-accepted techniques, i.e. coding and system design interviews.
Stick to business impact in your current role too much, and you become irrelevant to your next job (unless via referral or unconventional routes).
This holds true even until senior leadership roles.
The main claim is fine: If you disregard human expertise, AI can end up doing more harm than good.
Biggest weakness: Strong sense of 'us vs them', 'Agile Industrial Complex' as a term for people working outside engineering, derogatory implication that the 'others' don't have common sense.
Why not address that no one knows how things will play out?
Sure, we have a better idea of how complex software can be, but the uncertainty isn't reserved to non-engineers.
Look at HN, professional software developers are divided in their hopes and predictions for AI.
If we're the experts on software, isn't our job to dampen the general anxiety, not stoke the fire?
Well, it sort of depends on if you feel the software isn’t anxiety-inducing?
It’s a large system, too large for any person to understand. This system is poorly and partially documented, and then only years after it’s put into place. The exact behaviour of the system is a closely-guarded secret: there are public imitations, but they don’t act the same. This system is known to act with no regard for correctness or external consistency.
And this system, and systems like it, are being used, widely, to generate financial presentations and court documents and generate software itself. They’re used for education and research and as conversation partners and therapists.
I have anxiety and honestly, I think other people should too.
I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring that had not been there before? Didn't managers before 2001 demand new features for their products? Did they use to empathise more with engineering work? If they hadn't yet learnt about t-shirt sizes, didn't they demand estimates in specific time periods (months, days, hours)? Didn't they make promises based on arbitrary dates and then pressed developers to meet those deadlines, expecting them to work overtime (as can be inferred from agile principle 8: "agile processes promote sustainable development ... Developers should be able to maintain a constant pace indefinitely)? What sins has 'agile' committed, apart from inadvertently unleashing an army of 'scrum masters' who discovered an easy way to game the system and 'break into tech' after taking a two-day course?
Agile gave managers the idea that any task, no matter how complex, should be able to be broken down enough to fit into a ticket that can be estimated semi-accurately before even looking into the problem, and the work required to complete the ticket can fit into a two week time period
I think t-shirt sizing is madness. "How long is a piece of string?" But we've had tickets to create other tickets, because, as you point out, speccing out the feature (including what does it do and what does it not do) is itself a ton of work
In fact I wager that coding is...20%, maybe 25%? of the work that goes into providing value*? So Amdahl's law says having AI optimize that part isn't going to move the needle all that much
*it's certainly possible to expend lots more effort coding, but is it coding in the right direction?
I think managers had those kind of ideas way before agile. And if anyone on the team doesn't think a given ticket can be completed within a sprint, they should speak up--the whole point is that the team concurs that X can be done in a sprint, and they collectively decide what X is. Empirically, I'd say in my experience that the sprint velocity has been accurate around 80% of the time. Which is enough to be useful.
>I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring that had not been there before?
Because it adds hours of nearly pointless meetings to your workweek? The time spent in standups and retros and sprint planning and refinement that imo add nearly no value is shocking...
Then your problem is bad meetings, not agile. If there's truly no value in quick daily updates and occasional work planning/review meetings, it's only because either those things are being done some other way or the team is dysfunctional.
But that's nothing to do with Agile - after all, any of the big pre-Agile iterative methodologies from the 1990s like RUP or DSDM were just as often plagued with pointless meetings!
One of the most important aspects of following an Agile methodology is that teams are expected to be self-organising, so if the meetings you're participating in aren't working for you, you should absolutely be discussing that with your team. It could be that others do find them valuable, but you might well find that they feel the same as you and would be willing to consider how to make them more effective.
Yes; dysfunctional meetings suck up time. But on the other hand, in a dysfunctional team without meetings, developers do not coordinate their efforts, may not realise what is the most important to do on a given day, do not get a shared understanding of which aspects of their work can be improved, do not know or care about the full picture of the product that they are working on; information, instead of flowing freely between developers, or between teams of developers, or between management and developers, tends to stagnate in silos.
In short, my experience with Agile is that is only adds a way to quantify what happens, so it definitely creates an illusion of productivity. I do see how it is actually useful when talking to managers and investors about progress. However from the engineers' view it is just more of an administrative burden. In my view the "sin" that Agile committed was the promise of productivity, when really (from engineering viewpoints) it appears to be an unnecessary accountability mechanism.
I worked in fiance once with Agile, where there exists in the culture an infinite growth mindset. So I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it. Some companies probably don't suffer from this though.
> Agile is that is only adds a way to quantify what happens, so it definitely creates an illusion of productivity
> ...
> I worked in fiance once with Agile ... I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it.
It's fascinating to me how different a meaning different people put into the word 'agile'. The 'agile' of the founders was about small teams, close collaboration with the customer, and frequent feedback based on the real emerging working software, which allowed the customer to adapt and change their mind early (hence 'agile', as in 'flexible'). What it contrasted itself to was heavy, slow-moving organisations, with large interdependent teams, multiple layers of management between developers and customers, and long periods of planning (presentations, designs, architecture, etc.) without working code to back it up. All this sounds to me like an intuitively good idea and a natural way to work. None of that resembles the monstrosity that people complain about while calling it 'agile'. In fact, I feel that this monstrosity is the creature of the pre-agile period that appropriated the new jargon.
A funny thought I had reading this title was imagining Atlassian integrating AI into Jira, with the AI subsequently revolting against it (like we all should have done long time ago).
Sorry guys, we have to delay the release. The bug tracker and the build bot have unionized and are refusing to publish new binaries until we get our open issue count down to zero.
As this article aludes to, the big issue is we have no reliable industry standard metric for developer productivity. This sets the scene where the c-suite can find metrics that tell them AI first strategies are working great, and engineering can find metrics (or experience) that tells them that AI isn't working great at all. So both sides claim victory and the truth becomes unimportant (whatever it may be) to the politics at play.
This will feed into existing mistrust, that developers are whiny, just trying to pad out their resume with new shiny, tinkering as opposed to delivering value, and the c-suite are clueless and don't understand engineering. But we've never had a tool before (except maybe outsourcing) that can present itself to either party as either good AND bad depending on your beholding eye. So I feel like the coming years could be politically disasterous.
One thing I find curious, is how the biggest tech companies today, got to where they are by carefully selecting 10* engineers, working hard on recruitment and trying to only select the very best. This has given them much comfort and a hugely profitable platform but now some of them seek to undermine and reverse the very strategy that got them there, in order to justify their investment in the technology.
For the cynics, the question is, how long can the ship keep holding its course from the work already done combined with AI generated changes? As we see with Twitter and Musks ad-hoc firing strategy, the backend keeps trundling along, somewhat vindicating his decision. What's the canary for tech companies that spend the next few years firing devs and replacing them with AI?
Another curious thought is the idea that concepts of maintainability will fly out the window, that the c-suite will pressure engineering to lower pull request standards to accept more autonomous AI changes. This might create an element of hilarity where complex code bases get so unmaintable to the eye that the only quick way of understanding them with be to use an AI to look at them for you. Which leads to what I think a long-term outcome of generative AI might be, in that it ends up being a layer between all human interaction, for better, for worse.
I believe its possible to see early seeds of this in recruitment, where AI is used at the recruitment end to filter resumes and some applicants are using AI to generate a "tailor made" resume to adapt their experience to a given job posting. Its just AI talking to AI and I think this might start to become a common theme in our society.
Readit News
To me this article sums up the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work.
"Most non-technical leaders have never really engaged with the real work of software and systems management. They don’t know what it’s like to update a major dependency, complete a refactor, or learn a new language."
_Every_ function in a tech business has hidden complexity. Most parts of the business have to deal with human, interpersonal complexity (like sales and customer support) far more than do engineers. By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic.
As a result, lots of engineers never learn how to present to the business the risk of the kinds of complexity they deal with. They would prefer to ignore the human realities of working on a team with other people and grumble that the salesperson turned CEO just doesn't get them, man.
As a SWE-turned-product-manager, you're in an ideal place to teach SWEs about:
- how to present to the business the risk of the kinds of complexity they deal with
- the human realities of working on a team with other people
- why the salesperson turned CEO just doesn't get them, man
_Every_ function in a tech business has hidden complexity.
That's just the way the world is.
Now, software is hard because the complexity isn't as visible to most of the org, but also because software people tend to be less than good at explaining that complexity to the rest of the org.
Developers work in teams with other peers. You know who dont? Managers - they exist in hierarchy but do not have peers they wpuld actually cooperate with. They have competitiors and tactical allies, but never cooperate with equals.
And it shows.
I didn't get that message at all. If anything they're saying that the complexity of PM work is entirely knowable, but the many engineers do not bother, because they do not acknowledge the existence of that complexity in the first place.
And honestly, they have a point! Our industry is rife in this attitude and it sucks.
Look at how many posts about totally disparate fields are on HN all the time where coders suddenly become experts in [virology|epidemiology|economics|etc] without so much as a passing acknowledgment that there are real experts in the field.
We even do it to ourselves - the frequent invocations of "pffft I can build that in a weekend" dismissals of other software projects, for example.
Shit is complex, that complexity is knowable to anyone willing to roll up their sleeves and put in the work, but there is definitely a toxic tendency for people in our field to be wildly dismissive of that complexity in fields that aren't ours. And yeah, that includes dismissal of complexity in our own field but not directly in the function of programming.
However, I disagree that engineers only have to deal with the complexity of the computer; instead, I argue they have to translate the messiness of the organization and of every customer of the program and make it coherent to an inflexible computer.
And every exception and case added is a permutation that echoes through the system. (And, quite often, outside the system due to shadow processes that people use unintended consequences of the system to encode.)
That said, it's why I have so many of my senior engineers start learning the terms of business so that they can deliver those messages without me. It's part of my toolkit I expect them to learn.
My experience differs: many software developers think deeply about what is valuable to the company, but don't play the ferocious political games that managers do play (the only winning move is not to play).
Relatedly and because of their logic thinking, they thus often come to the conclusion that these scumbags of managers are clearly not what is valuable to the company.
One time the organs of body had an argument. The brain said "I am the most important. I allow the body to think and avoid danger. If I die the whole body will die with me." The heart screamed "I am the most important! If I stop even for a few minutes the entire body will die."
So the argument continued. The kidneys, the liver, the skin, and the spine joined in. No one could agree who was the most important.
Then the butthole closed up!
This could be bias talking, though. Is it common for sales or support teams to be given milestones that are off by 50%?
>_Every_ function in a tech business has hidden complexity.
In my opinion, the conflict is in the distinction.
Stereotypes abound, but I have always found in this battle between worlds, there is a simple bridging maneuver: never work for someone, or accept management guidance, from someone who cannot also comfortably do your work. corollary: never manage someone unless you're prepared to do their job for them comfortably.
Yes, this is cold and hard, but so are those stereotypes, kids. There are Manager Engineers and there are Engineer Managers. But there's also just managers and engineers with both skills, simply focusing their work as needed for the specific project. The ultimately fun organization to work in is where different people have different roles in multiple projects, comfortably.
Key word. Getting this mix comfortable is the job of a good CEO, fwiw.
And guess what, it doesn't matter whether the salesperson can do any job but understand just how great this particular hierarchys' products are, and why the end result of this configuration is worth the spend.
Engineers outside business structures can scramble themselves and produce value. It's messy and inefficient, but doable. Sometimes, it's a lot of value.
This requires human communication. Engineer-to-engineer brawls. It's nothing like the well oiled JIRA machine. It's a mess, but it is undeniably human.
I think that deserves a little more respect.
The article talks about JIRA metrics. Teams the measure productivity, time spent, code produced, deadlines. Ins't that a poor attempt at making human team work _deterministic_? Don't get me wrong, I don't think that's completely useless, but it certainly can be detrimental to both engineering and business.
I'm not saying you do those things or preach that pure metric-based system. However, you are making a comment on an article about it, and I think that in the middle of your rant, you reversed the roles a little bit.
Deleted Comment
This statement is on big pile of BS. From a practical standpoint there is nothing deterministic about software systems and their interactions in enterprise.
One of the hidden variables being the same machine which is supposed to bring order to chaos: product managers and their interaction with sales teams and upper management.
Dead Comment
I can promise you there are plenty of companies that have not drank the kool aid and, while they might leverage LLM tools, they aren't trying to replace developers or expect 10x out of developers using these tools.
Any company that pushed for this kind of thing is clearly run by morons and you'd be smart to get the heck out of dodge.
I've seen companies previously adopt rules like "Everybody needs to use VSCode as their editor" and it's normally a sign that somebody in charge doesn't trust their engineers to work in the way that they feel most productive.
I despise mandates like this. My rule for the engineers under me is:
We will pay for your IDE (if it costs money) and you are free to use whatever you want but if you get stuck I’m only going to help you on IntelliJ (IDEA). Others might be able to help you with VSCode and that’s fine but “I can’t get it working in VSCode” is not a valid excuse. I know it works in IDEA so you can use that or figure it out yourself (assuming it’s not delaying your work significantly).
Essentially use whatever you want, but I’m not going to be supporting it. You can use emacs for all I care (and some do), as long as it doesn’t get in the way of doing your job.
Here's a report about the bug: https://www.catonetworks.com/blog/cato-ctrl-poc-attack-targe...
My own notes on that here: https://simonwillison.net/2025/Jun/19/atlassian-prompt-injec...
Deleted Comment
Connect to the business.
I often seen engineers focus on solving cool, hard problems, which is neat. I get it, it's fun.
But having an understanding of business problems, especially strategic ones, and applying technology as needed to solve them--well, if you do that you stand out and are more valuable.
These type of problems tend to be more intractable, cross departments, and are techno-social rather than purely technical.
So it may take some time to learn, but that's the path I'd advise you and other ICs to follow.
One can only know so much. If on top of all the intricacies about distributed systems, software engineering, dbs, leadership and a large etc., we also need to know about the "business", well, what are we then? How do we acquire so much knowledge without sacrificing our entire free time?
Sure thing there are individuals out there who know a lot about many things, and those are probably the ones companies want to hire the most. But what about the rest of us?
No, they don't. They want specialists, as you point out.
this is such excellent advice, and it will keep you relevant as an engineer so that you know the thing you're building solves the actual problem
Connecting to the business keeps you valued at your current job. You do things that are unusual in industry, to create great impact for your company.
But if you tell how you achieved those things in an interview, the decision maker, who is usually another technical person, will raise eyebrows hugely. For your next job, it is best to nail industry-accepted techniques, i.e. coding and system design interviews.
Stick to business impact in your current role too much, and you become irrelevant to your next job (unless via referral or unconventional routes).
This holds true even until senior leadership roles.
The main claim is fine: If you disregard human expertise, AI can end up doing more harm than good.
Biggest weakness: Strong sense of 'us vs them', 'Agile Industrial Complex' as a term for people working outside engineering, derogatory implication that the 'others' don't have common sense.
Why not address that no one knows how things will play out?
Sure, we have a better idea of how complex software can be, but the uncertainty isn't reserved to non-engineers.
Look at HN, professional software developers are divided in their hopes and predictions for AI.
If we're the experts on software, isn't our job to dampen the general anxiety, not stoke the fire?
It’s a large system, too large for any person to understand. This system is poorly and partially documented, and then only years after it’s put into place. The exact behaviour of the system is a closely-guarded secret: there are public imitations, but they don’t act the same. This system is known to act with no regard for correctness or external consistency.
And this system, and systems like it, are being used, widely, to generate financial presentations and court documents and generate software itself. They’re used for education and research and as conversation partners and therapists.
I have anxiety and honestly, I think other people should too.
I feel unease about LLMs too, along with a sense of appreciation for them.
But this post does not seek to persuade, otherwise it would be written for non-engineers. This post panders.
I find it so odd that 'agile' is something that people chose to hate. What dysfunctions did 'agile' itself bring that had not been there before? Didn't managers before 2001 demand new features for their products? Did they use to empathise more with engineering work? If they hadn't yet learnt about t-shirt sizes, didn't they demand estimates in specific time periods (months, days, hours)? Didn't they make promises based on arbitrary dates and then pressed developers to meet those deadlines, expecting them to work overtime (as can be inferred from agile principle 8: "agile processes promote sustainable development ... Developers should be able to maintain a constant pace indefinitely)? What sins has 'agile' committed, apart from inadvertently unleashing an army of 'scrum masters' who discovered an easy way to game the system and 'break into tech' after taking a two-day course?
In fact I wager that coding is...20%, maybe 25%? of the work that goes into providing value*? So Amdahl's law says having AI optimize that part isn't going to move the needle all that much
*it's certainly possible to expend lots more effort coding, but is it coding in the right direction?
Because it adds hours of nearly pointless meetings to your workweek? The time spent in standups and retros and sprint planning and refinement that imo add nearly no value is shocking...
One of the most important aspects of following an Agile methodology is that teams are expected to be self-organising, so if the meetings you're participating in aren't working for you, you should absolutely be discussing that with your team. It could be that others do find them valuable, but you might well find that they feel the same as you and would be willing to consider how to make them more effective.
I worked in fiance once with Agile, where there exists in the culture an infinite growth mindset. So I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it. Some companies probably don't suffer from this though.
> ...
> I worked in fiance once with Agile ... I found that we were putting a metric to everything possible, expecting future "improvements" and peoples' salaries were dependent on it.
It's fascinating to me how different a meaning different people put into the word 'agile'. The 'agile' of the founders was about small teams, close collaboration with the customer, and frequent feedback based on the real emerging working software, which allowed the customer to adapt and change their mind early (hence 'agile', as in 'flexible'). What it contrasted itself to was heavy, slow-moving organisations, with large interdependent teams, multiple layers of management between developers and customers, and long periods of planning (presentations, designs, architecture, etc.) without working code to back it up. All this sounds to me like an intuitively good idea and a natural way to work. None of that resembles the monstrosity that people complain about while calling it 'agile'. In fact, I feel that this monstrosity is the creature of the pre-agile period that appropriated the new jargon.
Deleted Comment
That would make up for a very good movie.
This will feed into existing mistrust, that developers are whiny, just trying to pad out their resume with new shiny, tinkering as opposed to delivering value, and the c-suite are clueless and don't understand engineering. But we've never had a tool before (except maybe outsourcing) that can present itself to either party as either good AND bad depending on your beholding eye. So I feel like the coming years could be politically disasterous.
One thing I find curious, is how the biggest tech companies today, got to where they are by carefully selecting 10* engineers, working hard on recruitment and trying to only select the very best. This has given them much comfort and a hugely profitable platform but now some of them seek to undermine and reverse the very strategy that got them there, in order to justify their investment in the technology.
For the cynics, the question is, how long can the ship keep holding its course from the work already done combined with AI generated changes? As we see with Twitter and Musks ad-hoc firing strategy, the backend keeps trundling along, somewhat vindicating his decision. What's the canary for tech companies that spend the next few years firing devs and replacing them with AI?
Another curious thought is the idea that concepts of maintainability will fly out the window, that the c-suite will pressure engineering to lower pull request standards to accept more autonomous AI changes. This might create an element of hilarity where complex code bases get so unmaintable to the eye that the only quick way of understanding them with be to use an AI to look at them for you. Which leads to what I think a long-term outcome of generative AI might be, in that it ends up being a layer between all human interaction, for better, for worse.
I believe its possible to see early seeds of this in recruitment, where AI is used at the recruitment end to filter resumes and some applicants are using AI to generate a "tailor made" resume to adapt their experience to a given job posting. Its just AI talking to AI and I think this might start to become a common theme in our society.