There's a balance, as is often [always?] the case in inversely related factors like code "cleanliness" (hard to talk about since it's a little vague of a word) and developer "velocity": pristine code can go awry and became "fine china" code that's too verbose or restrictive to effectively change and maintain; likewise, spaghetti code, maybe the opposite?, needs no introduction.
Goodbye, Clean Code
511–520 of 599 posts
Re: Goodbye, Clean Code
#512Earlier quoted context omitted.
> Changing one developers _working code_ after they’ve invested a significant amount of time How much time they invested is irrelevant. There are lots of times where someone is wrestling with something for so long they just want to get it done and don't want to look at it anymore. Many times it's trivial for someone fresh to tidy it up > If removing repetitive code is a requirement then the team needs to be informed…
> There's no way to codify concrete requirements for handling every possible way code can be improved. If the change can’t be codified, then it calls into question why the change needs to happen at all. Assuming that there is some improvement that can be justified, then explain it to the team, and have the team start reviewing for it. By not going through the process of explaining the improvement to the team, it sign…
> If the change can’t be codified, then it calls into question why the change needs to happen at all.
No, there are lots of things that are difficult to codify but are very valuable. If you look at law and policy you'll find plenty of examples. This is akin to saying "If I can't formalize it mathematically, it doesn't exist" which is obviously false
Additionally, there's the category of things which are maybe in principle codifiable as requirements, but are tedious to specify. I would definitely put aesthetic judgements about code in this bucket. It's much simpler if you say something like "and the developers will use their best judgement on how to write clean maintainable code" and be done with it
Re: Goodbye, Clean Code
#513> 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 need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. 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…
> 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 miserable or realize what an amazing opportunity you have to improve.
Swallow your pride and approach the person who rewrote your code: "Hey, I noticed that you rewrote the code I wrote last week. Mind telling me what was wrong with it so that I can learn from you?" If the person answers "No" or "I don't have time" that person is an asshole and you are in the wrong place. But if the person answers "Sure! Let's schedule a meeting in a conference room with a whiteboard this afternoon and I'll explain what was wrong with it!" then you are in a great spot!
> Just rewriting code on your own is a big no for me, and to me, breaks the trust that we had.
Not for me. I trust my teammates judgement. They know when it's a good idea to rewrite my code and when it's not. No point wasting time holding meetings and bikeshedding over minutiae over work that can be done in a few hours. 9 times out of 10 they will do the right call. 1 time out of 10 they won't and we revert - no damage done.
Re: Goodbye, Clean Code
#514Earlier quoted context omitted.
> You haven't contributed to the basis of what other coders used. What fraction of us can claim they have, really? Most developers work at the application layer, the last one. The more foundational your stuff is, the less of it there is, because it is reused everywhere. For similar reasons, very few people work on massively popular software. Most work on software that have only a couple users, or even just one (typic…
> What fraction of us can claim they have, really? I think it's larger than you imagine. Just look at the code of GitHub, BitBucket, Sourceforge etc. Not to mention self-hosted commercially-developed FOSS. > Most developers work at the application layer, the last one. Well, that doesn't mean they have to work _only_ on that. Each developer uses a bunch of libraries, utilities and frameworks which are either FOSS or c…
> Just look at the code of GitHub, BitBucket, Sourceforge etc
I think those are misleading on two accounts: first, it's the tip of the iceberg. Most co-workers I've spoken to don't contribute to any such open source projects. They tend to have other priorities, starting with the proprietary or custom software they are paid to write. Yes, there are many programmers writing open source code out there. I'm willing to guess however that much more time is spent on proprietary or custom software.
Second, there's a lot of unused garbage out there. Yes, there are a massive amount of code that could be used by others, but the only code you see is the tiny fraction that is actually used by many people. Such is the way of search engines, they show you a highly skewed sample, biased towards fame. (And rightly so: famous stuff everybody use tends to be what you are interested in to begin with.)
> Each developer uses a bunch of libraries, utilities and frameworks which are either FOSS or could use a FOSS alternative.
That's the thing: everybody uses a bunch of libraries and utilities all the time. I believe much fewer people writes those utilities. Or at the very least, much less time is spent writing them.
The more popular the library or utility, the more pronounced this is. Everybody can write something 10 other programmers will end up using. Very few will be (un)lucky enough to write something that have enough users to be known across the planet.
Take me for instance. I've sought my GitHub ranking¹ which is mostly concentrated in a single project². Numbers suggest I'm in the top percentile. Not the most popular code out there, but I'm doing pretty damn fine.
[1]: http://git-awards.com/users/loupvaillant [2]: https://monocypher.org
Yet: have you even heard of those? Possibly, but I'd say probably not. The top percentile simply isn't enough.
> […] you can work on somewhat-popular or even niche software which is still used by hundreds of thousands, or just thousands, of people. That's still very significant!
Agreed. This is all a matter of degree, after all.
> I think programmers worth their salt should strive to produce code that other programmers use.
I'm not sure I agree with that goal. And I say that as someone who dreams of having a global impact. Sure, any professional worth their salt should strive to improve to at least some decent standard of excellence. (Some professions, like classical music, tend to require excellence merely to enter the field, which we could argue is maybe going a bit too far.)
Having other programmers use your stuff is a great way to have feedback and improve up to that standard, but I don't think it's not the only way. It may currently be one of the easiest, though.
> I believe that it's the visible code, and the free code, is what we should use as the model and the target of advice and improvement.
If we're going down that path, I'd go as far as to say pretty much all code should be free to begin with. Following that thought to its conclusion though, I quickly concluded that universal free software is mostly incompatible with capitalism. I can write software in my free time, but I need a salary in the first place to even have such free time. Currently, that salary comes from a day job dedicated to proprietary software.
I mean, recall the OpenSSL debacle. That piece of software is used literally everywhere, and we had to have Heartbleed for insanely rich corporations over the world to even notice that trickling a few drops of money down this project might be a good idea.
Re: Goodbye, Clean Code
#515One similar experience i had when I was starting out was when I created a PR and my colleague instead of suggesting changes, made the changes himself, approved and merged my PR. I told him directly that it’d be nice if he’d have suggested the changes instead of making them himself. He thought I was being protective of my code. I was never able to have a good working relationship with him anymore and eventually left.
Re: Goodbye, Clean Code
#516Isn’t the only reason we care about duplicate code that we don’t want to miss an instance of it for enhancements or bug fixes down the line? Don’t we have technology that helps us reduce that concern?
We also don't want to waste time writing and testing and reviewing n solutions to the same problem, risking the same set of mistakes each time.
Re: Goodbye, Clean Code
#517Earlier quoted context omitted.
> If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me... Or, what it might be telling you is the second person wouldn't have been able to clean it up in an evening without the first person having already spent a week or two on it. The second person was building on the first. Just because it was (hypothetically) less lines of code doesn't…
This blows my mind. If I had to discuss with my teammates every time I changed their code I would be way less productive. Everyone’s a little bit watched to the code they write, but iterative improvements and bumping the quality of the codebase is way more valuable than risking a fragile ego. It’s the teams code, we all benefit from improving it.
You can certainly go too far in either direction (talking or not talking), but to the extent talking matters when it does, it's not about "ego", it's about 1) "What did they know that I don't" and 2) Building shared understanding of the context and decisions and architecture.
As the OP says "A healthy engineering team is constantly building trust." Sometimes you already have enough trust and shared understanding to not need a discussion, other times a discussion is good.
Re: Goodbye, Clean Code
#518This article is so tooth-achingly dull, that I hope n-gate will pick it!
Re: Goodbye, Clean Code
#519Earlier quoted context omitted.
I have a very different view to this. As a disclaimer: I am working in a smaller team where most code is non-trivial, may be it is different in very large teams on large code bases. This isn't a question of ownership in the sense of a private property. It is about how you interact and respect and professionalism. First of all, a larger change to code a teammate wrote has a ring of saying: it was badly written. So thi…
> First of all, a larger change to code a teammate wrote has a ring of saying: it was badly written. Not necessarily. In actively maintained projects code change all the time in some area, and if you are doing proper commits very often a piece of code does not magically appears in a perfect state but is rather improved in a series. If you can improve the code you wrote, others can do too. Code quality is not a binary…
But that is exactly my point: there are not only a technical but also social considerations. And yes, in the end a code quality improvement - if the refactoring actually is - should make one happy. But still it is the decent thing to check with the author first, if that is possible.
Re: Goodbye, Clean Code
#520Earlier quoted context omitted.
I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. 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…
> 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 agree to change.
Again, there’s a reason why we work in teams, and not as individuals. I trust my teammates too, but rewriting code without any discussion breaks that trust for me.