Live data from Hacker News

They lied to you. Building software is hard

blog.nordcraft.com

91–100 of 119 posts

Re: They lied to you. Building software is hard

#91
post #48

One of my all-time favorite quotes is from Zen Mind, Beginner's Mind and it goes: “In the beginner’s mind there are many possibilities, but in the expert’s there are few.” There's such a wide divergence of experience with these tools. Often times people will say that anyone finding incredible value in them must not be very good. Or that they fall down when you get deep enough into a project. I think the reality is th…

This reminds of talking to my nephew at Thanksgiving years ago. He was studying for an exam after the holidays and I was looking at his screen open to a Google Doc which looked like his study notes except - they were being edited as I was watching - by someone else. I asked about it and he goes “we have a single Google Doc where all students collaborate on the study notes.” My mind was blown, I was also using Google…

All students collaborating on notes kind of defeats the point no? As I see it study notes are reminders to link you back to when you were reviewing the material. If you never wrote the notes you wont get that connection back to the material.

Re: They lied to you. Building software is hard

#92

LLMs have clearly accelerated development for the most skilled developers. Particularly when the human acts as the router/architect. However, I've found Claude Code and Co only really work well for bootstrapping projects. If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. It will probably change once the appro…

> We ultimately need optimized DSLs and aggressive use of stateless sub-modules/abstractions that can be implemented in isolation to minimize the amount of context required for any one LLM invocation

Wait till you find out about programming languages and libraries!

> It will probably change once the approach to large scale design gets more formalized and structured

This idea has played out many times over the course of programming history. Unfortunately, reality doesn’t mesh with our attempts to generalize.

Re: They lied to you. Building software is hard

#93
post #49
post #22

Earlier quoted context omitted.

I'm not sure. Think of the Game hits from the 90's. A room full of people made games which shaped a generation. Maybe it was orders of magnitude harder then, but today, it's multiple orders of magnitude more people required to make them. Same is true for websites. Sure, the websites were dingy with poor UX and oodles of bugs... but the size of the team required to make them was absolutely tiny compared to today. Thin…

Copying a game from the 90s is easier than ever. We see small teams making 90s level games all the time. It just happens that in the market, those are now just indies. The market demands not just better, more complicated games, but mostly much higher art budgets. Go look at, say, Super Metroid, and compare it to Team Cherry's games in the same genre, made mostly by three people. Compare Harvest Moon from the 90s with…

I wonder if the gaming market is actually demanding more complicated games, or if it's just that complicated games with massive budgets are all the studios are offering, so gamers accept what they're offered.

Re: They lied to you. Building software is hard

#94

Anything (software or physical things) that is fast, easy, and cheap to build; will never be a financial success for a single company. The minute you get some market traction, your competitors will come in and take away all your customers.

If you were given a copy of the entire software stack that runs YouTube I would bet $1000000 you can't take all of YouTube's customers. Businesses are more than just the software.

Are you saying that you think that YouTube was fast, easy, and cheap to build?

Re: They lied to you. Building software is hard

#95
years ago I watched a very senior engineer refuse to use an IDE debugger because “real understanding means doing it in your head.” He was brilliant - and also spent two days chasing a bug a junior fixed in 10 minutes by setting a breakpoint. The junior didn’t understand more; he just had a better tool for that moment.

Tools don’t make you wiser or lazier by default — they amplify whatever habits you already have. If you’re using them to avoid thinking, that shows. If you’re using them to explore faster, that shows too.

Beginner’s mind isn’t about ignorance; it’s about being willing to try leverage where it exists.

Re: They lied to you. Building software is hard

#96

Earlier quoted context omitted.

>If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. Worse, as its planning the next change, it's reading all this bad code that it wrote before, but now that bad code is blessed input . It writes more of it, and instructions to use a better approach are outweighed by the "evidence". Also, it's not tech debt: h…

People can take on debt for all sorts of things. To go on vacation, to gamble. Debt doesn't imply it's productively borrowed or intelligently used. Or even knowingly accrued. So given that the term technical debt has historically been used, it seems the most appropriate descriptor. If you write a large amount of terrible code and end up with a money producing product, you owe that debt back. It will hinder your busin…

All those examples were borrowing money. What you're describing as "technical debt" doesn't involve borrowing anything. The equivalent for a vacation would be to take your kids to a motel with a pool and dress up as Mickey Mouse and tell them its "Disney World debt". You didn't go in debt. You didn't go to Disney World. You just spent what money you do have on a shit solution. Your kids quite possibly had fun, even.

> term technical debt has historically been used

There are plenty of terms that we no longer use because they cause harm.

Re: They lied to you. Building software is hard

#97
post #49
post #22

Earlier quoted context omitted.

I'm not sure. Think of the Game hits from the 90's. A room full of people made games which shaped a generation. Maybe it was orders of magnitude harder then, but today, it's multiple orders of magnitude more people required to make them. Same is true for websites. Sure, the websites were dingy with poor UX and oodles of bugs... but the size of the team required to make them was absolutely tiny compared to today. Thin…

Copying a game from the 90s is easier than ever. We see small teams making 90s level games all the time. It just happens that in the market, those are now just indies. The market demands not just better, more complicated games, but mostly much higher art budgets. Go look at, say, Super Metroid, and compare it to Team Cherry's games in the same genre, made mostly by three people. Compare Harvest Moon from the 90s with…

I think you're ignoring multiple critical variables, including what the parent mentioned.

A pretty obvious one is that there's magnitudes more players these days and many more options for how they can play. Hell, there's even a few more billion people on the planet so it's more than just percentage of people owning systems that can play games. I'll let you think about others because I want to focus on what the patent said, but if top selling games weren't making at least an order of magnitude more money then that'd be a very concerning sign.

The parent said hardware was a big unlock and this is undoubtedly true. I don't just mean that with better hardware we can do more and I don't think the parent did either. Hardware is an unlock because it enables you to be incredibly lazy. If your players have powerful hardware you can get away with thinking less about optimization. You can get away with thinking less about memory management. You can get away with thinking less about file sizes.

The hardware inherently makes game development easier. We all know the quake fast inverse square root for a reason. Game development used to be famous for optimization for a reason. It was absolutely necessary. Many old games are famous for pushing the limits of the hardware. Where hardware was the major bottleneck.

But then look at things like you mentioned. Undertail is also famous for its poor code quality. All the dialogue in a single file using a bunch of switch statements? It's absurd!

But this is both a great thing and a terrible thing. It's great because it unlocks the door for so many to share their stories and games. But it's terrible because it wastes money, money that the consumer pays. It encourages a "good enough" attitude, where the bar keeps decreasing and faster than hardware can keep up. It is lazy and hurts consumers. It makes a naïve assumption that there's only one program running on a system at a time.

It's an attitude not limited to the game industry. We ship minimal viable products. The minimum moves, and not always up. It goes down when hardware can pick up the slack or when consumers just don't know any better.

Things like electron are great, since they can enable developers to get going faster. But at the same time it creates massive technical debt. The fact that billion dollar companies use a resource hog like that is not something to be proud of, it should be mocked and shamed. Needing a fucking browser to chat or listen to music?! It's nothing short of absurd! Consumers don't know any better but why devs celebrate this is beyond me.

People should move fast and break things. It's a good way to innovate and figure out how things work. But it has a cost. It leaves a bunch of broken stuff in its wake. Someone has to deal with that trash. I don't care much about the startup breaking some things but I sure do care when it's the most profitable businesses on the planet. They can pay for their messes. They create bigger messes. FFS, how does a company like Microsoft solve slow file browsers by just starting it early and running in the background?! These companies do half a dozen rounds of interviews and claim they have the best programmers? I call bullshit.

Re: They lied to you. Building software is hard

#98
post #90
post #48

One of my all-time favorite quotes is from Zen Mind, Beginner's Mind and it goes: “In the beginner’s mind there are many possibilities, but in the expert’s there are few.” There's such a wide divergence of experience with these tools. Often times people will say that anyone finding incredible value in them must not be very good. Or that they fall down when you get deep enough into a project. I think the reality is th…

Over the last 25 years of building commercial software, but being a programming enthusiast since I was 15 years old, I came to the conclusion that self-improvement (in the sense of gaining real expertise in a field, building a philosophy of things, and doing the right things) is in direct opposition to creating "value" in the corporate/commercial sense of today. Using AI/LLMs, you perhaps will create more commercial…

Why are you so certain that LLMs/AI can't be used as a tool to learn and grow?

Like Herbie Hancock once said, a computer is a tool, like an axe. It can be used for terrible things, or it can be used to build a house for your neighbor.

It's up to people how we choose to use these tools.

Re: They lied to you. Building software is hard

#99

LLMs have clearly accelerated development for the most skilled developers. Particularly when the human acts as the router/architect. However, I've found Claude Code and Co only really work well for bootstrapping projects. If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use. It will probably change once the appro…

Agreed.

What I've found is that AI can be alright at creating a Proof of Concept for an app idea, and it's great as a Super Auto-complete, but anything with a modicum of complexity, it simply can't handle.

When your code is hundreds of thousands of lines, asking an agent to fix a bug or implement a feature based on a description of the behavior just doesn't work. The AI doesn't work on call graphs, it basically just greps for strings it thinks might be relevant to find things. If you know exactly where the bug lies, it can usually find it with context given to it, but at that point, you're just as good fixing the bug yourself rather than having the AI do it.

The problem is that you have non-coders creating a PoC, then screaming from the rooftops how amazing AI is and showing off what it's done, but then they go quiet as the realization sets in that they can't get the AI to flesh it out into a viable product. Alternatively, they DO create a product that people start paying to use, and then they get hacked because the code is horribly insecure and hard-codes API keys.

Re: They lied to you. Building software is hard

#100

Earlier quoted context omitted.

If you were given a copy of the entire software stack that runs YouTube I would bet $1000000 you can't take all of YouTube's customers. Businesses are more than just the software.

Are you saying that you think that YouTube was fast, easy, and cheap to build?

As AI progresses it will be. What makes YouTube valuable is the company's relationship with advertisers, content creators, and users.
Post reply on HN