Junior dev: "I don't understand this code, therefore there must be something wrong with it. I'm gonna rewrite it."

Well, readability counts. Chances are the code is really bad as in hard to change or hard to debug.

@Huuugo readability is very important, but chances are junior dev are too inexperienced to know wth they are talking about (this one at least)

and also, how can you rewrite something you don't understand?

@DankestDev You appeal to authority. That's a common logical fallacy. You should rewrite your unreadable code.

Also, one does not need to know why some code works as long as its purpose is clear. Because you have commented and documented your code, right? Its purpose should be clear then.

Magically works?
*yeah, of course. it does every time*

@nulloperator I disagree. Readability is important, but this is what usually happens:

"Our junior devs do not understand SQL, so we rewrote everything to select * from table. We join and constrain data in PHP. Sure, it's less efficient, but we solve that with a giant redis layer, and more load balancers"

Too often I see security, data safety and integrity, orthogonality and efficiency sacrificed for readability.

If a junior dev starts rewriting code... He did not ask for help or noone felt responsible to help him...

Both things should be fixed...

And sometimes code ist complex, so even as a non junior dev you will have to ask...

If the junior dev does not want to learn and wastes time by being lone wolf instead of team player, well - fire him.

@Huuugo some code solves complicated problems and needs to be complex.

@apisarenco I completely disagree.

"You can make your code so complex there is no obvious bugs, or you can make it so simple there obviously are no bugs."
- not by me, but forgot the quote's author

From the zen of python:
If the implementation is hard to explain, it's a bad idea
If the implementation is easy to explain, it may be a good idea

@Huuugo well you can disagree all you want, but complex problems require complex solutions. It's that simple. If you don't know what I'm talking about, you never faced complex problems then.

A junior is not going to understand it.

Example:
Write a middleware API once, and consume it on your consumer, without ever updating the middleware API, even though the main API is constantly changing.

Why? Many reasons:
1. Original is purely XML API with bad date formats, but you need a flexible JSON/XML REST API with proper date formats.
2. You have to cache frequent calls in the middleware because of network restrictions.
3. You have to run the response past a heuristics engine to check for malware before returning it to the consumer.
4. You are prohibited to expose the consumer to the internet.
5. You have to translate API-provided Customer IDs with your own Customer IDs because you have 6 consumers and you don't want to implement this for each and every one of them.

@apisarenco I think every complex problem can be divided into smaller, simpler chunks that are easy to understand. Complex problems often lead to bad solutions because it's hard to manage that complexity and not every dev is a software architect. For almost every point in your list I would expect a whole Module/package that solves that particular problem. E.g. Spring solves this sort of stuff quite nicely

@apisarenco
1. ORM
2. Key/value store
3. API gateway with plugged in AV
4. Don't really know what you mean by that
5. One interface per consumer and API versioning usually solve this

@Huuugo ORM has nothing to do with it. Caching is not the problem, and neither are the rest.

The problem is that the middleware should translate the call, make it more "standard", more secure, and work as an isolation layer between the internet and intranet.

The problem is actually translating the calls.

@Huuugo
4. The consumer is the client that uses the web service. It's an intranet app that should not have any access to the internet, for example, because of security reasons, because it's a large corporation or something and HP has disabled updates on their 2005 installation of Windows XP. Whatever. Different reasons. But isolation is a frequent "solution" to security in large corporations.

@rantalicious of course not. But then again an incompetent dev would always defend his code no matter how bad

@rantalicious you'd be surprised :). I've been part of such a deal within my first 2 professional years. Junior as it can be.