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

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

561–570 of 599 posts

Re: Goodbye, Clean Code

#561

Post by DelightOne »

woutr_be wrote: post #520
bjourne wrote: post #513

Earlier quoted context omitted.

> Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. Here's some tough love. If people frequently rewrite code that you write it is because they are stronger developers than you are. You, the junior developer, can either sulk about it and feel misera…

I think you’re missing the point as to why I might lose confidence. I’m fine with people being better than me, especially when they explain why they did certain things. But we work as a team, that means that before we do work, we agree on one thing. If suddenly an engineer decides a week later he wants to do something else, then that’s not cool. Even if he has a valid reason for it. Instead you talk to the team, and…

Should every change be talked over? If not which ones?

Re: Goodbye, Clean Code

#562

Post by dx034 »

quickthrower2 wrote: post #273
altitudinous wrote: post #244

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…

When you work with your own apps you can be as messy as you like. In a team there is some incentive to make the code readable to other developers. At the lightweight end you have coding standards and linting, then design patterns then finally big refactorings. It’s all trade offs. Bug team products can have islands of code that are like one person projects and those can be messy for example.

Code with duplications isn't less readable. Quite the opposite. Fighting your way through layers of abstractions and generalizations can make it harder to understand for someone new to the code. Especially code that will rarely be touched except for bug fixes, having it as simple as possible can often be worth it.

And in the end, users will also appreciate this. Any time spent refactoring is time not spent on new features or bug fixes. A user doesn't care if your code is cleaner (unless it was buggy before), they'd rather have new features or improved usability.

Re: Goodbye, Clean Code

#563

Post by dx034 »

jammygit wrote: post #275
altitudinous wrote: post #244

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…

I find that every 1000 lines of code I write, my productivity goes down a bit more. Without refactoring, my code just gets really coupled and it gets harder to change. Your position is that the time cost of refactoring is less than that of speed up benefits?

If you duplicate and don't try to generalize wherever possible, these links won't hit you as hard. Changes to one module are much less likely to cause bad behavior in others compared to code where as much logic as possible is generalized and shared between functions.

Re: Goodbye, Clean Code

#564

Post by dx034 »

einpoklum wrote: post #342
altitudinous wrote: post #244

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…

> There isn't much code I wrote in my previous professional career that is still live That means your impact on the world has been very limited. You haven't contributed to the basis of what other coders used. Not that this is illegitimate - but I believe we should strive further. > the reason is vendors only make a profit because they need to generate cashflow constantly, and they do it by breaking the above rules un…

> That means your impact on the world has been very limited. You haven't contributed to the basis of what other coders used. Not that this is illegitimate - but I believe we should strive further.

I don't think many coders can claim that much of their code from decades ago is still alive. And rightly so! The areas where code is used for that long (e.g. core banking systems) are not necessarily the most pleasant to work with.

Re: Goodbye, Clean Code

#565

Post by Shinchy »

burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

I really like this way of looking at it.

Re: Goodbye, Clean Code

#566

Post by de_watcher »

BinaryIdiot wrote: post #295
bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

> I also think that a salaried engineer who thinks that a piece of code he or she (but almost always he) wrote is "his" or "hers" is totally wrong. It's the company's code. While this is _technically correct_, this isn't how humans work. Humans attach their worth to things they do, even when they shouldn't. It's a difficult thing to avoid to most people so if you write some code, commit it and then later see a teamma…

If you're the one who has created it and who touches that part of code more often than others then there is a notion of ownership: you don't want to accept changes that will get it into dead end and slow you down. That's how code review emerges. It's the same as the pull request system in the opensource development.

Re: Goodbye, Clean Code

#567

Post by woutr_be »

DelightOne wrote: post #561
woutr_be wrote: post #520

Earlier quoted context omitted.

I think you’re missing the point as to why I might lose confidence. I’m fine with people being better than me, especially when they explain why they did certain things. But we work as a team, that means that before we do work, we agree on one thing. If suddenly an engineer decides a week later he wants to do something else, then that’s not cool. Even if he has a valid reason for it. Instead you talk to the team, and…

Should every change be talked over? If not which ones?

If you run scrum, then every ticket should be talked over, and large changes should be discussed. Every change? No. Architectural changes? For sure.

A rewrite of someone else’s code? Most definitely.

Re: Goodbye, Clean Code

#568

Post by de_watcher »

woutr_be wrote: post #520
bjourne wrote: post #513

Earlier quoted context omitted.

> Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. Here's some tough love. If people frequently rewrite code that you write it is because they are stronger developers than you are. You, the junior developer, can either sulk about it and feel misera…

I think you’re missing the point as to why I might lose confidence. I’m fine with people being better than me, especially when they explain why they did certain things. But we work as a team, that means that before we do work, we agree on one thing. If suddenly an engineer decides a week later he wants to do something else, then that’s not cool. Even if he has a valid reason for it. Instead you talk to the team, and…

You can discuss when the rewrite is done, that way it wastes less of your time: you can talk about non-hypothetical existing thing. If the discussion shows that the rewrite is bad then it's his problem: he has to fix or revert.

Plus even the initial rewrite is more time-consuming to do if he doesn't discuss it with the original author beforehand.

Re: Goodbye, Clean Code

#569

Post by jrochkind1 »

paulnechifor wrote: post #533
jrochkind1 wrote: post #191

Earlier quoted context omitted.

Probably, I didn't even notice it in the OP, and if some other reader noticed anything, they were probably able to read on without much confusion anyway. (Did you find that one right there above confusing? I suspect not?)

Indeed. Maybe my English skills are fading with time, but my impression was that it works there because it's unclear who you're talking about. "Some other" is singular, but multiple people could have noticed that so it makes sense to use the plural there. It's kind of like how in American English they say "France _has_ won the WC", but in British English they say "France _have_ won the WC" (because a team has multipl…

Note of course you don't say "they is awful", you still conjugate they with "are", even when singular. For an unknown person, for a specific person, either way.

Re: Goodbye, Clean Code

#570

Post by huntleydavis »

From years of schooling and artificially constructed engineering problems we've gotten used to, for some addicted to, the idea of end solutions fitting neatly into a clean edged box. We've grown up on complex physics problem with a clean integer solution, homes with clean lines and polished finishes, and engineering that's constantly pushing for smaller and faster solutions. So, naturally we want our code bases to reflect our experiences : concise, clever, code that feels like a clean integer solution. And while maybe it should be a common aspiration to write code that's 'clean, the reality of the natural world is that solutions to some of the most complex problems are not 'clean'. Furthermore, rarely is the true end goal of the code you're writing to be the 'final state' of logic. The code that we write is almost always for ever evolving and expanding use-cases; we are creating scaffolding rarely a 'finished' product. Furthermore, most of us are writing code in ever evolving languages so even 'finished' state code will ultimately be paved over with something more concise and efficient as the language evolves. The point being : there's a happy medium ( I haven't mastered it ) of reconciling with the realities of complex evolving solutions and our internal desire for clean elegance in our codebases.
Post reply on HN