Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Loved reading your post and really found an earlier me on both sides of the fence - both complaining about others writing "bad" code and writing "bad" code (bad in another way) myself.
Code that seems to superficially patch away a certain problem that might require a deeper analysis and more thorough fix is bad in my opinion (in early versions of our application we had plenty of "if customer = ... then ... else ..." code segments to implement specific behaviour for specific customers which is obviously a bad idea). However, trying to make code clean, DRY, ... at any cost might end up in "bad" code, too - as in code where you get lost in layers and layers of abstractions and redirections and need weeks or longer to figure out how anything actually works.
So far, the best solution we have seen here: We use git and let the team do reviews of each pull/merge request. The team has a vague collection of code standards, but most important requirements are that code should solve the actual problem (obviously) and the reviewer should be able to understand how it works without too much ado.
Loved reading your post and really found an earlier me on both sides of the fence - both complaining about others writing "bad" code and writing "bad" code (bad in another way) myself.
Code that seems to superficially patch away a certain problem that might require a deeper analysis and more thorough fix is bad in my opinion (in early versions of our application we had plenty of "if customer = ... then ... else ..." code segments to implement specific behaviour for specific customers which is obviously a bad idea). However, trying to make code clean, DRY, ... at any cost might end up in "bad" code, too - as in code where you get lost in layers and layers of abstractions and redirections and need weeks or longer to figure out how anything actually works.
So far, the best solution we have seen here: We use git and let the team do reviews of each pull/merge request. The team has a vague collection of code standards, but most important requirements are that code should solve the actual problem (obviously) and the reviewer should be able to understand how it works without too much ado.
Maybe, after all, this one still holds true: mobile.osnews.com/story.php/19266/... ;)