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

The highest quality codebase

gricha.dev

Post reply on HN
Print view View original

371–380 of 409 posts

Re: The highest quality codebase

#371

Post by lucideer »

xnorswap wrote: post #18

Claude is really good at specific analysis, but really terrible at open-ended problems. "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. "Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest. It suggested enthusiastically a library for and it was all " Recommended " about it, but when I pointed out that the…

> There's a significant blind-spot in current LLMs related to blue-sky thinking and creative problem solving

I'd hesitate to call this a blind spot. LLMs have a lot of actual blind spots - things people developing them overlook or deprioritize. This strikes me more as something acutely aware of & failing at, despite significant efforts to solve.

Re: The highest quality codebase

#372

Post by skydhash »

Dylan16807 wrote: post #363
skydhash wrote: post #360

Earlier quoted context omitted.

And I’ve already answered that question. One of the main impact is that if you want a contributor to the codebase, the person have to learn Go. Even if they have good knowledge of the domain and are proficient in Rust. There would be some cost associated to training that person in Go (it may be small). Rewriting from Go to another language wouldn’t solve the problem better. Because Go is an implementation choice, not…

> And I’ve already answered that question. You somewhat answered it in a way that doesn't really get to why they asked it (you can't make every decision based on "demonstrated impact"). But you did that in a different comment than the one I replied to. The one I replied to was just answering the wrong question entirely. Which is why I replied. > Rewriting from Go to another language wouldn’t solve the problem better.…

> I'm sorry, are you arguing that using feel to decide how to structure a piece of code is a "huge red flag", but the choice of entire programming language is unimportant?

From my first reply, I've been arguing that using feels to decide things is very much dangerous. There are usually a less ambiguous way to frame the reasons behind a decision. Methodologies like the five why's can help.

And choosing a programming language is orthogonal to designing a solution to a problem. Everything get turned to opcodes and binary at some point.

Re: The highest quality codebase

#373

Post by skydhash »

KronisLV wrote: post #347
manmal wrote: post #344

Earlier quoted context omitted.

Yeah a bridge has a plan that it’s built and verified against. It’s the picture book waterfall implementation. The software industry has moved away from this approach because software is not like bridges.

> It’s the picture book waterfall implementation. One of my better experiences with software development was actually with something waterfall-adjacent. The people I was developing software for produced a 50 page spec ahead of any code being written. That let me get a complete picture of the business domain. That let me point out parts of the spec that were just wrong in regards to the domain model and also things th…

If you can't get a complete spec, it's better start with something small that you can get detailed info on, and then iterate upon that. It will involve refactoring, but that is better than badly designing the whole thing from the get go.

Re: The highest quality codebase

#374

Post by skydhash »

keeda wrote: post #317
altmanaltman wrote: post #310

Earlier quoted context omitted.

Honestly, I fundamentally disagree with this. Figuring out "what to prompt" is not problem-solving in a true sense imo. And if you're really going too deep into the problem domain, what is the point of having the code abstracted? My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out o…

> My comment was based on you saying you don't care about the code and only what it does. But now you're saying you care about the code and review everything so I'm not sure what to make out of it. I'm not the person you originally replied to, so my take is different, which explains your confusion :-) However I do increasingly get the niggling sense I'm reviewing code out of habit rather than any specific benefit bec…

What people are wary of is not solving the problem in the first pass. They are wary of technical debt and unmaintainable code. The cost of change can be enormous. Software engineering is mostly about solving current problems and laying the foundation to adapt for future ones at the same time. Your approach's only focus is current problems which is pretty much the same as people that copypaste from StackOverflow without understanding.

Re: The highest quality codebase

#375

Post by BatteryMountain »

xnorswap wrote: post #18

Claude is really good at specific analysis, but really terrible at open-ended problems. "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. "Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest. It suggested enthusiastically a library for and it was all " Recommended " about it, but when I pointed out that the…

It works great in C# (where you have strong typing + strict compiler).

Try this:

Have a look at xyz.cs. Do a full audit of the file and look for any database operations in loops that can be pre-filtered.

Or:

Have a look at folder /folderX/ and add .AsNoTracking() to all read-only database queries. When you are done, run the compiler and fix the errors. Only modify files in /folderX/ and do not go deeper in the call hierarchy. Once you are done, do a full audit of each file and make sure you did not accidentally added .AsNoTracking() to tracked entities. Do no create any new files or make backups, I already created a git branch for you. Do not make any git commits.

Or:

Have a look at the /Controllers/ folder. Do a full audit of each controller file and make sure there are no hard-coded credentials, username, password or tokens.

Or: Have a look at folder /folderX/. Find any repeated hard-coded values, magic values and literals that will make good candidates to extract to Constants.cs. Make sure to add XML comments to the Constants.cs file to document what the value is for. You may create classes within Constants.cs to better group certain values, like AccountingConstants or SystemConstants etc.

These kinds of tasks works amazing in claude code an can often be one shotted. Make sure you check your git diffs - you cannot and should not blame AI for shitty code - its your name next to the commit, make sure it is correct. You can even ask claude to review the file with you afterwards. I've used this kind of approach to greatly increase our overall code quality & performance tuning - I really don't understand all the negative comments as this approach has chopped down days worth of refactorings to a couple of minutes and hours.

In places where you see your coding assistant is slow or making mistakes or it is going line by line where you know a simple regex find/replace would work instantly, ask it to help you create a shell script as a tool for itself to call, that does task xyz that it can call. I've made a couple of scripts that uses this approach that Claude can call locally to fix certain code pattern in 5 seconds that would've taken it (and me checking it) 30 mins at least and it wont eat up context or tokens.

Re: The highest quality codebase

#376

Post by sandos »

airstrike wrote: post #211
SketchySeaBeast wrote: post #126

Earlier quoted context omitted.

I'm not sure how to interpret someone saying they don't follow DRY. Do you meant taking it to the Zealous extreme, or do you abhor helper functions? Is this a "No True Scottsman" thing?

I just think DRY is overblown. I just let code grow. When parts of it become obvious to abstract, I refactor them into something self contained. I learned this from an ice wizard. When I was younger, writing Python rather than Rust, I used to go out of my way to make everything DRY, DRY, DRY everywhere from the outset. Class-based views in Django come to mind. Today, I just write code, and after it's working I go bac…

I feel very strongly after 20+ years of development that DRY is a good guideline, but I have also seen many, many times that trying to follow it to the letter is actually detrimental and results in too complex solutions.

Re: The highest quality codebase

#377

Post by RHSeeger »

Nemi wrote: post #173
n4r9 wrote: post #54

Earlier quoted context omitted.

I think we have different opinions on what's fun and what's boring!

You've really hit the crux of the problem and why so many people have differing opinions about AI coding. I also find coding more fun with AI. The reason is that my main goal is to solve a problem, or someone else's problem, in a way that is satisfying. I don't much care about the code itself anymore. I care about the thing that it does when it's done. Having said that I used to be deep into coding and back then I am…

> I don't much care about the code itself anymore.

I use writing the code as a way to investigate the options and find new ones. By the time I'm sure of the correct way to implement something, half the code is written [1]. At that point, now that I know what and how I'm going to do, it starts to get boring. I think what would work best for me would be able to say "ok, now finish this" to the AI and have it do that boring part.

[1] This also makes my LOEs horrible, because I don't know what I'm going to build until I've completed half of it. And figuring out how long it will take to do something that isn't defined is... inaccurate.

Re: The highest quality codebase

#378

Post by [deleted] »

sfn42 wrote: post #273
breuleux wrote: post #261

Earlier quoted context omitted.

As someone who does that a lot... I agree. Self-indulgent is the word. It just feels great when the implementation is a perfect fit for your brain, but sometimes that's just not a good use of your time. Sometimes, you strike gold, so there's that.

I kind of struggle with this. I basically hate everyone elses code, and by that I mean I hate most people's code. A lot of people write awesome code but most people write what I'd call trash code. And I do think there's more to it than preference. Like there's actual bugs in the code, it's confusing and because it's confusing there's more bugs. It's solving a simple problem but doing so in an unnecessarily convoluted…

[deleted]

Re: The highest quality codebase

#380

Post by traceroute66 »

pdntspa wrote: post #43
xnorswap wrote: post #18

Claude is really good at specific analysis, but really terrible at open-ended problems. "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. "Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest. It suggested enthusiastically a library for and it was all " Recommended " about it, but when I pointed out that the…

That's why you treat it like a junior dev. You do the fun stuff of supervising the product, overseeing design and implementation, breaking up the work, and reviewing the outputs. It does the boring stuff of actually writing the code. I am phenomenally productive this way, I am happier at my job, and its quality of work is extremely high as long as I occasionally have it stop and self-review it's progress against the…

I don't follow.

In the same breath (same paragraph) you state two polar opposites about working with AI:

   - I am phenomenally productive
   - "as long as I occasionally have it stop" and "it tends to forget a lot of rules like DRY"
I don't see how you can claim to be "phenomenally productive" when working with a tool you have to babysit because it forgets your instructions the whole time.

If it was the "junior dev" you also mention, I suspect you would very quickly invite the "junior dev" to find a job elsewhere.

Post reply on HN