Q:

Can I criticise the more senior developers around me for not writing clean code?

I am a junior developer.  Although I already programmed in different languages for the last 5 years I still have a hard time debugging more complex issues.
On the other hand I like clean code and try to write expressive, short functions wherever possible (at present in React).  However, it annoys me that around me other developers who are more senior than I am don't write clean code, produce long and snarled methods that are not completely bad but could be easier to read.
My question: Would you bring this up in a meeting - like a 1:1 with another developer? Or would you just keep your mouth shut because you are more junior and wait for the critique until you are senior enough?

A:

Obviously, criticizing your elders isn't a great move and should be avoided.  Belittling juniors is also a bad thing.
One thing to remember is that loose coding practices doesn't necessarily lead to poor compiled code.  So, if it works, it works, and the guys know how to maintain their own code.  People can, and do, get defensive about their own parts of the code-base.
What you can (and should) do is maintain the best coding practice you can within your own portions of the code.  Allow that to speak for itself when other team members see this in the code-base or you're talking through examples.
If you need to work on a part of the code-base that someone else has worked on and you have problems in following it, then by all means ask the developer to talk through the relevant portion so that you can quickly complete this coding task.
You don't have to point out the bad coding practices from other people - take care of your own and hope that other people notice and also take on board what you're doing.

A:

All code should be peer reviewed (but I've worked in a lot of places where that never happened). How clean is clean? There should be coding standards and guidelines; ask for them. As to how "picky" you should be; that depends on the code being reviewed. Some people like having blank lines pointed out to them, and spacing. Others prefer you spot potential problems.
Don't keep your mouth shut because you're junior, but do be careful about how you highlight things. The aim here is not a blame game, but to collectively, as a team, improve the codebase. Try to suggest improvements. The code may not be "wrong", but there's usually something that can be improved, personal coding styles aside.

A:

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 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.)

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

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.

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 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.)

