Як ви можете сказати, якщо поради старшого розробника погані? [зачинено]

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

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

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

Моє запитання: що я можу зробити, щоб краще оцінити, чи є порада старшого розробника хороша, погана чи, можливо, хороша, але застаріла в сьогоднішньому контексті? І якщо це погано / застаріло, яку тактику я можу використати, щоб не реалізувати його на своєму шляху, незважаючи на «тиск», зберігаючи той факт, що я поважаю його як старшого?

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

1. Молодший не має всієї інформації під рукою, щоб зрозуміти рішення, яке було прийнято. У деяких випадках невелике пояснення може допомогти розробнику перейти до минулого концерну та вирішити ситуацію, що склалася.
2. Молодший має інформацію про БАД. Не забувайте, що ви насправді молодший. Це еквівалент бути підлітком в програмному плані. Я впевнений, що у вас є багато чудових ідей, але можливо, що ви не все знаєте. Я вважаю, що найбільш стійкі молодші розробники - це ті, хто твердо вірить, що вони знають, що найкраще для коду, компанії, світу. Цим розробникам краще служити, набуваючи смирення.
3. Рішення зробити щось певним чином було прийняте над головою старшого. Старший все-таки працює на когось іншого, врешті-решт. Насправді може бути кращий спосіб зробити щось, більш ефективний спосіб написати щось, або краще програмне забезпечення / обладнання, яке допоможе виконати роботу. Хоча бізнес все ще керує рішеннями. Керівники бізнесу, директори, віце-спонсори тощо часто приймають рішення, які впливають на процес розвитку. Це поза контролем старших, і коли юніори скаржаться на це, все, що вони роблять, - це посилює стрес.
4. Старший, що просто вийшов, не встигає це врахувати. Існують терміни, і іноді зміна моделей, практик та поведінки в середині потоку дорого коштує до цього терміну. Оскільки це його шия на рубаючому блоці, часто важливіше зробити продукт функціональним і вчасно, ніж "ідеально написаним".

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

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

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

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

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

Незважаючи на це, висловлюйте свої занепокоєння, коли ви стикаєтеся з такою проблемою, як у вас вже є.

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

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

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

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

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

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

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

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

Повністю очікуючи скорочення / незгоди для надзвичайно упередженої точки зору.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Що мені робити в такій ситуації?

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

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

Ось кілька пропозицій.

1. Не сваріться зі своєю ситуацією - випробування вогнем, хоча і не весело, навчає вас критичним навичкам дослідження в подальшому у вашій кар’єрі.
2. Почніть наполягати на тому, щоб стати активнішим. Робіть це обережно і шанобливо . Продовжуйте наполягати і будьте наполегливі, поки він не поступається (це насправді працює для багатьох ситуацій у житті).
3. Якщо ваша ведуча не залучатиметься, подивіться, чи є інші, хто може вам допомогти. Якщо ви не працюєте в крамниці, яка займається лише годинами доїння, тоді ваша компанія не буде проти іншого розробника з більшим досвідом, який показує вам кілька мотузок і переглядає ваш код.
4. Почніть стежити за новою роботою. Я б не сказав, що ти перебуваєш у ситуації "треба піти", але це не завадить твоїй кар'єрі опинитися в місці, яке серйозно сприймає твій розвиток як програміста.

Якщо у вас є кращий спосіб вирішити ту чи іншу проблему, просто Зробіть це .

Нехай ваш код / ​​рішення стане вашим найкращим аргументом. Інакше дотримуйтесь того, що вам сказали.

Справа в точці

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

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

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

Тим часом прочитайте відповідь Джоела Етертона.

Я настійно пропоную не намагатися "не реалізувати це по-своєму".

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

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

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

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

Зрештою, не кожен старший розробник звертає увагу на нові способи ведення справ. Часом вони мають старі шкільні способи, які чудово підходили до мови, яку вони почали 20 років тому, але вважаються хакі, або "мають поганий запах" у сучасному світі.

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

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

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

Ніколи не бійтеся поганого огляду. Чи б ви довіряли сліпому чоловікові судження про колір?

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

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

Якщо роль старшого - наставник, він пояснить, чому його запитують.

Як сказали HLGEM та Jarrod, це справді є благом у маскуванні. Обидві їх відповіді чудові, і я хочу додати деякі моменти.

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

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

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

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

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

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

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

1. Запитайте іншого старшого розробника,
2. Робіть дослідження самостійно.

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

Було б чудово, якби я помилявся, бо я просто змінив свою поведінку, але не був.

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

Це можуть бути стандарти кодування або загальна архітектура, мова чи методологія. Але це завжди щось. Багато разів це просто констатувало очевидне: "Чи не слід все документувати краще для наших кінцевих користувачів?"

Моя рада тобі - не бути таким хлопцем .

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

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

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

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

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

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

(Трохи відредагований для дій.)

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

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

Кілька думок:

1 / Чи працює? Його спосіб працює чи ні? Чи є якась об'єктивна причина, чому його шлях був би неповноцінним?

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

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

2 / Зоряні програмісти кажуть ... Чому чорт? Ви знайдете відомих програмістів, які сильно розбігаються між собою з багатьох фундаментальних предметів, таких як планування, проектування, OOP проти процедурних, тестування одиниць, обробка винятків, контроль джерела, і далі, і далі.

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

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

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

Що мені робити в такій ситуації?

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

З точки зору отримання оглядів коду та отримання допомоги в архітектурних проектах, навіть коли я мав хороших менеджерів, я ніколи не мав великого огляду коду, що перевищує "статичні змінні повинні бути встановлені s_".

Скористайтеся можливістю вчитися та навчитися вчитися; це буде майстерність, яку ви зможете використовувати в майбутньому.

Якщо ви на секунду подумаєте, що керівництво не розуміє, наскільки ви РЕАЛЬНО готові виконати роботу, то ви, мабуть, помиляєтесь. Керівництво, напевно, також розуміє, що зараз ваш керівник був би абсолютно марним, якби він замінив вас і перейняв вашу роботу.

РЕАЛЬНІ причини, що вони вас не переселили, тому що, незважаючи на всі ваші виклики, які ви їм представляєте, ви все ще найкраща людина для роботи. Вони, очевидно, занадто цінують вашу роботу, щоб ризикувати передавати її комусь іншому.

Не варто недооцінювати інтелект управління ...

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

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

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

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

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

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

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

У минулі вихідні. Хлопець сперечався / не погоджувався зі мною щодо одиноких. Я сказав, що вони не є добрими, і НІКОЛИ не повинні використовуватися, і абсолютно немає причин їх використовувати. Я пов’язав його з http://www.gmannickg.com/?p=24 та більш глибокою статтею, на яку він посилаєтьсячерез кілька днів після аргументу. У день згадки іншого програміста (DudeB) він використовує одиночні кнопки лише тоді, коли це доречно (до якого я додав слово "ніколи"). DudeB нічого про це не сказав, але DudeB сказав, що DudeB був у проекті, який мав суперечки щодо пам’яті, оскільки всі потоки отримували доступ до синглтона. Після згадування про це, показуючи статтю та згадуючи суперечки про пам’ять, хлопець, з яким я посперечався, сказав, що нам доведеться погодитися не погодитися, з чим я погодився, тому що мені не подобається говорити про синглів (все ж я пишу цей d'oh)

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

Я маю зовсім іншу / суперечливу думку з цього приводу.

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

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

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

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

[Репост: тому що я якось створив другий рахунок тут]

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

Вам повинно бути зрозуміло, чи це пропозиції, чи накази / інструкції / директиви / що завгодно.

Пропозиція = Я думаю, що краще зробити це так; але це ваш вибір.

Замовлення / тощо. = Я хочу, щоб це було зроблено так; і це мій вибір.

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