Even arts have technical rules

[bortzmeyer]

"warmth, empathy and understanding may outweigh a clever algorithm or technical argument" That's quite dangerous. Yes, programming is also an art and cannot be completely analyzed. But technical arguments cannot be defeated by warm and fuzzy feelings. Unlike a pure work of art, which cannot be judged in an objective way, a program works or doesn't.

I suggest to keep only "I will remember that programming is art as well as science and that some issues are hard to address purely by technical arguments."

[mo-g]

There was an interesting talk that touched on this at EuroSciPy 2016. I've also experienced it in practice.

As some hypothetical scenarios that I've actually seen and so are not hypothetical in any way;

• The case where a user submits their first PR to a project. It fixes the issue, but you can (as a more experienced coder) see a more elegant solution. Do you: Merge their change and give them confidence and encouragement to keep committing - OR prioritise the technical 'purity' of the code base and reject/make them rewrite their change so that your code is faster or more readable?

• The case where two or more collaborators are at loggerheads over a particular change, because both see their viable solution as technically superior. Obeying this Tenet would help them resolve the issue by encouraging them to prioritise other factors over just their own code.

I don't think this line mandates accepting a non-functional solution over a functional one to make someone feel better, or does it mandate always implementing the solution that will make the most people feel warm and fuzzy - it simply encourages us to remember that there may be times where emotion can guide or overrule our logic.

[bortzmeyer]

@mo-g There is obviously no ready-for-all-cases solution for the first use case. The project leader must exercice its judgment, keeping in mind both the technical issues and the sensibility to the submitter's feelings. But in some cases, it is clear: if the PR introduces a security issue, the project leader's duty is to reject it. Code is made for users, not for the programmer's ego.

When I contribute to programs, I certainly prefer a rejection with technical arguments than a nasty feeling that it was accepted just to avoid discussions. You accept any work from children, in order to encourage them, you don't treat adults the same way.

[mo-g]

But - in some cases it is not clear. I do feel that the inclusion of the word 'May' defangs some of your arguments. This Tenet isn't proscribing the prioritisation of technical arguments - it just serves to remind that not all disputes can be solved purely on a technical discussion and there are possible cases where other approaches should be considered.

How would a reweighting of the phrase sit with you? Something along the lines of Clever Algorithms and Technical Argument are the soul of programming, but there may be times where warm and fuzzy is good too? (Though, obviously not phrased in that exact way.

[bortzmeyer]

@mo-g This reminds me there is a tussle between the need for a short oath, with nice catch-phrases (just as "First, do no harm") and the need for explanations, details, nuances… May be the solution is to have two texts, the oath itself and some "Comments on the oath" for the people who want to examine details.

[mo-g]

"Commentaries on the I Ching"?

[zyphlar]

This sounds very close to the Ethics of Care in that it emphasizes how leaders should both care for their work product but also care for the programmers who report to them, in all the varying situations they may find themselves. The Engineering Ethics page touches on this with "Engineers shall continue their professional development throughout their careers, and shall provide opportunities for the professional development of those engineers under their supervision" -- Torvalds justifies his harsh attitude towards quality by saying it results in better programmers and better code over time. I barely buy that argument because at least it still ties back to the idea of caring for others' professional development.

[bortzmeyer]

Since you mention Torvalds, one can also note that the attitude of the project leader depends also on the importance of the project. Unlike Torvalds, I manage only small programs, which are not as strategic as the Linux kernel. I can afford to take risks and to accept more patches. I am kinder to new contributors, not because I'm a nice guy (I'm not) but simply because I have much less contributors and less patches to review (Torvalds is probably drowned under the proposals).

As a programmer, I wouldn't want my patches to be harshly rejected. As a Linux user, I'm glad Torvalds is strict. Who should we prioritize? Users or programmers?

[zyphlar]

I think there are two separate issues being overlapped here which deserve their own phrasing. Care must be taken with the skills and emotions of colleagues, and care must be taken with doing quality work. I think good work is being covered elsewhere and this may be more about treating colleagues well. It'll have to be up to the individual to strike the best balance between rules they can at any given time (I see a related issue asking about prioritization...)