In any case, two things can be simultaneously true:
1. Writing code is not the bottleneck, as in we can develop features faster than they can be deployed. 2. It's annoying and disruptive to be interrupted when doing work that requires deep focus.
Its because it comes from the same political faction. In general people are open about A when A seems palatable, and openly B when B seems palatable, but they almost never admit to do that when its obviously wrong to do so.
That is the rational part of the fallacy, even if these are different sets of people you can still tell they are biased since they never appear in the threads where its obvious they are in the wrong.
For example, lets say in a thread where a white cop shoots a black guy you find a lot of republicans say "this is just statistics, nothing to see here". Then in another thread where a black cop shoots a white guy republicans pour in and argue this must be racism and we should investigate! Maybe it isn't the same set of people, but its still a strong sign of problematic bias that they only choose to speak up in those particular threads and not the others.
Every political side everywhere does this, and that is why people started calling that out.
But nah, clearly they're all goombas.
I think it's very silly to make the argument that "groupwise hypocrisy" is not a fallacy in such a conversation. In politics, the reality is that people have to form coalitions with people with whom they don't agree on everything, and non-political groupings are even more non-sensical, often holding people responsible for the opinions of other people who happen to share things like inborn characteristics. It's especially ridiculous to explain this with this idea that people are engaging in some kind of elaborate coordination to argue with you on the internet. Yes, some people, and indeed political parties, engage in that kind of behavior, and if you think you're arguing with something like a botnet, there are larger considerations to make about what you gain as an individual by trying to engage with such a machine at all. If I believe I'm arguing about the merits of an idea with an actual person, and I find myself reaching for something like "your group is collectively hypocritical on this issue" to make my argument, this is cause to reflect on whether I actually have any real arguments for my position, as that one is... well, essentially meaningless
I think you're trying to invoke what's commonly called a "motte-and-bailey" argument, where people argue for a maximally-defensible position when faced with serious criticism, but act as though they're proving a much less defensible version of their argument, often including a nebula of related ideas, in other contexts. This is something individuals and coordinated factions absolutely do, but again doesn't really support treating any grouping you want to draw of some kind of collective hypocrisy. Even assuming we care about hypocrisy, it seems like this kind of reasoning about nebulous groups that don't explicitly coordinate would allow making that argument about any position in any context, depending on how you draw the boundaries of the group that day. It's well-understood that you can go on the internet and find someone who believes just about any crazy thing you can think of, or find someone who makes the argument for any position poorly.
it concerns you because you have a good authority over your spoken language, and like most people with those skills I presume the language flows easily from you.
that ability isn't guaranteed, for a lot of people expression is tough, and those people felt equally alienated when confronted with an essay of word salad about why their opinion is wrong.
An LLM is a tool. In the 90s I would read columns and editorials about the disgusting faux pas of replying to a wedding invitation via such a cheap trendy medium like internet e-mail , now you receive death certificates that way.
It's not all bad, simpletons can use LLMs to have the critiquing essays turned into 5 word ELI5 statements that they can become enraged over once all the nuance is stripped. That's fun!
A "human" is just a "featherless biped", after all?
I think the Goomba Fallacy captures something helpful to me- it's helpful to know the origin of a straw man if you want to un-stuff one.
Gave me a good laugh, thank you. :)
Although at least it has some cross-cultural references. Why is naming so hard.
First, it becomes possible for people who have a double standard to hide behind this. One can try to track an individual's stance, but a lot of internet etiquette seems to be based on the idea of not looking up a person's history to see if they are being contradictory. (And while being hypocritical doesn't necessarily invalidate an argument, it can help to indicate when someone is arguing it bad faith and it is a waste of time as someone will simply use different axioms to reach otherwise contradictory conclusions when they favor each.)
Second, I think there is the ability to call out a group as being hypocritical, even when there are two sub groups. That one group supports A generally and another group supports B generally (and assuming that A + B is hypocritical), but they stop supporting it when it would bring them into conflict indicates a level of acceptance by the change in behavior. Each individual is too hard to measure this (maybe they are tired today, or distracted, or didn't even see it), but as a group, we can still measure the overall direction.
So if a website ends up being very vocally in support of two contradictory positions, I think there is still a valid argument to be made about contradicting opinions, and the goomba fallacy is itself a fallacy.
Edit: Removed example, might be too distracting to bring up an otherwise off topic issue as an example.
But if A and B are opposed, then there is a question of why a strong position on A can be allowed with a weak position on B, if the reason for the strong position on A would also indicate a strong position against B.
The underlying argument being implied (but rarely ever directly stated) is to question if your reason for the strong position on A is really the reason you state, or if that is just the reason that sounds good but not the real reason for your belief.
In effect, that you don't apply the stated reason to B despite it fitting is the counter argument to why it doesn't actually support A.
If there is an inconsistency in arguments being applied, any formal discussion falls apart and people effectively take up positions simply because they like them, contradictions irrelevant. This generally isn't a good outcome for public discourse.
Steering a LLM also requires deep focus. Unless you want to end up on accidentally quadratic or have a CVE named after your project.
Reading 10x more code than before puts me straight into the zone. (In a language that I find interesting: Elixir)
My own process is improving so much that I had only one bug last week that was fixed immediately after the error tracker caught.
But yeah I feel more tired sooner. So it's oneto three hyper focus zones per day, just like before.
The difference is that I enter faster, and now I'm not afraid of leaving the task and resuming later, since I can just ask for a summary of what we did so far.
I'm using two different models from two different providers to cross check the work tho.
I'm very good with bad smells I guess, after years supervising less experienced developers since early days in my long career.
And requiring review of the result is not a "flow state". Flow states means continuous and uninterrupted focus while actively performing, LLMs block and return with new code or questions for minutes on end. That's the opposite of flow, it's the "let's take a break now, see you in a few minutes" for every interaction.
Are they devs or performance artists by now?
That's an organizational issue due to over-regulation, bureucracy, too many stakeholders each with their own irrelevant opinion, etc.
Startups or FOSS projects without the above absolutely can't "develop features faster than they can be deployed", and usually have a huge backlog of bugs and features they'd like to have, but never got around to.
In any case, the point still stands: most companies absolutely can't code "faster than they can ship" and for that have huge backlogs of things they'd want to add or bugs to fix.
I think there are small pieces of truth on both sides of the argument, but I find the sudden change to claiming that coding speed doesn't matter to feel half-baked. Coding speed is part of building a product. Speeding it up does provide benefit. There's a lot of denial about this, but I think the denial is rooted in emotion more than logic right now.
It can take a whole day to find 10 good lines to write.
So we've come full circle to code writing speed being a factor again? :)
In all seriousness, this just feels like a never-ending list of attempts to try to resist any notion that LLMs might accelerate software development, however small the increment. The original article was arguing that organizational and collaboration was the bottleneck and that taking a whole day to think about the code was not.
I could not have done this nearly as quickly. On the other hand, I gave it clear, precise instructions.
Fundamentally, LLM do not construct a consistent mental model of the codebase (this can be seen if you, uh, read LLM code,), and this is Bad for a lot of reasons. It's bad for long-term maintainability, it's bad for modelling this code accurately and it's behaviour as a system, it's bad for testing and verifying it, etc. Pretty much all of the tasks around program design require you to have that mental model.
You can absolutely get an LLM to show you a mental model of the code, but there is absolutely nothing that can 100% guarantee you that that's the thing it's using. Proof of this is to look at how they summarise documents, to look at how inaccurate a lot of documentation they generate is, and to look at how inaccurate a lot of their code summaries are. Those would be accurate if the LLM was forming a mental model while it worked. It's a program to statistically generate plausible text, the fact that we got the program to do more than that in the first place is very interesting and can imply a lot of things, but at the end of the day, whatever you ask for it, it will generate text. There is absolutely no guarantee around accuracy of that text and there effectively can never be.
You’re right that LLMs specifically have no guarantees about accuracy nor veracity of the text they generate but I posit that that’s the same with people, especially when filtered through the socialization process. The difference is in the kind of errors machines make compared to ones that humans make.
It’s frustrating we’re using anthropomorphic concepts like hallucinations when describing LLM behaviors when the fundamental units of computation and thus failures of computation are so different at every level.
> The difference is in the kind of errors machines make compared to ones that humans make.
There's another difference, and that is that other humans can learn and study that mental model (which is why "readable code" is a goal — the code is a physical manifestation of the model that you, the programmer, has to learn), and then the model can be tweaked and taught back to the original programmer, who can then think of that tweak in the future. Programming is inherently (in most cases) a collaborative art, because you're working with people to collectively develop a mental model and refine it, smoothing it down until (as Christopher Alexander said) there are no misfits between the model and the domain.
I've done a lot of "rebuild" / "second system" projects and the recurring theme is that the new version does less than the original. I don't think that's entirely down to the reality of second systems, I think that's in part because software grows over time but developers / managers rarely remove functionality. A full rebuild allows product owners (usually different from the ones of the original software) to consider whether something is actually needed.
Meetings that increases sync between customer and coder are few and precious.
In large organisations ceremonial meetings proliferate for the wrong reasons. People like to insert themselves in the process between customer and coder to appear relevant.
I personally am fond of meetings with customers, end-users, UX designers, and actual stakeholders.
I loathe meetings with corporate busybodies who consume bandwidth for corporate clout.
No, I don’t need another middle manager to interface themselves between me and my users.
Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated without me or our customers isn't disrupted and doesn't need adjustment. That would invite reprimand from the director, and the extra work would be terrible for them, I understand.
I'm reminded of this recent thread in which Heroku left the devs in charge and suddenly features that the author had requested for years got implemented: https://news.ycombinator.com/item?id=47669749
What hermit wouldn't love meetings that simultaneously insist that you do more while taking away time to do it, all to avoid adjusting a pollyanna quarterly plan and budget!
> Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later?
is actually you (or some other reader) please quit/find a new job ASAP even if it means a pay cut. You don't want to deal with back issues, heart issues, weight issues, digestion issues, blood sugar issues - none of that. Please respect your body and your limited time with us. A coworker of mine had a stroke at thirty - that is a life changing event with, honestly, no real paths to full recovery.
Value your body, value your life. Your bosses see you as a piece of meat.
I am a former Dev turned PO/PM and now CEO, I can tell you many a developers are not fond of those meetings you are fond of and people like myself don't insert our selves where we don't belong, we simply join the meeting and have the vital conversation with the customers/stakeholders whos payments make payroll possible, while the developers refused to.
My team have always commented and liked that I "shielded" them from the none technical meetings and distilled customer needs in our kanban, without them having to go to the meeting. While I agree this isn't the "best way" to do things, I simply have never seen a Dev Team work as the way HN tries to make the role sound "Dev/Eng and the customer is the only thing needed". Would love for this to be the case!
Also for those who think I'm down talking the abilities of my team, we made a company together when we left a huge company we worked for, as Co owners and even now we use same setup is used :)
Truth. I'm that person and didn't appreciate how rare I was until I became an EM and learned that most of my team would actively avoid conversations with the customer. Even though I have no way to quantify it, I'm sure it's benefitted my career.
I think a lot of HN truly believes that Software Developer is the only important role at their company. Software goes straight from the developer's brain, through his fingertips into the computer, and then on to the online store (run by nobody) for customers to buy. Engineering managers, program managers, product managers, marketers, MBAs, tech writers, QA, lawyers, process people, various admins and liaisons... they all exist to play pointless political games, have distracting meetings, and obstruct the One True Role. Design docs, planning, schedules, e-mails, JIRA, reviews, syncs, exec updates... all are useless parts of a scheme to torture the developer. It should just be "developers developing, and then money comes in from somewhere." This is an exaggeration, but you see these themes all over the comment section.
I doubt that. A lot of HN might have believed that some 10 years ago, perhaps, but most of those people have either matured or been driven away by the shift in the discourse.
I was one of the people who used to believe that, but the years of experience have taught me several important lessons that changed my mind. That change in attitude came both from my own failures and from having the rare privilege to work with people who were actually good at those other roles you listed.
> This is an exaggeration, but you see these themes all over the comment section.
And you'll keep seeing those comments, just like you'll keep seeing the comments about how developers are hypocritical divas. Those comments come from people's bad experiences.
Workplace political games are a thing. Unnecessary meetings and documents are a thing. Problematic, unprofessional developers are a thing.
It all begins with a product and a sale. That's how you go from zero to one.
Then if you're lucky enough to become an organization and start to have organisational problems you hire HR, accountants, lawyers, and managers.
But there will always be a dichotomy between core and auxilliary roles.
A coder and a salesman can create something out of nothing. We create the garden and those who come after tend to it.
Tech companies who grow large and old enough to forget that product and sales are the bedrock on which everything else stands decay and die.
When I get good feedback it's like winning a prize and when it's bad it lets me see where we should be spending our time rather than were we perhaps thought we should.
Though I agree, most managers are BSing way too much, but the reality is that most Devs cannot navigate conversations like they think they can, and like you said, nor do they want to. And that is exactly what the managers do.
This matches perfectly my experience in working in many companies, where in most of them meetings were useless, but in a few places meetings were very useful, depending on how the companies were organized and how the attendance to meetings was selected.
I have seen projects that had to be abandoned without bringing any money, despite being executed perfectly according to the specifications. The reason was that the specifications were wrong because the customers have not thought about describing some requirements and the developers could not ask about those, because of lack of direct communication, while the middle men had no idea about both things, about what the customers might require and about what the developers might need to know.
That comes with real tradeoffs, but I've never regretted that path.
How is it hypocritical?
If in the old world, the very important process that used up a lot of time and benefited greatly from no distractions was the actual writing of code then interruptions for various ceremonies with limited value other than generating progress reports for some higher ups would feel like a waste of time.
That same person in the 'new' world where writing code is very fast but understanding the business and technical requirements that need to be accomplished is the difficult part would then prioritize those ceremonies more and be ok with distractions while their AI agents are writing the code for them.
It's not hypocritical to change your opinion when the facts of the situation have changed.
I’ve noticed this push to try to clothe hypocrisy in made up virtues like intellectual curiosity and mental plasticity a lot lately. All I can think is that it’s some kind of ego satisfaction play people make when their place in the world is threatened.
How to do it? Focus on writing code.
New value: Producing high value software.
How to do it? Focus on writing specs for code / identifying needs.
I expect there are a lot of hypocrites in the mix, scared for their job. But this isn't a fundamentally hypocritical position - agents are changing the game for how software gets produced and the things that were important as recently as a year ago might reasonably be said to be irrelevant now. Ironically, we might yet see a great software engineer who has never written a program in their entire life. The odds are slim but it is possible now.
Old value: Returning value to shareholders.
How to do it? Treat your employees like family and don't be evil.
New value: Returning value to shareholders.
How to do it? Treat your employees like human resources and get away with what you can get away with.
Is this hypocritical? Most people would say yes, but in your framing it's not because we've backed up to the least specific articulation of an underlying principle. It's a species of the motte and bailey fallacy.
Agents may be changing the game for how software gets produced, but all it's really done is switch software developers from being managed to being managers. And software developers trying to square their historic value/principle that management tasks are useless, easy, and ceremonial (to borrow GP's word) tasks that should take a back seat to ~flow state coding~ with their new view that management is an integral, difficult, and requisite part of writing code reeks of hypocrisy.
I'm happy to defend that one too, for the reasons you outline. It is completely normal behaviour from a company, everyone understands it [0] and most managers I've worked with would be happy to talk about it openly. It isn't hypocritical. It'd be hypocritical to pretend that there was some sort of long-term commitment in an employment relation, but that isn't implied in your example.
Changing your behaviour when the situation changes isn't hypocrisy. That is just being aware of the conditions around you. Hypocrisy is pretending your behaviour is principles based, then clearly not following the principles. To show hypocrisy, you have to do two things (1) show people claimed to be following a principles and (2) show that they are not following it. In your scenario, you haven't identified a principle that people are being inconsistent with.
I note you threw in a "don't be evil", so maybe you're thinking of Google. Google is hypocritical, because it claimed to be acting on principles ("don't be evil") and then didn't follow them when it became inconvenient. But if it'd just been honest up front that it was a normal business and would act responsibly to maximise profit it could have undertaken exactly the same actions and not been hypocritical. It was the professing of principle in advance that made the hypocrisy, not the action. Claiming to "not be evil" is unusual for companies, because while they are immoral they usually only lie when it is detectable that it is to their benefit and they're usually just cynical, not hypocritical.
[0] "should" understand it, I suppose. One born every minute.
You can't be a dick on this platform without fancy prose I guess.
Looking at a slice of most folks' workday and calling it their whole job is in my opinion, incorrect.
Uh yes it does?? What are you talking about.
I don't think switching one's passion on a dime is a valid escape hatch from hypocrisy.
You're wrong. It's a virtue.
There is a reason (well, many reasons) that, if I'm working on a creative project with somebody outside a company, we would never think of reaching for Scrum ceremonies or Jira.
It is more than perfectly consistent to complain about that while valuing collaboration.
1. µManagement asking "What have you even been doing?" Now they have a dashboard, and I have a nice record.
2. Protect me from people who wouldn't tell me problems existed, but would tell their managers they were blocked by those problems. Now, the understanding is that if the Jira doesn't exist, then the problem doesn't exist.
3. I use the "On Hold" state of an issue for a clear signal, for them and their managers that I add as watchers, that there will be no progress until whatever requirement is met (question answered, etc). It dramatically decreases response times, and means I don't have to nag them. Goes back to #2, where I can point out that they are blocking themselves.
All these things come into existence because people are so bad at collaborating, but really good at pointing fingers.
In some places, the ticket tracker works top-down: only the manager creates tickets, and the manager makes measurements about tickets closed, velocity, and so on to assess the productivity of their team.
I think the great divide on JIRA and JIRA-likes often comes down to which culture people have been exposed to.
It might be easier to collaborate with one other person through email or text message history. Or even two or three people. But beyond a certain point having tickets to track all the conversations about a task becomes invaluable.
The problem rather is: often good programmers have quite good ideas how these problems could be solved, but for "organizational politics" reasons they are not allowed to apply these solutions.
Thus:
Concerning (B): Because they are not allowed to apply their improvement ideas, they are the bottleneck. But being the bottleneck is not the root problem, but rather a consequence of not being allowed to improve things.
Concerning (A): It is indeed often the case that if you simply let someone else do the work, the code quality decreases a lot and in subtle ways. Good programmers are very sensitive (and sometimes vocal) with respect to that - in opposite to managers.
I’ve been on all sides of this coin, and there is plenty of blame, misunderstanding, and bad ideas to go around.
Pushing a 90% solution through is a ‘win’ for the coder who is leaving, and hurts everyone on a continuing basis. It’s bad accounting, and lets the consultant look good for making the team perform worse (and look bad later).
And, IME, if that 90% solution needs a 100% rewrite after 40-80% burn in bugs and error chasing? What once was a bit behind is now way behind with staffing issues. Sunk costs don’t create extra budget.
Do It Right The First Time doesn’t always apply, only mostly always. Some people are insecure and territorial, yeah, but some know what their job is.
Entrenched engineers don’t want to you to alleviate or god forbid share the pain. Pain is good for employment security. And if the ship goes down, they’ll make sure they’re the last one to get fired, because there’s nothing the entrenched engineer fears more than having to job hunt.
The manager didn't do the work to figure out what a contractor should do before hiring one. Why would they expect that org to plan the exit if they didn't plan the entrance?
Behavior shouldn't be surprising, no?
I mean it really sounds like you're not on their side at all. It's their job to help you succeed, apparently. From what you've said already, you don't care about the project either. You're happy to waste time and money. It sounds like they're right not to trust you.
If I'm a manager of a team thats struggling and now also sabotaging additional resources, because they havent got the right warm and fuzzies, I'm going to be looking to have some difficult conversations. I'm also going to be very critical of anyone who floats a lack of "trust" as the blocker without some concrete evidence to justify it.
Whatever concerns they might have is not for the contractor to address. They are between them and their own management who deemed them unable to deliver sufficiently.
Resistance is also not the same as sabotage. My assumption is that everyone is acting in good faith from their own perspective. An immediate issue I see that the contractor was brought in because folks were looking at the calendar and not the tasks. Now the team is being pushed to carve out tasks. If shovel ready tasks are identified first, almost certainly, things go smoother. You're not context switching everyone. Its far less chaotic.
What you seem to not understand is empathy is going to move the team forward and deliver. Jumping to bad faith immediately is likely not the fastest way to a solution. If someone is struggling, its useful to understand why and address those problems. Its often not because they're bad.
True, most engineers hate meetings because as your rightly point often there can be too many "types" of meetings - team meting, issue tracking, backlogs, design reviews, triage etc etc. Out of the 7-8 working hours, a senior engineer might be in meetings for 4-5 hrs. Then they bitch and moan that they are spending too much in meetings and not enough time coding. A reason for that is projects often have unclear or even changing requirements along with tight deadlines.
Sure today with AI, code can be produced faster than ever. But the requirements being unclear or always evolving hasn't really changed. Today many non-engineers assume that what they have in mind is straightforward and can be created by AI. That is not true. Unclear requirements lead to unclear results. Garbage in Garbage out. Getting the right input is still the most important part of software. That has not changed. That is the collaboration piece of software.
And sure within the software community there are folks who don't like to collaborate even on requirements, they are more than happy to follow someone's lead. They like their manager/architect to "shield" them and do these tasks for them. These silent warrior type engineers are going to be the most impacted due to AI coding. Because they have no visibility and even if they are 5 rated coders, there is always going to be "But AI can produce code. What else can you do if you wont even collaborate?"
So, it's not very cut and dry. Engineers come in all shapes and size.
No developer was ever unhappy to communicate. But when pointless communication occupies too many long hours, interrupting useful the progress of understanding what could and should be done (by coding, yes, experimenting, getting a grasp of the beast), then yes they became unsympathetic.
I've worked with engineers all over the spectrum in terms of their styles, beliefs, and preferences... and some of them are frankly not very interested in getting out of their comfort zone (like heads down, writing code and being alone), and optimizing for the group rather than themselves.
So yes, they are in fact unhappy to communicate (in a general sense), because of how tedious and uncomfortable communication often is.
I'm not saying it's irrational or immoral, or not driven by the types of past poor experiences you mention, but in my experience it's often pretty obviously suboptimal and highly frustrating to work with.
If anything, genAI for coding is making engineers seek more engagement, that can't be a bad thing given the fracture between the business and product development.
Who?
There are millions of software engineers around the world. It's quite likely that they have a few different opinions and point of views!
>the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state" they claimed as their most essential and sacred activity
Seems pretty clear to me.
"I doubt the GP has gone back through their career and checked on each person who thought there were too many meetings have now all made the switched they're being accused of, though."
Anyway, I'm stopping this now as it's not a constructive conversation anymore. Let's agree to disagree.
1. Increased velocity makes rituals like daily standup and other comms relatively infrequent compared to how they used to be, so there are fewer touch points now. For example a daily standup might have been occuring several times while someone worked on one feature ticket, but now they can bang out multiple features a day plus some bug fixes, but still only have the daily touch point.
2. AI written code needs to be thought through and planned a lot more than human written, because the machine doesn't go through the same discovery/writing process that a human goes through. It looks superficially similar, but is subtlely and importantly different.
3. Without solid planning and requirements definitions, it's a lot easier for AI to go off the rails and do something you don't ultimately want. That wasn't true for humans writing code because they have a lot of project context knowledge that helps a great deal. AI obviously doesn't have this.
4. With the intense speed of devs now thanks to AI, it's far easier to step on each other and end up with at best merge conflicts, at worst significant deviation in solutions, and often major refactors/overhauls that can make the codebase feel foreign and confusing to devs. Most people have had the experience of stepping away from a project and coming back after a refactor had been done, and realizing that they don't know where basic things even are anymore. It can be unsettling and add a lot of friction.
5. AI can be pretty good (and very fast) at producing documentation and plans, so the "cost" of planning before coding is a lot lower now. That changes the equation of "what is the most important thing to spend my time on to iterate quickly".
- Understanding the problem at hand
- Putting all the pieces together so that they solve the right problem the right way
- Making sure that the solution facilitate future extension and doesn't lead to a ball of mud two months from now... Unless stakeholders want it to be quick and dirty, then making sure they understand the costs/risks
- Planning execution a way that is incremental and testable so that we can build confidence that the system is doing what we expect of it
- if you are in a team, figuring out common dependencies so that those can be done first and unblock parallelism on execution.
Once all that is done and documented, writing the code was easy and fast.
What would sometimes happen is that some unexpected detail or dependency would be discovered as part of the writing of the code and then you are back at the beginning, figuring out how to make everything fit together.
I find that the main confusion comes from people not realizing that those are two different activities and instead calling it all "writing code".
I think one of the things that AI is uncovering is how bad many programmers were/are at this. Sure , they may understand by ref vs. by val, but they can’t or won’t take the time to really understand what needs to be built.
I’ve said for a long time that coding is the easy part, it’s understanding what needs to be built that’s hard. AI has now come along and born that out.
I think the solution will be small (1-5 person) teams where product and engineering sit next to each other and have clear authorization to launch directly to prod at their discretion. The gripes about performative work tracking mechanisms and the realization that non-tech considerations are now the bottle neck are not mutually incompatible.
In fact, deep pipelines don't even need to have bottlenecks to take time. Even still any given meeting could still be a waste of time depending on the meeting.
They are not the same people.
> It's hilarious ... their most essential and sacred activity ... suddenly, and with no hint of shame ... the nakedly hypocritical attitude ... still extraordinary
Calm down the hyperventilating for two seconds, look around, and you’ll immediately see examples of the same group of people who now biTch aNd mOaN about how agentic coding is killing what they love about programming.
It’s interesting to see people either gloat or get incensed at the nerds who like computers in the context of these developments.
[With that said, the specific implementations of such collaboration are often still very painful and counterproductive...]
I don't think it's hilarious, I think it's rather sad to see people so easily trampled by the whims of an irrational market. Generally speaking, we benefit when people stick by their values, and yet we play this awful game where winning means abandoning our values in pursuit of "value" whatever that is.
Another example I can point to is software security. For context, I’ve built and sold two edtech companies that taught enterprise developers about software security .. It didn’t matter how good the training content was .. ouur product replaced boring appsec video training with interactive labs, vulnerable code snippets to hack and fix .. gamification ... leaderboards .. whatever it took so they couldn’t complain about having to watch boring videos .. however the completion rates sucked .. because they just didn’t care regardless of how hard we tried ..
Now post AI .. my Linkedn is full of blogs and think pieces about how important “software threat modelling” and “cybersecurity” are, and how “coding was never the hard part.” ... suddenly, TM, something only a tiny fraction of companies actually practice, is being framed as the real challenge .. and having deep understanding of OWASP / secure design , vulnerable dependencies ..secure architecture ,, is the real bottle neck .. lol
I'm seeing both these beliefs right now:
• Belief A: "I am a skilled professional whose value lies in my unique ability to solve complex problems."
• Belief B: "An LLM can now solve many of these problems in seconds for pennies."
This thread is great at showing how people are rationalizing by moving the goal posts, so to say
I don't think there is any hypocrisy. The error in the analysis is assuming both conflicting opinions are held by the same person. They aren't.
NONE of the activities you mentioned are activities that lead to what article talks about - well designed spec.
This is probably true of other fields too. But rolling back changes there is expensive (example construction).
But with software you can get to put things out and iterate. This is not to say identifying what’s needed isn’t important but you had roles where the product owner is getting feedback for the previous iteration while the devs are working on the current one.
With code assistants this loop collapses a LOT. Suddenly it can be a lot easier to define better what you need and in near real time also gauge how it would operate.
Both are true “leave me alone” and “you don’t know what to build”. Because the people identifying what to build aren’t the people doing the building.
I agree with this sentiment https://news.ycombinator.com/item?id=48033534
One of the reasons I liked coding is because it’s easy on a relative basis. Dealing with people, ambiguous requirements, edge cases, business realities, are all the parts that are hard.
American football player Ray Lewis said one time he was paid to go to practice, but he played the games for free. I feel the same way about coding - I was (and still am) paid to deal with everything else.
Unless you sign off on a Looks Good to Me PR and go loiter by the kombucha machine. Then you have other problems.
Personally I find it hilarious that the same people at my company who can't be bothered to write down detailed requirements and are constantly fighting any effort to do research or technical documentation or pay down tech debt are now trying vibe coding and struggling to produce anything useful. Oh you don't understand why you aren't getting the results you expected? Maybe you should try thinking deeper about what you expect before your rush your engineers or, now, your agents.
I am genuinely curious. I understand where you are coming from, you want to maintain flow state.
How does one effectively load the funnel to support flow state ?
Jira tickets? Requirements documents in some kind of ALM tool?
Having "house rules" on a team that new members must agree to follow tends to flush such people out and they usually exit on their own when their shenanigans get repeatedly called out as violative. Gotta introduce the rules in the interview process and get agreement after they join. Catching them out early is the key.
We had an intervention on one hard case and he rage quit the next day. I don't know why people do that, it's a small world and people talk.
In fairness, given the context those meetings give, it stands to reason that giving that same context to an AI, it can, in theory, still do the same thing as an engineer. But those meetings still need to be had.
If y'all can find that company where the product is entirely developed soup-to-nuts by a single lone-wolf developer, without any other stakeholders or involved parties, by all means join that company! And tell HN about it--many of us would join it, too. But in the real world, development is a messy people-soup and you have to communicate.
We've had systems that induce boilerplate before, and we've had systems that try to cope with that boilerplate before.
Considering the process to be tedious is really not the same thing as being antisocial.
But I have also worked with some who refused to participate in collaboration, they felt their time and ideas superior to others, and there's no excuse for that.
While I'm glad you posted this point of view/framing which honestly needs highlighting in the name of a better discussion, I must remind that the moaning back then was for the ceremony stealing time from building.
1-There is significant collaboration and action required beyond just coding to successfully create+implement software systems
2-When performing the coding step, minimal interruptions are vastly more efficient than working in little chunks of time
The focus is still the code.
The contradictions you see could mostly be variations across individuals rather than hypocrisy within individuals.
(Doubly so for vaguely defined groups, like "kind of engineer".)
Because even if someone is writing design documents you shouldn't be interrupting that process regularly either.
Even if coding was solved, meetings could still be the bottleneck.
You think spending more time on meetings is going to solve anything?
> team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews
Are frequently not:
> [important] collaborative activities
I've always been someone who disliked distractions from my "coding 'flow state' they claimed as their most essential and sacred activity to be protected at all costs" (because, you know, I was getting paid to write code and that's the only way I could actually get it done), but I also loved genuine collaborative activities (as in a small number of people, interacting with each other in a high bandwidth way, to figure something out or get on the same page).
A lot of the activities you explicitly mention are usually literal garbage for actual collaboration.
I'm going to assume you were getting paid to build software that solved problems and created value for your customers and stakeholders. Writing code has always been just one activity that's part of the job, and developers forget that and make statements like this! That's the parent poster's point. I'm not saying it's not an extremely important part of the job, or that people don't often collaborate poorly in ways that take away from the sacred deep work time, but framing it as "I get paid to do X and not Y" is just a highly limiting way to look at or talk about the role.
> I'm going to assume you were getting paid to build software that solved problems and created value for your customers and stakeholders.
That's a distinction without a difference. At least historically, I was "paid to build software that solved problems" and I was to do that by writing code. If I didn't write code, and enough of it, I'd be fired. Getting my flow state disrupted for no good reason was something I'd resist.
Also agile ceremonies are a drag, literally becoming the thing agile was originally supposed to be fighting against (not that agile is gospel, I've always disagreed with some of its practices). They're not a good reason. And I also mentioned an actual good reason. I should also note those meetings I was referring to positively were almost always with users, not tech people.
> Writing code has always been just one activity that's part of the job, and developers forget that and make statements like this! That's the parent poster's point.
I wasn't addressing the parent poster's point per se (and I noted that and why), just noting that a lot of the "collaborative" activities he cited were often not that collaborative, and the shade he was throwing at people who were unenthusiastic about participating in them was probably unwarranted and misguided.
tl;dr: OP needs to have more empathy. There are better ways to thread the needle of his observations than what was on display in his comment.
Also, expect harsh and rude reactions when pointing to big issues that are crystal clear in the middle of the village. Not all truths are warmly welcomed, especially when looking elsewhere feels more comfortable in the immediate experience.
Take care and don’t worry too much: the journey’s short, so remember to also enjoy the good parts.
(A)
Meetings where we discuss whether naming two users in an integration test `u1` and `u2` vs. `user1` and `user2` and whether whoever did the former is so hopeless that they should drop all computer work and go work on a farm, and spend an hour of meaningless and meandering style preferences.
(B)
Higher-level meetings where I can communicate with PMs and customers and CEOs almost on their level f.ex. "Does it make sense for us to have primary/co-borrower roles in our credit products or are all sides equally liable?".
---
With the advent of really good LLMs, meetings of Type A are nearly gone and meetings of Type B have increased meaningfully. I am very happy with that new state of affairs. Are you not?
The stark reality is this. Both coding and project management can be done with AI. I think coding is more important than all the fluff surrounding project management but with AI both are now ready to become obsolete.
The thing with project management is that it's a bit harder for AI to tackle because it's not just pure tokens it needs to deal with. We need to give the agent more tools to interact with real time and real world events for AI to fully take over this aspect of the job, but make no mistake... project management is easier in terms of skill (not in terms of effort).
Similarly, the amount of open source people who previously maintained a hardliner programming meritocracy stance and now pivoted to AI and market AI is exclusively limited to those whose companies are working on AI products. The good ones in that space are decidedly less than 1% of all good ones.
It's precisely because I get swamped with all the non-coding work that agentic coding works so well. And in multiple ways.
- it lets you get back in the flow faster (unless you were used to writing out your inner thinking monologues and reasoning to get yourself back to speed when you come back from a meeting).
- it lets you move faster and take on more on your own, meaning less people needed in the team, less communication/syncing/non-coding overhead.
If you're objective about it, AI coding is going to be amazing for individual productivity. It's probably going to fuck us (developers) over with the reduced demand, lower bargaining power, etc. But just on technical merits it's a great productivity tool.
The models are still not better than me at coding and handholding is required, but the speedups are undeniable, and we're long past the threshold of usefulness. So far all the contrarian takes are either shallow/reflexive pushback because people don't like the consequences, or people working in niche stuff where LLMs are not that great yet. But that has been shrinking with almost every release - in my experience.
I know everyone here writes cutting edge algorithms that were never encountered in the training data, their code is hyper optimized realtime bare metal logic that's used in life or death scenarios and LLMs are useless to them - but most of the stuff I do day to day is solve problems that have been solved before, in a slightly different context. LLMs are pretty good at that.
What even is your point? Are you... mad because the truthiness of a statement can change over time?
half the time you’re going to discover the right decision / path while you’re coding.
focus time went from hammering code to figuring out how to solve the problem. PRs are now how we exchange ideas. meetings are still productivity theater.
My opinion since college (8y ago) was that the best engineers are the ones who treat everything as halfway a people problem, even in low level code.
It's an inherent tension that every discipline has to wrestle with. The most experienced developers are in the best position to evaluate where LLMs are, but those who are the loudest about their own abilities generally aren't in this camp. Humility tends to come with experience, and arrogance tends to come with inexperience.
You see it elsewhere as well. There's now a cottage industry (with visible members like Ed Zitron) who have made a career out of creating and selling anti-AI content. At first they were complaining that AI lies constantly. As AI got better, they shifted to other talking points.
> There's now a cottage industry (with visible members like Ed Zitron) who have made a career out of creating and selling anti-AI content
I can't believe that Ed Zitron, who I just looked up, has made a career out of creating and selling anti-AI content. He's 40. He cannot have been doing that for very long.
> At first they were complaining that AI lies constantly. As AI got better, they shifted to other talking points.
Calling the truth "complaining" seems more revealing of you than them. If the AI was lying constantly, they weren't "complaining". They were telling the truth. Once the AI stopped lying so much, they stopped saying that as keeping on saying it would no longer be true. But there are still other issues to talk about. That's...right? Isn't it?
That's life.
Life changes and us along with it.
"Who Moved My Cheese?"
If the "goalposts" represent what people generally think LLMs are capable of, they should be moving, right?
And complex, multi-part, long term efforts like building software and software companies always have numerous obstacles. When one is cleared, you wouldn't expect there to be no more, would you?
Your tone is complaining, but I just see people working in reality.
Since I didn't agree with the premise of the top level post, I was scrolling down as far as possible to get to the second top level comment and yet here I am still scrolling.
From my perspective AI doesn't really accelerate me per se, it's more like the AI helps me avoid getting stuck.