קטגוריה: עבודה

מבחן שגוי

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

נניח ואתם מגיעים לראיון עבור משרה עבור לימוד מכונה בניתוח תמונה, ואתם מתחילים לקבל מבחנים, הייתם מצפים למבחנים בנושא אלגוריתמיקה, ניתוח מידע, אולי אפילו שימוש בOpenCV, נכון?

אבל במקום, מקבלים שאלות בנושא של TCP/IP, כיצד מסד נתונים עובדים, איך יוצרים מודולים לקרנל וכיוב'.
מה עכשיו? האם אתם מתאימים לתפקיד?

אז הגזמתי קצת, נכון? ובכן לא.

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

שאלות בנושא התפקיד להראות יכולת והבנה חשובים הרבה יותר מאשר היכולת אז אני מדבר על full stack עבור פיתוח web, הנה מבחנים טובים יותר מאשר שאלות מדמ"ח:

  1. יש לי צורך לאסוף את הנתונים הבאים – מה הסכמה למסד הנתונים שתתכנן ולמה?
  2. האם מסד נתונים מבוסס סכמה באמת מתאים לזה, או אולי מסד נתונים מסוג אחר?
  3. תן לי הדגמה מתי תבחר בdjango/rails ומתי ב sinatra/flask?
  4. מתי Go עדיפה על פיתון/רובי?
  5. מה ההבדלים בין Vue/React לבין Angular?

אלו לא רק שאלות, אלא ניתן לפתח אותם כמבחנים ממש, והם ממוקדים מאוד אודות התפקיד, כי הם נדרשים לתפקיד עצמו.

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

למה הן לא רלוונטיות?
נגיד ואני יודע לשלוף את האלגוריתם הכי יעיל, להגיד לכם מה ה O(n) שלהם, וכמה סייקלים של cpu יקח לסרוק את המטריצה, האם אני יודע לענות על חמשת השאלות שהעלתי למעלה? לא בהכרח, אבל הן חשובות לתפקיד.

במידה ולא אצליח לענות על השאלה עם המטריצה ואצליח לענות על השאלות עבור תפקיד ה full stack האם אינני מתאים לעבודה שכזו? הרי כיום אלא אם התפקיד דורש ממני יכולת לענות על הנושא, יש לי המון כלים להתמודד עם הנושא. כמובן שעדיף שאדע, אבל המבחן אינו מתאים לתפקיד.

זו כמובן דעתי, בלבד, בהצלחה 🙂

כניסה לפרויקט קיים

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

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

התחלה

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

טעויות בכניסה לקוד/פרויקט קיים

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

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

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

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

ושוב פעם אתם נכנסים ללימוד מ-אפס של החללית והמנגנונים שקשורים רק בזה.

הדרך שלי ללמוד

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

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

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

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

רכיבים קטנים

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

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

לאחר שיש לי הבנה ותובנה כיצד הבסיס עובד, קל מאוד להתחיל לעלות למעלה ולהבין דברים גדולים ומסובכים יותר כי יש בסיס להתמקד עליו.

אך בהעדר בסיס שכזה, לא ניתן באמת לדעת כיצד להתמודד עם דברים שונים.

עבור מה השיטה לא מתאימה?

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

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

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

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

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

סליחה, יש לכם אולי זמן ללמוד טכנולוגיה חדשה ?

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

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

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

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

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

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

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

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

אם מסתכלים על הקפיצה הגדולה בין 1.8.6 ל2.1.2 אפשר לחשוב כאילו לא היה מספיק זמן להמיר דברים, אך למעשה המעבר לרובי 2.0.0 היה מאוד ארוך, ובאמצע כלל גרסאות כמו 1.8.7 שהיו הרבה שנים בתמיכה, וגם 1.9 על סדרותיו, שנתנו את האפשרות להתאים את הקוד למעבר של גרסה 2.0.0. כלומר אותו ארגון נתקע מאחור, ועכשיו הקפיצה שלו יקרה מאוד עם המון בעיות, בעוד שאם היה "זורם", העלות הכוללת היתה נמוכה בהרבה, ושורת  הרווח שלו גבוהה יותר.

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

תכנון מודלארי של מערכת

"If I had eight hours to chop down a tree, I'd spend six sharpening my ax." — Abragam Lincoln

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

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

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

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

הדבר השני הוא לדעת לקרוא נכון לכל מתודה בזמן המתאים, ככול שיש יותר מתודות, ככה יש סוג מסויים של בלאגן.

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

בגישה המונוליטית יותר, היה קשה יותר להתאים את עצמי לשינוי של flow מסויים של המערכת, ולהוסיף במקומות מסויימים משהו נוסף, ובמקומות אחרים להסיר משהו אחר.

למשל אפילו הגדרה של "עד שלא מאשרים משהו, אתה משמיע אפשרויות" לקח לי חצי דקה להוסיף למערכת.

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

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

אנטגוניזם מקצועי

יוצא לי המון פעמים לשמוע תלונות של מפתחי ווב, כמה המקצוע שלהם קשה ומסובך, כי הם צריכים לדעת Javascript, CSS, HTML, DOM, XML ובנוסף יש גם את צד השרת עם שלל הדברים שלו (וזו רק רשימה חלקית ולא מכסה את העולם).

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

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

המטרה שלי בפוסט זה היא להסביר כי מה שנראה כמשהו נורא בצד אחד, יכול לצד אחר להראות כמשהו לגמרי שולי ופעוט לצד אחר לגמרי.

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

אני מוצא כי ככול שאני לומד יותר עולמות, גם שלא קשורים ישירות לשלי, אני מצליח להפיק יותר גם במקצוע שלי.

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

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

האם מיקרוסופט נעלמת מהעולם העסקי ?

לאחרונה לקוח נפל בכך שהזמין מערכת ממישהו שהקים חברה על איזה קורס וחצי של פיתוח בטכנולוגיות מיקרוסופט שלקח, ואותו אדם לא הצליח לספק לו את מבוקשו.
כאשר הלקוח עוד חשב כי יקבל, ביקש ממני סיוע למצוא שרת אירוח מבוסס Windows, היות והוא היה זקוק להתקין את המערכת שאותה חברה בנתה עבורו.
אז שנינו חיפשנו משהו בסדר גודל מסויים, והמחירים שמצאנו במקרה הטוב התחילו ב50 יורו.
מיקרוסופט Azure עצמה כל כך יקרה ולא ריאלית לעסק קטן, אשר זה נפסל עוד ללא מאמץ.
אז הלקוח הזמין Windows Server 2012. וגילינו כי זה, מגיע עם ממשק של Windows 8 משום מה.
והשאלה הראשונה ששאלתי היא: למה ?

מי ירצה להריץ שרת שעובד קשה על מערכת טאבלט ? מדוע הממשק צריך להיות זהה גם כאשר מדובר בשרת ?

אבל זה לא הכל, עצם החיפוש עבור חברות המספקות מערכת ווינדוז, היה יחסית קשה למצוא, בעוד שמאוד קל, פשוט וכיום כבר זול להזמין. למשל אני עובד עם Digital Ocean (לחיצה על הקישור והזמנה דרכו יזכו אותי בכסף – אומר זאת בצורה גלויה), שרת במחיר של 10 דולר לחודש (120 דולר לשנה) והכל עובד, קל, אין בעיות, יש לי סנאפשוטים של מצבים שונים כאשר אני עושה ניסויים על המערכת, ונהנה מזה שאין לי כאבי ראש מיותרים.
הכל היה קל ופשוט מידי, בייחוד כאשר משווים זאת לאמזון, אשר הם לא ברורים במחירים שלהם, והממשק שלהם זוועתי, וכבר סיפרתי מה הם עשו לי.

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

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

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

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

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

מחדשנות לשמרנות

אחד מהדברים שמאוד מסקרנים אותי, הוא שיש חברות אשר היו פעם מאוד חדשניות, ופתאום עברו להיות מאוד שמרניות.

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

דן אריאלי ענה על שאלה בנושא, מה שהצית מחדש את ההתעניינות שלי בנושא. אריאלי מדבר על כך שבעיות כאלו כנראה נוצרות בעקבות אפקט הבעלות.

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

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

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

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

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

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

לימוד שפת רובי

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

כבר שמעתי משפטים כמו "עד כמה שהבנתי ברובי אין משתנים, אלא הכל זה מערכים", מאדם אשר עבר קורס בRails.

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

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

העניין הוא ששוכחים כי רובי היא לא רק Rails. יש כלים מאוד נפוצים כמו שף ו Puppet, ועוד מספר טכנולוגיות שונות שיש בהם שימוש מעבר לשפה עצמה, אבל משום מה, כולם עשו חיבור כי Ruby = Rails,

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

האם יש צורך בQA ?

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

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

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

מי תיקח כמתכנת אצלך ?

במהלך 2012 השתתפתי במספר דיונים ואף יעצתי למספר חברות בדבר עובדים המתאימים לתפקידים כאלו ואחרים בעולם התכנות.

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

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

אז מה כן אני מייעץ ?

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

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

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

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

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

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

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

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