... (as of today)
Your code may be elegant, but mine works
111–120 of 174 posts
Re: Your code may be elegant, but mine works
#112The main reason that I agree with this is that developers are, as a group, the boy who cried wolf. It's not that technical debt doesn't matter or code quality doesn't matter but so many developers complain about technical debt and code quality when their concern is irrelevant or flat-out wrong that it's difficult to distinguish a legitimate concern from complete BS. Developers very often use technical debt or doing t…
I don't know man. I have been buried under mountains of technical debt before. It's a pretty horrifying experience and makes me paranoid about writing bad code. It's kind of like how starvation makes you see food differently. Technical debt isn't a joke.
[deleted]
Re: Your code may be elegant, but mine works
#113similar to the concept of ockham's razor.
many people with little familiarity or experience with actual philosophical work seem to believe the razor urges you:
"the simplest explanation is more likely to be correct."
however, the razor actually says:
"do not multiply entities beyond necessity."
the point here--and it's not just for programming or logic--is that you can make your explanation as big/small complex/simple as you want, but if it's more complex than it needs to be to adequately explain what you're talking about, ockham says: cut it down.
if my theory has 1000 elements, your theory has 2, and we predict slightly different results to some experiment, ockham has nothing at all to say to us. ockham's razor is only useful regarding predictively equivalent theories. if ockham were saying "keep your predictions simple stupid," his razor would be trivially bad, and its implications trivially false.
similar to code: if it doesn't work, its elegance is irrelevant. virtues like parsimony, elegance, or even scalability and the like are built on top of actually doing the job in the first place.
edit: p.s. people are attacking the article for its strawmen, or for being too simplistic re: speed vs quality. i don't see how either of those get in the way of the author's fundamental point: don't overengineer, or mistake "objective quality" (???) with what's called for in a project. if i'm buying a $100 laptop, i'm upset that it doesn't have a haswell i7, but i'm not immediately wondering why the laptop's processor is so bad because it doesn't have an i7. ideas need to be kept straight.
Re: Your code may be elegant, but mine works
#114Earlier quoted context omitted.
The worse thing is that he's saying "you shouldn't spend extra time to do the right thing", and then tries to justify that by giving examples of people doing the wrong thing. Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.
I don't know. The whole ecosystem we live in (YC) seems to be about, "Your idea may be good, but mine exists." Basically, the same thing as he's saying.
I felt the same about the YC ecosystem, which is why I submitted this.
Re: Your code may be elegant, but mine works
#115Earlier quoted context omitted.
Exactly. Specially with the chosen title. Almost all similar articles I read, are used as some kind of self justification to writing bad code and leaving it there forever. If you believe the software will fail (won't ever be changed/grow), do whatever you want with it. If you think it'll succeed, stack too many dirty hacks together and you're gonna pay for it later with tons of interest. Main problem is, too many tim…
> Almost all similar articles I read, are used as some kind of self justification Nerds (of which I am one) tend to be really good at rationalization. These articles serve as a sort of catharsis ("I probably could have done better, but I was really just moving fast and breaking things!"). Other times, these articles are written as a means of projecting identity (e.g. "I reject enterprise-y nonsense by refusing to doi…
Nerds ( also one myself ) tend to suffer from the over-generalization fallacy. Whereby they think that their local experience generalizes to a much larger scope. For instance, If you read most of HN programming articles with the prefix "when writing code for a web startup" they make sense, if drop that prefix they stop making sense. It also helps to keep in mind that advice that holds in the startup world can be quite toxic when applied elsewhere in the industry.
Re: Your code may be elegant, but mine works
#116How about a code which works and is elegant as well? Plan better.
Re: Your code may be elegant, but mine works
#117Reducing software development practices down to these cute catchphrases is a bit disingenuous. If you're writing throwaway code for a client with loose constraints and a tight deadline you'll write code differently then you would when you expect to maintain a long term relationship with a client who expects a high degree of correctness. I'm tired of these trite articles espousing some cute mantra holds as if it's som…
The worse thing is that he's saying "you shouldn't spend extra time to do the right thing", and then tries to justify that by giving examples of people doing the wrong thing. Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.
> Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.
Have you used any Java API? That's exactly the feeling I get from using them.
Re: Your code may be elegant, but mine works
#118Earlier quoted context omitted.
> But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I think this captures the central problem in our current software development state of affairs. Because as developers we are stuck with primitive tools that make doing even trivial stuff time consumi…
I don't know that sophisticated spreadsheets are trivial to create. I've seen way too many weird, buggy and outright broken spreadsheets to believe that. I agree with you we should strive to make trivial things simple to write, and I also agree many programming tools fail at that, but I don't agree the software we write (in general) qualifies as trivial. Even some spreadsheets don't qualify. People writing them often…
As bad as the spread sheets can get it's helpful to have the business side make them. Even if you do have to implement a 'real' solution at least you now have a prototype to go off of
Re: Your code may be elegant, but mine works
#119The main reason that I agree with this is that developers are, as a group, the boy who cried wolf. It's not that technical debt doesn't matter or code quality doesn't matter but so many developers complain about technical debt and code quality when their concern is irrelevant or flat-out wrong that it's difficult to distinguish a legitimate concern from complete BS. Developers very often use technical debt or doing t…
If it is elegant then it won't have tight coupling everywhere. Presumably by "elegant" you really mean inelegant.
Re: Your code may be elegant, but mine works
#120Over Engineering != Best Practices
Optimizing only if needed != Cutting Corners
but
Bad Code == Bad Code (no justification for it)