Pond's Laws of System Design (A.K.A. Something to Ponder)

In my eternal effort to keep up with everything, or at least the things related to what I do…  I found an excellent law of system design list by Mr Ward Pond over on his blog.  I always find lists interesting, as statistics show almost everyone does, but these types are actually of use.  Many of the points are true to the occupation and definitely worth reading and acknowledging.  Some of my own thoughts around Mr. Pond’s Laws are generally reinforcing the general undertone of each law.  The ones I generally have 2 cents to add are following.

#5 Pond mentions that the “value you add goes triple for the value that the job brings to you”.  I absolutely agree.  I would also add the correlation that without value being brought to the individual doing the job it is a worthless job.  If you can’t enjoy, even in some small way, you should probably either find a way to enjoy somehow or get the hell out of that type of work.  When #5 goes the other way, not only do you not add value to what you do and your coworkers efforts, but you detract extensively from your own life.

#6 “Play” with the product.  If you aren’t, are you even really doing your job?  Something I commonly ask of advanced DBAs, Software Developers, and even Architects that don’t write code anymore.  What are you doing then?  Why are you not doing it?  Get back to it, if you aren’t playing, something is big time wrong!

#8 Please, I implore people to know this, to simply know thy self.  Without this, you will never be good at the whole aspect of human contact, which regardless of what some might think, is pivotal to doing a good job at anything!

…and that leads me to the last law that I really must reiterate…

#10 Your code is a communication with someone else, who will likely come after you are gone.  This is true, it is frustrating, and sometimes agonizing, but simple leave some kind of whimsical comment is better than nothing.  I’ve made gross errors in this area of my career, but ongoing I always try to improve my comments.  On the same note, but the other end of the view, make sure you learn to grasp and read comments and code.  Make sure you actually know the technology (see #6), don’t blame inadequate knowledge and ability on the “guy that left” because you don’t understand patterns, objects, the language, the technology stack, or other scope.  Always learn, keep learning, and don’t stop.  With enough knowledge, even the most cryptic spaghetti isn’t all that bad to fix.