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

161–170 of 266 posts

Re: Software Engineering fundamentals matter more

#161

Post by adam_arthur »

arcanemachiner wrote: post #75
mstank wrote: post #70

I have an open question for software engineers out there: As someone that has never studied CS but has written basic code most of my life (accelerated now with AI), where is the best place to learn software engineering fundamentals?

I don't think there is such a thing as "software engineering fundamentals", as the fundamentals differ based on the type of software you want to make. Do you want to make websites, or work on embedded systems? Do you need to squeeze every OK ounce of performance out of the machine running your code, or is developer velocity more important to you? Will your code run on a single machine, or does it need to be networked…

There are tons of core principles that can be learned that largely apply across fields.

One prime example, single source of truth for data/concepts. To be violated only when performance is meaningfully improved (denormalized databases). But when you do so, you should definitely recognize you're opening up out of sync issues for that performance gain.

Though for the majority of code, there is no performance benefit to adding multiple sources of truth. Yet it's the most common error I see re: quality.

The sad thing is that software engineering fundamentals and best practices never became widespread or widely taught in school prior to LLMs

Re: Software Engineering fundamentals matter more

#162

Post by mekoka »

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 much tech debt that I was the third "new guy" to join in less than two years, after the previous attempts to hire had successively faltered within 6 months, because my predecessors couldn't deal with the unmaintainable mess. I made it to 9 months.

Maintainability is not tied to OOP or functional, but rather to how much a team cares to manage the cognitive load that comes attached to having to deal with the code base. When that becomes a genuine priority, the code tends to be written with concern for the next human mind's ability to interact with it. And when it makes sense in that one pursuit, functional, OOP, DRY, WET all become valid -- even seductive but toxic affordances like inheritance can sometimes be useful in the right context.

Re: Software Engineering fundamentals matter more

#163

Post by mikgp »

user43928 wrote: post #31

The article says what many here like to hear, but in my opinion the core arguments are false. > Making software debuggable, maintainable, layered, and composable – that’s still quite a trick Not really. I have been working on a mobile app for months, and I stopped even glancing at the code about two months ago. 150k LOC, around half of that in tests, and the AI still has no problem maintaining the code on my behalf.…

“Debuggable? It can add extensive instrumentation in seconds.

None of this requires expertise, prompting, or mention of TDD. It's the default.”

I’m pretty sure it takes some level of expertise just to use the term “instrumentation” correctly in a sentence.

Re: Software Engineering fundamentals matter more

#164

Post by mikgp »

amelius wrote: post #51

But do the same SWE fundamentals apply if the one doing the programming is many times smarter than us?

I think SWE fundamentals matter - because it will be a long time before software is a closed system.

And the problem is that as long as humans are in the loop building software that dynamic will have to be maintained.

We use Loki for logging at work. There’s certain types of queries it just doesn’t support. And so the question becomes -

Do you change logging providers Adapt to Loki’s capabilities Create a third layer / tiered storage.

And each of those decisions have multiple downstream consequences. It’s not that LLMs can’t make those decisions per say, it’s that

What does an LLM do when five different people ask for a system optimized to do five different things.

It could figure it out itself, but like I don’t think that’s how the human software contract works.

Re: Software Engineering fundamentals matter more

#165

Post by ben_w »

asveikau wrote: post #156
ben_w wrote: post #126

Earlier quoted context omitted.

Depends on the business. I can easily see Generic Local Späti being fine to replace a mediocre hand-made spreadsheet of what products they've got in stock with a vibe-coded database that can OCR all the business copy of receipts from the till, while also vibe-coding a website and logo that's far less bad than the thing they got by asking their kid's schoolfriend to make both of them on the cheap in the 2015 summer ho…

> OCR all the business copy of receipts from the till, I would not do this at all. OCR is still very bad. If you want incorrect dollar figures be my guest.

Sure, but I'm not suggesting it's good-good, I'm drawing a comparison with "a mediocre hand-made spreadsheet".

We live in a world where some genes had to be renamed because Excel evaluated their original names as dates, and genetics researchers used Excel anyway. Isn't there at least a reasonable risk of this happening with a random SKU, too?

Re: Software Engineering fundamentals matter more

#166

Post by agumonkey »

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…

I don't think most projects can be as simple as your metaphor points to. Nobody wants to stop at 6 parts single use programs.

Re: Software Engineering fundamentals matter more

#167

Post by crabbone »

LtWorf wrote: post #128
graemep wrote: post #124

Earlier quoted context omitted.

> Most of the "back in the day" furniture came from tearing down virgin woods. Sorting + shredding-recycling + making new "cheap particle board crap" furniture takes a lot of energy, but not a lot of non-renewable resources. It also lasted a lot longer. I have inherited furniture that must be around a 100 years old now and a lot that is over 50 years old and doing fine. A lot of my friends have older (even hundreds o…

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

I moved a lot, and in different countries. I bought different IKEA furniture pieces. There's no one size fits all. IKEA is different by country, by price, by product line... For example, I have a bed I bought from IKEA made of pine wood. Just a few years old, but it shows no signs of wear, and there's no reason for it. On the other hand, I've inherited kitchen countertops and cabinets from the previous owner, and judging by the tags, they've started their second decade sometime this year. It's particle board all the way. The hinges have completely destroyed the nesting in the doors. The doors, literally, fell off. The countertop bent because of weight, temperature, humidity... it's the kitchen after all.

I've been trying to fix these things as the problems appeared, but, really, most people in this situation would probably tear the kitchen down and put the new one up. It's ironic, because we live in a "historic" neighborhood, where the houses have been built in the 18 hundreds and some, perhaps, even 17 hundreds. But absolutely nothing in these houses is more than a decade or two old. They also use materials that superficially resemble the old stuff: plastic panels with wood-like texture, unnecessarily thick aluminum window frames that resemble the old wooden ones (and open in the wrong direction!), plastic shingles that look like ceramics... And everything is made of crap. So much so that the whole neighborhood is perpetually under construction. It's like the Winchester Mystery House that its owners keep building in hopes to stay alive.

Re: Software Engineering fundamentals matter more

#168

Post by slopinthebag »

danielbln wrote: post #26
slopinthebag wrote: post #23

Earlier quoted context omitted.

Where is the reasoning in linear regression?

Where is the reasoning in synaptic transmission?

This is just pure unbridled reductionism. "Show me a single atom in the human body that is 'alive'. You can't? Therefore we're all zombies...."

Reasoning is an emergent property of complex systems. Prediction is not. Thus you cannot claim reasoning drives prediction.

Re: Software Engineering fundamentals matter more

#169

Post by slopinthebag »

anon48293 wrote: post #37
necovek wrote: post #32

Earlier quoted context omitted.

There isn't, which is exactly the point: we do not yet understand the fundamentals behind reasoning.

Don’t we? We can build something which has all the output associated with reasoning. I’d say we’ve figured out the fundamentals behind reasoning.

First of all this isn't true. We cannot yet build something which has all the output associated with reasoning.

But secondary to that, symbols != semantics. If I had a magical machine which could appear from the outside to be reasoning, but upon closer introspection was simply simulating reasoning, by definition it would not be reasoning. And yet that is the criterion you seem to think indicates reasoning ability. So it's not a sufficient criterion.

Claiming we've figured out the fundamentals behind reasoning is hopelessly naive.

Re: Software Engineering fundamentals matter more

#170

Post by slopinthebag »

anon48293 wrote: post #96
chrisjj wrote: post #50

Earlier quoted context omitted.

> We can build something which has all the output associated with reasoning. Sure. A photocopier fed with a maths paper.

I’m willing to bet it still proved more novel mathematical theorems than you did. What does this say about your reasoning?

Excavator can dig a ditch better than I can, thus it must be more capable than me in every physical dimension.
Post reply on HN