Вкратце: соучредитель компании хочет заняться «настоящей работой», но приносит больше вреда, чем пользы.
Компания находится в Великобритании, занимается разработкой программного обеспечения, имеет около 20 сотрудников, стабильно зарабатывает, хорошо платит и предлагает отличные условия труда (дружелюбная атмосфера, льготы и т. д.).
Они наняли меня 3 месяца назад, чтобы начать новый, амбициозный и долгосрочный проект. На данный момент в проекте задействовано 3 человека: еще один специалист и один старший менеджер (соучредитель компании). Ролей менеджеров нет – мы все делаем «настоящую работу» и все равны (например, решения принимаются голосованием).
Проблема в том, что соучредитель не является опытным программистом. Возможно, он был когда-то, но, вероятно, потерял популярность за годы, когда не работал разработчиком программного обеспечения. Он с радостью обсуждает маловажные вещи (например, стиль кодирования), но когда дело доходит до кодирования, он совершает ужасные ошибки. Я устал перепроверять каждую часть его работы.
Я не могу пожаловаться на него как на человека (например, он не проявляет признаков грубости, ревности и т. д.), ему просто не хватает навыков. Вот почему я обычно тайно исправляю его ошибки во время слияний, но я подозреваю, что это не правильное решение в долгосрочной перспективе.
Учитывая, что я явно НЕ в том положении, чтобы советовать ему, что мне делать дальше? Должен ли я поговорить с ним? Или лучше отпустить и ждать катастрофы? Если это имеет значение, то речь идет об узкоспециализированной области разработки программного обеспечения, а парень, о котором идет речь, старше меня примерно на 10 лет. Он также является выпускником CS.
РЕДАКТИРОВАТЬ: отвечая на вопросы в комментариях: работаем в нише, достаточно сложная технология. Упомянутые ошибки — это простые ошибки, такие как использование неинициализированных переменных.
Хорошо то, что маловажные вещи обычно можно автоматизировать, особенно стиль кодирования. Посмотрите, сколько из этого может быть обработано вашей системой сборки. Внедрение монитора качества кода (например, Sonarqube или подобного) принесет огромные дивиденды в будущем, особенно в таком молодом проекте, как ваш.
Продемонстрируйте, что код неисправен. Исправляя вещи в тайне, вы
Вы не в том положении, чтобы давать ему советы, но можете указать на проблему и направить дискуссию в нужное русло.
Для таких мелочей, как неинициализированные переменные, монитор качества кода или статический анализатор будут чрезвычайно полезны. После того, как вы это сделаете, нужно просто согласовать уровень качества кода, который вы хотите для проекта.
Для более крупных проблем я бы создал модульный тест или тикет для каждой найденной ошибки. Как только у меня будет их куча, я укажу на растущую кучу и спрошу, как мы собираемся их решать. Сейчас самое время представить Scrum, если вы его поклонник.
В зависимости от динамики отношений вы все еще можете делать большую часть исправлений самостоятельно, но он будет знать о проблеме, и вы сможете оценить временные затраты, если вам когда-нибудь понадобится.
Наконец, если честно, он звучит как парень, который может воспринимать критику, так что я бы тоже это исследовал. Внедрите запросы на вытягивание и рецензирование в свой рабочий процесс и посмотрите, как все пойдет.
Не все думают, что им нужны мониторы качества кода. Если вы не можете продать его напрямую, вам, возможно, придется потратить некоторое время, чтобы настроить его, а затем указать, насколько это было огромным подспорьем, и предложить принять его. Опять же, ваш пробег будет варьироваться в зависимости от вашего босса; по моему опыту, демонстрировать всегда лучше, чем продавать (но я ужасный продавец).
красный щит
Эрик
АакашМ
Нейромант
Солнечная вспышка