The code culture problem • Hacker News Board

Re: The code culture problem

#111

Post by sitkack » Thu, Sep 05, 2013, 3:32 PM UTC

dragonwriter wrote: post #107

sitkack wrote: post #72

Earlier quoted context omitted.

No, a 6 min mile is not average. And yes the average of most things is shit. Shit isn't bad (unless it is), it is the output of useful work usually. It just needs to be covered up and stayed away from.

> Shit isn't bad I would suggest that this indicates that your figurative use of "shit" is not the common figurative use of the term in the phrase "shit code", which is impairing communication.

True, I was making a facetious statement that everything that eats produces shit and that the "shit code" is just another by product of a living organism (team, business, coders). Something can be not-good and still be not-bad. I would say my figurative use of the world shit in this context is near neutral but flawed quality. Like dollar store tools.

Most of my code is shit probably by everyones definition. So I try and write as little as possible to solve the problem. If I spent the time required to make all of my code non-shit (not good, but non-shit) then I would get very little done.

It would be nice if google wave didn't tank, or this discussion board was scriptable by the end users because I would love a sidebar where we could agree on the definitions of terms under discussion.

Due to the lack of attention, willful or otherwise, most conversations online end up talking _past_ or _at_ each other and not to.

Re: The code culture problem

#112

Post by sanderjd » Thu, Sep 05, 2013, 3:34 PM UTC

romaniv wrote: post #85

zeteo wrote: post #40

Earlier quoted context omitted.

>I've been in this business for over 25 years [...] The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. [...] Most code out there is shit code. Denying it is not going to help either. I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to…

If I can open a project and refactor some piece of code to be 1/10th of it's former size, while making it both more readable and more efficient without changing what it does than it's shit. In such cases I honestly don't care how good the original coder was supposed to be or what excuses he has. And yes, if I write code that can be optimized that way, I will be the first to admit that it's shit.

It's easier to refactor something that has already been created than to create that thing. This is why refactoring is such a good thing. It doesn't mean the original creation was "shit", it just means that it was massively improved by refactoring, which is sort of the point.

Re: The code culture problem

#113

Post by zwieback » Thu, Sep 05, 2013, 3:37 PM UTC

A lot of is an age thing. I vaguely remember feeling like that but that was soo long ago. Of course there is a lot of truly crappy code but you're only allowed to complain about it if you write flawless code each time, every time out of the gate, e.g. never.

Also, whatever your favorite "technology" is today is probably a bad joke to the next guy.

Re: The code culture problem

#114

Post by btilly » Thu, Sep 05, 2013, 3:39 PM UTC

kabouseng wrote: post #67

bowlofpetunias wrote: post #51

Earlier quoted context omitted.

Maybe I haven't been entirely clear. I'm not talking about a mismatch between approach (over- or under- whatever) and goal. I'm not talking about quick hacks that were never refactored (because of course, there never is time). I'm not talking about code that has gone through many cycles of unpredicted change and has acquired many layers of cruft. I'm not talking about code made by inexperienced developers who still h…

I would suspect that such practices are more prevalent in the web development world. Enterprise software and embedded development (my focus area) suffers far less from the pure unadulterated "shit" code pattern. Mostly I suspect that is because the software development practices such as code reviews and coding standards are actually enforced.

I would hope that embedded is better. But the "Enterprise software" that I have seen is generally horrible.

Re: The code culture problem

#115

Post by nsxwolf » Thu, Sep 05, 2013, 3:39 PM UTC

"If a tree falls in a forest" comes to mind.

If shit code is performant, correctly solves the intended problem, is well-tested and bug-free, is it really shit code?

Re: The code culture problem

#116

Post by [deleted] » Thu, Sep 05, 2013, 3:40 PM UTC

[deleted]

Re: The code culture problem

#117

Post by chriswarbo » Thu, Sep 05, 2013, 3:42 PM UTC

weavie wrote: post #41

bowlofpetunias wrote: post #25

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm t…

It depends on what you mean by shit code. Is code that was written on time and on budget - but has a few hacks in it shit? Is code that is beautiful and easily maintainable, but was £1m and six months over budget not shit?

Shit code is the third option: Code which was late, over budget and completely unfit for purpose, requiring an army of temp workers to process everything manually while another team come in and spend months on a death march trying to fix it, while the business is hemorrhaging money via lawsuits from pissed off clients with violated contracts.

Re: The code culture problem

#118

Post by RogerL » Thu, Sep 05, 2013, 3:47 PM UTC

chriswarbo wrote: post #104

DominikR wrote: post #63

Earlier quoted context omitted.

So what exactly is the point you are trying to make here other than that you are the smartest guy? The article is not about the existence of shit code, the amout of shit code produced per year or how much shit code the average developer will see in his career. It is about teamwork, and what kind of culture poisons the atmosphere in a company. Not about shit code, which by the way everyone here has produced at some po…

The first step to solving a problem is admitting that there is one. I remember debugging some AJAX code once which was racing with itself. It took a lot of mental effort to work out what the existing code was meant to be doing and what it was actually doing, both of which were wrong. At it's core was a simple jQuery AJAX call with a success callback (no error callback, of course), but interleaved through it was a mes…

Yes. I understand the OP point about not fostering a culture of negativity - that makes a lot of sense. But I've never seen negativity take down a product, just make it a bit more unpleasant working environment. The culture of 'good enough' is far more damaging, in my experience.

FWIW: when I was fresh out of school my logic was sometimes pretty twisted, to put it kindly. Lots of deeply nested if statements, global variables used to maintain state (in the state machine sense) that sort of thing. That is unworkable, I recognized it, and I learned from my peers, from books, from good code, from myself (reality is a wonderful instructor. Work til midnight fighting a bad piece of code you wrote, well, you should learn something from that). That's not ego, that is learning your discipline.

This is all testable in the marketplace - not in products sold, but the marketplace inside your development lab. Are you the programmer with endless bugs, or the one that generates nearly bug free code. Are you a 10x programmer, or not? Are you the one that everyone asks questions of (to learn from you, or get your opinion on a design), or not? Do people seek you out for code reviews, or not? Do people need to come to you endlessly to try to figure out what your code is doing, or not? Does your code have a disproportionate number of bugs written against it? If there is a bug in your code, do the rest of your team members assign it to you because they can't begin to understand your code? And so on. There's no ego in any of that, but it is all reality(what I called the marketplace) telling you the quality of your code, in the measurable form of understand-ability, maintainability, bugginess, and so on.

Re: The code culture problem

#119

Post by johnnyc3po » Thu, Sep 05, 2013, 3:52 PM UTC

Too many devs writing simple applications get caught in this "my code has got to be incredibly elegant" mindset. Remember, code is a tool to create something and bring value. Don't write code for the sake of writing code for Christ's sake (my). Carmack is a fine example of a value first, elegance second type of programmer.

Re: The code culture problem

#120

Post by boomlinde » Thu, Sep 05, 2013, 3:57 PM UTC

Shit code is shit code no matter the circumstances surrounding its creation. The way I see it, the author got the solution to the problem all wrong. You should be able to criticize bad code, and if the criticism insults you, you should just swallow your pride. You aren't your code.

The problem, if any, isn't the criticism itself, but the lack of explanation. If you can argue for why a piece of code is shit in a way that will help other developers, please do!