Обработка моего устаревшего коллеги

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

Дело в том, что мы работаем с командой, и его стиль работы полностью устарел. Он не верит в версию программного обеспечения (если вы просто убедитесь, что ваш код верен, вам не нужна вся эта чепуха). Не верит в развертывание (я могу предоставить работающий исполняемый файл. То, как его развернуть, нужно выяснить системным администраторам). Не верит в абстракцию. («Если вы хотите создать подпрограмму, продолжайте, но не вызывайте подпрограммы из этой подпрограммы. Это мешает, и код трудно следовать. Таким образом, каждый может следовать каждому шагу на своем пути». «или« да, конечно, вы можете использовать эту библиотеку, чтобы сделать это для вас, но таким образом вы не понимаете, что происходит ») и, конечно, не верит в ООП. (мы работаем в VB.net)

Он настолько хорош в том, что он делает, он может доставлять заявки намного быстрее, чем я. Но это просто не работает в команде. Другой член нашей команды молчит и не любит высказываться, хотя и склонен соглашаться. Наш менеджер думает, что я делаю правильные очки, но не программист.

Мне действительно тяжело поддерживать программы, которые он написал, и это не создает хорошую командную атмосферу. Как вы думаете, что лучше для меня сделать?

Это звучит как один из тех «Он хороший парень, но ...», где вы знаете, что правда придет. И правда звучит так, как будто он не так хорош для инженера. Хорошее программное обеспечение - это не только скорость работы и разработки. Это также касается других вещей, которые вы упомянули - ремонтопригодность, совместимость, абстракция (для дальнейшей эффективности) и т. Д.

Так что, как говорится, похоже, у вас есть разработчик проблемы в ваших руках. Что для вас хуже, так это то, что он доказал и, вероятно, настроен по-своему. Так что ты можешь сделать?

• Работай вокруг него.
• Стремитесь создавать свои проекты в столь же сжатые сроки, как и он.
• И если вы не можете получить лучший результат.
• Со временем те проверенные концепции, которые он отвергает, начнут окупаться за вас.

С другой стороны, если вы вынуждены работать своим путем, уходите.

Не пытайтесь изменить своего коллегу. Вы описываете его как человека, способного доставить работающее программное обеспечение. Возможно, уже слишком поздно интегрировать это в команду.

Итак, у вас есть два варианта:

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

• Удалить себя из team. У вас есть много точек, чтобы оправдать это. Может быть, вам следует оставить его в покое, поддерживать свои собственные приложения и посвятить себя новым вещам.

• Удалить себя из company. Иногда это единственное решение.

Если бы я был тобой, я бы прямо сейчас создал свою систему контроля версий. Начните использовать его для всего, что вы кодируете, и управляйте им, чтобы другие члены вашей команды имели учетные записи и могли получить к ним доступ. Ваши другие коллеги, вероятно, будут в восторге от его использования.

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

Вам не нужно быть воинственным или идти над ним, чтобы вовлечь его в более современные процессы. Иногда просто идти своим путем и быть лидером в действии более эффективно, чем пытаться убедить кого-то словами. Шаги малыша. Если он начинает лучше реагировать на управление версиями, начните рефакторинг подпрограмм и добавьте модульные тесты для защиты от изменений. Автоматизируйте тесты и покажите ему, как он может получить доступ к результатам, как только он сделает заезды.

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

Прежде всего, сделайте все как можно проще для него (Keep It Simple Stupid). Позвольте ему начать следовать этим практикам на своих собственных условиях. Но не позволяйте этому тянуть вас вниз.

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

Судя по тому, что вы сказали, если он производит ПО без ошибок, БЫСТРО, чем вы без использования многократно используемых библиотек и шаблонов проектирования, направленных на быструю разработку приложений, то это говорит о вас больше, чем о нем ...

... о нем ... да, найдите способ НЕ работать с ним и НЕ быть связанным с его работой. Похоже, у него типичное эгоистичное отношение к своей работе. Вы не можете работать с кем-то вроде этого, вы можете только наблюдать за его работой и убирать за ним (как вы в настоящее время).

Я видел это раньше ,

И я почти готов поспорить: этот тип парня появляется только «быстро», потому что у него в голове есть набор проверенных «шаблонов». 99% приложений Line of Business - это CRUD , базовые вещи.

Он, вероятно, использует тонну Copy & Paste из своего собственного кода (в этом нет ничего плохого).

Но..

В тот момент, когда он сталкивается с чем-то отдаленно сложным, оно падает, почему? потому что он больше не подходит ни к одному из основных «шаблонов».

Маленькая проблема ...

Я бы создал сторонний проект, сложный, который действительно выигрывает от ООП и повторного использования кода.

Затем покажите ему этот проект и попросите его реализовать функцию для функции.

Тогда я бы поспорил, что его код почти наверняка будет в 10 раз больше и в 10 раз страшнее, если он реализует его по-своему.

Посмотрите на это с деловой стороны.

Вы тратите больше времени на создание ошибочного кода. Вы приносите меньше дохода, поэтому вы сосете.

Если со временем вы можете изменить это, тогда вы можете полностью изменить это.

Но, может быть, просто может быть, этот устаревший программист может действительно научить вас нескольким вещам о быстром создании кода, который не содержит ошибок? Может быть, его методы не так стары, как вы думаете?

Я подозреваю, что кто-то может создать такой замечательный код без каких-либо очень хороших практик. Возможно, вы сможете изучить эти практики и применить их к «лучшим практикам» и модным вещам, которые вы понимаете.

Если ваш менеджер не программист, попробуйте сформулировать его так, чтобы он понял.

• Мы должны использовать sourecontrol, потому что если мы этого не сделаем, у нас могут возникнуть большие проблемы с восстановлением

• Он берет меня х количество времени , больше , потому что он отказывается следовать некоторым довольно основным процессам.

С другой стороны, убедитесь, что вы не слишком увлечены совершенством, то есть это лучшая практика, которой мы должны следовать. Вероятно, вашему коллеге есть что добавить, возможно, вам просто придется медленно подталкивать его в правильном направлении.

Похоже, вы, коллега, никогда не развивались в команде. Такой тип соло-гуру не позволяет хорошей групповой динамике. Поэтому расскажите об этом своему начальнику и постарайтесь обсудить все «за» и «против» с вашим партнером, который это делает. Если вы могли бы сделать это лучше, но если он отказывается, поднимитесь в каинскую команду

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

Я бы поговорил с другими, чтобы получить более широкую картину того, как все выглядит там, где вы находитесь. Возможно, там есть некоторые разделения, так что его код не должен слишком сильно смешиваться с другими, так как есть возможность выделить его в его собственную область одним способом, которым это можно было бы обработать, хотя это больше для высшего, как директор или ИТ-директор, чтобы сделать, а не разработчик.

Возможно, вы захотите поговорить с ним, чтобы увидеть, какие большие системы он построил, поскольку есть некоторые крупные корпоративные системы, которые, как правило, представляют собой множество строительных блоков, в которых спагетти-код может попасть в страну «О, вот почему ООП может быть хорошо! хотя иногда это случается, когда оказывается весьма полезным увидеть, как это может быть полезно иметь в своем наборе инструментов.

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

Испытайте его (в хорошем смысле), чтобы доказать вам обратное, покажите ему классную сторону инструментов и практик. Не покровительствуйте.

Например, возможно, он не верит в управление версиями в качестве помощи, но показывает ему, как ветвление / слияние и как он может работать с несколькими экспериментальными функциями, не нуждаясь в большом количестве файлов.

Что касается ООП, покажите ему несколько классных / сложных шаблонов проектирования, таких как шаблон команд, шаблон задач и как он может сэкономить ему драгоценное время и всю вашу команду.

Если вас не интересует ни малейшее ... он может быть проигранным делом, но опять же, у вас есть инструменты для вашей команды и вы, чтобы превзойти его. Попробуйте использовать программное обеспечение для репозитория, которое показывает / отправляет сообщения о фиксации электронной почты, которые может видеть ваш менеджер, что обеспечит прозрачность для вашего менеджера и оставит вашего коллегу за кадром (у bitbucket.org есть бесплатные частные репозитории с неограниченным пространством, если вы используете mercurial).

В конце концов, не пытайтесь убедить словами, но неопровержимыми действиями, это лучший способ справиться с упрямыми людьми ИМХО (обратная психология тоже иногда работает, смеется).

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

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

Вы должны попросить своего руководителя сделать презентацию для ВСЕХ о том, почему «версия» программного обеспечения хороша. Не выделяйте своего коллегу.

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

Мои коллеги ПОСТОЯННО сливаются, постоянно наступая друг другу на ноги. Но хорошая дружеская лекция о ее преимуществах была бы хорошей вещью и стимулировала бы дискуссии.