11 ms·

Why senior developers fail to communicate their expertise

• deleted 5mo ago
  [deleted]
• JohnMakin 5mo ago
  I don't necessarily disagree with this conclusion, but the way it is written has a lot of AI prose smell that was extremely distracting for me.
  • tmaly 5mo ago
    I didn't get the AI vibe from it. At some point we are just going to have to get use to most stuff being written to some degree by AI. There will be different shades of usage and maybe we draw a line somewhere in there.
    • ThrowawayR2 5mo ago
      The written word is how people interact with LLMs. Clarity and precision in writing results in more effective prompting of LLMs. It is just as possible that leaning heavily AI writing will be seen as a marker of not being natively skilled enough at writing to prompt LLMs effectively because of the GIGO principle.
    • yesitcan 5mo ago
      Let’s do the exact opposite of what this person is saying. Resist AI slop.
    • SpicyLemonZest 5mo ago
      There's no fundamental reason that I have to read random blogposts from people I don't know. I do it today because I find it to be an enjoyable way to learn more about my profession and explore various perspectives on it. If I stop finding it enjoyable because too many people write their posts with AI, I'll stop reading these kind of blogs altogether, in the same way that I (and I suspect many commenters here) do not read even the most lovingly crafted Linkedin posts.
    • jewel 5mo ago
      Also the consumption of AI-generated text could be having an influence on the tone of how people write. So even if AI was not used to write an article, it could "smell" like AI to someone who consumes less of it.
  • alwa 5mo ago
    I’m inclined to take the author at their word that they’re a copywriter by trade. I agree that the punchy staccato and the rhetorical questions smell AI-ish, but the way this person uses them, there’s, like, a payload each time. Versus LLM-speak, where the assertions are at best banal and more frequently just confusing.
    • srcreigh 5mo ago
      I've found myself using AI rhetorical styles. Mostly in PRs. The whole "not just X, Y" pattern hooked into my brain.
  • tolerance 5mo ago
    You have to be able to distinguish the scent of LLMs from the scent of Gary Halbert.
  • zzzeek 5mo ago
    im either the biggest idiot in the world or this person is a terrible "copywriter". I found this post to be nearly unintelligible: "You can’t explain away someone else’s problem using your own problems." WTF does that mean? this would be a good place to put some very simplistic examples of what they mean, but they dont. is that because theyre trying to be succinct? clearly not as the post rambles on and on anyway. I hate posts that are both 1. not explaining their concept and 2. super long winded. That's a problem are we just trying to say, "use AI for prototyping and customer demos that aren't important to be mature, use senior devs to develop and maintain the real products" ? You could just say that then...? Which I also disagree with as how AI should be used, AI is valid to include as a tool across all forms of development - it just should never be put in charge for production-level software (e.g. no vibe coding of mission critical components).
• lnenad 5mo ago
  As a /senior/ developer I really dislike blanket statements. I've seen the same amount of failures caused by > “Do we really need that?” > “What happens if we don’t do this?” > “Can we make do for now? Maybe come back to this later when it becomes more important?” as with experimenters. Every system is different, every product is different. If I were building firmware for a CT scanner, my approach towards trying out new things would be different than a CRUD SaaS with 100 clients in a field that could benefit from a fresh perspective. There are definitely ways to have eager/very open seniors drive systems into hard to get out corners. But then there are people that claim PHP5 is all you need.
  • hirako2000 5mo ago
    A sort of survivor bias. A VP ordered to use elastic search, because it worked well at his company before. Turned out it worked well for us. Listen to the VP to make technical decisions. And use elastic search.
    • giancarlostoro 5mo ago
      Reminds me when the ELK stack was called just ELK (idek what it is now) we had a server we put it on, and after making the additional dashboards my manager wanted, we learned the limits of ES / ELK. It needs a ridiculous amount of memory, because it will shove everything in memory. Same thing when I learned that MongoDB indexing puts every item in memory as well, which is a yikes, why would you not want to index? I bet there's money to be made for building a drop-in to either of those two that requires less memory, would save companies a bundle, and make other companies a bundle as well.
      • hilariously 5mo ago
        There's no high performance database that wont take all of your memory (at least for size of data) if you let it. That's because it's much, MUCH faster to do it that way, though if you can deal with certain type of latency trade offs for throughput something like turbopuffer can do wonders for your costs.
• deleted 5mo ago
  [deleted]
• don-code 5mo ago
  I agree with the author's premise - that one feedback loop optimizes for speed, and the other for scale - but I don't think the market is bearing the conclusion - that AI should be utilized to enable more rapid experimentation, where we better scale what works. Many vendors seem to be learning (or not learning, but just throwing their weight against it anyway) that adding hastily-generated AI features are causing customer dissatisfaction, as more people brand the features "slop". In the best case, the users give the company more chances. Infinitely more chances. In a worse case, the users assume the new feature will always be bad, given their first impression. It's hard for a vendor to make people reconsider a first impression. The absolute worst case is that AI enables a new market, but the first attempts are so poor that the first movers make people write that market off as a dead end, leading to a lost opportunity.
• hirako2000 5mo ago
  Most proof of concepts I've seen get traction turned into production. A rewrite? I recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened. The article touches on responsability, accountability. There is none for risk taker. By definition. You have a crazy idea, you rush it out, you hope clients bite. You profit. It's not even your problem how to make it work, scale, not cost more to run than we sell it for. The loop on the right. There are companies, two of them are very popular these days, they took it to an extreme. You ship something fast, and since it only scales linearly you go raise money. Successful companies, countless users, some of them even pay. Who's to blame? The senior developer, or simply someone reasonable who asks, how's that sustainable, what's the way out of this? Those are fired, so whoever's left is a believer.
  • ____tom____ 5mo ago
    > recall a few times everyone promised, if this gets promoted then we will rewrite it from zero. Never happened. Old quote: "There is nothing so permanents as a temporary hack."
    • entropicdrifter 5mo ago
      https://thecodelesscode.com/case/234 https://thecodelesscode.com/case/234
  • dasil003 5mo ago
    This is why you need sufficiently senior engineering leadership (both IC leadership and management). If you have engineers who meekly do whatever a non-technical stakeholder asks then you have a vacuum of responsibility, and sooner or later things will blow up catastrophically and whoever was least adept at CYA will get blamed. On the other hand, almost any business problem can be solved in a reasonable way that doesn't send your system through any terrible one-way doors if you zoom out enough and ask enough whys. Of course not every place allows engineering to do that, but the ones that don't aren't able to retain senior folks because they will just go somewhere where their judgment is valued. Sometimes technical debt is the right thing for the business, but sufficiently senior engineers can set things up so there is always a way out. But what you can't do is uphold the purity of the system above the business problem. The systems are paid for by the business, so if you lose sight of that then you've lost the plot and the basis for your influence.
• throwway120385 5mo ago
  A really competent senior figures out what the prevailing culture of the company is now, and what it will need to be in 5 years, and adapts as they go. Startups with 5 people maybe don't need extra complexity costing runway. A 500 person business may need that complexity because now there are second-order effects that need to be mitigated for every business decision. It's not a black-and-white "always avoid complexity" it's "add complexity when it makes sense" and even that question has a lot of nuance because sometimes the business just needs to survive for another couple of months.
  • hilariously 5mo ago
    Right, prioritization and transparency allow you to change the variables that people should be using to solve a problem (and if it doesn't they are not good at the job) - if you have two hours before a storm comes you will be asking "will it take on enough water that I cant bail it out?" instead of thinking about your architecture. The problem I see is management is playing games with not talking about how much money is available, what the real timelines are, etc - because they fear the people contributing will leave before the critical moment and so people keep making stupid decisions in that context and then you all get to get a new job.
• iJohnDoe 5mo ago
  FTA: “AI agents are the future of software development. We won’t need developers anymore to slow down the progress of a business.” Almost all business presidents, CEOs, and owners are thinking this. I guarantee you they are sick and tired of developers taking forever on every project. Now they can create the apps themselves. My comment isn't meant to debate every nitty-gritty detail about code quality, security, stability, thinking of every aspect of how the code works, does it scale, etc. All of those things are extremely important. However, most leadership never cared about any of that anyways. They only heard those as excuses why developers took so long. Over the last decade they put up with it begrudgingly. You know all the developers that wanted to complain about IT, cybersecurity, DevOPs, cloud architects for getting in their way and if they only had administrator access then they could get everything done themselves because they are experts in networking and everything else? Well, those developers are about to have the worst day ever when every single person on the planet can generate code and will be "experts" in everything as well.
  • mschuster91 5mo ago
    > Well, those developers are about to have the worst day ever when every single person on the planet can generate code and will be "experts" in everything as well. And society is beginning to suffer from it. AWS alone managed to slop itself into outages twice in a matter of a year [1] (and I bet that's just the stuff that escalates into mass-visible outages, not the "oh, can't start a new EC2 instance of a specific type for a few hours" kind), and a lot of companies were affected. It's always the same game: by the time the consequences of the beancounters' actions come home to roost, they have long since departed with nice bonus packages, leaving the rest to dig out the mess. [1] https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws https://www.theguardian.com/technology/2026/feb/20/amazon-cl...
  • bigfishrunning 5mo ago
    Now they *think* they can create the apps themselves. I say let every CEO and business administrator try; business will fail, everything will get shitty, and eventually somebody somewhere might learn something. Let 'em cook.
• mschuster91 5mo ago
  > Ah, well, it can’t yet do the one thing senior developers still do. Take responsibility. If only higher-ups would recognize that. Instead we see left and right mass layoffs, restructurings and clueless higher-ups who clearly drank not just a bottle of koolaid but a barrel. > The ‘Speed’ version allows the rest of the business to continue learning from the market, as the senior developers build a trailing version of the system that’s well-reviewed and understandable. Yeah... that doesn't fly. The beancounters don't care. The "speed" version works, so why even invest a single cent into the "scale" version? That's all potential profit that can be distributed to shareholders. And when it (inevitably) all crashes down, the higher ups all have long since cashed out, leaving the remaining shareholders as bagholders, the employees without employment and society to pick up the tab. Yet again.
• goosejuice 5mo ago
  > The avoider, the reducer, the recycler. As this kind of person, it can be alienating in some teams / companies. What I've found works best is to convey how the added complexity will affect non-engineers. You have to understand the incentives and trade offs though, and sometimes it's better to take the loss. If you have the fortune of sticking around with the same leaders for awhile, a few rounds of being vocal, but compromising, will work in your favor. When that complexity comes back around to bite them in the way you described, you will earn some trust. In my experience the solution proposed will rarely result in a less complex solution. Quick MVPs have the tendency to stick around. As soon as a customer starts using some product or feature, the cost of pivoting goes up. If you wish to experiment, do it on a segment.
  • bob1029 5mo ago
    The best strategy is to frame your argument from the perspective of the customer: > This will allow for us to deploy the feature in only X days supporting Y use case with Client W who has been complaining about this shit for Q months now. Arguments like: > We should do Z because it would provide future extensibility. > Z could eventually enable some novel platform capabilities. > Z is easier to unit test. Are much less likely to succeed in the business contexts that I have experienced so far.
    • goosejuice 5mo ago
      We may be looking at this differently based on our own experience fwiw. I also should have said added complexity or lack of (from poor planning). That can work too, e.g. when demonstrating the pain a customer will experience when something complex is poorly designed (like some b2b workflow), but it's less visceral than telling your internal stakeholders all the extra work they'll have to do if it's rushed. Even the best of your peers are a bit selfish. The business side has a lot of incentives around quick turnarounds so it's easy to overlook the downside. Imagine such a scenario. You're in healthcare and working on a feature that will add new data model for some kind of clinical information. You could say: > This will allow for us to deploy the feature in only X days supporting Y use case with Client W who has been complaining about this shit for Q months now. Yeah that very well may prevent W from churning, though hopefully you think about how it will affect other clients too. Or, you could say "If we get this data model wrong, and the value set is ambiguous, you (product/sales/cs) will have to reach out to every single customer and clarify what they meant by x/y/z if we wish to migrate it with any degree of accuracy in the future." That's drawn from experience but I'm sure there are a lot of parallels to that in other industries for any kind of data. Migrating data is a pain in the ass for everyone, but often it can be the people pushing for a quick solution that suffer the most when that goes wrong. This kind is stuff is why commission structures should consider churn / residuals. Bad incentives make for hastily made decisions.
• deleted 5mo ago
  [deleted]
• hosh 5mo ago
  Complexity, if it can be reduced to a single measurable dimension, is only one of several factors in a solution space. There are other properties such as, maintainability, scalability, reliability, resilience, anti-fragility, extensibility, versatility, durability, composability. Not all apply. Being able to talk about tradeoffs in terms of solution spaces, not just along a single dimension, is one of what I consider the differentiator between a senior and staff+ developer.
  • lwhi 5mo ago
    Many of these factors are directly influenced by complexity.
    • hosh 5mo ago
      They all influence each other to one extent or another. And, the Cynefine Framework defines “complexity” a bit differently than the intuitive way it’s often used. The simple domain is a single dimension. The complicated domain is a system of factors. I think when most people say “complex”, they are really talking about what Cynefine labels as “complicated”. The Cynefine complex domain is not so easily solved or reduced. It has emergent behaviors. The act of measuring tends to perturb the system. No single solution will ever solve something in the Cynefine complex domain, because the complex system will shift behavior, making solutions that worked before start working against it. Examples are ecosystems and economies. Software systems tend not to be complicated, not complex, until you start getting into distributed systems. One of the key insights of Cynefine is understanding that each of the domains has its own way of solving things and that often times, people use solutions and methods from one domain to solve problems characterized by a different domain. You don’t solve problems in the complicated domain with methods from the simple domain. And you don’t solve problems in the complex domain with methods that work for complicated domains.
      • chrisweekly 5mo ago
        Interesting and salient comment. But > "Software systems tend not to be complicated, not complex, until you start getting into distributed systems." these days so much software is "distributed systems".
• deleted 5mo ago
  [deleted]
• BiraIgnacio 5mo ago
  One could say in order to be a senior developer in any area, more-than-good- communication skills are required.
  • nathanielks 5mo ago
    Unfortunately that's not the case. There are many senior and above level engineers out there who are unskilled communicators but very technically skilled.
    • lwhi 5mo ago
      In which case maybe they're best suited to not leading a team.
      • nathanielks 5mo ago
        100%! Just pointing out how the reality of things doesn't match our desires.
• ____tom____ 5mo ago
  I feel this is about as accurate and relevant as if I were to write an article on senior copywriters.
• roughly 5mo ago
  This is well-put, but the problem comes when you’ve got leadership looking at what appears to be a fully-functioning version of the product that the market is clearly indicating to them is sufficient to drive revenue. Budgeting the 6 weeks or whatever to translate from “the working version” to “the trustworthy version” is a hard pitch. This is why part of a senior developer’s job is designing and developing the fast version in a way that, if it goes into production, won’t burn the building down. This is the subtle art of development: recognizing where the line is for “good enough” to ship fast without jeopardizing the long-term health of the company. This is also the part that AI is absolutely atrocious at - vibe code is fast, that’s the pitch, but it’s also basically disposable (or it’s not fast - I see all you “exhaustive spec/comprehensive tests/continuous iteration” types, and I see your timelines, too). If you can convince the org that’s the tradeoff, great, but I had a hell of a time doing it back when code was moving at human speed, and now you just strapped rockets onto the shitty part of the system and are trying to convince leadership that rocket-speed is too fast.
• mgaunard 5mo ago
  Even with AI, there is a clear difference between juniors and seniors. None of the things I can think of have anything to do with avoiding problems. To some degree, having 5+ agents working on different projects is similar to leading a team of 5+ people. The skills translate well. The senior is also able to understand what the agents do, review and challenge it. Juniors often can't. And finally, the senior has a deeper understanding of what the business and problem domain are, and can therefore guide the AI more effectively towards building the right thing.
  • hun3 5mo ago
    Avoiding problems outside your business problem domain, and can therefore guide the AI more effectively towards building the right thing.
    • mgaunard 5mo ago
      Making things fit for purpose is not avoiding problems in my book. If anything, quite often it's introducing more problems, because we know we'll run into them and they need to be addressed. AI is sometimes quite lazy and refuses to solve the hard problems (sometimes making funny excuses like it would take weeks) until you make it explicit that it's important they are dealt with.
• nikhilpareek13 5mo ago
  [flagged]
• varispeed 5mo ago
  [dead]
• rvz 5mo ago
  The unspoken observation on the reason why this happens is it almost always political in the organization to make themselves more valuable and harder to fire / layoff. That includes gate-keeping behaviour such as not handing off knowledge, sham performance reviews to prevent ambitious juniors from over-taking them (even with AI) and being over-critical to others but absent and contrarian when the same is done to them. That leverage does not work anymore in the age of AI as having "expensive" seniors begging for a pay-rise can cost the company an extra amount of $$$. So it is temping to lay them off for another one that is a yes person that will accept less. In the age of AI, I would now expect such experience to include both building and working at a startup instead of being difficult to work with for the sake of a performance review.
• dcchambers 5mo ago
  In 2026 the answer is "job security"
• CobrastanJorji 5mo ago
  > I don't like the kind of senior developer that says "I found this new tool and it’s pretty cool ..." Remember that the first half of this statement, the part listed here, is great. I love playing with new tools. The only bad part is the implicit bit after the dots: "we should use this in our product." You don't want cool things anywhere near your product, unless the cool thing is that they remove complexity.
• nullorempty 5mo ago
  What I found is that my willingness to communicate and share my expertise is usually not in demand with more junior developers. In general, I find developers uninterested in finding a mentor. They don't look at your linked in profile, they don't look at you as a possible source of knowledge and expertise. So it's not like I have nothing to share after 30 years of experience in the industry, I just have nobody to share it with.
  • gib444 5mo ago
    Exactly my experience. You describe it more diplomatically than I do hah. To me, young people just don't seem to know, or want to know, that information and knowledge can be gained from a person. It's the arrogance of youth x100 They have a supercomputer in their pocket/on their desk, and an AI that knows 'everything'. I can't imagine what it's like being a teacher right now. How's your AI going to explain the office politics? The CTO's opinion on things? Talk about recent outages and learnings (details of which are not often on blogs)? They think all they need is knowledge and facts and none of history, politics, communication etc I think a lot of is that an AI or Google search won't challenge them, push them, disagree with them - and that's comforting to them, and more desirable than the learning that could happen
    • asdfman123 5mo ago
      I like to play an online strategy game, openfront.io. The way to win is to take out someone who is gaining power before they get too powerful. It's just basic game theory, and you see it everywhere. However, it's so annoying in the workplace when your two options seem to come down to try to dominate or be dominated. Especially if you care about quality code and don't care for meetings. As far as I'm concerned, I think I have to make peace with the fact that if I don't play the game, I am going to be managed by people who don't know what they're doing. But neither option seems particularly good. Should I try to bury my ego and influence from below? Should I work harder and try to climb the corporate ladder? I'm still not sure.
      • judahmeek 5mo ago
• t43562 5mo ago
  I found that the proposers of features "want everything" because they don't know what is critical - they're therefore totally unwilling to accept anything other than "the full monty". So as a senior developer you cannot propose any faster route. As you might imagine, a lot of these ideas fell by the wayside but we had to develop them in full.
  • xyzelement 5mo ago
    The article covers that under the imperative of discovery. Learn what works quickly because you may not know what the core part is otherwise. There's ways to navigate it.
  • panny 5mo ago
    It's the XY problem. The customers tell sales they want Y, rather than stating their problem X which they think Y will solve. Sales runs breathlessly to the dev team and demands we implement Y. Now scale this up to 10 customers or 100 customers. They all have the same X but come up with independent Ys. You see the problem immediately. Sales/marketing didn't do their job sussing out what X is and wastes dev time with Ys. And worst of all, write once, support forever. Each one off Y has to be maintained for the special snowflake customer that uses it. None of the Ys actually work well for all the customers with problem X so you end up drowning in "technical debt" spent to create them all. If your marketing department leads the company, I've discovered the best option is to just quit. Go find a job at an engineering company.
    • j_w 5mo ago
      This is why the first thing you should do as a dev when somebody tells you that they want Y feature is to ask why. Non-developers have no clue WHAT they want, then know WHY they want it. The why is much more important to know, because the requestor has no clue how software works and imagines bad solutions.
      • t43562 5mo ago
        In some cases it's just because they think that any "missing thing" might be the one that causes customers to reject the offering. So they "must" have everything. It's the lack of knowledge that's the problem and they don't feel that they're going to get more than one chance/feedback cycle to learn from. The product managers proposing things have their reputation tied up in them so a major feature is a chance at fame for them. It's as if everyone gets "a turn" at using the development department once in a while and they want to make the utmost of it, knowing that the instant their feature is "finished" the spotlight will be gone from them for months.
• jinkuan 5mo ago
  The polarization of speed vs scale concern on team is interesting. Maps to what we believe on our team - functional vs non-functional. AI ships functional features fast but developers are more important than ever in making sure the non-functional aspects are taken care of
• nyeah 5mo ago
  This is copy. I'm only interested in content.
  • xyzelement 5mo ago
    What does this mean?
    • nyeah 5mo ago
      The article explains what copy is. It's advertising writing, manipulation rather than factual communication.
• Bmello11 5mo ago
  [flagged]
• augment_me 5mo ago
  I think that if this becomes an actual problem, there will be such a massive incentive to add AI to the scale/compression/risk avoidance side that there will be automated tools specialized in that kind of work. I feel like this is shooting from the hip from a single point of view from some semi-large corpo.
• someone654 5mo ago
  > Your thoughts, senior software developer? The senior should also start using AI to increase the amount of work done to stabilise the system, in a careful manner. More benchmarks, better testing, better safety net when delivering software, automated security reviews, better instrumentation, and so on. > And this is how AI affects the two loops There should be another image illustrating that the amount of mitigations done from senior side, red-/blue-team style.
• hamstergene 5mo ago
  Because the most important parts of the expertise are coming from their internal "world model" and are inseparable from it. An average unaware person believes that anything can be put in words and once the words are said, they mean to reader what the sayer meant, and the only difficulty could come from not knowing the words or mistaking ambiguities. The request to take a dev and "communicate" their expertise to another is based on this belief. And because this belief is wrong, the attempt to communicate expertise never fully succeeds. Factual knowledge can be transferred via words well, that's why there is always at least partial success at communicating expertise. But solidified interconnected world model of what all your knowledge adds up to, cannot. AI can blow you out of the water at knowing more facts, but it doesn't yet utilize it in a way that allows surprisingly often having surprisingly correct insights into what more knowledge probably is. That mysterious ability to be right more often is coming out of "world model", that is what "expertise" is. That part cannot be communicated, one can only help others acquire the same expertise. Communicating expertise is a hint where to go and what to learn, the reader still needs to put effort to internalize it and they need to have the right project that provides the opportunity to learn what needs to be learnt. It is not an act of transfer.
  • zsoltkacsandi 5mo ago
    That’s very well put.
  • whattheheckheck 5mo ago
    Well here's an engineering problem figure out how to mentor 10x the number of juniors
    • necovek 5mo ago
      Mentor 3 who need to mentor/"pair with" 3 each? ;-)
    • the_snooze 5mo ago
      You don't. You accept that social bandwidth is a real-world constraint that you work with, not magic away. That's real engineering.
• chrisweekly 5mo ago
  I may be missing something, but the "left" and "right" loops strike me as slightly different words for the same exact thing. The company provides (offer | service) to the (market | user) and receives (feedback | payment). The service IS the offer, the userbase IS the market, and payment IS the feedback signal. Right? EDIT - expanded on original comment to add: The author's point might be lost on me but seems to be that framing things with one of those sets of labels vs the other may correspond to use of "complexity" vs "uncertainty" as the element targeted for reduction, and choosing those labels carefully in turn correlates to "senior" devs' persuasiveness in prioritization battles with product owners. To which my response would be, "maybe?". (shrug) I'm not a copywriter by trade but I care about words and may have just been nerd-sniped.
  • DougWebb 5mo ago
    The company is providing existing services to existing users for payment. The company is offering potential new services to current and potential users in the market and getting feedback on how valuable those new services might be.
• pragma_x 5mo ago
  Interesting article. I appreciate the range of perspectives here, and the overall pitch to keep the most experienced in frame along side new-fangled advancements (AI). The "speed" loop reminds me a lot of RAD. In fact, AI might be _the_ thing that helps us deliver on RAD's promises from decades ago. https://www.geeksforgeeks.org/software-engineering/software-engineering-rapid-application-development-model-rad/ https://www.geeksforgeeks.org/software-engineering/software-...
• donatj 5mo ago
  Speed… speed… velocity… speed. All I hear about these days. Every meeting. Honest question does high velocity / first mover ever really pay off these days? I don't feel like having the first AI slop to the market has actually paid off for anyone? Am I wrong? Am I missing something? Am I out of touch? The way I see it, first movers do a lot of work proving the idea works, and everyone else swoops in with better product or at least at a cheaper rate. Beyond that, let's take the company I work for, for example. We have an ingrained and actually relatively happy customer base on a subscription model. I feel like the only thing increased velocity can do is rapidly ruin their experience.
• einpoklum 5mo ago
  Irrespective of the linked post, let me say why I (being sort-of-a senior developer) fail to communicate my expertise. In no particular order: 1. I am discouraged or forbidden from devoting time to communicating my expertise; they would rather use it. Well, often, they'd rather I did the grunt work to facilitate the use of my expertise. 2. Same, but devoting time to preparing materials which communicate my expertise. 3. A lot of my expertise is a bunch of hunches and intuitions, a "sense of smell" for things. And that's difficult to communicate. 4. My junior colleagues don't get time off their other duties to listen to "expertise sharing", when it does not immediately promote the project they're working on. 5. Many of my junior colleagues lack enough fundamentals (IMNSHO) for me to share all sorts of expertise with them. That is, to share B with them I would need to first teach them A, and knowing A is not much of an expertise; but they're inexperienced, maybe fresh out of university. 6. My expertise may only be partially or very-partially relevant to many of my colleagues; but I can't just divide the expertise up. 7. For good reasons or bad, I have trouble separating my expertise from various ethical/world-view principles, which fundamentally disagree with the way things are done where I'm at. So, such sharing is to some extent a subversive diatribe against the status quo. 8. My expertise on some matters is very partial - and what I know just underlines for me how much I _don't_ know. So, I am apprehensive to talk about what I feel I actually don't know enough about - which may just result in my appearing presumptuous and not knowledgeable enough. 9. My expertise on some matters is very partial - and what I know just underlines for me how much I _don't_ know. So, I try to polish and complete my expertise before sharing it - and that's a path you can walk endlessly, never reaching a point where you feel ready to share. 10. Tried sharing some expertise in the past, few people attended the session, I got demotivated. 11. Tried sharing some expertise in the past, few people were engaged enough to follow what I was saying, I got demotivated. 12. Shared some expertise in the past, got a positive feedback, but then those people who seemed to appreciate what I said did not implement/apply any of it, even though they could have and really should have.
• a_c 5mo ago
  You can't force people to feel what you feel. One can (pr|t)each, without experiencing, other can only mimic or rebel. That's how cult is formed.
• dyauspitr 5mo ago
  Probably because unlike apprenticeships a senior developer isn’t an owner. This creates a situation where imparting knowledge means you have less time to do your own packed work stack.
• panny 5mo ago
  I can/have done this without AI and it tends to be disasterous. Management declares we need X fast. Okay, we can build that really fast, but it won't scale. Management says fine, just build it. We do. Management now wants to build Y fast. But wait, what about X? Nevermind, just build Y now. Okay, we're building Y, and X collapses... because it wasn't built to scale. Now we're being called in at 2 am to fix X while also expected to ship Y tomorrow. Sure, they'll glow you up and tell everyone what a hero you were for coming to the rescue at 2 am, but on that six month performance review, the blowup is used as reason to withhold raises and promotions. They don't lose any sleep of course, just you, the developer.
• danhorner 5mo ago
  I tripped over the double-entendre of the teaser quote and then found it ironic that the author is a copy writer. >> “AI agents are the future of software development. We won’t need developers anymore to slow down the progress of a business.” > And so, to me, a copywriter, what’s happening here is that the same message is meaning two different things to two different audiences. I couldn't tell whether to parse this as "We will be faster without those slow developers", or more cynically as "We don't need developers to slow us down; We can now be slow with ai agents". I suspect that with creeping complexity the latter reading will hold up better for large projects.
• deleted 5mo ago
  [deleted]
• greenchair 5mo ago
  Wow I'm only done with part one and the author pegged me to a t.
• alecco 5mo ago
  This is engagement bait. I almost fell for it.
  • xyzelement 5mo ago
    What does that mean? The article expressed something that seems to be really true and I hadn't heard expressed this clearly.
• tracker1 5mo ago
  I do a bit of both... I pay attention to new tools, libraries and languages. But will rarely recommend them initially. That said, I also tend to fight complexity to an extreme degree KISS/YAGNI are my top enterprise development keystones.
• deleted 5mo ago
  [deleted]
• austin-cheney 5mo ago
  Its all relative. There is no baseline for expertise in software. So, instead its whatever self-serving quality some sociopath on the other end favors.
• wewewedxfgdf 5mo ago
  >> “AI agents are the future of software development. We won’t need developers anymore to slow down the progress of a business.” No-one says this.
  • deadbabe 5mo ago
    They say it quietly whenever there is a workforce reduction.
• xyzelement 5mo ago
  Just wanted to say this writeup made tangible a real thing - a truly clarifying way to think about it.
• jrumbut 5mo ago
  I think it's possible that this idea would work as a communication/branding strategy for senior developers, though I don't think it's strictly true. I am really skeptical of arguments based around "I can do things the model can't" because that space of things is not very large and is getting smaller every day. The opportunity to not merely cling on to what we have another year but to grow is to say "together, the model can manage so much more complexity than before that we can do things that were not previously possible." We haven't identified too many of those things yet, but I am certain they are coming.
• nitwit005 5mo ago
  This misses the basic problem of incentives. What "the company" wants doesn't matter, it's what the people making particular decisions want. There exist people who's jobs depend entirely on rolling out new features, or apps of some sort, and having them show up in some form of company metric. If the senior developers says it's a bad idea, those people won't listen, or won't care. Their job is on the line.
  • sublimefire 5mo ago
    A typical example would be the researchers which are evaluated based on papers and new stuff they put out into the wide blue world. But if you are on a product side this makes little sense because you need to match “features” to the requirements expressed by the customers and you will tell researchers to stop pushing.
• piterrro 5mo ago
  this almost reads as a rephrased version of: https://grugbrain.dev/ https://grugbrain.dev/
• block_dagger 5mo ago
  It seems to me that the author fails to extrapolate on the effects of recursive self improvement. The only things preventing 95% engineer obsolescence will be compute/energy constraints and the speed of adoption, which can take years for large infrastructure companies. But it's coming.
  • halfcat 5mo ago
    Cuts both ways. If supply chain attacks continue recursive self improvement, everyone’s going to be working in air-gapped facilities. Departments also need to be air-gapped from one another. And each team air-gapped. And so on. There’s a speed limit, because the faster you go the less room for error you have. It’s the same as being heavily leveraged with debt. If you have a cash investment and it drops by 50% you can just wait. If you’re leveraged 100-to-1, a 1% drop forced liquidation and wipes you out.
• wagwang 5mo ago
  Depends on the product, but in many cases you cant actually decouple the complexity because the complexity is the product. There are times where the archaic flow needs to work for some stupid compliance reason.
• deleted 5mo ago
  [deleted]
• hmokiguess 5mo ago
  apex predator of grug is complexity complexity bad say again: complexity very bad you say now: complexity very, very bad
• orisho 5mo ago
  Shouldn't a senior developer strive to eliminate complexity while increasing velocity? The two do not contradict. Reducing complexity can increase velocity.
• drbojingle 5mo ago
  They fail to communicate in the same way we fail to download a copy of "the truths of the world as we know it" into every child's brain. It's easily to say " look both ways when you cross the road" but speech is so one dimensional. It's a slow tape reel and that's just the encoding.
• deleted 5mo ago
  [deleted]
• overgard 5mo ago
  Hits home for me; although a lot of times adding complexity is not about your opinion as a senior developer but rather what the business wants. I've definitely worked jobs where I helped create microservice kubernetes nightmares, and while this was partially my fault for wanting to play with shiny things, a lot of this was just "this is what the business wants and you have the expertise to do it", and I'd kinda shrug and go OK. I worked one job (small business) where an executive once leveled with me that the reason they wanted the complexity is because it looked good to investors, not because it was an actual need. FWIW though the idea about a "speed" product and a "stability" product isn't new. We used to call it "prototyping". I don't know when/how that disappeared from the collective consciousness. "have a space where we can build things fast with horrible practices" isn't some AI era innovation, it's what smart companies have done for decades.
• devhouse 5mo ago
  Good read. The big elephant in the room though: you likely won't purely hand-code the Stable version for much longer. So where's that split? Prototype vs. Prod? Feature Flags? Canary? 2 codebase nightmare? All of this already exists. The message that hits for me is that of AI being a destabilizer while simultaneously being an accelerator. The Speed/Scale suggestion won't address this. A codebase no one understands, growing at machine speed won't go away just because you drew a box around it. The fix is likely more mundane stuff like process and role shifts, smaller PRs, tests, tooling, ownership principles.
• aussieguy1234 5mo ago
  As a senior developer, I achieved last night what I thought was impossible with all the anti-bot (including bot detection) tech that gatekeeps much of the internet. An AI agent using a web browser like a human. I used various stealth technologies to achieve this. I set it off on a research task for me and it saved me $30 of a purchase by finding the best price. Its Jeff Bezos worst nightmare, visting amazon.com and ignoring all the product placement ads. It had multiple tabs open, did searches in multiple places, opening products and checking sites....it looked just like a human would do doing the same task. This I can assure you would not have been possible without my expertise. I had to be very careful to remove all bot signals from the browser, including going to browserscan.net to check. Once done, most captchas were never shown to the agent. There is a NodeJS codebase involved that I wrote by hand. I searched through the code of the browser automation framework I was using, looking for ways to make it look more human. I had AI help with this part, but had to confirm everything and pull the agent up when it suggested bad ideas. Most of the work was architectural, including making sure my browser was easy for the agent to use. I'm going to add 2captcha as a next step, to solve the few captchas that it still encounters (as I still do sometimes as a human). I'm thinking of open sourcing it, but i'm not sure if its a good idea as if it became widespread, it might encourage the adoption of even more invasive anti-bot measures.
• CharlieDigital 5mo ago
  It's funny, I've been literally trying to convey these exact sentiments to my team over the last few days down to the: > Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it? Pretty much word for word. It feels like engineers are collectively feeling the pain now that product has decided that engagement of mental faculties is no longer necessary on their behalf; just build it and figure out the user persona and utility later...if ever. What used to be a process of taking the time to understand the domain, the user, and how the product fits into some process has been tossed out the window; just ship whatever we think some imaginary user wants and experiment until we succeed. It creates the exact problem that OP talks about: every random feature that gets vibe-coded becomes a source of instability and risk; something that can then only be maintained via more vibe coding because no one has a working mental model of the thing.
  • deleted 5mo ago
    [deleted]
• deleted 5mo ago
  [deleted]
• lenerdenator 5mo ago
  I'm a "senior" developer. Want me to communicate my expertise? Give me some time to actually do it.
• abhisek 5mo ago
  I partly agree. Agents are not going to replace senior devs. Exactly for the internal context and the decision making that comes with it. But senior devs are also expected to have a compounding effect even pre-AI. Writing a single doc, refactoring legacy code to make it extensible, building security frameworks specific to the project and many more. All of these would compound the dev team. I think the same will happen with agents working on a org specific paved path set by senior devs.
  • himata4113 5mo ago
    They will (and already have) replace low-performing senior developers because a single high-performance senior developer can do a lot more than they used to. I have personally noticed this a lot how multiple people can work on the same problem, but the more senior developers get way more miledge out of AI compared to those that are early in their carreers. Another difference I've noticed is how many agents one can keep running without losing awareness. It generally just raised the bar on what management will expect from developers which will result in a shrinking workforce. The only ones that will benefit are AI companies and the upper management since less employees means less management so lower management will get screwed too.
    • simplyluke 5mo ago
      > will result in a shrinking workforce Jevons paradox is already rearing its head, I've seen data suggesting open roles in tech are at their highest since the post-pandemic slump [1]. If you're a senior leader at a company and your engineers are now capable of multiple-times more productivity, is the logical choice to fire half, or set way more ambitious goals? One assumes engineers are hired because their outputs are worth more than their cost. If outputs, at least for those capable of wielding new tools, are higher, so is the value of that employee to you. The universal thing I'm hearing from friends at small-mid-size tech companies, and experiencing myself, is that there is way more work and demand for it from senior leaders than they're capable of with their current teams. 1: https://www.ciodive.com/news/tech-job-postings-hit-3-year-high-april/819778/ https://www.ciodive.com/news/tech-job-postings-hit-3-year-hi...
• dirtbag__dad 5mo ago
  > I don’t like senior developers who like trying new technology. I like ones that avoid more complexity. I guess the author has never worked on a dog shit system with no tests at all and constant downtime. I have worked with “complexity averse” engineers who would rather fix the edges over and over again, than roll up their sleeves and just get the job done. I just don’t believe that using new tools is at odds with avoiding complexity. Sometimes you have to take it to the chin, and get to use the new shiny thing along the way to move much faster.
  • throwaway74628 5mo ago
    Any can can be kicked down the road in the name of pragmatism, sure, but IME the kind of tech debt you’re describing often comes about from lack of fear and respect for complexity and the damage it can do. Before you can reduce complexity, you must first manage it by breaking the problem into smaller parts through categories, boundaries, and contracts; so many software engineering best practices concern this aspect. That is to say, the rolling up of sleeves usually involves first adding tests for existing behavior and then doing more-or-less what’s described. The tools involved are aside to this; “catch as catch can”
• kevdoran 5mo ago
  I feel like I was totally on board until the conclusion about one fast system and one stable one. It's not really possible in practice, once a customer starts paying for something, even a vibe coded app by a sales person, it's now a stable system. The thing breaks, the salesperson says "can you check this out?" then disappears and we're back to where we started. I don't even find this very new: many companies I've been at have tried to spin-off a "fast" team to sell stuff.
• romaniv 5mo ago
  >We could call this the ‘Speed’ version of the system. It’s not meant to be understandable, the goal is getting things good enough to take it to the market for feedback. AI is actually quite awful for prototyping, because it makes it far too easy to add random crap to your "prototype" without any specific intention. This quickly transforms the prototyping process from something that's high-level and geared towards building the mental model of the real system into something akin to copy-editing a random piece of software without any coherent mental model involved. Moreover, prompting allows to to glaze over some essential complexity of the task without getting any notions of the scope of the effort of actually doing it. In other words, people end up failing to make necessary decisions and simultaneously get bogged down with unnecessary ones. In short, fast feedback loops are only useful if there is actual feedback involved.
• hona_mind 5mo ago
  [flagged]
• invalidSyntax 5mo ago
  It sounds like a perfect idea on paper until you notice that junior devs will not be able to learn about stable code. Unless AI get's good enough to write stable code, or good enough that no human has to look in the code, the next generation will face a bigger problem than now. Well it's AI that started it so let's make AI take responsibility... Oh they can't. Now what?
• doxeddaily 5mo ago
  I actually think the article makes some pretty interesting points. It's not about the name of it though.
• davebren 5mo ago
  The loop on getting slop out to market quick in order to get feedback is already flawed. If you don't understand the problems of your customers well enough to come up with a coherent vision for how to solve them you shouldn't be the one doing the product design or making high level business decisions in the first place. There's a place for prototyping and experimental features but now agile has cultivated extreme learned helplessness and everything is an A/B test because there's no longer any ability to judge whether something is good or bad based on a holistic vision.
• robin64 5mo ago
  I enjoyed reading this, and I agree with the underlying message: communicating better with our audience. I think the framing started in the right path and then took a slightly wrong turn. Both loops presented benefit from being tighter, faster. One to take a system to a “stable” (maintainable) setpoint quickly. The other to handle uncertainty. And the additional insight about splitting the systems to better adapt to AI… we’ve described spikes for years, well before AI went mainstream
• robin64 5mo ago
  I enjoyed reading this, and I agree with the underlying message: communicating better with our audience. I think the framing started in the right path and then took a slightly wrong turn. Both loops presented benefit from being tighter, faster. One to take a system to a “stable” (maintainable) setpoint quickly. The other to handle uncertainty. And the additional insight about splitting the systems to better adapt to AI… we’ve described spikes for years, well before AI went mainstream.
• psychoslave 5mo ago
  Interestingly the article put complexity management vs uncertainty reduction. But reduction is narrower than management which is narrower than organization. Also uncertainty is part of complexity. Being able to isolate what is deemed predictable under clearly identified premises is the best that can hoped on that matter. It means that then one strategy can be applied to protect the stable core, and other strategy can be tried on what is unknown (known and unknown unknowns).
• wills_forward 5mo ago
  There's a lot of opportunity in being the manager who can still see it
• heisenbit 5mo ago
  While I agree with adding code contributing to complexity is problematic there is lots of code in existing code basis which is overly complex due to past outdated requirements or less than perfect human coders. The current flood of AI driven security fixes demonstrates that AI can be pretty good in detecting security edge cases. It is not inconceivable to use it to also reduce code complexity.
• dotancohen 5mo ago
  I stopped communicating my experience-derived lessons when I discovered that 1. it cheapened the perception of "my genius", and 2. nobody wants to hear it anyway. From non-tech workers for whom I'd write a bat or bash script for, to engineers for whom I'd debug a complex race condition - they all just want the answer and care nothing about how I got it. Fine, then, I'll keep the experience to myself.
• sfink 5mo ago
  The safest answer a sales person can give is "yes". The safest answer an engineer can give is "no".
• p0w3n3d 5mo ago
  “I found this new tool and it’s pretty cool ...” yup “This company <company totally unlike the one we’re in> does things this way, so …” agreed “Here, look at this HackerNews post that says this is best practice, we should probably …” sir/m'lady, we're at war from now on. This is the only reason I come here. Of course I don't take everything carelessly, but the amount of experts on this forum is damn high and this is the only forum in the last 10 years that helped me grow so much
  • npodbielski 5mo ago
    At war with whom? About what?
    • p0w3n3d 5mo ago
      at a FLAME WAR with the author of course. normal, classic flame war. I try to defend that HackerNews is a great source of good practices. This is merely the same as what the author thinks, but he/she says it requires more insight. So we fight and then, later, we realise that we've always had the same views on that but it's to late. Peace is no longer an option. flame war.
• est 5mo ago
  > Senior developers care a lot about stability I saw this yesterday https://trinkle23897.github.io/learning-beyond-gradients/ https://trinkle23897.github.io/learning-beyond-gradients/ They are very remotely related yet somehow very close.
• asn_tech_2019 5mo ago
  [flagged]
• aa-jv 5mo ago
  Here's a mental exercise - do you immediately think you know what this command does? PING Junior developer: PING is used to check if a host is reachable by a network Middle developer: PING constructs and sends ICMP packets to an address Senior developer: what machine, what OS? Junior manager: Don't care, ask a techie if you need to do something technical Middle manager: Ask <techies name> about it, I know he has great experience with it Senior manager: PING is used to check if a host is reachable by a network Senior developers fail to communicate their expertise, because that expertise is developed and formed by asking more questions than answers, and managers fail to understand the capabilities of "their techies", because managers see question-asking techies as counter-productive, and attempt to route around them. Managers only want answers, developers know the value of asking deep questions. Thus, AI. (BTW, PING is a command that produces a distinct sound on the Oric-1/Atmos computers, and it is thus an Onomatopoeia.. I know this, because I am a Senior Oric-1/Atmos Developer who knows what lies at #FA9F, how it works, what the 14 bytes are for, and so on.. because I once asked the question, "how does PING go 'poooinnng' but ZAP go 'zap'?") AI: <asks billions of questions in a second>PING is ..
• npodbielski 5mo ago
  The second part of the system that author proposes, will not work for most of the medium and small companies. From what I saw people that ran those companies, the owners for example were looking at those devs like, hacks that try to extort them for money. They were angrily grinding their teeth but put up with that because they need them to do their software to actually make money. Now, with so-called AI they will mostly slap something kinda working in few days and then maybe get hacked or double invoice some customer from time to time... They will learn of those problems the hard way. Or maybe they will not because it will be mostly working emailing system and nobody will care if it will loose 2% of the emails because of some bug. Nevertheless, either the Stable version, Scale version of the software will never happen or will be looked like not necessary or it will became a thing after catastrophic failure. Anyway I do not think it will be like that, everybody cares about speed and money and making money quickly without an effort is the ultimate unicorn entire world is after. Those complaining developers just stand in a way.
• casey2 5mo ago
  If you're a senior Go player and you think robots can play I'm suspicious of your expertise. Literally what people thought after Fan Hui (2-dan) was beaten. For humans software requires ingenuity and creativity. Computers can cheat that, infact computers ALWAYS cheat that to beat humans. NTP as a method of cheating is slightly more general than say board evaluation, so it's less efficient for the same problem, but scaling laws show that with enough compute NTP can beat humans at chess (or any most other arbitrary games, in real time).
• egorfine 5mo ago
  > this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can And push an insurmountable pile of technical debt onto the successor. Well, yeah, I understand the idea and I'm all for it: the less code the better, the less changes the better. However in certain industries it is no longer a right approach for the job. In modern frontend development if you did not update your codebase for like a couple of months, this codebase falls so much behind that it becomes way more expensive to push an upgrade as compared to daily minor updates of packages. Yeah, I hate this as much as you do, but this is the pace frontend is moving at, and if you don't follow, you will mount technical debt.
• lionkor 5mo ago
  I really dislike the "ah this is my favorite senior" language. The author would have done well to simply leave this "rating" of different kinds of people out, and it would not harm the article. In fact, it would improve it. People don't want to be judged in the introduction of an article, based on how they like to approach their literal dayjob. It's a weird jab.
• luodaint 5mo ago
  The article is all about technical communication — diagrams, architectural discussions, code snippets. The more difficult piece to communicate is product sense: which user feedback indicates a genuine trend, when a feature request is a workaround for an underlying issue vs. the issue itself. It’s not difficult for seasoned engineers with deep technical backgrounds to whiteboard a distributed system in twenty minutes. It takes hundreds of customer discussions, invalid hypotheses, and years of experience building judgment about whether this is the right solution at the right time. The engineers who compound quickly have usually built their skills in both areas concurrently. Communication of the latter is more challenging due to the judgment-based foundation beneath it.
• dragochat 5mo ago
  > I don’t like this kind of senior developer [...] not my wavelength. Bro & I would not get along well =)))) But the article IS good stuff.
• dnnddidiej 5mo ago
  This is an excellent article. Thought provoking and Ill rememner the 2 loops forever on. > What if we had one system just for speed? Like a beta? It would take incredible discipline from the business and customers not to consider that production software and demand 99.99 uptime and bug free.
• ahussain 5mo ago
  I’m curious about this scale vs speed distinction. Every codebase includes parts that are more experimental, and parts that are more core. My sense is that AI can help on both of these fronts (I.e building rapid prototypes on the fringes and hardening the core with better test coverage).
• ChrisMarshallNY 5mo ago
  > They want to avoid development as much as they can. One of my favorite .sigs was: I hate code, and want as little of it as possible in my software. I don't remember where I saw it, but it was a while ago. It's possible the author has an HN account. One of the things that happens to "avoiders," is that they get attacked for being "negative." It can get career-ending, when the management chain is the "Move fast and break things" type. I just stopped offering suggestions, after encountering that crap a few times, and learned to just quietly make preparations for when the wheels fall off. I have spent my entire adult life, shipping, and shipping means lots of "not-shiny," boring stuff. But it gets onto shelves, and into end-users' hands. I was originally trained in hardware development, where mistakes can't be fixed with an OTA update. It taught me to "play the tape through," and make sure that I do a good job on every part of the project; which includes a lot of anticipating problems, and designing mitigations and prevention.
• rudnevr 5mo ago
  I'm trying to avoid a snarky comment like "oh of course it's a senior dev's fault again", so I'll tell a story. When I started around 20 years ago, my junior dev experience was pretty harsh - I was taught, not always in a correct or respectful manner, to do this and not to do that. Overall though, it was absolutely useful and formative. Senior engineers are rarely abusers, they communicate real issues, better or worse, and it was on me to figure out why and how to work the right way. Also we were raised in a pretty receptive attitude to the "old" technology - from Tcl and Smalltalk to Ada, Perl, etc. It was admired classics rather than just old shit. Surprisingly, this didn't translate too well to my experience when I found myself in a mentoring position. Starting from 2015 maybe the situation changed. Newer generation of devs felt much more entitled to social games, higher salaries and opinions rather than authentic engineering interest and therefore my experience. No amount of structured communication would change that, even the cold pressure of production failures and very specific poor management feedback normally doesn't work. They're also more lenient to prod screw-ups, and often use "everyone can make a mistake" excuse for excusing even more mistakes. The thing is, most of them don't want to hear for any reason. As many of my peers I learned humility and accepted that as is, only using my advantage in expertise when it comes directly to my responsibility territory, and to avoid a hassle imposed by my eager younger teammates, like I usually parse prod logs and settings with command line while the younger guys trying to push through loki/grafana query limitations. I'm fine and safe, and my job is no less secure, I guess, because someone has to fix bugs etc. The companies less so, but as long as they don't care why would I. It will be interesting to see this generation wiped off by the next one. I guess they shouldn't be in a very good shape, because the foundation they built upon (namely quickly changing libraries and language supersets like React/TypeScript/some JVM flavour/and I hope Kafka) will be replaced by the next tech fashion.
• toshikatsu-oga 5mo ago
  [flagged]
• ionwake 5mo ago
  Ill never forget I was fired from an aerospace company for designing a new system that was basically a linear diagram compared to the highly complex nightmare web of mystery my boss had desgined for our current system, which simply didnt work. I was given a chance to redesign and it and when I failed to add the added complexity I was let go. To this day I reckon the higher ups are still having the same age old problems and excuses from their underlings regarding a system that has an utterly useless design. The guy in charge, rarely in the office, calmly explaining its a fantastic implementation, the new coders we are getting just cant work with it / operate it well because they suck. I am not bitter, if anything it just made me terrified of being C-suite of any large company, knowing it would be almost impossible to understand why your company is failing.
• buster 5mo ago
  > Forget maintaining stability, AI is a downright destabilizer. It worsens understandability, fixability, debuggability, teachability, guaranteability, all the bloody bilities. This is just an assumption and the whole article falls flat if this turns out to be wrong. In my limited (as everyone else's) experience, working with agentic AI needs good documentation, good specification (spec driven, you know it's all the hype nowadays). Those alone lead to much improvement. Now take into account that probably your senior dev also has more time to think about the big picture, to improve all those little things that were a nuisance in the past but now are a mere "Claude, fix that" in a worktree away.. I would not bet on the assumption of this article.
• brador 5mo ago
  Survivor bias. The ones who did were fired.
• narag 5mo ago
  Why junior bloggers fail to make me read their articles
  • khalic 5mo ago
    hot take number 9712956028926...
  • lioeters 5mo ago
    "Why experts fail to X", written by a non-expert.
• strix_varius 5mo ago
  > Why? Because they hunt a singular monster in professional software development: complexity. I love this sentence.
• xiaosong001 5mo ago
  [dead]
• kimjune01 5mo ago
  we lack the shared data structure for it
• deleted 5mo ago
  [deleted]
• SergeyKuch 5mo ago
  [dead]
• SergeyKuch 5mo ago
  [flagged]
• Prilog 5mo ago
  The “AI accelerates uncertainty reduction but increases system complexity” framing is probably one of the better ways I’ve seen this explained. What’s missing from a lot of the “AI replaces developers” discussion is that generating code is only a tiny part of operating production software. The hard part starts after deployment: debugging, understanding cascading failures, maintaining consistency, and safely evolving systems over time. Feels like the next wave of tooling won’t just be “AI that writes code faster”, but AI that helps absorb and reduce operational complexity after the code exists.
• jeffg2026 5mo ago
  [flagged]
• Izkata 5mo ago
  > Imagine you get asked to build something ambitious, and you say: > “Sure, I’ll have the Speed version ready in 3 days. Then the Scale version in about 6 weeks.” > They get what they want, speed and momentum. You get what you want, observation and design. Except that 6 weeks is now blocking the next thing and you'll be pushed to drop it. So this doesn't really solve anything. I was kind of hoping at the end they'd suggest getting the non-developers involved more so they can experience the pain points they're creating. Not entirely sure how that would work though.
• jake-coworker 5mo ago
  I don't love the title - the article is about differing perspectives/incentives in a company, not about senior developers' inability to communicate That said, I think everyone will agree both extremes are failure modes - moving too fast and not having things work right, or building things too correctly and never building something people want. IMO the two stereotypes in the article generally hold true, and the job of each in a healthy company is to present the trade-offs, and collect enough data to experimentally validate. And when you disagree, let the decision maker (CEO) decide, but disagree and commit
• edge_trader_41 5mo ago
  [flagged]
• deterministic 5mo ago
  In my experience, a lot of developers (senior or not) are really bad at (1) thinking clearly and (2) communicating clearly. Which is reflected in the software they write. If your thinking is messy, your code will be messy too.