איך להתקדם להיות סיניור

איך להתקדם להיות סיניור

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

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

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

קוד טוב הוא רק חצי מהעבודה

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

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

ביקורת שלילית היא מידע, לא כתב אישום

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

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

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

אל תממשו דרישה לפני ששאלתם למה

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

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

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

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

לא לדעת הוא לא כשל מקצועי

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

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

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

טעות טובה היא נכס רק אם לומדים ממנה

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

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

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

השורה התחתונה

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

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

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