To me, clean code is a separate concern from coherent interfaces. Your change changed the interfaces and although I don't have deeper context, I personally prefer the simpler original interface. Have good interfaces first, then use clean code principles to handle implementations
Goodbye, Clean Code
451–460 of 599 posts
Re: Goodbye, Clean Code
#452I'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…
> 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 (typically one corporate user). Very few people are famous, because fame is fundamentally scarce.
Implying that every programmer worth their salt should have produced code other programmers use is just not realistic.
Re: Goodbye, Clean Code
#453> 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…
> seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well.
The people doing the rewrite benefit from your work though. They might would have done the initial writing "worse" than you did.
It is good to have fresh views. I agree it is good to communicate, too.
Re: Goodbye, Clean Code
#454> 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'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…
I also think it's fine to change the code someone wrote. Just because someone wrote it, doesn't mean it's the right way to do it. I often find myself rewriting the code, it's the natural process of code evolution. It just feels that it should be more readable, efficient etc. Although, if the change is essential or it requires more pair of eyes, I'll just make a PR(MR) and let the people review it.
I think a better process is to discuss with the other dev, talking through how you think it could be improved. They (or sometimes you!) can learn something that will lead to improved in the future.
It's a bit like that analogy about giving a man a fish vs a fishing rod.
Re: Goodbye, Clean Code
#455> 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 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 thing. Moreover, if code quality actually has been improved, you should be happy with it.
Now how it is done is also important, but neither more nor less than any other human interaction.
Re: Goodbye, Clean Code
#456Earlier 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…
From (I think) an old Joshua Bloch talk on API design, paraphrased: * If you generalise based on one example, you will get a flexible API that can handle only that example. * If you generalise based on two examples, you will get a flexible API that can switch between those two examples. * If you generalise based on three examples, you have a chance of abstracting over the common essence.
Hmm. I wonder if he got that from Simon while he (JB) was at CMU. He (HS) once said to me, jokingly, I think, “One makes an observation, two makes a generalization, three makes a proof”.
Re: Goodbye, Clean Code
#457I was less bothered by any duplication than I was unnecessarily using let instead of const
Re: Goodbye, Clean Code
#458Earlier quoted context omitted.
"It isn't magic!" mantra is often heard in Go apologetics, but every time I see it, it occurs to me that Go's definition of "magic" is somewhat akin to a 15th century peasant seeing a lightbulb. Stuff like exceptions or error types isn't magic - they have been around for a long time, they're well understood, and they have significant advantages.
Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.
The main issue with any discussions on exception is the elephant in the room, Java. Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception.
I really like the exception model of Erlang, recovery is only possible from another routine. It's is in my opinion the best exception model.
Go code is nice because everything is fully explicit but it's hard to read, trying to follow the control flow when half of the statements are error recovery code is just very unpleasant. And i still don't know how to express that an error is the result of another error without forgetting the context.
Re: Goodbye, Clean Code
#459I know it's completely tangent to the point of the article, but is anyone else wondering why it took a week to implement scaling objects in a visual editor? The codebase? The coder? Documentation requirements? A combination of things?
I want to understand what causes projects to lose velocity, and try to solve those issues.
Re: Goodbye, Clean Code
#460Earlier quoted context omitted.
"It isn't magic!" mantra is often heard in Go apologetics, but every time I see it, it occurs to me that Go's definition of "magic" is somewhat akin to a 15th century peasant seeing a lightbulb. Stuff like exceptions or error types isn't magic - they have been around for a long time, they're well understood, and they have significant advantages.
Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.
>Except exceptions are rarely understood and used correctly by most programmers.
That's just your opinion.