Поводження з моїм застарілим колегою

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

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

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

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

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

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

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

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

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

Отже, у вас є два варіанти:

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

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

• Видаліть себе з company. Іноді це єдине рішення.

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

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

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

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

Перш за все, зробіть для нього все максимально простим (Keep It Simple Stupid). Дозвольте йому почати слідувати цій практиці на власних умовах. Але не дозволяйте це тягнути вас вниз.

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

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

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

Я бачив це раніше ,

І я майже готовий зробити ставку: такий тип хлопця виявляється лише "швидким", тому що у нього є набір випробуваних "моделей" у голові. 99% додатків Line Business - це базові матеріали CRUD .

Він, ймовірно, використовує тонну Copy & Paste з власного наявного коду (нічого поганого в цьому немає).

Але ..

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

Маленький виклик ...

Я б створив проект зі сторони, складний, який дійсно виграє від OOP та повторного використання коду.

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

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

Подивіться на це з боку бізнесу.

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

Якщо з часом ви можете це змінити, ви можете змінити це.

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

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

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

• Ми повинні використовувати sourecontrol, тому що якщо ми цього не зробимо, ми можемо мати великі проблеми з відновленням

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

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

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

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

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

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

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

Киньте виклик йому (хорошим способом) довести вам інше, покажіть йому круту сторону інструментів та практик. Не опікуйтесь.

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

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

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

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

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

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

Ви повинні попросити свого керівника зробити презентацію для ВСЕГО про те, чому "версійне" програмне забезпечення добре. Не виділяйте своїх колег.

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

Мої колеги НЕБЕЗПЕЧНО зливаються, постійно наступаючи на пальці ніг. Але хороша доброзичлива лекція про її користь була б приємною справою та викликала б дискусії.