Live data from Hacker News

The highest quality codebase

gricha.dev

281–290 of 409 posts

Re: The highest quality codebase

#281
post #254

Earlier quoted context omitted.

I believe wage work has a significant factor in all this. Most are not paid for results, they're paid for time at desk and regular responsibilities such as making commits, delivering status updates, code reviews, etc. - the daily activities of work are monitored more closely than the output. Most ESOP grant such little equity that working harder could never observably drive an increase in its value. Getting a project…

> Naturally workers will begin to prefer the motions of the work they find satisfying more than the result it has for the business's bottom line, from which they're alienated. Wow. I've read a lot of hacker news this past decade, but I've never seen this articulated so well before. You really lifted the veil for me here. I see this everywhere, people thinking the work is the point, but I haven't been able to crystall…

Marx had a lot of good ideas, though you wouldn't know it by listening to capitalist-controlled institutions.

https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation

Re: The highest quality codebase

#282
post #237

Earlier quoted context omitted.

The impact is that now, if you want to modify the project in some way, you will need to learn Go. It's like all the codebases in COBOL. Maybe COBOL at that time was the best language for the product, but now, it's not that easy to find someone with the knowledge to maintain the system. As soon as you make a choice, you accept that further down the line, there will be some X cost to keep going in that direction and so…

> The impact is that now, if you want to modify the project in some way, you will need to learn Go. That's tautologically true, yes, but your claim was > Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain. So, assuming the domain of infrastructure-at-code is mostly known now which is a fair statement -- which i…

> So, assuming the domain of infrastructure-as-code is mostly known now which is a fair statement -- which is a better choice, Go or Rust, and why? Remember, this is objective fact, not art, so no personal preferences are allowed.

I think it’s possible to engage with questions like these head on and try to find an answer.

The problem is that if you want the answer to be close to accurate, you might need both a lot of input data about the situation (including who’d be working with and maintaining the software, what are their skills and weaknesses; alongside the business concerns that impact the timeline, the scale at which you’re working with and a 1000 other things), as well as the output of concrete suggestions might be a flowchart so big it’d make people question their sanity.

It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation.

But to humor the question: as an example, if you have a small to mid size team with run of the mill devs that have some traditional OOP experience and have a small to mid infrastructure size and complexity, but also have relatively strict deadlines, limited budget and only average requirements in regards to long term maintainability and correctness (nobody will die if the software doesn’t work correctly every single time), then Go will be closer to an optimal choice.

I know that because I built an environment management solution in Go, trying to do that in Rust in the same set of circumstances wouldn’t have been successful, objectively speaking. I just straight up wouldn’t have iterated fast enough to ship. Of course, I can only give such a concrete answer for that very specific set of example circumstances after the fact. But even initially those factors pushed me towards Go.

If you pull any number of levers in a different direction (higher correctness requirements, higher performance requirements, different team composition), then all of those can influence the outcome towards Rust. Obviously every detail about what a specific system must do also influences that.

Re: The highest quality codebase

#283
post #273

Earlier quoted context omitted.

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…

I’ve linked this before, but I feel like this might resonate with you: https://www.stilldrinking.org/programming-sucks

I enjoyed that but honestly it kind of doesn't really resonate. Because it's like "This stuff is really complicated and nobody knows how anything works etc and that's why everything is shit".

I'm talking about simple stuff that people just can't do right. Not complex stuff. Like imagine some perfect little example code on the react docs or whatever, good code. Exemplary code. Trivial code that does a simple little thing. Now imagine some idiot wrote code to do exactly the same thing but made it 8 times longer and incredibly convoluted for absolutely no reason and that's basically what most "developers" do. Everyone's a bunch of stupid amateurs who can't do simple stuff right, that's my problem. It's not understandable, it's not justifiable, it's not trading off quality for speed. It's stupidity, ignorance and lazyness.

That's why we have coding interviews that are basically "write fizzbuzz while we watch" and when I solve their trivial task easily everyone acts like I'm Jesus because most of my peers can't fucking code. Like literally I have colleagues with years of experience who are barely at a first year CS level. They don't know the basics of the language they've been working with for years. They're amateurs.

Re: The highest quality codebase

#284
post #273

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…

I can guarantee you that if you were to write a completely new program and continued to work on it for more than 5 years, you'd feel the same things about your own code eventually. It's just unavoidable at some point. The only thing left then is degrees badness. And nothing is more humbling than realizing that the only person that got you there is yourself.

Re: The highest quality codebase

#286

Earlier quoted context omitted.

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 + surroundi…

What I'm saying is that is normal. Unless you've worked everyday with the same language and a very small set of functions, you're bound to forget signature and syntax. What I'm advocating is a faster retrieval of the correct information.

Re: The highest quality codebase

#288
post #283

Earlier quoted context omitted.

I’ve linked this before, but I feel like this might resonate with you: https://www.stilldrinking.org/programming-sucks

I enjoyed that but honestly it kind of doesn't really resonate. Because it's like "This stuff is really complicated and nobody knows how anything works etc and that's why everything is shit". I'm talking about simple stuff that people just can't do right. Not complex stuff. Like imagine some perfect little example code on the react docs or whatever, good code. Exemplary code. Trivial code that does a simple little th…

Then it’s quite possible that you’re working in an environment that naturally leads to people like that getting hired. If that’s something you see repeatedly, then the environment isn’t a good fit for you and you aren’t a good fit for it. So you’d be better served by finding a place where the standards are as high as you want, from the very first moment in the hiring process.

For example, Oxide Computers has a really interesting approach https://oxide.computer/careers

Obviously that’s easier said than done but there are quite a few orgs out there like that. If everyone around you doesn’t care about something or can’t do it, it’s probably a systemic problem with the environment.

Re: The highest quality codebase

#289
post #173

Earlier quoted context omitted.

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 like this framing; I think it captures some of the key differences between engineers who are instinctively enthusiastic about AI and those who are not. Many engineers walk a path where they start out very focussed on programming details, language choice, and elegant or clever solutions. But if you're in the game long enough, and especially if you're working in medium-to-large engineering orgs on big customer-facing…

I'm guessing, but I'm pretty sure you're dealing with big balls of mud which has dampened your love of coding. Where implementing something is more about solving accidental complexity and dealing with technical debts than actually doing the job.

Re: The highest quality codebase

#290

Earlier quoted context omitted.

Maybe I'm weird but I enjoy "actually writing the code."

You really get enjoyment writing a full CRUD HTTP API five times, one for each endpoint? I don't :) Before I had IDE templates and Intellisense. Now I can just get any agentic AI to do it for me in 60 seconds and I can get to the actual work.

Why do you need a full crud http api for? Just loading the data straight from the database? Usually I've already implemented that before and I just copy paste the implementation and doing some VIM magic. And in Frameworks like Rails or Laravel, it may be less than 10 lines of code. More involved business logic? Then I'm spending more time getting a good spec for those than implementing the spec.
Post reply on HN