שתי משרות מתכנת

02/03/2021

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

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

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

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

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

  3. אפשר לעשות את השינוי מבפנים, אבל זה די קשה - כשמופעל עליכם לחץ לבנות יותר פיצ'רים ממה שבכלל אפשרי להספיק ביום, כשהכלים פועלים נגדכם וכשכל דבר שאתם עושים נמדד, זה די קשה להתחיל להכניס פרקטיקות של בדיקות אוטומטיות, Code Reviews, Pair Programming, הרצאות העשרה, תרבות של Refactoring וכלי ניהול גירסאות טובים יותר. בטווח הרחוק כלים אלה ישפרו את הפרודוקטיביות ויחסכו לכם זמן זה נכון, אבל כרגע יש יותר מדי שריפות מכל הכיוונים.

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

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

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