Continuous Knowledge Delivery

לכולנו כבר ברור לגמרי מדוע אנחנו רוצים למזג קוד כל הזמן (Continuous Integration), מדוע אנחנו רוצים לבדוק ולהכין קוד כל הזמן, (Continuous Delivery) או מדוע אנחנו רוצים לשחרר קוד כל הזמן (Continuous Deployment).

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

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

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

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

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

פעם עבדתי בארגון בו התלוצצנו שמי שמתקבל לעבוד בארגון, לא יוכל אחרי שנתיים או שלוש להתקבל לארגון מחדש: ראיונות העבודה הטכניים היו בהחלט קשים, אבל פילוסופיית העבודה לא "נשענה" על ידע עמוק של העובדים: נבנו תשתיות פנימיות שמגבילות מאוד את צורת העבודה: למשל תשתיות לעבודה מול בסיס הנתונים – סט abstractions מעל hibernate שלא היה ניתן לראות SQL והיה לאנשים רק דימיון (שגוי לרוב) מה באמת קורה מאחורי הקלעים, או מן שפת XML שתורגמה ל HTML+CSS, שהגבילה את יכולת העבודה ו"חסכה" מהאנשים חשיבה והבנה מה באמת מתרחש בדפדפן.

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

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

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

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

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

מה אפשר לעשות?

אני מגשש בנושא הגדול, המורכב והחשוב הזה, ולכן התחלתי בהשוואה זריזה בין גישות למידה שונות. נתחיל בנושא הקל יותר (נראה לי) – למידה של טכנולוגיות כלליות:

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

  • כנסים הם חוויה, אבל לא מקור למידה משמעותי בעיני. מאוד נהניתי מכמה כנסים – וכמה מהם היו פותחי-עיניים עבורי, אבל את הלמידה עצמה, עשיתי מאוחר יותר, מתוך ספרים ומאמרים. אם לא הייתי מוסיף את הלמידה העצמית, הייתי יודע לדקלם כמה ססמאות נוספות, עם מעט מאוד הבנה במה באמת מדובר.
  • יש משהו מאוד מלמד לתת לאנשים בתוך הארגון להרצות, הם בוודאי מתפתחים באופן אישי ממתן הרצאה – אבל בשלבי ההתפתחות הראשונים הם עלולים לספק סשנים ברמה לא מספיק טובה. אולי כדאי להתחיל מפורום של צוות/קבוצה, ורק בעקבות הצלחות שם – לזמן לאנשים לבמה רחבה? (נניח: 100 איש). כל סשן בינוני ומטה שמועבר ל 100 איש – הוא פספוס לדעתי, שעלול להפוך לנזק מצטבר (איבוד אמון בפורום, הורדת הסטנדרטים).
  • ספרים עדיין "עובדים", אבל לפלח הולך ופוחת של האוכלוסייה. אני מאמין ש Video Tutorials הם המדיה העדיפה כיום. כמובן שלאנשים שונים, מתאימים דברים שונים – אבל אם לא נתתם למדיה הזו סיכוי מספיק – אני ממליץ (בתור אחד שקרא עשרות רבות של ספרים, אבל גם ראה עשרות רבות של Video Tutorials).
    • למרות מוטיבציה גבוהה של אנשים להיות עם ידע, הלמידה עצמה אינה קלה, ולעתים קרובות לא מתממשת (כמו שכולם רוצים להיות בכושר, אבל קשה ליישם. מסגרת יכולה מאוד לעזור). השלב הקשה ביותר הוא כנראה הקצאת זמן – וארגון שרוצה להצליח כנראה צריך לעזור לעובדים לפנות זמן משמעותי, ולהתחייב ללמידה. למשל: לקבוע ברבעון כמה ימים קבועים מראש (ולא ניתנים להזזה) לצורך הלמידה + לבקש לסכם ולהציג את סיכום הדברים מול הצוות.
  • חונך אישי הוא דיי ברירת מחדל, במיוחד כאשר מגיעים Juniors לארגון – אבל הם יקרים מכפי שנדמה: גם בכמות ההשקעה בפועל, וגם מכך שלא תמיד החונך ידע לחנוך בצורה טובה, או אפילו לספק תשובות מספיק טובות למגוון שאלות שיעלו. החניך לרוב לא יוכל לתת אינדקציה לאיכות החניכה, עד שלא צבר כמה שנים טובות בתעשייה – והפידבק יהיה בעיקר סביב זמינות ונחמדות.

בואו ננסה לעשות תרגיל דומה, על ידע פנימי / ספציפי לארגון:

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

  • תיעוד טוב יכול להיות מאוד יעיל (כנראה, למשל תיעוד של ספריות OSS) – אך מעולם לא עבדתי בארגון שהצליח לייצר תיעוד בעקביות: בכמות ובאיכות.
  • אני מאמין שתיעוד בקוד הוא מאוד שימושי, כפי שכתבתי באריכות בפוסט קוד ספרותי = סופן של ההערות בקוד. הפוסט מתאר אלו הערות בקוד הן מיותרות, ועדיף שייכחדו, ואלו הן שימושיות (בגדול: דברים שאפשר לפספס מקריאת הקוד, תמונה גדולה, עקרונות, עבר וכוונות עתיד). יותר קל ליצור תרבות של תיעוד בקוד – כי קל יותר לכתוב אותו ולהסביר את הערך שבו.
  • כשהארגון גדל מצטבר בו ידע וכללים, כגון Coding Conventions ו Best Practices. יש כאלו שמתנגדים לכל סוג של סדר / חוקים ורוצים להיות "Rock Stars" – ראיתי שוב ושוב את הנזקים המצטברים של הגישה הזו. לא צריך להגזים, וחשוב להשאיר חופש לסגנון אישי – אבל סדר ואחידות בדברים הבסיסיים (לחווייתי ארוכת השנים) יוצרים הרבה יותר תועלת מנזק. בלי תיעוד של הכללים האלו – קשה להפיץ ותחזק אותם. גדילה מסיבית של הארגון יכולה בקלות לגרום לאיבוד של לקחי-העבר, וגם הטובים שבהם. לקחים צריך לתחזק, לחדש, ולהתאים.
  • כלי שנראה מאוד שימושי ויעיל להפצה ואכיפה של קונבנציות של Coding Convention ו Best Practices פנימיים לארגון הוא כלי Static Analysis שניתן להרחיב ולקסטם לחוקים הספציפיים של הארגון. מאסתי מזמן מכלים שאוסרים על שורה להיות מערבר לאורך מסוים או מחייבים אותי להוציא constant מכל מספר שמופיע בקוד – אני מוקיע את הכללים האלו, וממליץ לבטל אותם! מצד שני, הצגתי אולי עשרים פעמים בארגון את כללי הבסיס של מבנה טבלאות שהוחלט עליון (חייב להיות primary key שהוא GUID או Autoinc, להוסיף 2 עמודות לזמני יצירה + triggers שימלאו אותם, שימוש ב UTF8 – לא משהו חריג), ושוב ושוב היו פספוסים ואנשים שלא שמעו מעולם על הכללים (שגם מתועדים היטב). פעם אחת יצרנו חוק של Static Analysis שלא מאפשר לעשות ל commit אם יש חריגות – ונראה שהידע החל לעבור, ובלי כמעט השקעה נוספת. כל כלל הוא הזדמנות ללמד, ולכן חשוב מאוד לא רק להציב את החוק אלא להסביר אותו, ולהפנות למקורות. למשל: מדוע למשל חשוב ב MySQL שיהיה Primary Key ומה העלות של Primary Key גדול (בבתים). בנקסט אנחנו משתמשים ב Detekt (לשפת קוטלין) ו Danger (לשפת TypeScript) לכתיבה של Custom Static Analysis rules.
    • התאוריה המקובלת היא ש 70% מהלמידה בפועל מתבצעת מתוך או תוך-כדי עשייה בפועל, וזה הרגע המתאים ביותר ללמוד בו – כאשר הנושא 100% רלוונטי אלי, ואני זקוק לידע בו. Code Analysis tools (עם הסברים מפורטים בצד) – מצטיינים בקליעה לרגעים החשובים הללו.
    • בלי קשר, כל סוג של למידה כדאי לקשור לצורך נוכחי, למשל: קורס SQL לקחת בעת עבודה על פיצ'ר מורכב בבסיס הנתונים, ולהתמקד בצרכים הספציפיים – ולא בעת ההצטרפות לחברה, שאולי שנתיים רצופות לאחר-מכן לא יעשה בידע שימוש משמעותי.

אחרית -דבר / סיכום

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

הרמה האסטרטגית בהפיכת ארגון לארגון שבו "זורם ידע, באופן מתמשך" – דורשת עבודה… אסטרטגית. למשל: קביעת יעדים משמעותיים ואי התפשרות עליהם. למידה היא השקעה שפירותיה ניתנים רק לאחר זמן, ויש המון פיתויים לדחות אותה. כיצד הופכים למידה משמעותית ותמידית לערך בארגון שנלחמים עליו, ממש כמו Continous Delivery? הרבה ארגונים מוכנים להקריב הרבה בכדי להגיע ל Continuous Delivery הנכסף, אך האם לכל הארגונים הוא ייתן תרומה זהה או גבוהה יותר מ Continuous Knowledge Delivery?!

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

הגדרת מומחיויות: איש QA, איש אוטומציה, Release Manager, איש Operations (בטעות נקרא: DevOps), DBA ועוד – עוזרות לפשט את הניהול בטווח הקצר, אבל יוצרות Silos של ידע (ואי-זרימת ידע) שיקשו עלינו בעתיד.

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

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

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

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

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

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

בקיצור: הרבה שאלות, קצת פחות תשובות.

אתם יותר ממוזמנים להוסיף את התובנות שלכם בנושא.

שיהיה בהצלחה!

תואר החלומות ב"הנדסת תוכנה"

היי,

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

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

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

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

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

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

נושאים

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

לפני שאתם \"קופצים\" על מה שנאמר על קורס האלגוריתמים (נושא טעון), עברו על השקף הבא:

אנו רואים שינויים משמעותיים בעולם הידע המקצועי: שינוי שאם האוניברסיטאות / מכללות לא יפנימו, הן עלולות למצוא את עצמן הופכות מ\"מיינסטרים\" ל\"נישה\". אם פעם הדרך היחידה כמעט לרכוש ידע יסודי על רשתות תקשורת היה לעשות קורס במדעי המחשב – היום יש ספרות מקצועית רבה ואיכותית וזמינה (תוך דקה אצלי על ה iPad), קורסים מעולים בוידאו, בתשלום או ברשת בחינם, או סתם גיגול ל StackOverflow שיפתור לי את הבעיה באופן רגעי ואלמד משם טיפה אחר טיפה.
לגבי האלגוריתמים והמתמטיקה: אנו מאמינים שזהו נושא חשוב לאלגוריתמאים / חוקרים, שמהווים לא יותר מ5% מסך אנשי התוכנה. לשאר אנשי התוכנה – אין שימוש ממשי בידע זה. גם ידע מתמטי עמוק, כדרך אגב, ניתן כיום להשלים מהבית בעזרת Coursera / iTunesU ואחרים.

התוכנית

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

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

התמונה הגדולה של התוכנית

הנה כמה רעיונות שרציתי להעביר:

איפה שנה ג\'? אנו מאמינים שלמידה היום יכולה להיות קצרה יותר. עדיף ללמוד מעט – ואז להתחיל לעבוד, מאשר לשבת שלוש-ארבע שנים ורק ללמוד. יותר Agile ופחות Waterfall. השלמות ותוספות יתרחשו מעצמן תוך כדי העבודה ואם ממש רוצים – אולי כתואר שני (של שנה?). חשוב שהבוגר יקבל בסיס ומיומנויות למידה, אבל זה יהיה בזבוז (waste) להמשיך ולתת לו עוד ידע, בלי שברור שהוא זקוק לו.
ידע \"אנושי וארגוני\" הוא לא פחות חשוב מידע טכנולוגי – ואפשר ללמוד אותו. למה אוניברסיטאות נותנות משקל כ\"כ קטן (אם בכלל קיים) לצד זה של ההשכלה? האם \"מדעני מחשב\" באמת לא זקוקים לידע בין-אישי? האם באקדמיה עובדים לבד ולא בקבוצות / שיתופי פעולה? 
Domain Knowledge הוא ידע יקר ערך שאוניברסיטה לא תוכל לספק, אבל היא כנראה יכולה לתת הצצה אליו – ולפתוח צוהר לסטודנטים ללמוד אותו. ב Domain Knowledge אני מדבר על ההיבטים שתוכנה לגופי IT שונה מתוכנה לחברות של תשתיות או רפואה, ביטוח או פיננסים. זה להבין בגדול כיצד ה\"ביזנס\" שעבורו אנו כותבים מערכות עובד, אלו צרכים מיוחדים יש לו (לפעמים בעקבות רגולציה) וכיצד מתנהלים ארגונים שעוסקים בתחומים אלו? מה מטריד ומעסיק אותן? אלו Patterns של תוכנה מקובלים להתמודד עם הבעיות הללו?
לדוגמה:
  • בשוק החשבונאי חשוב דיוק מלא בכל הנוגע לכסף. אסור לחלק מיליון דולר ל 7 חלקים – ולאבד סנט אחד, בגלל עיגולים שעשה המחשב.
  • בשוק הביטוח כדאי להבין את כל ההסכמים של ביטוח ההדדי בין חברות – וכיצד עסקי הביטוח עובדים.
  • בשוק הרפואי יש רגולציות רבות יש אבטחת מידע רפואי פרטי. יש הרים של מידע ומינוחים שונים רבים לאותו הדבר – שיש להתמודדד איתם וכו\'….
אם יש ידע שעדיין לא ניתן לקנות ספר טוב ללמוד אותו ממנו, או שאין קורסים באינטרנט ותשובות ב StackOverflow לגביו –  זהו כנראה ה Domain Knowledge – ומשתלם מאוד ללמוד אותו, בתחום בו אתם עוסקים.
שבירת הסדר בין \"יסודות\" ל \"ידע מעשי\" – באוניברסיטה מקפידים על סדר של bottom up, מלמדים שכבה אחר שכבה. למשל: לומדים את מבנה המחשב, לפני שלומדים מערכות הפעלה. לומדים ממשק משתמש (UX) רק אחרי שלומדים לפתח UI – וכו\'.
הבעיה היא ש:
  1. התוכנית מתארכת – ולא מגיעים כמעט ל\"תוכן משמעותי\" לפני שנה שנייה.
  2. מנסיוני האישי – לעתים יותר קל להתחיל בכתיבת תוכנה, ורק מאוחר יותר להעמיק ב\"יסודות\" כיצד דברים עובדים.
נקודה זו היא פחות חד-משמעית, אך עדיין נראה שש כאן עקרון שכדאי לשקול מחדש.

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

סיכום

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