Assume But Verify #

One of the mistakes that it took me the longest to rectify was to always verify my if the changes I made to a piece of work actually worked. 

I always thought that not knowing for sure something works was a sign of weakness without realizing that delivering faulty work has far worse effect on one’s reputation. And as bad as it is to delivering faulty work, people will lose will no longer rely on your word.

They will lose credibility on you because they will asume you have dropped the ball and they must verify your work for you which will also make them resent you. This is not to say that nobody should review somebody else’s work but there is a difference between polishing and actually having to make sure the basics works.

Other than thinking it was a weakness, I kept doing this mistakes because eventually I would get a one thing right, deploy it and fix a problem and would get a few compliments like “you are so smart”. Now looking back I realize they weren’t remotely worth it and the amount of work it took to regain the trust of my peers was many orders of magnitude harder than just double checking my work.

I fixed my bad behavior by changing what I assumed from assuming the implementation works to assuming that my solution of choice is the right one for the issue at hand and then verify throughly the implementation and in some cases even ask for a second opinion before submitting my solution to a code review.