Live data from Hacker News

Your code may be elegant, but mine works

omniti.com

141–150 of 174 posts

Re: Your code may be elegant, but mine works

#141
post #94

> "You hate testing!" I started working as a Unix sysadmin in 1996, and while I have always written programs, and have been doing so more heavily lately, I never wrote a program with someone else before. All of my programming has either been programs completely written by me, or small patches sent to existing open source projects. The purpose of testing aside from the most rudimentary always eluded me. A few months a…

this would fall under regression testing, and is most certainly covered by any list of top reasons to do TDD.

Re: Your code may be elegant, but mine works

#142
post #97

Earlier quoted context omitted.

No it's not. If the author's methodologies result in undecipherable code, that's quite relevant to the discussion.

The author has presented an argument. Whether the author himself generates any code at all has absolutely no effect on the validity of his arguments.

Since when is credibility not a thing?

Re: Your code may be elegant, but mine works

#143

Earlier quoted context omitted.

> I think that's about all that needs to be said. Yeah, and that's like a perfect definition for "ad hominem" argument.

You people really need to work on your fallacies. Quoting from the Wikipedia definition of Ad hominem : "[I]n which a claim or argument is rejected on the basis of some irrelevant fact about the author [...]" Leon is a really nice, super funny guy, but the fact that no one can maintain the code he writes is highly relevant to the subject of the article. In summary, http://lwtc247.files.wordpress.com/2010/06/get-a-bra…

Hehe: https://news.ycombinator.com/item?id=6803680

Re: Your code may be elegant, but mine works

#144

The difficulty of changing code is directly proportional to the amount of code that has to be changed. This is almost tautological. So, 6 months ago, perhaps the least difficult thing to do to make a new spreadsheet report was to copy and paste the first one and change a few bits of the query. Repeat 10 times. Management is happy, look how many reports we churned out. Maybe you thought about making a generalized repo…

My experience too. If they balk at the price/time it will take to build a quality solution, let them go with a lower bidder. They'll come back and willingly pay this time.

Re: Your code may be elegant, but mine works

#145
Someone ask Target if they'd rather highend security w/ a missed deadline or insecure and on time...

The point: Context is king in this matter, it sounds like the OP doesnt work on things that really matter much (and hence the cost of a bug is miniscule)

Re: Your code may be elegant, but mine works

#146

The difficulty of changing code is directly proportional to the amount of code that has to be changed. This is almost tautological. So, 6 months ago, perhaps the least difficult thing to do to make a new spreadsheet report was to copy and paste the first one and change a few bits of the query. Repeat 10 times. Management is happy, look how many reports we churned out. Maybe you thought about making a generalized repo…

My experience too. If they balk at the price/time it will take to build a quality solution, let them go with a lower bidder. They'll come back and willingly pay this time.

exaaaactly

Re: Your code may be elegant, but mine works

#147

This is a great excuse to write terrible code that "works" until it goes out and breaks. Then it doesn't work because you saved a little bit of time by cutting corners. What is the cost of it breaking? $0? $1,000? $10,000? What is the cost to fix the broken code? What is the cost to maintain it? How much developer time do you waste down the line because they have to fix the "working" code? I say these things because…

>How much developer time do you waste down the line because they have to fix the "working" code?

That is absolutely spot on. One of the hardest thing is explaining to management that the code your co-worker wrote in a "flash" three years ago is still eating up developer time today. We have a few ill-conceived or badly written systems that seems to eat up time and constantly interfere with new projects. The problems are pretty much invisible to management, because the developers spend a few hours here and there proppring up the badly written systems. Over time you end up having to spend all your time just putting out fires rather than helping the business moving forward.

Re: Your code may be elegant, but mine works

#148

I used to work at OmniTI. The real irony of this article is that it was written by a guy who's (in)famous for his indecipherable Perl one-liners. I think that's about all that needs to be said.

> I think that's about all that needs to be said. Yeah, and that's like a perfect definition for "ad hominem" argument.

...Not sure you know what "Ad Hominem" means...

This is not a disaccreditation of the man based upon his character or something unrelated to the topic, his ability to write good code is highly relevant to the issue at hand.

Re: Your code may be elegant, but mine works

#149

Earlier quoted context omitted.

No, actually it's not. This isn't ignoring the issue at hand and just attacking the author's character, it's attacking the authors authority on a subject matter.

If one focuses on personal characteristics (here skills) of the author rather than the logical construction of his argument, it is in fact ad hominem.

[deleted]

Re: Your code may be elegant, but mine works

#150
MVPs are great, however new business opportunities and new ideas will always come up on a monthly basis, at least.

Especially in startups, you never have time to take care of technical debt. In practice, technical debt is dealt with "on the side" and teams that don't do it will end up in situations in which simple features or pivots are extremely hard to execute, which will lead to lost business opportunities. I was at some point in this situation due to a minor pivot that should have been painless but wasn't, with the solution chosen being to rebuild the product from scratch. This is why I've been telling my colleagues to always leave the codebase in a better state every day, even if that means just renaming a variable. Sloppy code also suffers from the broken-window effect.

What you really want is to write elegant code that works and that's delivered on time. And the greatest trait of a senior developer is not "cutting corners" but rather simplifying the problem. That's not the same thing, as the simplification of a problem often leads to more initial work.

Post reply on HN