Насколько чистым должен быть код на моем github

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

Я чувствую, что вы считаете профиль Github слишком важным в процессе найма здесь. В этом нет ничего прискорбного или необычного — 99% кода, который вы пишете в профессиональной среде, вероятно, будет именно таким. Это здорово — это означает, что вы можете перечислить коммерческий опыт, который вы получили, работая над этими внутренними проектами.

Поэтому я подумал, давайте сделаем страницу на github, чтобы показать мою работу. Но перед этим я посмотрел советы в Интернете. И это меня смущает, если честно.

Как правило, в наши дни есть два типа людей, которые имеют профили на Github: те, кто активно участвует в проектах с открытым исходным кодом, и те, кто просто создает его, чтобы загрузить дамп кода, который они написали ранее. Я бы сказал, что первый сценарий определенно лучше , но и во втором нет ничего плохого, если:

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

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

Так:

Стоит ли все же выкладывать на гитхаб примеры моих работ, даже если они не "идеальны"?

Абсолютно. (Кроме того, «код производственного уровня» определенно не означает идеальный!)

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

У вас есть мастер и опыт. Оба должны быть документами (Uni-Abschluß, Arbeits-/Praktikumszeugnisse), которые вы можете предъявить. Веское доказательство того, что вы прошли обследование и признаны годными к службе. Вам не нужно представлять что-то меньшее, чем это.

Только представьте, какими странными были бы собеседования, если бы работодатели не доверяли сертификатам и рекомендациям:

Сэр, мы в Garbage Inc очень гордимся тем, что нанимаем только лучших водителей мусоровозов. Мы видим, что у вас есть действующая лицензия, сертификат на переработку опасных материалов и яркая рекомендация от нашего главного конкурента... но, сэр, мы заметили, что вы не публикуете никаких личных видео, на которых вы выносите мусор. Нам нравится нанимать людей на основе их потока на YouTube о вывозе мусора.

Да... нет.

Иди с тем, что у тебя есть. Это здорово и должно быть много. Если кто-то не ценит мастера над страницей на гитхабе, вы не хотите там работать.

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

Вы должны смотреть на это как на рекламу для себя. Так что будьте очень критичны к тому, что вы там публикуете. Лучше иметь 2-3 сложные задачи с данными и их решения, чем 100 коротких примеров.

В реальных решениях есть такие вещи, как модульное тестирование и комментарии. У них есть документы с требованиями. Если вы хотите показать, что вы лучше, чем ваши конкуренты, вы должны показать это, сделав свои примеры Git hub как можно лучше. Если я нанимаю двух человек с примерно одинаковым опытом, и один показывает git-хаб со 100 крошечными проектами, большинство из которых кажутся примерами классов, и все они выглядят как быстрый и грязный код, а один показывает три сложных проекта и презентация профессиональна, включая тесты, комментарии, регистрацию ошибок и т. д., какой из них произведет на меня большее впечатление как на нанимающего чиновника?

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

Меня больше всего беспокоит это заявление:

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

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

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

Через десять лет у вас будет 10 лет проектов, которые можно показать, но только если вы не начнете. Не публикуйте одноразовый код с нулевой редакцией, но и не зацикливайтесь на вопросе: «Должен ли я свернуть этот цикл?» или «идеальны ли эти имена полей документа?». Git также очень удобен для разработки кода, а не только для того, чтобы хорошо выглядеть, так что не стесняйтесь.

Я собираюсь повторить то, что я сказал во многих ответах. Найм — это процесс продажи. У вас, как у соискателя, есть что-то, что вы пытаетесь продать (себя: или, по крайней мере, вашу способность выполнять работу).

Этого можно добиться с помощью инструментов продаж: резюме, заявления о приеме на работу, сопроводительного письма, рекомендаций и (возможно) портфолио работ — т. е. учетной записи на github. При оценке того, как вы используете эти инструменты, вы должны сосредоточиться на том факте, что они являются инструментами для облегчения процесса продаж.

Чтобы перейти к вашему конкретному вопросу:

Стоит ли все же выкладывать на гитхаб примеры моих работ, даже если они не "идеальны"?

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

Я думаю, вы дали некоторые намеки на ответы, когда сказали:

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

Ваше портфолио на github демонстрирует быстрое и грязное решение проблем и свободное владение некоторыми языками. Хотя это и положительные моменты, которыми можно похвастаться, есть потенциальный пробел: как менеджер по найму, ответственный за разработку программного обеспечения, что более важно, чем эти характеристики, я ищу людей, которые пишут устойчивый код. Разработчики, которые думают о долгосрочной перспективе и понимают , почему такие вещи, как модульные тесты, являются хорошей идеей, а не только люди, которые делают модульные тесты, потому что им сказали, или люди, которые не делают их вообще. Другими словами, меня так же интересуют процесс и подход (т.е. вы провели модульные тесты и соответствующие комментарии), как и конечный результат (вы получили правильный ответ на быстрое задание хакатона).Ясно, что есть и другие менеджеры по найму в разных типах организаций, которые могут иметь несколько иную точку зрения на этот вопрос. Из вашего вопроса неясно, какую именно работу вы собираетесь выполнять. Если вы ищете должность, в большей степени ориентированную на науку о данных, или позицию, в которой программное обеспечение является второстепенным по отношению к конечному результату, ваша способность писать код, решающий проблемы, может оказаться более важной, чем ваша способность следовать строгим процессам разработки программного обеспечения.

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

В итоге:

• Используйте свои инструменты продаж (резюме, портфолио и т. д.), чтобы точно определить, что ищет менеджер по найму.
• В разработке программного обеспечения процесс так же важен, как и конечный результат. Для более формальной позиции, ориентированной на разработку программного обеспечения, показ ТОЛЬКО того, что вы можете решать быстрые и грязные проблемы, может сделать вас рискованным по сравнению с кандидатами, которые могут продемонстрировать всестороннее понимание процессов разработки. Для позиции, более ориентированной на науку о данных, где разработка/сопровождение кода может быть немного менее важным, чем буквальное получение ответа, это может не применяться.
• Подумайте о конкретном типе должности, на которую вы претендуете, и о том, что вы хотите показать о себе, а затем, если есть пробелы, вам нужно устранить пробелы - независимо от того, включаете ли вы свою учетную запись github в свое приложение или нет. .