I find it more interesting, educational, and stimulating to fix bugs that are challenging - rather than mundane stupid mistakes. It does nothing but sharpen your skills.
If you aren't enjoying the work you do and the code you write - why are you a programmer? The thrill of solving puzzles and gaining understanding is what drew me to writing code, and I dread the day that it ceases to be like that.
There's beauty in code, elegance in syntax, and art in converting your thought processes into functioning programs. I wish all developers could experience it like this.
I guess we can all agree that nobody likes to waste time on mundane mistakes. Question is what causes mundane mistakes and how to avoid them? And how can we make sure that mistakes are as easy to spot and fix as possible? The way I see it is that some of the ideas that you are trying to promote in fact is often a source of mundane mistakes that are difficult to detect yet you're keen to brush it off as simply being subjective.
Regarding beauty and subjectivity. Yes beauty of code is subjective. But it can be quantified. Subjectivity and beauty is merely a shortcut. By practicing one or another approach we can train our brains in what is beautiful and what's not so that we can more quickly judge what's better what's not without getting too much in depth into details of why something is better or worse - getting into details every time would be wasting a lot of our time. Yet going into details and turning subjective into objective very often is possible with more efforts put into reasoning, argumentation, thought experiments and real experiments.
I can tell you that the code you wrote is ugly and more beautiful would be this and that. You might agree with that and we'd save a lot of time. On other hand if you don't agree that doesn't necessary mean that there is no objectively better or worse approach here. We can get deeper into conversation and maybe we'd find quantifiable ways to judge which approach is better.
To me the approach that is the most easy to read and understand and requires lowest learning curve is the best the most beautiful - that's my brain shortcut that I often apply. And I cannot buy idea that introducing unnecessary complexity as a useful tool of gatekeeping less capable individuals is a beneficial practice (I got that you had this idea on your take on clean code). While gatekeeping using complexity can indeed work and I've seen projects getting away with it I just don't think it's the best we can do.
I find it more interesting, educational, and stimulating to fix bugs that are challenging - rather than mundane stupid mistakes. It does nothing but sharpen your skills.
If you aren't enjoying the work you do and the code you write - why are you a programmer? The thrill of solving puzzles and gaining understanding is what drew me to writing code, and I dread the day that it ceases to be like that.
There's beauty in code, elegance in syntax, and art in converting your thought processes into functioning programs. I wish all developers could experience it like this.
I guess we can all agree that nobody likes to waste time on mundane mistakes. Question is what causes mundane mistakes and how to avoid them? And how can we make sure that mistakes are as easy to spot and fix as possible? The way I see it is that some of the ideas that you are trying to promote in fact is often a source of mundane mistakes that are difficult to detect yet you're keen to brush it off as simply being subjective.
Regarding beauty and subjectivity. Yes beauty of code is subjective. But it can be quantified. Subjectivity and beauty is merely a shortcut. By practicing one or another approach we can train our brains in what is beautiful and what's not so that we can more quickly judge what's better what's not without getting too much in depth into details of why something is better or worse - getting into details every time would be wasting a lot of our time. Yet going into details and turning subjective into objective very often is possible with more efforts put into reasoning, argumentation, thought experiments and real experiments.
I can tell you that the code you wrote is ugly and more beautiful would be this and that. You might agree with that and we'd save a lot of time. On other hand if you don't agree that doesn't necessary mean that there is no objectively better or worse approach here. We can get deeper into conversation and maybe we'd find quantifiable ways to judge which approach is better.
To me the approach that is the most easy to read and understand and requires lowest learning curve is the best the most beautiful - that's my brain shortcut that I often apply. And I cannot buy idea that introducing unnecessary complexity as a useful tool of gatekeeping less capable individuals is a beneficial practice (I got that you had this idea on your take on clean code). While gatekeeping using complexity can indeed work and I've seen projects getting away with it I just don't think it's the best we can do.
Seems like you misunderstood my take on clean code too