IUPAC-InChI / InChI

Main InChI repository
https://iupac-inchi.github.io/InChI-Web-Demo/
MIT License
69 stars 9 forks source link

The ideal developer - part of a Faraday discussion paper from Frank Neese #47

Closed schatzsc closed 2 months ago

schatzsc commented 3 months ago

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

JanCBrammer commented 2 months ago

Closing this as "nice to know, not actionable".