10% программистов ничего не делают на рабочем месте

В прошлом году вышло исследование, которое показало, что примерно 9,5% разработчиков программного обеспечения ничего не делают на рабочем месте. Их назвали «инженеры-призраки» («ghost engineers»). Вирусным стал пост в X, который ссылается на статью «Predicting Expert Evaluations in Software Code Reviews».

Давайте поговорим об этом.

Команда Стэнфордского университета, которая занимается изучением продуктивности разработчиков собрала данные по более чем 50 тысячам разработчиков из сотен компаний и выяснила, что 9,5% из них ничего не делают на рабочем месте и, возможно, коварно работают на нескольких работах, используя время компании.
Чтобы это выяснить, исследователи взяли код из репозиториев на GitHub и прогнали по нему некий алгоритм. Получилось, что в офисах «призраков» всего 6%, а на удаленке – 14%. Среди тех, кто работает частично в офисе и частично удаленно, «призраков» 9%, и медиана как раз составила 9,5%.
Около 58% разработчиков вносит существенные изменения и отправляет код в репозиторий только три раза в месяц, а еще 42% вносят незначительные изменения: редактируют одну строчку или символ.
Получают при этом разработчики немаленькие деньги, так что компаниям нужно их немедленно уволить и сократить таким образом свои издержки.

Статья, на которую ссылается пост, не совсем про производительность разработчиков – она про создание инструмента, с помощью которого можно сократить время на ручную проверку кода. Этот инструмент не должен полностью заменить ручную проверку, но должен помочь разработчикам сфокусироваться на решении действительно сложных проблем.
Проверка кода включает в себя поиск ошибок, оценку производительности и соответствия кода стандартам, принятым в компании или в рамках конкретного проекта. Это критически важная часть разработки: без нее, во-первых, ничего не заработает, во-вторых, будет сложно понять, почему не заработало. Проводят проверку более опытные разработчики, которые могли бы затраченное время вложить в создание чего-то нового. Не отрицая важности проверки, авторы стремятся избавить проверяющих от рутинной работы и поскорее отпустить решать другие задачи.
Для этого была создана модель автоматической проверки некоторых аспектов кода (той части, которая не требует непременной человеческой оценки). В качестве набора данных взяли 70 изменений*, внесенных в код 18 авторами. Десять экспертов попросили ответить на семь вопросов относительно каждого изменения. Вопросы приведены в разделе 3.5 статьи:

В качестве модели использован случайный лес (про него я писала пост в телеграме, там можно узнать подробности).
Ответы экспертов использовали как «правильные ответы» для обучения, и код оценивался по следующим параметрам:

Я не буду вдаваться в технические подробности, только приведу пример, чтобы вы понимали, о чем речь. Для оценки структуры кода исследовали изменения, вносимые в классы, методы и интерфейсы. Класс описывает один объект, у которого есть свой набор методов и интерфейс для взаимодействия с другими объектами. Например, есть объект «кошка». У него есть методы «лежать на столе», «скинуть объект со стола», «ночной тыгыдык» и так далее. У объекта «стакан», например, тоже будут свои методы, и кошка будет взаимодействовать со стаканом определенным образом – через интерфейс (чтобы применить к нему метод «скинуть со стола»).
В идеале классы, методы и интерфейсы должны быть стабильны и не должны переписываться каждый раз, когда вводится новый объект или метод. Изменения в структуре класса влияют на то, насколько код будет стабилен и насколько удобно будет поддерживать его в рабочем состоянии. Если изменений много, что-то, возможно, идет не так: появились новые требования или код изначально был написан не совсем аккуратно и требует постоянной доработки.
Все метрики авторы расписали в статье, вы можете обратиться к главе 2 за подробностями.

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

Во-первых, неправильно оценивать продуктивность работы программиста по числу написанных строк кода. Одной строке могут предшествовать часы исследований, экспериментов, выявления и исправления ошибок. То, что загружается на GitHub – окончательная версия, отлаженная и проверенная. За ней стоит длинный черновик с разными вариантами решения одной задачи.
Во-вторых, разработчик-новичок может потратить больше времени на написание небольшого куска кода просто потому, что ему нужно изучить инструмент и полазить по форумам в поисках ответов на вопросы. Это не значит, что он потратил время впустую – он повысил свою квалификацию, что полезно и для него, и для компании. Если уволить всех неопытных программистов за то, что они медленно работают, откуда потом брать опытных, которые работают быстрее?
Разработчики с большим опытом, кстати, обычно пишут мало кода. Они занимаются обучением, проверкой кода коллег, решают организационные задачи. Чем выше должность, тем больше совещаний и меньше изменений на GitHub.
Есть еще часть работы, которая критически важна, но не приводит к появлению новых строчек кода: разработка архитектуры приложения, исправление ошибок, отбор и тестирование новых инструментов.

Коме того, есть проблема в самом дизайне исследования: для обучения случайного леса отобрали всего 70 изменений у 18 разработчиков. Авторы статьи постарались сделать выборку представительной: собрали 1,73 млн. изменений и посчитали средний размер такого изменения. Отобранные 70 соответствуют среднему размеру. Однако размер – не показатель качества или значимости, так что критерий отбора вызывает сомнения. И 70 объектов – слишком маленькая выборка, она в любом случае окажется искаженной, если не по размеру, то по другим параметрам (в том числе по качеству кода, например).

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

Автору поста, конечно, прилетело по голове от сообщества разработчиков. Оно ожидаемо: выводы были сделаны поспешно. Сначала стоило бы дождаться комментариев по дизайну исследования, исправить ошибки, а потом расширять выводы на большую выборку.
Разумеется, всегда есть некоторое количество людей, которые и правда ничего не делают и просиживают на работе штаны. Возможно, даже с оценкой их доли авторы не так уж и промахнулись. Но мы тут за ответственный подход к исследованиям и трезвую оценку громких заявлений.
В целом, пожелаем авторам удачи. Если они решат усовершенствовать свой подход и выпустить новую статью, я про это обязательно расскажу у себя в телеграме.
*Взяли 70 коммитов (commit) – это внесенное изменение с кратким описанием того, что было изменено.