Про жаргон та зірковість

#thinking

It’s Wednesday, dudes!
Цього тижня я натрапив на цікаву статтю від Gergely Orosz - “Is Critical Thinking the Most Important Skill for Software Engineers?”.
В ній автор розповідає про дві важливі речі: жаргонізми та довіру "зіркам".

Жаргонізми
Це - будь-які незрозумілі нам терміни - як бізнесові, так і технічні. Проблеми з ними у тому, що коли ми їх чуємо та не розуміємо - ми з якихось причин боїмося запитати. В більшості випадків - причина страху в тому, що усі подумають, що ви мало знаєте та й взагалі дуже сумнівний спеціаліст. А питати треба. По-перше - ви дізнаєтесь нове та розберетеся в незрозумілому. По-друге - дасте шанс людині пояснити ці терміни простими словами. Адже якщо ти не можеш пояснити термін, який застосовуєш - ти не до кінця розібрався в ньому.

Довіра “зіркам”
Коли ми починаємо кар’єру (та й надалі) ми стикаємося з лідерами думок: в Твіттері, телеграм каналах, на конференціях. Ці люди, зазвичай, дуже впевнено стверджують різні речі. А через їх досвід та “медійність” - ми схильні таким людям довіряти.
Але варто пам’ятати, що ці “зірки” можуть помилятися або грунтуватись на суто власному досвіді (а потім натягувати цей досвід на будь-які ситуації).

В обох випадках, треба критично ставитися до інформації. Розбиратися та перевіряти. Навіть, якщо це говорять люди з великим досвідом.

Для тих, хто хоче дізнатися більше - ласкаво прошу прочитати оригінал.

Про причинно-наслідкові помилки

#testing #curious #fallacies #thinking

Причинно-наслідкові помилки (causal fallacy) виникають, коли хтось бере дві окремі незв'язані між собою події та визначає, що одна подія викликає іншу.

Наприклад, ви помітили, що ваші UI автотести дуже повільні. Ви почали думати, у чому ж можуть бути причини цього.
Після читання розумних людей в чатах та на форумах, місцеві "експерти" одразу допомогли визначити проблему: Ваші автотести повільні, бо ви користуєтесь повільним Python, замість інших, більш швидких мов програмування.
Ви приймаєте цей висновок та йдете переписувати усі двадцять тисяч тестів знову - втретє за останні роки.

Але щоб такої помилки уникнути - треба лишень глибше досліджувати проблеми та докопуватись до суті проблеми (а причини може бути в недостатньо оптимізованому коді із купою sleep() або копіпасти)

Дуже легко прийняти "очевидну" відповідь та побудувати хибні причинно-наслідкові зв'язки. Особливо, коли дві події дійсно можна пов'язати між собою. Якщо ви хочете побачити більше подібних помилок у кореляції двох подій - зацініть ресурс Spurious Correlations.

Про помилку незворотніх витрат a.k.a Sunk-Cost Fallacy

#testing #curious #fallacies #thinking

Помилки можуть виникати усюди. Найчастіше ми маємо справу з помилками в софті або якихось хардварних частинах. (Або у ваших автотестах ...)
Але чи існують помилки у тому, як ми мислимо? Виявляється, що так. Це помилки у логіці мислення. Ми робимо такі помилки навіть не помічаючи цього. 

У цьому циклі дописів, я спробую коротко розповісти про такі помилки із прикладами з тестування та автоматизації. Декілька днів тому я вже розповідав про causal fallacy. 

Що таке sunk-cost fallacy?
Сьогодні настав час для наступної помилки - sunk-cost fallacy або помилки незворотніх витрат. 
Уявімо ситуацію. Хтось у минулому прийняв рішення. Через деякий час виявилося, що рішення було неправильним. Але оскільки на це рішення було витрачено вже багато часу, зусиль та грошей - людина (або команда чи компанія) продовжують працювати над цим хибним рішенням. Та ще й відмовляються його переглядати. 

Приклади:
- менеджмент вважав, що автоматизація - то "легко" та купив усім ліцензії на відому та рекламовану low-code / no-code тулзу. Через деякий час виявилося, що тести дуже важко підтримувати та вони швидко ламаються після кожної зміни на фронтенді. Але гроші на річну ліцензію вже були витрачені, тому тестувальникам треба працювати з цими інструментами "через силу"
- те ж саме стосується будь-яких нових інструментів чи підходів (BDD, shift-left and right, etc) Особливо, коли інструменти "спускають зверху". Рішення вже "прийняті" або "нічого не знаю, клієнт так хоче!" або "це модний фреймворк, на ньому усі круті інженери пишуть - це майбутнє!"

Як запобігти цій помилці?
- Приймайте зважені рішення з порівнянням наявних альтернатив
- Розробляйте proof of concept будь-яких нових інструментів
- Думайте не тільки про плюси, а й про час на підтримку, переписування, інтеграцію нового у інфраструктуру
- Постійно оцінюйте прийняті рішення та не бійтеся відмовлятися від хибних та неефективних (навіть якщо сил та грошей було витрачено багато)

Помилка більшості a.k.a. Bandwagon Fallacy

#testing #curious #fallacies #thinking

Продовжуємо розбиратись з помилками в логіці та як вони можуть впливати на роботу інженера.

Що таке bandwagon fallacy?
Суть цієї помилки полягає в тому, що ми приймаємо рішення базуючись тільки на факті, що так робить більшість людей в індустрії. При цьому, ми не думаємо, а чи підходить це рішення для нашої конкретної ситуації.

Приклади
- AI та ChatGPT зараз на хайпі - саме тому треба його не просто вивчати, але й пхати усюди де тільки можна!
- Багато хто застосовує low-code або no-code інструменти - тому й вам потрібно почати!
- Усі пишуть автотести (шифтують вліво чи право, вивчають JS чи якийсь конкретний фреймворк) - тому й вам потрібно вивчати та застосовувати саме ці мови та підходи!
- Усі навкруги пишуть пишуть чек-лісти замість тест кейсів, тому й вам потрібно робити те саме!
- Усі міряють тестове покриття та ставлять не нижче 75-80-90% - тому й у вас на проєкті потрібно впроваджувати таке!

Як запобігти такій помилці?
- Вчити нове та розбиратися з хайповими технологіями завжди цікаво та корисно.
- Але до усілякого нового інструментарію потрібно ставитись скептично та перевіряти чи підходить воно саме вам та саме у цей момент часу. Кожен проєкт може відрізнятись та бути на різному етапі свого розвитку.
- Те що той чи інший підхід використовують “усі” - може означати, лишень, що про цей підхід зараз “модно писати та говорити”.
- Збирайте більше інформації, знайте слабкі та сильні сторони поточних інструментів та процесів та обережно пробуйте нове.

Модель отримання навичок братів Дрейфус

#thinking #learning

Коли ми навчаємось чи навчаємо когось (як ментор чи на курсах), треба розуміти як люди взагалі отримують нові навички. Одна з моделей, яка може розповісти про це - це модель Стюарта та Губерта Дрейфусів. Згідно з цією моделлю, кожен студент проходить крізь пʼять різних етапів: новачок, просунутий початківець, компетентний спеціаліст, досвідчений спеціаліст та експерт.

Етап 1 - Новачок

У новачків немає або дуже мало досвіду. Новачки навіть не стільки вчаться, скільки хочуть виконати конкретну задачу в моменті часу. Новачкам потрібні рецепти (покрокові інструкції).
Проблема з рецептами в тому, що вони позбавлені контексту. То ж неможливо зробити "універсальні рецепти на усі випадки".

Етап 2 - Просунутий початківець

Просунуті початківці вже можуть потроху "ламати правила". Вони навіть можуть формулювати свої рецепти, але все ще не можуть досліджувати проблеми глибоко. Просунутим новачкам не цікаво знати проблему в масштабі. Але вони можуть користуватись порадами в нових контекстах, які схожі на ті, що вже траплялись. В початківцях ще не сформувалось цілісне розуміння (та й немає бажання його отримати).

Етап 3 - Компетентний спеціаліст

Компетентний спеціаліст може "дебажити" проблеми. Такі люди можуть взяти задачу, дослідити її та знайти рішення на основі їх досвіду. Компетентні люди можуть навіть займати лідерські позиції в команді.

Етап 4 - Досвідчений спеціаліст

Досвідченим спеціалістам потрібна цілісна "велика" картина. Вони прагнуть зрозуміти підходи на концептуальному рівні, то ж можуть страждати від занадто спрощеної інформації. Такі спеціалісти можуть аналізувати свої результати та робити висновки про зміни (покращення) в підходах. Вони також можуть вчитись на досвіді інших - зі статей, дослідницьких робіт, доповідей. Додатково - на цьому рівні люди можуть застосовувати "кращі практики" в залежності від конкретного контексту.

Етап 5 - Експерт

Експерти - то найперші джерела знань та інформації в команді, компанії, індустрії. Вони постійно у пошуку нових та кращих методів. Це саме ті люди, що пишуть книжки, виступають з лекціями. Експерти довіряють власній інтуїції. Експерти знають різницю між важливими та другорядними деталями

Гаразд, але що з того?

- Більшість людей знаходяться на рівні просунутий новачок
- Новачкам потрібні люди, які б їх направляли та давали зворотній звʼязок
- Продуктивність експертів падає, якщо підходи й правила єдині для всіх рівнів
- Користуйтесь правила та гайдами для новачків, залиште інтуїцію для експертів
- Експерти не завжди найкращі вчителі, бо вони мислять паттернами, які подекуди не можуть пояснити іншим
- Кожна наша окрема навичка рухається згідно моделі Дрейфусів. То ж можна "прокачувати" навички наче окремі гілки героя в RPG
- Не достатньо просто практикуватись 10000 годин. Треба розбивати практику на конкретні задачі потрібної складності, мати постійний зворотній звʼязок щоб виправляти помилки одразу
- Для швидкого прогресу потрібно оточувати себе більш експертними людьми в команді
- Ми вчимося краще коли спостерігаємо та імітуємо. То ж сесії парного тестування чи програмування можуть стати у нагоді