81–90 of 512 posts
Earlier quoted context omitted.
Does performance not matter? What if your AI uses an O(n) algorithm in a function when an O(log n) implementation exists? The output would still be "correct"
> Does performance not matter? Performance can be a direct target in a feedback loop and optimised away. That's the easy part. Taking an idea and poof-ing a working implementation is the hard part.
Earlier quoted context omitted.
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, balancin…
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…
My own two cents: there's an inherent tension with assistants and agents as productivity tools. The more you "let them rip", the higher the potential productivity benefits. And the less you will understand the outputs, or even if they built the "correct thing", which in many cases is something you can only crystalize an understanding about by doing the thing.
So I'm happy for all the people who don't care about code quality in terms of its aesthetic properties who are really enjoying the AI-era, that's great. But if your workload is not shifting from write-heavy to read-heavy, you inevitably will be responsible for a major outage or quality issue. And moreso, anyone like this should ask why anyone should feel the need to employ you for your services in the future, since your job amounts to "telling the LLM what to do and accepting it's output uncritically".
Earlier quoted context omitted.
> 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 pivo…
How do you even converge on the right data model without refining code? Elegant code and elegant data model are the exact same thing!
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. 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…
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.
If "good code" == "useful code", then yes. People forget that good engineering isn't "the strongest bridge", but the cheapest bridge that just barely won't fail under conditions.
Engineers don't build the cheapest bridge that just barely won't fail. They build the cheapest bridge that satisfies thousands of pages of regulatory requirements maintained and enforced by dozens of different government entities. Those regulations range from safety, to aesthetic, to environmental, to economic, to arcane. Left to their own devices, engineers would build the cheapest bridge they could sell that hopefu…
I don't know any real (i.e. non-software) engineers, but I would love to ask them whether what you said is true. For years now, I've been convinced that we should've stuck with calling ourselves "software developers", rather than trying to crib the respectability of engineering without understanding what makes that discipline respectable.
Our toxic little industry would benefit a lot from looking at other fields, like medicine, and taking steps to become more responsible for the outcomes of our work.
Earlier quoted context omitted.
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 use…
> 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.
Earlier quoted context omitted.
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…
> 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 th…
If "good code" == "useful code", then yes. People forget that good engineering isn't "the strongest bridge", but the cheapest bridge that just barely won't fail under conditions.
Earlier quoted context omitted.
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…
> 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 th…
Earlier quoted context omitted.
Look up Roman concrete. There are 2000 year old bridges and aqueducts still in use. We only recently figured out how to reproduce Roman concrete. We’d have more but a lot were blown up during WWII.
There is nothing special about roman concrete compared to moderns concrete. Modern concrete is much better The difference is that they didn't have rebar. And so they built gravity stable structures. Heavy and costly as fuck. A modern steel and concrete structure is much lighter and much cheaper to produce. It does mean a nodern structure doesn't last as long but also the roman stuff we see is what survived the test o…
Roman concrete is special because it is much more self-healing than modern concrete, and thus more durable.
However, that comes at the cost of being much less strong, set much slower and require rare ingredients. Roman concrete also doesn’t play nice with steel reinforcement.