One of the hardest lessons I've discovered in the last few years here is that confirmation-bias is bad, and it's even worse when it's acknowledging bad and yet is an encouraged practice.

In a way, everyone is hired for their expertise. Thus, part of your job's main responsibility is to use your knowledge as an expert and apply that to any situations that come your way. You'd think that in most organizations that since the management have hired you in the first place, that they would believe in what your knowledge and experience will tell you.

Funny thing is, that's often not the case! Makes you wonder why though.

When i stepped into one of the projects and saw the quality (or lackthereof) of the design and implementation, i was quite shocked by it. Simple failure test cases would break it in minutes, and caused a lot of unnecessary discussions and arguments about what some testers were testing and passing.

Using notepad as a simple example (my project wasn't notepad!), it was almost like this:

- requirements stated that notepad should load a text file and display it within the notepad program window

For testers that would just want to confirm the design, they would literally find the easiest text file available and load it into notepad. Test PASS!

Now with hindsight, this is a very very bad requirement. Bad in terms of it being very unclear, immeasurable and unspecific enough. In simpler terms, it's too vague.

In a way, this situation also taught me to think and use phrases almost in a legal manner. Sometimes maybe too extreme, especially in new hires' eyes, but it's something that you'd learn from mistakes made, by others and yourself.

Mistakes will be made over and over again. I hope that they will be different mistakes, and lessons can be learnt from each mistake made.

I personally have a training style where I try to give people as much leeway to make mistakes as possible. Sink or Swim, so they say.

My opinion is that if people are good and are personally accountable to themselves, they would want to find their own ways to do certain actions in their jobs. It's harder to tell folks what are bad, but it's easier to let them make the mistakes, and show them what the correct (or more desirable) actions are, and let them make the call to think about them. This allow folks to grow 8).

Which is my number one reason for not having documentation! hahaha..

I think this philosophy came as a result of a few good mentors throughout the years: Grabbing the good points from mentors such as Tony, Teck, Chan, Sherman and Randy, avoiding the bad points from other folks, and adding a little "Jonathan" spice, and out come my training philosophy.