> Good code doesn't need documentation.

Here's the full quote from the article: "Good code doesn’t need documentation, great code is well documented so that anyone who hasn’t been part of the evolution, trial & error process and requirements that led to the current status can be productive with it. An undocumented feature is a non-existing feature. A non-existing feature shouldn’t have code." Maybe you're just objecting to the first part, but he isn't saying "don't document".

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.

Eeek

> our system could do it in about 10 seconds, give or take

> user's don't care about the difference between 10 seconds and 1 second

They d,o but your boss doesn't. That is until they complain. Happened to me multiple times over the past 16 years. No one cares about Performance until it's too bad then suddenly it a huge problem. I've been in several projects where fixing performance was a rewrite due to this attitude. Performance should be much higher on the list period. Also not having correctness is insane.

> I've been burned by external libs plenty of times

Yes and you're not the only one but the "I've been burned therefore noone can use 3rd party libs" is childish.

> A lot of it is just check boxing.

That's presumably coming from someone who has a lot of experience and is very familiar with the domain. For those who are new to the company and new to working in tech in general good documentation is a godsend.

> Get out ASAP

Ah yes, heard this many times. It's completely impractical and often comes from people in an privileged position. Not all devs are paid high amounts and can quit their job on a whim.

>They d,o but your boss doesn't

You don't know. You don't work there. You're just making stuff up to bolster your position. Users never complained about the speed of the system based on that algorithm.

>Yes and you're not the only one but the "I've been burned therefore noone can use 3rd party libs" is childish.

No one said that but you.

>is childish

If you can't attack the position, attack the person, right?

Well we'll just have to agree to disagree. I'll run my team how I see fit and you run your team how you see fit.

imho simplicity ist the most important trait.

I have a rule i derive from that: like economy of movement there must be a requirement for every change/code.

when nobody says what is slow, how can I optimize. I would pick simplicity and maintainability every time over some undefined performance. Especially as high performant solutions tend to be rather complicated compared to simple ones...

3rd party libs come at a price that is often overlooked/ignored...