Return to Answer

As developers we are, the mindset should remain always as open as sceptical.

Open, because we don't know when a developer (no matter the role) may surprise us, and sceptical because we should be humble enough to accept that in the software engineery there are different ways to achive the very same goal and our solutions, as our rationale, could make sense for us, and make no sense for others.

  Behind a code smell there could be a great idea. Maybe, the developer didn't find the way to express it properly.

Due to we (humans) are terrible at communication, don't make false assumptions, be up for asking to the code owner about the code you have reviewed. If he/she failed at coding the idea under the code standars, as lead developer be ready for providing with guidance and mentoring.

It doesn't mean to say: "Do It as I say it should be. It rather means: Delve into this other approach, seek for references and feel free of asking in case of doubts.

Here the subjective approach. The objective approach, IMO, is very well explained here.

In addition to the link above, the set of objectives to be meet (maintainability, readability, portability, high cohesion, loose coupling, etc.), are not necessarily the Ten Commandments. You (and the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers". Once you have found the balance, try adding new objectives or change those that were proven to be unecessary or inefficient for the team.

I would suggest the usage of static code analysis for measuring the progress of the quality, according to the objectives of the team. Tools like SonarQube, provide us with Quality Gates and Quality Profiles that can be customized according to our priorities. It also provides us with a issue tracker, where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.

These kind of tools could be also a good starting point. But, as I said, keep yourself sceptic, you could find some rules in Sonar, to be meaningless for you, so feel free to ignore them or remove them from your quality profile.

As developers we are, the mindset should remain always open and sceptical at the same time.

Open, because we don't know when a developer may surprise us, and sceptical about our own ideas because we often forget that in software engineery there's not a single correct way to implement a solution. The rationale behind our solutions could make sense for us and make none for others. Behind a code smell there could be a great idea. Maybe, the developer didn't find the way to express it properly.

Due to we (humans) are terrible at communicating, don't make false assumptions, be willing to ask to the code owner about the code you are reviewing. If he/she failed at coding the idea under the company' standars, as lead developer be willing to guide him/her too.

Here the subjective approach. The objective approach, IMO, is very well explained in this question.

In addition to the link above, the set of objectives to be achived (maintainability, readability, portability, high cohesion, loose coupling, etc.) are not necessarily the Ten Commandments. You (the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers".

I would suggest the usage of static code analysis tools for measuring the progress of the quality according to these objectives. Tools like SonarQube provide us with Quality Gates and Quality Profiles that can be customized according to our priorities. It also provides us with a issue tracker, where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.

These kind of tools can be a good starting point, but as I said keep yourself sceptic. You could find some rules in Sonar to be meaningless for you, so feel free to ignore them or remove them from your quality profile.

As developers we are, the mindset should remain always as open as sceptical.

Open, because we don't know when a developer (no matter the role) may surprise us, and sceptical because we should be humble enough to accept that in the software engineery there are different ways to achive the very same goal and our solutions, as our rationale, could make sense for us, and make no sense for others.

Behind a code smell there could be a great idea. Maybe, the developer didn't find the way to express it properly.

Due to we (humans) are terrible at communication, don't make false assumptions, be up for asking to the code owner about the code you have reviewed. If he/she failed at coding the idea under the code standars, as lead developer be ready for providing with guidance and mentoring.

It doesn't mean to say: "Do It as I say it should be. It rather means: Delve into this other approach, seek for references and feel free of asking in case of doubts.

Here the subjective approach. The objective approach, IMO, is very well explained here.

In addition to the link above, the set of objectives to be meet (maintainability, readability, portability, high cohesion, loose coupling, etc.), are not necessarily the Ten Commandments. You (and the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers". Once you have found the balance, try adding new objectives or change those that were proven to be unecessary or inefficient for the team.

I would suggest the usage of static code analysis for measuring the progress of the quality, according to the objectives of the team. Tools like SonarQube, provide us with Quality Gates and Quality Profiles that can be customized to our priorities. It also provides us with a issue tracker where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.

These kind of tools could be also a good starting point. But, as I said, keep yourself sceptic, you could find some rules in Sonar, to be meaningless for you, so feel free to ignore them or remove them from your quality profile.

As developers we are, the mindset should remain always as open as sceptical.

Open, because we don't know when a developer (no matter the role) may surprise us, and sceptical because we should be humble enough to accept that in the software engineery there are different ways to achive the very same goal and our solutions, as our rationale, could make sense for us, and make no sense for others.

Behind a code smell there could be a great idea. Maybe, the developer didn't find the way to express it properly.

Due to we (humans) are terrible at communication, don't make false assumptions, be up for asking to the code owner about the code you have reviewed. If he/she failed at coding the idea under the code standars, as lead developer be ready for providing with guidance and mentoring.

It doesn't mean to say: "Do It as I say it should be. It rather means: Delve into this other approach, seek for references and feel free of asking in case of doubts.

Here the subjective approach. The objective approach, IMO, is very well explained here.

In addition to the link above, the set of objectives to be meet (maintainability, readability, portability, high cohesion, loose coupling, etc.), are not necessarily the Ten Commandments. You (and the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers". Once you have found the balance, try adding new objectives or change those that were proven to be unecessary or inefficient for the team.

I would suggest the usage of static code analysis for measuring the progress of the quality, according to the objectives of the team. Tools like SonarQube, provide us with Quality Gates and Quality Profiles that can be customized according to our priorities. It also provides us with a issue tracker, where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.

These kind of tools could be also a good starting point. But, as I said, keep yourself sceptic, you could find some rules in Sonar, to be meaningless for you, so feel free to ignore them or remove them from your quality profile.

As developers we are, the mindset should remain always as open as spectical.

Open, because we don't know when a junior or a senior developer may surprise us, and sceptical because we should be humble enough to accept that in the software engineery there are different ways to achive the very same goal. Our solutions, as our rationale, could make sense for us, and make no sense for others. And viceversa.

Behind a code smell there could be a great idea. Maybe, the developer, didn't find the way to express it. Or viceversa. Due to we (humans) are terrible at communication, be up for asking to the code owner about the code you have reviewed. If he/she failed at coding the idea under the code standars of the team, as lead developer be ready for providing guidance and mentoring.

It doesn't mean to say: "Do It as I say it should be. It likely means: Delve into this other approach, seek for references, feel free of asking in case of doubts.

Here the subjective approach. The objective approach, IMO, is very well explained here.

In addition to the link above, the set of objectives to be meet (maintainability, readability, portability, high cohesion, loose coupling, etc.), are not necessarily the Ten Commandments. You (and the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers". Once you have found the balance, try adding new objectives or change those that were proven to be unecessary or inefficient for the team.

I would suggest the usage of static code analysis for measuring the progress of the quality, according to the objectives of the team. Tools like SonarQube, provide us with Quality Gates and Quality Profiles that can be customized to our priorities. It also provides us with a issue tracker where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.

These kind of tools could be also a good starting point. But, as I said, keep yourself sceptic, you could find some rules in Sonar, to be meaningless for you, so feel free to ignore them or remove them from your quality Profile.

As developers we are, the mindset should remain always as open as sceptical.

Open, because we don't know when a developer (no matter the role) may surprise us, and sceptical because we should be humble enough to accept that in the software engineery there are different ways to achive the very same goal and our solutions, as our rationale, could make sense for us, and make no sense for others.

Behind a code smell there could be a great idea. Maybe, the developer didn't find the way to express it properly.

Due to we (humans) are terrible at communication, don't make false assumptions, be up for asking to the code owner about the code you have reviewed. If he/she failed at coding the idea under the code standars, as lead developer be ready for providing with guidance and mentoring.

It doesn't mean to say: "Do It as I say it should be. It rather means: Delve into this other approach, seek for references and feel free of asking in case of doubts.

Here the subjective approach. The objective approach, IMO, is very well explained here.

In addition to the link above, the set of objectives to be meet (maintainability, readability, portability, high cohesion, loose coupling, etc.), are not necessarily the Ten Commandments. You (and the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers". Once you have found the balance, try adding new objectives or change those that were proven to be unecessary or inefficient for the team.

I would suggest the usage of static code analysis for measuring the progress of the quality, according to the objectives of the team. Tools like SonarQube, provide us with Quality Gates and Quality Profiles that can be customized to our priorities. It also provides us with a issue tracker where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.

These kind of tools could be also a good starting point. But, as I said, keep yourself sceptic, you could find some rules in Sonar, to be meaningless for you, so feel free to ignore them or remove them from your quality profile.