Live data from Hacker News

The highest quality codebase

gricha.dev

261–270 of 409 posts

Re: The highest quality codebase

#261

Earlier quoted context omitted.

I think it ultimately comes down to whether you care more about the what, or more about the how. A lot of coders love the craft: making code that is elegant, terse, extensible, maintainable, efficient and/or provably correct, and so on. These are the kind of people who write programming languages, database engines, web frameworks, operating systems, or small but nifty utilities. They don't want to simply solve a prob…

Crafting code can be self-indulgent since most common patterns have been implemented multiple times in multiple languages. A lot of time the craft oriented developer will reject an existing implementation because it doesn't match their sensibilities. There is absolutely a role for craft, however the amount of craft truly needed in modern development is not as large as people would like. There are lots of well crafted…

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.

Re: The highest quality codebase

#262
> We went from around 700 to a whooping 5369 tests

> Tons of tests got added, but some tests that mattered the most (maestro e2e tests that validated the app still works) were forgotten.

I've seen many LLM proponents often cite the number of tests as a positive signal.

This smells, to me, like people who tout lines of code.

When you are counting tests in the thousands I think its a negative signal.

You should be writing property based tests rather than 'assert x=1', 'assert x=2', 'assert x=-1' and on and on.

If LLMs are incapable of acknowledging that then add it to the long list of 'failure modes'.

Re: The highest quality codebase

#263

Earlier quoted context omitted.

but do you solve the problem if you just slap a prompt and iterate while the LLM gathers diffs ?

If the client is happy, the code is well-formed, and it solves their problem is a cost-effective manner, what is not to like?

cause the 'dev' didn't solve anything

ultimately i wonder how long people will need devs at all if you can all prompt your wishes

some will be kept to fix the occasional hallucination and that's it

Re: The highest quality codebase

#264
post #201

Earlier quoted context omitted.

Some people are into designing software, others like to put the design into implementation, others like cleaning up implementations yet others like making functional software faster. There is enough work for all of us to be handsomely paid while having fun doing it :) Just find what you like, and work with others who like other stuff, and you'll get through even the worst of problems. For me the fun comes not from th…

I've found that good tab AI-based tab completion is the sweet spot for me. I am still writing code, but I don't have to type all of it if it's obvious.

This has been my approach, as well. I've got a neovim setup where I can 1) open up a new buffer, ask a question, and then copy/paste from it and 2) prompt the remainder of the line, function, or class. (the latter two are commands I run, rather than keybinds).

Re: The highest quality codebase

#265

Earlier quoted context omitted.

Notetaking with ADHD is another sort of hell to be honest. I absolutely can attest to what parent is saying, I have been developing software in Python for nearly a decade now and I still routinely look up the /basics/. LLM's have been a complete gamechanger to me, being able to reduce the friction of "ok let me google what I need in a very roundabout way my memory spit it out" to a fast and often inline llm lookup.

Looking up documentation is normal. If not, we wouldn't have the manual pages in Unix and such an emphasis on documentation in ecosystems like Lisp, Go, Python, Perl,... We even have cheatsheets and syntax references books because it's just so easy to forget the /basics/. I said notetaking, but it's more about building your own index. In $WORK projects, I mostly use the browser bookmarks, the ticket system, the PR de…

It is very hard to explain the extent of it to a person who did not experience it, really.

I have over a decade of experience, I do this stuff daily, I don't think I can write a 10 line bash/python/js script without looking up the docs at least a couple times.

I understand exactly what I need to write, but exact form eludes my brain, so this Levenshtein-distance-on-drugs machine that can parse my rambling + surrounding context into valid syntax for what I need right at that time is invaluable and I would even go as far as saying life changing.

I understand and hold high level concepts alright, I know where stuff is in my codebase, I understand how it all works down to very low levels, but the minutea of development is very hard due to how my memory works (and has always worked).

Re: The highest quality codebase

#266
post #53

Earlier quoted context omitted.

Oh I’ve had agents remove tests plenty of times. Or cripple the tests so they pass but are useless - more common and harder to prompt against.

Ah true, that also can happen — in aggregate I think models will tend to expand codebases versus contract. Though, this is anecdotal and probably is something ai labs and coding agent companies are looking at now.

It’s the same bias for action which makes them code up a change when you genuinely are just asking a question about something. They really want to write code.

Re: The highest quality codebase

#267
post #246

Earlier quoted context omitted.

but do you solve the problem if you just slap a prompt and iterate while the LLM gathers diffs ?

Depends what the problem is. Sometimes you can, sometimes you have to break the problem apart and get the LLM to do each bit separately, sometimes the LLM goes funny and you need to solve it yourself. Customers don't want you wasting money doing by hand what can be automated, nor do they want you ripping them off by blindly handing over unchecked LLM output when it can't be automated.

there are other ways: being scammed by lazy devs using AI to produce what devs normally do and not saving any money for the customer. i mentioned it in another thread, i heard first hand people say "i will never report how much time savings i get from gemini, at best i'll say 1 day a month"

Re: The highest quality codebase

#268
post #108

Earlier quoted context omitted.

Why is that a developer's problem? If anything, they are incentivized to avoid creating future competition in the job market.

It's not a problem for the senior dev directly, but maybe down the road. And it definitely is a problem for the company once said senior dev leaves or retires. Seriously, long term thinking went out the window long time ago, didn't it?

No, long term thinking didn't go out the window.

It is definitely a problem for the company. How is it a problem for the senior dev at any point?

What incentive do they have to aid the company at the expense of their own *long term* career prospects?

Re: The highest quality codebase

#269
I would love to see an experiment done like this with an arena of principal engineer agents. Give each of them a unique personality: this one likes shiny new objects and is willing to deal with early adopter pain, this one is a neckbeard who uses emacs as pid 1 and sends email via usb thumbdrive, and the third is a pragmatic middle of the road person who can help be the glue between them. All decisions need to reach a quorum before continuing. Better yet: each agent is running on a completely different model from a different provider. 3 can be a knob you dial up to 5, 10, etc. Each of these agents can spawn sub-agents, to reach out to professionals like a CSS export, or a DBA.

I think prompt engineering could help here a bit, adding some context on what a quality codebase is, remove everything that is not necessary, consider future maintainability (20->84k lines is a smell). All of these are smells that like a simple supervisor agent could have caught.

Re: The highest quality codebase

#270

On the Result responses... I've seen this a few times. I think it works well in Rust or other languages that don't have the ability to "throw" baked in. However, when you bolt it on to a language that implicitly can throw, you're now doing twice the work as you have to handle the explicit error result and integrated errors. I worked in a C# codebase with Result responses all over the place, and it just really complic…

The Result pattern also works exceptionally well with C#, provided you ensure that code returning a Result object never throws an exception. Of course, there are still some exceptional things that can throw, but this is essentially the same situation as dealing with Rust panics.

IMO, Rust panics should kill the application... C# errors shouldn't. Also, in practice, in C# where I was dealing with Result, there was just as much chance of seeing an actual thrown error, so you always had to deal with both an explicit error result AND thrown errors in practice... it was worse than just error patterns with type specific catch blocks.
Post reply on HN