Hacker News Reader

Comment by magic_hamster | Hacker News Reader

It's how much it would cost to produce the text files in your code. I think that most software engineers will agree that writing the code is the easiest part of the job. The hard parts are figuring out the problem, figuring out your data modeling, what is going to work and what it would cost, considering tradeoffs in speed, scalability, maintainability, etc. And, you know, getting the thing to actually run.

There's no doubt that AI is going to be a huge factor in coding. But we will have to change a lot of things for it to outright replace humans. I'm sure some people are already working on those changes...

View on HN

The hardest part is supporting the platform for 7~10 years. With those lifetimes, writing code is like 5% of the effort, the rest is supporting it for years and handling all the nasty bugs that show up when thousands of engineers pound on it 24/7. They don't teach you about that in college, and I wish they did, but I doubt anyone would take a class on how to support software even though it's the most important part.

I’ve got code barely touched in 15 years still in day to day production use.

Isn’t it nice when requirements don’t change! :)

Let’s see how it does when it’s constantly worked on to add new features, etc.

And every few months someone wants to switch to a new framework or module for one specific reason and then the codebase is riddled with 10 different ways to do the same thing.

Features are the problem.

Stop adding features.

Make packages as best you can, such that, If you really want something added on, it's a separate package to add on.

That is a maintenance nightmare

Why would it need new features. It was written to solve a business problem. The problem is still there, the solution still works.

I'm jealous. I'm sure there are lots of codebases where "write once and forget about it" is the lifecycle...

I’ll add that 7-10 years is rather on the short side compared to the systems I’ve been involved with in my career. 20 years isn’t that rare, and the more interesting challenges tend to happen after the 10-year mark.

It’s really only important to the companies that can afford to teach it. If you’ve got a product that’s lasting to stick around for 10 years - it’s probably a cash cow. You can afford to teach engineers at that point.

For a lot of the companies out there that are just trying to get off the ground - all this talk of supporting the system long term is irrelevant outside of major system crashes or whatnot.

Even all that, difficult though it is, doesn't include the cost if understanding the actual problem, knowing the field well enough to propose a good solution, and coordinating and communicating with everyone the whole way through.

"Every problem is a people problem", and people-solutions are something that AI still doesn't solve.

I'm not saying that AI doesn't have it's uses, it certainly does, but I'm trying to highlight that purely technical solutions very often aren't good solutions to a lot if real-world problems.

When AI truly becomes helpful in the workplace developer jobs will probably change a lot but I think the biggest change will be in the size of the business scope. Most projects I've worked in could easily grow ten times if developers were ten times as efficient.

At the same time I've always wondered why IT problems haven't all been solved comprehensively already because so many problems seem so similar.

I can't really fit those two narratives together.

All IT problems are 90% similar... it's the last 10% difference that is 9000% of the work!

I think part of the problem is human networking limitations. I can learn to code very well and can become a core contributor on a project. The problem is my understanding doesn't scale well. If I get hit by a bus tomorrow that project could die. I could leave the project and it could flounder. Now, lets say you add 3 people as good as me on that project... the problem is the project will grow 4 times as large leading to every one of us becoming a critical failing point. Any time you want to bring a new core contributor in, it's a massive undertaking of time and effort to get them up to speed.

Yeah this rhymes with my experience. AI could perhaps turn this dynamic on its head if we let it into all the code bases. Now it can perhaps explain the background for all the nooks and crannies in the code. It could chip into any discussion in the corporate or community environment to tell you why another team has designed the way they've done. It can potentially act as a mediator to make a more cohesive whole.

But that all also kind of sounds a bit scary. It has to be built in a way that inspires trust.

> But we will have to change a lot of things for it to outright replace humans

Like having AI in the first place. I still haven’t seen any example generated by GPT that is not a naive translation (perhaps between languages) of some code already in its training set in one way or another. Which is a cool thing, we get a much more intelligent (though factually less punctual) search engine for code! But we are very far from it replacing any programmer worth their weight.

Everyone is freaking out about AI writing “common code” yet we have reusable code in the form of libraries for decades - and now frameworks. You will never have to write code that does what the library does ever again.

The hard part of software engineering should be figuring out the problem, tradeoffs, etc.

But the reality is this field has multiple completely different groups of people calling themselves software engineers.

There's those who basically work at consultancies/shops that get paid to push out tons of client projects using a standardized approach and their job is to write a bunch of code. Or those that work on in-house systems that get paid to largely implement pre-scoped work.

Then there's those that are actually designing systems, improving them, iterating on them, etc. You know, actually "engineering".

The fact that coding itself is fairly easy and the proliferation of bootcamps that teach coding (and now ChatGPT) has flooded the market with individuals that know nothing of good software engineering practices let alone CS and systems fundamentals.

I expect that's the group most exposed to AI risk. Pumping out lots of shitty self-contained code is something LLMs excel at.

I could imagine an LLM that brainstorms all the edge cases, data modelling, algorithm, etc... The final decision will still have to be done by a human, but having a companion LLM that gives you ideas, plays devils advocate and looks for problems would definitely speed up the decision process.

Unless it leads you astray and that costs more time than coming up with the code on your own in the first place.

Wait, sounds like you've rolled out SAP before, I'd love to pick your brain for tips other than "don't".

> don't

Just don't

A 'Tree of thoughts' if you will...

Yeah, but then you need the knowledge, experience, and decision making to act on that feedback. LLMs are also notoriously bad at things like edge cases, etc. and more training data won't necessarily help.

The hard part is figuring out other peoples code.

This… is not what people would have said 10 years ago. Remember the idea of the 10x developer? Even at a design heavy firm, 80% of engineers despise writing the design docs.

Reply on news.ycombinator.com