151–160 of 224 posts
I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..
"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." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…
For me, one of the interesting points of the article is not just that the replacement code was inferior, it's the recognition that the emotional compulsion to "clean up the dirty code" was a problem in itself.
Sure, as you say, if you refactored it in the other direction in this would also be problematic -- but there aren't many people who feel a visceral emotional compulsion to refactor code to make it less "clean". (Maybe brainfuck aficionados? Anyway, a rare breed.)
So I think there's something about the concept of "neat/clean code" that asymmetrically/directionally produces this error, and I took the "goodbye" to be giving up on this compulsive attachment to the concept of "all code must be cleaned", rather than saying that the concept of clean code shouldn't be used anywhere. The money quote being:
> Am I saying that you should write “dirty” code? No. I suggest to think deeply about what you mean when you say “clean” or “dirty”. Do you get a feeling of revolt? Righteousness? Beauty? Elegance? How sure are you that you can name the concrete engineering outcomes corresponding to those qualities? How exactly do they affect the way the code is written and modified?
It's really more about identifying the feelings that "dirty" code produces and realizing that they might lead you astray.
> "X considered harmful! ...I mean, if you're overdoing X"
I'm 100% on board with the general objection to this kind of thing, it's a pet peeve that I share. I just didn't get triggered by this one :)
Earlier quoted context omitted.
This is just how some places work, unfortunately. We all push to main, no code reviews, no CI etc. Hell, some people here patch things by downloading the live dll, decompile, update code, recompile and stick it back to live...
You realise that everyone pushing changes to main several times a day is the definition of CI? and it's pretty much impossible to do with code review as a gate for pushing to main. Interesting how CI has become semantically diffused to mean literally the opposite of CI: tooling and processes that delay integration and make it easier to work in isolation. https://wiki.c2.com/?ContinuousIntegration " The most granular…
I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..
How is pushing to master not a form of CI?
This article really buries the most important lesson about refactoring: > 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 e…
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
Earlier quoted context omitted.
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
Two reasons, one technical, one social. Firstly, the original developer probably spent more hours thinking over and working on that bit of code than you have -- so maybe they had a good reason for doing it the way they did. You won't know unless you ask them. Secondly, I think it's a fairly natural and common human behaviour that when you spend a lot of time working on or making something that you feel some degree of…
Realistically, people doing such work care very little about writing 'great code' because they know they have no real 'ownership'. There hopes for higher pay and recognition rely on climbing the corporate ladder by whatever means available. Team member, team leader, division manager, VP of whatever, etc. Blame bad results on someone else, that's the normal tactic for these types. Don't hold up production over code quality concerns, because delays in pushing product to market upset the shareholder board, which they see as lost profits.
The whole notion of a 'skilled technical individual who takes pride in their work because they own it' sounds like some awful corporate in-house propaganda campaign to be honest. And this accounts for much of the current mass exodus from the corporate workforce, I imagine.
"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." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…
I really don't see your point about the article being linkbait-y at all.
I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..
It was reviewed the next day by his boss. How is pushing to master not a form of CI?
I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..
It was reviewed the next day by his boss. How is pushing to master not a form of CI?
Assuming Master is the "protected branch" and not kitchen sink, this sounds like - "we test only in production". Wouldn't or shouldn't reviews happen before merging to master?
"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." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…