I can see where he's coming from. I started around the same time he did and from my point of view from my experience, perhaps I can further explain how I see it.

>Performance is last ? Code length is more important than performance? That's wrong. Also correctness is not mentioned at all surely that has to be in that list.

Depends on the scenario. Early in my career I was maintaining a scheduling DSS. You would enter in some appointments and it would consider a bunch of rules the users would create and find an appointment with matched resources. It was very cool and I really got into it. One of our test cases was scheduling 12 related appointments all at once. After some tuning, our system could do it in about 10 seconds, give or take. I decided to give a prototype a whirl with different ways to store and process everything (in memory) and got it to schedule these 12 related appointments in under a second. I showed my boss and he was impressed, but ultimately said, "the user's don't care about the difference between 10 seconds and 1 second, it's 1000x faster than doing it on paper." When the OP says performance last, I feel this is what he means. Some developers tend to tunnel vision on picking the best set of algorithm and caching mechanisms above all else, allowing the product to face delays when no-one cares about the difference between 10 seconds and 1 second. Of course, this is dependent on the solution. If you are google or Netflix trying to serve millions of users, performance matters. Most of the time, great is the enemy of good in this regard, especially in enterprise apps. Also, you can always tune trouble spots later down the road.

>I bet this person has had a problem with a dep a few years ago that caused a lot of emotional damage and the response is to never use 3rd party deps where possible.

I write stuff in house whenever possible. I've been burned by external libs plenty of times, and there is one I have in my current codebase I wish I didn't. It depends on the quality of your developers, for really good teams, this isn't a big deal at all. I use third party stuff for more specialized libs like image conversion and whatnot. The benefits of in house libs is they only do what you need, so they are tight and when something goes sideways, a smaller codebase trying to satisfy 1 use case is easier to understand than a large lib trying to satisfy 10 difference use cases. Plus, you don't always have access to the source code of third party libs.

>> Good code doesn’t need documentation
>This is impractical at the end of the day you'll need to have something for the user to lookup for reference.

Yes, I'm torn on this. I've written plenty of documentation that nobody has ever read but me though. If he means "code with good comments," I'm ok with that. External documentation outside of good tight specs is hit or miss. A lot of it is just check boxing.

>Most devs don't get to decide this they will be told to do X by someone in a large org and given a brief description of why. Refusing to do your work until you fully understand a problem will lead to dismissal.

I don't disagree this happens, but if it does, you're probably in an environment that doesn't respect you, your work or your growth in the company. Get out ASAP. I always explain to my devs why I'm doing something; mainly so they won't write some funky code because they don't understand the problem.