Live data from Hacker News

The code culture problem

fraustollc.com

81–90 of 162 posts

Re: The code culture problem

#81
post #72
post #61

Earlier quoted context omitted.

"Most code out there is shit code." semantic point. if you're saying 'most code' is shit, aren't you saying average code is shit? Kind of like saying a 6 min mile is shit because it's not a 4 min mile.

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.

This reminds me of how pretty much everyone believes they're a better than average driver. Everyone also thinks other drivers are terrible. Both claims cannot be true.

I'd say its appropriate to call 'most/typical code' average code, not shit.

Re: The code culture problem

#82
post #40

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

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

I think it's a bad case of "dislike due to knowledge".

It's stark in the arts, but it applies to almost every human endeavor. As an example in the arts, I dance, and I'm good at it according to almost everyone who sees me dance. But I see myself as a terrible dancer. If I make a video of me dancing, others see every part that's well executed. I'm accustomed to them, and I tend to ignore those parts in favor of every part that's sloppy, every part that just doesn't look right.

And it's no different for code. You know what one of the marks for good code is? If the guy writing it is tearing it apart in the comments. Where do you see /* This is a dirty hack I'm ashamed of */? Usually right next to stuff that's a stroke of genius, or at the very least really good code.

It's strange that the more you know about something, the less comfortable you get with your knowledge, but it seems almost universal that "Ignorance is bliss", or rather the corollary "The more you know, the less you think you know".

Re: The code culture problem

#83

I imagine anyone who's been around for long at all has written what someone would call "shit code." Hindsight is 20/20. Imagine auto makers comparing product today with those from 50 years ago? That's about how far we've progressed in 10-15 years in this industry. Were those guys whose contemporaries were able to send people to the moon on CNC-less machine tools and computers with 4K RAM somehow doing "shit engineeri…

Good point, but writing software in PHP or Java is voluntary retardation. You're holding back the advancement of our trade.

Re: The code culture problem

#84

Earlier quoted context omitted.

Most code out there is shit code. Denying it is not going to help either. So you do it "right" then, I assume. What do you think the next guy is going to say about your code? Do you really think they're going to praise the excellent code quality? Or will they declare to all around that it all needs to be rewritten because it doesn't conform to the newest flavor of the month? I absolutely and unequivocally agree with…

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 thoroughly agree that there is a difference between hacky code and shit code. I've seen far too much code which isn't even attempting to solve the right problem, but is so buggy that its myriad problems compound to make it sometimes appear that the original problem is solved. Things which takes weeks to understand, and only went unnoticed due to an extraordinary unlikely coincidence of errors at all levels of the stack which Rube Goldberg would be proud of.

Re: The code culture problem

#85
post #40

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

>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.

Re: The code culture problem

#86

Some years ago I was doing paid for code reviews. I learned many things but one particularly relevant to this article is: You can only tell if code is shit after you have dug through it for at least a few days. Sure there are the obvious mistakes like non-idiomatic code style. But that's easy to spot. But for anything that is related to the problem domain and not the language itself you need to dig deeper. Because th…

Indeed, I came across a last_day_of_the_month SQL implementation today that I showed my colleague who's instinct was that it was shit, but upon closer inspection, it seems quite clever.

Re: The code culture problem

#87

How about a culture of "stop fucking up". (I admit I stole this from Ted Dziuba, but it has stuck with me.) People who are willing to call things "shit" instead of being nicey-nice at least give a shit. But it is important to be intellectually honest, and not be egotistical about one's own code, which could be shit just like anyone else's.

I don't like Dziuba's harshness sometimes, but I agree with this sentiment. Code doesn't care about your feelings, and you shouldn't either. Just write good stuff that works, and if it's not good, don't blunt the message. If you think code and programmers should respect your feelings, you'll get slow code with many bugs, and few people willing to do anything about it in order not to hurt other people's feelings.

Straight up honesty is the best medicine when it comes to software. If you have a problem with this kind of honesty, find something else to do.

Re: The code culture problem

#88

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

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…

> So what exactly is the point you are trying to make here other than that you are the smartest guy?

He took the one thing he could make an easy, pedantic point about and posted it. It's easier to do that and get free karma that actually be mindful. It's low hanging fruit. Just like I could find errors in his comment that would serve no purpose.

At issue is, while his point might be technically correct, it serves nothing other than to encourage "Me too" replies. This happens frequently on HN. I encourage you to down vote such posts.

Re: The code culture problem

#89
post #35

Earlier quoted context omitted.

I'm just going to ask the question... What do you think makes your code good? I bet the next guy that comes around in 15 years and reads your legacy code (Grats on having code actually runs for 15 years!) will think it's the worst piece of shit ever created and are sure to think you are one of the worst developers in the world.

> What do you think makes your code good? Answering for myself: (1) it's short. Often significantly shorter than my colleagues'. (2) it has few bugs, if our bug tracker is to be believed (I reckon I'm not very confident about that one). On the other hand, I tend to be slower, especially when I have to write against less than optimal APIs.

But short code isn't necessarily a garrant for good code. I went through a teenage phase where I would strive to write the shortest code possible.

It's cringe worthy, and working my back into it seems scarce impossible. If you drew out the program logic, it'd look like an Eldridge terror. It just isn't good code.

But yes, if you're writing War and Peace in order to parse XML, it's unlikely you're writing good code.

Re: The code culture problem

#90
It is a problem if programmers cannot give a reason why the code is shit. But most of the time they give reason, the reason is not good enough. However, I still think it is necessary to say "this is shit code".
Post reply on HN