שמן נחשים להמונים Snake oil for all

Source: http://thehealthcareblog.com/blog/2016/06/28/the-patient-and-the-snake-oil-salesman/

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

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

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

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

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

נתחיל מהסוף - חשבתי שיהיה גרוע יותר, אז אפשר לומר שהופתעתי לחיוב. 

קצת יותר בפירוט, אפשר לומר שהסדנה קיבלה ניקוד מלא בסעיפים 1 ו4, דילמה לגבי סעיף 2 ונכשלה ממש מבחינתי רק בסעיף 3. 

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

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

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

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

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

---

A couple of years ago we had an opening for another tester in our team and I found myself interviewing a lot of candidates. It was a bit long and very painful, but one of the candidates left a lingering impression. Like with most candidates, we've asked him to solve a simple coding problem on the whiteboard. How simple? Simple enough so that I asked my brother (who's programming background at the time was the stuff taught in high-school) to solve it, and he had no real difficulty with it. The candidate sat and thought about it. He pondered and considered and then contemplated a bit. Then, with an outburst of honesty said "look, I'm an automation person, I'm not a programmer".
We managed to keep a straight face.

The reason I recalled this now is that last week I stumbled upon an advertisement for a "introduction to automation workshop", free of charge, only two hours long. You know, the stuff that is usually done to sell a longer, pricey course that will teach someone "automation" from scratch. Normally  I see these things and fume silently. Those workshops have a constant format: You gather a bunch of people with no prior knowledge on coding, make them copy-paste some selenium commands in your language of choice and voilà! Automation! There are a million things wrong with this, but that's not what we're here for, since this time I changed my normal habit and asked the organiser to join. After all, what are a few hours of my time for the possibility to smear people on a founded basis?

However, as I was investing some time in it I decided I'll try to be fair and set some criteria according to which I'll pass my judgement. They are (in no particular order):

1. Fair presentation of the workshop. One can only achieve so much in a two hours session, especially when assuming no prior knowledge. Making sure to explicitly say that and let people set realistic expectations is important.
2. Is there a real advantage to attending the workshop over just going through some online tutorials?
3. Respect to the profession (in this case - automation) - A sales pitch that conveys the message of "Automation is not that difficult, everyone can do it" will gain my contempt faster than one that will say "Automation is a complex task, let me help you do the first steps". 
4. How much is the workshop geared towards sales? It is one thing to attend such an event when it is clear that it is only a taste of a bigger course, it is another to have the speaker mention it every other sentence and pushing it down the audience's throat. 

To start with the conclusion: I expected worse, so one might even say I was positively surprised. The workshop got full points for criteria 1 and 4, sort of passed the 2nd and failed only in the 3rd criterion, and even that was less severe than I expected it would be.  

The workshop was presented in a fair way - the speaker mentioned that no one will leave this room an expert, and threw some terms around to show that there is more to learn. This is also where I decided that the level of sales promotion was decent - the fact that most of the mentioned "stuff we won't learn today" is taught at the courses was almost unmentioned - Naturally, it was there in the background, but  I appreciated that it was not mentioned bluntly. The only discomfort I felt here was that the speaker did spend some time to convince the audience that it is becoming more and more difficult to find work without "automation skills", and while the market is probably going in that direction, I think there was some cherry picking in the job-ads presented as "evidence" to make it look more significant than it actually is. Still - it felt well within the boundaries  of the game. 

An advantage over the internet was a bit tricky to determine. On one hand, there's someone who knows his way around that can answer questions, explain what is needed and point the way forward. On the other - when one studies alone there isn't this pesky time limitation that forces the approach of "just copy paste this, we don't have time to explain this in detail", and being forced to deal with some technical difficulties usually mean better understanding. It is quite clear to me that in comparison to a good internet tutorial (such as the free parts of Alan Richardson's course), this workshop falls very short: The explanations in the video series are far better than what one could have got in the workshop, and the content is far superior in that that by the end of the workshop the participants had a "main" function that couldn't be used or extended in any way, while following the video tutorial would have left one with a fully functional, albeit very basic, testing project (maven+Junit). However - I knew what to look for. I was familiar enough with Richardson work to suspect he would have a very good tutorial, and I had the knowledge to evaluate the content one I saw it. Simply googling for "selenium for beginners" gave a lot of results that would put the workshop contents in a very good place. So, taking that into consideration, I think there is a small benefit to attending this workshop over trying to learn alone (unless you are reading this post, in which case, you know where to find better content).

Finally, the main pain point is in what I labeled as "respect for the profession". This is the main reason I felt the need to actually attend the workshop: The content of such workshops is pretty much well defined by the genre and will differ only in a few small nuances, but the real difference in in the subtext - in the way things are presented and the subtext of the whole activity. It is important to say that in my eyes every short workshop with the goal of teaching non-programmers to use selenium starts this evaluation with a failing score. A good workshop might flip my impression by focusing on the correct messages, but it isn't trivial to do so.
Here, it actually started with a small bright spot, when the speaker mentioned that in order to learn automation one needs to learn coding, which is an important message to hear when the market is so full with solutions selling "codeless automation". I was also happy to hear that this speaker did not equate automation with selenium (and has provided some reasons for focusing on it first) and that people wanting to know how to automate will have to work hard at it.
However, this wasn't enough. Primarily because actions are stronger than words, and they were sending the opposite message. Automation is not only selenium? then how come that the workshop (and, as far as I understood, the "basic" course as well) is only about selenium? I would have been satisfied with even a single, simple assertion.
Hard work is required to be able to learn automation? How does this align with statements such as "When automating we are not writing 'developers code' " or "A programmer that decides to write automation is probably lacking the skills to write production code"? And how does it align with the whole goal of teaching non-coders to write automation in less than 15 lessons? If I'm generous, that's the amount of time invested in CS101, and no one would dream consider CS101 graduates as decent programmers. In addition, even in a 2 hours workshop, if good coding was something the course provider believes in, I would expect to see some minor tips about naming variables, or extracting logic to function, even if it was only to say "normally I would do this, but here we don't have the time".
If this is the approach taken by course providers, it is no surprise that a candidate thought it is legitimate to claim that they were "an automation engineer, not a programmer".

In conclusion, the situation isn't good.
The speaker is answering a market need - I believe his claims that his students are able to find work in automation. In that he is providing his clients a valuable service. But, I think that this course (and its similar competition) is doing a disservice to both their students and to the profession. The students are getting to the market with a lacking skillset and a skewed perspective about how good automation should look like. Therefore, they are not doing as good a job as they should have been doing. In fact, I would wager that any automation project based on the principles demonstrated in the workshop will fail within three years.
Meanwhile, the market is flooded with low skilled "automators"and the many places that are now venturing into the automation space are finding a lot of bad candidates around - some of them will get hired since the hiring company doesn't know better. In fact, that market learns that "Bad programmers are good enough for automation" and this has an impact in three ways: Good programmers are considering automation to be beneath them, companies paying less those that have automation skills (compare to "real" programmers), and the expectation from an automation project is lowered - making it a self fulfilling prophecy.
In my opinion (which I kept pretty much to myself, as my goal was not to ruin the sales event) any person wanting to learn automation would do well to avoid such courses and focus on learning to code well. If, after doing so, automation will still be a challenge, just take a two hours course on some of the specific tools used in testing. 

אולי אחר כך Myabe later

תזמון זה הכל בחיים. או ככה לפחות אומרים כולם. 

בדרך כלל כשמדברים על תזמון בהקשר של בדיקות תוכנה יש לזה כיוון אחד - איך אפשר להיות מעורבים מוקדם יותר?

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

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

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

---

Timing is everything. Or at least that what's everyone says.
Usually, when said in the context of testing, it has one meaning - getting involved earlier.
Naturally, it is not everything. It is just as important to know when to when not to speak, and even when the opportunity to speak is gone.
A couple of months ago, I was abroad participating in CAST (Was great, thanks for asking). Just before I flew over we finished designing a complicated piece of code in a way that I was quite happy with. Two weeks later when I returned I found out that there were some discussions and the design was changed. I didn't really understand or agree with all of the decisions made, but that's fine - I wasn't there when the discussion was taking place and it's unreasonable to expect them to wait for me just because I took a vacation. As I was catching up, I came across another feature where I had some comments. As I spoke with the team member who was working on this I got a response that went along the lines of "there were countless discussions about it, I'm sick and tired of all this so I just do what I'm told". This raised two alarms in my head: First, we have someone who's writing code they don't agree with its design, which is a source of potential mistakes as writing code is much about having a feel of what part fits where and when you write something you disagree with you don't always have that intuitive understanding. The second, more serious alert was that there were some discussions that went wrong, and we were in the domain of proof by exhaustion, and I don't mean the proper mathematical type of exhaustion. In short, now might not be the best time to ask for a major change I thought was required. Instead, I asked for the urgent changes only (you don't want to go and change database tables once in production, it makes it way more difficult in terms of backwards compatibility) and offered to do the work myself - I went to get agreement from the other people, and changed the code. I also left the important but not urgent discussions for later.
My reasoning for not pressing on this argument was simple: Fixing code is easier than fixing people, and it is much easier to deal with a not so perfect piece of code than to deal with a communication problem in the team.
What I didn't take into consideration was, of course, the human nature: After a while, ideas take root in people's mind and they get used to it, so changing their mind now is more difficult. In addition, changing something in retrospect usually takes more effort than changing it while it is being created, so the price of action is higher. 
At the end, we did have another discussion about the design - I can't say I'm super excited with the result (or rather, with the current result, as the solution is inching its way towards the original design that I liked, only with different terminology), but during the years I've learned one thing - While it's easy to think I'm always right (I am, but this is besides the point) The people I work with know software at least as good as I know it. If someone else prefers a solution I don't like it's usually not because they are wrong, but because each of us gives different weights to the various properties of each solution. What was really important was that we discussed our differences and got to an agreement about how we want to push forward. We also added a task to create a diagram of what we've decided to make sure everyone is aligned - which helped us avoid some mistakes in the future since we found some obstacles earlier.

So, to sum things up - Speaking up is not always the right thing to do - as long as you are having those discussions later.