12 ms·

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as y

• roland35 7mo ago
  That's true, but I think there is a gray area in between. As things scale up in one way or another, having high quality is important for both #1 and #2. Its hard to extend software that was designed poorly. The question where experience comes in is when quality is and isnt worth the time. I can create all sorts of cool software I couldn't before because now I can quickly pump out "good enough" android apps or react front ends! (Not trying to denigrate front end devs, it's just a skill I dont have)
• packetlost 7mo ago
  I agree on the software dev camps. > The general public does not care about anything other than the capabilities and limitations of your product. It's absolutely asinine to say the general public doesn't care about the quality and experience of using software. People care enough that Microsoft's Windows director sent out a very tail-between-legs apology letter due to the backlash. It's as it always has been, balancing quality and features is... well, a balance and matters.
  • seamossfet 7mo ago
    The public doesn't care about the code itself, they absolutely care about the quality and experience of using the software. But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code. My point was that consuming software as a user of the product can be quite different from the experience of writing that software. Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product. I'd just be careful to separate code elegance from product experience, since they are different. Related? Yeah, sure. But they're not the same thing.
    • packetlost 7mo ago
      That's fair! > Facebook is a great example of this, there's some gnarly old spaghetti code under the hood just from the years of legacy code but those are largely invisible to the user and their experience of the product. I'm sure that's the case in basically everything, it sorta doesn't matter (until it does) if it's cordoned off into a corner that doesn't change and nominally works from the outside perspective. But those cases are usually isolated, if they aren't it usually quickly becomes noticeable to the user in one way or another, and I think that's where these new tools give the illusion of faster velocity. If it's truly all spaghetti underneath, the ability to make changes nosedives.
    • blackbear_ 7mo ago
      There are other players in the game: the business and the market. Good code makes it easier for the business to move fast and stay ahead of the competition while reducing expenses for doing so.
      • WarmWash 7mo ago
        That's true, but excel '98 would still cover probably 80% of users use cases. A lot, and I mean a lot, of software work is trying to justify existence by constantly playing and toying with a product that worked for for everyone in version 1.0, whether it be to justify a job or justify charging customers $$ per month to "keep current".
• ModernMech 7mo ago
  > You treat your code as a means to an end to make a product for a user. It isn’t that though, the “end” here is making money not building products for users. Typically people who are making products for users cares about the craft. If the means-to-end people could type words into a box and get money out the other side, they would prefer to deal with that than products or users. Thats why ai slop is so prevalent — the people putting it out there don’t care about the quality of their output or how it’s used by people, as long as it juices their favorite metrics - views, likes, subscribes, ad revenue whatever. Products and users are not in scope.
  • seamossfet 7mo ago
    Yeah, I'm not trying to defend slop. I don't think all means-to-end people are just in it for money, I'll use the anecdote of myself. My team is working on a CAD for drug discovery and the goal isn't to just siphon money from people, the goal is legitimately to improve computational modeling of drug interactions with targets. With that in mind, I care about the quality of the code insofar as it lets me achieve that goal. If I vibe coded a bunch of incoherent garbage into the platform, it would help me ship faster but it would undermine my goal of building this tool since it wouldn't produce reliable or useful models. I do think there's a huge problem with a subset of means-to-end people just cranking out slop, but it's not fair to categorize everyone in that camp this way ya'know?
• Swizec 7mo ago
  > The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster. I am in both camps. Always have been. Code janitors about to be in high demand. We’ve always been pretty popular with leadership and it’s gonna get even more important. Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things My output is org velocity.
  • seamossfet 7mo ago
    >slop cannons I am stealing that phrase haha
  • acedTrex 7mo ago
    > My output is org velocity. Amen, slow and steady and the feature fly wheel just keeps getting faster.
  • joshmarlow 7mo ago
    > Treat code design and architecture as the thing that lets your slop canons (90% of engineers even pre-ai) move fast without breaking things I'm currently of the opinion that humans should be laser focused on the data model. If you've got the right data model, the code is simpler. If you've got the relevant logical objects and events in the database with the right expressivity, you have a lot of optionality for pivoting as the architecture evolves. It's about that solid foundation - and of course lots of tests on the other side.
    • JambalayaJimbo 7mo ago
      How do you even converge on the right data model without refining code? Elegant code and elegant data model are the exact same thing!
      • bitwize 7mo ago
        It's called "systems analysis". Programmers are generally pretty terrible at it because it requires holistic, big-picture thinking. But it used to take up the bulk of the design activity for a new enterprise system.
• clan 7mo ago
  I respect your opinion and especially your honesty. And at the same time I hope that you will some day be forced to maintain a project written by someone else with that mindset. Cruel, yes. But unfortunately schadenfreude is a real thing - I must be honest too. I have gotten to old for ship now, ask questions later projects.
  • jstanley 7mo ago
    I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity. If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. I think camp 2 would rather see one beautiful thing than ten useful things.
    • deleted 7mo ago
      [deleted]
    • ambicapter 7mo ago
      > At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. Ah yes, if you aren't shitting code out the door as fast as possible, you're probably not shipping anything at all.
      • Nevermark 7mo ago
        That isn't a fair reading.
        • jplusequalt 7mo ago
          Neither is the original assertion. There are thousands of examples of exceptionally well crafted code bases that are used by many. I would posit the Linux kernel as an example, which is arguably the most used piece of software in the world.
• bloppe 7mo ago
  I mostly agree with this. Part of the confusion with the discourse around AI is the fact that "software engineering" can refer to tons of different things. A Next.js app is pretty different from a Kubernetes operator, which is pretty different from a compiler, etc. I've worked on a project that went over the complexity cliff before LLM coding even existed. It can get pretty hairy when you already have well-established customers with long-term use-cases that absolutely cannot be broken, but their use-cases are supported by a Gordian Knot of tech debt that practically cannot be improved without breaking something. It's not about a single bug that an LLM (or human) might introduce. It's about a complete breakdown in velocity and/or reliability, but the product is very mature and still makes money; so abandoning it and starting over is not considered realistic. Eager uptake of tech debt helped fuel the product's rise to popularity, but ultimately turned it into a dead end. It's a tough balancing act. I think a lot of LLM-generated platforms will fall eventually into this trap, but it will take many years.
  • 9rx 7mo ago
    > It can get pretty hairy when you already have well-established customers with long-term use-cases that absolutely cannot be broken LLMs are often poor at writing tests that provide useful information to human readers and poor at writing tests that can survive project evolution. To be fair, humans are also poor at these tasks if done in hindsight, after all the information you normally want to capture in tests has been forgotten. That boat has been missed for the legacy code no matter how you slice it. But LLMs are quite good at writing tests that lock in existing functionality in the rawest way. It seems like LLM-generation is actually the best hope of saving such a project?
• iamcalledrob 7mo ago
  Sloppy technical design ends up manifesting in bugs, experiential jank, and instability. There are some types of software (e.g. websites especially), where a bit of jank and is generally acceptable. Sessions are relatively short, and your users can reload the webpage if things stop working. The technical rigor of these codebases tends to be poor, but it's generally fine. Then there's software which is very sensitive to issues (e.g. a multi-player game server, a driver, or anything that's highly concurrent). The technical rigor here needs to be very high, because a single mistake can be devastating. This type of software attracts people who want to take pride in their code, because the quality really does matter. I think these people are feeling threatened by LLMs. Not so much because an LLM is going to outperform them, but because an LLM will (currently) make poor technical design decisions that will eventually add up to the ruin of high-rigor software.
  • Benjammer 7mo ago
    > the quality really does matter. If this level of quality/rigor does matter for something like a game, do you think the market will enforce this? If low rigor leads to a poor product, won't it sell less than a good product in this market? Shouldn't the market just naturally weed out the AI slop over time, assuming it's true that "quality really does matter"? Or were you thinking about "matter" in some other sense than business/product success?
    • bloppe 7mo ago
      Yes, both the article and GP are making that exact point about it mattering from a customer's perspective.
    • deleted 7mo ago
      [deleted]
    • theossuary 7mo ago
      Yes, there's every reason to believe the market will weed out the AI slop. The problem is, just like with stocks, the market can stay irrational longer than you can stay solvent. While we all wait for executives to learn that code rigor matters, we still have bills to pay. After a year when they start trying to hire people to clean up their mess, we'll be the ones having to shovel a whole new level of shit; and the choice will be between that and starving. As someone who also falls into camp one, and absolutely loves that we have thinking computers now, I can also recognize that we're angling towards a world of hurt over the next few years while a bunch of people in power have to learn hard lessons we'll all suffer for.
• ambicapter 7mo ago
  This is like when people decided that everyone was either "introvert" or "extrovert" and then everyone started making decisions about how to live their life based on this extremely reductive dichotomy. There are products that are made better when the code itself is better. I would argue that the vast majority of products are expected to be reliable, so it would make sense that reliable code makes for better product. That's not being a code craftsman, it's being a good product designer and depending on your industry, sometimes even being a good businessman. Or, again, depending on your industry, not being callous about destroying people's lives in the various ways that bad code can.
  • renewiltord 7mo ago
    I’m an introvert. I make sure that all my “welcome to the company” presentations are in green. I am also an extrovert in that I add more green than required.
• slopinthebag 7mo ago
  This is just cope to avoid feeling any shame for shipping slop to users.
  • throwaway613746 7mo ago
    [dead]
• logicchains 7mo ago
  It's perfectly possible to write very clean code with AI, it just takes a lot more time and prompting.
  • Gigachad 7mo ago
    Easier to just write it yourself.
• yakattak 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. If you have buggy software, people don’t use it if there are alternatives. They don’t care about the code but hard to maintain, buggy code will eventually translate to users trying other products.
  • theshrike79 7mo ago
    Good code can also be buggy, bad code can be buggy. The thing here was that if you have two boxes that take the same input and produce the same output at the same speed, do you care what the insides look like? What if one is delivered in 4 days and the other in 30 days and costs more? Which one will you pick?
• allknowingfrog 7mo ago
  I think "make a product" is the important point of disagreement here. AI can generate code that users are willing to pay for, but for how long? The debate is around the long-term impact of these short-term gains. Code _is_ a means to an end, but well-engineered code is a more reliable means than what AI currently generates. These are ends of a spectrum and we're all on it somewhere. You ever notice how everyone who drives slower than you is a moron and everyone who drives faster than you is a maniac? Your two camps have a similar bias.
  • zozbot234 7mo ago
    > Code _is_ a means to an end, but well-engineered code is a more reliable means than what AI currently generates. AI can help you make well-engineered code, but you have to ask for it because it's not what it will do by default. Prompt it with "Figure out how this crappy piece of code really works and document it in depth. Propose viable refactorings that could improve code quality" and it will do a much better job than the usual vibe-coded result.
• quantummagic 7mo ago
  This is a very useful insight. It nicely identifies part of the reason for the stark bifurcation of opinion on AI. Unfortunately, many of the comments below it are emotional and dismissive, pointing out its explanatory limitations, rather than considering its useful, probative value.
  • bakugo 7mo ago
    "I have an opinion and everyone on the planet agrees with me, if you disagree, you don't matter" is not a useful insight, and is, in fact, far more emotional and dismissive than any of the replies to it.
    • quantummagic 7mo ago
      That's a horribly broken misrepresentation of what was said in the original post. If that's what you took away from it, you're not reading carefully or critically.
      • ratrace 7mo ago
        [dead]
      • emp17344 7mo ago
        That is, in fact, how it comes across. You’re labeling perceived opponents as “emotional” and “dismissive”.
      • bakugo 7mo ago
        No, that's exactly what the original post said. > No one has ever made a purchasing decision based on how good your code is. This has since been edited (I suspect OP later realized how ridiculous of a claim it was) but it's an objectively false statement that blindly projects OP's stance on software quality onto the entire population. People have, in fact, stopped using software because it was too slow or buggy. I've done it, many others have done it. To give you a real example, I'm a fan of JetBrains IDEs functionality-wise, but I've been seriously considering moving away from them due to how bloated and unoptimized they've become in recent years - when your IDE feels more sluggish than one built on top of Electron, something has gone seriously wrong. I don't have to actually read the code itself to know it's bad code, I can feel it by simply using the software. Just because you don't care doesn't mean others don't. Modern society was not built by people who didn't care about their craft, nor was it built by designing everything with the lowest common denominator in mind.
• CodeMage 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. There are two reasons for this. One is that the people who make purchasing decisions are often not the people who suffer from your bad code. If the user is not the customer, then your software can be shitty to the point of being a constant headache, because the user is powerless to replace it. The other reason is that there's no such thing as "free market" anymore. We've been sold the idea that "if someone does it better, then they'll win", but that's a fragile idea that needs constant protection from bad actors. The last time that protection was enacted was when the DOJ went against Microsoft. > Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively. Any semblance of accountability for that has been diluted so much that it's not worth mentioning. A bug someone wrote into some cloud service can end up causing huge real-world damage in people's lives, but those people are so far removed from the suits that made the important decisions that they're powerless to change anything and won't ever see that damage redressed in any way. So yeah, I'm in camp #2 and I'm bitter about AI, because it's just accelerating and exacerbating the enshittification. Someone on the HN wrote recently that everyone who's foaming at the mouth about how AI helps us ship faster is forgetting that velocity is a vector -- it's not just about how fast you're going, but also in what direction. I'd go further and say that I'm not even convinced we're moving that much faster. We're just cranking out the code faster, but if we actually had to review that code properly and make all the necessary fixes, I'm pretty sure we would end up with a net loss of velocity.
• nocman 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly). The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks. You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.
  • steveBK123 7mo ago
    > The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks. Exactly. A lot of devs optimizing for whether the feature is going to take a day or an hour, but not contemplating that it's going to be out in the wild for 10 years either way. Maybe do it well once.
    • ttamslam 7mo ago
      > but not contemplating that it's going to be out in the wild for 10 years either way I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.
      • steveBK123 7mo ago
        It's important to know which type of repo/project you are in and hire/code accordingly. I've seen mismatch in each direction..
• squidsoup 7mo ago
  false dichotomy - you need to care about both.
• imiric 7mo ago
  While creating good software is as much of an art as it is a science, this is not why the craft is important. It is because people who pay attention to detail and put care into their work undoubtedly create better products. This is true in all industries, not just in IT. The question is how much does the market value this, and how much it should value it. For one-off scripts and software built for personal use, it doesn't matter. Go nuts. Move fast and break things. But the quality requirement scales proportionally with how many people use and rely on the software. And not just users, but developers. Subjective properties like maintainability become very important if more than one developer needs to work on the codebase. This is true even for LLMs, which can often make a larger mess if the existing code is not in good shape. To be clear, I don't think LLMs inevitably produce poor quality software. They can certainly be steered in a good direction. But that also requires an expert at the wheel to provide good guidance, which IME often takes as much, if not more, work than doing it by hand. So all this talk about these new tools replacing the craft of programming is overblown. What they're doing, and will continue to do unless some fundamental breakthrough is reached, is make the creation of poor quality software very accessible. This is not the fault of the tools, but of the humans who use them. And this should concern everyone.
• steveBK123 7mo ago
  I think type1 vs type2 dev requirements are also dependent on lifecycle / scale of your project, not just that its library / framework / mission critical software. If you aren't even sure if your idea is even gonna work, whether you have PMF, or the company will be around next year.. then yeah.. speed over quality all day long. On the other hand, I've never done the startup thing myself, and tend to work on software project with 10-20 year lifecycles. When code velocity maximalism leads to outages, excess compute cost and reputational issues.. good code matters again. Re: "No one has ever made a purchasing decision based on how good your code is." Sonos very much could go out of business for agreeing with this line. I can tell you lots of people stopped buying their products because of how bad their code quality became with the big app change debacle. Lost over a decade of built up good will. Apple is going through this lately with the last couple major OS releases across platforms and whatever is going on with their AI. This despite having incredible hardware.
• tclancy 7mo ago
  Now you done it! Yeah, one of the difficult things is being able to see both sides. At the end of the day, I happen to write code because that's how I can best accomplish the things I need to do with the minimum of effort. While I do take pride in elegance and quality of code, it is always a means to an end. When I start gold plating, I try to remind myself of the adage I learned in a marketing class: No one ever needed a drill, they needed the ability to make holes. It is strange, but not really upsetting to me, that I am not particularly anal about the code Claude is generating for me anymore but that could also be a function of how low stakes the projects are or the fact nothing has exploded yet.
• Nevermark 7mo ago
  > it's hard to talk about this stuff if we're not clear on which types of projects we're talking about. It mystifies me when people don't intuit this. For any suitably sized project, there are parts where elegance and friction removal are far more important than others. By an order or two of magnitude. I have shipped beautifully-honed, highly craft code. Right alongside jank that was debugged in the "Well it seems to work now" and "Don't touch anything behind this in-project PI" category. There are very good reasons and situations for both approaches, even in one project.
• JambalayaJimbo 7mo ago
  You need both to be a great software engineer. The "means to an end" people will happily slop out PRs and let the "craft" people worry about it.
• Darmani 7mo ago
  No-one comes out of the womb caring about code quality. People learn to care about the craft precisely because internal quality -- cohesion, modularity, robustness -- leads to external quality (correctness, speed, evolvability). People who care about code quality are not artists who want to paint on the company's dime. They are people who care about shipping a product deeply enough to make sure that doing so is a pleasant experience both for themselves and their colleagues, and also have the maturity to do a little bit more thinking today, so that next week they can make better decisions without thinking, so that they don't get called at 4 AM the night after launch for some emergency debugging of an issue that that really should have been impossible if it was properly designed. > No one has ever made a purchasing decision based on how good your code is. Usually they don't get to see the internals of the product, but they can make inferences based on its externals. You've heard plenty of products called a "vibe-coded piece of crap" this year, even if they're not open source. But also, this is just not true. Code quality is a factor in lots of purchasing decisions. When buying open source products, having your own team check out the repo is incredibly common. If there are glaring signs in the first 5 minutes that it was hacked together, your chances of getting the sale have gone way down. In the largest deals, inspecting the source code It was for an investment decision rather than for a purchase, but I've been personally hired to do some "emergency API design" so a company can show that it both has the thing being designed, and that their design is good.
  • mkehrt 7mo ago
    > People who care about code quality are not artists who want to paint on the company's dime. They are people who care about shipping a product deeply enough to make sure that doing so is a pleasant experience both for themselves and their colleagues, and also have the maturity to do a little bit more thinking today, so that next week they can make better decisions without thinking, so that they don't get called at 4 AM the night after launch for some emergency debugging of an issue that that really should have been impossible if it was properly designed. Speak for yourself. This is exactly the GPs point. Some people care more about the craft of code than the output. I personally find writing good code to be what motivates me. Obviously its a spectrum; shipping is good too. But it's not why I get up in the morning.
• farmeroy 7mo ago
  I think developers fall into two camps: 1. you care about shipping working, tested code that solves a specific business/user problem 2. you care about closing tickets that were assigned to you
  • leptons 7mo ago
    I think developers fall in to way more than 2 "camps".
  • singpolyma3 7mo ago
    Some of us also care about craft and code quality instead
• meheleventyone 7mo ago
  You realize you’re essentially building a false dichotomy? I work in video games where code really is a means to an end but still see that authorship is important even if that code is uuuuugly due to it being the expression of the game itself. From that perspective I’m neither worried about craft or product but my ability to express myself though code as the game behaves. Although if you really must have only two categories I’d be in camp one. As such AI is a net negative as it would be in writing a novel or making any other kind of art.
• qaid 7mo ago
  Professionally, I've always been in camp #2. The quality of your code at least partially represents you in the eyes of your peers. I imagine this is rapidly changing, but the fact will always remain that readable code that you can reason about is objectively better. For personal projects, I've been in both camps: For scripts and one-offs, always #1. Same for prototypes where I'm usually focused on understanding the domain and the shape of the product. I happily trade code quality for time when it's simple, throwaway, or not important. But for developing a product to release, you want to be able to jump back in even if it's years later. That said, I'm struggling with this with my newest product. Wavering between the two camps. Enforcing quality takes time that can be spent on more features...
• alecbz 7mo ago
  Craft, in coding or anything else, exists for a reason. It can bleed over into vain frivolity, but craft helps keep the quality of things high. Craft often inspires a quasi-religious adherence to fight the ever-present temptation to just cut this one corner here real quick, because is anything really going to go wrong? The problems that come from ignoring craft are often very far-removed from the decisions that cause them, and because of this craft instills a sense of always doing the right thing all the time. This can definitely go too far, but I think it's a complete misunderstanding to think that craft exists for reasons other than ensuring you produce high-quality products for users. Adherents to craft will often end up caring about the code as end-goal, but that's because this ends up producing better products, in aggregate.
• pron 7mo ago
  I generally fall into the first camp, too, but the code that AI produces is problematic because it's code that will stop working in an unrecoverable way after some number of changes. That's what happened in the Anthropic C compiler experiment (they ended up with a codebase that wasn't working and couldn't be fixed), and that's what happens once every 3-5 changes I see Codex making in my own codebase. I think, if I had let that code in, the project would have been destroyed in another 10 or so changes, in the sense that it would be impossible to fix a bug without creating another. We're not talking style or elegance here. We're talking ticking time bombs. I think that the real two camps here are those who haven't carefully - and I mean really carefully - reviewed the code the agents write and haven't put their process under some real stress test vs those who have. Obviously, people who don't look for the time bombs naturally think everything is fine. That's how time bombs work. I can make this more concrete. The program wants to depend on some invariant, say that a particular list is always sorted, and the code maintains it by always inserting elements in the right place in the list. Other code that needs to search for an element depends on that invariant. Then it turns out that under some conditions - due to concurrency, say - an element is inserted in the wrong place and the list isn't sorted, so one of the places that tries to find an element in the list fails to find it. At that point, it's a coin toss of whether the agent will fix the insertion or the search. If it fixes the search, the bug is still there for all the other consumers of the list, but the testing didn't catch that. Then what happens is that, with further changes, depending on their scope, you find that some new code depends on the intended invariant and some doesn't. After several such splits and several failed invariants, the program ends up in a place that nothing can be done to fix a bug. If the project is "done" before that happens - you're in luck; if not, you're in deep, deep trouble. But right up until that point, unless you very carefully review the code (because the agents are really good at making code seem reasonable under cursory scrutiny), you think everything is fine. Unless you go looking for cracks, every building seems stable until some catastrophic failure, and AI-generated code is full of cracks that are just waiting for the right weight distribution to break open and collapse. So it sounds to me that the people you think are in the first camp not only just care how the building is built as long as it doesn't collapse, but also believe that if it hasn't collapsed yet it must be stable. The first part is, indeed, a matter of perspective, but the second part is just wrong (not just in principle but also when you actually see the AI's full-of-cracks code).
• deleted 7mo ago
  [deleted]
• bigstrat2003 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. The general public does not care about anything other than the capabilities and limitations of your product. The capabilities and limitations of your product are defined in part by how good the code is. If you write a buggy mess (whether you write it yourself or vibe code it), people aren't going to tolerate that unless your software has no competitors doing better. People very much do care about the results that good code provides, even if they don't care about the code as an end in itself.
  • efromvt 7mo ago
    I think this is exactly the point though (maybe more of the link than of this comment) - a sufficiently good product by all external quality metrics is fine even if the code is written on one line in a giant file or some other monstrosity. As long as one black box behaves the same way as another in all dimensions, they are competitive. You can argue that internal details often point to an external deficiency, but if they don’t, then there is no competitive pressure.
• coffeefirst 7mo ago
  This is absolutely false. The purpose of craft is a make a good product. I don’t care what kind of steel you used to design my car, but I care a great deal that it was designed well, is safe, and doesn’t break down all the time. Craft isn’t a fussy thing.
• yobbo 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. I routinely close tabs when I sense that low-quality code is wasting time and resources, including e-commerce sites. Amazon randomly cancelled my account so I will never shop from them. I try to only buy computers and electronics with confirmed good drivers. Etc.
• somewhereoutth 7mo ago
  3. You use the act of writing code to think about a given problem, and by so doing not only produce a better code, but also gain a deeper understanding of the problem itself - in combination a better product all around.
• jmyeet 7mo ago
  I'm going to re-characterize your categorization: 1. The people who don't understand (nor care) about the risks and complexity of what they're delivering; and 2. The people that do. Widespread AI usage is going to be a security nightmare of prompt injection and leaking credentials and PII. > No one has ever made a purchasing decision based on how good your code is. This just isn't true. There's a whole process in purchasing software, buying a company or signing a large contract called "due diligence". Due diligence means to varying degree checking how secure the product is, the company's processes, any security risks, responsiveness to bugfixes, CVEs and so on. AI is going to absolutely fail any kind of due diligence. There's a little thing called the halting problem, which in this context basically means there's no way to guarantee that the AI will be restricted from doing anything you don't want it to do. An amusing example was an Air Canada chatbot that hallucinated a refund policy that a court said it had to honor [1]. How confident are we going to be that AIs won't leak customer information, steal money from customers and so on? I'm not confident at all. [1]: https://arstechnica.com/tech-policy/2024/02/air-canada-must-honor-refund-policy-invented-by-airlines-chatbot/ https://arstechnica.com/tech-policy/2024/02/air-canada-must-...
• dirkc 7mo ago
  I view every single line of code as a liability, the best solution is if you can avoid writing any code. Does that put me into group 1 or group 2?
• joe_the_user 7mo ago
  I was just using an app that competes with airbnb. That the app's code is extraordinarly unreliable was a significant factor in my interactions with others on the app, especially, I gradually realized I couldn't be sure messages were delivered or data was up-to-date. That influenced some unfortunate interactions with people and meant that no one could be held to their agreements since you never knew if they received the agreements. So, well, code quality kind of matters. But I suppose you're still right in a sense - currently people buy and use complete crap.
• throwatdem12311 7mo ago
  > No one has ever made a purchasing decision based on how good your code is Because the ones that sell crappy code don’t sell to people that can tell the difference. You think I’d pay for Jira or Confluence if it wasn’t foisted upon me by a manager that has got it in with the Atlassian sales rep? I don’t even need to see Atlassian’s source code to know it’s sh*t.
• ggregoire 7mo ago
  3. Coding is fun, prompting not so much
• amelius 7mo ago
  > With that said, I do have respect for people in the latter camp. Well, you certainly should. Those people made AI based coding a possibility in the first place.
• coldtea 7mo ago
  >No one has ever made a purchasing decision based on how good your code is. That's however what makes for stable systems, deep knowledgable engineers, and structurally building the basis for the future. If all you care about is getting money for your product slop, it's not different than late night marketed crap, or fast fashion...
• fasterik 7mo ago
  I think this is a false dichotomy. If you're passionate about your craft, you will make a higher quality product. The real division is between those who measure the success of a project in: - revenue/man-hour, features shipped/man-hour, etc. - ms response time, GB/s throughput, number of bugs actually shipped to customers, etc. People in the second camp use AI, but it's a lot more limited and targeted. And yes, you can always cut corners and ship software faster, but it's not going to be higher quality by any objective metric.
• Thanemate 7mo ago
  How about the type of developer who comes up with statistics and made up "camps" as if enjoying the craft itself makes you, out of necessity of the false premise, unable to enjoy the fact that what you made is useful enough to people that they choose your product because you are obsessed with making a good work? John Carmack has talked about it in a podcast a few years ago, and he's the closest popular programmer that I can think of who was simply obsessed with milking every tiny ounce of GPU performance, yet none of his effort would matter if Doom and Quake weren't fun games.
• pm 7mo ago
  It is possible to exist in both camps. The quality of the process affects the quality of the product, and the quality of your thought affects the quality of the process. It's a cycle of continual learning, and from that perspective, thought, process and product are indivisible. Treating code as a means to an end doesn't guarantee success for your product anymore than treating code as a craft.
  • Rapzid 7mo ago
    It's not possible for two-camp believers to conceive of two-camp dwellers. That would be tantamount to a third, potentially superior camp. The two-camp construct is a tool to establish the believer as a member of the supreme one camp group; apart from the lesser campers. Their entire identity and self worth is built around one-camp membership.
• solid_fuel 7mo ago
  It's easy to write off critics of this slop development as just "caring about the wrong thing", but that is couched in incorrect assumptions. This is the unfortunately common mistake of confusing taking responsibility with some sort of "caring about the code" in an artistic sense. I can certainly appreciate the artistry of well-written code, but I care about having a solid and maintainable code-base because I am accountable for what the code I write does. Perhaps this is an antiquated concept which has fallen out of favor in silicon valley, but code doesn't just run in an imaginary world where there are no consequences and everything is fun all the time. You are responsible for the product you sell. If you sell a photo app that has a security bug, you are responsible for your customers nude photos being leaked. If you vibe-code a forum and store passwords in plaintext, you are responsible for the inevitable breech and harm. The "general public" might not care, but that is only because the market is governed by imperfect information. Ultimately the public are the ones that get hurt by defective products.
• peacebeard 7mo ago
  I think this is a false dichotomy. Maybe there is some theoretical developer who cares about their craft only due to platonic idealism, but most developers who care about their craft want their code to be correct, fast, maintainable, usable, etc. in ways that do indeed benefit its users. At worst, misalignment in priorities can come into play, but it's much more subtle than developers either caring or not caring about craft.
• theredsix 7mo ago
  With AI you actually don't need to choose anymore. Well laid out abstractions actually make AI generate code faster and more accurately. Spending the time in camp 2 to design well and then using AI like camp 1 gives you the best of both worlds.
• giancarlostoro 7mo ago
  > The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster. I'm weird, I'm part of camp 2, but I think AI can be used to really craft some interesting things. While I appreciate camp 1, camp 2 is what produces better codebases that are easier to maintain, myself and others have realized, that the best practices for humans are also the best practice for AI models to fit your code.
• Waterluvian 7mo ago
  It’s much more complex. Part of your value as an engineer is having a good feel for balancing the trade offs on your code. Code is usually a liability. A means to an end. But is your code going to run for a minute, a month, a year, or longer? How often will it change? How likely are you going to have to add unforeseen features? Etc. Etc. Etc.
• ryandrake 7mo ago
  Trying to describe craftsmanship always brings me back to the Steve Jobs quote: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
  • mikkupikku 7mo ago
    Steve Jobs didn't really know anything about cabinetry, because using plywood / MDF in places where it won't be seen but which would benifit from dimensional stability is absolutely common and there's no reason it shouldn't be.
    • ryandrake 7mo ago
      You might be missing the point of the quote. He's not talking about whether it is commonly done. He's talking about the mentality that justifies sacrificing the aesthetic and artistry, in favor of things like "dimensional stability". He is giving a reason why it shouldn't be done, and people can disagree about whether the reason is a good one.
      • mikkupikku 7mo ago
        He's saying that carpenters who make nice things wouldn't use a material like that, but they objectively do and this doesn't sacrifice the aesthetic or artistry. He specifically calls out the use of the material in a place it wouldn't be seen as something that the carpenter making beautiful cabinets wouldn't do, but that's actually something they absolutely do. He's trying to argue some other point by way of this analogy, but his analogy is wrong because he doesn't know anything about it. It would be like if I was trying to argue my point by way of car analogy but the example I chose was to say that car enthusiasts insist on genuine OEM parts, I'm only exposing myself as somebody who doesn't understand car people.
        • 7mo ago
• davnicwil 7mo ago
  I keep seeing this idea repeated, but I don't accept the dichotomy between those who care about 'crafting code' and those who care about 'building products' as though they are opposite points on a spectrum. To me, the entire point of crafting good code is building a product with care in the detail. They're inseparable. I don't think I've ever in my life met someone who cared a lot about code and technology who didn't also care immensely about detail, and design, and craft in what they were building. The two are different expressions of the same quality in a person, from what I've seen.
  • carlosjobim 7mo ago
    Millions of companies work out of spreadsheets, which is incredibly low quality and inefficient code by programming standards (not Excel, but the spreadsheet itself). Would those companies be better off just using pen and paper? Because "craft code" programmers don't have time for this, and not all companies can pay for bespoke software. Well, maybe now they can, with AI "slop". Likewise, should people who don't have the skills or means to cook delicious and nutritious meals just starve without food? Or is it okay that they eat something which isn't perfect?
    • davnicwil 7mo ago
      With respect I'm not sure what you're saying follows as a challenge to what I've said. Perhaps because I didn't phrase clearly enough. I don't think that. In fact I spent years at a company whose product let people build software backed by spreadsheets so I'm at least a little acquainted with that corner of the world :-) The thing I'm saying is that among those who want to engage in building software via coding, I don't accept that caring about coding craft and caring about building great products that solve problems for people are opposing points on a spectrum. If anything I'd argue the opposite, that these qualities are correlated. Again, speaking about people who are interested in building software with code. I think the thing of building useful software with software (like spreadsheets / AI builders) while deliberately not wanting to engage with coding is a discussion apart from this. There's apparent overlap because it's true to say that those people are concerned with building useful things and not necessarily concerned with coding. But the fact they're not concerned with coding by definition puts them out the scope of the first conversation, it's just a different thing.
• mememememememo 7mo ago
  Yes great so we sell shit. No one buys a ticket because ofnhow safe the 737 Max plane is or buys a post office franchise based on how good the software Fujitsu sold the post office is, but fuck lets take some pride in outselves and try to ship quality work.
• Pxtl 7mo ago
  As developers we have a unique advantage over everybody else dealing with the way AIgen is revolutionizing careers: Everybody else is dealing with AIgen is suffering the AI spitting out the end product. Like if we asked AI to generate the compiled binary instead of the source. Artists can't get AIgen to make human-reviewed changes to a .psd file or an .svg, it poops out a fully formed .png. It usurps the entire process instead of collaborating with the artist. Same for musicians. But since our work is done in text and there's a massive publicly accessible corpus of that text, it can collaborate with us on the design in a way that others don't get. In software the "power of plain text" has given us a unique advantage over kinds of creative work. Which is good, because AIgen tends to be clumsy and needs guidance. Why give up that advantage?
• deleted 7mo ago
  [deleted]
• ppqqrr 7mo ago
  i've learned in two years of unemployed hacking that there is a camp 3: you treat code like an evolving life form, requiring both ingenious introspective craft and utilitarian grit to survive and thrive. a product is a trajectory of software in time, and software is a trajectory of code in time; this is no different from how our genetic code determines our physical existence, which then shapes our lives. there is no spectrum between code vs product; if you want to remain relevant in software design, you must see them as layers of a larger whole (and there are many, many more layers once you go beyond the binary of code VS product).
• sornaensis 7mo ago
  It all depends on the tools. AI will surely give a competitive advantage to people working with better languages and tooling, right? Because they can tell the AI to write code and tests in a way that quashes bugs before they can even occur. And then they can ship those products much faster than before, because human hours aren't being eaten up writing out all of these abstractions and tests. The better tooling will let the AI iterate faster and catch errors earlier in the loop. Right?
• shinycode 7mo ago
  That’s non sense. Every software people pay or use as their professional tool should be carefully crafted. Would you buy a house/car/anything or value knowing that people who built it don’t care about their craft as long as you got it in your hands and pay for it ? Or maybe you produce something cheap and worthless
• voidfunc 7mo ago
  It's the end of era where the plucky code crafter gets to have a seat at the table of production. Those skills are going to become less and less useful going forward. Industry is going to stop hiring those types. The future of software looks a lot more like factory production lines with a small group of architect-tier engineers working on a design with product management and then feeding it into the factory for prototyping and production. If you're not an experienced late senior or principal engineer at your career stage by now there is basically no future for you in this industry. Lower end roles will continue to be reduced. People who can build and maintain the factory and understand its outputs are going to be the remaining high-value software talent.
• BoorishBears 7mo ago
  I think some people are misunderstanding your point. Yes, some people left to their own devices would take twice as long to ship a product half as buggy only to find out the team that shipped early has taken a massive lead on distribution and now half the product needs to be reworked to catch up. And some people left to their own devices will also ship a buggy mess way too early to a massive number of people and end up with zero traction or validation out of it, because the bugs weren't letting users properly experience the core experience. So we've established no one is entirely right, no one is entirely wrong, it's ying/yang and really both sides should ideally exist in each developer in a dynamic balance that changes based on the situation. - But there's also a 3rd camp that's the intersection of these: You want to make products that are so good or so advanced *, that embracing the craft aspect of coding is inherent to actually achieving the goal. That's a frontend where the actual product is well outside typical CRUD app forms + dashboard and you start getting into advanced WebGL work, or complex non-standard UI state that most LLMs start to choke on. Or needing to do things quicker than the "default" (not even naive) approach allows for UX reasons. I ran into this using Needleman-Wunsch to identify UI elements on return visits to a site without an LLM request adding latency: to me that's the "crafty" part of engineering serving an actual user need. It's a completely different experience getting near instant feedback vs the default today of making another LLM request. And it's this 3rd camp's feedback on LLM development that people in the 1st camp wrongly dismiss as being part the 2nd craft-maxxed group. For some usecases, slop is actually terminal. Intentionally contrived example, but if you're building a Linear competitor and you vibecode a CRDT setup that works well enough, but has some core decisions that mean it'll never be fast enough to feel instant and frontend tricks are hiding that, but now users are moving faster than the data and creating conflicts with their own actions and... You backed yourself into a wall that you don't discover until it's too late. It's only hypervigilance and strong taste/opinion at every layer of building that kind of product that works. LLMs struggle with that kind of work right now and what's worrying is, the biggest flaw (a low floor in terms of output quality) doesn't seem to be improving. Opus 4.6 will still try to dynamically import random statements mid function. GPT 5.3 tried to satisfy a typechecker by writing a BFS across an untyped object instead of just updating the type definitions. RL seems to be driving the floor lower actually as the failure modes become more and more unpredictable compared to even GPT 3.5 which would not even be "creative enough" to do some of these things. It feels like we need a bigger breakthrough than we've seen in the last 1-2 years to actually get to the point where it can do that "Type 3" work. * good/advanced to enable product-led growth, not good/advanced for the sake of it
• mamami 7mo ago
  This type of thinking is exactly how you end up with 50MB webpages and is core to rhe general sloppification of software
• keybored 7mo ago
  This is a Venus v.s. Mars developer trope at this point. > The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate on their product faster. That’s fine for people argue those things. My criticisms of AI are mainly 1. The principle of the GenAI approach 2. Political The first point is about how stupid the GenAI approach is (I could link to the arguments). But I have left open the door for pure results, i.e. demonstrating that it (despite my belief) works in practice. So this is not about craftmanship. I’ve previously commented that I would respect a more principled approach even though it takes my craft.[1] > Personally, I fall into the first camp. Of course you do. Because... > No one has ever made a purchasing decision based on how good your code is. In these dichotomies the author typically puts himself forward as the pragmatist and the other side as the ones who care about things that are just irrelevant to the purchasing decision or whatever. But the AI haters have made real arguments against AI, against the people behind AI, and so on. It’s not a matter of vibes. So maybe respond to those arguments? We don’t need another armchair lesson in psychological inclinations. Be a pragmatist for all I care. But beware of the bloodless pragmatist who only sees what is, essentially, instant product gratification and not what comes after, or from the sides, or from below. [1] https://news.ycombinator.com/item?id=47358696 https://news.ycombinator.com/item?id=47358696
• culi 7mo ago
  Personally I fall into the first camp and have quite a lot of criticisms of AI-usage. The parts of my job that were the easiest are now done by AI and the parts of my job that were the worst have exploded and are most of what I do now. Code quality isn't just a fetish. It has real implications for security and the final product. I've also found that unmaintainable codebases aren't just hard to maintain for humans. LLMs seem to struggle with them just as much
• throwaway613746 7mo ago
  [dead]
• DetroitThrow 7mo ago
  >No one has ever made a purchasing decision based on how good your code is. I got my company to switch from GitHub to GitLab after repeated outages. I've always moved companies to away from using GCP or Azure because of their reliability problems. This is a really funny comment.
• haolez 7mo ago
  Option 1 is a PM.
• hn_acc1 7mo ago
  I'm in neither camp. I write code to make our product work, which we can then sell as a unit to the end user. If I do a bad job, I get a bunch of bug reports, I get called out for writing bugs, etc. We've been pushed to use AI, and it's hurt more than it's helped with our code base.
• smusamashah 7mo ago
  I dont think 1 and 2 are that clear cut. We recently started using Codex at work. I never thought it would be able to do even closer to what it has been doing for me in our legacy code base. But I am not the fan of code it writes most of the times. I want my code to read and behave certain way. I can not submit that code, even if it works, if I can't explain or just don't like it. I then iterate over that code myself or ask AI until it has the shape I agree with. For my personal side projects I don't care as much what code looks like as long as it works correctly and easily modifiable. But for work, it still remains my responsibility no matter which tool was used.
• dbshapco 7mo ago
  I feel like any argument that begins by asserting a dichotomy is almost certain to be circular and will proceed as if the dichotomy were a fact rather than an unproven hypothesis. I don't believe there is a dichotomy, or even a spectrum of developers, but a complex landscape. Of course, that is also an bald assertion, but on a weaker claim, and no less valid than the original assertion. That said, independent of assertions about developer classification, in my experience there is a clear connection between the quality of the software and the quality of the product, and I've often see evidence of poor quality software compromising the product and user experience. Poor quality leaks out. Remember BSOD? Maybe not. I've become hesitant to unleash coding agents simply because the code base ends up looking like the victim of drive-by coding, littered with curious lambda functions, poor encapsulation, etc. The only thing I use coding agents for is exploratory and throwaway code, like one off scripts. I love coding agents for all the ancillary work, I protect the critical path like mamma bear her cubs. Coding agents make all the second order work easier so I have more bandwidth to focus on the critical parts. Again, software is a landscape, but at least for my work I can't abdicate parts to a coding agent and "works" is an inadequate standard. I need bullet-proof and unfailingly correct. Token generation definitely produces a certain stream-of-consciousness, Kerouac-as-programmer style. As long as I don't ever have to maintain or modify the code myself, am not concerned about cost control (especially in cloud environments where I am billed by compute cycles), I am fine with quick and dirty and done. I sigh when I see what should be a six line change in my head balloon to 300 lines of generated code, revert, and write the six lines myself. Would take longer to write the prompt to get the coding agent to fix it than fix it myself. It would grind away for several minutes and burn up an astonishing number of tokens for simple fixes. Anything linguistic the coding agents do well. Want to rename a variable in 300 different source files? I mean, it is overkill to be running a 200B parameter model to avoid writing the sed script I might write otherwise, but who am I to turn my nose up at my work being subsidized by investors? I don't think that economic model will go on forever. Any higher abstraction is being cargo-culted from language. This is where LLMs are weakest, because they don't understand abstraction or encapsulation, only the artifacts as expressed in language. Outside of exploratory and throwaway code, I use inline prompting to precisely target and scope changes, and then identify the cleanup and refactoring required to bring the code to acceptable quality. Although I do a lot of cleanup by hand as well. Rather than tell the coding agent that a lambda function wrapping a one liner that is used in one place in the code is dumb, I'll just remove the lambda myself. The coding agent can't adopt and generalize lessons from code review comments the way a human software engineer can -- I am forced to burn tokens every single time to get it to dial back its insane love affair with lambda functions. Again, not a big deal while costs remain subsidized. Operations and maintenance overhead in the type of software I've written through my career dominates over programming cost. Telecom, aerospace, e-commerce, etc. Systems are long lived. Outages are expensive. Regulatory compliance is a large factor. I've worked in shops with 70% cost overhead in operations. A $50K a month cloud compute bill can be reduced to $15K. There's usually some low hanging fruit and poor quality software doesn't account for all of this, but it is a significant fraction. Like a poorly written termination condition in a container that essentially was a busy wait burning thousands of dollars a month doing nothing (true story). I am currently writing a trading system, and can't afford to hallucinate a bunch of bad trades. Like the developer landscape, the software landscape is complex and not uniform. So I will concede there are probably many types of software outside of my own experience that can be implemented largely by coding agents. Low consequence. Marginal operational overhead. I might assert that coding agents forte is autogenerating technical debt, but then I am just being a wag. Less waggishly I would say use of coding agents is subject to engineering judgement, like any tool. Who is going to read that headline or give it a billion dollar valuation?
• singpolyma3 7mo ago
  Can I be both? When I wish I can take great pride in the craft of a particular piece of code. But also I know when to put up and make the damn thing work.
• ramsaybolton 7mo ago
  Okay tell this to game devs
• DesaiAshu 7mo ago
  We crossed a threshold in the past couple months where I'm not sure I'd agree that "libraries other devs depend on" is the right cutoff for LLMs. In many cases, LLMs will write more concise, faster, and more accurate code. Not by one-shooting, but through a deeper search of possibility space - not dissimilar to how stockfish and other pre-llm search algorithms worked Modern harnesses are systems built with LLMs as one of many building blocks (incl. regex, test suites, linters). If it can be measured and verified, there's a good chance LLMs will optimize it This is not a new concept. Humans stopped writing "artful" assembly many years ago, because Lattner and others made it much more efficient to rely on LLVM than hand-optimizing assembly It's also been demonstrated in other domains within Google (4x4 matmul, silicon photonics, protein folding) Interface heavy apps are not purely about objective function, they are about feel, comfort, usability - those apps will benefit heavily from humans. But subcomponents of these apps (eg. an algorithm to route packets efficiently) can often be better solved (somewhat objectively) by LLM-based solvers or other forms of RL. However, writing assembly for the sake of art sounds rather interesting in an 2026. Many of my favorite musicians and DJs are driving a resurgence in vinyl to help balance the computed future - and I think that's a great thing
  • nostrebored 7mo ago
    what types of problems are you seeing this for? i'm wondering if it's just a difference in domains, but this is not our experience at all. llms will write something, but the odds that it is efficient for any problem with deep complexity has been basically zero. if it really were fuzzing and finding different candidate spaces, then I'd expect it to be good at things like dynamic programming, where I've only seen it fail. usually i see it get stuck in a bad solution and just thrashes around in that minima. these are problems where we can construct a verifiable test space, and it will eventually wind up with a solution, but one that is thousands of lines long and uses no structure of the problem space
• waterTanuki 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. RollerCoaster Tycoon. > The general public does not care about anything other than the capabilities and limitations of your product. Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively. People care how fast you're able to ship updates, new features, and bugfixes. If you're working with a pile of vibe-coded spaghetti slop it's going to take longer to deliver these.
• rolandhvar 7mo ago
  I mean just look at UV. Did that guy make it because Rust, and because he's passionate about that sort of thing? Probably. But it's fucking fast. So did he sell out to OpenAI? Of course he did. And thusly, both camps.
• Rapzid 7mo ago
  I find there are two types of people. People who think developers fall into one of two camps. And people worth listening to.
• yoyohello13 7mo ago
  It seems pretty clear to me that the AI coding revolution has not lead to better software. In fact, software seems more brittle than ever now. Code quality is absolutely important. It’s just not a quality that’s easily visible to a layman. I can definitely feel the difference as a user when a program has been crafted with care.
• tikhonj 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. This is very much a "it's not the fall that kills you, it's the sudden stop at the end" sort of thing. (Same with the other variant I've heard, which is something like "no company has gone out of business because of tech debt".) Code is as much a tool for developing and expressing conceptual models as it is for making computers do things. So not only does code quality have proximate impacts on engineering productivity and reliability, but, done well, it also improves the holistic design of the system you're building. You get better tools, faster, by putting some thought and care into your codebase and, especially, your core abstractions. Teams with good code move faster even in the short term and produce better tools and products. Of course, it's not just a matter of code; you also need a culture that gives engineers the agency to make real, long-term decisions about what you're building (not just how) which, unfortunately, is rare to find in the modern tech industry :/ The dominant "high-output management" paradigm where code is seen as a virtually fungible "output" to be "delivered" loses the higher-order advantages of good code and good conceptual design, and leaves us with something much closer to the trade-off you describe. But there are other ways of approaching technical work that don't make this trade-off at all!
• eboy 7mo ago
  [dead]
• threethirtytwo 7mo ago
  I fall into camp 2 but I’m different. I cannot delude myself away from reality. What you will find is that people in camp 2 are lying to them selves. They are denying an impending reality where ai slop becomes even better than the code they write themselves. Also it’s more than an art or a craft. It’s identity. Many people hold their coding skill as an identity they honed it over many years and it put them in the ranking they are in today. This kind of destruction of identity by AI is what causes people to deny reality. This stuff also covers your job, even if you don’t hold coding as an identity it is still responsible for many people’s livelihoods. Like ai is convenient right now but what happens when it gets even more convenient? What happens to your job and your life especially if software was all you did for over a decade? I’m in camp 2 and I can’t lie to myself about what’s happening. I’ve embraced ai and I now vibe code daily even though I was originally an artistic functional programmer. This ability comes at high cost. I’m able to do it because I hold zero identity. I dont identity with anything and I don’t put too much pride into anything I do or at least if I put pride into something I’m always conscious of severing the entire thing at a moments notice. Lying to oneself is a powerful ability but it becomes a liability when society goes through an intense paradigm shift. This is what is happening now.
• m0llusk 7mo ago
  There is a huge space of possible software solutions. A very large amount of software that has real value involves using basic methodologies to build interfaces to databases and enable some known business logic. Writing this kind of software is very different compared to making highly general developer tools that need to have finely honed abstractions. LLMs are especially good at whipping up basic apps, but can actually interfere with the process of coming up with and implementing new concepts that operate differently from existing tools. In this respect I find that working with LLMs is very similar to working with graduate students who have energy, drive, and patience, but are also prone to making bad decisions and doing work that ends up being thrown away.
• gmerc 7mo ago
  Is this like some kind of disorder? I’m asking because as a healthcare tech professional, In reasonably sure you don’t want me to adopt “this product is for entertainment only” copilot and software that’s of bad code quality. People have gotten radiation overdoses from those. So I’m confused. I really am, help me understand your world view.
• UltraSane 7mo ago
  Code quality is directly related to how easy it is to modify without creating bugs which customers absolutely DO care about. I've read about an EMR product that was such spaghetti code every bug fix was likely to create 2 new bugs. I suspect this is a major reason Siri has not had any major new features in forever.
• cortesoft 7mo ago
  It's funny because I feel like I am both. Sometimes I am in it for the code itself, and the process of writing it. I see how the code will perfectly fit what I want to do, and I am so excited to make that happen. I want to make that thing. Other times, I have something specific I want to accomplish, but I dread the amount of time it will take to make it happen. Now, it is never that I don't know HOW to make it happen, it is that I know how, and I know how many steps it is and how many components there are to build to even get the simplest version running and I just dread it. I want the thing, but I don't want to spend the time to make the thing. I have had so much fun recently making so many things that I have never gotten around to over the years, because I just couldn't justify the time. I also have the time to tell the AI to add all the nice to haves, and handle all the edge cases that weren't worth the time before, etc. I am having a blast. I still stop to write the fun bits when I want to, though. It is great because I only have to code the bits I want, that are fun.
• yurimo 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. When I make a purchasing decision I expect the payment to go trough quickly and correctly and for whatever I purchase to arrive to me in reasonable time. All of this rests on the reputation of software being solid. If a user hears a whiff of purchase not being executed correctly, money or goods going somewhere else, this is the death sentence for your company. Industry is now pushing for agentic web where agents can do this on your behalf. But if we have slop foundations and then add unstable models that can hallucinate and make mistakes on top of it, then it's just a recipe for catastrophe. I think relegating 2) into category of only mission critical software escapes the reality of how much reliability goes into everyday services people use.
• snthpy 7mo ago
  Well put. I agree.
• globular-toast 7mo ago
  Ah, that'll be why Toyota is struggling. They spent too much effort making their cars reliable and not enough time making them look good. Oh wait, they're the biggest car builder in the world.
• throw310822 7mo ago
  There is also type 3, the worst kind: the developer who enjoys writing code to "get things done", no matter what the requirements are and the quality of the code. Produces tons of spaghetti code that barely works, without much thought about architecture or quality, and duly accompanied by tons of unit tests that test the exact implementation, bugs and all.
• roncesvalles 7mo ago
  This is a false dichotomy. Good code creates good products. >No one has ever made a purchasing decision based on how good your code is. Disagree. Users tend to be very sensitive to quality, in software more than anything else. (Of course there isn't always perfect transmission from "user" to "purchaser" but most likely for an upstart product, your user will be your customer. You're not Oracle or Microsoft yet.) In fact, quality matters now especially more than before because the barrier to entry has reduced. If you have a great idea, but executed it poorly, it attracts second movers like a magnet. Quality is intimidating. Quality is moat. Good software engineers (your camp 2) can anticipate the ways in which bad code results in a poor quality product, or one that is difficult to debug and evolve. That is the crux of good code. Good code is not craftsmanship in the same sense as making a beautiful painting or making colorful notes.
• camgunz 7mo ago
  This binary is old and tired. It's possible to want to ship things and think LLMs make that harder. You don't engage with TFA at all, which is exploring this exact point: that the more slop that gets into prod the harder it will be to add features and fix bugs. If you like LLMs for coding and care about shipping long-term, this should be something you have an answer for.
• aryehof 7mo ago
  I feel like your missing a third alternative:- You (are required to) treat your code as having to fulfill both functional requirements and declared non-functional requirements, including measures of maintainability, reliability, performance, and security and (regulatory/legal) compliance.
• _the_inflator 7mo ago
  The dude is right and I strongly side with him however, what is missing is that I oscillate like the TV megahertz that powered the first commercial Pang games between states and this open the space for more grey in between altered states like “Ok, will fix later. Let’s put a #TODO and ship it.” So instead of criticizing the gentleman for its dichotomy I feel like adding more states to it to complete the picture. And I mean it, this is not making fun of someone it means I tamed myself in stopping to do premature optimization knowing Gigahertz won’t care about me saving a cycle and might even hinder the masterfully crafted compilers from optimizing even more. 3. Partly awesome, partly not so much but don’t need to be awesome. 4. Myself has to understand this masterpiece of human thinking in six months and more from here and after a 20 hour stint I myself marvel at the result so better comment before committing the code into oblivion. 5. Embarrassing, but people are delighted. 6. This made headlines years ago, but some code doesn’t age well. 7. OMG, OOP might looks right, but a new paradigm rushes me into refactoring frenzy and makes the code look better without breaking any features! 8. I used tool to check for bottlenecks and it runs well, but looks crap. So what do I do? 9. Loop unrolling is still a thing or not? Do compilers have headaches just like I do? Do they really care or simply follow orders or adjust to the target platform and settings?
• uduni 7mo ago
  Slop becomes impossible to maintain, and eventually product velocity slows down. Maybe it's ok for an ultra simple todo app, but for most apps code quality absolutely matters... Users expect snappy UX and all the new bells and whistles. Why did Whatsapp grow so big while thousands of previous chat apps didn't code quality (scalability)
• fatata123 7mo ago
  [dead]
• rkagerer 7mo ago
  The best of us have a little bit of both 1 and 2.
• bayindirh 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. As stated by others, this is very false. Most if not all software I use is selected by its disk/memory footprint and performance. Having a small disk/memory footprint and having good performance at the same time is a good indicator of a good code quality. Moreover, after using computers for more than three decades, you get a feeling about the performance of a particular software suite. So an inefficient piece of code makes itself known in a loud way if you look the right way. One of my favorite applications, Obsidian, is generally performs well, but when you hit it just the right way (e.g. add a couple of PDFs and enable previewing), you can feel how sluggish it becomes. Having a suite of well written applications which have high performance/footprint ratio also allows me to do more with less resources and in less time. So, good code quality matters. It also almost guarantees the software suite will be maintained in a longer time. Incidentally, I'm also in camp #2, and write my code with the same attention to detail. I have also written code which squeezed all performance from systems, approaching theoretical IPC limits of the processor the code is running on.
  • theshrike79 7mo ago
    I've built dozens of services and applications for companies. ZERO times has anyone even mentioned disk/memory footprint. Performance maaybe, but no hard limits were defined in any contracts. And even those were "these things have to be processed within 24 hours because the law says so", not microsecond precision. Even Obsidian is 440MB. It's a markdown editor with a built-in javascript scripting system. There's no reason for it to be almost half a gigabyte. Zero people have checked the directory size and went "nah, too big, won't use it".
    • bayindirh 7mo ago
      > Zero people have checked the directory size and went "nah, too big, won't use it". Nope, at least one. I refused to install software just because it's too big. I resisted using Obsidian exactly of these reasons until I failed to find a credible alternative. Well, there's ZimWiki, but it wasn't working on macOS well enough to use that daily.
  • 7mo ago
• konschubert 7mo ago
  I fall strictly into camp 1, but I disagree on code quality. Code quality makes the difference between a janky system that works most of the time and a rock solid system that is an enjoyment to use. QA can only apply duct tape. If your state management isn’t clean, the UX will suck. If your functions aren’t clean, you will keep chasing bugs. Luckily, AI is capable of writing good code. Today, that still requires some amount of hand holding, but it’s getting better.
• est 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. But many ppl will refuse a purchasing because the product breaks randomly
  • theshrike79 7mo ago
    I've used programs for 30 years. They have broke down randomly, despite being artisanally programmed by actual humans. Being created by a human doesn't imbue any specific amount of reliability to a piece of software.
• paganel 7mo ago
  There's not that much about art and craft but about knowing that less is more and that adding complexity to a thing (almost any thing) will only bring greater troubles down the road. We've had to learn this as an industry for how long now?, I'd say 70 years, give or take (I've only been a professional programmer for about 20 years, if that counts), so a new methodology coming in and saying that there is indeed a silver bullet might not be that well-received.
• k__ 7mo ago
  "No one has ever made a purchasing decision based on how good your code is." Because to determine good code, you need to see it and I'd presume most open source code is free.
• otabdeveloper4 7mo ago
  Are you seriously claiming that technical debt doesn't exist?
  • hu3 7mo ago
    I read it more like: Tech deb is over indexed by many and most money doesn't care as long as it works reasonably well.
    • otabdeveloper4 7mo ago
      It's called "debt" because you will be forced to pay it off eventually. In other words, it "works reasonably well" until it doesn't. That point might break your business. Many such cases.
• tpoacher 7mo ago
  "Made with Slop" is the equivalent of "Made in China" (in the olden derogatory sense). Just because one falls in the "Cha bu duo" camp and (potentially) looks down on the "Kaizen" types doesn't mean the two products are equivalent. That also doesn't mean that slop / cha bu duo / made in china products are bad, mind you. They have their place, and occasionally a Kaizen approach would be detrimental to getting "something" done quick and dirty that will likely work ok anyway. The danger is in believing that just because they're "ok" this means they are equivalent (or at least largely overlap) with the more refined products, which is demonstrably false and can be a dangerous attitude to have.
• rainmaking 7mo ago
  That's a fascinating way to look at it. I've always found my self at the clean code end of the spectrum (which also means simple and flexible to me) because it makes it easier to be flexible for customer needs. So I like good code but it's a means to an end.
• marstall 7mo ago
  | iterate on their product faster. i've run into a situation where it really slowed iteration down, because i wasn't able at some point to explain in english what I wanted it to do and had to go into the code, which, lo and behold, I didn't understand. Ended up scrapping everything that had been generated and starting over by hand!
• mhitza 7mo ago
  This is an often repeated reductionist classification, which I've yet to match with my real life experience. Vibe coding will fill in more "new feature" checkboxes, faster, but the level of quality averages out, to something often mediocre, or worse (like all my OSS projects in which I experiment; because such projects are the training data). It skips liberally on maintainability, accessibility, security and privacy considerations. Code is a liability, I want to have less of it at a higher abstraction level (for which natural language isn't a good fit due to inherent ambiguity). For products, simplicity and user utility is how I approach the problem when given wiggle room. We are on HN, so there's bound to be many startup people that only need to bang out features to lure in users and then pass on that pile further onto someone else, when they cash out. What I have seen however, are mid-managers+ that haven't coded in a decade or so, and now with LLMs they feel that they deliver equal quality results, whereas they have been so long out of the game and haven't picked up the modern skills on how to maintain and build applications.
  • theshrike79 7mo ago
    Sometimes a mediocre solution is better than no solution, especially if the mediocre solution is done in days. Yes, there are risks (Lethal Trifecta and all that), but AI assisted developmet by non-programmers isn't that much worse than letting the same people do complex macro/function/VBA setups in shared Excel sheets. I'm running out of fingers on my hands on the number of 100% vibe-coded applications we've built internally that save double digits of % of time from people's day to day work. All created by the people who use them to fix a very specific workflow they've had to do by hand over hours. Now It's a click of a button on a bespoke application they made.
• Shorel 7mo ago
  People do these kind of decisions every day, every second. Shit bloated code is one of the reasons Epic Launcher is extremely behind in market share when compared to Steam. Sure, they ship their product fast. They can iterate faster than Valve. They also add technical debt with each iteration. Also: we are almost all using a Chrome derived browser instead of Firefox, old IE, old Opera, because of performance and quality. They just won the internet because of the quality of their code. Besides that, all browsers let you browse the internet. When people can choose, they choose quality most of the time.
• chunkyguy 7mo ago
  > You treat your code as a means to an end to make a product for a user. This sounds more like a product owner not a developer
• SwtCyber 7mo ago
  Most real-world work sits somewhere in the middle
• agentultra 7mo ago
  True. I’ve never bought a piece of commercial software and wanted to inspect the source first before making that decision. But I will demand my money back or sue you if your crappy code leaks my personal information, destroys my property, performs worse than advertised, or otherwise harms me in some way. There was sloppy code before LLMs. It’s what they were trained on. And it’s why they generate slop. All that code that was rushed out to meet an arbitrary deadline made up by the sales team, written by junior and lazy senior developers, pushed by the, “code doesn’t matter,” folks. Code written by the enterprise architecture astronauts with a class hierarchy deeper than the Mariana Trench. A few years down the line you get bloated, slow, hard to maintain spaghetti piles of dung. Windows rendering text that stutter when you scroll them. Virtual keyboards that take seconds to pop up. Browser tabs that take more available memory than was available to send astronauts to the moon and back. When humans write it you generally have a few people on a team who are concerned with these things. They try to reign in the slop generating, “always be shipping,” people. You need a mix of both. Because each line of code is a liability as much as it’s a new feature.
• xigoi 7mo ago
  You are assuming that people only write software to sell it to someone. Most software I write is either for myself or for an academic project, and in both cases, code sualita definitely matters.
• lelanthran 7mo ago
  > I find most developers fall into one of two camps: > 1. You treat your code as a means to an end to make a product for a user. > 2. You treat the code itself as your craft, with the product being a vector for your craft. Among the vocal devs, maybe. Most devs choose a trade-off between #1 and #2, leaning heavily towards #2. And the reason is, very few people actually want to the output of their labour to be poor, no matter how superficially good it looks. I find, like the poster below me said, the people presenting the false dichotomoty you present are desperate to legitimise their production of lovecraftian code horrors. It's a trick, a verbal one usually, that people who espouse woo and who know that they are BSing, use to sort of "borrow" legitimacy from a field that is already respectable. Like... ghost-believers referring to themselves as occult scientists. They throw in the word "scientist" in there to borrow the legitimacy and respectability of actual scientists[1]. Throwing in "user delight" or "useful to the user" into their arguments for vibe-coding is their way of borrowing the respectability of actual developers, who had always been developing for an actual user, and who cared about their user enough to target that specific use-case. The folks in #1 are simply borrowing what they can from the respectable practitioners to paper over the fact that all they care about is themselves, not actual users. The clear majority of them are hoping to hit a jackpot; the borrowed terms, phrases and words is simply a poor attempt to cover up their naked greed. --------------------------- [1] There's probably a joke in there somewhere about "software engineers" :-)
• 9rx 7mo ago
  > The people who typically have the most negative things to say about AI fall into camp #2 I think more often they simply picked the wrong programming language as a target. In my experience, AI is especially bad at writing Typescript/Javascript, which happens to overlap with the most widely used language. I have negative things to say about AI too when developing in that ecosystem. If I only ever used AI in that ecosystem I'd probably tell you it is useless with the rest of them. But my daily work sees me working in more than one language and when I am in some other language environments I have no reservations about AI whatsoever. AI vs good code is no longer even at odds with each other. In those certain languages, the models write good, stable, production-ready code pretty much all the time. It is really quite amazing.
• raincole 7mo ago
  > The general public does not care about anything other than the capabilities and limitations of your product. The developers don't care that either. If developers cared the whole npm ecosystem wouldn't exist.
• devin 7mo ago
  I do both 1 and 2, because 1 is frequently served by some attention to 2 at times. This notion that it’s one or the other is unserious.
• thesz 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. People make purchasing decisions on the availability of source code all the time, preferring source code available and be able to use it. It is safe to assume that they can perform purchase decisions on the quality of source code, given all is equal.
• 710dev 7mo ago
  [flagged]
• ratmeadow 7mo ago
  > No one has ever made a purchasing decision based on how good your code is. Another perspective: if the quality of your code has no bearing on the quality of the product, then your code/produce clearly isn't doing much useful, and perhaps we could do without it.