Пет-проект в одиночку или в команде: что даёт больше

Что даёт одиночная работа

Полный контроль. Никого не надо ждать и ни с кем не надо согласовывать. Для первого проекта это важно: вы разбираетесь во всём сами и понимаете, как устроена вещь целиком.

Широту. Приходится делать и хранение данных, и интерфейс, и развёртывание. В команде эти части обычно разбирают разные люди.

Понятный темп. Никто не тормозит и никто не подгоняет.

Чего одиночная работа не даёт

Опыта работы с людьми. А именно его проверяют на собеседовании отдельно, потому что работа — это в первую очередь другие люди: их код, их мнения, их сроки.

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

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

Внешней дисциплины. Бросить проект, о котором никто не знает, не стоит ничего.

Что даёт команда

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

Больше шансов дойти до конца. Проект, за который отвечаете не только вы, бросить труднее — не из-за давления, а из простой неловкости.

Другой разговор на собеседовании. К вопросу «что ты делал» добавляется «как вы это делали вместе». Второй вопрос интереснее нанимающим, и ответ на него куда труднее выдумать.

Чем команда неудобна

Она медленнее. Согласование, ожидание, споры о подходах, разные темпы у участников. Первый командный проект почти всегда идёт дольше, чем сделанный в одиночку такой же.

И бывает больно: ваш код будут разбирать, и не всегда мягко.

Что выбрать

Разумный порядок такой:

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

Второй — с кем-то. Даже вдвоём. Здесь вы добираете ровно то, чего нет в первом.

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

Одна деталь про командные проекты

У них есть слабое место: со стороны непонятно, что делали именно вы. «Участвовал в разработке» звучит одинаково и у того, кто вёл базу, и у того, кто поправил три строчки.

Поэтому фиксируйте вклад. Хорошо, когда это описывает не сам участник, а тот, с кем он работал, — и когда рядом видно историю изменений, которую можно открыть и проверить. Тогда командный проект перестаёт быть словами и становится доказательством.