החודש הראשון שלך בסטארט-אפ מותיר חותם. אין תקופת הסתגלות איטית, אין שבוע של צפייה בסרטוני אוריינטציה בזמן שמחכים שצוות ה-IT יכין לך מחשב נייד. ביום הראשון, מצפים ממך לבנות, לשבור ולתקן דברים שאנשים אמיתיים באמת ישתמשו בהם. למדתי זאת מהר מאוד לאחר שהצטרפתי ל-Treevah, חברה שבנתה כלים כדי לעזור למחפשי עבודה לארגן את הגשת המועמדות שלהם. שלושים ימים בסביבה בשלבים מוקדמים לימדו אותי על פיתוח תוכנה יותר מכל כיתה או תחרות שאי פעם יכלו.
הקצב הוא בלתי פוסק
ב-Treevah, העבודה לא מחכה שתתאקלמו. הצוות דוחף להעביר את המוצר משלב אלפא לביתא ובסופו של דבר לסביבת production, מה שאומר שכל משימה היא בעלת משקל. אין מקום לעבודה זמנית או למשימות שנשמרות בתיבת הדואר הנכנס של פרופסור. כשאתה משחרר (ship) פיצ'ר, הוא הולך ישירות למשתמשים שמנסים לעקוב אחר דדליינים, ראיונות ומעקב (follow-ups) בזמן שהם מחפשים את התפקיד הבא שלהם.
הקצב מתיש. אתה נע במהירות בכל יום, ועומס העבודה נערם מהר יותר ממה שציפית. דדליינים הם לא מופשטים; הם קשורים לאבני דרך שקובעות האם החברה תוכל לשרת יותר מחפשי עבודה או לתקן פערים בחוויה הנוכחית. הכבדות הזו שוחקת אותך. אבל היא גם יוצרת בהירות שקשה למצוא בארגונים גדולים יותר. כשאני מסיים משימה, אני יכול לשרטט קו ישר בין מה שבניתי לבין אדם שכעת יש לו קל יותר לנהל את חיפוש העבודה שלו. תחושת בעלות כזו היא נדירה, והיא גורמת לעייפות להרגיש שווה את המאמץ.
מיומנויות נבנות מהר יותר ב-Production
לפני הקיץ הזה, חלק גדול מהאנרגיה שלי הושקעה בדיבור מול קהל ובהאקתונים. שניהם לימדו אותי איך לחשוב מהר ולהציג רעיונות תחת לחץ. האקתונים במיוחד מאמנים אותך להרכיב דמואים עובדים תוך שעות. אבל יש הבדל בין פרויקט של סוף שבוע שמרשים שופטים לבין קוד production שצריך לשרוד מגע עם מאות משתמשים אמיתיים.
בילוי חודש מרוכז בפיתוח ווב (web development) ב-Treevah סגר את הפער הזה. בבית הספר, פרויקטים מגיעים עם מגבלות (guardrails). ההיקף קבוע, הדרישות מוגשות בקלות, ואם סכימת מסד הנתונים שלך קורסת, אתה יכול להסביר זאת במצגת. בתוך סטארט-אפ, הסכימה שלך חייבת להחזיק מעמד כי מחפשי עבודה אמיתיים מאחסנים בה נתונים אמיתיים של מועמדות. לולאת המשוב היא מיידית וחסרת רחמים. כשדף נטען לאט או שטופס נכשל בשמירה, לאף אחד לא אכפת מה הציון שלך; אכפת להם אם הם בדיוק איבדו מעקב אחר הזדמנות.
הלחץ הזה מחייב צמיחה. אתה לומד לכתוב קוד נקי יותר לא בגלל שקריטריון מסוים דורש זאת, אלא בגלל שאתה תהיה זה שיבצע לו debugging בחצות. אתה לומד לשאול שאלות חדות יותר במהלך code review כי פריסה של build שבור משמעותה שמשתמשים אמיתיים נתקלים בקיר. ההזדמנויות כאן פשוט חזקות יותר מפרויקטים בבית הספר. הטעויות עולות יותר, ולכן השיעורים נחקקים.
המציאות המלמדת של באגים
אם יש מיתוס אחד שהייתי רוצה להפריך, זה הרעיון שכל באג בתוכנה הוא כשל לוגי דרמטי. חלקם הם, כמובן. אבל רבים מהבאגים שנתקלתי בהם ב-Treevah היו קטנים ומעצבנים באופן בלתי נסבל. הם הסתתרו ממש מול העיניים ובזבזו שעות מחיי.
שני דפוסים המשיכו להופיע. הראשון היה כללי CSS כפולים. כשמפתחים מרובים נוגעים באותו רכיב לאורך מספר ספרינטים, גיליונות העיצוב מתנפחים. אדם אחד מוסיף מחלקת עזר (utility class) של margin בעוד שאחר מקודד ערך באופן קשיח (hardcodes) בקובץ הרכיב. אף אחד מהם לא טועה בנפרד. אך יחד הם יוצרים תזוזות פריסה (layout shifts) או "מלחמות ספציפיות" (specificity wars) שגורמות לכפתור להיראות בסדר ב-Chrome אך שבור ב-Safari. איתור שלהם אומר לפתוח את כלי המפתחים של הדפדפן ולעבור על computed styles שורה אחר שורה במקום לקרוא לוגיקה אלגוריתמית אלגנטית.
השני היה הגדרת אלמנטים מחוץ ל-divs ההורים שלהם. טריגר של מודאל או תפריט נפתח (dropdown) עלולים להתווסף לצומת (node) הלא נכון ב-DOM. המסך נראה כמעט תקין, אז אתה מניח שהמבנה תקין. ואז מופיע קונפליקט z-index, או שאירוע לחיצה (click event) "בועות" (bubbles) למטפל (handler) הלא נכון, ופתאום משתמש לא יכול לסגור פופ-אפ שמכסה את טופס המועמדות שלו. אלו אינם חידות מדעי המחשב. אלו טעויות מרחביות ומבניות שמצטברות כשאתה נע במהירות.
חלק מהבאגים האלה לקחו שבועות למצוא. הייתי בוהה בקוד, משכנע את עצמי שהלוגיקה תקינה, ומתעכב במבויים סתומים שלא הובילו לשום מקום. התסכול הוא אמיתי. מרגישים כאילו משהו ברור נעלם מכם, ואכן כך. אבל הסיפוק שבסוף לזהות כלל כפול או תג סגירה במקום הלא נכון הוא באופן מפתיע