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

341–350 of 409 posts

Re: The highest quality codebase

#341

Post by mrsmrtss »

tracker1 wrote: post #270
mrsmrtss wrote: post #204

Earlier quoted context omitted.

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.

I think you just had experienced a bad codebase. If you opt for using Result then you can not throw at the same time. If you follow this rule, then it works perfectly.

Re: The highest quality codebase

#342

Post by jffhn »

gmueckl wrote: post #284
sfn42 wrote: 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 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.

I can guarantee you that I have been doing just that for 20 years, creating and working on the same codebase, and that it only got better with time (cleaner code and more robust execution), though more complex because the domain itself did. We would have been stuck in the accidental complexity of messy hacks and their buggy side effects if we had not continuously adapted and improved things.

Re: The highest quality codebase

#343

Post by [deleted] »

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…

[deleted]

Re: The highest quality codebase

#344

Post by manmal »

KronisLV wrote: post #278
sfn42 wrote: 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

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.

Re: The highest quality codebase

#345

Post by sfn42 »

gmueckl wrote: post #284
sfn42 wrote: 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 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.

No, I wouldn't. I have been working for years on the same codebase, it's not that hard to keep it clean and simple. I just refactor/redesign when necessary instead of adding hacky workarounds on top of hacky workarounds for years until the codebase is nothing but a collection of workarounds.

And most importantly I just design it well from the start, it's not that hard to do. At least for me.

Of course we all make mistake, there's bugs in my code too. I have made choices I regret. But not on the level that I'm talking about.

Re: The highest quality codebase

#346

Post by KronisLV »

Dylan16807 wrote: post #338
KronisLV wrote: post #282

Earlier quoted context omitted.

> 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 o…

> It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation. If it's impractical to know, why is using personal preference and intuition a "huge red flag"? That's the core idea being disagreed with, not the idea that you could theoretically with enough resources get an objective answer.

It might be because depending on one's sensitivity to various factors and how much work they put into discovering the domain, things might feel okay, and yet be the completely wrong choice.

For example, how to many people MongoDB felt like a really good option during its hype cycle before it became clear how there are workloads out there, where you will get burnt badly if you pick anything other than a traditional RDBMS with ACID.

Similarly, there are cases where people cargo cult really hard or just become opinionated over time - someone who has worked primarily in Java for 20 years will probably pick that for a wide variety of projects, though this preference might make them blind to the fact that others aren't as good with it on a given team and that they might not iterate fast enough to ship, when compared with, let's say Django or Ruby on Rails or even Laravel.

Feelings can be dangerous, informed choices will generally be better, though I guess with the way we use language, those two kinda blend together. If those feelings are based on good enough data and experience, then those might be pretty valuable too - someone who has been writing code for 20 years will probably be more accurate than someone who has been programming for 2 years, yet if someone has 10x2 years of experience (doing the same thing, not learning, not exploring), then it's a toss up, worse yet if people think that still means seniority.

I kinda get why someone might react to the word "feels" in seemingly deterministic development context, but my own reaction wouldn't be so strong and with certain people, I'd trust their feelings. At the same time I've seen plenty of people who write what they believe to be a good code that is a bit of a mess in my eyes.

Re: The highest quality codebase

#347

Post by KronisLV »

manmal wrote: post #344
KronisLV wrote: post #278

Earlier quoted context omitted.

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

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 that could be simplified. Implementation became way more straightforwards and I still opted for a more iterative approach than just one deliverable at the end. About 75% of the spec got build and 25% was found to be not necessary, it was a massive success - on time and with fewer bugs than your typical 2 week "we don't know the big picture" slop that's easy to get into with indecisive clients.

Obviously it wasn't "proper" waterfall and it also didn't try to do a bunch of "agile" Scrum ceremonies but borrowed whatever I found useful. Getting a complete spec of the business needs and domain and desired functionality (especially one without prescriptive bullshit like pixel perfect wireframes and API docs written by people that won't write the API) was really good.

Re: The highest quality codebase

#348

Post by kubb »

mjr00 wrote: post #78
pdntspa wrote: post #43

Earlier quoted context omitted.

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…

> 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 so tired of this analogy. Have the people who say this never worked with a junior dev before? If you treat your junior devs as brainless code monkeys who only exist to type out yo…

In my experience, juniors were more capable at solving engineering problems than some staff engineers, but that’s just an artifact of a broken ladder system.

Re: The highest quality codebase

#349

Post by swiftcoder »

> The version "pre improving quality" was already pretty large. We are talking around 20k lines of TS

Even before that rest of it, 10k lines of code for an app with 5 screens is... yeah. Reminds me of "enterprise" Java codebases from 15 years ago

Re: The highest quality codebase

#350

Post by skydhash »

Dylan16807 wrote: post #337
skydhash wrote: post #258

Earlier quoted context omitted.

Neither. Because the solution for IaC is not Go or Rust, just like the solution for composing music is not a piano or a violin. A solution may be Terraform, another is Ansible,… To implement that solution, you need a programming language, but by then you’re solving accidental complexity, not the essential one attached to the domain. You may be solving, implementation speed, hiring costs, code safety,… but you’re not…

> Neither. > A solution may be Terraform They're asking about what language you use to write Terraform. It's not accidental complexity, it's what the question is about.

It’s very much accidental complexity. As the sibling comment to my previous comment said, the choice of a language does not depend on Terraform design, but on contextual information like the team skill, business requirements like time delivery and implementation correctness. None of which really impacts the design of Terraform as a solution. Just like SMTP or Posix tools does not care about the language.
Post reply on HN