I would also say it is waste of effort working a late night rewriting existing code that actually worked. Why waste your time on over-polishing when s/he could’ve left work early and get a good night’s sleep? I think that is the more important perspective.
Goodbye, Clean Code
291–300 of 599 posts
Re: Goodbye, Clean Code
#292Earlier quoted context omitted.
That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…
Future coding has lead to some of the most overcomplicated systems I've worked with. It's one of the reasons (among many) I quit my last job. I was constantly told code that had no use cases was "important to have" because "we needed it".
So does that same idea apply to all of the many abstractions thst geeks do just to stay vendor or cloud agnostic just in case one day AWS/Azure go out of business?
Re: Goodbye, Clean Code
#293One way I think about this. It seems the earlier version of the author's self was thinking about the state of the code as a sequence of atomic states. When you start thinking about your code more as a constantly evolving organism, the BEST version of a particular section of code isn't necessarily what is BEST at the moment. But because there are logical branches that your path can take as the software evolves, your code at this moment is best when it can more easily accommodate the best path to the future.
Re: Goodbye, Clean Code
#294> 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…
Several years ago, I wrote a big chunk of code to analyze engineering data from an engine test cell, and display a graph of the results. Someone else had done the hard part; I was merely coding up a gloriously-complex Excel spreadsheet in C++. I grabbed data from a MySQL database, and labeled the row data like: row[combustion_air_mass_flow] + row[fuel_mass_flow] * row[specific_gravity_of_diesel]. (Or whatever; it's been awhile. You get the idea.)
I had HUNDREDS of lines of calculations, and each variable was very clearly understood so that you could trace the whole process. The code was running and producing replicated results from the spreadsheet. We started trusting it to process new test runs, instead of copy-pasting into Excel.
The next morning, I came in to find the "other" programmer had stripped EVERY variable reference, and replaced them with the column numbers. There was absolutely NOTHING in the code that could help you understand that "combustion_air_mass_flow" was column, say, 54.
I turned to him and asked him what happened, and he said it was inconsistent with the rest of the code base. I was literally gobsmacked. I racked my brain for a response. In the awkward pauses, he admitted that my code was better, but he couldn't bring himself to use it, because that would mean that he would have to go back and recode every other place that worked like that, and there were many.
He was the guy responsible for most of the system; I was just writing this part because I'm an engineer who codes, and could understand the actual science going on. In the end, I re-replaced my equations with my previous code, and wrote another couple hundred lines defining column number to engineering variable, to "translate" his column numbers to something that made sense.
So, no, I don't believe in "do it; don't ask."
And, if, by some chance, you see this, Chris, I still think that was the weirdest flex I've ever seen.
Re: Goodbye, Clean Code
#295> 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 teammate completely rewriting it, it can come off as either:
1. You spent a lot of time and hard work on code that you kinda identify with (I mean, it's code you wrote. It's your "art") and then someone comes in and re-writes it without even asking you about it can make it feel that they think you're an idiot.
or maybe even worse
2. They didn't know the reason you wrote it that way (maybe it was in support of future changes?) and now they just screwed it all up.
Maybe you haven't run into either of those situations. If you haven't, great! I spent the first part of my career hitting the first one because of how hard it can be to disassociate with the work you produce and the second one I see happening occasionally. It's a breakdown in communication within a team.
Re: Goodbye, Clean Code
#296Earlier quoted context omitted.
Yes, exactly, and it is such a good rule to go by so much of the time. But like many rules, you need judgment to know when to apply it.
Rules are a poor substitute for actual thought.
> Rules are a poor substitute for actual thought.
This should be the guiding principle of life!
Re: Goodbye, Clean Code
#297> 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…
If you are on my team and you want to rewrite code I wrote (cause it sux) then do it! Sure, rewriting is fine, but ideally it would come in the form of a PR rather than being checked in, so if you had valid reasons for writing it that way, it can be reverted before anyone else layers code on top of the bad rewrite.
clearly these guys are trunking though, and when they have decided to go that way, its part of the trade-off. Has its pluses and minuses.
Re: Goodbye, Clean Code
#298Re: Goodbye, Clean Code
#299Earlier quoted context omitted.
Future coding has lead to some of the most overcomplicated systems I've worked with. It's one of the reasons (among many) I quit my last job. I was constantly told code that had no use cases was "important to have" because "we needed it".
So does that same idea apply to all of the many abstractions thst geeks do just to stay vendor or cloud agnostic just in case one day AWS/Azure go out of business?
We had platform agnostic discussions with no concrete plan or action by anyone to actually escape our platform.
Re: Goodbye, Clean Code
#300Earlier quoted context omitted.
That’s why I make the test fail before writing the code. If the code is already written, then I break it in the minimal way to test the test, and then fix it.
That's a test for your test, so why only run it once transiently instead of running every time? "Mutant" testing helps with this. It's basically fuzzing your test code to make sure that every line is meaningful.
I can see how that would be useful, but I also think it's a matter of priorities.
I'm basically saying I rarely have bugs in my tests because I verify them first. In fact I can't think of a single bug in my tests over the last 4 years (or even 10 years), but I can think of dozens of bugs in my code.
For example here are some pretty exhaustive tests I've written for shell, which have exposed dozens of bugs in bash and other shells (and my own shell Oil):
https://www.oilshell.org/release/0.7.pre11/test/spec.wwz/osh...
I would rather spend time using the tests to improve the code than improving the tests themselves. But I don't doubt that technique could be useful for some projects (likely very old and mature ones)