Hacker News new | past | comments | ask | show | jobs | submit login

> even if the actual code Works - which I think is the number one most important thing about code

Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code. Exactingly defined requirements, operating contexts, rigorous development processes (thinking of you, NASA checklist). Things like databases and aerospace.

Otherwise the two (IMHO) most important things about code are adaptability and maintainability, not correctness; one way I look at is that your code can't be more correct than the product design. Give me pure but incorrect code and I can fix it. Give me impure but correct code and I can't adapt it when the needs change.

IMHO (and bias disclaimer: Rubyist here) this is why Rails took over web and Python took over academia / ML - Python is about being correct, Ruby is about being adaptable - so Python is better suited to the well-defined-hard-to-do stuff, and Ruby is better suited to the poorly-defined-easy-to-do.

> explain that purity in a way that would make the end user understand its value

Challenge accepted! :)

Good code breaks down the business and product concepts into good elements, and this has many downstream impacts. You, the end-user, can only use the concepts that we've baked into the product, and the product can only be made out of the concepts that we've baked into the code. The less this is true for something - the more that it's a powerful, flexible tool - the more expertise you need to use it (looking at you, Jira) and the closer it gets to just having you write code yourself. So doing a good job of picking the concepts we use to program a thing impacts how well you, as the end-user, can use those concepts to accomplish your goals and meet your needs.

(And that's aside from stability, new-feature rates, etc).

Edit: Just to be clear! I am very, very glad that people with your mindset exist and are working on things. I rely on the things that you make that Are Correct when I'm making my Nearly Correct things. So thank you :)




> Ehhhh if the most important thing about your code is that it works, IMHO, that code should be, call it, deep tech code.

I think code that is adaptable and maintainable but, doesn't work, is universally useless regardless of context. Definitionally, useless.

> Challenge accepted! :)

Unfortunately I am a HN denizen and therefore disconnected from the world of end users, who are sometimes convinced by my arguments that refactoring and good testing is important, but in some cases aren't, particularly when they have me on an obscene day rate for a 60 day contract where I'm delivering 3 projects on 3 entirely different codebases I've never seen before (one of which it takes me a day and a half to even compile).

I have a constant desire to write fast, good, tests, that run in complete isolation and are entirely reflective of how things run in prod. I miss the mark, many times, and I have a feeling even the purists do, since I keep having to refactor their code.


> work

Fair. Maybe another way to put what I'm trying to say is that "the code works" isn't the most important thing when, in the problem context, "works" is a fuzzy / non-binary state. Example: The code for each of the blue checks "worked", buuuuut.

> they have me on an obscene day rate for a 60 day

Oh god totes fair. I will fall back on the twin defenses of "users != clients" and "explain != convince to budget for".

> refactor

Do you find that better tested code is more easily refactored?

Kinda where I'm going: I generally wouldn't consider "this needs to be refactored" an inherent mark of missing that mark, as that can also come from changed needs and requirements. But I would expect "hitting the mark" to result in code that's easy to refactor (and that's part of how I define the mark that I, personally, aim for).

Edit: to more clearly define my goal posts; better tested != fully tested. IME too many people don't hold their test code to a good standard; so IMO "better tested" also means that the test code itself is also "hitting the mark" (or close to it).


> Do you find that better tested code is more easily refactored?

100% - I am 100% for really good, fast, compartmentalizeable testing that tells you exactly what's broken when it breaks. I am 100% for making people very aware that tests should never require another test before to run to make the test work. It's confusing and bad! Good testing makes refactoring painless, and I love that. It's the implication that test order requirements happen because a developer sucks, that I think is incorrect, and fundamentally displays a misunderstanding of what "good" software is! Good software in my view, primarily works. Everything else is secondary to that.

Works is really in the eye of the stakeholders, in my view! It is fuzzy! It is possible to convince stakeholders the problem they have with the code is, incorrect, and then the code magically "works" again. It is possible to refactor people's expectations and have them think that code without good testing, doesn't work. I find that to be the exception rather than the rule.

These are of course all just my views and others have good points and will disagree.


>IMHO (and bias disclaimer: Rubyist here) this is why Rails took over web and Python took over academia / ML - Python is about being correct, Ruby is about being adaptable - so Python is better suited to the well-defined-hard-to-do stuff, and Ruby is better suited to the poorly-defined-easy-to-do.

I see it the other way round - Rails took over the web because it offered the one true (correct) opinionated way to do web development (plus some great marketing and timing around a wave of Java/PHP disillusionment plus github taking off etc). At the time Python had many competing web approaches some going back to the 90s with no consensus about what 'correct' even was.

I don't see much difference between Python and Ruby on the correct vs adaptable continuum when other languages are taken into account. And often see Rubyists being much more purist in their views of eg Object Orientation etc and regard Python as a dirty collection of pragmatic hacks.


Interestingly about 3/4 websites still use PHP. I'm not usually a PHP dev, but my tendency to happily work with any toolset means I've worked professionally on a variety of frameworks in Ruby (Sinatra, Rails, Jekyll), Python (Flask, Django, FastAPI), and others (.NET, Hugo). I can confidently say that some of the most confusing (and magical) code I've read has been rails code. I don't know though, maybe that was the place I worked, or the version of rails, or whatever. I'd totally work at a rails shop again regardless.


I specifically think of each's principles:

https://rubyonrails.org/doctrine

https://peps.python.org/pep-0020/

"No one paradigm" vs "There should be one-- and preferably only one --obvious way to do it."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: