These are well-written and highly consistent with my experience.
I especially like #8 when combined with #2:
Code is merely a moment in time that captured what we thought we knew about something. It’s not you. You may have wrote it, but since that moment (even if it was 3 minutes ago) you’ve grown, but the code has not. A conversation about code, good or bad, should never be personal.
Definitely goes both ways as far as code reviews go. Avoid accidentally coming off as personal, and avoid taking comments personally. This is the rule of charity. If code is always a liability, there should be an understanding that everyone’s goal is to minimize the surface of that liability. And that sometimes implies burning down and reworking reviews, time permitting.
Anyway, definitely sharing this around at work. Thanks for the excellent writeup.
I know you said they’re yours, but they resonate very much with me too. Especially 11 (“Teaching is a form of learning in disguise”) - this is true not only in formalised contexts (writing a tutorial, giving a class or running a workshop) but also when writing blog posts. To be able to learn as a side effect of sharing is something of great value to me.
Great axioms individually and they are even better all together in one list!
The only slight inconsistency in my opinion, in points 4, 5, 6 and 25, is the implicit assumption of a static good or bad system design.
I would add that what is a good design now can turn into a poor design after any functional change. So the system design should constantly be questioned, otherwise it will always end up violating the points above.
These are well-written and highly consistent with my experience.
I especially like #8 when combined with #2:
Definitely goes both ways as far as code reviews go. Avoid accidentally coming off as personal, and avoid taking comments personally. This is the rule of charity. If code is always a liability, there should be an understanding that everyone’s goal is to minimize the surface of that liability. And that sometimes implies burning down and reworking reviews, time permitting.
Anyway, definitely sharing this around at work. Thanks for the excellent writeup.
25 axioms are a Constitution :)
Does anybody have a collection of such posts? Axioms, rules, lessons learned, etc? I always find these posts really interesting.
I know you said they’re yours, but they resonate very much with me too. Especially 11 (“Teaching is a form of learning in disguise”) - this is true not only in formalised contexts (writing a tutorial, giving a class or running a workshop) but also when writing blog posts. To be able to learn as a side effect of sharing is something of great value to me.
I teach people to learn too. The fear of not being able to cover the subject in front of an audience is a great motivator.
Great axioms individually and they are even better all together in one list!
The only slight inconsistency in my opinion, in points 4, 5, 6 and 25, is the implicit assumption of a static good or bad system design.
I would add that what is a good design now can turn into a poor design after any functional change. So the system design should constantly be questioned, otherwise it will always end up violating the points above.