Anything you can do, can I do better?

Another ETC post. There are others:
Tutorial days
Conference days
My retrospective

Up until recently, I was assuming something very simple: There's nothing an average developer can do that I can't (and vice versa) - Yes, there are some differences in the experience we have,  but overall we have the same basic training, speak the same language and discuss software design with each other. So, with the exception of those superstars you see here and there that are clearly better programmers than their peers, I considered myself equal.

Then I went to ETC, where I heard Liz Keogh speaking on Cynefin, and creating safe-to-fail experiments. One of the basic assumptions she has there is that testers are good at finding problems, and developers are good at coming up with ideas to solving problems (even ideas that don't work). What does it mean "testers are not good at coming up with solutions"? Surely I can do that, I solve problems all the time at work. Don't I?
There were two things that happened and pretty much convinced me there is a point in this. The first, is the talk I had with Liz after the tutorial day where I was bombarded with a series of questions that led to that "oh..." moment, and the second is Liz talking about how people have tend to respond to new ideas with the phrase "That won't work because...", which I realized that I do a lot.
So, are testers less efficient in find solutions? Are testers so constricted by spotting possible fail points that they can't act?
The more I think about it, I tend to say yes. As a general rule of thumb, I can see how this can be true. Of course, this is not a yes\no question, but rather a scale - and the exact position on which a person stands had some other factors that affect it (such as the experience in doing similar things, knowledge of the field in which an action takes place, etc.), but in general, it makes a lot of sense - Testers are tasked, on a day to day basis, to find potential problems, to poke at the perfect model someone has built and find weak spots in it. Developers, on the other hand, start almost every really new task by "creating a proof-of-concept", something that will sort-of work and teach them how to approach the problem in full scale. I take it for granted that I test better than most developers with equivalent experience because I have invested a lot of time in becoming better at it, and that they are probably better at coding since this is what they practice. But practicing a skill does not only mean getting better at it, it means tuning your mind and habits to it, and if some other skill is opposed to that, it will be that much harder to acquire.
Also, one other thing that is important to keep in mind - This mindset is not the permanent. People can, and do function successfully in both roles, though probably not simultaneously (I think I recall someone saying it takes them about a week to do this mental shift).

I took three things out of Liz's talk -

1. There is an important place for asking the difficult questions when setting out to try and solve something. It part of what makes an experiment "safe to fail" (which was the title of the talk). Putting this kind of lens gives me another tool that will help presenting questions at the context they are relevant to (e.g. - not going into "where should we put this bit" during a high level description)
2. I, too, have my limitations. Now that I'm aware of one of them, I can act to make sure it's used properly (for instance, when I spoke with one of the developers in the team about the architecture of a new piece of software we're planning, I wrote down my questions instead of interrupting. By the end of his explanation, half of the questions were answered, and I could provide feedback that was more relevant. And how is litening relevant to Liz's talk? Knowing that what I'm about to hear is an imperfect solution that "generally works", the small problems were no longer blockers, and so writing them down is more useful than stopping the whole train of thought). 
3. I need to practice my "let's do it" mindset - It's true that I'm a tester, but I still need to solve some problems, and there's more to me than just work. As long as I keep tabs on my "professional pessimism", being able to flow with an idea is useful.

זה פוסט נוסף על כנס הבדיקות האירופאי. כתבתי עליו קצת קודם (באנגלית בלבד):
יום הסדנאות
ימי הכנס
משוב קצר

עד לאחרונה, יצאתי מנקודת הנחה פשוטה - אין שום דבר שמפתח תוכנה ממוצע יכול לעשות ואני לא, ולהיפך: אין דבר שבודק תוכנה ממוצע יכול לעשות ומפתח לא. כן, יש לנו קצת הבדלים בניסיון ובכישורים שבחרנו לפתח, אבל לשנינו יש את אותה הכשרה בסיסית, אנחנו מדברים באותה השפה ודנים יחד על הדרך בה נעצב את התוכנה שלנו. אז, אם נשים רגע בצד את אותם מתכנתים מבריקים שגם טובים בבירור מאלה איתם הם עובדים, הנטייה שלי הייתה להניח שהיכולות שלי דומות.

ואז הלכתי לכנס, שם שמעתי את Liz Keogh מדברת על Cynefin, ועל איך ליצור ניסויים שבטוח להיכשל בהם. אחת מההנחות שהיו לה שם היא שבודקי תוכנה טובים במציאת בעיות, ואילו מפתחי תוכנה טובים במציאת מגוון פתרונות (כולל כאלה שלא לגמרי עובדים).
רק רגע, מה זאת אומרת "בודקי תוכנה לא טובים בלמצוא פתרונות"? בטח שאני יכול לעשות את זה. אני פותר בעיות בעבודה כל הזמן. לא ככה?
היו שני דברים שגרמו לי לבחון מחדש את ההנחה הזו שלי. הדבר הראשון היה שיחה שהייתה לי עם ליז בערב שלאחר יום הסדנאות, בה בקשת הדגמה הובילה לרצף מהיר של שאלות שבסופו נותרתי עם תחושת "אה, כזה...", והשני היה רגע קצר במהלך ההרצאה שם היא הזכירה את הנטייה האנושית להגיב לכל רעיון חדש ב"זה לא יעבוד כי...", בו שמתי לב שזו פחות או יותר התגובה האוטומטית שלי להרבה מאוד דברים.

אז, האם בודקי תוכנה פחות יעילים במציאת פתרונות? האם בודקי תוכנה כל כך מוגבלים על ידי איתור הבעיות האפשריות עד שהם לא מסוגלים לפעול?
ככל שאני חושב על זה יותר, הנטייה שלי היא לומר "כן". ככלל אצבע, אני בהחלט יכול לראות איך האמירה הזו נכונה.  כמובן, לא מדובר כאן בשאלה בינארית של כן ולא, אלא בסקאלה - והנקודה המדוייקת בה אדם נמצא על סקאלה מושפעת מגורמים נוספים (כמו ניסיון עבר בבעיות דומות, כמו מידת הידע על תחום הבעיה, וכד'). עם זאת, באופן כללי זה מאוד הגיוני. בודקים נדרשים מדי יום למצוא בעיות אפשריות בפתרונות, למצוא חורים במודלים המושלמים של אחרים ולאתר את נקודות החולשה שלהם. מפתחי תוכנה, מצד שני, מתחילים כמעט כל משימה חדשה באמת ב"הוכחת היתכנות", פיתרון חלקי שנכתב במהירות ולא מקיים את כל הדרישות מהמוצר המוגמר, אבל הכנה שלו מאפשרת למתכנת ולצוות ללמוד איך צריך לעשות את הדברים. אני מניח באופן אוטומטי שאני מסוגל לבדוק תוכנה טוב יותר מאשר מפתחים עם ניסיון מקביל לשלי, ושהם מתכנתים טוב יותר ממני, כי כל אחד מאיתנו השקיע מאמצים בפיתוח היכולת המרכזית שלו. אני "גם מתכנת", ומפתח טוב "גם בודק", אבל תחומי העניין והמיקוד שונים. אלא שתרגול של יכולת מסויימת לא מוביל רק לשיפור של היכולת הזו, אלא גם לשינוי דפוסי המחשבה וההרגלים בהתאם. ואם יש יכולת אחרת שבמקרה מנוגדת ליכולת שאני משקיע בה מאמץ, יהיה קשה יותר לרכוש אותה.
ועוד משהו אחד שכדאי לזכור - ההבדל הזה הוא עניין של הרגל (ושל נטייה טבעית ראשונית), לא גזירה משמיים. יש אנשים שמסוגלים להחליף בין התפקידים השונים ובין צורות המחשבה השונות (נדמה לי ששמעתי מישהי מספרת על כך שלוקח לה בערך שבוע לעשות את המעבר המחשבתי הזה).

שלושה דברים שנשארו איתי בעקבות ההרצאה של ליז:

1. יש מקום חשוב לגישה ה"פסימית"ולשאילת השאלות הקשות בתחילת הדרך. זה חלק ממה שמאפשר לנו לערוך ניסויים שבטוח להיכשל בהם (וזה, כזכור, היה נושא ההרצאה). 
2. גם לי יש את המגבלות שלי. זה נחמד לאגו שלי כשאני מתעלם מהן, אבל אם אני מודע לנקודות החולשה שלי אני יכול לעשות משהו כדי לפצות עליהן, או כדי לוודא שהן מתבטאות במקום הנכון (למשל - כשישבתי עם אחד המפתחים אצלנו על ארכיטקטורה של רכיב חדש, החלטתי להקשיב עד הסוף ולכתוב את השאלות שלי - עד שהוא סיים, חצי מהן כבר קיבלו תשובה, והשאלות שנותרו קיבלו יותר תשומת לב והיו רלוונטיות יותר.  איך זה קשור? כי כשניגשתי למשימה עם מודעות לכך שזה לא חייב להיות פיתרון מושלם מייד בהתחלה, הבעיות הקטנות שראיתי לא חסמו אותי מלבחון את המכלול השלם).
3. אני צריך לתרגל קצת את הגישה של "בואו נעשה את זה ונראה מה יצא" - נכון, אני בודק תוכנה, אבל לכולם יש בעיות שצריך לפתור, ולפעמים צריך לדעת לשים בצד את כל הפחדים והחסמים כדי לעשות משהו. אני יודע לעשות את זה עד רמה מסויימת, כדאי להשתפר בזה קצת. כל עוד אני לא מזניח את הפסימיות המקצועית שלי, זה כלי שכדאי שיהיה בארגז הכלים שלי.