Pull to refresh

Comments 757

Это фиаско, братан.
А вообще в любой либе бывают баги. И если они фиксятся с твоего пулреквеста, то это ачивка. Но если ты суровый Энтерпрайз, то...

Вот только нужна ли кому эта ачивка? Сидеть, ковыряться за бесплатно в чужом коде, тратить на это кучу своего времени чтобы банально перед кем-то козырнуть? Это бессмысленно. Бессмысленнее только плодить свои велосипеды, что потом кому-то что-то доказывать на собеседованиях.
А какой тогда смысл во всем этом? Какой смысл учить программирование? Ведь во время учебы вы «тратите на это кучу своего времени чтобы банально перед кем-то козырнуть». И совсем не факт, что вас возьмут на работу после этого, а козырнуть вы сможете только показав Hello World своему другу. И я более того скажу, далеко не у всех есть достаточно знаний, чтобы «Сидеть, ковыряться за бесплатно в чужом коде».
Смысл в том, чтобы заработать достаточно денег, на которые в свободное время заниматься тем что нравится. И для того что бы человек хорошо делал свою работу, абсолютно не обязательно чтобы он делал ее и в свое свободное время тоже.
Но увлечённость программированием коррелирует с тем, что вы им занимаетесь и в свободное время.

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

А вообще речь не только про IDE. Думаю, если я работодателю скажу, что в свободное время почитаю Пирса-Шеня-Голдблатта, это тоже будет плюсиком мне в моей сфере деятельности.
Так речь как раз о том, что если конкретно вам хочется «в выходные глядеть в IDE», а другим этого делать не хочется, потому что есть другие увлечения, то и корреляции как таковой нет между наличием у вас кода, выложенного на условный гитхаб и вашим уровнем как специалиста.
Почему? У меня больше практики и больше возможностей познакомиться с новыми инструментами, подходами, и так далее.

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

Но вот у меня, так же как и у автора статьи, есть другие хобби и увлечения, не очень связанные с разработкой. И вот в субботу мне приходится делать тяжелый выбор между маунтин-байк покатушкой, тренировкой по скалолазанию, фото-вылазке в осенние леса, подготовкой фото и написанием текста в блог — или IDE. А еще же надо книжку почитать. И уделить внимание семье. И друзьям и социализации. Плюс при наличии детей время, доступное для хобби, уменьшается примерно в два-три раза. Ну вот и что мне выбрать?

Возможно, вы лучший и более увлеченный программист чем я, потому что в выходные вы можете посвятить себя хобби программирования. Я ничуть не иронизирую, это прекрасно! Я даже немножко завидую :-)
Да, в сутках всего 24 часа, увы.

Мне в своё время приходилось выбирать между всякой социализацией-гитаркой, скажем, и обучением в вузе, самообразованием и подработкой (есть-то хочется). Отказаться пришлось от первого, а с тех пор уже как-то по накатанной пошло :)
Это индивидуально. Я не могу отказаться от социализации и активного образа жизни. Пробовал, но через год начинаю чахнуть и впадать в черную меланхолию. Путешествия и горы в университете сыграли свою роль, я тогда умел делать это почти бесплатно, а теперь прекратить путешествовать и ходить-лазить-ездить по наклонным и вертикальным поверхностям практически невозможно. Да и нужно ли, если это приносит счастье в конце концов?
Да не. У всех своя функция приятности их состояния, повезло быстро найти её примерный максимум — и хорошо же.
И я более того скажу, далеко не у всех есть достаточно знаний, чтобы «Сидеть, ковыряться за бесплатно в чужом коде»

В нынешнее время почти любой человек может взять и начать коммитить.
К примеру можете взять даже меня. Сразу скажу, я — не программист. Это даже не побочная мне сфера деятельности (всякие скриптики для облегчения жизни — не в счет). Так вот, у меня есть немного ПРов на Гитхабе в проекты, которые не то что мне близки или я в них разбирался бы… Я даже ЯПа, на котором они написаны — не знаю.
банально перед кем-то козырнуть

вы в исправлении бага в чужом проекте только это видите?

В чужом — да. Не вижу смысла делать что-то бесплатно.
Ненавидишь — не делай. Но другим то чего указывать?
UFO just landed and posted this here

Это инвестиция в свою ценность перед работодателем. Но это многоходовочка, которая не каждому...

И слава богу, тем легче тем, кто инвестирует в себя.

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

Вот тут дико плюсую. Из недавнего, что было со мной — для личного проекта надо было на одной платке с ARM-процессором звук завести, благо кодек предусмотрен железом. Собрал билдрутом образ, но звук ни в какую не работает. Начал копать, в итоге выяснил, что драйвер есть, а в device tree нет ноды с ac97. Дописал, звук завёлся. Погуглил про процесс пуллреквестов в ядро линукса, через пару месяцев — мой код официально в ядре. В итоге, и свою задачу решил и самому дико приятно, что после меня хоть что-то да останется))
Как-то странно: увидеть ошибку и не исправить. Давно вы программируете и на чём?
Простая ситуация: вы использовали стороннюю библиотеку в проекте, над которым работаете. Она отлично решает вашу проблему, однако выясняется, что в ней есть баг. fork -> fix -> pull request -> profit. И ачивка вам, и проект сделан и некоторого рода благодарность автору библиотеки.
… а автор библиотеки отказывается принимать его говоря что тесты оформлены неправильно :-)

Ну да, ваше желание кому-то помочь ещё не означает, что вы должны делать это в стиле тяп-ляп. Помогите действительно нормально всё что надо было сделать — это в общем-то и не смертельно, и опять же показатель вашей ответственности и усердия. А спотыкаться на такой глупости, что ты 2-3 строки кода оформил не по их дизайну и тебе лень их поправить — что делается за несколько секунд — говорит о том, что вы просто ищете повод для оправдания своей лени. Для меня это например уже сигнал для того чтобы задуматься, если ли смысл с вами работать, к примеру?

Почему сразу — лень-то?
Потому что ты неудобный.
Не оформил по стандартам — переделай.
Лень переделать… Лень читать стандарты… и так сойдет?
Вот нафиг ты мне такой нужен?
Дешевле и эффективнее взять того кто в чужой монастырь приходит соблюдая устав.
Пока ты не способен играючи, не тратя лишнего времени оформлять правильно пулреквесты — ты нуб, и цена тебе как любому юниору.
И дело даже не в том что ты их не делаешь.
Дело в том, что ты не понимаешь почему их надо делать «правильно» а не как бог на душу положил.
Значит ты еще зеленый.
Если ты не делал коммитов в чужие репы, не запускал собственных пет-проектов, то… у тебя банально очень мало опыта. Не в часах, а в кейсах. В командной работе и т.п.
Не в обиду. В контексте командной работы мне самому опыта не хватает. Просто показатель уровня. Объективно.
Это вы точно мне пишите?
В каждом проекте свои монастыри. Пока устав каждого изучишь....)
В серьёзных проектах изучение устава ограничивается просмотром .editorconfig или в крайнем случае CODESTYLE.md, а соблюдение его же — в выполнении перед коммитом какого-нибудь make lint или npm test в зависимости от.
А вы используете библиотечки из несерьезных проектов?)
И контрибьютите в них? И сталкивались с тем, что ваши реквесты заворачивали по кодстайлу? Можно ссылки на эти PR посмотреть? Чисто ради любопытства.
Там не кодстайл, уж стиль-то я бы поправил. Там есть хитрая система построения документации, которая требует чтобы каждый тест демонстрировал очередную фичу. А у меня была не фича, у меня было исправление бага.

Я неделю думал как выдать за фичу исправление бага — но так не придумал.

Вот он: github.com/hazzik/DelegateDecompiler/pull/53
Ой всё! Меня не поняли, своими кодстайлами замучали, дурацкая автодокументация, и вообще больше не буду коммитить в чужие репы…
— Я правильно понял мысль?
А вы рисковый, не боитесь что такой проект накроется разбитым корытом?

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


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

> Если ты не делал коммитов в чужие репы, не запускал собственных пет-проектов, то…

Ты нормальный, разносторонне развитый человек, а не стереотип из картинки:
i.work.ua/fun/1354.jpg
Странная логика. Почему при этих же условиях я не могу быть, например, имбецилом?
Так, еще раз, другими словами. А то видно не очень понимают люди.
Я работодатель. Ну или HR, или нач.отдела куда берут человека и участвующий в собеседовании. Не суть.
Мне нужно взять человека на вакансию тыжпрограммиста.
Здесь есть три варианта:
1) я беру стажера/юниора/эникейщика, который будет выполнять простую работу, и возможно расти в моей среде (возможно нет). В таком случае вполне достаточно стандартных вопросов на знание, и нестандартных заданий на смекалку и проверку некоторых психологических характеристик. Если у человека есть гитхаб с пет-репами, и/или коммитами в чужие репы, то это будет плюсом, но в целом я и так все вижу по нему за первые две минуты общения.
2) я беру зрелого разработчика способного вести участок который ему выделят и соблюдать корпоративные стандарты или даже легаси-стандарты конкретного проекта. В целом это «рабочая лошадка» бизнеса. Человек который выполняет объем работы. От него требуется определенный уровень квалификации, определенный уровень деловых качеств, и определенная степень… стандартности. Нет, ну правда. Если каждый мидл будет подстраивать под себя корпоративную среду, то нафига такой мидл нужен? Я лучше завезу побольше печенек, чем буду иметь проблемы с проектом когда он уйдет. Ничего личного, просто бизнес. Юниор либо неработопригоден, либо впитывает культуру и прочий контекст вместе с знаниями. А вот мидл… Мидл может быть прожженым индивидуалистом. Может писать самостоятельно большие и сложные вещи, но после него их будет проще переделать с нуля. И как мне это узнать? Задать пару простых заданий? Ну задал. Ну вроде понимает, вроде пишет. Вроде читает. Но как он будет вести себя с чем-то покрупнее чем хелловорд и прочие пузырьковые сортировки? Вариантов собственно не так много — посмотреть что он умеет в его гитхабе. Дать тестовое задание домой, на пару дней (не оплачиваемое, ага) и взять на стажировку и платить ему зарплату, и приглядываться к нему… Ну или есть четвертый вариант — «мы с вами свяжемся, если вдруг двадцать других претендентов тоже будут без гитхаба».
3) нанимаем звезду/сеньора. Тут у меня меньше возможностей сказать «следующий». И скорее всего я пойду на более дорогой вариант с стажировкой или еще чем-то подобным. Может более долгие многораундные собеседования и т.п.

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

Ещё раз процитирую:


Areso: у меня в опен-сорс выложены игры, программы-кликеры, калькуляторы, и энное количество утилиток. Их я делал или «по фану», или по личной (своей) необходимости.

Вас такое как работодателя привлечёт?

> Итого — если у тебя нет гитхаба и пет-проектов, то ты обходишься мне дороже.

С этим никто не спорит, естественно, человек с хорошим аккаунтом на гитхабе, обойдется дешевле, т.к. ему можно платить меньшую зарплату за тот же уровень квалификации. Работодатель ведет себя, безусловно, правильно — так, как ему выгодно. Неправильно ведет себя в данном случае работник, который терпит подобное отношение к себе со стороны работодателя.
То есть, еще раз: то, что работодатели просят показать гитхаб, это все хорошо, т.к. это просто способ сэкономить на зарплате при прочих равных. На черта нужен начальник, который не захочет в таких условиях сэкономить? Он дурачок что ли?
Неправильно то, что сами программисты это поддерживают — то есть, фактически, занижают свою ценность как специалистов (вместо того, чтобы наоборот повышать).
«Дороже» выходит «покупка» такого специалиста, а не оплата его труда. О чем я написал прямым текстом, причем прямо следующей фразой, после той которую вы процитировали:
Итого — если у тебя нет гитхаба и пет-проектов, то ты обходишься мне дороже. Значит ты должен меня чем-то привлечь чтобы компенсировать эти лишние расходы. Например я буду платить тебе меньше зарплату. Или у тебя очень крутые рекомендации или опыт работы (кода твоего я не видел, но знаю что ты работал ведущим разработчиком в серьезном проекте). Или ты готов писать большое тестовое задание бесплатно, или месяц стажироваться без зарплаты или ты сын моей любовницы, или что-то еще.

И вот эта вот неспособность услышать оппонента она очень сильно показывает вашу низкую квалификацию. Сегодня вы не слышите меня на хабре, придумывая понимание моих слов под свое видение, завтра вы не услышите коллегу, послезавтра будете доказывать клиенту что он верблюд. Проверенно. лично вы в принципе неработопригодный человек. И это не вопрос гитхаба или еще чего-то. Т.е. Майоров с которого начался этот тред — выйдет дороже другого специалиста, лично мне не подойдет поскольку у нас слишком разные взгляды на многие принципиальные вещи (не только тут, а вообще так сложилось по факту общения), но другому работодателю вполне может быть идеальным. А вот вы — неработопригодный. И мне жалко ваших работодателей (хотя возможно они этого заслужили).
И да, отвечая на вопрос уважаемого Idot — пет-проекты про рыбок и кликеры мне дадут много информации в вашу пользу. Способность понять задачу (даже если это своя собственная задача), знание технологий (даже если речь про банальные SOLID/DRY/MVC поскольку все остальное у вас в работе другое) и т.п.
А слова «ну это было давно» или «я пока еще не добрался до того чтобы придать этому божеский вид» вполне себе покажут что это не лучшее на что вы способны.
Впрочем отсутствие не скажет что вы непригодны, но усложнит возможность разглядеть ваши достоинства. Так зачем же усложнять работодателю увидеть ваши плюсы?
> О чем я написал прямым текстом, причем прямо следующей фразой, после той которую вы процитировали:

Я это видел. Вы написали неверно. Конкурентное преимущество человека с богатым гитхабом в первую очередь именно в том, что ему можно меньше платить.

> И вот эта вот неспособность услышать оппонента она очень сильно показывает вашу низкую квалификацию.

Я вас прекрасно услышал, а вот вы сделали поспешный вывод из неполных данных.

> Так зачем же усложнять работодателю увидеть ваши плюсы?

«Плюс», заключающийся в готовности работать за более низкую плату — является плюсом для работодателя, но никак не для работника. Работнику, определенно, следует демонстрировать те плюсы, что повысят возможную зп, а не наоборот. Человек, который хвалится своей увлеченностью, и тем, что работает за бесплатно — объективно снижает ценность своего труда.
У работодателя нету задачи поставить вам ту зарплату, которой вы объективно стоите, у него задача поставить вам такую зарплату, за которую вы готовы эффективно работать. И если вы готовы работать за меньше, чем стоите — то работодатель, безусловно, будет очень доволен.
Я это видел. Вы написали неверно. Конкурентное преимущество человека с богатым гитхабом в первую очередь именно в том, что ему можно меньше платить.

Я то ли нить потерял, то ли не понял. В общем, откуда это следует-то, что ему платить можно меньше?
Человек считает, что специалист, который бесплатно контрибутит в опен-сорс, снижает цену часа своей работы таким образом.
Не знаю, как это должно выглядеть… Ну, предположим, 8 часов за Х денег и 4 часа опен-сорса за 0 денег. Таким образом, человеку можно платить (Х+0)/12. Druu у вас такая арифметика?)
> В общем, откуда это следует-то, что ему платить можно меньше?

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

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

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

Здесь мы возвращаемся к интерпретации. Если человек просит вас показать код, именно чтобы посмотреть код (оценить его качество) — его вполне устроит ваш гит с графическими проектами (равно как какой-нибудь очередной туду-лист или ваше старое тестовое задание), это все вполне нормально, тут на самом деле нету требования к наличию стороннего проекта — тут есть требование к демонстрации кода.

Если же он спрашивает с целью сесть на шею — то будет просить код именно по близкой к рабочей тематике.

Мы обсуждаем именно второй вариант, Х из поста выше — это то, чем вы будете заниматься на работе.
Или наоборот. Я настолько увлечён X, что за рутину, легаси и прочее подобное счастье вместо свободного полёта мне нужно очень сильно доплачивать.
Нет, он не потребует меньше. Он потребует столько же, но часть времени будет заниматься своим пет проектом и обойдется дороже ;)
Почему дороже? Смотря какую «часть» времени он будет им заниматься. «Правило 20%» Корпорация Добра уже отменила, но это сугубо их внутренние расклады, а так — если ты успеваешь по основному проекту, то 20% времени на собственные проекты — компании очень выгодны.
1) Ты все равно будешь отвлекаться. Разработка того что нужно, а не того что хочется — утомляет.
2) Вместо того чтобы в это время сидеть на кухне и поедать халявные печеньки ты развиваешься, а значит будешь писать лучше и быстрее.
3) Когда аврал чаще всего можно избежать овертаймов, просто отложив пет-проекты на время дедлайна и получив +20% к эффективности. А ведь овертайм не просто лишние расходы на его оплату, но и значительное падение производительности труда (как в овертайм, так и после выхода из дедлайна).
Из минусов тут только сложность в организации рабочего процесса так, чтобы не было проблем с переключением внимания и т.п.
Конкурентное преимущество человека с богатым гитхабом в первую очередь именно в том, что ему можно меньше платить.
Это что еще за демагогия в стиле «белое — это черное, война — это мир»?
Это соцэкономика. Рассчёт исходя из себестоимости и всё такое…

Кому-то стоит вспомнить про то, как работает капитализм. Если вы требуете от разработчика чего-то дополнительно (неважно чего — кода на гитхабе или умения вышивать крестиком в арктическом походе), то пул возможных кандидатов снижается и цена рабочего времени растёт…

Другое дело, что «вышивать крестиком в арктическом походе» в список требований для кандидатов не включается обычно, а «показать список проектов на гитхабе» — включается, как видим…
То есть, вы пришли к выводу, противоположному Druu?

Больше требований (+github) → меньше пул подходящих кандидатов → выше з.п. (разумеется, у тех, кто умеет в github).
> Если вы требуете от разработчика чего-то дополнительно (неважно чего — кода на гитхабе или умения вышивать крестиком в арктическом походе), то пул возможных кандидатов снижается и цена рабочего времени растёт…

Если я требую от работника работать за зп ниже рыночной, то пул возможных кандидатов снижается и… цена растет?
Не кажется вам, что тут есть противоречие, и ваш тезис надо как-то переформулировать, чтобы он не был столь универсален?
Да нет, все нормально. Когда ваше предложение найдет ровно 0 откликов, вы сами повысите цену вашего предложения) Закон спроса и предложения (и пересечения этих кривых) никто не отменял. Или сделка не состоится, вы не наймете программиста.
> Да нет, все нормально.

Выполнение требования о низкой цене приводит к повышению цены? Это же явное противоречие, чего тут нормального? В вашей модели данное требование просто невыполнимо.
TL;DR. Давайте рассмотрим пример. У вас есть 1 вакансия, программистов по вашему профилю — скажем, 3000 человек, чьи резюме размещены на hh.ru. Вы ставите зп 200 000 рублей и они все (условно) готовы работать за них. Нам ведь не нужны все? Вы ставите 100 000 рублей, осталось 1500 программистов. Вы ставите 50 000 рублей, осталось 200 программистов. Вы ставите, наконец, 30 000 рублей, осталось 5 человек. Молодежь! С профилями на гитхабе! Вы рассуждаете, что уж им-то можно платить еще меньше (ибо нефиг!) и понижаете сумму до 20 000 рублей (или потому, что их много, или потому, что у них профили на гитхабе — как вам угодно. Но скорее профили, так эпичнее). И все, даже этих теперь не видно. Вы поднимаете предложение до, скажем, 25 тысяч и под него попадает 1 человек с гитхабом. Ну не было бы гитхаба, вы бы может ему 30-ку дали, а так — ну только 25. Правда, перед этим вы пытались найти кого-нибудь за 20, и желательно с гитхабом, но не получилось чВ

Подводя итог: цена вашего предложения начнет расти, когда пул кандидатов на текущую цену с вашими требованиями станет равным 0. Т.е. когда не найдется ни 1 человека, устраивающего вас и согласного работать за предложенные вами деньги.
Я хочу видеть его глаза когда он будет этого одного потом увольнять. Не важно почему. Ведь выбирал то он его исключительно по «цене». Ведь чем ниже «цена» тем дешевле… вроде бы. А дешевых было не много, и выбирать было не из чего.
Я не знаю в чем будет причина увольнения этого одного, но я точно знаю что набор сотрудников у такого «нанимателя» начнется не с того что Вы описали а с увольнения того самого «одного». Даже если с ним будет «всё так», то он просто уйдет сам, повысив свой уровень или еще чего, не суть.
Ваше исходное утверждение неверно, сужение пула потенциальных кандидатов не ведет к росту зп _само по себе_. К росту зп приводит отсечение из пула тех, кто готов работать за минимум.

То есть, было в пуле 100 кандидатов, мы добавили условие «кандидат имеет опыт работы с технологией Х», в пуле осталось 90 кандидатов, т.к. отсеялись 10 студентов, которые не имеют соответствующего опыта работы. Причем эти студенты как раз претендовали на минимальную зп => необходимая зп возросла, мы уже не можем нанять дешевых студентов, их не осталось в пуле.

Другой случай — в пуле было 100 человек, добавляем условие «кандидат должен быть студентом». В итоге в пуле останется 10 тех самых студентов (то есть в 9 раз меньше человек, чем в прошлом случае!) но зп не вырастет, т.к. остались ровно те люди, которые претендуют на ту самую минимальную зп в пуле.

Таким образом, если добавление к списку требований требования «наличие сторонних проектов на гитхабе» не отсеивает людей, претендующих на минимальную зарплату из пула без этого требования, то это добавление не ведет к росту зп.
Ладно ноль. Это еще отличный вариант. При нуле даже Druu поймет что что-то не так и будет менять требования.
А вот когда придут полторы калеки, и из них придется выбирать… (Нет, изменить требования когда полторы калеки есть — не получится.) Чтобы понять необходимость этого нужен немалый опыт, ведь полторы калеки есть, максимум еще немного покрутим объявление… плюс как правило наем работника процесс коллегиальный: партнеры, начальство, HR, нач.отдела где работник будет работать, тимлид — много кто еще. И если с нулем пришедших всем более-менее понятно что надо что-то делать, то когда пришли, но недостаточно — понятно не всем.
Я вас прекрасно услышал, а вот вы сделали поспешный вывод из неполных данных.

Я всегда принимаю решения на основе неполных данных.
Такой уж я человек.
Собирать полные данные обычно слишком дорого.
Вот вы например сколько лет потратили на собеседования сотен соискателей чтобы выяснить что те кто контрибьютят в опенсорс имеют меньшие зарплатные ожидания? Наверное лет пять потратили да? </сарказм
Вы несете полнейшую чушь, причем вам КАЖЕТСЯ что вы несете ее с серьезным лицом, и не расплескиваете.
Человек СЛИШКОМ увлеченный натащит тебе стек технологий которые самые модные, а значит сырые. А если не натащит, то ему будет не интересно и он будет плохо работать или убежит. Ну а притащив этот сырой стек он все равно убежит. Туда где можно будет еще интереснее работать. За неделю до дедлайна да. Зато такому человеку да, можно будет платить чуть меньше.
А тот кто увлечен, но не маньяк, тот у кого есть чуть в репе, или даже нет, но на вопрос честно ответит «оно у меня на битбакете закрытое ибо мне стыдно выкатывать сырое» — тот дешевле работать не будет. Просто в силу того что с интересными технологиями он может поработать и вечером, когда будет писать очередной пулреквест в очередной новый и супер-модный движок. А на работе нужно деньги зарабатывать, чтобы оплачивать квартиру и удобный диван. И ради этого можно и не очень модный стек технологий потерпеть.

А вот человек который никогда ничего не писал для фана, не контрибьютил в чужие репы… если мы говорим о мидле, то будет слишком ограничен в своих способностях. Будет плохо понимать архитектурные моменты, ему нужно будет подробнее разжевывать, ведь он никогда не писал сам, только допиливал чужое или работал в команде. Он не знает (на своей шкуре, а не в теории) о том почему нужно принимать те или иные решения. Не имеет интуитивного опыта того где технический долг уместен, а где нет, где стоит закладывать гибкость на будущее (еще не известно какое), а где наверняка будет только один сценарий и можно спокойно все хардкодить… Все это приобретается с опытом, и только с самостоятельным опытом. А самостоятельно вести ентерпрапрайз-проект человеку без опыта не дадут. Ну а своих он не ведет. Если случайно он окажется толковым (ну мало ли, просто у человека не хватает времени саморазвиваться, а не просто жлоб), то постепенно сможет этот опыт частично перенять. Задавать вопросы тимлиду/техдиру — красиво, мол объясни, научи почему, сидеть в обед медитировать над тем почему именно так написана спецификация, писать пулреквесты в ядро написанное «старшими товарищами» и т.п… Но скорее всего будет как всегда — справляться с работой будет хреново и в перерывах между авралами будет искать другую работу. Где больше платят и меньше требуют. Ведь коллеги не более квалифицированные и более опытные — они просто идиоты которые себя не ценят…

И да, меня очень забавляет как люди без опыта собеседования людей — пишут сотни комментариев о том как правильно нужно принимать людей на работу. По моему мнению хоть немного понимать что такое собеседование с точки зрения работодателя и рассуждать об этом может человек имеющий за плечами минимум пять… увольнений. Ну рассуждать то может любой, но вот категорические выводы, утверждения навязывать — тут без опыта никуда.
Если б у меня было за плечами пять увольнений, то у меня было бы и еще 1 самоубийство — у меня в отделе было всего трое людей, не считая собаки. И в отличие от меня, никто из них не был «попрыгунчиком», которому не сидится больше двух лет на одном месте). Когда у нас открылась вакансия, это был квест длиною в год найти человека на эту вакансию…
Ну опыт можно получить и иначе. Но тут такое — вам не приходилось увольнять (как и нанимать) кучу народу, но вы и не рассказываете несусветные истории про мотивацию нанимающей стороны как это делает оппонирующий нам троль.
Вы были с другой стороны, пусть даже может быть ваш голос был лишь совещательным, но вы там были, и вы возможно и не бог рекрутинга, но уж чушь то нести не будете.

Оффтоп: в воскресенье были на одном семинаре в одной организации где работала моя жена. Раньше подобные семинары организовывала она. Сейчас она была в роли посетителя, и по ее словам это совершенно другой опыт, и воспринимается оно все совсем иначе.
> А тот кто увлечен, но не маньяк, тот у кого есть чуть в репе, или даже нет, но на вопрос честно ответит «оно у меня на битбакете закрытое ибо мне стыдно выкатывать сырое» — тот дешевле работать не будет.

Безусловно, не будет. Вы тут такую простыню накатали, спорили. А с чем спорили-то, если с озвученными тезисами я согласен и нигде их не оспаривал?
Я работник. У меня нет пулреквестов на гитхабе, потому что, когда я нахожу ошибку в библиотеке, я описываю баг вбагтрекере. У меня полно своей работы и физически нет времени делать чужую. Когда я открываю свое резюме, мой телефон раскаляется от звонков HR-ов (им пофиг, что я прошу связываться со мной по мылу, они все равно звонят). Даже когда я не держу свое резюме в открытом доступе, я получаю минимум 1 приглашение на собеседование в неделю (к ним только паподи в базы...).
Поэтому, когда я встречаю работодателя с такими закидонами, как у тебя, я просто прохожу мимо. А ты остаешься без нужного тебе специалиста.
БеСпроблем.
Буду счастлив не иметь у себя в команде такую звезду которая не способна увидеть весь «алгоритм целиком» и заметить что «звезды» и сеньоры попадают в третий пункт.
Ничего личного. Я достаточно «взрослый» чтобы понимать что сухую спецификацию которая не трогает ваших эмоций вы прочитаете лучше. Но мне оно не нужно. Как и вам не нужно работать со мной. Ну бывает, чЁ.
Ты тут уже в комментариях много диагнозов по фотографии поставил, что намекает о том, что ты все-таки недостаточно взрослый, по крайней мере в эмоциональном плане.
И вот когда такие люди начинают принимать решения, очень часто приходит беда.
Ну да, по фотографии, что плохого то? Для чего фотографии нужны? Ведь если бы по фотографиям не ставили диагнозы то их бы не прикладывали к анкетам.
Шучу конечно, но что плохого если даже вот так утрированно взять — отказать кандидату потому что не понравилась фотография, это плохо?)
Нет, серьезно.
Если есть выбор, если ты понимаешь что это необъективно и т.п., но такой тип лица или стиль или еще что — будут вызывать дискомфорт в работе с этим человеком, то что плохого в таком выборе?
У меня в свое время было предложение от одной очень крупной частной корпорации от которого я отказался. Да, з/п была примерно в десять раз выше той что была у меня тогда, но я честно ответил что меня не устраивает их дресскод и я лучше приду раз в год к ним в гости как сторонний эксперт и получу намного меньше чем в штате, но зато приду в свитере а не в галстуке.
Что кто-то был не прав? Я тут выбрал натурально по фотографии, и это было разумно. И для работодателя было разумным не делать для меня исключений (к слову когда я работал в государственном секторе для меня исключения были).

Ну и по «диагнозам» в этой теме:
1) Druu — человек с довольно очевидными психологическими проблемами, он в этой теме их очень хорошо продемонстрировал и да, тут и фотографии не нужно
2) Павел Майоров — единственный «диагноз» который я ему поставил, так это несовместимость со мной. Тут и фотографий не надо. Второе — отсутствие публичной активности повышает цену найма что при прочих равных будет жирным минусом да. Но это не к нему лично а ко всем. А так то с ним бывает интересно подискутировать, даже когда он и «не прав» (по моему мнению конечно).
3) Ты — ну тут просто всё. Эмоциональная оценка изначально была твоя, так что да, эмоционально мы не совместимы, ну и ок.

По поводу эмоций… Ну есть такое, бесит меня когда человек вообще не в зуб ногой в той или иной сфере начинает «отчитывать» тех кто этим занимается профессионально. На Druu вон время трачу. Говорю свою позицию прямо не обращая внимания на размер обратной связи. Ну эмоционально, да. Но… имею право, мы на хабре а не на работе).
Павел Майоров — единственный «диагноз» который я ему поставил, так это несовместимость со мной. Тут и фотографий не надо.

Да ну? Кажется, вы это формулировали по-другому. Но сейчас вы, конечно же, правы: я и правда несовместим с человеком, который сначала делает неверные обобщения, потом из них делает кривые выводы, и при этом не слушает других.

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

И? Что дальше? От того, что баг описан — он никуда не делся. И он прямо сейчас мешает работать лично Вам, конкретно в Вашей "своей работе". Обычно в этот момент частью "своей работы" становится исправление этого бага, разница только в том, насколько грязно это делается и насколько сложно потом это исправление поддерживать.

Ну, если человек никуда не шипит бинарник или если исходный код под BSD-like-лицензией, никто ему не мешает не раскрывать свои правки.

А речь не про раскрытие. Речь про то, что эти правки во-первых сделать необходимо, и во-вторых крайне желательно сделать достаточно чисто, чтобы не создавать лишних проблем с их поддержкой. А дальше, имея чистые правки создание PR — дело пары минут, и отказываться от этого просто глупо: PR даёт возможность получить бесплатное ревью от автора плюс если автор его примет то это избавит нас от самостоятельной поддержки этой правки.

Безусловно. Это я к тому, что техническая и юридическая возможность сделать свою работу, не раскрывая её результатов на гитхабе, есть.
У вас какое-то странное представление о разработке. Не всегда наличие бага означает «немедленно бросить все. перебисать либу, все неверно».
В половине случаев достаточно почитать вдумчиво код и использовать другую апишку. А автору зарепортить что текущее апи не достаточно очевидно и легко попытатся использовать апи Х для задачи Y.
Баг в документации — это другое. Бывает, что баг — это просто баг, а «апишка» — одна-единственная. В моей области (embedded Linux) — нормальная история.
Обидно бывает, когда не принимают, потому что ты заимплементил фичу, поддержка которой нужна тебе, но потенциально ломает парадигму, в рамках которой автор видит развитие проекта.

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


И еще второй способ, в случае больших систем — это создание плагина к ним, вместо добавления кода в основной репозиторий.


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

Для экономии времени можно сначала задать вопрос-предложение. Иногда разработчик предлагает создать PR.

В таких случаях всё равно стоит создать пул (мерж)-реквест и предложить доработать его кому-нибудь другому. Было дело, я поднимал такие пул-реквесты других людей и допиливал, после чего их мержили в апстрим.


Людая работа опенсорс-сообществу может пригодиться.

Здесь только надо учитывать, что человек может не быть фронтендщиком, и тогда риск возникновения подобных ситуаций снижается на порядок (или вернее сказать, что во фронтенд-разработке риск выше на порядок?).

Если отказывается по делу, то надо поправить тесты. Если нет, то надо посчитать, что дешевле: поддержка своего форка или сделать то, что хочет автор.

Чаще «автор библиотеки на неё забил год назад и теперь твой пул-реквест двадцатый из неразобранных».
Или, что хуже — автор библиотечки отказывается принимать PR с аргументом «я лучше знаю как писать код и это не бага, а фича. но я подумаю и может быть через пару релизов изменю это поведение».

Это не обязательно плохо. В зависимости от ситуации это может означать, что автор прав, и библиотека просто используется не так, как было задумано или не по назначению, или что автор не прав, но у него слишком большое эго, чтобы признавать свои ошибки. В обоих случаях продолжать использовать эту библиотеку (текущим образом в первом случае, или в принципе во втором) — явно становится слишком рискованно. И то, что благодаря отклонённому PR вы об этом узнали раньше, чем это стало проблемой для вашего проекта — хорошо.

Это был второй случай:

«Проблемы с потреблением памяти» — это одна из функций требовала памяти в 16 раз больше, чем реально могло бы потребоваться (а когда памяти не хватало — функция кидала die() ).

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

Ну если раз в полгода релизится, то можно и пересмотреть его коммиты и если ничего ужасного то затянуть их в свой форк, а так да «форкнул и забыл».
Автору проекта может банально не хватать сейчас времени на code-review вашего изменения кода проекта. А мергить без review ОЧЕНЬ дорого обходится.
Оставляете пул реквест и ждете. Иногда год.
Может.

Но моя правка заключается в одной (!) строчке, снабжена подробнейшим описанием в комментариях и issue. ЧСХ, проблема такая не у меня одного.

Оставил пулл-реквест, пулл-реквест отвергнут почти сразу же. Комментарий автора выше писал.

Автор библиотеки, наверно, не прав (но утверждать это точно я не могу ибо не видел кода). Но надо помнить, что он в целом никому ничего не обязан.

что в ней есть баг.

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


На а дальше — всё зависит от ваших устремлений. Если вы чувствуете активное желание обязательно делиться со всем миром своими наработками — делитесь. Если вы хотите понравиться потенциальным работодателям чем бы то ни было — делайте это. Если ни первое ни второе не про вас — тратить время на присылание кому-то патчей будет ни к чему.

Всё просто, либо вы тащите с собой этот патч до скончания веков — накладываете его на новые версии библиотеки, чините мерж-конфликты — либо держите устаревшую версию с возможными багами, уязвимостями и проблемами совместимости с новыми системами, героически превозмогая ещё и это.
Обычно хорошие разработчики стараются всего этого избежать, поэтому пропихивание патча в апстрим решает чисто ваши собственные проблемы.
К сожалению полно «разработчиков» которые считают что поддержка кода это не его забота. И это еще не самое страшное. Хуже когда они считают что это таки да их забота, но вместо того чтобы пойти прямым путем (в данном случае это пулреквест, в другом случае — использовать классы для ООП, а не хрен знает для чего) — появляются такие ужасы как VQMOD… и да, в данном случае поддерживать совместимость с новыми версиями можно с помощью VQMOD.)))
После чего вы его исправляете в дереве исходных кодов вашего софта, куда включён код библиотеки.

За бандленные версии библиотек в дереве опенсорс-проекта надо делать что-то нехорошее с лидом такого проекта.

Разве что, если автор либы категорически отказывается принимать фикс или новую фичу, но тогда лучше форкнуть и выложить библиотеку отдельно.
За бандленные версии библиотек в дереве опенсорс-проекта надо делать что-то нехорошее
А как надо? Подключить remote/external к определённой ветке-релизу другого проекта? Но это, по сути, замораживание версии.

Или подключиться к master/trunk другого проекта? И думать, почему перестало компилироваться в самый неудобный момент, или стало глючить, когда автор мутит какие-то эксперименты и новые API.
Зачем что-то куда-то подключать?

А вообще это от языка и его инструментария зависит. Я-то, считайте, два языка использую, плюсы и хаскель. В хаскеле всё просто, последние пару лет там принято использовать stack, а до того — cabal, они сами когда надо и зависимости выкачают, и соберут их, и так далее. В плюсах пакетного менеджера нет, поэтому авторы проекта Foo, как правило, пишут в своих Makefile/CMakeLists.txt/etc директивы для нахождения сторонних пакетов, а мейнтейнеры проекта Foo в соответствующих дистрибутивах следят за тем, чтобы оно всё собиралось, чтобы версии были правильными, и так далее.

А когда автор мутит эксперименты и новые API, он не делает новые релизы этих библиотек.

mva, мейнтейнящий ряд вещей в Gentoo, может вам поболе рассказать, думаю.
А, т.е. предлагаете unix-way — не тащить хидеры к себе в дерево проекта, а требовать их наличия в /usr/local/include и в переменной окружения INCLUDE, и устанавливать либы в систему.

Ну не знаю, в Windows (и в Android) давно от такого отказались из-за проблемы Dependency Hell, там предпочитают, чтобы каждая софтина включала внутри себя все библиотеки, 50 МБ кода никакой погоды не сделают.
Эм, причём хедеры к dependency hell? Это ж исключительно вопрос сборки и пакетирования.

В ОС/дистрибутивах, где софт собирается централизированно, такой проблемы заведомо нет (наоборот, возникают проблемы с проприетарным софтом, поставляемым со своей джавой-бустом-кутями-libGL.so). А при сборке вашего проекта под Windows или Android или OS X никто не мешает в процессе сборки подтягивать все нужные зависимости и класть их в .msi/.dmg/etc. Зато ваша репа с исходным кодом чистая и содержит только ваш код, а не кучу очередных копий очередных библиотек в непонятно каком состоянии (а патченные ли они, например?). И история коммитов отвечает только вашим изменениям.

Один мой опенсорс-проект именно так собирается: в репе ничего, кроме него (и в одном месте выдранных кусокв libqxt, потому что оно, похоже, сдохло), а при сборке под макось macdeployqt и самописные костыли кладут куда надо все вспомогательные библиотеки (которые при этом при разработке под макосью тащатся из homebrew).
А что будет, если вам станет лень поддерживать свой проект, но кто-то через 10 лет захочет собрать его из исходников, а все либы-зависимости развились далеко вперёд и потеряли совместимость со своими старыми релизами?
Виртуалка, LTS релиз тех лет, и проект, который нужно запустить.
Ровно так и запускается все это старье.
А если бы исходники (или даже бинарники в случае windows) всех либ лежали в репо, оно бы собралось сразу.
Или не собралось бы. За 10 лет понавыходит новых стандартов языка и компиляторов, которые будут более строго относиться к кривому коду прошлых лет.

В любом случае, это представляется очень маргинальным юзкейсом.
Ну и да, я не говорю, что это идеальный подход. Вариант haskell stack, с lts-релизами множества зафиксированных версий библиотек, сендбоксами для сборки и возможностью при этом подтянуть любую библиотеку откуда угодно, хоть с гитхаба по commit hash, мне нравится куда больше.

В вашей репе при этом всё равно ничего стороннего нет, есть только указание списка и набора версий сторонних библиотек.
10 лет никто ничего не делал с проектом, никто про него не вспоминал, и через 10 лет он кому-то понадобился? Мне очень сложно в это поверить. А так вам уже написали, да.
10 лет никто ничего не делал с проектом, никто про него не вспоминал, и через 10 лет он кому-то понадобился?
Ну дык эта. А почему нет. Как сервер встал — так и замену нужно устроить. А за это время и процессоры сменились (x86-64 нонче в моде, да) и дистрибутивы немного другие…

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

Но так-то мы тут за опенсорс говорили, а не за кровавый тырпрайз.
Но так-то мы тут за опенсорс говорили, а не за кровавый тырпрайз.
Они, как ни странно, пересекаются куда как жёще, чем вам кажется.

Если это не IBM и не NASA, то, как сейчас уже, как правило, встречается немного подкрученный open-source… 10-летней выдержки. Понять что и как там подкручивали — зачастую не так просто. Проще «с помощью лома и какой-то матери» завести исходники 10-летней давности. Ну а через очердные 10 лет, когда очередной сервер умрёт — кто-то будет собирать исходники уже 20-летней давности.

Чисто для справки: поинтересуйтесь тем как устроены SPEC CPU 2000 и SPEC CPU 2006. Мы их и сегодня на современных системах собираем без всяких правок — а это, как бы, сплошь open-source проекты… так что рассказы про то, что «за 10 лет понавыходит новых стандартов языка и компиляторов, которые будут более строго относиться к кривому коду прошлых лет» — это для бедных. 252.eon вполне себе рулит и побеждает на не то, шоб очень уж старом, clang 5
Ну, как для бедных. Я вам в ответ могу порассказывать историй, связанных с геморроем от перехода с gcc 4.9 (RH DTS 2) на 5.4 (RH DTS 4).
Расскажите. Интересно. Потому как в моей практике все обычно было в районе пары исправлений на сто тысяч строк. То есть если их в проекте много миллионов, то да, в абсолютных величинах их может быть много — но масштабы обычно даже и близко не сравнимы с тем, которые требуются для того, чтобы найти правильные исходники из которых оно всё собиралось. Если, конечно, в своё время на это не обращали внимания и делали как тут рекламируют: «trunk сегодня у меня собирается — ну и хорошо».
Как-нибудь потом, оно пока под нда.

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

Но идеально, когда есть всякие BUILDING{,.txt,.md}, конечно.
Эм, причём хедеры к dependency hell? Это ж исключительно вопрос сборки и пакетирования.
Такой подход подразумевает, что библиотека установлена в системе, и строго последней версии?

Если в коде проекта написано
#include <pcre.h>
то в проект референсится последняя версия, а не та, с которой тестировал автор собираемого проекта.
Такой подход подразумевает, что библиотека установлена в системе, и строго последней версии?

Нет, почему? Версии не меньше той, которая поддерживается автором, и той же major-версии.

В системе, кстати, может стоять несколько версий одной и той же библиотеки, включая хедеры (см. слоты в генте, например).

то в проект референсится последняя версия, а не та, с которой тестировал автор собираемого проекта.

А вы правда тестируете с новыми релизами pcre, openssl и glibc?

Бессмысленно получить более оплачиваемую работу? Кому как. Если вы и так получаете максимум, доступный или желаемый для вас (или вообще не работаете, потому что не хотите), тогда никакая дополнительная ачивка не нужна.

Просто посчитай количество человеческой работы, которой ты пользуешься бесплатно как программист.
Начиная ОС, языка, ИДЕ, сторонних либ. И тебе жалко потратить несколько часов своего времени чтобы поддержать open source? Это звучит жалко...

А в чем тогда по вашему вообще есть смысл? Лежать на диване и смотреть телевизор с утра до ночи? Достижения прежде всего нужны вам, а не кому-то. Я живу по принципу: «все или ничего». Мне тоже часто приходится проходить через огонь, воду и медные трубы, но главное не останавливаться и шаг за шагом достигать намеченных целей))
Так ведь помогая сообществу, Вы помогаете и себе. Хотя бы тем, что получаете дополнительный опыт.

А приведите свой фрагмент кода для обозрения в подтверждении вашего многозначительного " то..."

Ну вот, а говорят, что у роботов чувств нет.
Тут речь о том что поиск увлеченных людей для участия для работы в сервисной компании это фундаментальная ошибка. Потому что программная инженерия это вообще не разу не интересная штука. Это не написание блистательного кода в супер новом и крутом приложении, это джитуии приложения с тоннами чужого кода с устаревшими концепция в основе платформы. Это тупые митинги и бесконечные чаты, код ревью и написание документации в объёме большем чем объём кода, это бесконечное планирование и эстимации, это обучение новичков и попытки объяснить клиенту что так как он хочет сделать будет очень дорого. Вообще ничего интересного для тех кто увлечён программированием. Искать для такой работы звездных программистов это как минимум чудовищная глупость.
UFO just landed and posted this here
И почему-то только у программиста считается НЕ НОРМАЛЬНЫМ не заниматься своей РАБОТОЙ в нерабочее время бесплатно ради «ачивки», а иметь ДРУГИЕ УВЛЕЧЕНИЯ.
Не «почему-то», а вполне понятно «почему»: Хороший программист в 10 раз более продуктивен, чем средний. Отличный программист в 20-100 раз более продуктивен, чем средний. И это не преувеличение — исследования, проводящиеся с 1960-х годов, чётко это показывают. Плохой программист не просто непродуктивен: он не только не выполняет свою работу, но ещё и создаёт проблемы, которые приходится решать другим.

Вы можете нанять дерьмового почтальона и фигового уборщика и компенсировать качество зарплатой — ну придётся вам нанять 5 уборщиков вместо 4, снизите зарплату на 20% и всё будет нормально.

Но даже самый паршивый программист не будет работать за 1/10 той зарплаты, которую вы платите хорошему программисту — он просто не выживет. Особенно в силиконовой долине.

Так нафига брать его на работу и переплачивать за него?

P.S. Наличие кода на github не доказывает, конечно, что перед вами — хороший программист. Но увеличивает вероятность этого. Вот и всё…
UFO just landed and posted this here
Я вот в нерабочее время предпочитаю программировать для души. Но моя основная работа с программированием не связана никак. Если у меня будут проекты на github я автоматом становлюсь хорошим программистом?
Если вы этому уделите достаточно много времени — то да, можете стать лучшим программистом, чем те, кто получили диплом по этой специальности.

Математика обычно такая:
Если мне надо написать модуль, то хороший программист потратит на него условные 10 часов за 2000р в час = 20000р.
Средний программист потратит 12-20 часов по 750-1000р в час — от 8000 до 20000р — качество кода не хуже.
Плохой программист потратит 30 часов по 1000р в час.
Это если вам нужно написать этот модуль — и повесить на стенку в рамочке. А вообще-то нужно, чтобы модуль использовался. И тут получается совсем-совсем другая математика:
Хороший программист потратит на него условные 10 часов за 2000р в час = 20000р. На этом всё закончится.
Средний программист потратит 12-20 часов по 750-1000р в час — от 8000 до 20000р — качество кода не хуже… вот только не работает оно почему-то. После недели-двух отладки — будет обнаружено, что в ТЗ «кой-чего не учли» — а программист спросить не догадался. Итого — уже 42-100 часов. От 31500р до 100000р.
Плохой программист потратит 30 часов по 1000р в час — потому что придётся всё переписывать три раза и пару раз вся команда программистов из 100 человек будет терять по полчаса на «расхлёбывание» последствий первых двух коммитов. А в последущий год к этому модулю придётся возвращаться раз 10 и переделывать — каждый раз снова часа по три. Суммарные затраты времени на этот модуль — легко улетают за миллион.

Разобраться с тз и понять с какой стороны приступать занимает больше времени.
А кто с этим спорит? Хороший программист от плохого отличается не тем, сколько знаков в минуту они набирают. Когда речь идёт о потраченном времени, то речь идёт обо всём потраченном времени — включая постановку задачи и, главное, отладку и исправление ошибок. Которые, как раз, у плохого и хорошего программистов и отличаются в десятки раз — и которые, как раз, неплохо можно отследить по любому проекту на github'е.

Мой личный, правда старый, пример: у нас был драйвер для Windows (виртуальная файловая система, всё такое) и человек, который отвечал за этот драйвер потратил полгода на то, чтобы сделать так, чтобы драйвер не падал на Windows ME. Безуспешно. После чего был найден специалист, который за неделю написал такой же драйвер с нуля. И он работал. Недёшево обошлось, да — но результат того стоил: во сколько там разница в производительности была (притом, что кроме полугода борьбы с Windows ME там ещё было потрачено время и на другие вещи — до того, как наступил кризис)? А с учётом того, что всё это время приходилось клиентов «завтраками кормить» и обьяснять, что Windows ME мы «пока» не поддерживаем?
UFO just landed and posted this here
Окей, предположим в ТЗ указали про админку… А список должен быть с группировками или без? А можно ли там ставить фильтры в этом списке по товарам или по подписавшимся? А нужно ли этот список потом выгрузить в csv (ваш_формат) или нет? ТЗ может быть очень и очень полным, но тогда на такую простую фичу оно займет прилично места и времени для его проработки.
Почти всегда в ТЗ есть что-то, что «забыли», «не учли», «не расписали»…
Ну вот, снова придираетесь! Ясно же, что программист должен был угадать желания.
А вообще, ТЗ- лучший друг программиста и заказчика функционала.
UFO just landed and posted this here
UFO just landed and posted this here
Не-не, это вы возлагаете на программиста обязанности, которые свойственны или разработчику (инженеру), или консультанцу-внедренцу, или кому-нибудь еще. Вот когда я работаю как программист, я открываю ИТИЛЬ, открываю первую задачу в списке и делаю то, что написано. С некоторых пор, если я где-то в чем-то не уверен, я могу вопрос задать лишь менеджеру, а тот задаст его клиенту. Или ответит сам. Мое дело — кодить.
Другое дело, когда я — разработчик. Там я могу задать вопросы или не задать и сделать на свое усмотрение или сделать опять же ровно то, что заказано. Больше фич — пожалуйста, больше денег. А то оказывается, что хотелок у клиента на 50 листов, а оплата — на студента. Оплатил как студента, задачу поставил как эээ профан (сэкономив на предпроектной стадии, ага), получил соответствующий результат. Можно вместе с клиентом составить этот 50 страничный документ, но будет ли он его оплачивать? Будет ли он оплачивать все эти фишки, которые всплыли во время формализации? Нет, он подготовил бюджет на «сделать подписку на поступление товара». Плевая задача на часок работы и 10 баксов.
К тому же, какие вопросы правильные никто не знает. Для клиента мои вопросы могут показаться глупыми (например, вам файлы с BOM или без?), а важные для клиента вопросы могли быть и не озвучены… Simplevolk прав, читать мысли мы еще не умеем.
UFO just landed and posted this here
О эта любовь айтишников спихивать с себя обязанности.
О эта любовь неайтишников — требовать дополнительной работы бесплатно.

Ваша задача написать модуль.
Ok.

Правила хорошего тона — переменные настраиваются в админке (или вы и переменные жестко в код зашиваете?)
Нет — переменные у меня в текстовом конфиге. Иногда — передаются в командной строек или кладутся в базу. От проекта зависит. Никакого UI для их модификации нет — потому что мне он не нужен и его написание — это дополнительная работа.

Всякие хотелки по отображению это уже хотелки, а вот базово показывать список подписок, что бы минимально понять работает модуль или нет, имхо, очевидно.
Совершенно неочевидно. Это увеличивает обьём работы примерно вдвое (а то и в несколько раз) и в первоначальную постановку задачи не входит от слова «совсем».

Если вы закажите плотнику прорубить «чёрный вход» в дом — вы от него тоже будете ожидать что он дорожку булыжником выложит и калитку в ограде сделает? Ну это же «правила хорошего тона»?

Так вот — «в тз кой-чего не учли» оно одинаково для любого программиста.
Нет, конечно. Хороший программист — вынесет настройки в базу. Средний — в текстовый файл конфигурации. Плохой — всё захардкодит и даже CSS напишет через style="".

В результате модуль у третьего может даже и раньше «поспеть» — но «на долгих дистанциях» оно таки выстрелит.

Пока что наша дискуссия выглядит примерно так:
Veyron в 10 раз быстрее мопеда
— да ладно вам: я вчера на мопеде задирал телевизир из ремонта — так быстрее соседа с таким агрегатом управился
— но ведь ремонт телевизоров — в вашем доме находится!
— да — но с другой стороны дома!

То же самое с тут: невозможно ничего сказать о качестве программиста по заданию на 50-100 строк кода. Отсюда, собственно, и статья, которую мы обсуждаем, взялась…
UFO just landed and posted this here
Хороший пример. Заказали вы сделать черных ход в дом у плотника. Он вам зарядил 50 тысяч с дверью. Вы выбрали дверь и платите 50 тысяч. Приходите, а в стене дыра и дверь рядом лежит. Ну а чо? Черный ход с дверью, а про установку в тз ничего и не сказано. Вы в ты не написали, а мне чего?
Извините, но пользоваться лежащей на полу дверью — нельзя. Модулем без красивого интерфейса в админке — можно.

Статья взялась вообще с затеи, что программиста проверять на его работу вне рабочего места и делать какие-то выводы как минимум ограниченно для HR.
Почему? При выдаче кредитов заёмщика оценивают по тому, что у него лежит в холодильнике, а почему при приёме на работу нельзя оценивать по тому, что лежит на GitHub'е? Тот же «холодильник», только для кода, по большому счёту…
UFO just landed and posted this here
Заемщика оценивают потому, что если у него ничего нет в холодильнике — очевидно кредит он не выплатит.

Вот ведь блин.
А если у него полный холодильник то значит выплатит?)
Вот так скажешь пять фраз из целого рассказа, запомнят одну, и ту упрощенно, а потом будет как всегда.
Особой корреляции между полнотой холодильника и добросовестностью заемщика нет.
Зато есть большая корреляция между несоответствием холодильника образу жизни внешнему виду заемщика и добросовестностью.
Тут больше сходство с тем как на паспортном контроле могут спросить «какой у вас знак зодиака?». При этом если ты его не знаешь то это вовсе не значит что у тебя паспорт поддельный, но приглядеться к тебе повнимательнее стоит…
Если вам потом поддерживать этот проект, сможете ли вы признаться заказчику, что доработка вашего модуля займет не 3 часа, а 20

А откуда 20? Один программист сделал модуль за 3 часа, вынес настройки в конфиг, другой программист при доработках нашел конфиг и поменял. Занимает 2 минуты.
Если вы под доработками подраузмеваете UI в админке, которое все-таки пришлось сделать, то вам так сразу и сказали — админка это дополнительная работа. Либо вы эти 17 часов оплатили сразу тому же программисту, либо потом другому.


Заказали вы сделать черных ход в дом у плотника. Он вам зарядил 50 тысяч с дверью. Вы выбрали дверь и платите 50 тысяч.

Итак, установим соответствие между сущностями в этой аналогии. Черный ход — это модуль. Дверь — это дизайн модуля. Дом — это сайт. Сделать черный ход в доме с красивой дверью — добавить модуль на сайт с понравившимся дизайном. Дверь лежит рядом — модуль отправлен вам в архиве, устанавливайте сами. Черный ход 40x40, не позволяет им воспользоваться человеку — модуль размера 1x1 пискель, либо кнопки невидимые, не позволяет пользователю его использовать.
Где в этой аналогии админка?


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

Простите, а как это вообще влияет на качество программиста???!!!

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

Мы тут о программистах говорим, или о супер-пупер-мега-левшах-и-на-дуде-игрецах? Про последних недавно хорошая статья была, вот: Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо приняли.
Потому что хобби «для души» никак не должно быть работой и наоборот.

А о том, чтобы дома решать рабочие задачи, никто и не говорит.
UFO just landed and posted this here
У нас, вероятно, разные определения ограниченности, но поигрывание на гитаре песен про севшие батарейки и прочие подобные вещи не сильно расширяют кругозор.
В автосервисе человек варит всякие ржавые вёдра, а в своём гараже скульптуры из оставшихся кусков и запчастей это ограниченно?

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

С чего вы решили, что это очевидно? Речь идет о конкретном функционале за конкретные деньги. Вывод в админке — это другой функционал, и работы там больше, чем для самой кнопки. Это как электрика попросить "Установите мне электросчетчик", а потом удивляться, почему это он вам всю проводку в доме не развел, очевидно же, что электросчетчик вам сам по себе не нужен.

UFO just landed and posted this here
Если вы электрика попросите УСТАНОВИТЬ счетчик, а он придет и вкрутит вам счетчик в электрический шкаф прямо на шурупы на старый, не подключая провода и не опломбировав его потому, что вы не указали, что вам еще старый отключать (в тз же установить- про демонтаж там ни слова) и провода подключать надо и пломбировать, а еще и документы, наверное, надо? Это будет считаться УСТАНОВКОЙ или все-таки нет?
Прекрасный пример! Просто-таки великолепный! Ну просто у меня мама как раз недавно этим занималась.

Так вот: установка и замена счётчика — разные вещи. Демонтаж оплачивается отдельно. И установка УЗО — тоже отдельно. И нет, она не является «само-собой разумеющейся».

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

Да, только не в админке и не в коде. А там, где программе удобнее их взять, а программисту поменять.
Да, только не в UI. Для проверки и отладки есть специальные инструменты. Да, клиент к БД один из них.


И уж точно обязательно для уровня ТОП программистов

Вы неправильно представляете ситуацию. Сторонний программист, нанятый для одного модуля, и постоянный, который работает на поддержке проекта, имеют разное отношение к работе и разную информацию о нем.
Стороннего вы нанимаете сделать конкретный объем работ, он даже не в курсе, может вы админку другого наняли делать.
А постоянный знает, кто работает на проекте и что уже сделано, и может предположить, что потом все равно задача появится на вывод списка, и возможно спросит заранее.


Если вы электрика попросите УСТАНОВИТЬ счетчик...

Он сделает то, что указано в процедуре оказания услуги "Установка счетчика". В этом случае ТЗ находится в нормативных актах и правилах его фирмы. В вашем случае ТЗ вы делаете сами.
Так что да, если он выполнит все что указано, это будет считаться установкой. Независимо от того, что вы сами об этом думаете.

> Хороший программист потратит на него условные 10 часов за 2000р в час = 20000р. На этом всё закончится.
> Средний программист потратит 12-20 часов по 750-1000р в час — от 8000 до 20000р — качество кода не хуже… вот только не работает оно почему-то. После недели-двух отладки — будет обнаружено, что в ТЗ «кой-чего не учли» — а программист спросить не догадался. Итого — уже 42-100 часов. От 31500р до 100000р.
> Плохой программист потратит 30 часов по 1000р в час — потому что придётся всё переписывать три раза и пару раз вся команда программистов из 100 человек будет терять по полчаса на «расхлёбывание» последствий первых двух коммитов. А в последущий год к этому модулю придётся возвращаться раз 10 и переделывать — каждый раз снова часа по три. Суммарные затраты времени на этот модуль — легко улетают за миллион.

А все эти замечательные выкладки подтверждаются чем-либо, кроме ваших личных фантазий? Допустим, цифры по оплате даны, но откуда вы взяли цифры о производительности? Может, плохой программист за 1000 прекрасно все сделает за 12 часов, а не за 30? А хороший — с-но, за 11?

Как уже упоминалось в комментах — есть куча классических исследований на эту тему. Сто не сто, но в десять а то и десятки раз — такие цифры результаты этих исследований действительно выдавали. Хотите более конкретно — посмотрите у Макконнелла, он кучу такой статистики в Code Complete приводит, со ссылками на конкретные исследования.


Другое дело, что эти "классические" исследования проводились до 2000-го, а то и до 1990-го, и с тех пор появилась (или просто начала намного более широко использоваться) куча инструментов и техник, которые теоретически должны компенсировать ряд слабостей программистов, и средним/плохим программистам, теоретически, это должно помочь сильнее, чем хорошим — сокращая таким образом разрыв в продуктивности. Так что было бы интересно почитать более современные исследования на эту тему.

> Как уже упоминалось в комментах — есть куча классических исследований на эту тему.

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

Почему это фиаско? Некоторые люди и не стремятся в элиту за счёт других интересов — в тексте же написано, что для того чтобы быть элитой надо ущемлять другие жизненные интересы, а многие на это не готовы. Лично я, человека, который в 30+ лет оргазмирует лишь от вида кода и не имеет других интересов (девушки/жены/детей/игры на гитаре/кайтинга/<что хотите добавьте по вашему желанию много раз>) — назвал бы инфантильным задротом. Просто потому что это человек может и крутой специалист, но… абсолютно неинтересный в других сферах. Для работодателя, возможно, это находка, но… тогда этот человек не войдёт по параграфу "не подходит к нашему сработавшемуся коллективу" =).

Лично я, человека, который в 30+ лет оргазмирует лишь от вида кода и не имеет других интересов (девушки/жены/детей/игры на гитаре/кайтинга/<что хотите добавьте по вашему желанию много раз>) — назвал бы инфантильным задротом.

А если кроме кода ещё, скажем, матаном обмазывается, это уже норм?

Это вы с целью потроллить интересуетесь?

Нет, с целью скорректировать свои ожидания относительно средних ожиданий.
Когда компания говорит, что ищет «увлечённых разработчиков», которые программируют в свободное время, когда говорит, что ищет «лучших», я начинаю нервничать. Это близорукий подход к тимбилдингу. Это коварный способ найти людей-роботов.

У кого-то хобби это ходить по горам, а у кого-то программировать. Почему это сразу люди-роботы.


Я не уделяю достаточно времени тому, чтобы поддерживать на высоком уровне своё образование и навыки. Программирование — это «просто работа».

А потом присылают тестовое задание с OpenGL 1, или c delete this в деструкторе.

Ну честно говоря, delete this, вообще то не самое элегантное решение. В деструкторе то понятно бред. Но вот вызов в функции тоже должен быть сделан аккуратно. Потому как обращение к члену или вызов метода (non static) не меньшая дурь. И в случае с деструктором все быстро и понятно, то с вызовом еще где-то можно нарватья на любителя извращений и построения трехэтажных велосипедов с приводом на переднее колесо…
А у кого нет хобби (только работа)? Кто после работы фрилансит? Получается так же не чего показать. Хотя как бы работаешь…
Можно же показать проекты, в которых принимал участие, пусть даже это не код, всё равно уже неплохо? Плюс технологии, которые использовал.
Если идет ООП, то тут одним файлом дело не кончится, слишком всё взаимосвязано.
Необязательно показывать все зависимости. Они и сами не будут в этом всём разбираться. Можно выбрать просто самый «симпатичный» класс :D
Где взять эти проекты, если во-первых они под nda, а во-вторых ты сам не знаешь в какой из заморских лабораторий они находятся?
Хм с этой стороны я не подумал.
Да. Кстати когда меня брали на работу, про гитхаб не спрашивали. Правда тогда ещё были в сети сайтики, которые я делал, может их смотрели. Пс. минус не я поставил
Вообще, когда устраиваешься на работу, попадаются заказчики, которые занимаются либо конвейерной разработкой, либо работают над одним/несколькими крупными проектами. Первая категория заказчиков ищет не вольного копейщика, а подневольного пахаря, который будет получать деньги по факту сдачи проекта. Но их достали нубы, и где-то они слышали, что у опытного разработчика должно быть несколько OpenSource проектов и код в гите, который он может показать. Но эти разработчики предпочитают работать со вторым типом заказчиков. Эти заказчики, как-правило, предлагают выполнить тестовое задание, пройти собеседование с техническим специалистом, либо пройти небольшой технический тест. Поскольку у них у самих NDA, плюс их не интересует где ты там писал функции для контроллеров холодильников. У них своя ниша, и их интересует, сможешь ли ты быстро вникнуть и начать работать. Вот и получается, что вопрос «покажите нам свои проекты на гитхабе», фактически означает поиск промышленного программиста, который ни за что не согласится работать за их зарплату и на их условиях. Это просчёт HR.
А у кого вообще нет хобби? Я не собираю после работы спиннеры. Я читаю, гуляю, смотрю фильмы, общаюсь с друзьями и семьёй, занимаюсь домашними делами.
читаю, гуляю, смотрю фильмы, общаюсь с друзьями и семьёй, занимаюсь домашними делами
Ну вот видите, как у вас много хобби.
Ну какие же это хобби. Так можно и сон с дыханием в хобби записать.
Хо́бби (от англ. hobby — увлечение, любимое дело) или увлечение — вид человеческой деятельности, некое занятие, которым занимаются на досуге, для наслаждения.
Сомневаюсь, что вы ловите какое-то особое наслажение от дыхания. А вот чтение, фильмы и все остальное, что вы перечислили выше, вполне подходит под определение.
Ну значит программирование (уже?) не его тема…
Это значит, что ему есть чем заняться, кроме программирования. Я тоже предпочитаю в свободное время не заниматься программированием. Но это совершенно не значит, что я не программист.
А если подойти с другой стороны. Постоянно появляются новые инструменты разработки. Чтобы уметь создавать ценность с их помощью, надо с ними экспериметировать. Вопрос, кто должен за это платить (компания рабочим временем, или программист личным)?
Весьма честный подход, что компания платит за результат (работу на хорошо известных, проверенных временем технологиях), а программист в свободное время педалит никому не нужные проекты на новых «горячих» технологиях, чтобы быть востребованным через год-два.
> Вопрос, кто должен за это платить (компания рабочим временем, или программист личным)?

Безусловно, компания. Она же хочет, чтобы ее работник и через год-два был хорошим работником?
Если компания и дальше планирует пользоваться тем же стеком технологий, то через пару лет программист хуже не станет.
Если нужно компании, то она выделяет не только рабочее время, но и деньги на обучение.
Проблема в том, что редко, когда это нужно. К примеру, реальный случай, знаю людей, которые хорошо знают Delphi, и пишут на нем сегодня, поддерживая легаси систему (да, ее переписывают потихоньку, но совсем другие люди, а эти люди нужны именно тут, и поэтому, компании их обучить чему-то посвежее невыгодно). Работодатель доволен, и они, вроде, не унывают. Но получают меньше своих коллег из других команд, использующих современные языки.

Если их это устраивает, то все хорошо. А если нет, то единственный вариант стать ценнее на рынке (и не важно, уйти на новые технологии, или остаться на Delphi, но с прибавкой к ЗП) — выучить что-то новое, экспериментируя по вечерам.
PS и да, деньги и некоторое время выделяются. Но, понятно, что никто не заапрувит Delphi девелоперу курсы по .Net Core или модным фреймворкам js, так, как это не поможет компании

Или дождаться когда делфи разработчиков станет ЕЩЕ меньше :)

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

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

Это компания хочет, чтобы человек, который у нее работал — был нужным. Самому программисту это не надо, не путайте.
Это если работник уже есть.
А если это не работник а соискатель, и таких соискателей достаточно, поскольку компания и соцпакет дает хороший, и зарплату, и обучение и даже время на написание опенсорса выделяет, а значит желающих хватает.
И вот значит приходит к такому работодателю два кандидата — у одного есть гитхаб с репами/коммитами, а у другого нет. Первичное собеседование одинаковое. Код на гитхабе нравится, а где не нравится так все понятно почему («ну я это писал когда только начинал, а дальше вынужден был поддерживать ибо многие используют» или еще почему).
Выбор простой — взять того что с гитхабом, или отказать ему, и усиленно тестировать второго, авось он лучше окажется. Потратив на его тесты время, и возможно деньги.
Ваш выбор?
>Вопрос, кто должен за это платить (компания рабочим временем, или программист личным)?

У меня к этому такое отношение — компания платит мне не за часы, и даже не за результат, а за вклад в компанию.

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

Главное, чтобы ожидания с обеих сторон выполнялись.

При этом, понятно, что есть тёмная сторона, можно соответствовать ожиданиям делая примерно нулевой вклад (чем, на мой взгляд, занято далеко ненулевое количество сотрудников), но тут уж только личные моральные устои помогут.
понятно, что есть тёмная сторона, можно соответствовать ожиданиям делая примерно нулевой вклад (чем, на мой взгляд, занято далеко ненулевое количество сотрудников)
Если верить Принципу Парето (и применить его три раза), то половина сотрудников делает один процент работы, а один процент сотрудников — половину работы.
Даже больше половины и меньше процента:
0.8*0.8*0.8 = 0.512
0.2*0.2*0.2 = 0.008
Если 1% сотрудников делает половину работы (50%) и ещё половина сотрудников делает 50% работы, то что тогда делает 49% сотрудников? :)
Ничего не делают, и даже немножко мешают.
Если 1% сотрудников делает половину работы (50%) и ещё половина сотрудников делает 50% работы, то что тогда делает 49% сотрудников? :)
Половина сотрудников делает не 50% работы, а 1% (в сумме, а не каждый процент сотрудников по проценту работы).
Тогда на остальные 49% сотрудников остаётся 49% работы.
Я тоже с недоверием отношусь когда гитхаб у разработчика пустой. Плюс в компании выносим то, что не содержит бизнес-логики на гитхаб аккаунт. Ведь очень часто случаются ситуации когда можно кусок упаковать в пакет, мало ли где и кому пригодится.
А зачем выкладывать свои pet — проекты всем на обозрение?
Не обязательно пет проекты. И даже если это они, почему нет?
Хм. А почему да? Эксгибиционизм какой-то, как по мне.
Почему эксгибиционизм? Мы вроде о смене работы говорим? Так вот «пет проект» с github'а вы на новой работе сможете использовать, а то, что осталось под NDA — нет.

Так что выкладывать всё, что не является вашим конкурентным преимуществом (то есть не то, что позволяет вашей фирме зарабатывать, а всякие вспомогательные вещи) на github — очень пользительно.
Ок, если это касаеться пет-проекта, еще хоть как-то можно обосновать. Но ведь помимо этого есть еще куча вещей.
обычно это просто увеличивает энтропию в мире… а к тому же зачастую мешает менять и совершенствовать код в этих проектах.
Делать реально нормальный опенсорс это труд причем не малый. Зачастую стоит пожалеть нервы и время людей которые вдруг используют ваш код. Т.к. саппорт или даже ответ на свой вопрос они врят-ли получат

Чтобы было видно, что контора не дно днищенское.
Вы ж знаете, эйчары льют кисель на уши, а по факту как не спросишь хотя бы про Джоел-скор, так никто не в курсе. Так хоть соискатель видит уровень конторы.

Стоп, причём тут контора и мои личные проекты?

Речь не о личных проектах, а о конторах, которые свои полезные фичи, которые не корные и не НДАшные опенсорсят. Обычно это конторы высокого уровня.

В смысле пет-проекты контор. Тут соглашусь. Хорошая практика.
Twitter Bootstrap — это Pet-проект? Этот фреймворк начал разрабатываться как внутренняя библиотека компании Twitter.

Вообще много таких. Возьмите любую мейнстримовую контору, хоть Гугл, хоть MS — у них тонны OpenSource. И ведь кто-то это все писал…
Нет. Есть 2 вида кода: проект и модуль. Так вот модули без бизнес-логики выносить очень полезно в опенсорс. Хотя бы потому что разделение зависимости положительно сказывается на качестве кода и дает возможность использовать еще раз этот модуль в следующем проекте.
Обсуждение, общение, обмен опытом.
На гитхабе? Да они там никому не нужны. Там тонны всякого Г валяются.
Не нужны или о них никто не знает? Пишешь статью на reddit/so и понеслось.

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

В общем, кому надо, тот возьмёт и сделает.

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

Меня весьма настораживает, когда у соискателя много выложено на гитхаб. Особенно если количество своих разработок (или сильно развитых форков) переваливает за десяток — это верный знак того, что человек на работе хронически чувствует себя не на своём месте, и находит отдушину в программировании на стороне. Мне, как злобному капиталисту, ставящему ценности моего текущего работодателя выше личных, в команду не очень нужны такие сотрудники.

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

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

o rly?
Я сейчас занимаюсь разработкой ММО РПГ. ТОчнее я её довожу. Проект многие годы разрабатывался ребятами на энтузиазме. Сейчас у них появились деньги и они начали активнее работать. В частности наняли меня, чтобы допиливать проект.
Я чувствую себя на своём месте. Мне нравится код проект, сеньор который его писал — написал его так, как на его месте этот код написал бы я. Используется стэк близких мне технологий. Я каждый рабочий день с радостью погружаюсь в проект и пилю такси из джиры.
Но я не удовлетворен. Потому что у меня есть старая идея терраформинговой РТС, которую я иногда пилю потихоньку. Потому что мой дрифт-таз остро нуждается в электронных обвесах самого разного рода, которые я тоже с радостью делаю. НЕ говоря уж об умном доме, который каждый день ставит новые интересные задачи передомной.
Я удовлетворен своей работой, я на своем месте, но в свободное время я с удовольствием пилю самые разные вещи. Потому что если бы я тупо работал работу и больше бы ничего не делал — я бы очень быстро свалился в депрессуху. Потому что кровавый энтерпрайз лишь на 20% дает творчества, а остальные 80% — это нудная и тяжелая работа.
«Кровавый энтерпрайз» зачастую вознаграждает успешным внедрением и долгой продуктивной работой проекта в проме. Это ли не высшее удовлетворение для программиста? Пусть хоть на 100% тяжёлой нудятины, и 0% творчества, но зато сотни тысяч довольных кастомеров, которые заработали при его помощи немножко денежек. Много ли самопальных поделок могут похвастаться таким КПД?

Вопрос о системе ценностей, на самом-то деле.
Совершенно верно. Вопрос ценностей.
Я вот за творчество. А удовлетворение клиентов мне в целом побоку.
Поэтому в свободное время я творю. А вы, видимо, об удовлетворении клиентов думаете только во время работы.
Это я к тому, что ценности у меня одинаковые и на работе, и вне работы. А у вас раздельные.
Поэтому работодатели и хотят видеть энтузиастов своего дела на ответственных должностях. А не тех, кто о работе забывает сразу после 17:00.
Я в свободное время отдыхаю. Готовлю, смотрю кино, ремонтирую квартиру (капитально, с перепланировкой), читаю хабр. В рабочее же время (формально 40 часов в неделю, а по факту бывает и все 60 — ночерами я частенько работаю из дома по RDP) моим интересом является product delivery, то бишь, работа на благо клиента.

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

Но если ты будешь думать о деливери круглые сутки, свихнёшься. Лучше не надо.
Ну вот и я в свободное время отдыхаю. Пишу что-то на хаскеле, тыкаю в Idris, обмазываюсь C++17, читаю Шеня по логике и забыл какого чувака по формальной теории вероятности.
Когда-то, когда я был молод и меня на всяких собеседованиях спрашивали важно ли для меня работать в интересном проекте, с интересной командой — я всегда отвечал «да, конечно!». Мне это казалось правильным. Более важным даже, чем уровень оплаты.

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

Потому, что это и есть профессионализм. Ты делаешь то, что должен, настолько качественно, насколько способен. Каждый день. А интересно оно там мне или не интересно — клиента не должно заботить. Представьте, если бы вам хирург отказался проводить операцию, потому что «она какая-то скучная».
Когда человек решает встать на путь хирурга, то для него рутина (вскрывать фурункулы, вырезать панариции и прочее) — нормальное явление, которое даже во внимание не берется. Человеку интересен этот путь и этого достаточно, и ни у кого не возникнет даже мысли спросить у хирурга занимается ли он хирургией в свободное от работы время. А есть ли у него канал на трубе, где он выкладывает видео с препарацией африканских тигров клыком верблюда? И уж тем более никому в голову не придет не взять его за это на работу, потому что он «не увлечен». Однако почему-то внутри ИТ сообщества это нормальное явление.
Потому что один хирург, даже очень талантливый, не сможет прооперировать миллион человек. А один программист сможет написать утилиту, которой пользуется миллион пользователей.

Другое дело что часто и от людей, «лабающих» формочки для внутренних нужд компании в 10 человек применяется этот же подход…
Вот только от ошибки программиста вряд ли кто-то умрет в компании, а от ошибки хирурга — легко. Рука дрогнула и конец. Уровень ответственности несоизмерим!
Да, я рискую нарваться на минусы, написав такое, но почему-то внутри ИТ сообщества процветает зашкаливающее ЧСВ, поэтому им нужны печеньки, теннис, комната для подремать и прочие блага. По моему мнению — многие просто зажрались. Считают себя избранными, творцами и т.д., а остальные — быдло, даже другие программисты — тоже быдло. Бесконечные холивары и прочее. Это очень хорошо прослеживается на русскоязычных форумах, посвященных ИТ тематике. Каждый считает своим долгом облить оппонента грязью, ведь именно О-О-О-Н ЕДИНСТВЕННЫЙ все делает правильно, а остальным это недоступно по определению, и лишь единицы отвечают по теме вопроса. На буржуйских ресурсах я такого не встречал.
Я не раз сталкивался с таким отношением к себе всяких новичков, которые приходили на мое место. Я старался им все объяснить подробно, что и как, какие мелочи нужно помнить, но они слушали свысока, мол — давай, хватит уже, до свидания. Однако через время (месяцы) некоторые признавались (в переписке или при встрече), что зря меня не слушали и что я им действительно говорил по делу.
Почему когда кто-то пишет статью, обязательно найдутся такие, кто скажет — я даже не буду читать эту чушь и сразу ставит минус. Не нравится статья и ты уже знаком с этой темой — промолчи, пройди мимо. Но ка можно? Это ведь такая удачная возможность запустить грязью в кого-то. Откуда столько агрессии в наших людях?
>> рука дрогнула и все.
Ну, разве что речь о нейрохирургах. Да и то у нейрохирургов сейчас масса компьютерного оборудования с таким набором фантастических свойств, но все благодаря программам, блокирующие не только дрожание рук хирурга. Все стало слишком связанным…
А в остальном все верно. )))
От ошибки программиста в современном мире может погибнуть множество людей, начиная от пассажиров авиалайнера на автопилоте, заканчивая самоубийствами по причине утери денег впоследствии сбоя системы. Я уже не говорю о управляемых сердечних стимуляторах, в которых находят баги чаще чем очередный пациент их ставит. Но большинства программистов, меня в том числе, такой уровень отвественности не касается.
Но большинства программистов, меня в том числе, такой уровень отвественности не касается.

Вот! Это ключевая фраза! Мы же говорим об обычных людях, а не о тех единицах, которые пишут прошивку для кардиостимулятора или руля высоты.
Когда Буран, во время автоматического полета, при снижении вдруг стал набирать высоту, его хотели уже взорвать, как потерявшую контроль машину (но что-то их остановило). Оказалось, что он пошел на второй круг. Посадка в результате прошла успешно и позже выяснилось, что машина определила, что при таком ветре правильную посадку при движении по выбранной траектории выполнить не удастся и Буран пошел на второй круг, чтобы скомпенсировать ветер… Вот где верх мастерства! Когда я впервые услышал эту историю, мне захотелось снять шляпу и поклониться до земли этим программерам! Однако картинка вокруг выглядит так, будто каждый второй именно тот, кто писал автоматику для Бурана ну или как минимум написал бы ее без труда, если потребует Родина…
Однако что-то мне подсказывает, что эти «Бурановские» программеры с виду совершенно обычные ребята, у них нет профиля на Хабре и Гитхабе и нет пафоса. Поговорив с ними никогда не догадаешься, что это были именно они!

Дико извиняюсь за некропостинг, но не смог пройти мимо. Отвечу с точки зрения врача — еще как спросят!
Сейчас от хорошего доктора при трудоустройстве треьуется не только подтверждение квалификации, но и раскрученный аккаунт в соцсетях и пул пациентов.
Особенно это проявляется в "продающих" специальностях, типа дерматолога, стоматолога, пластического хирурга, но постепенно расползается на все.
Про обучение в свободное время уже даже не обсуждается — узаконено и обязательно для всех врачей причём в очном и платном формате. И это мировой тренд.

А удовлетворение клиентов мне в целом побоку.
Я бы вас не взял на работу.

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

Поэтому работодатели и хотят видеть энтузиастов своего дела на ответственных должностях. А не тех, кто о работе забывает сразу после 17:00.
Работодатели хотят видеть энтузиастов, потому что им можно меньше платить. Но не на ответственных должностях. Точнее, работодателю выгодно приложить усилия, чтобы энтузиасту его должность казалась ответственной — так он будет еще больше работать.

Но еще есть в мире компании, где нужны сеньоры. Там не нужен энтузиазм, а нужно ответственное отношение к деливери и способность принимать верные решения и делать задачи с срок. Это настоящие ремесленники, знающие свое дело, и получающие удовольствие от создания успешного продукта, приносящего прибыль компании и пользу заказчику, а не от какого-то воображаемого «творчества». То, о чем говорит PastorGL и чего вы (пока) не понимаете. Эти ребята уже слишком позвзрослели и обрасли цинизном, чтобы работать на одном «творческом» энтузиазме.
Не понимаю, за что вас минусуют. Совершенно взрослый взгляд на наше ремесло.
Ну так здесь же не только взрослые.
UFO just landed and posted this here
Не взрослый, а скорее старый, в значении «устаревший». И пусть у каждого есть свой путь восприятия своей деятельности, но навязывать это как одно из возможных «высших удовлетворений программиста» по крайней мере не очень красиво. В реальности почти весь этот «кровавый энтерпрайз» сводится к мертворожденным проектам, единственная цель которых для бухгалтерии свободно переносить B2B денежные потоки в B2C русло и обратно. А сами проекты делают счастливыми кастомеров по принципу «сначала меня заставили им пользоваться, но он даже не работал! потом починили — ну теперь хоть жить можно!», и вот это «жить можно» и становится высшим удовлетворением большинства компаний, которые глубоко в этом сидят. Обычно их взаимодействие довольно интегрировано, к тому же. Так что если бы «кровавый энтерпрайз» вообще бы исчез, внешний мир бы этого не заметил.

Так вот работа, работа — она не такая, работа и правда должна приносить удовольствие, а не его навяызвать, а уж тем более, навязывать (ложные) идеи удовольствия.
Осталось только вам найти друг друга — работодателя и соискателя с общими взглядами.

Насколько было бы удобнее, если бы в описании вакансии прямо было сказано: большой гитхаб-профиль обязателен, или наоборот, opensource-контрибуторам просьба не обращаться.
Такие находятся.

Насчёт вакансии, это неэтичная формулировка, нельзя так писать.

Если взять ваш довод за основу, то м.б. как раз у вас такому товарищу будет интереснее?

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

Ищете тех, кто готов работать на вас по 16 часов в сутки?
А если у программиста силы на семью и детей, или, не знаю, каякинг остаются, он тоже недозагружен?
Почему по 16? Я после 8 часов не испытаваю никакого желания садиться дома опять за компьютер и кодить, наполняя гитхаб (ведь не в рабочее время этим заниматься?). У меня есть куча других, не менее интересных и важных дел и нет времени на собственные проекты. Когда мне было 20-25 я тоже сидел ночами и кодил ради фана, а сейчас приоритеты поменялись.
Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет заниматься другой работой бесплатно вместо того, чтобы провести время с семьей?
Почему по 16?

Потому что речь шла об отсутствии времени, а не желания.

Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет заниматься другой работой бесплатно вместо того, чтобы провести время с семьей?

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

Да и никто ни от кого ничего не ждёт. Просто тот человек, который сидит и кодит вечерами ради фана, имеет в среднем больше конкурентных преимуществ.
10 часов на работу (включая дорогу), 8 на сон, 2 на еду и мыльно-рыльное, 4 на семью и хобби. И где взять время на гитхаб?

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

>Просто тот человек, который сидит и кодит вечерами ради фана, имеет в среднем больше конкурентных преимуществ.
Это заблуждение.
10 часов на работу (включая дорогу), 8 на сон, 2 на еду и мыльно-рыльное, 4 на семью и хобби. И где взять время на гитхаб?

Ну вон же у вас 4 часа в том числе на хобби. А ещё и выходные есть.

У меня 8.5 часов на работу (включая дорогу), 7 на сон, час на еду и мыльно-рыльное, остаётся много.

Не надо заниматься подменой понятий. Читая статьи, код на гитхаб не выложишь.

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

Это заблуждение.

Опять же, почему, если у него больше практики и больше шансов познакомиться с новыми инструментами?
4 часа на хобби, на гитхаб времени нет. Вы вообще читаете, что вам пишут или у вас монолог?

Ну так и не занимайтесь подменой понятий

Всего вам хорошего. Общаться с демагогом не имею желания.
4 часа на хобби, на гитхаб времени нет. Вы вообще читаете, что вам пишут или у вас монолог?

Значит, программирование для вас не хобби. Бывает. Ничего в этом плохого нет, в общем, и вы вроде не жалуетесь (тут никто особо не жалуется, кроме автора переведённой статьи).

Всего вам хорошего. Общаться с демагогом не имею желания.

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

Значит, программирование для вас не хобби


Извините за вопрос, Вы — идиот? Или просто тролль?


У меня есть хобби — и оно программирование, и оно опенсорс, но гитом я не пользуюсь, НЕ ОБЯЗАН!

Можно глупый вопрос? Почему?

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


Ровно также, как и житель страны 3 мира, нашедший себя на помойке, имеет преимущество при получении работы перед жителем страны 1 мира, которому и страховки, и кредиты, и детей в университеты отправлять надо.
Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет заниматься другой работой бесплатно вместо того, чтобы провести время с семьей?

в точку
Ну ок, я прошёл курсы программирования на Coursera, получил свои не то 95%, не то 98% за курс, и написал после этого небольшую игру с использованием пройденного языка программирования.
А теперь вопрос — кому она на этом самом GitHub нужна?
А если не на гитхаб, то куда выкладывать? В google play после переделки под Android?
Или всю папку игры слать как образец кода? Или класс из неё?

И второй вопрос — а если я разработчик баз данных / кубов, то тогда что слать?
UML, ER, любая_ваша_нотация-диаграммы. Инфологическую модель БД (хотя бы самый сок).
Самому себе она на гитхабе нужна. Я много чего храню на гитхабе, банально, как бекап. А если кто-то увидит что-то на моем гитхабе и у него случится рвотный рефлекс от плохого кода — так это его проблема.
Просто гит удобен для ведения разработки и даже не только кода. Можно откатиться, можно разные ветви развития впилить. Я может быть и хранил всё на личном закрытом гит сервере. Но правда в том, что никому ж дела нет до того, что у тебя там лежит, даже если оно открыто.
А конкретно гитхаб. Я раньше хранил проекты на google code. Так вот даже они закрылись. Что говорить про личные какие-то серваки, которые живут год-два. И всё на помойку улетает. А тут хоть шанс есть, что кому-то что-то и прогодится. Кто-то время жизни сэкономит
Многие мои знакомые (и я тоже) используют для этих целей bitbucket. Даже некоторые небольшие комманды используют. Очень удобно и бесплатно. Понадобилось на работе какую-нибудь фичу добавить, а я её раньше на своём проекте делал — зашёл через браузер и посмотрел вместо того чтобы опять тратить кучу времени на гуглёж. При этом репозитории приватные и можно не стыдиться за код, который местами не оптимален.
А если вдруг понадобиться на собеседовании свой код показать, то можно просто открыть доступ только потенциальному работадателю, а не на весь интернет.
Что постыдного в своем коде? По-моему пахнет каким-то пуританством.
Вот тоже так думал, ну потом подумал, а почему бы и нет, чем вред нахождение на гите? Кто увидел — то это его проблемы, кто нет, ну он и не узнает. Правда… у меня GIT теперь содержит софт для закачки музыки с одного сайта, что не совсем законно, ну опять же кто увидит?
Я тоже с недоверием отношусь когда гитхаб у разработчика пустой

А почему все ОБЯЗАНЫ писать на гитахбе?
У меня что не может быть иного хобби кроме гитхаба?!


PS то чем я занимаюсь, когда у меня на это есть время и настроение http://www.moddb.com/mods/wolfgl-3d — это проект с открытым кодом, и его на гитхабе нет.

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

Проблемы начинаются, когда другие работодатели увидев, что-то кто ФОРСИТ гитхаб (или иную модную штучку), начинают делать из него Культ Карго.

Гитхаб — это модно стильно молодежно. Не думаю, что работодатель откажет только потому, что хотел увидеть проекты (PR-ы, коммиты) на гитхабе, а ему дали ссылку на профиль на gitlab или bitbucket, или, ну худой конец там google source или source forge.
Вы не поверите, но проблемы начинаются, когда делают карго-культ. А уж ИЗ ЧЕГО его делают — неважно.
Статья отличная!
Поддерживаю.

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

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

Видимо, на рынке много непрофессионалов и джуниоров, поэтому так и происходит.
Непрофессионалов много во всех сферах. Просто программисты изначально сами себя так поставили. В какой еще профессии вы найдете столько людей, готовых работать за еду ради первого опыта, перерабатывать десятки часов в неделю бесплатно и тому подобные вещи? Нигде больше нет таких людей, вот на них и ездят. А человек, который ценит себя и старается работать по ТК уже воспринимается каким-то неадекватом и белой вороной в коллективе.
У врачей подобные проблемы тоже есть (с переработками)

Что? Может в пост СССР какая-то альтернативная реальность, в Израиле наоборот, только программисты могут позволить себе ставить условия труда как у госслужащих. Адвокаты пашут по 12 часов в сутки, иначе не жди карьерного роста (а первая работа с зарплатой уборщика), бухгалтеры сидят по 10 лет в одном офисе, где им совсем не нравится, просто потому, что иначе на новом месте себя надо будет опять годами доказывать. Что уж говорить о профессиях попроще. А на разработчиков такой спрос, что они могут сказать "больше 9 часов работаю только в случае ЧП". И первая зарплата студента после окончания учебы уже как средняя по рынку (если бывший студент кончено не штаны просиживал, иначе эту работу найти будет очень трудно).

Ну у евреев все не как у людей (шутка). Если глянуть даже не в пост-СССР, а, например, в Мекку программирования и всего такого — Кремниевую долину, то по многочисленным статьям и новостям оттуда можно заметить, что работники овертаймят иногда на целую рабочую неделю, а если так не делать, то отсутствие карьерного роста будет наименьшей из проблем. И вся эта ситуация постоянно культивируется руководителями компаний (тем же Маском, например), мол «смотрите, как это так, я работаю по 18 часов в день, а вы хотите свои 8 и еще отпуска какие-то. Мы инновационная компания или где?» И постоянно давление со всех сторон и никто не хочет ничего с этим делать. А народ туда прет и готов жить на работе (можно почитать статьи про Palantir, например) за среднюю, в общем-то, по местным меркам зарплату, лишь бы быть причастным к этому всему. И на них ездят, ездят как могут и выдавливают из них все, а потом десятки статей на Reddit и Medium в стиле «Как я выгорел на работе, программируя по 25 часов в сутки последние 3 года». Это нездоровая фигня, с ней надо бороться и я рад, что есть места, где это получилось.
Это нездоровая фигня, с ней надо бороться и я рад, что есть места, где это получилось.

Эффективно бороться с этим можно только на уровне государства. И события 100лет назад как раз прекрасное напоминание о том, что и как надо делать, если хочешь отношения к себе как к человеку, а не к бесправному скоту. Ибо бизнес чем крупнее, тем менее договоропригоден без ствола в пузо.
Мне нельзя отвечать на такие посты на хабре, мне нельзя отвечать на такие посты на хабре, мне нельзя… а черт, все равно не удержусь...
Отнять и поделить, поставить за руль Швондера кухарку — стратегия приводящая к предсказуемому результату.
Но раз уж пост у нас менеджерский, то давайте порассуждаем.
Есть такая легенда, что в одном ВУЗе студенты достали одного препода своими рассуждениями о крутизне социалистической модели общества, и он наглядно объяснил им в чем суть. Он объявил о том, что вся группа будет получать одинаковые оценки за контрольные, а именно среднюю арифметическую от всех.
На следующей контрольной все сдавали как обычно — троечники на тройки, отличники на пятерки, хорошисты на четверки. И все получили четыре.
К следующей контрольной отличники уже не так тщательно готовились, ведь пятерку все равно не получить, да и троечники расслабились. В итоге все получили тройбан. На третий раз результат был закономерен. Пара да. И все естественно попросили вернуть «капиталистический» вариант оценок.
Теоретический разбор данной притчи приводит нас к ошибочному выводу — «а вот если бы они скооперировались, и отличники стали бы помогать двоечникам...». но нет. Двоечникам много не надо. Им бы тройку. Они и рады помочь отличникам, но лишь чтобы до тройки дотянуть. Вытянуть троечников на четверку — дохлый номер. Как троечник говорю. У нас в школе было шесть «четвертей» и после каждой считали рейтинг. Если я слишком хорошо учился, то в следующей части я расслаблялся, чтобы больше времени оставалось на чтение того что мне нравится и т.п. Не уговорить меня было бы… Так что из-под палки, если бы не вернули «капитализм» можно было бы выжать максимум троечку. Ну а если взять сферических учеников, которые ну очень замотивированы и способны «подтянуть» троечников, то… что им мешает делать тоже самое в «капитализме»?

На практике единственный минус рыночно-капиталистического подхода к управлению (любому) — монополизация. Однако в данном конкретном случае, а именно в вопросах ценообразования зарплат в сфере ИТ монополизм невозможен, поскольку если вам платят меньше чем вы стоите то вы легко организуете собственный стартап, возьмете самых классных спецов (ведь картельный сговор конкурентов не дает им платить нормальные зарплаты, а вы сможете), и цены сразу выровняются. Для програмистского стартапа надо очень мало — хорошая команда, хорошая идея и т.п. Не нужны баснословные вложения как в медицине или электронике. Не нужны глубокие связи как у оборонки. Все что нужно это голова. Так что тут монополизм не опасен.
Государство по сути это и есть очень крупный бизнес. Решать проблему нескольких крупных корпораций одной огромной монополией не очень разумно. Кстати, тот самый пример 100 летней давности это показывает.
Зависит от того, в чьих интересах монополия — труда или капитала.
Монополия всегда существует только в своих собственных интересах.
Монополия будет работать в интересах того кто будет ею управлять.
Миф о классах забавен, но не более.
Капиталист за рулем корпорации работает не в интересах некоего «класса» капиталистов а в своих собственных. Т.е. в интересах одного конкретного капиталиста. Соответственно кухарка во главе государства будет действовать не в интересах всех кухарок в мире а в интересах одной конкретной кухарки. Ну а дальше уже по цепочке разваливается и весь миф.
Водопроводчиков часто нанимают обычно по рекомендации, друзей, знакомых, которые недавно делали ремонт. Несложно найти отзывы о проделанной работы. При серьезных работах оформляется договор, в котором прописываются штрафы, за некачественную работу.
Сантехника не тестируют, потому что у нанимателя квалификации нет. А если сами сантехники к себе в бригаду нанимают, то обо всем спросят.
Да, все верно — тут вопрос уже переносится в область «доверяешь ли ты бригадиру или нет», а бригадир, в свою очередь, чтобы не потерять клиентов, борется за качество и дрючит сантехников :)

Следовательно — надо попробовать посмотреть на два носа вперед, прежде чем сделать вывод, когда тебе кажется, что в другой профессии как-то проще. (это уже не вам, а так, просто)
С сантехниками проще, потому что ему доверяют трубу и даже если будет протечка, то можно все же устранить, пусть и руками другого сантехника. А вот программист как архитектор, который проектирует дом. И если он зальет слабый фундамент, не по уровню, использует не ту марку цемента, то дом покосится, треснет, рухнет и фундамент так просто не исправишь. Нельзя просто так взять и заменить фундамент, когда на нем стоит дом, а трубу — можно. Можно даже дорогу перекопать, заменить трубу и закопать назад, а дом не сломаешь, ибо в нем уже люди живут.
С программистами действительно беда, потому что приходят ДЕСЯТКИ людей и не могут решить элементарную задачу, в которой не требуется знаний каких-то протоколов или технологий — банальная задача на смекалку, а ее нет. А если грунт нестандартный, как ему доверить фундамент?
Хотя и з/п очень даже хорошая, но лишь 1 из 10 решает задачу правильно и в срок.
Вас не умиляет, что можно купить автомобиль и разобрать его до винтика и никто за это слова не скажет, а вот купить программу и дизассемблировать (не модифицировать, а просто посмотреть) — нельзя, копирайт, лицензия! Можно учить наизусть, переписывать в тетрадку стихи Пушкина и воспроизводить бесконечное число раз со сцены для миллионов ушей, а вот музыку копировать нельзя и кино тоже — копирайт, лицензия! Или Пушкин был опенсорсником?
Можно учить наизусть, переписывать в тетрадку стихи Пушкина и воспроизводить бесконечное число раз со сцены для миллионов ушей, а вот музыку копировать нельзя и кино тоже — копирайт, лицензия! Или Пушкин был опенсорсником?

Нет, у него просто срок авторского права давно истёк.
Музыку Моцарта и Баха — Вы можете свободно копировать в виде нот, и фильмы Чарли Чаплина — тоже можно свободно копировать.


Вас не умиляет, что можно купить автомобиль и разобрать его до винтика и никто за это слова не скажет

На Гиктаймс была тема про трактор защищённый копирастами от нелицензированной разборки, и то как судили фермера починившего свой трактор.
А ещё, была новость про то как Apple пытается продвинуть законы запрещающие нелицензированно чинить их телефоны под страхом уголовного наказания.

ну абсурдное сравнение же: совсем не тот уровень последствий, затрат, интеллекта, доступности, вовлеченности
Хорошая статья, сам недавно писал примерно на эту же тему.

Согласно логике таких работодателей, после 10 часов написания кода (а также документации, сравнительных исследований платформ и библиотек, и т.п. фигни) на работе, я должен ещё и дома код писать, чтобы мне было что показать им? Причём, мне обязательно необходимо участвовать в опенсорсе?

Н-да. Но, пожалуй, нет.

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

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

Дело вовсе не в том, что надо в чём-то обязательно участвовать. Это получается само собой — при определённом подходе к работе. И, соответственно, наличие PRов в сторонние библиотеки и собственных проектов служит индикатором этого подхода к работе. А подход очень простой:


  • Сейчас практически не существует проектов, которые не используют сторонние опенсорсные библиотеки/утилиты. А когда используешь что-то в таких количествах — обычно сталкиваешься с проблемами. И при наличии достаточной квалификации нередко проще решить проблему самостоятельно — форкнув и пофиксив что нужно. Мы все это постоянно делаем. Вопрос в том, что будет сделано дальше: будет ли этот фикс правильно оформлен и отправлен PRом в оригинальный проект? Компании тратить на это свои ресурсы выгодно по ряду причин (качество фикса/фичи увеличится если её отревьювит автор проекта, а главное дальнейшая поддержка этого изменения будет на авторе, а не на нашей компании). Так что если этого не делается, то либо изменение кривое и вы заранее знаете, что автор его не примет, либо не хватает квалификации корректно его оформить (угу, дока, тесты, кодстайл — всё это действительно необходимо для дальнейшей поддержки этого изменения, кто бы ей не занимался), либо не хватает ума объяснить начальству почему компании это выгодно (и не хватает ума работать в компании, в которой это и так понимают). И какова бы не была причина — в любом случае это минус лично Вам.
  • При правильной декомпозиции в большинстве задач возникают небольшие универсальные кусочки, не связанные с бизнес-логикой текущего проекта. Если такие куски не оформлять полноценными библиотеками, с докой и тестами — этот код быстро загниёт и не будет повторно использоваться даже в проектах этой же компании, так что нормально оформлять эти библиотеки компании выгодно. А дальше их можно выложить в публичный доступ — выгода от этого для компании уже не столь очевидна, но она есть — плюс в карму, больше привлекательности для сильных разработчиков работать в этой компании, возможность дополнительно пиариться на этих проектах, и если эти проекты заинтересуют кого-то ещё то сторонняя бесплатная помощь в развитии этих проектов, … (здесь троеточие не потому, что больше нечего добавить, а потому что многое зависит от специфики и размера компании — например когда крупная компания выкладывает свои инструменты/фреймворки в паблик у неё появляется возможность со временем нанимать людей уже знакомых с используемыми в компании инструментами/фреймворками). Отсутствие же таких проектов говорит либо о том, что у вашей компании проблемы с корректной декомпозицией или оформлением библиотек, либо о том, что компания пока не доросла до осознания пользы от выкладывания таких проектов в паблик. В первом случае это минус и Вам, во втором нет, но… как говорится, серебряные ложечки нашли, но осадочек всё-равно остался.
Сейчас практически не существует проектов, которые не используют сторонние опенсорсные библиотеки/утилиты. А когда используешь что-то в таких количествах — обычно сталкиваешься с проблемами.
Мне кажется, это не везде так. Я в последние годы работаю в крупных компаниях, над крупными проектами (1kk+ LOC). Да, в каждом проекте используются какие-то сторонние библиотеки, но, во-первых, своего кода гораздо больше, чем стороннего, а во-вторых, лишь очень малая часть этого стороннего кода используется повсеместно — большая его часть скрыта под внутренними обертками, с которыми работают лишь соответствующие команды.
Итого: пока все работает нормально, я вижу сторонние библиотеки только в виде вызовов API, причем лишь наиболее известных его частей. Ситуаций, когда что-то вроде boost::iterator_facade работает неверно, пока что не было. А исправления во внутреннем SDK на GitHub не выложишь.
По-моему опыту компании не парятся из-за таких вещей, ибо вкладываться в поддержку и тесты нужно сейчас, а профит будет когда-то потом при переиспользовании. А может и не будет.

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

Да, вкладываться в поддержку/доку/тесты нужно сейчас. Вне зависимости от того, планируется ли выкладывать этот код в опенсорс. Но дивиденды будут не когда-то потом, а практически сразу же — при дальнейшей отладке и поддержке этого кода. Не существует выбора между "тратить время на тесты" или "не тратить время на тесты" — на самом деле это выбор между "тратить время на отладку" или "тратить время на тесты", и последнее обычно значительно выгоднее.


Всё это можно не делать только в одном случае — если данный код планируется запустить один раз (вариации — использовать его ближайшие несколько дней), после чего выкинуть. Если же код потребуется в будущем поддерживать или развивать или повторно использовать — дока и тесты (в разумных объёмах, конечно же) сэкономят ресурсы компании, а не растратят их. Максимум — можно отложить написание доки до момента, когда потребуется объяснять работу этого кода новому сотруднику, а написание тестов до момента, когда потребуется этот код отлаживать/фиксить/развивать. (Но откладывать — не очень хорошая идея. Потому что доку проще и быстрее написать пока код в голове, желательно даже до написания кода, а не когда он кому-то понадобился через три месяца. А тесты морально намного проще писать небольшими кусками, по мере написания кода, а не одним героическим рывком покрывать весь код спустя месяцы.)

Ну, возможно у вас очень понимающий менеджер, который любит красивый код.

Там, где я работал, обычно пилятся фичи по принципу «Работает — не трогай». Модуль пишется один раз, и после этого подвергается минорным доработкам. После этого фичи релизятся и проводится большой регресс по всему функционалу продукта. После чего всплывающие баги фиксятся уже в релизной ветке, которая после прохождения QA попадает в прод.

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

А Вы начните отдельно считать абсолютно всё время, которое уходит на отладку/поиск и исправление ошибок, плюс время потраченное на дополнительные перепроверки после исправления ошибок тестировщиками во время этого большого регресса. А потом сравните его с тем, сколько бы заняло написание юнит-тестов, которые бы позволили практически все эти ошибки найти и исправить ещё в процессе разработки (причем исправить намного быстрее, потому что во-первых очевидно что ошибка в только что написанном коде и во-вторых потому что этот код ещё в голове и в-третьих потому что можно не сильно беспокоиться о том, что может сломаться в других местах из-за исправления ошибки потому что это моментально поймают юнит-тесты). Обычно на юнит-тесты уходит примерно столько же времени, сколько на код, который они проверяют. Так что если на всё вышеописанное у Вас уходит больше времени — то писать тесты выгоднее уже прямо сейчас.

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