Live data from Hacker News

The code culture problem

fraustollc.com

71–80 of 162 posts

Re: The code culture problem

#71
The shitty truth begins to appear when you've — way too many times, might I add — read the old code, thinking it makes sense and then feeling the pain of naivete shifting out as the code eventually turns out to make no sense.

Then begin to recognize potentially shit earlier in the process and while you do enough many rounds of that, confirming your expectations, you can just look at the code and say "this is shit" and be quite confident that you're right.

That's not to say that there wouldn't be a similar process working towards recognizing "When to rewrite this shit?" There is and the answer it gives is "Rarely".

A seasoned programmer will balance between "this is shit" and "not rewriting this shit". And there's nothing wrong with shit, because the shit is shipping and mostly works unlike the ultimate refactoring that nobody has time to write.

So it's the programmer's job to fix shit, and occasionally write new stuff that shall be deemed shit by a later fellow colleague.

Instead of pointing at the vague shitty attitudes towards shit, the author should probably just roll up his sleeves and start fixing the shit.

Re: The code culture problem

#72
post #61

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

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

Re: The code culture problem

#73

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

My job is "first level support". I have to analyse problems reported by users and often to read source code to find bugs. I have seen a lot of shitty code and a lot of very clean code, but most of the problems come from shitty specifications. When the requirements reflect a poor understanding of the users need (or a poor sense of logic), whatever the qualities of the developer, the resulting code will always be a mai…

I always thought 80% of coding (solving anything really) is understanding the problem.

The other 50% is implementation.

Re: The code culture problem

#74

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

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…

I once was responsible for maintaining code like this:

There were 3 client-side javascript files. They were named something like this:

foo.js foo2.js foo-z.js

Each file was about 4,000 lines long. All 3 were nearly line-for-line identical, save for about 500 lines of differences each, strewn wantonly about. For some of the URLs the app would use foo.js, for some other URLs it would use foo2.js, and for yet more of the URLs it would use foo-z.js.

There were 4 files on the server like this which did the same thing - copied line for line and then changed in various places.

After refactoring these files together and eliminating the duplicate code, I ended up deleting something like 8,000 lines of code. I quit soon after - by then I was already looking for another job.

That code was shit. There is no question about it.

Re: The code culture problem

#75
I think this is just a general reflection of modern (internet) culture. It's easier to get "internet points" (read: facebook likes, twitter retweets, etc) by being snarky than it is by being positive.

Re: The code culture problem

#76
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 engineering?"

Imagine if what someone sees as "shit code" ultimately made yesterday's coder $1000/line because it got done while there was an opportunity to sell it. Is it still "shit code?" You're not being asked to be a music critic here. Most code is written as part of a business.

That said, code reviews are a great way to learn from and align with your team!

Re: The code culture problem

#79
This piece reminds me of Linus Torvalds. He's the kind of guy that lives these truths. Always respectful and constructive, never saying code is shit, etc etc. We need more developers like him.
Post reply on HN