היי #פידטק, נניח ואתם חדשים בתפקיד שלכם ורואים משהו שגורם לכם לחשוב ״מה לעזאזל הם חשבו כשהם עשו את זה?!״, מה הדבר הראשון שאתם עושים?
אם התשובה היא ״משנים״, אז רוב הסיכויים שאתם טועים. בואו נדבר רגע למה ובדרך נעבור לנו דרך הגדר של צ׳סטרטון, נירמול הסטיה וחלון אוברטון.
בתור מתכנתים הדחף הראשוני שלנו הוא לפתור את כל הבעיות. אבל מה שנראה לנו בתור בעיה בשלב הראשון הוא לא בהכרח בעיה.
הגדר של צ׳סטרטון הוא עקרון שאומר ״יש פה גדר, אתה לא מבין למה, אל תלך להוריד אותה לפני שאתה מבין למה.״ en.wikipedia.org/wiki/G._K._Che…
יש פה 3 דברים שאנחנו צריכים להבין:
1) למה אנחנו בכלל רוצים להוריד את הגדר הזו? אם זה מרגיש לנו נכון אינטואיטיבית, אז מאיפה האינטואיציה הזו נכונה?
אנחנו חייבים את זה לעצמנו להבין למה הדחף הזה קיים, כדי שנוכל להסביר לעצמנו ולאחרים למה, בלי קונטקסט ״צ׳סטרטוני״ בכלל, השינוי נכון.
לפעמים נגלה שאין באמת רציונל טוב.
2) למה הגדר הזו הוקמה מלכתחילה?
במקרה הפשוט - נשאל, יספרו לנו ונבין. אפשר לא להסכים, אבל לפחות נבין.
במקרה המסובך יותר - לא ידעו להסביר לנו.
אז זהו? מותר לנו לעשות את השינוי?
ממליץ שלא. הדבר הנכון הוא לרשום את זה לעצמנו ולהמשיך ללמוד. מתישהו נחזור לרשימה הזו ואולי עד אז נבין.
3) למה הדבר הזה כל כך רחוק ממה שנראה לנו ״נורמלי״?
יש קונספט שנקרא ״נירמול הסטיה״ שבו קבוצה של אנשים עובדת ביחד במשך הרבה זמן ולאט לאט הם סוטים ממה שנראה נורמלי או סטנדרטי. לא בגלל שהם רעים או טיפשים, אלא פשוט כי הם ביחד ב-echo chamber שבו זה קורה טבעי.
אנשים חדשים שמגיעים לאותה קבוצה מגיעים בלי הסטיה מהנורמה ומשתמשים ב-beginner mindset שלהם כדי לזהות שיש סטיה. יכול להיות שמה שזיהינו הוא בעצם סטיה כזו.
אחזור למה שכתבתי ב-2 ואמליץ לרשום את ה״סטיה״ הזו ולהמשיך ללמוד. יכול להיות שהיא הגיונית וסבירה ואנחנו אלה שלא מבינים.
אגב, אני ממליץ לכל עובד ועובדת חדשים אצלנו לפתוח מסמך פרטי כזה אצלם בשם Gripes Doc (מסמך תלונות) ולהתחיל לתעד. כמעט שנתיים לתוך התפקיד הנוכחי, אני עדיין מדי פעם חוזר אל שלי.
אבל נניח, שאחרי כל הבחינה העצמית הזו והזמן שעבר כדי ללמוד למה המצב כמו שהוא, שהבנתם שזה משהו שצריך לשנות.
אם מדובר במשהו שבשליטתכם המלאה לפתור, מצוין - הגיע הזמן להחליט מתי לפתור אותו.
מצד שני, אם זה משהו שצריך לשכנע אחרים לעשות, אתם צריכים להבין איפה הוא יושב על חלון אוברטון.
חלון אוברטון (עם דרגות טרביניו) הוא מונח מעולם מדעי המדינה שמדבר על ״מהם הדברים שמקובלים בשיח״. זה כלי שעוזר לכם להבין האם השינוי שאתם הולכים להציע יגרום לכם להראות כמו משוגעים בעיני החברים שלכם לקבוצה.
נניח שהשינוי שאתם רוצים להציע, עבור מישהו שחי את הסטיה מהנורמה, נופל על Sensible, לא יהיה לכם קשה מדי לשכנע אותו. מצד שני, אם אחרי שסקרתם את השטח והשינוי הוא Radical או Unthinkable, כדאי לעצור ולחשוב איך אפשר להזיז את החלון לכיוון. תמצאו רעיון שנופל בתוך החלון בכיוון הכללי הנכון.
אחרי שעשיתם מספיק עבודה (טובה ומוצדקת) בקצה החלון, אתם תקבלו את ה-buy in של אנשים והחלון לאט לאט יזוז לכיוון של השינוי שרציתם לעשות מלכתחילה.
לדוגמא (פשטנית): כולם אצלכם משתמשים ב-Hungarian Notation וקוראים למשתנים שלהם strStreetAddress או intCount. איך מזיזים אותם מזה?
נניח וזיהינו שזה Unthinkable, אבל שמצד שני לאף אחד אין בעיה שתשתמשו באיזה IDE שאתם רוצים. צעד אפשרי הוא להשתמש ב-IDE שמוסיף את ה-typeים בזמן העריכה לחלון העריכה, אבל לא לטקסט:
עכשיו הגיע הזמן להראות לכולם ולהשוויץ ב-IDE התותח שלכם שמראה לכם את ה-typeים בלי שתצטרכו לכתוב אותם בעצמכם שוב ושוב ושוב.
נניח והצלחתם ויותר ויותר אנשים עוברים להשתמש ב-IDE הזה? עכשיו הזזתם את חלון אוברטון ואולי עכשיו היכולת לדבר על לרדת מ-Hungarian Notation לא נראה כל כך מטורף.
אז דיברנו על איך עושים שינוי, למה כדאי להבין למה הגדר של צ׳סטרטון עומדת לה, איך זה שהסטיה נורמלה ואיך לחשוב על חלון השינוי של אוברטון כדי להביא את השינוי בהדרגה במקום להפוך להיות המוזרים האלה שעושים ההיפך מכולם :)
אם יש לכם סיפורים על שינויים שעשיתם, ספרו ואשמח ללמד מהם!
During my time at WeWork, while working on developer tooling, I wrote and reviewed lots of documents: PRD’s, design docs, technical docs, tutorials, etc.
Here’s a short thread about a few lessons I learned from the mistakes I made along the way:
1) Ask yourself who your audience is. Consider what they should already know before reading and what you’d like them to know when they’re done.
2) Not all readers will have complete context. Link to previous docs. Consider changing previous docs to link to your new doc.
3) It’s possible that a document isn’t the right medium. Other options include: Your company’s wiki, a slide deck, a README.md file in the repo, a meeting, a recording of you presenting slides... Consider your audience and what you aim to achieve.
Twitter thread of all the cool things *that may have gone under the radar* in the @scala_lang 2.13.0 release as I'm reading the release notes :) github.com/scala/scala/re…
You can now access the names of the fields in a Product (e.g. case classes)! No more need to use reflection or use macros/shapeless to get them! github.com/scala/scala/pu…
unfold is a useful new method that lets you create an iterable (list, etc.) out of a single value github.com/scala/scala/pu…