בעיית ה-XY היא לשאול על הפתרון שניסיתם (Y) במקום על הבעיה האמיתית שלכם (X) – כך שאנשים בסוף עוזרים לכם בדבר הלא נכון.
יש לכם בעיה. אתם לא שואלים עליה.
אתם רוצים לעשות X. אתם חושבים ש-Y אולי הדרך לעשות את זה. אתם לא יודעים איך לעשות Y, אז אתם מבקשים עזרה עם Y. מישהו מבזבז 20 דקות לעזור לכם עם Y. ואז מתברר ש-Y מעולם לא היה פותר את X מלכתחילה.
זו בעיית ה-XY. וזה קורה כל הזמן – בשרתי Discord, שרשורים ב-Stack Overflow, ערוצי Slack, קבוצות וואטסאפ, ובכל מקום אחר שבו אנשים מבקשים עזרה.
החלק הגרוע ביותר? אתם לא מבינים שאתם עושים את זה. אתם באמת חושבים שאתם שואלים את השאלה הנכונה. אתם פשוט כל כך מרוכזים בפתרון שכבר בחרתם שהם שכחתם להזכיר את הבעיה האמיתית.
איך זה נראה בפועל
תכנות: מלכודת סיומת הקובץ
מישהו שואל בצ’אט:
איך אני מקבל את 3 התווים האחרונים של שם קובץ ב-Python?
עוזרים קופצים פנימה. הם מציעים חיתוך מחרוזות, filename[-3:], דפוסי regex. חמש עשרה דקות של דיון הלוך-חזור. אז מישהו סוף סוף שואל: “למה אתה צריך את 3 התווים האחרונים?”
אני רוצה לבדוק אם קובץ הוא
.csv.
התשובה האמיתית? filename.endswith('.csv') או pathlib.Path(filename).suffix. לקחת את 3 התווים האחרונים היה נכשל על .json, .xlsx, או כל סיומת שהיא לא בדיוק 3 תווים.
הבעיה הייתה X (לבדוק את סוג הקובץ). הם שאלו על Y (לקבל את 3 התווים האחרונים).
תכנות: מחילת הארנב של Regex
איך אני כותב regex שמאמת כתובת אימייל?
זו אחת מבעיות ה-XY הכי נפוצות בתכנות. הבעיה האמיתית היא כמעט תמיד “אני צריך לבדוק אם המשתמש הזין אימייל תקין.” התשובה לזה היא: אל תשתמשו ב-regex. שלחו אימייל אישור. או השתמשו בספריית ולידציה מוכחת. לכתוב regex משלכם לאימייל זה רעיון גרוע ידוע ששרף אלפי מפתחים.
אבל מי ששואל כבר החליט ש-regex זה הפתרון. אז הוא שואל על regex, והבעיה האמיתית אף פעם לא עולה.
לא-תכנות: המקדחה והחור
אדם נכנס לחנות חומרי בניין:
מה מקדח ה-1/4 אינץ’ הכי טוב לגבס?
המוכר יכול פשוט להצביע על המקדחים. אבל מוכר טוב שואל: “מה אתה מנסה לעשות?”
אני רוצה לתלות תמונה.
מתברר שהוא לא צריך מקדח בכלל. פסי דבק או מסמר קטן יעבדו טוב יותר, יגרמו לפחות נזק, ויקחו חלק קטן מהזמן. הוא לא היה צריך מקדח – הוא היה צריך תמונה על הקיר.
לא-תכנות: לוח הזמנים בעבודה
מישהו שואל את המנהל שלו:
אפשר לעבור למשמרת שלישי/חמישי?
המנהל מתחיל לבדוק התנגשויות בלוח הזמנים, דרישות כיסוי ולוגיסטיקת כוח אדם. אחרי דיון ארוך, הוא שואל למה.
אני צריך לאסוף את הילד מבית הספר בשני, רביעי ושישי.
עכשיו המנהל רואה את הבעיה האמיתית ומציע פתרון פשוט יותר: להזיז את שעת ההתחלה בשעה בשלושת הימים האלה. אין צורך לארגן מחדש את כל לוח הזמנים. העובד היה כל כך מקובע על פתרון ספציפי אחד שהוא אף פעם לא הזכיר מה הוא באמת צריך.
איך לזהות שאתם עושים את זה
אתם כנראה בטריטוריה של בעיית XY כש:
אתם שואלים על כלי או שיטה ספציפיים במקום על מטרה. אם השאלה שלכם מתחילה ב"איך אני משתמש ב-X כדי…" יש סיכוי טוב שצריך לשאול “איך אני משיג Z?” במקום.
השאלה שלכם דורשת הרבה הסבר רקע. אם אתם מוצאים את עצמכם כותבים שלוש פסקאות של הקשר כדי להצדיק למה אתם מנסים לעשות משהו חריג, עצרו רגע. הגישה החריגה עשויה להיות הגישה הלא נכונה.
התשובות שאתם מקבלים לא ממש פותרות את הבעיה. אם אנשים ממשיכים לענות על השאלה שלכם נכון אבל התשובות שלהם לא עוזרות, ייתכן שאתם שואלים את השאלה הלא נכונה.
אתם נלחמים בכלים. כשהגישה שלכם דורשת לעקוף את הדרך הרגילה שבה דברים נעשים, זה סימן. ייתכן שאתם כופים פתרון במקום שקיים פתרון טוב יותר.
מישהו שואל “מה אתה בעצם מנסה לעשות?” כשעוזר שואל את זה, הוא לא מקשה. הוא זיהה את בעיית ה-XY. ענו לו בכנות – הוא מנסה לחסוך לכם זמן.
איך להימנע מזה
התיקון פשוט: שתפו את הבעיה המקורית, לא רק את הפתרון שניסיתם.
זה לא אומר שלא צריך להזכיר מה ניסיתם. בהחלט כן – זה מראה מאמץ ועוזר לאנשים להבין את החשיבה שלכם. אבל תתחילו עם הבעיה, לא עם ניסיון הפתרון.
לפני (בעיית XY):
איך אני מפרסר HTML עם regex ב-Python?
אחרי (הבעיה האמיתית):
אני צריך לחלץ את כל הקישורים מדף אינטרנט. התחלתי לנסות להשתמש ב-regex כדי לפרסר את ה-HTML, אבל אני לא בטוח שזה עובד נכון. יש גישה טובה יותר?
עכשיו העוזר רואה את המטרה האמיתית (לחלץ קישורים) ואת הגישה שניסיתם (regex). הוא יכול להפנות אתכם ל-BeautifulSoup או lxml במקום לעזור לכם לכתוב regex שיישבר על דף HTML קצת שונה.
לפני (בעיית XY):
איך אני מגדיר משתנה סביבה מתוך Dockerfile CMD?
אחרי (הבעיה האמיתית):
האפליקציה שלי צריכה ערך קונפיגורציה שונה ב-production לעומת staging. חשבתי על הגדרת משתנה סביבה בהוראת CMD, אבל זה לא עובד כמו שציפיתי. מה הדרך הנכונה לטפל בקונפיגורציה לכל סביבה ב-Docker?
הגרסה השנייה מזמינה תשובות על Docker env files, build args, docker-compose overrides ופתרונות נכונים אחרים. הגרסה הראשונה לוכדת עוזרים בדיבוג של גישה שגויה.
הקשר לשאילת שאלות טובות יותר
בעיית ה-XY היא בעצם מקרה ספציפי של בעיה גדולה יותר: לשאול אם מותר לשאול על הדבר הלא נכון. כשאתם מדלגים על ההקשר האמיתי וקופצים ישר לפתרון שהנחתם, אתם מסתירים את המידע שהעוזרים הכי צריכים.
נוסחת Skip The Ask מטפלת בזה באופן טבעי:
- המצב שלכם – עם מה אתם עובדים והמטרה האמיתית שאתם מנסים להשיג
- השאלה הספציפית – במה אתם צריכים עזרה, ממוסגר סביב המטרה, לא רק סביב פתרון אפשרי אחד
- פרטים רלוונטיים – מה כבר ניסיתם (כולל הגישה שהובילה אתכם במסלול ה-Y) ולמה זה לא עובד
כשאתם מתארים את המצב מתוך הבעיה האמיתית, אתם נותנים לעוזרים את התמונה המלאה. הם יכולים להעריך את הגישה שלכם וגם להציע חלופות שלא חשבתם עליהן. ככה מקבלים תשובות שבאמת פותרות את הבעיה במקום תשובות שטכנית עונות על השאלה אבל משאירות אתכם תקועים.
בפעם הבאה שאתם עומדים לבקש עזרה, עצרו לחמש שניות ושאלו את עצמכם: האם אני שואל על מה שאני באמת צריך, או שאני שואל על גישה ספציפית אחת שכבר בחרתי? אם זה האחרון, חזרו אחורה. תתחילו מ-X, לא מ-Y.
למבט רחב יותר על שאילת שאלות טובות יותר בכל פלטפורמה, ראו את המדריך המלא שלנו לשאילת שאלות טובות יותר באינטרנט.