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

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

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

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

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

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

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

למשל לעבוד עם מכונה מאוד חזקה לווירטואליזציה, זה דבר נחמד, אבל האם אולי טכנולוגיה כמו 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 זה נחמד, אבל התפקיד של המתכנת בסופו של דבר הוא לספק לי כלי שיעזור לעסק להכניס כסף. הוא צריך להבין מה הוא עושה, ולא רק לכתוב ללא הכרה. כלומר הוא צריך להיות חלק מהמערכת שהוא כותב.
השפה לא מעניינת, הפלטפורמה לא מעניינת, החשיבה העסקית כן. הוא לא צריך להיות איש עסקים, אבל כן להבין חשיבות עסקיות, ולהתמודד עם דירשות שהן נטו עסקיות, ואינן קשורות בכלל לעולם התוכנה, למעשה לפעמים רק מסרבלות את העולם.

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

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

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

מצגות בעולם הרחב של הרשת

מאז 2007, התחלתי להעביר הרצאות, חלקם ללקוחות בתשלום, ורובם קהילתיים לגמרי.

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

עד היום הייתי במידת הצורך יוצר שקפים באמצעות Impress של Libre/Open Office (בהתאם לקיומם בעולם), וכבר הרבה זמן שאני חושב להתחיל לעשות את זה קצת אחרת.

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

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

אז החלטתי ללכת על משהו בין מה שגוגל מציעים לבין impress.js, ומצאתי את reveal.js.
המערכת מציעה להעביר מצגות, עם תמיכה ב html5, css3 ו javascript. אבל אינה דורשת ממני לתכנת דברים, אלא להתמקד בתוכן, וכיצד אני רוצה שהוא יוצג. למעשה התכנות שלי זה html הכי מינימליסטי בעולם. המפתח שלה אפילו חשב על תמיכה בשפות כמו עברית, ולאפשר לנו להציג הרצאה מימין לשמאל לפי בחירה.

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

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

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

May the source be with you 🙂

שימוש שגוי בזמן המתכנת

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

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

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

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

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

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

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

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

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