Як виправити молодшого, але спонукати його думати про себе? [зачинено]

Я є керівництвом невеликої команди, де кожен має менше року досвіду розробки програмного забезпечення. Я б ні в якому разі не називав себе гуру програмного забезпечення, але я засвоїв кілька речей за кілька років, що писав програмне забезпечення.

Коли ми робимо огляди коду, я дуже навчаю і виправляю помилки. Я скажу такі речі, як "Це надмірно складно і суперечливо, і ось чому" або "Що ви думаєте про переведення цього методу в окремий клас?" Я дуже обережно повідомляю, що якщо у них є запитання чи незгодні думки, це нормально, і нам потрібно обговорити. Кожного разу, коли я когось виправляю, я запитую "Що ви думаєте?" чи щось подібне.

Однак вони рідко якщо ніколи не згодні або запитують чому. І останнім часом я помічаю більш кричущі ознаки того, що вони сліпо погоджуються з моїми заявами та не формують власну думку.

Мені потрібна команда, яка може навчитися робити справи правильно самостійно, а не просто виконувати вказівки. Як виправити молодшого розробника, але все-таки спонукати його думати про себе?

Редагувати: Ось приклад одного з цих очевидних ознак того, що вони не формують власну думку:

Мені: мені подобається ваша ідея створення методу розширення, але мені не подобається, як ви передали велику складну лямбда як параметр. Лямбда змушує інших занадто багато знати про реалізацію методу.

Молодший (після нерозуміння мене): Так, я повністю згоден. Тут ми не повинні використовувати методи розширення, оскільки вони змушують інших розробників знати занадто багато про реалізацію.

Було непорозуміння, і цим було вирішено питання. Але в його заяві не було навіть ОУНЦЕ логіки! Він думав, що він відрегулює мою логіку назад, думаючи, що це має сенс, коли насправді він не має поняття, чому він це говорить.

Коротка відповідь:

Залучайте їх (покладіть головоломку на думку), наділіть їх правомочністю (довіряйте їхні відповіді).

Це питання, яке нас рухає! - Матриця.

Взагалі, за моїми спостереженнями, у юніорів є свій світ - власне обмежене уявлення про те, як вони думають, а в якійсь частині і власний ентузіазм / фаворити / думки щодо речей.

Немає нічого поганого в тому, щоб сказати їм головою, що ви неправі, але найкраще, щоб ви змусили їх думати. Чому? Чи є інші способи? Чи є кращі способи зробити те саме? Один із анекдотів, якими я завжди користуюся, - "Дайте мені три рішення (на цю проблему)!"

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

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

Однак вони рідко якщо ніколи не згодні або запитують чому. І останнім часом я помічаю більш кричущі ознаки того, що вони сліпо погоджуються з моїми заявами та не формують власну думку.

Як правило , це є результатом , що ви робите прийняти їх пропозиції , але потім скасовують їх , і вони однаково переконали про ваших поглядах; тільки тому, що ти старший, вони уникають бійки!

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

Не тільки в програмному забезпеченні, але і в кінцевому підсумку лише найбільш уповноважені товариші по команді наважуться відповісти, а не ставити під сумнів систему.

Якщо ви хочете, щоб ваші юніори думали про себе, не виправляйте їх: змусьте їх виправити себе .

Замість того, щоб говорити їм, що ви вважаєте неправильним у їх вирішенні, задайте їм відповідні запитання щодо цього. У вашому прикладі ви можете запитати їх про те, що потрібно знати людині, яка використовує метод розширення, щоб створити лямбда. Продовжуйте задавати такі питання, поки вони не підкажуть, що це проблема. Таким чином, ви знаєте, що вони зрозуміли, чому їх рішення може бути проблемою, і, крім того, більше шансів навчитися на цьому - якщо ви просто скажете їм, що їх рішення неправильне, це зовнішнє судження, і їх легко ігнорувати. Якщо вони прийдуть до усвідомлення самостійно (з невеликим спонуканням), вони зрозуміють, наскільки це обґрунтовано, і будуть набагато частіше вчитися на своїй помилці.

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

Оскільки у вас є декілька молодших розробників, вони переглядають код як групу, а не 1 один.

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

Потім проведіть круглий стіл щодо відносних переваг та недоліків різних реалізацій з наміром направити молодших розробників на вибір найкращої реалізації, не розповідаючи, що це таке.

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

Коли я вперше почав працювати в роботі з програмування, я зробив саме те, що ви описали: коли говорив про щось, що я міг би робити, я завжди погоджувався Це було головним чином тому, що я не мав достатнього досвіду, щоб сказати інакше.

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

Хороший спосіб полегшити індивідуальне мислення - дозволити їх зазирнути на веб-сайти з програмуванням, як Stack Overflow або Programmers SE. Я знаю, що вони допомогли мені дізнатися про різні методи, які були там, і дозволили мені вести дискусії зі старшими членами команди, а не сліпо погоджуватися з ними.

Справа в тому, що без досвіду пропозиції старших членів завжди будуть звучати правильно.

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

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

Звичайно, ти не завжди можеш бути прямодушним щодо того, щоб попросити їх повторити сказане, тому потрібно скорегувати свою стратегію. Наприклад, ось як я б переосмислив вашу подальшу заяву з ОП як "пробне" питання:

Мені подобається ваша ідея створення методу розширення, але мені не подобається, як ви передавали велику складну лямбда як параметр. Чи бачите ви, як ця складна лямбда змушує інших знати занадто багато певних речей щодо впровадження методу?

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

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

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

Коли мені довелося зіткнутися з цим, я сказав (чесно) такі речі, як:

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

Цього зазвичай було достатньо, щоб вказувати людей у ​​новому напрямку.

Відповідальність - це одне, що може їм допомогти.

Я в минулому керував командою чи двома, і одна з речей, яка змусила юніорів блищати, - це тягар особистої відповідальності. Коли хтось усвідомлює, що його дії можуть вплинути на нього в один момент, він / вона, як правило, бере на себе більше, ніж робить. Не кажучи вже про те, що коли вони відчувають свою роботу, хороші результати набагато задовольняють.

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

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

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

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

наприклад "Мені подобається ваша ідея створення методу розширення, але мені не подобається, як ви передали великий комплекс лямбда як параметр. Лямбда змушує інших занадто багато знати про реалізацію методу. Чи можете ви придумати кращий спосіб реалізувати цей метод розширення, який не розкриває стільки інформації? "

Це дозволяє їм бачити недоліки в тому, що вони розвиваються, одночасно надаючи їм можливість вирішити проблему, яку вони ввели в додаток.