Повторне набуття довіри старшого програміста [закрито]

Мій начальник дізнався, що я не такий розумний, як він думав.

Приклад з мого досвіду:

Я молодший програміст, і працюю в команді з двох, мій начальник (старший програміст) і сам.

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

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

Отже, враховуючи цей приклад, моє запитання:

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

EDIT : Дякую всім за чудові відповіді та підтримуючі відгуки!

Якщо йому сподобався продукт, який ви створили, але він застряг у використанні Backbone, вам обом потрібно поговорити про потрібний технологічний стек.

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

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

tl; dr. Ти добре зробив. Поговоріть зі своїм старшим і подивіться, що він очікує від вас.

Він не здається мені "старшим", щоб зробити такий виклик швидкого рішення. Я завжди схильний використовувати належну рамку замість анти-шаблону "Винаходити квадратне колесо". Якби він був по-справжньому старшим, він би зрозумів і знав цінність хороших рамок. У кращому випадку я б очікував, що він поставить під сумнів вибір Backbone.js щодо іншого фреймворку JavaScript MVC та набагато раніше. Він не зумів належним чином наставляти і перевіряти вас як молодшого і допомогти вам на правильному шляху розвитку (на його думку).

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

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

Щоб відповісти на ваше запитання про те, що я хотів би бачити як старший:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тільки тому, що старший програміст не робить його непогрішним.

Ваші подальші коментарі, які сказали, що начальник засмучений, він повинен навчитися чомусь новому ....

Якщо є щось інше, про що ви не згадали, я буду дратуватися в HIM.

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

Але, керівництву, варто турбуватися про інші речі. У них є терміни дотримання, у них обмежений чи відсутні бюджети на навчання.

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

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

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

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

Як професійний розробник ви не припиняєте вчитися. Колись. Якщо ви це зробите, ви збираєтеся застоюватися. І це може бути добре в деяких районах. У банківській справі працює багато застарілих систем, які потребують підтримання, тому знання старих систем, які рухаються дуже повільно, чудово. Мій друг редагував COBOL в банку, щоб виявити, що вихідний код, який він фіксував, не торкався близько 30 років (а оригінальним автором був наш викладач COBOL в університеті) ... Тим не менш, він все ще повинен вивчити нові речі, оскільки старі системи мають бути інтегровані в нові системи.

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

Я завжди навчаюсь. Хоча я дуже хотів би, щоб мій роботодавець щороку забирав мій рахунок на освіту, рідко вони витрачають щось наближене до того, що я відчуваю, що мені насправді потрібно, але я знаю, що я повинен залишатися працевлаштованим, тому витрачаю десь в районі 2000 фунтів стерлінгів. GBP (приблизно $ 3000 USD) на мою власну освіту щороку.

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

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

Ваш старший розробник повинен навчитися чомусь. Їм потрібно навчитися не використовувати емоційні слова (як-от «неслухняність»), щоб приховати власні недоліки, адже це виб'є впевненість у інших. Їм потрібно вивчити нові рамки (навіть якщо вони не можуть навчитися цілій справі, дізнатися, що це робить, і як вона вирішує проблему, і якщо їм це буде потрібно в майбутньому, вони можуть вкласти час у навчання глибше). І їм потрібно дізнатися, що вони знаходяться на роботі, де їм доведеться постійно вчитися.