Brothers in Arms, Part 2
Of knowing something... and understanding it
Shorter post this time, but I just felt compelled to share a little something that I came across earlier today. The second part in this series was inspired by Zeger van Hese's post Feynman on Naming. I really like this post. Not only because I agree with Feynman's father's methods, the points both van Hese and Feynman make but also because it strongly reminded me of a write-up named "From books people learn to remember, from mistakes to understand" I wrote back in 2001. To quote the write-up:
Humans have a vivid imagination, with the capability of visualizing practically anything within the limits of human experience. Yet, imagination and visualization are not the same as true understanding; one can not imagine experience.
What this means is simple: you may know exactly (neurologically and physiologically) what happens when a person sticks his/her hand on a hot oven plate but you do not understand what it really is, until you have done it yourself. If you have, it is possible to recall what it actually felt like and how you perceived the sensation, in addition to knowing everything there is to know about the event. Your understanding has grown deeper than anybody's who hasn't made the same mistake themself.
While it may be intelligent not to stick your own hand on a hot oven plate, after seeing someone else doing it, in a way it is unwise: you will be depriving yourself of an experience. The same applies to just about everything; sex, drugs, skydiving, you name it. This is where "common sense" steps in the ring - some experiences are best left unexperienced. Personally, I wish I will never have to go through - for example - any of the following: death of a child or wife, sexual abuse, long-term imprisonment, drug overdose, psychosis of any kind, becoming paralyzed etc. Some I can prevent with my own actions and decisions, some I have no power over.
To quote "Good Will Hunting" - one of my all time top-10 movies:
"So if I asked you about art, you'd probably give me the skinny on every art book ever written. Michelangelo, you know a lot about him. Life's work, political aspirations, him and the pope, sexual orientations, the whole works, right? But I'll bet you can't tell me what it smells like in the Sistine Chapel. You've never actually stood there and looked up at that beautiful ceiling; seen that."
This is exactly what I mean with the difference between knowing and understanding.
This, in turn, reminded me of another text I wrote, also in 2001:
Furthermore, so what if some scientist, poet or philosopher had already come up with an idea 100, 1000 or, 3000 years ago, that you came up with right now? Ideas aren't inherited, they don't transfer to children in genes and make their lives better. No, those children will have to gain an understanding of their own and, in that, some long-dead philosopher's profound ideas or incredibly deep understanding of the world, humans or life will have no effect. I'm not saying people couldn't learn from other people's ideas, no. What I'm saying is that reading those ideas does not equal understanding them - that has to come from inside yourself - the book or the long-dead philosopher can't do it for you. Thus, it's critically important to come up with ideas, in order to grow, develop and mature.
While I know this isn't directly testing-related, it's trivially easy to apply there as well. Just like van Hese wrote in his blog. I wish more people would do that - strive to understand, instead of just memorizing!
Brothers in Arms, Part 1
The art of making enemies?
I'm pretty sure it's not exactly the best approach around to start your life in the blogosphere (or anywhere, for that matter) by criticizing people, but hey, this blog is about protesting against poor software quality and quality always starts with the people involved (feel free to contradict me on that, I'd love to see someone explain to me why I'm wrong) - their attitudes included - so if a big part of the problem is in the attitudes and mental approaches of the people instead of the methods or techniques used, then that's what I will be protesting against today.
Starting the series...
As stated before, I will be posting a lot about my thoughts and views on what my colleagues in the testing world write in their own blogs and webpages or what I've been discussing with them through one medium or another.
The "honor" for the first post in this series goes to Rob Lambert for his excellent post Don't be a follower, be a tester, which woke a multitude of emotions and thoughts in me. Actually, the post irritated me. Not because I would disagree, but because he's so damn right in what he says. Briefly put: the irritating essence of the post is that the testing world is full of sheep bleating trendy catchphrases that make things sound really nice while actually meaning absolutely nothing (a favorite subject of criticism by Richard Rorty).
What really caught my attention were these three conclusions Rob made, based on the comments to one of his earlier posts:
We should not challenge the best practices of testing
We should not challenge the experts in testing
We should not talk about testing publicly
unless we are an expert or we know the experts.
My immediate first thought, after reading this was: What, exactly, constitutes an expert in testing? How does one become an expert in testing? Added bonus question: How, exactly, would knowing an expert in testing lend more credibility to what I am saying? I'm not the expert in question, am I?
So, how does this becoming-an-expert-in-testing happen? by not challenging the current authority figures? By not trying to come up with something new and/or improved? By not tackling the problems you see and just serenely accepting them (*baah*, said the sheep and continued munching on grass) as a necessary - and unchangeable - part of the world you're living in?
Let me answer that for you: It happens by stirring the hornet's nest, by challenging the consensus. It happens by telling people that they're doing things in an ineffective way, when they are, and then proposing an alternate way. It happens by not just accepting everything that's being force-fed to you without questioning. It happens by making mistakes, learning from them and then coming back stronger and better equipped than before. It happens by acknowledging the fact your thoughts and ideas could be shot down and torn to shreds in public, and still having the courage to present them despite the risk.
In brief: One does not become an expert (in testing) by being an idle spectator. You do it by taking a stand and making it your very own, personal, responsibility to change the way things are done. And that sure as hell won't happen if you don't throw your ideas out there for people to see and have a taste of. Of course, this is just my personal view - your mileage may vary.
Dramatic, I know, but sometimes being an opinionated tester is like the IT-world equivalent of being John Rambo...
As a sidenote: seems I just discovered a defect in WordPress while writing this post. 😛
Sidenote #2: seems I just discovered another defect in WordPress when trying to add more tags to this post (sorry Rob, WordPress refuses to store your name as a tag with Capital First Letters, I'm not trying to be disrespectful here...)
Endings and Beginnings
Like I said on the About:Petteri page, this blog is going to be a professional one (as opposed to a personal one) and will concentrate on software testing (plus agile and lean, which I didn't mention there), but this very first post is going to be more personal. It will soon be followed by more technical posts, though.
Referring to the title, endings often mean new beginnings. In this case the ending was on the personal side of life, while the new beginning is on the professional side of life. And a good change it was, too, since for the last few weeks my head has been so full of (technical) thoughts and ideas that I feel like it's going to burst if I don't get them out. This blog is a result of that change and will be just the place for getting it all out. Hopefully, to someone's benefit.
How did I end up in testing?
I've always seemed to possess the ability of doing the unexpected which has resulted, among other things, in my grandmother's clock radio going completely haywire when I was like 7 and simply decided to see what happens if I press certain two buttons at the same time. It has also slowly, but steadily prepared me for a career in (software) testing and, now that after few years of trying it out I've realized my potential in the field, it's also a strong driving factor for me and one of the root causes of my passion for testing. I want to help make things right in the IT world. I will not succumb to poor quality software for as long as there's something I can do about it. The name (and slogan) of this blog are no coincidence.
Sure, my chances of having an effect may be miniscule, all in all, but I'm a big fan of chaos theory (ever heard of the butterfly effect?) and that alone is reason enough to keep me going. Maybe I'm building castles in the air here, but my response (well, actually, I think it's an old Spanish proverb, but quick googling didn't reveal anything so I'm not sure) to that is: "If you don't build castles in the air, you don't build any castles". You need something to strive for - a destination or a goal. It doesn't have to be achievable, as long as it gives you direction, and that's exactly what's happening here.
Based on all of the above, I have finally truly awakened in this business of testing, and I can not get enough of it. I'm reading books about it like crazy. I'm following just about every tester blog I've come across so far (James Bach, Michael Bolton, Matthew Heusser, Markus Gärtner, "Michael the Explorer", just to name a couple), and I'm more than eager to take up any challenges you people out there might have in store. Even if I can't guarantee good results (as I might simply not be good enough if the challenge is a difficult one) I can guarantee a result. Bring it on!
And that just about covers everything I wanted to say in this post. Stay tuned as more technical writings will be added soon enough!
P.S. I would like to thank Markus Gärtner for encouraging me to start writing the blog - his comments were the deciding factor (after years of deliberation of doing it) that eventually led to this.
Latest entries
- A Little Help with Jolla
- An Object Is What the Object Does – Or Is It?
- Standards and Best Practices in Testing
- Physics, Testing and Academia
- Schools of (pro)testing
Archives
- December 2013
- April 2013
- June 2012
- May 2012
- March 2012
- December 2011
- June 2011
- May 2011
- March 2011
- November 2010
- October 2010
- August 2010
- July 2010
Latest comments
- on Standards and Best Practices in Testing
- on An Object Is What the Object Does – Or Is It?
- on An Object Is What the Object Does – Or Is It?
- on An Object Is What the Object Does – Or Is It?
- on An Object Is What the Object Does – Or Is It?
Latest tweets
- A couple new #Jolla tips in my blog post "A Little Help with Jolla". Check it out if you haven't done so already: http://t.co/SKT2NL0peb - posted on 22/01/2014
- ...without even trying if the system would accept longer messages (it does, the counter is more of a recommendation than an absolute limit). - posted on 21/01/2014
- Ah, automatic assumptions. Counter on a page says "x characters left" in a comment field and people complain about the length restriction... - posted on 21/01/2014
- Anyone read the book "Remedial Genius: Think and Learn Like a Genius with the Five Principles of Knowledge". If yes, what did you think? - posted on 05/06/2013
- How a tester might have been able to help prevent this with mere curiosity... "Neverwinter's economy just crashed": http://t.co/b1fJQxMAUM - posted on 20/05/2013