Are you referring to the author specifically? Or a specific hypocritical person you know? If you're making a general statement about groups of online people you might be falling for the group attribution error[1], where the characteristics of an individual are assumed to be reflective of the whole group.

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.

[1] https://en.wikipedia.org/wiki/Group_attribution_error

This is a false dichotomy. Software development has always been about keeping people in agreement, from the customer to the coder, and all the people in between (the fewer the better).

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.

> nakedly hypocritical

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.

Ceremonies and tickets aren't especially effective for actual collaboration. They're primarily tools for making work legible and controllable to management.

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.

This seems to confuse cause and effect.

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.

It's 100% denial/ego. I've been a contractor longer than I'd like and it's the exact same response I see when I join a new team. The team complains they have too much work and can't get anything done, so their manager pulls me in. Suddenly, they don't want to give anything up. I'm actually in the middle of this right now. The team "is swamped" yet somehow, they are able to argue that almost everything I can handle is best handled by them and they don't need help. Fine by me, I'll sit around and get paid. But it smells exactly the same. They don't want to admit that A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload.

The bitching was about meetings and ceremonies that took away the little time left to spend time asking more features to be implemented, or revisited before it could get completed.

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.

No Thats not the same persons.Thats as simple as that. Those who used to be hyperfocused in the zone/flow so to get integrated designed consistent opiniated KISS Small-Is-Beautifull antipattern-free reusable code featuring the best abstraction layering with just the right amount of external dependencies and cognitive load ... these people are suffering a lot seeing the skills they cherished their whole life being devalued in less than a year. This opinion is a project manager's one. He's probably right. Both sides are right.

> the same kind of engineer

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!

What type of engineer, who until a year ago - because of AI apparently - is suddenly no longer concerned about code? Personally I'm just as concerned about code because AI has not changed the fact that it still takes a really long time to develop stable, secure software (ie- if you're making software to do ambitious things). Nothing about modern AI tools eliminate the need to get in the zone; using AI to amplify one's engineering skills let's us solve the next problem faster - but in software there are unlimited problems.

Just because I hate those ' team meetings, agile ceremonies, issue trackers, backlogs, slack, emails, design reviews, and anything else that disrupted the hours of coding "flow state"' - doesn't mean I don't understand how important they were and are. I moaned them before, and will continue to - but they were always important. I have learned the hard way more than once what happens when you sit at a keyboard and write code (one time I lost my job because the code I was writing was so far out from what the company needed, the next I realized what was happening in time to leave first - only after I was gone did they realize that what I was doing really was important and they made me a good offer to come back)

I'm not in the group you described so I don't want to speak for them, but I can empathize because there are some things that are meaningfully different with AI:

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".

I posit that getting into a coding flow state isn't just about producing code. It morphs and develops the problem space in the engineer's head. It helps them realize where the spec is lacking. It familiarizes them with the capabilities of the codebase so they can speak confidently about what future changes will entail.

I understand your sentiment, and there’s absolutely some truth to it, but I don’t think the path forward is throwing more management resources (or layers) at the problem. And I don’t think the management technology industry is the answer either.

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.

That was me. I complained a lot about meetings, design docs, etc. I did not understand that the process of discovery is messy and what looks inefficient is not really. I expected sharper meetings, shorter docs etc. In retrospect I see my naivety but it took me too long to change my attitude.

I think you're assuming the venn diagram is a circle here, I don't think that's a healthy perspective to have (in any context).

The activity that needed and still needs to be protected is problem solving:

- 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".

You’re describing a multitude of different people with a variety of viewpoints. It’s also smart to change your mind when the environment changes; code being easy to write is a decisive shift.

Just because concurrent design, QA, research etc push out the Gantt chart doesn't mean your meeting isn't useless.

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.

The people I know like this are people I consider to be "advanced juniors". They are held back by their inability to work with other parts of the business and understand customer needs. In order to be successful they need to be spoon fed requirements. What I've seen from the limited sample in my orbit is that they've actually doubled down on AI and are creating little private worlds of agents and further isolating themselves from the business, not talking about how great collaboration and such are.

Meanwhile people who bitch and moan about “other engineers” all the time haven’t changed at all. How refreshing.

I don’t think that’s the issue. The problem is that with software you don’t know what a user might like until something is in production.

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.

Is it hypocrisy or learning? A more charitable take - it wasn't too many years ago that I also decried the need for all the collaboration. But as I advanced in my career, that worldview just didn't hold up. In this case, maybe the introduction of agentic coding has accelerated that learning because now 'regular' engineers are forced to take on coordination roles.

[With that said, the specific implementations of such collaboration are often still very painful and counterproductive...]

An important thing can (and one may argue will) be overdone AND hvlfvssed stealing oxygen from another important thing.

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.

That's just scarcity based economics doing its thing.

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.

/s Oh noooo, it's like they're turning into managers... Now that machine can do their job better than them they've become as unimportant as you always thought they were, always pretending to be banging keyboard where it used less brain cycles than highly important work like posturing in a meeting did. Anyone can bang a keyboard even a machine can do that now, it can surely never replace important work of you having to 10 meetings. Lets replace all of them with machines and us meeting lovers can run the company with the machine produced work that we never have hope of understanding.

I agree with this sentiment https://news.ycombinator.com/item?id=48033534

I've had seniors tell me my entire career that writing code was the easiest part of their jobs.

Just because you use LLMs doesn't mean you don't need the "flow". Reading code SUCKS, getting into the flow is harder than ever.

Unless you sign off on a Looks Good to Me PR and go loiter by the kombucha machine. Then you have other problems.

I feel attacked. I still dislike most team meetings, agile ceremonies, etc. Slack and emails give me anxiety. A 30 min meeting will disrupt me for 90 minutes. But, yea, the code was never the bottleneck. Except maybe when I worked at a startup. All of the above are true.

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.

There's nothing hypocritical about preferring the part of the job that isn't the bottleneck and wishing one could spend more time on enjoyable things. Nor is code being called "inconsequential" simply because it can be done (more) easily.

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.

They sound like very important people no matter what the circumstances are, haha.

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.

There are 2 bands: you let people earn a living or you let investors/executives become richer every year to the detriment of workers. I don’t care about the medium, Im not with the big fishes

Two things can be true at the same time. Yes, those meetings are horrible, and plenty of times they're useless and can be summarised as "why wasn't this an email/slack message", but also plenty of those same meetings can equally be extremely important.

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.

Or the person just likes to lock into flow states at the point of maximum leverage. Previously that was coding. Now it’s commanding agents.

I've got nothing to add to the discussion but want to take a moment to appreciate your ability to construct long sentences. It flows beautifully.

That's an oppinion for sure, and a very shallow, general oppinion. Some people like solving problems, sometimes via code, while others tend to hide behind the 'Collaboration' banner, to help their own career progression. Both are legitimate tracks. To dismiss one, is to make the other appear 'non-Good'. But, perhaps data can be furnished as part of this post to support either as 'better'.

It's certainly the case that the collaborative ceremony can be mismanaged, and that is frustrating when you need time to implement. I don't expect that complaint to go away, those who are using AI heavily will replace it with not having enough time for prompting.

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.

The amount of cognitive dissonance I'm seeing on HN right now is concerning.

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

If coding by hand took 10x longer, why would it have bee unreasonable for people to demand more time to code? Seems like floored logic and you're just exciting to dunk on people?

I've been selling and managing my own projects for over six years, so I don't count myself in the antisocial camp. But LLMs haven't changed the fact that I like to have at least five hours of deep work every day.

They are still anti-social. But they see the “social” as a way to feed the AI better, to make better code.

The focus is still the code.

My sense is that it's the opposite. The people who complain about meetings, managers, and methodologies also complain about agentic coding. The people who are excited about frameworks, methodologies, and project management tooling are excited about agentic coding.

I have seen this play out too IRL and I am really enjoying the schadenfreude.

Did you ever try no meeting days and other methods to avoid interrupting thought workers?

Because even if someone is writing design documents you shouldn't be interrupting that process regularly either.

I do need to point out that not all meetings are equal, and the "hypocrisy" you are seeing may come from different groups of people.

Before, meetings (aka. coordination) bottlenecked the coding.

Even if coding was solved, meetings could still be the bottleneck.

You think spending more time on meetings is going to solve anything?

It's an astute observation but overstated. There are just as many programmers who view their activity as too sacred to consider using an LLM, even for relatively easy, predictable, or disposable work.

Generally, groups of people aren't homogenous.

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".)