Skip to main content
The Workplace

Return to Answer

Add another suggestion as per comments, add final section, and a few general tweaks.
Source Link
gidds
gidds
  • 2.3k
  • 2
  • 9
  • 13

  • Avoiding unnecessary changes to working code (keeping diffs manageable, avoiding introducing unnecessary bugs, &c).

  • Keeping related code so it can be seen together.  (No benefit from nice short functions if that just hidesobscures the complexity.)

  • Avoiding subtle language or performance issues.

  • Matching the style of other code.  (Don't underestimate the value of consistency in a codebase; once you're familiar with it, it can make code much easier to read and, understand, and maintain, reduce friction between developers, and avoid subtle bugs.)

  • Most developers are mediocre (even though we all think we're reallypretty good…).

  • Previous developers may have been in a hurry, and didn't have time to consider refactoring.

  • Previous developers may not have cared enough about clean code, or seen how to improve it.

  • Don't aim to make large changes simply to improve the code.  Instead, make improvements as you go along; when you fix a bug or add a feature, improve the code you're already working on.  That way, it's easier to account for the time spent, and it won't require any extra testing &c.  And over time, the quality will increase.

  • Don't criticise your fellow developers, or act as if you know more than they do.  Even if you do, that won't win you friends — and a good working relationship is important too.  By all means, suggest improvements, but in a constructive way, without blame.  And accept that they may not agree.

  • Run significant changes past a senior colleague first.  If any of the reasons above apply, it's better to find out about it before doing lots of damage!

  • Don't rewrite code just for the sake of it.  The original author may take it personally; and you want to be seen as working with them, not against them.  (Remember that what seems an obvious improvement to you may look very different to them.)  Also, each change brings risk; a decent test suite &c can reduce that, but changes aren't free, and being conservative can save headaches.

  • Accept that while improvingInstead, make improvements as you go along: when you fix a bug or add a feature, improve the code you're already working on. That way, it's easier to account for the time spent, and it won't require any extra testing &c. And over time, the quality iswill increase.

  • Finally, accept that while it's important, that's just one of several priorities.improving code quality is just one of several priorities.  Developer time is limited, and there are always compromises.  Sad, but true.

It's great that you care about code quality!  Too many developers don't.  But try to use your concern in a productive way that's good for the team as well as the codebase.

—

(I've been that young developer who wants to rewrite everything…  To some extent, I still do!  But I've also watched my own code being changed pointlessly or made worse by people whose priorities I didn't agree with, or who simply misunderstood it.  And I've struggled over codebases which used inconsistent formatting, naming, organisation, and style.  Ultimately, life's much better if the codebase works well together, and the developers work well together.)

  • Avoiding unnecessary changes to working code (keeping diffs manageable, avoiding introducing unnecessary bugs, &c).

  • Keeping related code so it can be seen together.  (No benefit from nice short functions if that just hides the complexity.)

  • Avoiding subtle language or performance issues.

  • Matching the style of other code.  (Don't underestimate the value of consistency in a codebase; once you're familiar with it, it can make code much easier to read and understand.)

  • Most developers are mediocre (even though we all think we're really good…).

  • Previous developers may have been in a hurry, and didn't have time to consider refactoring.

  • Previous developers may not have cared enough about clean code, or seen how to improve it.

  • Don't aim to make large changes simply to improve the code.  Instead, make improvements as you go along; when you fix a bug or add a feature, improve the code you're already working on.  That way, it's easier to account for the time spent, and it won't require any extra testing &c.  And over time, the quality will increase.

  • Don't criticise your fellow developers, or act as if you know more than they do.  Even if you do, that won't win you friends — and a good working relationship is important too.  By all means, suggest improvements, but in a constructive way, without blame.  And accept that they may not agree.

  • Don't rewrite code just for the sake of it.  The original author may take it personally; and you want to be seen as working with them, not against them.  (Remember that what seems an obvious improvement to you may look very different to them.)  Also, each change brings risk; a decent test suite &c can reduce that, but changes aren't free, and being conservative can save headaches.

  • Accept that while improving code quality is important, that's just one of several priorities.  Developer time is limited, and there are always compromises.  Sad, but true.

It's great that you care about code quality!  Too many developers don't.  But try to use your concern in a productive way that's good for the team as well as the codebase.

  • Avoiding unnecessary changes to working code (keeping diffs manageable, avoiding introducing unnecessary bugs, &c).

  • Keeping related code so it can be seen together.  (No benefit from nice short functions if that just obscures the complexity.)

  • Avoiding subtle language or performance issues.

  • Matching the style of other code.  (Don't underestimate the value of consistency in a codebase; it can make code much easier to read, understand, and maintain, reduce friction between developers, and avoid subtle bugs.)

  • Most developers are mediocre (even though we all think we're pretty good…).

  • Previous developers may have been in a hurry, and didn't have time to consider refactoring.

  • Previous developers may not have cared enough about clean code, or seen how to improve it.

  • Don't criticise your fellow developers, or act as if you know more than they do.  Even if you do, that won't win you friends — and a good working relationship is important too.  By all means, suggest improvements, but in a constructive way, without blame.  And accept that they may not agree.

  • Run significant changes past a senior colleague first.  If any of the reasons above apply, it's better to find out about it before doing lots of damage!

  • Don't rewrite code just for the sake of it.  The original author may take it personally; and you want to be seen as working with them, not against them.  (Remember that what seems an obvious improvement to you may look very different to them.)  Also, each change brings risk; a decent test suite &c can reduce that, but changes aren't free, and being conservative can save headaches.

  • Instead, make improvements as you go along: when you fix a bug or add a feature, improve the code you're already working on. That way, it's easier to account for the time spent, and it won't require any extra testing &c. And over time, the quality will increase.

  • Finally, accept that while it's important, improving code quality is just one of several priorities.  Developer time is limited, and there are always compromises.  Sad, but true.

It's great that you care about code quality!  Too many developers don't.  But try to use your concern in a productive way that's good for the team as well as the codebase.

—

(I've been that young developer who wants to rewrite everything…  To some extent, I still do!  But I've also watched my own code being changed pointlessly or made worse by people whose priorities I didn't agree with, or who simply misunderstood it.  And I've struggled over codebases which used inconsistent formatting, naming, organisation, and style.  Ultimately, life's much better if the codebase works well together, and the developers work well together.)

Source Link
gidds
gidds
  • 2.3k
  • 2
  • 9
  • 13

A few points in addition to the other answers:

Accept that, as a junior, you don't know everything :-)  There may be reasons for the style of code that you are unaware of, such as:

  • Avoiding unnecessary changes to working code (keeping diffs manageable, avoiding introducing unnecessary bugs, &c).

  • Keeping related code so it can be seen together.  (No benefit from nice short functions if that just hides the complexity.)

  • Avoiding subtle language or performance issues.

  • Matching the style of other code.  (Don't underestimate the value of consistency in a codebase; once you're familiar with it, it can make code much easier to read and understand.)

That said, it's also entirely possible that your changes are worth making!

  • Most developers are mediocre (even though we all think we're really good…).

  • Previous developers may have been in a hurry, and didn't have time to consider refactoring.

  • Previous developers may not have cared enough about clean code, or seen how to improve it.

In my experience, every codebase can be improved.  Even on code that I've written and worked on many times, I often spot improvements that I'd previously missed!

As to how to handle it, I'd suggest:

  • Don't aim to make large changes simply to improve the code.  Instead, make improvements as you go along; when you fix a bug or add a feature, improve the code you're already working on.  That way, it's easier to account for the time spent, and it won't require any extra testing &c.  And over time, the quality will increase.

  • Don't criticise your fellow developers, or act as if you know more than they do.  Even if you do, that won't win you friends — and a good working relationship is important too.  By all means, suggest improvements, but in a constructive way, without blame.  And accept that they may not agree.

  • Don't rewrite code just for the sake of it.  The original author may take it personally; and you want to be seen as working with them, not against them.  (Remember that what seems an obvious improvement to you may look very different to them.)  Also, each change brings risk; a decent test suite &c can reduce that, but changes aren't free, and being conservative can save headaches.

  • Accept that while improving code quality is important, that's just one of several priorities.  Developer time is limited, and there are always compromises.  Sad, but true.

It's great that you care about code quality!  Too many developers don't.  But try to use your concern in a productive way that's good for the team as well as the codebase.