ToCode

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

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

def v1(fin_name, fout_name):
    with open(fin_name, encoding='utf8') as fin:
        with open(fout_name, 'w') as fout:
            for line in fin:
                fout.write(line)

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

from contextlib import ExitStack
def v2(fin_name, fout_name):
    with ExitStack() as stack:
        fin  = stack.enter_context(open(fin_name, encoding='utf8'))
        fout = stack.enter_context(open(fout_name, 'w'))
        for line in fin:
            fout.write(line)

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

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

# שלוש שאלות חשובות על מיומנות יש רק שלוש שאלות ששווה להתלבט לגביהן לפני שמחליטים אם לקחת או לא לקחת מסלול לימוד מסוים (קורס, ספר, השתתפות במיטאפ, פיתוח פרויקט לבד וכו'): ## האם אני יכולה להשתפר? שאלה ראשונה - האם אני בכלל יכולה להיות טובה יותר בדבר הזה? אני כמובן רוצה לצעוק "כן!" לא משנה מה הנושא, אבל האמת קצת יותר מורכבת. אולי העוגת גזר שאתה מכין לכל אירוע משפחתי בעשר השנים האחרונות היא ממש טובה כמו שהיא. כולם כבר התרגלו לטעם וכל שינוי רק יזיק. כולנו מכירים מאכלים כאלה שאנחנו אוהבים בדיוק בגלל שהם כמו שתמיד היו. אולי את כבר יודעת ממש טוב למלא את הדוח השנתי למס הכנסה. העסק שלך לא משתנה יותר מדי, את מתעדכנת מדי פעם בשינויי החקיקה, ישבת עם רואה חשבון שילמד אותך כל מה שצריך ווואלה הדוח יוצא מעולה. גם במקרה הכי טוב שתצליחי לדחוף עוד הוצאה זה לא יחסוך לך יותר מדי ובטח לא משהו ששווה להתאמץ בשבילו. זה הכי טוב שזה מגיע. לפני שאנחנו מתחילים להתאמן כדי להשתפר כדאי להיות משוכנעים שזה משהו שאפשר בכלל לעשות אותו יותר טוב. ## האם כדאי לי להשתפר? בתכנות המצב יחסית קל - כל מי שאני מכיר שכותב קוד יכול לעשות את זה יותר טוב, וכל המתכנתים הטובים שאני מכיר מודעים לזה שכשאנחנו מעלים את הרמה אנחנו מרוויחים המון. האתר הזה כתוב ב Ruby On Rails. כשהתחלתי אותו כמעט ולא ידעתי Rails, אבל היום 6 שנים אחרי אני יודע מספיק ריילס בשביל להתעצבן כמעט על כל שורת קוד שכתבתי כשהתחלתי. יש לי גם את הפרספקטיבה לראות איך כשאני כותב קוד חדש היום אני יכול הרבה יותר בקלות להוסיף אליו פיצ'רים והקוד מכיל הרבה פחות באגים בהשוואה ללפני כמה שנים. שיפור המיומנות שלי חסך לי שעות של עבודה בפיתוח ותחזוקה של האתר. ובגלל שכולם בתעשיה יודעים את זה כל החברות רוצות לגייס את ה 5% מתכנתים הטובים ביותר בארץ, והעיתונות מלאה בכתבות על האבסורד שמצד אחד יש כל כך הרבה משרות תכנות פנויות ומצד שני יש המון מחפשי עבודה שלא מצליחים להשיג את המשרות האלה. ## האם המסלול המוצע יעזור לי להשתפר? עכשיו אנחנו מגיעים לשאלה הקובעת: אם אני יודע שבתור מתכנת מאוד משתלם לי כל הזמן ללמוד ולהשתפר, נרצה לשאול על דרך לימוד ספציפית האם היא שווה את הזמן שלי. האם לקרוא ספר על Design Patterns יעשה אותי מתכנת טוב יותר וייתן לי כלים טובים יותר ממה שיש לי כדי להתמודד עם בעיות ביום יום? האם לקחת קורס אונליין על Rails יהפוך אותי למתכנת ריילס טוב יותר? האם לבנות פרויקט-צד ב React יהפוך אותי למתכנת ריאקט טוב יותר? האם להעביר הרצאה במיטאפ יעזור לי ללמוד משהו יותר לעומק? והנה משימת הבית שלכם להיום - קחו שלושה נושאים שהייתם רוצים להשתפר בהם וכתבו לעצמכם 5 הצעות לדברים שאתם יכולים לעשות כדי להשתפר בכל אחד מהנושאים (סך הכל 15 משימות). לא צריך לעשות את כולן יחד, אבל כן כדאי לבחור אחת, את זו שנראית הכי חשובה או הכי כיפית, ולהתחיל איתה. וכן היום זה יום מצוין לזה.

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

class VM:
    def __init__(self):
        self.memory = defaultdict(int)

    def add(self, x, y):
        self.memory[x] += y

עכשיו אנחנו יכולים להפעיל את הפקודה add כדי להוסיף ערך לזיכרון:

vm = VM()
vm.add('a', 10)

# prints 10
print(vm.memory['a'])

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

    def set(self, x, y):
        self.memory[x] = y

    def mul(self, x, y):
        self.memory[x] *= y

    def mod(self, x, y):
        self.memory[x] %= y

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

vm = VM()
vm.add('a', 10)
vm.set('b', 20)
vm.add('a', 'b')

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

    def add(self, x, y):
        self.memory[x] += valify(y)

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

    @valify(1)
    def add(self, x, y):
        self.memory[x] += y

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

def valify(index):
    def decorator(f):
        def inner(self, *args):
            next_args = list(args)
            if args[index] in string.ascii_lowercase:
                next_args[index] = self.memory[args[index]]
            else:
                next_args[index] = int(args[index])

            f(self, *next_args)
        return inner
    return decorator

אז נכון שילמנו מחיר בכתיבת פונקציית Decorator שהיא יותר מורכבת מאשר פונקציה רגילה, אבל הרווחנו שרוב הקוד שלנו יישאר נקי יותר וכמעט לא יושפע מהעדכון בדרישות. נ.ב. אני מסביר ממש לעומק על התחביר של Decorators עם עוד המון דוגמאות למקרים בהם כדאי להשתמש בו בקורס פייתון מתקדם כאן באתר. אם אתם כבר כותבים פייתון ורוצים להעלות את הרמה ולכתוב קוד נקי יותר ממליץ להעיף מבט. זה הקישור לקורס: https://www.tocode.co.il/bundles/advanced-python3

# חדש באתר: קורס ריאקט לייב - לומדים חודשיים עם מרצה ויוצאים עם פרויקט ביד הי חברים, אני לא מבין איך אנשים עדיין לומדים בכיתות. באמת. הסיטואציה הזאת של לשבת בכיתה מול מרצה, להתאמץ כדי להישאר מרוכז (ולאבד את זה כל פעם מחדש) ובדיוק כשאתה מרגיש שמתחיל להבין יש איזה משהו שמתפרץ עם שאלה הכי לא קשורה ושוב הלכת לאיבוד. אף פעם לא היתה לי חווית לימודים טובה בכיתה. כשאני לומד אונליין מול המחשב אני מרוויח בגדול: אני יכול לראות את השיעור כמה פעמים שאני צריך עד שאני מבין. אני יכול לדלג על קטעים שלא מעניינים אותי. אני יכול להתאמן בלי שאף אחד מסתכל. ואני יכול לשאול שאלות בלי להרגיש שרק אני לא הבנתי. אבל גם ללמוד אונליין זה קשה. זה קשה כי בשביל להתקדם אתה צריך עוד אנשים, אתה צריך אנשים שישאלו אותך שאלות על הקוד שכתבת, אתה צריך שיראו לך את מקרי הקצה ואת הכיוונים שלא חשבת עליהם. ובתכנות זה אפילו יותר מסובך, כי בשביל ללמוד ברמה גבוהה צריך לשבת לכתוב פרויקט ברמה גבוהה, ורובנו לא יודעים להמציא לעצמנו פרויקטים טובים לפני שאנחנו מכירים לעומק טכנולוגיה מסוימת. אני חושב שאנחנו יכולים לעשות משהו יותר טוב. שאנחנו יכולים לשבור את המחסום בין האונליין לאופליין ולהינות מהיתרונות של שני העולמות. במתכונת החדשה, טוקוד לייב, נקיים קורס של חודשיים בליווי מרצה ובכיתה אונליין, במהלכו בנוסף לחומר הלימוד גם כל משתתף ומשתתפת יכתבו פרויקט מעשי ברמה גבוהה ובסיום הקורס תצאו עם פרויקט ביד ומספיק ביטחון וידע כדי להיכנס לעבודה או להמשיך לבנות פרויקטים עצמאית. הקורס הראשון יהיה React ומיועד למתכנתים שכבר יודעים לכתוב קוד Front End, מכירים JavaScript ברמה סבירה אבל מכל מיני סיבות לא הצליחו עדיין להיכנס לשוק העבודה למשרות ה Front End הטובות באמת. הקורס ייפתח באמצע מרץ ויימשך חודשיים. אם אתם מרגישים שאתם יודעים לעבוד, אולי אפילו למדתם או ניסיתם ללמוד ריאקט לבד אבל עדיין אתם עובדים במשרה שקטנה עליכם ומרגישים תקועים, הקורס הזה יהיה תפור עליכם. העבודה שתעשו במהלך החודשיים, הפרויקט איתו תצאו והשיחות השבועיות בהן תציגו את ההתקדמות שלכם מול הכיתה יתנו לכם את הידע והביטחון לרוץ קדימה. לכל הפרטים על קורס ריאקט הקרוב מוזמנים לקפוץ לדף הנחיתה החדש שבניתי בקישור https://www.tocode.co.il/live_courses/1 נתראה בקורס ינון

הי חברים התחלתי היום רישום לקורס ריאקט במתכונת חדשה ToCode Live הקורס יועבר אונליין בליווי מנטור ובהנחיה שלי ויכלול חודשיים של למידה ועבודה מעשית על ריאקט כדי לבנות פרויקט שיהיה מספיק טוב כדי להכניס אתכם לעבודה אמיתית כמפתחי React יהיה וידאו מוקלט על כל הנושאים יהיו וובינרים חיים לשאלות וכדי להציג את העבודה שלכם מול כולם תהיה קבוצת דיונים והחלפת רעיונות ויהיה מנטור שיעזור כל פעם שנתקעים פוסט יותר ארוך עם יותר פרטים יצא מחר בבוקר, ובינתיים אם אתם סקרנים מוזמנים לראות את הפרטים בדף הרישום ולשלוח אליי הודעה (או להשאיר שם פרטים) אם מעניין אתכם https://www.tocode.co.il/live_courses/1

# זה אף פעם לא משתלם להתחיל מאפס מדי פעם אנשים שואלים אותי אם שווה להיכנס לתחום X או תחום Y. בן אדם אומר לעצמו - אני כרגע יודע לכתוב בדיקות אוטומטיות אבל קצת משעמם לי ואני לא רואה אפיק קידום טוב, אולי שווה לי ללמוד לפתח אפליקציות לאנדרואיד במקום? זאת שאלה טובה כי היא מחביאה הרבה ניואנסינים במיוחד המילה "שווה". גם בהנחה הכי אופטימית, ללמוד לפתח אפליקציות אנדרואיד מאפס עד לרמה שאתה יכול להיות מועיל ייקח בין שנה לשנתיים. נכון, תוצאות ראשונות תראו כבר אחרי חודשיים-שלושה, ואפליקציה ראשונה בחנות אפשר לשים תוך חצי שנה. אבל להיות טוב בזה? ברמה שמישהו ייקח אותך לעבודה בתור מפתח אנדרואיד? ברוב התחומים זה דורש זמן והרבה עבודה (לפחות שעה ביום, לרובנו תוך כדי עבודה במשהו אחר כי צריך עדיין להתפרנס). אם את אותה שעה ביום היית משקיע בללמוד יכולות נוספות של פיתוח בדיקות אוטומטיות, היית יכול להעלות לעצמך את המשכורת ולהתקדם משמעותית יותר מהר: למשל ללמוד איך עובד Jenkins או איך להשתמש נכון ב Github Actions, ללמוד דוקר או לינוקס יותר לעומק או אפילו להתמקצע ב JavaScript כדי לכתוב בדיקות מדויקות יותר - כל אלה היו מניבים לכם רווח הרבה יותר גדול בטווח הבינוני והקצר בהשוואה ללימוד משהו חדש מאפס. והסיכון היחיד בלהמשיך להתמקצע בדבר הזה שאתה כבר עושה הוא שהמקצוע או הטכנולוגיה יעלמו. זה קורה אבל זה מאוד נדיר: מפתחי צד-לקוח טובים שהמשיכו להתמקצע ברצף מסוף שנות ה-90 רק מרוויחים מכל שינויי הטכנולוגיות ומצליחים כל הזמן להעלות את הערך שלהם. מפתחי Mobile מנוסים לא הפסיקו להיות מפתחי Mobile כשאפל עברו ל Swift, אלא המשיכו ללמוד Swift וגם Kotlin וממשיכים להשתפר ולהעלות את הערך של עצמם. הבחירה להתמקצע לאורך שנים במקצוע היא כמעט תמיד יותר משתלמת ופחות מסוכנת מהבחירה לדלג בין מקצועות. זה קצת כמו הקופות בסופר: מרגע שנעמדתם ליד קופה ברוב המקרים שווה להישאר בה, גם אם נראה שבקופה ליד התור רץ יותר מהר, ובכל מקרה כשמתחילים לעבור 3, 4 ו-5 קופות אנחנו רק ניתקע יותר זמן בתור. אבל... אני לא רוצה להיות מפתח Mobile כל החיים אבל ... כולם מדברים על Machine Learning אבל ... שמעתי ש Full Stack זה המקצוע הכי טוב למתכנתים אבל ... בדיקות אוטומציה זה משעמם הכל טוב. אני אתכם. לא הכל זה כסף בחיים והרבה פעמים שווה לקחת את ההימור ולהיכנס לתחום חדש כי קשה לשמר את התשוקה לעבודה לאורך זמן באותו תחום או כי התחום החדש נראה מדליק ומלהיב יותר או כי יש לך רעיון מטורף לאפליקציה וחייב לכתוב אותה. אני בעד. באמת. רק שימו לב שאתם מבינים לאן אתם נכנסים ויש לכם את המוטיבציה להגיע בשלום לצד השני.

# סדר פעולות 1. לבנות משהו פשוט לפי Tutorial. 2. לבנות משהו קצת יותר גדול לבד. 3. לקרוא ספר. 4. לקרוא קוד של אחרים. 5. לשמוע הרצאות מכנסים ביוטיוב. 6. לעשות Refactoring לקוד שכבר כתבנו. 7. לחזור לסעיף (2) וכן זו לולאה אינסופית, וכן היא עובדת לכל טכנולוגיה שתבחרו. כל איטרציה נוספת בונה עוד קומה במגדל הידע, וכל קומה פותחת את הדלת לרעיונות חדשים ומפתיעים.

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