Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering fundamentals matter more

rhonabwy.com

Post reply on HN
Print view View original

221–230 of 266 posts

Re: Software Engineering fundamentals matter more

#221

Post by blub »

Rebuff5007 wrote: post #93
samiv wrote: post #78

Earlier quoted context omitted.

What a sad analogy. IKEA furniture is mostly cheap particle board crap and it's a shame that we as a humanity have cheapened our lives to the point where IKEA is some kind of standard (and the only thing) most people can afford. Back in the day furniture was artisanal and hand made yet people were able to afford and have it. Isn't that in fact weird, supposedly our societies are richer than ever before but most peopl…

What a sad retelling of reality. A large amount of ikea furniture is not cheap particle board crap. they have a range of materials for all of their products, and even some of the medium end products look nice and hold well. Additionally, many middle-class families have "back in the day" stories where their houses were filled with bare essentials for which i'm sure an ikea bed frame would feel like an upgrade. I think…

Names and links or they don’t exist :)

Even their absolute high-end stuff is at best particle board with veneer. And you can bet the back will still be that thin 3mm fiberboard, no matter how high-end they look.

Unfortunately, top models nowadays have more and more hollow panels. Seems to me that quality’s going down and they’re trying to save money with the materials they offer. But they can still be a good enough compromise, as I found out when looking for e.g. a TV sideboard.

Re: Software Engineering fundamentals matter more

#222

Post by johnnyanmac »

8note wrote: post #201
quietbritishjim wrote: post #57

Earlier quoted context omitted.

The problem with this analogy (actually one of many) is that most people can make do with a cabinet that is literally identical to everyone else's. IKEA is great for that. If you want software that is literally identical to what someone else is using then you don't need AI. You need a license to that software! That is just the traditional software model. AI gives software that is bespoke with hundreds of decisions ma…

> If you want software that is literally identical to what someone else is using then you don't need AI. You need a license to that software! That is just the traditional software model. isnt this the software model that AI is gonna kill over time? You dont need to pay a recurring license fee when you vibe code up a free tier alternative and never do maintenance on it

Depends on if code is the value. Which is rarely is to the consumer. Coding isn't the bottleneck for a better Twitter/Facebook, even if the backend behind it does demand proper code. Code isn't really the bottle neck for GTA6. Code isn't why your Netflix service gets worse by the years.

Re: Software Engineering fundamentals matter more

#223

Post by johnnyanmac »

mekoka wrote: post #162
brabel wrote: post #62

> Making software debuggable, maintainable, layered, and composable – that’s still quite a trick. Quite a lot of that work requires extensive, thoughtful reasoning. And that’s where the LLM’s today, even the leading edge of the “capability” from frontier models, fall short. It’s been my quest during my career to figure out what is maintainable software, what is composable or not, and how the two things, and many othe…

> If your goal is to take over the market quick, as many here would like, maintainability is a very low priority aspect of your code base. Is it? How long do you expect to keep your momentum after "taking over the market"? Anecdata time. I once joined a 3 year old project that had ground itself to a near halt with this philosophy. The project's lead seemed almost allergic to the word "refactoring". It had accrued so…

>How long do you expect to keep your momentum after "taking over the market"?

A few years making millions is more than enough for leadership to be satisfied. Even if everyone underneath simply has broken dreams and an increasingly unstable work style. I guess in that lens the company "succeeded" compared to those who did things right and never took off.

Re: Software Engineering fundamentals matter more

#224

Post by johnnyanmac »

erichocean wrote: post #197

Scenario: an AI lab develops ASI for software development internally. The ASI produces bug-free software and human-readable specs. It's so reliable the company can guarantee the code matches the spec. Rather than provide tokens to developers, they instead sell finished software to the companies: specs in, software out. Companies no longer need to employ software developers. Instead, they buy bespoke, bug free, guaran…

>Seems plausible to me.

As plausible as any cyberpunk Utopia model you read up on, sure. Nevermind that AGI/ASI is still pie in the sky thinking as of now.

Re: Software Engineering fundamentals matter more

#225

Post by voidhorse »

user43928 wrote: post #155
voidhorse wrote: post #123

Earlier quoted context omitted.

But can't you see how coming out with a strong statement like "i've been doing this, it works" before your app even has a single user and before you've had to contend with any externally filed bug reports and keep the app stable as you fix those and add new features isn't very reasonable? If anything there are clear counter example to your claim, such as the major provider agent harnesses which are all almost always…

Don't you think I've fixed bugs and kept the app stable during the 300 hours I have been working on it? That's why I can say with full confidence that it works. I doubt it will magically all fall apart the moment an external user touches it, or that I will expand the scope dramatically in the near future. The agent harnesses are an interesting topic. I believe they have large teams shipping a ton of changes weekly. I…

> The agent harnesses are an interesting topic. I believe they have large teams shipping a ton of changes weekly. In that environment, is it realistic to expect rock solid software with such a feature set to be developed in a few months and shipped to 10M users?

Yes, the whole argument is that LLMs make shipping quality software at scale in months possible. You're arguing out of two sides of your mouth now. On the one hand, agents have enabled you to build a bullet-proof high quality app in a few months as a solo dev. On the other hand it's supposedly unreasonable to expect a team of engineers with lots of funding and lots of expertise to use those same LLMs to build high quality software in a few months.

The main difference is you are still working in a vacuum and the harness teams have actually shipped to users. Once you do that, you face significantly more challenges than you do tinkering in isolation. Don't claim a methodology works until you've actually proven so. "My personal closed source pet project that no one but me has ever seen works" is not convincing evidence. My pet dragon who is definitely real but that I can't show anyone else agrees.

Re: Software Engineering fundamentals matter more

#226

Post by jaggederest »

hirvi74 wrote: post #200
MattGaiser wrote: post #3

Earlier quoted context omitted.

What is “it” specifically and what languages are you using?

"It" is a lot of things. Languages: - C#/.NET: Sufficient sometimes, but not how I'd write things. Most results at least compile, but I have noticed plenty of defiance towards particular instructions, e.g, "Do not use , use " -> code contains and not . - C#/Godot: I have noticed the greatest amounts of defiance here. Not to mention most results are an 80/20 implementation of what I asked for. And no, I am not trying…

Direct feedback:

You have to give up on style. "not how I'd write things" is not a blocker. Defiance of instructions is normal, you just have to steer it and correct. There's no substitute for diligence yet.

80/20 - this means your scope was too large, split the scope or tell the agent to revert, split the scope, and try again.

RE and assembler: it's really good at this stuff. It can patch almost any binary with the right tools

Swift: you have to give it tool usage in whatever result you're wanting. If it's a macos app, you have to let the LLM pilot it to get feedback, or build an extensive end to end test suite that it can drive autonomously. If you get into the loop on changes it'll feel awful and like no time savings. Review at the level of using the app and looking at the code, not in process or reviewing every tool call or diff.

applescript: works great, I have a bunch of automation set up this way, what problems are you seeing?

elisp: tough language, llms kinda hate parentheses unless you're really tight on the linting, and elisp is enough of its own animal that the training for e.g. common lisp isn't great.

python: will suck unless you enable all the typechecking, make it use bdd, and have a linter/formatter run precommit and yell at the robot for you.

Web vs cli: you should use the cli 100% because it lets you change the environment, if you're getting better results on web, you haven't set your local environment up very well. My personal preference is to run my own dev server on aws but that's spendy.

Re: Software Engineering fundamentals matter more

#227

Post by eudamoniac »

samiv wrote: post #78
Alien1Being wrote: post #38

AI generated code is like IKEA furniture. IKEA furniture embodies many elements of good cabinet making but skips many nonessential elements. And does this more consistently than cabinet makers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day. In the future AI code inevitably will embody most good software engineering practices. And will do this more consistently than software en…

What a sad analogy. IKEA furniture is mostly cheap particle board crap and it's a shame that we as a humanity have cheapened our lives to the point where IKEA is some kind of standard (and the only thing) most people can afford. Back in the day furniture was artisanal and hand made yet people were able to afford and have it. Isn't that in fact weird, supposedly our societies are richer than ever before but most peopl…

> Back in the day furniture was artisanal and hand made yet people were able to afford and have it.

I'm pretty sure this is not correct. "Back in the day" artisanal solid wood furniture was so expensive that you would buy it once and keep it your entire life and then your children would use it after you die for their entire life. It was not even the same ballpark of price.

Re: Software Engineering fundamentals matter more

#228

Post by chr15m »

user43928 wrote: post #40
hbcdbff wrote: post #33

Earlier quoted context omitted.

How do you expect us to take your views on LLM code quality and durability seriously when a) you don’t even look at the code and b) you’ve only been doing this for two months?

I've been working on the app for four months, and I am clearly not talking about code quality. I am talking about product quality and maintainability. Both are more than adequate. I know this because I have worked on it for an estimated 300 hours. Has the author practiced a similar approach for even a week? I doubt it.

> worked on it for an estimated 300 hours

If humans aren't needed why have you had to spend 300 hours?

I upvoted your comment BTW because I think you might be right, but I'm not sure. I still see people doing a lot of work, despite LLMs.

Re: Software Engineering fundamentals matter more

#229

Post by [deleted] »

radlad wrote: post #149
LtWorf wrote: post #128

Earlier quoted context omitted.

You've never seen ikea furniture if you think it lasts less than a decade.

There are definitely different tiers. I've bought simple shelving that began to fall apart within years (Billy maybe?). I have 10 years old bedroom furniture still going strong (Kallax/Malm).

[deleted]

Re: Software Engineering fundamentals matter more

#230

Post by fatata123 »

Alien1Being wrote: post #38

AI generated code is like IKEA furniture. IKEA furniture embodies many elements of good cabinet making but skips many nonessential elements. And does this more consistently than cabinet makers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day. In the future AI code inevitably will embody most good software engineering practices. And will do this more consistently than software en…

[dead]
Post reply on HN