Write better code, or write less code?

Let's take a look at an interesting discussion:

I would rather have my students try their best to write better code than to write better annotations. --uncle Bob Martin (design pattern and agile development pioneer, "code neat Way" author)

I'd rather the students write less code than the "Better" code. --bob Marshall

Nothing is more useless than "a very efficient way of doing something that should not have been done". --peter Drucker

This raises a discussion about "writing better Code" or "writing less code."

A good compromise is to write better code in less code. The code's pros and cons are not the number of lines of code, or some other stupid thing, but the main look is meaningful code. In this discussion, the "less code" side is concerned not to make the code as compact as possible, avoid duplication, and so on, but rather they think it is reasonable, as little as possible or not to write code.

Should we focus on deciding what to do, what not to do, or whether we should strive to improve our software development skills?

In any case, no one can reasonably answer this question in the absence of a contextual environment. Let's take a separate discussion here.

Better code  

This is from the developer's perspective. In most large software development companies, there is little direct connection between developers and product managers or product owners, which means that managers know little about the product's build knowledge or even know nothing about it. &NBSP

Of course, as a developer, I can and should share some of my ideas about building specific features, but I'm not likely to have enough information to make the right judgments in many cases. For example, I don't think I should add a damn function, even if I'm right, but if the client gets added, my opinion is less likely to be accepted. Of course, not exactly, you can convince clients to change their minds, but that's very rare. &NBSP

If you have ever participated in a large contract project, each detail has been identified in the early stages, and because of internal political reasons, no one in the customer wants to change anything, you know what I'm talking about. If you haven't worked in a similar company, you're lucky. &NBSP

In this case, it's best to focus on building better code, not less code, because it's hard to say what makes sense is less code. &NBSP

Less code  

This is the point of view of the product manager. For them, their primary focus should be on building fewer code. Yes, I know they don't write code, but it should still be their primary goal. &NBSP

Product managers should know which features can enhance the value of the product and which cannot. They are usually more suitable for discussions with customers, such as what the customer wants, the cost, the unnecessary functionality, the unwanted code, and so on. &NBSP

As a developer, your leaders want you to create more value, or less waste, and focus on building fewer code. Of course, you are free to choose to write better code, or less code, but it seems wiser to choose the latter. At the same time, your productivity depends largely on what you do, so you should do more with less code and focus on the quality of the code, rather than using a lot of code to solve the problem. &NBSP

Obviously, there is no definite answer to this debate. Standing in the position of the product manager, I would advise Peter Drucker, and for the developer, I would suggest Bob Martin's view. &NBSP

Original in English: code Better or code less?