Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The code culture problem

fraustollc.com

Post reply on HN
Print view View original

41–50 of 162 posts

Re: The code culture problem

#41

Post by weavie »

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?

Re: The code culture problem

#42

Post by badman_ting »

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.

Re: The code culture problem

#43

Post by username42 »

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…

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

Re: The code culture problem

#44

Post by AznHisoka »

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…

You're assuming all code is written in a vacuum. Sometimes developers are forced to write code under unrealistic time constraints, or they were told to prototype it quickly b/c we'll replace it later (but they never get the time to), and so on.

Re: The code culture problem

#45

Post by lnanek2 »

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…

Agreed. Hell, most of my code lately has unit tests and UI automation tests and goes through code review and adaptions for a week after writing and it is still pretty shitty and needs to be tweaked later and will always be a crappy code by committee result by the end. Just getting it into production is a grueling battle that sucks out the most idealistic souls and makes most into code monkeys just trying to hack something out. But hey, if I was coding for a startup lately all of my code would be shit because of long hours and no tests since most of the time we're just writing experiments we'll throw out later so why test?

Re: The code culture problem

#46

Post by redblacktree »

eksith wrote: post #28
lucisferre wrote: post #19

Earlier quoted context omitted.

I don't see how this has anything to do with the brogrammer fad (as annoying as that was/is). People have been talking this way about code for a lot longer. I'll throw out one of Linus' gems as an example [1]. [1] http://staefcraeft.blogspot.com/2013/07/linus-torvalds-there...

Dated "13 Jul 2013". I'm curious what Linus was like before he created Linux.

At least in the message that introduces Linux, he's much more congenial.

https://www.cs.cmu.edu/~awb/linux.history.html

Re: The code culture problem

#47

Post by fogus »

In my time as a professional programmer I've come to notice a trend. It's true that there is a lot of bad code in the world and much of it is worthy of derision. That said, time after time I've noticed that when confronted with a smelly codebase junior and/or less-skilled programmers are quick to blame the code and the person who wrote it while more senior and/or highly-skilled programmers will start by placing the blame on their own lack of understanding.

Re: The code culture problem

#48

Post by Jach »

nilkn wrote: post #38
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…

If the majority of code is shit, then it's not really a very useful observation to make repeatedly. So I think this goes back to the author's point that this is really a cultural or attitude issue. It's like the friend who complains about everything all the time: constantly complaining about traffic, about the weather, about how the city is losing its charm, about his job, about his classes, about his parents, about…

There is at least one useful implication to the observation, and that's that most (or all) software is shit. Yet people still use and buy it. The implication is a nice three-edged sword. You're guarded against crippling perfectionism, you're striving to get out of the shit as much as you can, and for developers you will always prefer having the source if you want to fix some shit. This article made me remember this from my quotes file:

"All software sucks, be it open-source [or] proprietary. The only question is what can be done with particular instance of suckage, and that's where having the source matters." --viro

Re: The code culture problem

#49

Post by static_typed »

Ultimately, code is like farts. It does stink, but passes with time. Also, stretching the fart analogy a bit more, as developers we always find the output of others (farts and code) to stink more than our own. Some even seem to like their own.

Re: The code culture problem

#50

Post by kyllo »

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…

There's also the issue that most enterprise code is shitty by design. Tight deadlines and budgets, no time to write tests, project scope too large, too many features, too many developers on the same project, too many meetings and standups, poorly described requirements from Product, UML written by business analysts, overuse of patterns, Spring and other overkill frameworks, etc.

To err is human; to really screw up takes a committee.

Post reply on HN