הבלוג של ינון פרק

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

אבל בתכנות הסיפור קצת אחר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כי על פניו אם אתה מתכנת Front End שכותב CSS ב-5 שנים האחרונות ואתה מגיע לחלק המקצועי בו שואלים אותך איך לשים אלמנט באמצע העמוד אתה כנראה יודע לדקלם את זה הפוך מתוך שינה. עכשיו שתי שאלות: קודם כל למה אנחנו שואלים שאלות מקצועיות בראיון עבודה? ולמה אנשים עם הידע המקצועי המתאים לא עוברים?

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

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

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

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

במשחקים עם דוקר ראיתי את השורה הבאה בתיעוד שלהם:

$ printf "This is a secret" | docker secret create my_secret_data -

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

זה עובד גם מחוץ לדוקר, למשל התוכנית wc יודעת די טוב לספור תווים בשורה שהיא קוראת מתוך STDIN או מקובץ, אבל אם יש לכם ביד טקסט קבוע תוכלו להשתמש ב printf כדי לשלוח אותו ישירות אליה:

$ printf "hello world" | wc -c
11

אז למה printf ולא echo? כי מסתבר ש echo מוסיף תו ירידת שורה לטקסט אותו הוא מדפיס. כך בספירת התווים אנחנו מקבלים:

$ echo "hello world" | wc -c

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

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

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

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

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

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

שפת Sass, שזה קיצור ל Syntactically awesome style sheets היא שפה שנועדה להוסיף מנגנונים של שימוש חוזר בחלקים מהקוד ל CSS. היא נכתבה על ידי הנרי תורנטון ונמצאת איתנו מ 2006. בזכות תאימות מלאה ל CSS קל מאוד להתחיל להשתמש בה וכך לאט לאט לשפר את קוד ה CSS שלכם. כל העבודה עם Sass מתבצעת בצד השרת לפני שהקבצים מגיעים לדפדפן ולכן מבחינת הדפדפן זה שקוף לגמרי. לגולש אין מושג אם אתם משתמשים ב CSS או ב Scss.

ביום חמישי הקרוב אעביר וובינר של שעה על Scss - החל מכלי העבודה הבסיסיים ודרך הרבה מהיכולות של השפה. מוזמנים בחום להצטרף (זה בחינם). המשך הפוסט הוא תקציר של מה שהולך להיות בוובינר. זה הקישור להצטרפות:

https://www.tocode.co.il/workshops/72

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

אבל קודם - מה זה בכלל אומר ״מוכנים הרבה יותר ממה שצריך?״

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

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

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

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

נ.ב.1 אפשר לעשות את זה כמעט עם כל טכנולוגיה. האנדרואיד כאן היה רק דוגמא.

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

בהצלחה.

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

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

ומה איתנו?

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

והתשובה כמובן שיש משהו שנשאר. שמתכנתת עם 5 שנים ניסיון בפיתוח Java שמגיעה ללמוד Objective C תסתכל על הטכנולוגיה בצורה אחרת לגמרי מתכנתת שרק עכשיו סיימה לימודים. ושלמרות שאולי לשתיהן כתוב בקורות חיים ״שנה ניסיון בפיתוח אפליקציות ל iPhone״, ה-5 שנים הקודמות גורמות לזה ששנה של אחת שווה יותר מהשנה של השניה.

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

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

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

הרבה יותר מועיל להתאים את רמת המשחק לרמת השחקן. השלבים נראים בערך כך:

1. קח את הקוד הזה ותקליד אותו אצלך ותראה שעובד.

2. קח את הקוד הזה שהקלדת ותשנה את הצבעים.

3. קח את האפליקציה הזאת ותוסיף לה פיצ'ר.

4. קח את הרעיון הזה ותבנה ממנו אפליקציה.

5. פשוט תעוף על זה :)

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

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

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

1. מדובר על מידע גלובאלי שכל רכיב ביישום משתמש בו.

2. מדובר על מידע שביסודו הוא Immutable, או לפחות שלא משתנה לעתים קרובות.

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

דוגמאות נפוצות ל Context כוללות: הגדרות שפה, הגדרות עיצוב גלובאליות ו Redux Store.