בודקי תוכנה זה דבר מיותר

 

English

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

1. אין צורך במומחיות. ברוב המקומות בהם הייתי, לפחות 95% מעבודת הבדיקות שנעשתה, וזו שהייתה צריכה להיעשות, הייתה ברמה שבודק תוכנה מתחיל היה יכול לבצע, או ביצע בפועל. המשמעות של זה היא שאנשים בלי הכשרה יכולים לבצע את המשימות האלה בקלות יחסית, או לכל היותר אחרי הדרכה קצרה וקצת תרגול. נכון, ישנם מקרים בהם באמת נדרשת מחשבה מעמיקה או מומחיות - כשצריך להגדיר אסטרטגיה לפרוייקט גדול או מורכב במיוחד, כשצריך להבין איך לבדוק מוצר קשה לבדיקה או פיצ'ר מסובך במיוחד. שם נזדקק לבודק תוכנה מומחה, אבל המקרים האלה נדירים. 
2. הסרת אחריות - כשיש מישהו שתפקידו הוא למצוא את הבעיות, שאר האנשים בסביבה יכולים להרשות לעצמם להיות קצת פחות זהירים, גם כשזה לא קורה באופן מודע. הם מגישים את התוצרים שלהם "לבדיקה", אז לא צריך להיזהר מאוד - מקסימום, יעזרו לי למצוא את הטעויות. 
3. הסחת יעדים -  אם יש אדם אחד שאחראי לכתוב תוכנה ואחר שאחראי לבדוק אותה, כל אחד מהם נמדד על הביצועים שלו בתחום האחריות הספציפי הזה. המטרה המשותפת שלהם - להוציא לשוק את התוכנה הנכונה במהירות האפשרית - לא שייכת לאף אחד. לאחד יש "דאג לספק תוכנה בקצב מהיר, ואילו לאחר יש "ודא שהתוכנה כתובה כיאות", וזה אם יש לנו מזל. במקומות מסויימים, היעד כפי שהוא משודר בפועל הוא "מצא סיבות טובות לעכב את שחרור המוצר". זה יכול להוביל למגוון בעיות התנהגותיות, ולקושי בשיפור כאשר כל צד מנסה לשפר את החלק שלו ולא מסתכל על המערכת בכללותה. אי שם לפני קצת פחות מעשור זכיתי לחוות את השינוי הזה בצוות בו הייתי. את הפיצ'ר אני כבר לא זוכר, אבל אני זוכר שכחלק מתכנון העבודה, ביקשתי לשנות את המימוש כך שחלק מסויים יהיה חשוף החוצה כך שיהיה קל יותר לבדוק חלק משמעותי של הלוגיקה. המתכנת שהיה אחראי על כתיבת החלק הנ"ל, התנגד. קודם כל, הוא כבר התחיל בכיוון מסויים, וזה לא נכון לעוות את התוכנה רק בגלל צורכי בדיקות, ובכלל, הנה כמה סיבות שנשמעות די משכנעות בגללן נכון יותר להישאר עם הבחירות הנוכחיות. אז קצת יותר קשה לבדוק את זה? נו, שוין.  רצה הגורל, ובגלל בעיות עומס, אותו מתכנת קיבל גם את המשימה של לבדוק את הפיצ'ר. גם כי היה עמוס, וגם כי היינו בשלב מתקדם יחסית של מעבר לצוות נטול תפקידים, בו כל חברי הצוות הם "מהנדסי תוכנה" או משהו כזה. כמה ימים אחר כך, במהלך הדיילי, הוא סיפר שהוא הסתבך קצת עם בדיקת הפיצ'ר, ומצא פיתרון יצירתי שהפך את הבעיה לטריוויאלית. בגדול? אותו דבר שביקשתי ממנו קודם. כל הטיעונים הטובים מקודם הפכו פתאום להיות פחות חשובים מאשר לשמור על קוד קל לתחזוקה ולבדיקה. 
4. לולאת משוב ארוכה יותר. לא משנה איך מסובבים את זה, או כמה טוב התיאום בין חברי הצוות, לולאת משוב שכוללת שני אנשים תהיה איטית יותר מכזו שכוללת אדם אחד. כאשר אותו אדם שמבצע עבודה גם בודק את התוצאה, יש לנו סיכוי הרבה יותר טוב לראות התנהגות של "בדוק, תקן, בדוק שוב". גם הפעולה בעקבות המשוב זורמת הרבה יותר - לא צריך לשכנע אף אחד שהבעיה אמיתית, ולא צריך לבזבז זמן על הסברים כמו "איך לשחזר את זה?". זה יכול גם לקרות כאשר כמה אנשים עובדים יחד - כאשר הם עובדים יחד על אותה משימה, בזוג או באנסמבל.
5. ריבוי צווארי בקבוק פוטנציאליים - אם יש לנו פונקציה ייעודית של בודק תוכנה, יש לנו עוד קודקוד בגרף התקשורת שלנו ובגרף התלויות - כלומר, יש יותר מסלולים שצריך לוודא שעובדים, יותר פקקים שיכולים להיווצר ויותר מקום לטעויות. מבנה פשוט יותר תמיד עדיף, כאשר הוא מתאפשר.
6. יש ראיות אמפיריות שמוכיחות את זה. ספציפית, אם אנחנו קוראים את מה שכתבו מחברי accelerate נראה שהם מוצאים קורלציה חזקה בין הצלחת החברות לבין זה שמי שכותב ומתחזק את הבדיקות האוטומטיות הוא אותו אדם שכותב את הקוד למוצר. ומה לגבי בדיקות שאינן אוטומטיות? ובכן, הם מאוד דיפלומטיים שם, ולא מזכירים את הנושא לטוב או לרע. מספיק לזכור אולי שהספר הזה מסכם כמה שנים של סקר בשם state of devops כדי להבין שאין בעולם שלהם המון מקום לבדיקות שאינן אוטומטיות. 

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

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

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

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

אני מקווה שהטיעונים האלה משכנעים אתכם לפחות כמו שהם משכנעים אותי, אבל גם אם לא, 

Testers should not be

עברית

People who heard me speak about testing, or noticed what I wrote  here, for example, might know that I believe most companies should strive to get rid of dedicated testers. I think it's time to put some more words to it. There aren't that many reasons, but I find them convincing, and hope you will too.

1. No specialization required. In most places I've seen, at least 95% of the testing work can either be done or is being done by junior testers -  people without a lot of experience, and any skill they might possess can be taught to just about any software professional with relative ease. There are some cases where we need to define a strategy for a large project, or find a way to deal with large amounts of data, or cases where it's hard to define "correct". In those cases we might need an expert tester - but those are the rarity. 
2. Abdication of responsibility - when there's someone whose role is to find problems, the rest of the people are less careful. Even when they don't mean to. They submit their artifacts for "testing", so they assume they need to do very little of it themselves. 
3. Goal displacement - when there's one person writing code and another testing it, no one actually has the supposed shared goal - "deliver the right thing at a good pace". One has "deliver at a good pace", the other has "deliver the right thing" (if we're lucky, it might be "find reasons to delay the delivery"). This can lead to strange behaviors, that are perhaps best illustrated in an experience I had about eight or nine years ago, when I spent some time asking a developer to change the design of a feature in order to make it easier to test. His response was "it's not right to change design just for testing, and here are a few reasons why the current design is preferred". This very reasonable (yet wrong) response flew out of the window a couple of weeks later when the same developer was tasked testing the feature (we were transitioning to a role-less development team, which worked really well, I think) and after struggling for a few days, he came to the daily standup saying "I was having trouble testing the feature, so I made some changes to the design and now it's easy to test". All the good reasons suddenly were less important than having maintainable (which includes easy to test) code.
   We don't want people in the team to have different goals, unless it's really necessary.
4. longer feedback loop. It doesn't matter how hard we collaborate, how good are our tools and practices, getting the feedback from someone else almost always adds some overhead to the feedback loop. when we have the same person who does the work also verifying the job is done well, we get a faster feedback loop, and action is taken on that feedback more easily. We are much more likely to see the loop of "test-tinker-test" when the same people are doing both tasks (either as a pair or ensemble comprised of different skilled people, or as a homogenous group of one or more people)
5. More (potential) bottlenecks - with a dedicated tester, we've just made another vertex in our communication  and dependency graphs. This means that there's one more party to update and hope no significant information gets lost, and there's one more kind of work that we need to coordinate with the rest of the work. 
6. There is some empiric evidence this is the case, I'm familiar with the claims in "accelerate" (that have been very careful to narrow their scope to "automated tests", but I suspect this choice is a political one, as they don't mention any other kinds of testing that has any correlation to business success)

Ok, let that sink for a while. I can hear some rant in the distance, rambling about "What about the tester's mindset??", and there are a few examples where dedicated testers are simply a must and I'm sure they jump into your mind. As for the first objection - there isn't a thing like that. Testing, and the thinking associated with it are skills that are being taught and honed by experience that includes focus on risk seeking. In this aspect, a developer with a decade of experience will probably do a better work testing than most testers with two or three years under their belt. 

The second point, however, holds true, and this is why I believe only "most" companies can do without dedicated testers, and not all of them. The most notable example I've met is while I was interviewing for the team I was at a few years ago. The interviewee held a masters degree in physics and was testing a ground radar. His day job included a lot of calculations and applying his knowledge - knowledge the developers didn't have, nor did they have the time to acquire it. This is probably the only situation I can think of where having separate testers is more efficient than making testing a part of the creator's work. There might be some constraints that would make having dedicated testers a good choice for the time - we might not have the right culture, or we might be testing an application that we pay someone to develop and we don't trust their testing is good enough for us, or our budget and reporting mechanism might encourage us to behave in that way -  but those are conditions that should be eliminated over the longer term.

I hope you find those arguments convincing as much as I do, but even if you disagree, I hope it helps to understand my stance on dedicated testers.

Next: Why, despite those thoughts, I identify as a tester and invest effort in becoming better at it.

ושוב איתכם

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

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

אז התחלתי, באופן רשמי, באפריל האחרון. עד אז הייתי בצוות כבר תשעה חודשים, ולפחות באופן רשמי, נוהלנו באופן ישיר על ידי ראש הקבוצה שתפקד כראש צוות זמני. יש סיבות טובות לעיכוב הזה במינוי ראש צוות קבוע - כשלוקחים סטארט-אפ ברמת תפקוד ישראלית סטנדרטית ומצרפים אותו לתאגיד אמריקאי לא קטן, יש לא מעט שריפות שצריך לכבות בכל מיני צוותים, יש אנשים אחרים שעוזבים וצריך למלא את התקן שלהם, וצוות קטן וחדש שלא גוזל המון קשב ניהולי ובונה את עצמו בשקט יחסי בינתיים הוא לא הבעיה הכי דחופה. חוץ מזה, כמו שיודע כל מי שניסה לגייס אנשי בדיקות - השוק מלא במועמדים לא טובים מספיק, והדבר נכון שבעתיים לגבי ראש צוות. וכן, אני מניח שגם לזה שהייתי שם כדי לסתום חלק מהחורים שהיעדר מנהל משאיר בדרך כלל עזר קצת להפוך את המצב לנסבל. חוץ מזה, בשנתיים האחרונות הכל התנהל לפי סדר עדיפויות אחר לגמרי בכל המדינה. בכל מקרה, הדבר הכי נכון כדי למלא את המשימה שלי - להקל על המנהל שלי ולעזור לו להשיג את המטרות שלו בארגון - היה לקבל ניהול פורמלי של הצוות. אני לא בטוח אם קראתם את הפוסט של תומר על תסמונת המתחזה אבל הוא לגמרי צודק - תסמונת המתחזה אף פעם לא הולכת, גם לא אחרי עשור של חיזוקים חיוביים, למידה והצלחות בעבודה. ידעתי שעדיין לא פיתחתי את הכישורים הדרושים לעבודה החדשה, ושאני אפילו לא יודע עדיין במה היא שונה מהתפקידים הטכניים שביצעתי קודם.  מה שכן משתפר עם הידע והניסיון הם מנגנוני ההתמודדות עם ההרגשה הזו - אחרי התחושה הראשונית של "שיט, למה נכנסתי?" מנגנוני החשיבה האיטית נכנסים לפעולה ואני יכול לשים לב לכך שזו לא רק חוויה מפחידה, אלא גם הזדמנות צמיחה מצויינת. או לזכור שאני אולי לא יודע לנהל, אבל היו לי גם מנהלים טובים וגם מנהלים טובים פחות, ושאני יודע לזהות חלק מהמאפיינים של אלה או של אלה, שלאורך השנים קראתי והקשבתי ללא מעט תוכן שכלל גם פילוסופיה של ניהול צוות ושבסופו של יום, יש לי מנהל ישיר שאני יכול להיעזר בו. בנוסף, גם הידיעה שעד היום האסטרטגיה של fake it until you make it עבדה לי היטב, ושהחלקים נרחבים בעבודה היומיומית הם דברים שהתנסיתי בהם בעבר - כמוביל טכני יצא לי לעזור לאנשים לפתח את הכישורים שלהם, לכוון את העבודה הטכנית , לבנות backlog של משימות ואפילו לשבת לשיחות 1X1 עם אנשים. יש עדיין לא מעט חלקים חדשים, כמו לדעת מה עושה כל חבר צוות, או להעריך את תפקוד הצוות והחברים בו ולשפר אותם, או לתת פידבק לאנשים גם כשהם לא מגיעים אלי כדי לבקש אותו, אבל אני יכול להישען על החלקים שאני כבר יודע לעשות כדי ליצור איזו שגרה בתוכה אני יכול לתת שירות טוב מספיק בעודי משפר את החלקים החדשים ומגלה מה עוד אני לא יודע. זה גם עוזר שאני יודע מה אני רוצה לעשות כמנהל - אני רוצה לקדם את הרמה המקצועית בצוות ולתת לעובדים סביבה בה הם ירגישו שמקשיבים להם, ושהם מתפתחים ומשפיעים. אני רוצה לפנות להם את הזמן לעבוד ולא להתעסק בשטויות מעבר למה שצריך' ואם אפשר, לתת להם להתמודד עם משימות שיאתגרו אותם בדיוק מספיק כדי לצמוח.

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

בקיצור, לא קל, אבל מעניין. אחד הדברים שעוזרים לי הוא אסטרטגיה שפיתחתי ועזרה לי לא מעט בשנים האחרונות - כשאני עושה משהו חדש, אני נשען על הידע והכישורים שכבר יש לי. סקירת קוד? חניכה מקצועית? הקשבה? תכנון משימות? יש לי ניסיון סביר עם כל אלה, והם מהווים חלק משמעותי מניהול צוות. אז אני מתחיל משם ונעזר בהצלחות כדי לבסס את רף התפקוד הבסיסי, ומשפר את היתר. זה גרם לי לחשוב קצת על אנשים שעשו את המסלול המקוצר - שנתיים-שלוש כחברי צוות מן המניין (ובמקרה הגרוע באמת - בצוות שכולל רק אותם), ומשם להיות ראש צוות - כי הסטארט-אפ התרחב קצת, כי הם רצו "להתקדם" ולחצו, או אפילו אם הם באמת היו האדם הכי מתאים בסביבה. על אילו כישורים הם יכולים לסמוך? מה זה עושה ליכולת הטכנית שלהם? הרי גם עם צוות לא מאוד גדול, אני עדיין שורף המון זמן על משימות ניהוליות, וכל המיקוד שבעבר השקעתי בהתמודדות עם בעיות טכניות-עסקיות עכשיו מופנה לצרכים השגרתיים. כמה זמן לוקח למנהלים חסרי רקע עד שהיכולת שלהם לתפקד בתוך הצוות שהם מובילים נפגעת? איפשהו, האמונה שלי היא שמנהל צריך להיות מסוגל לבצע את העבודה שהוא מנהל באופן ישיר - כדי לסתום חורים כשצריך, כדי לעזור למי שתחתיו לבחון את העבודה שלו ולהשתפר בה. איך מי שלא רכש את המיומנות הזו מעולם מצליח לתפקד? בינתיים, התובנה הזו השפיעה על הדרך בה אני מסנן קורות חיים. עד היום התייחסתי לניהול צוות כאל בונוס - בעל קורות החיים הנ"ל  ראה עוד חלקים מהעבודה ויש לו ראייה רחבה יותר. הוא בטח גם יכול להוביל כל מיני אספקטים בצוות. היום, אני רואה גם את החיסרון - מי שהפך לראש צוות מוקדם מדי, סביר שלא התנסה מספיק בעבודה היומיומית ולא פיתח חלק מהאינסטינקטים. גם אם הוא אומר שהמשרה הייתה "70% הנדס-און", ניהול משנה את הפוקוס. עכשיו, ברור לגמרי - ראש צוות של אדם אחד כנראה מספיק לעשות יותר (בתור התחלה, הוא צריך להשקיע הרבה פחות בפגישות 1X1), אבל אני מאמין שאפילו במצב הזה, זווית הראייה של ניהול הצוות משנה את המיקוד - אני לא משקיע קודם כל בי ובאספקטים הטכניים, אלא קודם כל באחרים ובאספקטים התפעוליים. זה אומר שאני שם לב לדברים שונים, ולומד דברים אחרים. 

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

Hi again

 It's been a while since I last wrote here. A bit over a year, in fact, and I have many excuses. Truth is, some things have caught my attention and I dropped the habit of writing here, I think I want to catch up again on it. 

One of the things that happened in the past year, is that I was asked to lead the team I was in. Becoming a manager was something I have avoided so far since I was in a position to enjoy most of the fun parts of managing without the tedious or annoying parts. It was also an inertia thing - I started wanting to avoid managing at almost all costs, and having expressed that clearly and loudly, people around that kept assuming this was my position even when I started to warm up to the idea in the past few years when I got to experience more of the fun parts about managing. 

I officially started last April. By then, I was about 9 months into my new place, and my team was being managed by our group leader as an interim team lead. There have been a lot of reasons for this delay - we were a start up acquired by a corporate, there were other teams that needed attention, and finding a decent manager for a testing team is a difficult task. There were also external factors that took our attention. So, true to my claim of doing my best to help my manager in whatever way - I agreed to fill the gap. Despite having over a decade of good (and bad) managers, of functioning as a tech lead and mentoring team members, I felt unprepared for the task. After all, it's the first time that other I had such a direct impact on other people's careers. It is now up to me not only to provide guidance when asked or when I feel like it, but to actively evaluate the skills of the team members, identify gaps in the team and have a plan to fill them. It's also the first time I needed to define future plans that were not relying solely on my execution abilities but had to factor in the ability of other people to complete their work, based on their skills that I have no idea how to evaluate. One advantage I did have is that I knew, in theory, what was important for me as a manager. Specifically, I want to focus on nurturing my team into one I'll be proud to be a part of (which, to be frank, was not the starting condition, and was one of the reasons I was asked to join and then to manage) and my way of doing that is to try to provide my team members with what I got from my good managers and what I was missing from the less proficient ones - a sense of direction (what should they be doing next and why), coaching on their tasks - including feedback and help when needed, but allowing them to stretch their skills and a safe environment where they'd know they are heard.

Knowing something in theory, even if I  read about it in a book or a dozen, is very different than actually living up to it. I found out how difficult is to tell someone they need to improve without getting them defensive is a challenge, and keeping tabs on who does what at any given time is a lot even with just four people in my team. Add to that maintaining a backlog for the team, some code reviews and still taking a task every now and then, and I'm stretched pretty thin. On top of that I still need to raise my head above water and take the long-term view, which is a skill I'm still learning. So, great fun all around. 

As is my approach with most tasks in the recent years, I'm building from the things I know - I'm ok in coaching and in the technical aspects of the work,  I had the chance to practice one on ones in my previous workplace and for some odd reason, I'm good at making people think I listen to them (even when I don't, but I am honestly trying), I am also relying on my manager to take care of  some aspects I don't have the attention span to do now such as figuring out whether we have need for another person on the team or forcing me to stop and consider whether the work we're doing is effective. 

It's a new experience for me, and it really makes me wonder - it's not uncommon to see people transitioning to the management track early on in their careers - how much impact does this have on their technical abilities? I'm in a relatively relaxed situation - not a lot of team members, our deadlines are meaningful, but they don't  threaten to run the company out of business if we miss them, and still I find very little time to dedicate to the technical aspects of work, and mostly rely on the skills I've built in the past  decade or so.  Can a manager without such experience transition back to an IC role if they don't have such a foundation? It really makes me reevaluate the way I interpret CV's - managing a team, even a small one, strengthens a lot of leadership and bureaucratic skills, but even when being super involved in the technical aspects, it's still fairly limited. While I have no doubt that if asked, people in my team will say I'm into every detail of their work, that's true only in the superficial sense - Hopping around that many topics is preventing the deep diving into details needed for true work to happen - so I comment, I skim occasionally, and mainly - I rely on the tasks beings similar to ones I've done dozens of times, so I can seem to know what I'm talking about and still bring some value with low effort. 

Anyway, I'm not sure there's a message or a point to this post, I manly wanted to say hi again, and tell I'll be back to writing here. At least until I pick up the habit again,  I don't expect to write more than one blog a month (you'd be amazed how much time it takes me to write the same post in a 2nd language), but I'll try to keep at least to this pace.