למה אתם *לא* צריכים תיק עבודות

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

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

*המאמר בלשון נקבה (בלי סיבה מיוחדת), ופונה למעסיקים וג׳וניורים ולא רק למעסיקות וג׳וניוריות.

למה בכלל תיק עבודות?

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

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

1. אנחנו מכירים את החומר (שפות התכנות, הפריימוורקים וכו׳) ככל שניתן. לא הסתפקנו רק בקורס/בוטקאמפ/תואר אלא המשכנו ללמוד ולהתעמק בעצמנו.
2. יהיה עוד המון מה ללמוד בעבודה עצמה. דרך תיק העבודות נראה שאנחנו יודעים ללמוד לבד, עצמאית, בלי שיחזיקו לנו את היד. זה יוריד המון סיכון בהשקעה של הסביבה בהכשרת הג׳וניורית.
3. העבודה בתעשיה היא מאוד לא ״סטרילית״ כמו במסגרת לימודית. לא משנה אם זה תואר, בוטקאמפ או קורס. כלומר – בתדירות נמוכה מאוד יצא לנו לעבוד על קוד שכתבנו מאפס ואנחנו מכירים היטב. לרוב נעבוד על קוד לפחות בן שנה (במקרה הטוב שנה, אבל גם קוד בן 3,4 ואפילו 8 שנים זה לא מופרך), שעבר הרבה ידיים, הרבה ריפקטורינג והרבה גלגולים. הרבה מהיום שלנו יתרכז בכלל בקריאת קוד (כדי להבין איפה אנחנו מכניסים פיצ׳ר חדש, או איפה צריך לשנות משהו) מאשר כתיבת קוד. משהו שכמעט ולא נלמד בשום מסגרת.
4. בנוסף לכל אלו, העבודה היא עבודת צוות. פתאום עבודה עם Git זה לא רק אני מול ה-Git שלי, אלא זה עבודה עם עוד חברי צוות, שמירה על סטנדרט קוד של החברה, קונפליקטים בין אנשים שעובדים על איזורים דומים וכו׳.
   ואחרי שהכנסתי את הקוד, עוד לא סיימתי. הקוד הזה הוא קוד שהולך לפרודקשן ומכיל עשרות/מאות אלפי שורות קוד (אם לא מיליונים). צריך לוודא שהקוד הזה, שעוד מעט יגיע למשתמשים, לא שובר איזורים אחרים במערכת, מתנהג בצורה קוהרנטית עם פיצ׳רים אחרים. לכן הוא יעבור תהליכים של בדיקות אוטומטיות דרך תהליכי בילד אוטומטיים שביחד אנחנו קוראים לזה – CI (Continuous integration). אז אנחנו גם צריכים להבין בכתיבת טסטים ובתהליכי בילד.
5. ואם כבר עבודת צוות, צריך לדעת לקרוא תיעוד של חברי צוות אחרים (בין אם בקוד, בין אם Readmes או wikis למיניהם) וגם לכתוב ככה שיוכלו לתחזק את המערכות שלכם גם בלי לדבר איתכם ישירות. עוד משהו שפחות מתנסים בו במהלך לימודים.
6. חוץ מזה, בעבודה היומיומית לרוב מתממשקים עם מערכות אחרות. בין אם APIs פנימיים או חיצוניים. צריך להבין איך לקרוא תיעוד, איך להתממשק וכו'. לא תמיד יוצא לעשות את זה בפרויקטים פשוטים וזה skill פשוט הכרחי כמעט בכל פרויקט.

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

הטעות שחוזרת על עצמה

יצא לי לעזור להרבה מתכנתות ג'וניוריות עם תיק העבודות שלהן. התיק לרוב מכיל פוייקטים די דומים אחד לשני (ודומים למה שכולם עושים בתיק העבודות) – איזשהו אתר e-commerce (חנות אינטרנטית), איזה שירות הזמנות (נגיד למסעדה), אולי איזה לוח מודעות. כשחושבים על זה כולם בעצם אותו פרויקט. פרויקט CRUD (Create, Read, Update, Delete) שמעביר ביטים מצד לצד. יש איזשהו Database עם מודל פשוט, יש איזה שרת web שיודע לקבל קריאות HTTP מהאפליקציה הוובית שלנו ולשלוח שאילתות ל-DB ולהחזיר תוצאה. האפליקציה הוובית יודעת לשנות את ה-state על המסך. ובעצם כל תיק העבודות הוא העתקה של אותו פרויקט שוב ושוב ושוב. אחרי שעשיתם פרויקט אחד כזה, כבר די ברור שתוכלו לעשות את הפרויקט הבא.
כן, המשקיעניות כותבות פרויקט אחד בריאקט ואחד באנגולר. זה נחמד אבל זה לא מוריד את הסיכונים שהוזכרו לעיל.

אז מה אני מציע?

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

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

1. נסו לחשוב על משהו שהייתן משתמשות בו

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

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

2. בחרו פרויקט שיכלול כמה סוגים מרכיבים

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

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

3. בצעו טסטים

לימדו איך מבצעים Unit tests, integration tests, E2E tests וכו׳, והוסיפו טסטים לקוד שלכם. בתעשיה כמעט תמיד צריך לכתוב טסטים כחלק מהמשימה, בעיקר בחברות שמפתחות אפליקציות Web. הנה עוד סיכון שתוכלו להוריד על ידי הוכחה שאתם כבר יודעים לעשות את זה.

4. מצאו דרך לממש CI Pipeline

אם כבר עשיתם טסטים, למה שלא תלמדו קצת על CI (Continuous integration)? תקראו על מה זה בדיוק CI, ומצאו דרך לממש CI Pipeline. אפשר להשתמש ב-Github actions (כי גם ככה הפרויקט שלכם שם) או ללמוד על כלים סטייל CircleCI, Jenkins, TeamCity ועוד. כמובן אל תתפזרו, בחרו כלי אחד ותשקיעו בלהבין אותו ממש טוב ואיך לממש CI רק עליו. אין צורך ללמוד 10 פלטפורומות CI שונות.

5. תוסיפו פיצ׳רים

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

6. לימדו על גיט

לימדו על עבודה עם Git – נסו לעבוד כמה שיותר דומה לאיך שעובדים בתעשיה. כל פיצ׳ר חדש שתוסיפו שיהיה ב-Branch שבסוף עובר merge ל-main.

7. נסו לתרום קוד פתוח

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

8. אל תתביישו לשאול

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

אם תגיעו לכדי פרופיל Stack overflow מרשים (מעל 1000 נקודות זה מאוד מרשים לג׳וניורית לטעמי), תוכלו גם להוסיף את הלינק לפרופיל לקורות החיים שלכן ולהמם את המגייסות אפילו עוד יותר!

9. צרו קבוצות למידה

משהו שמאוד יכול לעזור זה לייצר קבוצת למידה עם עוד ג׳וניוריות ולבנות פרויקט גדול ביחד. זה יאפשר לכן למידת עבודה בצוות. תוכלו לפתוח כלי לניהול משימות (Jira, Trello, Monday, מה שבא לכן), לכתוב שם משימות, באגים וכו׳, לסמן מי עובדת על מה ולבסוף להשתפשף באספקטים הטכניים של עבודת צוות – קריאת קוד של מישהי אחרת, עבודה מרובת משתתפים עם Git, דוקומנטציה ועוד.

איך להבליט את הפרויקט בקורות החיים שלכם

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

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

כמה זמן זה יקח לי?

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

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

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

לקריאה נוספת:

• 5 רעיונות לפרויקטים בתכנות

אבי עציוני

מנהל פיתוח מנוסה, עד לאחרונה VP R&D ב-Planck ומנחה פודקאסט המפתחים הפופולרי ״מפתחים חסרי תרבות"