Addition to programmer's oath.

[blogodisiac]

I shall not leave a known issue unaddressed.
I shall test the code I write to the best of my ability and knowledge of usage patterns.

[mo-g]

I don't like the wording of the second one.

I shall treat testing and coding as equal in both validity and importance.?

[blogodisiac]

@mo-g: I somehow feel the "treat testing and coding as equal" is not binding enough. Feel free to put in what you think portrays my emotion of testing the code thoroughly.

[mo-g]

@blogodisiac Just to confirm, I have no commit rights on this repo. Just another interested party making an attempt at constructive criticism. 🤞

[mo-g]

@blogodisiac What's your opinion on the importance of Documentation?

[Widdershin]

@mo-g @blogodisiac I appreciate the feedback and discussion.

I shall not leave a known issue unaddressed.
I shall test the code I write to the best of my ability and knowledge of usage patterns.

I appreciate the sentiment underlying these, but they can be often hard to uphold, especially when working under constraints. Should we be including tenets that might not be achievable in a professional context?

I feel that the closest existing tenet to these two is number 8:

I will be diligent and take pride in my work.

To me, addressing known issues and writing quality automated tests is part of diligence, but perhaps the sentiment I was going for is not communicated here?

What do y'all think?

[mo-g]

Perhaps it might be good to append to 8. instead, something like...

I will be diligent and take pride in my work, committing to achieving the highest quality I can in my work.

N.B. I chose quality over standards to prevent the linguistic confusion between 'standards of work' and 'coding standards'.

[Widdershin]

I like the idea of extending 8., but I personally don't think I could swear to always achieve the highest quality I can in my work, mostly because there is a tradeoff between time/money and quality.

If achieving the highest quality possible meant that your endeavour failed, that would not be ideal.

I think there's a subtlety here as well: quality is important where a lack of it causes other people to suffer. I think that's part of where @blogodisiac's points come from. Not addressing known issues and not writing tests can cause suffering, but if you're mucking about in a REPL and writing low quality code, that's probably not going to hurt anyone. Unless you're in a REPL in production, in which case quality is suddenly very important, because people might suffer.

[mo-g]

That's true enough, though as a programmer I was always taught to treat your experimental mucking-about code like production code, because you never know when someone will walk-past-and-tell-you-to/copy-your-code-and deploy it in production anyway. 😉

[bortzmeyer]

@Widdershin "Should we be including tenets that might not be achievable in a professional context?" Even in a personal context, it is not achievable. Days have only 24h.

On the other hand, @blogodisiac suggested "I shall not leave a known issue unaddressed", not "I shall not leave a known issue unsolved", which would have been wildly unrealistic. Tagging an issue as "I see the point but not today" addresses it, IMHO.

[blogodisiac]

@mo-g #documentation Programmers are well known for no-to-least documentation - let alone usable. But, the programmer should comment the code reasonably enough not just to indicate the flow but the thought process involved in writing that code - this helps the future maintainers of the code understand your mind space in using the constructs or data structures and the algo in general. This is very pertinent since most fixes to problems found later are addressed with band-aids rather than solutions due to various constraints. At least, such comments would help implement a better solution. Yes, to answer your question, we must add something about documentation in the line of better comments. But pinning the programmer down to document their code, good luck with that.

[vassudanagunta]

This Oath is about ethics, responsibility and humanity, not about how to code or code quality, except indirectly as ethics, responsibility and humanity demand.

So I don't thing specific technical methodologies or any kind of technical specifics belong in it. I detracts from the spirit of the Oath, and and unnecessarily precludes alternate thinking on how best to do no harm.