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

121–130 of 162 posts

Re: The code culture problem

#121

Post by johnnyc3po »

ahadden wrote: post #17

This is similar to the discussion around "legacy code", which in many ways is corporate speak for "shit code". In his book "Working Effectively with Legacy Code", Michael Feathers provides an interesting definition of legacy code. He defines legacy code as code that is not under test. The idea is that if code is under test then it is easier to improve/refactor. Maybe instead of saying that code is "shitty", we should…

You don't need tests to refactor code... unless you are an OCD programmer who needs nice little test containers for everything. And the other thing about testing, forgot to write a critical unit test? App fails, all the other tests are a moot point. It is no different then writing "legacy" code and forgetting something critical. Be careful what you read and are influenced by.

Re: The code culture problem

#122

Post by twistedpair »

zeteo wrote: post #40
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…

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

Let's admit that while there is code that could be cleaned up and made more efficient, which isn't "shit," there remains code that is riddled with antipatterns, latent bugs, is undocumented, untested and otherwise ostensibly terrible. This is what should fall under the "shit" category.

Re: The code culture problem

#123

Post by avelis »

If code is not clean we should be able to state for at least two reasons why. e.g. It breaks SRP, lacks dependency injection, not enough abstraction. Saying something is "st" usually means we lack the verbiage to describe it. Clean code is a continual process one that needs curation with care. There are times when we are reading code and it's just terrible to understand. No care was put into it. My frustration comes to when I don't see care in code. Code is not inheritedly careful. We have to make it that way.

Re: The code culture problem

#124

Post by slewis »

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…

Sure, there is some really bad code out there. But even pretty good code looks really bad to a lot of developers, because of the "This is shit" mentality the article describes.

Re: The code culture problem

#125

Post by acjohnson55 »

mgkimsal wrote: post #58
babarock wrote: post #32

Earlier quoted context omitted.

You're probably right, what do I know I've only been programming professionally for 3 years. However, I find that it's more helpful to have a positive attitude when reading code I didn't write. "Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". I'm not denying that I found seriously bad code running in production. And I'm not denying that it'…

"Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". --------------------- You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to. You will have learne…

I'd much prefer to have GP on my team than you, frankly. I think companies are much more productive when they have people willing to learn from and teach one another rather than bringing negativity.

Re: The code culture problem

#126

Post by njharman »

scotty79 wrote: post #26

I almost never look at somebodys code and think it's shit. Sometimes I think some ideas are not the best possible ones in given context. But I almost exclusively think "this is shit" while I'm looking at my own code. And I agree that that feeling is a problem as it often destroys my motivation to finish what I started.

> it often destroys my motivation to finish what I started

Shit code, mine or others, highly motivates me. To refactor/fix it. To the point I have a really hard time making targeted, single purpose commits.

Because I have pride in my work, concern for the dev who has to maintain this shit after me, and understand costs of technical debt.

Re: The code culture problem

#127

Post by boomlinde »

mjhea0 wrote: post #13

"Psychological projection was conceptualized by Sigmund Freud in the 1890s as a defense mechanism in which a person unconsciously rejects his or her own unacceptable attributes by ascribing them to objects or persons in the outside world." In other words, we think out own code is "shit" so instead of dealing with that, psychologically, we just attack others.

I don't see how you can make that conclusion from the quote.

Re: The code culture problem

#128

Post by mgkimsal »

acjohnson55 wrote: post #125
mgkimsal wrote: post #58

Earlier quoted context omitted.

"Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". --------------------- You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to. You will have learne…

I'd much prefer to have GP on my team than you, frankly. I think companies are much more productive when they have people willing to learn from and teach one another rather than bringing negativity.

The last few years, I've primarily been working freelance going in to companies and dealing with crap cleanup left by people who were "positive" about their own abilities, gave a pass to everyone else on the team who could get something to run without too many obvious errors, then left.

So... you can call it negative, I call it realistic. I'm pleasantly surprised when I discover good, well-written code, and it means my estimates can be revised downward - something everyone enjoys. Hoping for the best and getting the worst is horrible - expecting "meh" and getting a positive shock is great, but doesn't happen all that often.

I'd have loved to be at a company where people learned from each other and taught one another - imo, it's extremely rare. I've seen it a couple times in the past 15 years, but more often than not, politics and/or ineptitude takes over, and the 'learning/teaching' thing goes out the window.

As a developer, I had a technical manager over me who'd never coded. I've had a colleague who was hired to 'fix bugs', and has to watch the people who wrote the bugs go rewrite everything in to a 'version 2', rewriting exactly the same problems, because "they've been here longer".

So... yeah, companies that foster teaching/learning environments might be nice, but it takes a LOT of work to get right.

Re: The code culture problem

#129

Post by twistedpair »

DominikR wrote: post #63
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…

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 point can be that the team can do it BETTER. If you run Sonar on a codebase and get 10K serious findings... then the code certainly is not optimal. There is no upper limit on how optimial it can be, but you'll certainly have an easier life and a better end product if you've followed best practices as opposed to "just getting it done" by the most junior, lowest payed code monkeys possible.

Re: The code culture problem

#130

Post by Too »

kybernetyk wrote: post #20

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…

Checking the history of the file can also be quite revealing. First version usually looks good. Later, most commits are just trying to squeeze in new functionality by changing as little as possible of the existing code. 20 check-ins later the original design is no longer relevant and mostly consists of exceptions because nobody was brave enough to refactor. Getting refactoring approved could also be hard by in certain cultures and organizations because "why change something that is proven to work in production"
Post reply on HN