One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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
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.
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
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.
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.