I think it's best to rely on tooling and communication, both proactive, in review, and retroactive, to communicate what's desired as a team. Further, it's best to lean on your code review tools, like pull requests and merge requests, which not only preserve a record of decisions made, but also allows stakeholders to chime in.
As for 'clean code', it all depends on your approach, and your goals. If you're an OOP or FP maximalist, especially when the team is working in a multi-paradigm language like JS, TS, Rust, Ruby, Python, etc., there's absolutely many other factors to consider, than what's "idiomatic". Sure, there's an easy way and a hard way to solve a problem, and sometimes you can contribute your own thoughts and experiences. But this isn't just your codebase. It's your team's, other team's, future teams, and past teams.
Often, I find performance to be underappreciated, but performance is also subjective until it can be measured. Your tools and your review process, your communication process and perhaps even documentation process (but use sparingly, just to communicate objectives and areas of concern, rather than winding up as a maintenance sink, in addition to tests and review), are the major things you'll come to lean on.
I might also say, your approach matters, and using the term 'cleanliness' as a metric to describe code quality is highly subjective, to say the least, and not always that helpful. Linters, code coverage, unit tests and integration tests, end to end tests / smoke tests, regression tests, and most of all, team communication, are your number one guiding factors here.
I will admit, to answer the question originally stated, I regret the approach I once took in my career. I subscribed to FP and/or OOP, "idiomatic" religions, and often was adversarial when challenging the decisions of others. I've had to learn to reign it in, and provide constructive feedback and discussing higher-order goals than can just be addressed through a cursory glance at a PR/MR.
Further, it's always a balance. No single prescriptive approach works everywhere. "It depends" is better than solutioning right out of the gate. Ask more questions, and don't just jump in and do the work. Take a healthy, balanced, measured approach. To some, it might come easy. To others, like me, I've had to learn that software development is more than just writing code, however clean it may be. Much more.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think it's best to rely on tooling and communication, both proactive, in review, and retroactive, to communicate what's desired as a team. Further, it's best to lean on your code review tools, like pull requests and merge requests, which not only preserve a record of decisions made, but also allows stakeholders to chime in.
As for 'clean code', it all depends on your approach, and your goals. If you're an OOP or FP maximalist, especially when the team is working in a multi-paradigm language like JS, TS, Rust, Ruby, Python, etc., there's absolutely many other factors to consider, than what's "idiomatic". Sure, there's an easy way and a hard way to solve a problem, and sometimes you can contribute your own thoughts and experiences. But this isn't just your codebase. It's your team's, other team's, future teams, and past teams.
Often, I find performance to be underappreciated, but performance is also subjective until it can be measured. Your tools and your review process, your communication process and perhaps even documentation process (but use sparingly, just to communicate objectives and areas of concern, rather than winding up as a maintenance sink, in addition to tests and review), are the major things you'll come to lean on.
I might also say, your approach matters, and using the term 'cleanliness' as a metric to describe code quality is highly subjective, to say the least, and not always that helpful. Linters, code coverage, unit tests and integration tests, end to end tests / smoke tests, regression tests, and most of all, team communication, are your number one guiding factors here.
I will admit, to answer the question originally stated, I regret the approach I once took in my career. I subscribed to FP and/or OOP, "idiomatic" religions, and often was adversarial when challenging the decisions of others. I've had to learn to reign it in, and provide constructive feedback and discussing higher-order goals than can just be addressed through a cursory glance at a PR/MR.
Further, it's always a balance. No single prescriptive approach works everywhere. "It depends" is better than solutioning right out of the gate. Ask more questions, and don't just jump in and do the work. Take a healthy, balanced, measured approach. To some, it might come easy. To others, like me, I've had to learn that software development is more than just writing code, however clean it may be. Much more.