Тебя когда-нибудь спрашивали на собеседовании, сколько строк кода умеешь писать за день? Это звучит немного странно, но такой вопрос появляется чаще, чем хотелось бы. Многих начинающих специалистов волнует, а что, если я пишу слишком мало — меня уволят?
Вот что важно понять с самого начала: строки кода — это далеко не самый честный способ оценить, сколько ты работаешь. Один рабочий день ты можешь набросать тысячу строк, а в другой застрять над сложной задачей и не написать почти ничего, потому что всё время уходит на размышления и тесты.
Когда речь заходит о работе программистов, многие почему-то цепляются за количество строк — мол, чем больше написал, тем больше пользы принес. Особенно эта тема популярна среди руководителей, далеких от программирования. Им просто: написал 500 строк — молодец, написал 20 — лентяй.
Эта логика перекочевала из индустриальной эпохи, где количество деталей с конвейера действительно показывало производительность. Но код — не гайки на заводе. Один хороший программист может решить проблему за 10 строк, а другой будет мудрить на 100, но работать это будет так же или даже хуже.
В разных компаниях подход к подсчету строк всё ещё встречается, хотя уже давно признан устаревшим. Например, по исследованию исследовательской группы McConnell, примерно треть менеджеров в США до сих пор добавляют KPI по количеству строк кода в отчеты.
Посмотри сам — удобная табличка:
| Год | Процент менеджеров, использующих строки кода в отчетах |
|---|---|
| 2010 | 47% |
| 2018 | 38% |
| 2023 | 29% |
Всё дело в том, что строки кода — это простой и быстрый способ хоть как-то замерить работу разработчика. Особенно когда нет технических знаний. Но если присмотреться, видно, что такой подход немного устарел и часто играет против самой идеи хорошего кода.
В крупных IT-компаниях давно поняли — разработчику важнее не количество написанного кода, а его качество и понимание, решает ли он задачи бизнеса. Всё чаще оценивают не строки, а закрытые задачи, решённые баги или вклад в архитектуру проекта.
Многие представляют, что программисты пишут кучу строк кода каждый день. На деле всё намного скромнее — и на это есть конкретные причины. Фокусироваться только на количестве можно разве что на первом курсе вуза.
Есть исследование Standish Group, известное в IT-среде, где говорится: средний разработчик в больших проектах пишет около 10-20 строк рабочего кода в день. Для задачи высокого уровня это вообще норма, и иногда это могут быть даже меньшие числа.
"В среднем за год обычный разработчик создаёт 10 000 строк продуктивного кода, но большая часть рабочего времени уходит не на набор текста, а на чтение, тестирование и исправление ошибок." — из отчёта Standish Group CHAOS Report
Интересный момент: сотрудники Google и Facebook признаются, что средний темп написания кода — около 50-100 строк за неделю, если задача требует качества, тестов и ревью от коллег.
Вот табличка с реальными средними цифрами по разным сферам и компаниям:
| Компания/Область | Дней в неделю | Строк кода в день |
|---|---|---|
| Крупная IT-компания | 5 | 10–30 |
| Стартап на этапе MVP | 6 | 40–150 |
| Open Source проекты | 2-3 (волонтёры) | 5–20 |
| Веб-студия с "поточным" конвейером | 5 | 100–200 |
Самое главное: оценивать строки кода — это всё равно что мерить качество статьи количеством букв. Мало кода — не обязательно плохо. Большой объём бывает и при простых, рутинных задачах или при отсутствии тестов. Важнее качество и полезность, а не число.
Неожиданно для многих, на количество строк кода, которые программист пишет за день, влияет совсем не желание показать класс. Тут все куда практичнее и зависит от нескольких реальных факторов.
Во-первых, тип задачи. Фиксить баги — это часто работа щипцами и точечно: можешь весь день гонять один баг и написать всего пару строк (или даже просто убрать строчку). А если проект только начинается, то и «кодить» можно много — за день можно спокойно выдать сотни строк, особенно если идет первичная генерация шаблонов или автосгенерированный код.
Во-вторых, уровень и опыт. Джуниор частенько пишет больше кода, потому что только осваивается, еще не думает про оптимизацию. Сеньор же обычно пишет меньше, зато кода его более устойчивый, с глубоким смыслом и зачастую без лишней воды.
Третье — стек технологий. Программист на Python может писать меньше строк, чем тот же backend-разработчик на Java, но сама работа при этом будет не проще и не тяжелее. К примеру, фреймворки вроде Django или Laravel оборачивают большую часть логики в несколько строк, и строки кода тут вообще не показатель.
И наконец, не забывай о «невидимой» работе: думать над архитектурой, переписывать плохие решения, читать чужой код или писать документацию. Всё это никак не видно в числах, а времени отнимает не меньше, чем сама печать на клавиатуре.
На первый взгляд может показаться, что большие задачи — это всегда про горы кода, а маленькие — наоборот. Но на деле всё сложнее. Иногда одна простая на вид задача превращается в недельный квест, а массивная фича складывается из десятков мелких изменений, которые особо и не видно по строкам.
Многие компании уже не смотрят просто на строки кода. Один и тот же функционал можно написать полностью по-разному: опытный программист сделает это за 20 строк, а новичок — на 200. При этом оба создают рабочий код.
Вот простой пример. Кто-то исправляет баг: зашёл в один файл, поменял две строчки, система заработала. А кто-то пишет новый модуль с нуля — изменяет десятки файлов, но по сути реализации может быть не больше.
По опыту компаний типа Google или JetBrains, на задачи тратят разное число строк, и это очень плавает:
| Тип задачи | Среднее кол-во строк кода | Время на выполнение |
|---|---|---|
| Исправление бага | 5–30 | от 10 минут до нескольких часов |
| Добавление небольшой функции | 20–200 | пара часов — 1 день |
| Переделка архитектуры | от 500 до тысячи и больше | от 3 дней до недели |
Любой большой проект — это не только чистое написание кода. Время уходит на обсуждение решений, ревью, тесты. Вот почему нельзя честно сравнивать задачи только по количеству строк.
Сравните себя не с чужим количеством строк, а с прогрессом по задачам. В конечном счёте важнее, чтобы продукт работал, а не то, сколько кода вы накидали.
Если судить продуктивность только по количеству строк кода, можно серьезно ошибиться. Бывают дни, когда все идет гладко — ты пишешь много, но часто реально толковый код занимает очень мало места. Поэтому строчки — это скорее технический шум, а не результат.
В крупных IT-компаниях, по данным Stack Overflow, средний разработчик пишет от 10 до 80 строк кода в день, работающих потом в продакшене. Остальное время тратится на размышления, обсуждения, код-ревью и тесты. Например, в Google или Яндексе часто ценят даже не строчки кода, а то, насколько просто поддерживать и масштабировать твои решения.
| Компания | Средние строки кода в день на продакшн |
|---|---|
| ~30 | |
| Яндекс | ~50 |
| Типичный аутсорс | 60-80 |
Почему не стоит гнаться за количеством? Вот несколько минусов такого подхода:
Что реально работает? Оценивай, насколько твой код решает задачу пользователя, уменьшает количество ошибок и легко ли им пользоваться коллегам после тебя. Обсуждай подходы с тимлидом — вдвое чаще, чем подсчитываешь строчки. Чистые коммиты, хорошее покрытие тестами и вовремя найденные баги ценятся намного выше простого объема.
Погоня за тоннами кода — не цель, а часто ошибка. Вот что реально помогает программисту расти и не застревать на одном уровне:
Если хочется сравнить свой темп с другими, вот таблица со средними цифрами по индустрии для разных уровней — не для соревнования, а для ориентира:
| Опыт | Средние строки кода в день | Комментарии |
|---|---|---|
| Junior | 30-100 | Много обучения, ревью и исправлений |
| Middle | 50-200 | Рабочие задачи занимают больше времени, меньше вопросов |
| Senior | 30-150 | Упор на архитектуру, дизайн и ревью чужого кода |
И помни, что даже если ты написал одну строчку, которая избавила команду от головной боли — это уже отличный день.
