9 ms·

It's hilarious to me to see the same kind of engineer, who throughout my career have constantly bitched and moaned about team meetings, agile ceremonies, issue

It's hilarious to me to see 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 to be protected at all costs, suddenly, and with no hint of shame, start preaching about about the vital importance of collaborative activities and the apparent inconsequence of code and coding, the moment a machine was able to do the latter faster than them. I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary.

drfloyd51 5mo ago
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.
forgotaccount3 5mo ago
> 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.
- abduhl 5mo ago
  Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable. 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.
  - roenxi 5mo ago
    Old value: Producing high value software. 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.
    - freejazz 5mo ago
      Sorry, did people not identify needs when developing "high value software" before? That doesn't seem true to me at all. I took a "Needs Assessment" course in my class of '09 undergrad...
    - abduhl 5mo ago
      This is shifting the principle/value discussion up to a level where it's meaningless. Let's use a different example. 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.
      - roenxi 5mo ago
        > 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. 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.
sillysaurusx 5mo ago
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.
- onemoresoop 5mo ago
  Code may be easy to write once you know what the code needs to do.
ftmootnomoat 5mo ago
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.
- msteffen 5mo ago
  Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals. 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 https://news.ycombinator.com/item?id=47669749
  - msteffen 5mo ago
    For that matter, here's a thread from a few days ago recommending the practice of scheduling status meetings for the purpose of pressuring the attendees to work on your project in addition to their other work: https://news.ycombinator.com/item?id=47906942 https://news.ycombinator.com/item?id=47906942 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!
  - munk-a 5mo ago
    Just on a personal note as someone who worked in the game dev industry for far too long and is still suffering for it... if > 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.
sdevonoes 5mo ago
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
dmm 5mo ago
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 https://en.wikipedia.org/wiki/Group_attribution_error
- knollimar 5mo ago
  Or just goomba fallacy
  - onemoresoop 5mo ago
    [flagged]
  - sermah 5mo ago
    til https://en.wiktionary.org/wiki/Goomba_fallacy https://en.wiktionary.org/wiki/Goomba_fallacy
    - SV_BubbleTime 5mo ago
      That’s kind of just strawman with an origin story isn’t it?
      - _diyar 5mo ago
        No because the goomba is the average of two real opinions, and the strawman is a distortion/reduction of any opinion such that its easy to argue against.
        SV_BubbleTime 5mo ago
        Ah, ok, so two real opinions made into a distortion. Right, I see how very dissimilar to an origin story of a strawman that is…
rafaelmn 5mo ago
Yes this exactly, it's getting ridiculous at this point. 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.
kenforthewin 5mo ago
Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?
- frollogaston 5mo ago
  This community hasn't agreed on either of those things, just like it never agreed on good coding practices. 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.
- kusokurae 5mo ago
  The community portion that unironically think AI is good enough now, are mostly managers and non/semi-technical people, and engineers who do not engage in critical or complex problems. HN has always been too much of the velocity-alignment-synergy class of professional talkers; it's just so much more obvious now that they feel emboldened in false confidence.
  - vehemenz 5mo ago
    There's some of that, but more often it's developers whose arguments are a year behind the frontier models or, just as common, they're dramatically overstating their abilities. 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.
    - deleted 5mo ago
      [deleted]
    - deleted 5mo ago
      [deleted]
    - goatlover 5mo ago
kj4211cash 5mo ago
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.
- Antibabelic 5mo ago
  Isn't solving problems, instead of blindly implementing a high-level description of the solution, your job as a developer?
  - bluGill 5mo ago
    There are problems you can solve, and problems that you cannot. Depending on the exact details GP may have been slacking for not solving problems, or correct in saying he can't do good work because he shouldn't be solving the problems alone.
  - kj4211cash 5mo ago
    I don't understand this reply. Yes, I solve problems all the time. And that usually requires thinking deeply about the problem. And that deep thought is difficult when I'm getting constantly pinged about other stuff.
- reachableceo 5mo ago
  Um… how do you get those requirements if slack / email give you anxiety ? And meetings are disruptive ? 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?
dwoldrich 5mo ago
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.
AussieWog93 5mo ago
Comments like these are why I still come to HN. Absolute kino.
jmull 5mo ago
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".)
ElatedOwl 5mo ago
no, these meetings are still hot garbage. 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.
psychoslave 5mo ago
Welcome in humanity my friend. 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.
deleted 5mo ago
[deleted]
raincole 5mo ago
> 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!
- moralestapia 5mo ago
  But it is written there, and GP was quite specific: >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.
  - robertlagrant 5mo ago
    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.
    - moralestapia 5mo ago
      Why does that matter?
      - deleted 5mo ago
        [deleted]
      - goatlover 5mo ago
        Because a claim was made about a group of people.
        moralestapia 5mo ago
        Exactly. Does it matter if one member of that class does not follow the trend?
notnullorvoid 5mo ago
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.
bluGill 5mo ago
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)
AnimalMuppet 5mo ago
But the flow state wasn't just about typing code. The flow state was about understanding the problem, about loading it into your head so that you could "walk around in it" mentally, so that you could figure out that what really needed to happen was that module X needed to add a getter to value foo, that module Y needed to get foo and make a change based on the value, and that the key to making this all work was to add a way for Y to access X that fit within the existing architecture. That took focus, far more than implementing the pieces did.
- Serhii-Set 5mo ago
  [dead]
frollogaston 5mo ago
I hate meetings when they're mismanaged, which is often. I like a good meeting. Probably what most swes would say.
yearesadpeople 5mo ago
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'.
vehemenz 5mo ago
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.
GrinningFool 5mo ago
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...]
keybored 5mo ago
Just look at what they write. There is a correlation between the Agentic Multitasker and the type of person who wanted results and didn’t care about the coding in itself. That’s what they themselves keep writing. 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.
NothingAboutAny 5mo ago
I've had seniors tell me my entire career that writing code was the easiest part of their jobs.
- dep_b 5mo ago
  True
- matwood 5mo ago
  I’m one of those, and it’s true. 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.
renegade-otter 5mo ago
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.
dahs617 5mo ago
I would say in general the amount of persons who pivot like that is low. 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.
tempaccount5050 5mo ago
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.
- aleph_minus_one 5mo ago
  > A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload. 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.
  - tempaccount5050 5mo ago
    And I totally respect that, I get it, I really do. But it's really obvious when people are being territorial and any contractor will tell you this happens every time. I suspect that a lot of the times, I'm hired to "teach them a lesson" in that "Hey, velocity sucks and I'm hearing a lot of whining, so if you don't like doing it, this guy will" and people snap into shape.
    - skydhash 5mo ago
      Unless the team are seriously bad developers, many times, it’s the manager fault. As a hired consultant, you often benefit many freedom that team is lacking. As someone that has been hired as a consultant, one of those are meetings and not having to worry about office politics.
tikhonj 5mo ago
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.
- nomel 5mo ago
  I require Jira for all my work to protect myself from three things, definitely not productivity: 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.
  - tomjakubowski 5mo ago
    This is a good way of using a ticket tracker: bottom-up, where engineers, testers, and other stakeholders are empowered to create and manage tickets as a means of communicating about their work and what they are blocked on. It's part of the writing culture mentioned in TFA. 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.
  - jimbokun 5mo ago
    Sounds like JIRA is a very important tool.
hirako2000 5mo ago
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.
- bcooke 5mo ago
  > No developer was ever unhappy to communicate 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.
  - hirako2000 5mo ago
    Some are inherently that way. Yes. Those don't thrive even within the engineer groups. Outliers don't make the rule. OP argues developers are hypocrites for demanding to be left alone when it suits them, or engaged when they feel they job is at stake. 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.
goda90 5mo ago
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.
vishnugupta 5mo ago
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.
figmert 5mo ago
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.
- ryandrake 5mo ago
  Yea, when you have multiple people doing anything, communication has to happen. It's not optional. As soon as your company hires developer #2, you need to communicate. As the team sizes get larger, 1:1 in-person conversations become less important and you need E-mail. As the team sizes get even larger and non-developer stakeholders become more numerous, meetings creep in. These things are not developer-torture devices. They are happening because your company decided that the product needs to be built by more than one person. 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.
watwut 5mo ago
Collaborative activities and process being important is NOT mutually exclusive with many meetings being useless, agile ceremonies time wasting uselessness and design review being used as a place to pontificate about crap. NONE of the activities you mentioned are activities that lead to what article talks about - well designed spec.
wanderer2323 5mo ago
Meanwhile people who bitch and moan about “other engineers” all the time haven’t changed at all. How refreshing.
peab 5mo ago
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
- albedoa 5mo ago
  "both these beliefs" and you label one a Belief and the other a Fact.
__MatrixMan__ 5mo ago
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.
jmilloy 5mo ago
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.
appplication 5mo ago
I think there’s some kernel of validity in this comment, but the unnecessarily aggressive tone loses it. This just comes off as bitter.
jayd16 5mo ago
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.
ChimpWithHat 5mo ago
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.
galbar 5mo ago
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".
- matwood 5mo ago
  > Understanding the problem at hand 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.
thisisit 5mo ago
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.
devin 5mo ago
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.
- pesus 5mo ago
  Are my standards too high to expect juniors to also be able to work with other parts of the business and ask for additional requirements if needed?
  - devin 5mo ago
    No. "Plays well with others" is part of being a functional member of any engineering team that I'm on.
freedomben 5mo ago
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".
tauwauwau 5mo ago
/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 https://news.ycombinator.com/item?id=48033534
zahlman 5mo ago
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.
locknitpicker 5mo ago
> I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary. 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.
gyanchawdhary 5mo ago
THIS COMMENT IS GOLD. 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
palmotea 5mo ago
I'm not going to comment on the likely "Goomba fallacy" at work in your comment, but I just want to note: > 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.
- bcooke 5mo ago
  > (because, you know, I was getting paid to write code and that's the only way I could actually get it done) 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.
  - palmotea 5mo ago
    >> (because, you know, I was getting paid to write code and that's the only way I could actually get it done) > 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.
syndacks 5mo ago
The archetype of the "jerk engineer" is over, because it turns out coding isn't all that valuable anymore. We now need "engineers" who understand much more than coding.
morelandjs 5mo ago
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.
Perz1val 5mo ago
What? Coding was escape from what that hypothetical engineer of yours disliked the most. Now there is less of it and ai hypers keep yapping about the job being no longer needed. Meanwhile it's just the fun part that was optimised out. Working hours stay the same, so it's more of the unfun activities. The job is worse, but we're told it's "solved". Bitching more makes sense, no?
empath75 5mo ago
I think probably both things can be true. That all of those things can be actively harmful when they distract the most productive coders from coding, and become more useful when time at a keyboard isn't really the constraint for producing code any more and coordination becomes a more serious problem.
JohnMakin 5mo ago
I have seen this play out too IRL and I am really enjoying the schadenfreude.
pdimitar 5mo ago
That's a straw man at the root of which sits a conflation of at least two types of meetings: (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?
drschwabe 5mo ago
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.
jolt42 5mo ago
Sometimes code is the bottleneck, other times it's not. Large company, not a bottleneck, fixing bugs or individual app developer, more so.
2ndorderthought 5mo ago
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.
ncruces 5mo ago
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?
deleted 5mo ago
[deleted]
AlienRobot 5mo ago
Textbook example of goomba fallacy.
aerhardt 5mo ago
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.
bsza 5mo ago
They were right back then because these tools didn't exist yet, and they're right today because they do now. What even is your point? Are you... mad because the truthiness of a statement can change over time?
fg137 5mo ago
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.
orochimaaru 5mo ago
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.
deleted 5mo ago
[deleted]
ares623 5mo ago
Then there's the other kind of engineer, who would rather see the world burn and their friends destitute than spend another second in an agile meeting.
threethirtytwo 5mo ago
Nah they're reaching for something they're good at. Same with you bro. 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).
chanux 5mo ago
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.
Cthulhu_ 5mo ago
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).
gniv 5mo ago
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.
miellaby 5mo ago
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.
bamboozled 5mo ago
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?
robtothetower 5mo ago
I mean, it's a natural reaction to the floodgates of quickly produced AI work. This article highlights that problem https://nooneshappy.com/article/appearing-productive-in-the-workplace/ https://nooneshappy.com/article/appearing-productive-in-the-...
RaftPeople 5mo ago
Both things can be true at the same time: 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

drfloyd51 5mo ago

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.

forgotaccount3 5mo ago

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

abduhl 5mo ago
Well it is hypocritical. Hypocrisy is an action or statement that is contrary to a stated value or principle. Just because your values or principles changed doesn’t make you a suddenly no longer a hypocrite, it just admits that your former opinions are no longer tenable. 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.
- roenxi 5mo ago
  Old value: Producing high value software. 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.
  - freejazz 5mo ago
    Sorry, did people not identify needs when developing "high value software" before? That doesn't seem true to me at all. I took a "Needs Assessment" course in my class of '09 undergrad...
  - abduhl 5mo ago
    This is shifting the principle/value discussion up to a level where it's meaningless. Let's use a different example. 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.
    - roenxi 5mo ago
      > 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. 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.

sillysaurusx 5mo ago

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.

onemoresoop 5mo ago
Code may be easy to write once you know what the code needs to do.

ftmootnomoat 5mo ago

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.

msteffen 5mo ago
Yes! So much of professional software development is about assisting the nominal job of management—planning and budgeting—rather than users or even business fundamentals. 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 https://news.ycombinator.com/item?id=47669749
- msteffen 5mo ago
  For that matter, here's a thread from a few days ago recommending the practice of scheduling status meetings for the purpose of pressuring the attendees to work on your project in addition to their other work: https://news.ycombinator.com/item?id=47906942 https://news.ycombinator.com/item?id=47906942 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!
- munk-a 5mo ago
  Just on a personal note as someone who worked in the game dev industry for far too long and is still suffering for it... if > 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.

sdevonoes 5mo ago

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

dmm 5mo ago

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 https://en.wikipedia.org/wiki/Group_attribution_error

knollimar 5mo ago
Or just goomba fallacy
- onemoresoop 5mo ago
  [flagged]
- sermah 5mo ago
  til https://en.wiktionary.org/wiki/Goomba_fallacy https://en.wiktionary.org/wiki/Goomba_fallacy
  - SV_BubbleTime 5mo ago
    That’s kind of just strawman with an origin story isn’t it?
    - _diyar 5mo ago
      No because the goomba is the average of two real opinions, and the strawman is a distortion/reduction of any opinion such that its easy to argue against.
      - SV_BubbleTime 5mo ago
        Ah, ok, so two real opinions made into a distortion. Right, I see how very dissimilar to an origin story of a strawman that is…

rafaelmn 5mo ago

Yes this exactly, it's getting ridiculous at this point. 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.

kenforthewin 5mo ago

Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?

frollogaston 5mo ago
This community hasn't agreed on either of those things, just like it never agreed on good coding practices. 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.
kusokurae 5mo ago
The community portion that unironically think AI is good enough now, are mostly managers and non/semi-technical people, and engineers who do not engage in critical or complex problems. HN has always been too much of the velocity-alignment-synergy class of professional talkers; it's just so much more obvious now that they feel emboldened in false confidence.
- vehemenz 5mo ago
  There's some of that, but more often it's developers whose arguments are a year behind the frontier models or, just as common, they're dramatically overstating their abilities. 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.
  - deleted 5mo ago
    [deleted]
  - deleted 5mo ago
    [deleted]
  - goatlover 5mo ago

kj4211cash 5mo ago

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.

Antibabelic 5mo ago
Isn't solving problems, instead of blindly implementing a high-level description of the solution, your job as a developer?
- bluGill 5mo ago
  There are problems you can solve, and problems that you cannot. Depending on the exact details GP may have been slacking for not solving problems, or correct in saying he can't do good work because he shouldn't be solving the problems alone.
- kj4211cash 5mo ago
  I don't understand this reply. Yes, I solve problems all the time. And that usually requires thinking deeply about the problem. And that deep thought is difficult when I'm getting constantly pinged about other stuff.
reachableceo 5mo ago
Um… how do you get those requirements if slack / email give you anxiety ? And meetings are disruptive ? 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?

dwoldrich 5mo ago

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.

AussieWog93 5mo ago

Comments like these are why I still come to HN. Absolute kino.

jmull 5mo ago

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

ElatedOwl 5mo ago

no, these meetings are still hot garbage. 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.

psychoslave 5mo ago

Welcome in humanity my friend. 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.

deleted 5mo ago

[deleted]

raincole 5mo ago

> 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!

moralestapia 5mo ago
But it is written there, and GP was quite specific: >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.
- robertlagrant 5mo ago
  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.
  - moralestapia 5mo ago
    Why does that matter?
    - deleted 5mo ago
      [deleted]
    - goatlover 5mo ago
      Because a claim was made about a group of people.
      - moralestapia 5mo ago
        Exactly. Does it matter if one member of that class does not follow the trend?

notnullorvoid 5mo ago

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.

bluGill 5mo ago

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)

AnimalMuppet 5mo ago

But the flow state wasn't just about typing code. The flow state was about understanding the problem, about loading it into your head so that you could "walk around in it" mentally, so that you could figure out that what really needed to happen was that module X needed to add a getter to value foo, that module Y needed to get foo and make a change based on the value, and that the key to making this all work was to add a way for Y to access X that fit within the existing architecture. That took focus, far more than implementing the pieces did.

Serhii-Set 5mo ago
[dead]

frollogaston 5mo ago

I hate meetings when they're mismanaged, which is often. I like a good meeting. Probably what most swes would say.

yearesadpeople 5mo ago

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

vehemenz 5mo ago

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.

GrinningFool 5mo ago

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

keybored 5mo ago

Just look at what they write. There is a correlation between the Agentic Multitasker and the type of person who wanted results and didn’t care about the coding in itself. That’s what they themselves keep writing. 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.

NothingAboutAny 5mo ago

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

dep_b 5mo ago
True
matwood 5mo ago
I’m one of those, and it’s true. 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.

renegade-otter 5mo ago

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.

dahs617 5mo ago

I would say in general the amount of persons who pivot like that is low. 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.

tempaccount5050 5mo ago

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.

aleph_minus_one 5mo ago
> A - they are replaceable and their work isn't that unique and B - they are the bottleneck, not the process or workload. 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.
- tempaccount5050 5mo ago
  And I totally respect that, I get it, I really do. But it's really obvious when people are being territorial and any contractor will tell you this happens every time. I suspect that a lot of the times, I'm hired to "teach them a lesson" in that "Hey, velocity sucks and I'm hearing a lot of whining, so if you don't like doing it, this guy will" and people snap into shape.
  - skydhash 5mo ago
    Unless the team are seriously bad developers, many times, it’s the manager fault. As a hired consultant, you often benefit many freedom that team is lacking. As someone that has been hired as a consultant, one of those are meetings and not having to worry about office politics.

tikhonj 5mo ago

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.

nomel 5mo ago
I require Jira for all my work to protect myself from three things, definitely not productivity: 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.
- tomjakubowski 5mo ago
  This is a good way of using a ticket tracker: bottom-up, where engineers, testers, and other stakeholders are empowered to create and manage tickets as a means of communicating about their work and what they are blocked on. It's part of the writing culture mentioned in TFA. 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.
- jimbokun 5mo ago
  Sounds like JIRA is a very important tool.

hirako2000 5mo ago

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.

bcooke 5mo ago
> No developer was ever unhappy to communicate 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.
- hirako2000 5mo ago
  Some are inherently that way. Yes. Those don't thrive even within the engineer groups. Outliers don't make the rule. OP argues developers are hypocrites for demanding to be left alone when it suits them, or engaged when they feel they job is at stake. 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.

goda90 5mo ago

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.

vishnugupta 5mo ago

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.

figmert 5mo ago

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.

ryandrake 5mo ago
Yea, when you have multiple people doing anything, communication has to happen. It's not optional. As soon as your company hires developer #2, you need to communicate. As the team sizes get larger, 1:1 in-person conversations become less important and you need E-mail. As the team sizes get even larger and non-developer stakeholders become more numerous, meetings creep in. These things are not developer-torture devices. They are happening because your company decided that the product needs to be built by more than one person. 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.

watwut 5mo ago

Collaborative activities and process being important is NOT mutually exclusive with many meetings being useless, agile ceremonies time wasting uselessness and design review being used as a place to pontificate about crap. NONE of the activities you mentioned are activities that lead to what article talks about - well designed spec.

wanderer2323 5mo ago

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

peab 5mo ago

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

albedoa 5mo ago
"both these beliefs" and you label one a Belief and the other a Fact.

__MatrixMan__ 5mo ago

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.

jmilloy 5mo ago

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.

appplication 5mo ago

I think there’s some kernel of validity in this comment, but the unnecessarily aggressive tone loses it. This just comes off as bitter.

jayd16 5mo ago

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.

ChimpWithHat 5mo ago

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.

galbar 5mo ago

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

matwood 5mo ago
> Understanding the problem at hand 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.

thisisit 5mo ago

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.

devin 5mo ago

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.

pesus 5mo ago
Are my standards too high to expect juniors to also be able to work with other parts of the business and ask for additional requirements if needed?
- devin 5mo ago
  No. "Plays well with others" is part of being a functional member of any engineering team that I'm on.

freedomben 5mo ago

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

tauwauwau 5mo ago

/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 https://news.ycombinator.com/item?id=48033534

zahlman 5mo ago

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.

locknitpicker 5mo ago

> I mean, they're not even wrong, but the nakedly hypocritical attitude of people who, until a year ago, were the most antisocial and least collaborative members of any team they were on is still extraordinary. 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.

gyanchawdhary 5mo ago

THIS COMMENT IS GOLD. 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

palmotea 5mo ago

I'm not going to comment on the likely "Goomba fallacy" at work in your comment, but I just want to note: > 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.

bcooke 5mo ago
> (because, you know, I was getting paid to write code and that's the only way I could actually get it done) 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.
- palmotea 5mo ago
  >> (because, you know, I was getting paid to write code and that's the only way I could actually get it done) > 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.

syndacks 5mo ago

The archetype of the "jerk engineer" is over, because it turns out coding isn't all that valuable anymore. We now need "engineers" who understand much more than coding.

morelandjs 5mo ago

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.

Perz1val 5mo ago

What? Coding was escape from what that hypothetical engineer of yours disliked the most. Now there is less of it and ai hypers keep yapping about the job being no longer needed. Meanwhile it's just the fun part that was optimised out. Working hours stay the same, so it's more of the unfun activities. The job is worse, but we're told it's "solved". Bitching more makes sense, no?

empath75 5mo ago

I think probably both things can be true. That all of those things can be actively harmful when they distract the most productive coders from coding, and become more useful when time at a keyboard isn't really the constraint for producing code any more and coordination becomes a more serious problem.

JohnMakin 5mo ago

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

pdimitar 5mo ago

That's a straw man at the root of which sits a conflation of at least two types of meetings: (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?

drschwabe 5mo ago

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.

jolt42 5mo ago

Sometimes code is the bottleneck, other times it's not. Large company, not a bottleneck, fixing bugs or individual app developer, more so.

2ndorderthought 5mo ago

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.

ncruces 5mo ago

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?

deleted 5mo ago

[deleted]

AlienRobot 5mo ago

Textbook example of goomba fallacy.

aerhardt 5mo ago

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.

bsza 5mo ago

They were right back then because these tools didn't exist yet, and they're right today because they do now. What even is your point? Are you... mad because the truthiness of a statement can change over time?

fg137 5mo ago

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.

orochimaaru 5mo ago

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.

deleted 5mo ago

[deleted]

ares623 5mo ago

Then there's the other kind of engineer, who would rather see the world burn and their friends destitute than spend another second in an agile meeting.

threethirtytwo 5mo ago

Nah they're reaching for something they're good at. Same with you bro. 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).

chanux 5mo ago

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.

Cthulhu_ 5mo ago

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

gniv 5mo ago

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.

miellaby 5mo ago

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.

bamboozled 5mo ago

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?

robtothetower 5mo ago

I mean, it's a natural reaction to the floodgates of quickly produced AI work. This article highlights that problem https://nooneshappy.com/article/appearing-productive-in-the-workplace/ https://nooneshappy.com/article/appearing-productive-in-the-...

RaftPeople 5mo ago

Both things can be true at the same time: 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