ToCode

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

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

קל מדי זה לא סימן טוב אחד הדברים שלמדתי כשהתחלתי לעשות כושר - אם תרגיל קל מדי אתה כנראה לא עושה אותו נכון. והדבר אפילו יותר נכון כשמדובר בקוד. הקריטריונים שלנו למה נחשב טוב משתפרים עם הזמן. במיוחד בתחילת הדרך עדיין קשה לנו לראות שאנחנו מתרגלים את הדבר הלא נכון ומשתפרים בפרמטרים שהם לא כאלה חשובים. תחושת ההצלחה היא חשובה ולכן אם אני בתחילת הדרך נאבק שעה בתרגיל ובסוף מגיע לתוצאה זה ממש בסדר, גם אם הטכניקה לא היתה טובה (וגם אם חצי מהתוצאה כתב ChatGPT). אבל אז אנחנו משתפרים ולומדים להשתמש ב Chat GPT טוב יותר או לחפש בגוגל טוב יותר או לגרום לדברים לעבוד יותר מהר, ופתאום אותו תרגיל או תרגילים דומים נהיו הרבה יותר קלים. הרבה אנשים יעצרו כאן ויגידו "אני יודע ריאקט" או "אני יודע פייתון" ומפה זה רק עוד מאותו דבר. החוכמה היא לעצור כאן ולהתעכב רגע על אותו תרגיל קל מדי. לחפש לשבור אותו. לחפש שינויים קטנים שיגרמו לו להיות יותר קשה. החיפוש הזה לבדו הוא בעל ערך, והאוצר האמיתי הוא כשמוצאים את הטכניקה הנכונה. את השינוי באופן הפיתרון שגורם לתרגיל להיות מאתגר וללמד אותך משהו חדש על הפריימוורק. כמו בשיר של שלמה ארצי, יש להאט, להביט ולשים לב לפרטים כדי להתקדם לארץ חדשה.

if (value > maxValue.value) {        
    maxIndex.value = counterIndex;
    maxValue.value = value;
  }
}
</script>

<template>
  <Counter @change="(newValue) => onNewValue(0, newValue)" :isMax="maxIndex == 0" />
  <Counter @change="(newValue) => onNewValue(1, newValue)" :isMax="maxIndex == 1" />
  <Counter @change="(newValue) => onNewValue(2, newValue)" :isMax="maxIndex == 2" />
  <Counter @change="(newValue) => onNewValue(3, newValue)" :isMax="maxIndex == 3" />
</template>

ואת קומפוננטת המונה באופן הבא:

<script setup lang="ts">
import { ref, computed } from 'vue'

const count = ref(0)
const emit = defineEmits(['change']);
const {isMax} = defineProps<{isMax?: boolean}>();
const background = computed(() => isMax ? "green" : "yellow");

function onClick() {
  count.value++;
  emit('change', count.value);
}
</script>

<template>
  <div>
    <p>Value = {{ count }}</p>
    <button @click="onClick">+1</button>
  </div>
</template>

<style scoped>
  div {
    background-color: v-bind(background);
    padding: 20px;
  }

  button {
    color: white;
  }

  p {
    color: black;
  }
</style>

יתרונות וחסרונות בשתי הגישות נשים לב להבדלים וליתרונות והחסרונות בין שתי הגישות: 1. הגישה הראשונה היתה יותר פשוטה מנקודת מבט של כל קומפוננטת מונה וגם מנקודת המבט של הקומפוננטה העוטפת. כל המידע של כל המונים נשמר במערך אחד וכל פעם שהוא משתנה בודקים מי הערך המקסימלי ומעדכנים את כל המונים. 2. הגישה השנייה טובה יותר מבחינת ביצועים. כל פעם שמתעדכן מונה צריך לבצע רק השוואה אחת, במקום לרוץ על כל מערך המונים ולחפש את הערך המקסימלי. אבל ההבדל הכי גדול בין שתי הגישות הוא התלות בין הקומפוננטה למקום שלה. בגישה הראשונה אנחנו לא יכולים לקחת קומפוננטת מונה ולהוציא אותה למקום אחר בפרויקט. היא תמיד צריכה להיות בתוך קומפוננטה שמעבירה לה את מספר הלחיצות, והקומפוננטה העוטפת חייבת לטפל באירוע לחיצה ולעדכן את הערך. הקומפוננטה שיצרנו היא "חלק מ" מבנה גדול יותר, ואינה יכולה לתפקד בצורה עצמאית. בגישה השנייה כל קומפוננטת מונה היא עצמאית. אפשר להעביר אותה למקום אחר בפרויקט והיא תמשיך לעבוד בתור מונה לחיצות. בנוסף לתפקיד הזה שלה, היא גם מדווחת על שינויים לקומפוננטה שעוטפת אותה כדי שאפשר יהיה לשנות לה את הצבע. הגישה השנייה היא לכן יותר מודולרית, היא מאפשרת לנו יותר חופש פעולה לשינויים עתידיים ותאפשר בעתיד יותר בקלות לפרק ולבנות מחדש את היחסים בין הקומפוננטות. כשאתם בונים קומפוננטות Vue נסו לחפש התנהגות בסיסית הגיונית ועצמאית לכל קומפוננטה, ולבנות את הקשר בין הקומפוננטות בתור שכבה נוספת שלא פוגעת בעצמאות כל אחת מהקומפוננטות הבודדות, כדי שיהיה לכם קל לשנות את הקוד בעתיד. עכשיו אתם 1. עדכנו את שני הפיתרונות כך שישתמשו ב v-for במקום לשכפל את יצירת המונה 4 פעמים. 2. שימו לב ששני הפיתרונות לא מתנהגים אותו דבר. כשיש מספר מונים עם אותו ערך מקסימלי בפיתרון השני הירוק לא משתנה אבל בפיתרון הראשון הצבע הירוק יינתן למונה העליון ביותר שמציג את הערך המקסימלי. עדכנו את הקוד של שני הפיתרונות כך שאם למספר מונים יש את אותו ערך מקסימלי אז אף מונה לא ייצבע בירוק.

דוגמת Vue: מספר מונים וצביעת הגדול ביותר בואו נכתוב תוכנית המציגה 4 מונים וצובעת את מונה הלחיצות שמראה את המספר הגדול ביותר בצבע שונה - וכן ננסה את זה ב Vue. פיתרון 1 - שמירת כל המידע בקומפוננטה העליונה לכתוב מונה לחיצות ב Vue זה קל ובעצם אנחנו מקבלים כזה בחינם כשיוצרים פרויקט חדש. אבל אם נשים 4 קומפוננטות כאלה על המסך לא תהיה לנו דרך לתקשר בין 4 הקומפוננטות. כל אחת תספור לחיצות בצורה עצמאית ולא תדע מה מספר הלחיצות בקומפוננטות האחרות, ולכן לא ברור איך היא תדע להשתמש בצבע רקע שונה אם מספר הלחיצות אצלה הוא הגדול ביותר. דרך אחת לחבר בין ארבעת הקומפוננטות היא ליצור קומפוננטה עוטפת ולהעביר את משתני ה ref של המונים לקומפוננטה העוטפת, בתור מערך. כל פעם שמשתמש לוחץ על כפתור באחת מקומפוננטות המונים אנחנו נעביר אירוע "נלחץ" לקומפוננטה העוטפת והיא כבר תעדכן את המספרים. הקומפוננטה העוטפת תוכל למצוא מה הערך הגדול ביותר ומי המונה עם הערך הגדול ביותר ולשמור את הערכים במשתני computed, וגם להעביר אותם פנימה לקומפוננטות המונים הפנימיות וכך קומפוננטת המונה עם הערך הגדול ביותר תוכל לצבוע את עצמה בירוק. הקוד לקומפוננטה העוטפת הוא בסך הכל:

<script setup lang="ts">
import {ref, computed} from 'vue';
import Counter from './Counter.vue';

const counts = ref([0, 0, 0, 0]);
const maxValue = computed(() => Math.max(...counts.value));
const maxIndex = computed(() => counts.value.findIndex(el => el === maxValue.value));

function onClick(counterIndex) {
  counts.value[counterIndex]++;
}
</script>

<template>
  <p>max value = {{ maxValue }}</p>
  <p>max index = {{ maxIndex }}</p>
  <Counter @click="onClick(0)" :isMax="maxIndex == 0" :count="counts[0]"/>
  <Counter @click="onClick(1)" :isMax="maxIndex == 1" :count="counts[1]"/>
  <Counter @click="onClick(2)" :isMax="maxIndex == 2" :count="counts[2]"/>
  <Counter @click="onClick(3)" :isMax="maxIndex == 3" :count="counts[3]"/>
</template>

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

<script setup lang="ts">
import { ref, computed } from 'vue'

const emit = defineEmits(['click']);
const {isMax, count} = defineProps<{isMax?: boolean, count: number}>();
const background = computed(() => isMax ? "green" : "yellow");

function onClick() {
  emit('click');
}
</script>

<template>
  <div>
    <p>Value = {{ count }}</p>
    <button @click="onClick">+1</button>
  </div>
</template>

<style scoped>
  div {
    background-color: v-bind(background);
    padding: 20px;
  }

  button {
    color: white;
  }

  p {
    color: black;
  }
</style>

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

emit('change', 10);

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

<Counter @change="(newValue) => doSomethingWith(newValue)" />

עכשיו שאנחנו יודעים את זה נוכל לכתוב את הקומפוננטה העוטפת ולקבל:

<script setup lang="ts">
import {ref} from 'vue';
import Counter from './Counter.vue';

const maxValue = ref<null|number>(null);
const maxIndex = ref<null|number>(null);

function onNewValue(counterIndex, value) {

ארבעה דברים שממש אהבתי ב Nuxt נוקסט היא גירסת ה Full Stack של Vue המאפשרת פיתוח יישומים מלאים עם Server Side Rendering. אני חייב להודות שכשהתחלתי לשחק עם הפריימוורק הייתי בטוח שאני הולך לפגוש עוד next.js ושמחתי למצוא מספר פיצ'רים ייחודיים שמיד עשו חשק ללמוד יותר. אלה הדברים שכבר ממבט ראשון על nuxt אהבתי במיוחד: 1. יבוא אוטומטי - כן אני יודע VS Code משלים פקודות import בלי מאמץ ובכל זאת אין קוד תמיד עדיף על קוד שנכתב מהר. קטע כזה עובד ב nuxt בלי שנצטרך להוסיף שום פקודת import:

<script setup lang="ts">
/* ref() and computed() are auto-imported */
const count = ref(1)
const double = computed(() => count.value * 2)
</script>

2. מערכת מודולים מובנית - לקח לי שתי לחיצות להוסיף את Tailwind לאפליקציית ה nuxt שבניתי דרך מנגנון המודולים שלהם. יש מודולים לחיבור לבסיסי נתונים, לחיבור לפורטלי תשלום, לניהול משתמשים, מוניטורינג של האפליקציה ועוד. 3. כלי הפיתוח המובנית שמציגים את זמן טעינת העמוד בכל עמוד במצב פיתוח. הרבה מאוד פעמים בכתיבת יישומים במיוחד בפריימוורקס שאנחנו לא הכי מכירים אנחנו עושים שטויות שיכבידו על זמני הטעינה של העמוד, וזה משהו שאנחנו עלולים לגלות רק מאוד מאוחר בזמן הפיתוח. הצגה של המידע הזה מול העיניים כבר מהרגע הראשון אומרת משהו על סדרי העדיפויות של המפתחים שבנו את התשתית וזה מעודד. 4. התיעוד של nuxt מאוד מושקע. הוא גם כולל מדריכים איך לעשות המון דברים בפריימוורק וגם מסביר על מבנה פרויקט, איזה תיקיות יש ומה צריך לשים בכל תיקייה. בהחלט אחד מעמודי התיעוד הטובים שראיתי. כן צריך להגיד ש nuxt הוא לא פריימוורק פשוט. יש הרבה יותר פונקציות, חיבורים ויכולות בהשוואה ל next.js. גם תבנית הפרויקט החדש היתה קצת דלה בדרך כלל תבניות כאלה כוללות הדגמה של יותר יכולות של הפריימוורק. אני בכל מקרה בינתיים לקוח מרוצה ובטח אבנה איתו כמה דוגמאות ואפרסם פה בעתיד.

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

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

לא שוב טייפסקריפט בואו נכתוב קומפוננטת Vue שיכולה להיות מופעלת בשני אופנים - או שאפשר להעביר לה כ Property מספר או שמעבירים לה שתי מחרוזות. אם מעבירים מספר אז המחרוזת הראשונה תהיה המספר שעבר והמחרוזת השנייה תהיה טקסט קבוע. ניסיון ראשון עשוי להיראות כך:

<script setup lang="ts">
const props = defineProps<
  | {number: number}
  | {text1: string, text2: string}>();

const text1 = "number" in props ? String(props.number) : props.text1;
const text2 = "number" in props ? "Great Number!" : props.text2;
</script>

<template>
  <p>{{ text1 }}</p>
  <p>{{ text2 }}</p>
</template>

והקריאה לקומפוננטה עשויה להיראות כך:

<Demo :number="5" />
<Demo text1="hello" text2="world" />

זה עבד מבחינת טייפסקריפט אבל הקוד עצמו נכשל. בהגדרת props עם defineProps ב Vue, אוביקט הפרופס תמיד מכיל את כל הפרופס האפשריים, כלומר בשתי ההפעלות הוא יקבל גם את number, גם את text1 וגם את text2, פשוט בהפעלה הראשונה number מקבל את הערך 5 והטקסטים יהיו undefined ובהפעלה השניה זה number שיהיה undefined והטקסטים מקבלים את הערכים הנכונים שלהם. רעיון אחד לצאת מהסיפור עשוי להיות לעדכן את הקוד שמושך את הטקסטים מ props ולתקן את הבדיקה. הבעיה שזה לא ממש עובד:

const text1 = props.number ? String(props.number) : props.text1;
const text2 = props.number ? "Great Number!" : props.text2;

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

const props = defineProps<
  | {number: number, text1?: never, text2?: never}
  | {number?: never, text1: string, text2: string}>();

const text1 = props.number ? String(props.number) : props.text1;
const text2 = props.number ? "Great Number!" : props.text2;

הקוד הזה עובד ובנוסף יש לנו בדיקת טייפסקריפט טובה. שתי השורות האלה תקינות:

<Demo :number="5" />
<Demo text1="hello" text2="world" />

ושלושת אלה מראות פס אדום על הקומפוננטה כדי שנזהה הפעלה לא נכונה:

<Demo :number="5" text1="hello" text2="world"  />
<Demo text1="hello"  />
<Demo  />

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