No really an issue - but highly interesting Faraday discussion paper by Frank Neese (MPI Mülheim, lead developer of the ORCA quantum chemistry software package) with a section on "the ideal developer" and some "sins" in working on such large scale developments:
"(1) Always taking the shortest shortcut to meet one’s individual goals. This may
be characterized as a “no matter how” or “crash and burn” policy.
(2) Rewriting or changing other people’s code without prior notice or consent.
(3) Never documenting their code or leaving a comment as to why something
was done a certain way.
(4) Using in-depth knowledge of programming languages to “show-off” a highlevel
of sophistication. This is frequently combined with an unwillingness to
comment the code. Frequently, this results in very difficult, if not plainly
unreadable, code that tends to be not understood even by its own creator only
a few months later.
(5) Being afraid to break something may lead to uncontrolled “copy-paste”
approaches to development. With the best of intentions sometimes thousands of
lines of code are copied and pasted only to make a few minor changes at the very
end or change a few prefactors or signs.
(6) Implementing a useful improvement only in one part of the code but
lacking the commitment to make the feature consistent throughout.
(7) Leaving code parts that are known to be incorrect in the code without
warning or comments. This is ofen motivated by a lack of trust in one’s own
abilities or a lack of time or commitment.
(8) Trying to be funny during development. A funny name of a routine that
makes reference to, say, a certain movie character or celebrity may be considered
to be funny by a given developer at a given moment in time. However, this wears
off very quickly and what remains is cryptic function name that confuses later
generations of developers."
No really an issue - but highly interesting Faraday discussion paper by Frank Neese (MPI Mülheim, lead developer of the ORCA quantum chemistry software package) with a section on "the ideal developer" and some "sins" in working on such large scale developments:
https://dx.doi.org/10.1039/d4fd00056k
"(1) Always taking the shortest shortcut to meet one’s individual goals. This may be characterized as a “no matter how” or “crash and burn” policy. (2) Rewriting or changing other people’s code without prior notice or consent. (3) Never documenting their code or leaving a comment as to why something was done a certain way. (4) Using in-depth knowledge of programming languages to “show-off” a highlevel of sophistication. This is frequently combined with an unwillingness to comment the code. Frequently, this results in very difficult, if not plainly unreadable, code that tends to be not understood even by its own creator only a few months later. (5) Being afraid to break something may lead to uncontrolled “copy-paste” approaches to development. With the best of intentions sometimes thousands of lines of code are copied and pasted only to make a few minor changes at the very end or change a few prefactors or signs. (6) Implementing a useful improvement only in one part of the code but lacking the commitment to make the feature consistent throughout. (7) Leaving code parts that are known to be incorrect in the code without warning or comments. This is ofen motivated by a lack of trust in one’s own abilities or a lack of time or commitment. (8) Trying to be funny during development. A funny name of a routine that makes reference to, say, a certain movie character or celebrity may be considered to be funny by a given developer at a given moment in time. However, this wears off very quickly and what remains is cryptic function name that confuses later generations of developers."
D6466-FD24.pdf