DEV Community

Discussion on: Philosophy of a Good Developer

Collapse
jmfayard profile image
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴 • Edited on

you make a lot of good points
I especially agree with 1) no blame game 2) look at the bigger picture 3) thinking about others 4) write stuff down.

I have some caveats, but they probably only mean the we work in different contexts

  • when writing things down for yourself - as opposed to for the team-, I would recommend to use pen and paper instead of yet another app.
  • I treat comments as code smells. if my code does not speak for itself, I should make it simpler instead of adding soon to be obsolete comments. if something needs to be documented, then in the team wiki or issue tracker, not in the code
  • I don't agree with the no shortcut rule. I choose the simplest way to solve today the problems that I have today, and I'm a big fan of waiting for future problems to materialize instead of fixing them preemptively
Collapse
kmwill23 profile image
Kevin

I somewhat agree on self-commenting code, but there are always cases were having the comment right there in another Dev's face is the right way to go.

If a bit of code is non-intuitive, a comment detailing it so other Dev's don't try to "fix" it may be appropriate. My personal example are coding patterns which solve major performance issues, but are not intuitive or self-documenting. Having that info in-context and not in a wiki is very important.

Collapse
vuesomedev profile image
Gábor Soós

Totally agree. Good points in the article, but the second one is a big no-no.
Comments make the code harder to read, not to mention obsolete comments.