Comments 757
Это фиаско, братан.
А вообще в любой либе бывают баги. И если они фиксятся с твоего пулреквеста, то это ачивка. Но если ты суровый Энтерпрайз, то...
Ну и кроме того, далеко не всегда удаётся все интересные эксперименты по новым фреймворкам-либам-языкам-технологиям-принципам поставить за деньги работодателя в оплачиваемое время.
А вообще речь не только про IDE. Думаю, если я работодателю скажу, что в свободное время почитаю Пирса-Шеня-Голдблатта, это тоже будет плюсиком мне в моей сфере деятельности.
Но вот у меня, так же как и у автора статьи, есть другие хобби и увлечения, не очень связанные с разработкой. И вот в субботу мне приходится делать тяжелый выбор между маунтин-байк покатушкой, тренировкой по скалолазанию, фото-вылазке в осенние леса, подготовкой фото и написанием текста в блог — или IDE. А еще же надо книжку почитать. И уделить внимание семье. И друзьям и социализации. Плюс при наличии детей время, доступное для хобби, уменьшается примерно в два-три раза. Ну вот и что мне выбрать?
Возможно, вы лучший и более увлеченный программист чем я, потому что в выходные вы можете посвятить себя хобби программирования. Я ничуть не иронизирую, это прекрасно! Я даже немножко завидую :-)
Мне в своё время приходилось выбирать между всякой социализацией-гитаркой, скажем, и обучением в вузе, самообразованием и подработкой (есть-то хочется). Отказаться пришлось от первого, а с тех пор уже как-то по накатанной пошло :)
И я более того скажу, далеко не у всех есть достаточно знаний, чтобы «Сидеть, ковыряться за бесплатно в чужом коде»
В нынешнее время почти любой человек может взять и начать коммитить.
К примеру можете взять даже меня. Сразу скажу, я — не программист. Это даже не побочная мне сфера деятельности (всякие скриптики для облегчения жизни — не в счет). Так вот, у меня есть немного ПРов на Гитхабе в проекты, которые не то что мне близки или я в них разбирался бы… Я даже ЯПа, на котором они написаны — не знаю.
банально перед кем-то козырнуть
вы в исправлении бага в чужом проекте только это видите?
Это инвестиция в свою ценность перед работодателем. Но это многоходовочка, которая не каждому...
Иногда не остаётся выбора кроме как чинить баги в чужих проектах, поэтому что эти чужие проекты используются в своих.
Ну да, ваше желание кому-то помочь ещё не означает, что вы должны делать это в стиле тяп-ляп. Помогите действительно нормально всё что надо было сделать — это в общем-то и не смертельно, и опять же показатель вашей ответственности и усердия. А спотыкаться на такой глупости, что ты 2-3 строки кода оформил не по их дизайну и тебе лень их поправить — что делается за несколько секунд — говорит о том, что вы просто ищете повод для оправдания своей лени. Для меня это например уже сигнал для того чтобы задуматься, если ли смысл с вами работать, к примеру?
Не оформил по стандартам — переделай.
Лень переделать… Лень читать стандарты… и так сойдет?
Вот нафиг ты мне такой нужен?
Дешевле и эффективнее взять того кто в чужой монастырь приходит соблюдая устав.
Пока ты не способен играючи, не тратя лишнего времени оформлять правильно пулреквесты — ты нуб, и цена тебе как любому юниору.
И дело даже не в том что ты их не делаешь.
Дело в том, что ты не понимаешь почему их надо делать «правильно» а не как бог на душу положил.
Значит ты еще зеленый.
Если ты не делал коммитов в чужие репы, не запускал собственных пет-проектов, то… у тебя банально очень мало опыта. Не в часах, а в кейсах. В командной работе и т.п.
Не в обиду. В контексте командной работы мне самому опыта не хватает. Просто показатель уровня. Объективно.
.editorconfig
или в крайнем случае CODESTYLE.md
, а соблюдение его же — в выполнении перед коммитом какого-нибудь make lint
или npm test
в зависимости от.Я неделю думал как выдать за фичу исправление бага — но так не придумал.
Вот он: github.com/hazzik/DelegateDecompiler/pull/53
А это чем-то плохо? Если принято решение использовать некоторый проект — значит, его текущая функциональность нас устраивает. В таком случае даже если он накроется — старая и проверенная версия этого проекта никуда не денется.
Если же неожиданно всплывет какой-то баг — его и самому починить можно.
Ты нормальный, разносторонне развитый человек, а не стереотип из картинки:
i.work.ua/fun/1354.jpg
Я работодатель. Ну или HR, или нач.отдела куда берут человека и участвующий в собеседовании. Не суть.
Мне нужно взять человека на вакансию тыжпрограммиста.
Здесь есть три варианта:
1) я беру стажера/юниора/эникейщика, который будет выполнять простую работу, и возможно расти в моей среде (возможно нет). В таком случае вполне достаточно стандартных вопросов на знание, и нестандартных заданий на смекалку и проверку некоторых психологических характеристик. Если у человека есть гитхаб с пет-репами, и/или коммитами в чужие репы, то это будет плюсом, но в целом я и так все вижу по нему за первые две минуты общения.
2) я беру зрелого разработчика способного вести участок который ему выделят и соблюдать корпоративные стандарты или даже легаси-стандарты конкретного проекта. В целом это «рабочая лошадка» бизнеса. Человек который выполняет объем работы. От него требуется определенный уровень квалификации, определенный уровень деловых качеств, и определенная степень… стандартности. Нет, ну правда. Если каждый мидл будет подстраивать под себя корпоративную среду, то нафига такой мидл нужен? Я лучше завезу побольше печенек, чем буду иметь проблемы с проектом когда он уйдет. Ничего личного, просто бизнес. Юниор либо неработопригоден, либо впитывает культуру и прочий контекст вместе с знаниями. А вот мидл… Мидл может быть прожженым индивидуалистом. Может писать самостоятельно большие и сложные вещи, но после него их будет проще переделать с нуля. И как мне это узнать? Задать пару простых заданий? Ну задал. Ну вроде понимает, вроде пишет. Вроде читает. Но как он будет вести себя с чем-то покрупнее чем хелловорд и прочие пузырьковые сортировки? Вариантов собственно не так много — посмотреть что он умеет в его гитхабе. Дать тестовое задание домой, на пару дней (не оплачиваемое, ага) и взять на стажировку и платить ему зарплату, и приглядываться к нему… Ну или есть четвертый вариант — «мы с вами свяжемся, если вдруг двадцать других претендентов тоже будут без гитхаба».
3) нанимаем звезду/сеньора. Тут у меня меньше возможностей сказать «следующий». И скорее всего я пойду на более дорогой вариант с стажировкой или еще чем-то подобным. Может более долгие многораундные собеседования и т.п.
Итого — если у тебя нет гитхаба и пет-проектов, то ты обходишься мне дороже. Значит ты должен меня чем-то привлечь чтобы компенсировать эти лишние расходы. Например я буду платить тебе меньше зарплату. Или у тебя очень крутые рекомендации или опыт работы (кода твоего я не видел, но знаю что ты работал ведущим разработчиком в серьезном проекте). Или ты готов писать большое тестовое задание бесплатно, или месяц стажироваться без зарплаты или ты сын моей любовницы, или что-то еще.
С этим никто не спорит, естественно, человек с хорошим аккаунтом на гитхабе, обойдется дешевле, т.к. ему можно платить меньшую зарплату за тот же уровень квалификации. Работодатель ведет себя, безусловно, правильно — так, как ему выгодно. Неправильно ведет себя в данном случае работник, который терпит подобное отношение к себе со стороны работодателя.
То есть, еще раз: то, что работодатели просят показать гитхаб, это все хорошо, т.к. это просто способ сэкономить на зарплате при прочих равных. На черта нужен начальник, который не захочет в таких условиях сэкономить? Он дурачок что ли?
Неправильно то, что сами программисты это поддерживают — то есть, фактически, занижают свою ценность как специалистов (вместо того, чтобы наоборот повышать).
Итого — если у тебя нет гитхаба и пет-проектов, то ты обходишься мне дороже. Значит ты должен меня чем-то привлечь чтобы компенсировать эти лишние расходы. Например я буду платить тебе меньше зарплату. Или у тебя очень крутые рекомендации или опыт работы (кода твоего я не видел, но знаю что ты работал ведущим разработчиком в серьезном проекте). Или ты готов писать большое тестовое задание бесплатно, или месяц стажироваться без зарплаты или ты сын моей любовницы, или что-то еще.
И вот эта вот неспособность услышать оппонента она очень сильно показывает вашу низкую квалификацию. Сегодня вы не слышите меня на хабре, придумывая понимание моих слов под свое видение, завтра вы не услышите коллегу, послезавтра будете доказывать клиенту что он верблюд. Проверенно. лично вы в принципе неработопригодный человек. И это не вопрос гитхаба или еще чего-то. Т.е. Майоров с которого начался этот тред — выйдет дороже другого специалиста, лично мне не подойдет поскольку у нас слишком разные взгляды на многие принципиальные вещи (не только тут, а вообще так сложилось по факту общения), но другому работодателю вполне может быть идеальным. А вот вы — неработопригодный. И мне жалко ваших работодателей (хотя возможно они этого заслужили).
И да, отвечая на вопрос уважаемого Idot — пет-проекты про рыбок и кликеры мне дадут много информации в вашу пользу. Способность понять задачу (даже если это своя собственная задача), знание технологий (даже если речь про банальные SOLID/DRY/MVC поскольку все остальное у вас в работе другое) и т.п.
А слова «ну это было давно» или «я пока еще не добрался до того чтобы придать этому божеский вид» вполне себе покажут что это не лучшее на что вы способны.
Впрочем отсутствие не скажет что вы непригодны, но усложнит возможность разглядеть ваши достоинства. Так зачем же усложнять работодателю увидеть ваши плюсы?
Я это видел. Вы написали неверно. Конкурентное преимущество человека с богатым гитхабом в первую очередь именно в том, что ему можно меньше платить.
> И вот эта вот неспособность услышать оппонента она очень сильно показывает вашу низкую квалификацию.
Я вас прекрасно услышал, а вот вы сделали поспешный вывод из неполных данных.
> Так зачем же усложнять работодателю увидеть ваши плюсы?
«Плюс», заключающийся в готовности работать за более низкую плату — является плюсом для работодателя, но никак не для работника. Работнику, определенно, следует демонстрировать те плюсы, что повысят возможную зп, а не наоборот. Человек, который хвалится своей увлеченностью, и тем, что работает за бесплатно — объективно снижает ценность своего труда.
У работодателя нету задачи поставить вам ту зарплату, которой вы объективно стоите, у него задача поставить вам такую зарплату, за которую вы готовы эффективно работать. И если вы готовы работать за меньше, чем стоите — то работодатель, безусловно, будет очень доволен.
Я это видел. Вы написали неверно. Конкурентное преимущество человека с богатым гитхабом в первую очередь именно в том, что ему можно меньше платить.
Я то ли нить потерял, то ли не понял. В общем, откуда это следует-то, что ему платить можно меньше?
Не знаю, как это должно выглядеть… Ну, предположим, 8 часов за Х денег и 4 часа опен-сорса за 0 денег. Таким образом, человеку можно платить (Х+0)/12. Druu у вас такая арифметика?)
Оттуда, что он меньше потребует за свою работу. Человек, который настолько увлечен Х, что готов заниматься им бесплатно, всегда в среднем будет готов делать Х за сумму меньшую, чем человек, которому Х нравится не настолько сильно.
Я увлечён программированием графики и занимаюсь этим забесплатно, но х… х-х… хрен я буду заниматься программированием баз данных забесплатно.
Здесь мы возвращаемся к интерпретации. Если человек просит вас показать код, именно чтобы посмотреть код (оценить его качество) — его вполне устроит ваш гит с графическими проектами (равно как какой-нибудь очередной туду-лист или ваше старое тестовое задание), это все вполне нормально, тут на самом деле нету требования к наличию стороннего проекта — тут есть требование к демонстрации кода.
Если же он спрашивает с целью сесть на шею — то будет просить код именно по близкой к рабочей тематике.
Мы обсуждаем именно второй вариант, Х из поста выше — это то, чем вы будете заниматься на работе.
1) Ты все равно будешь отвлекаться. Разработка того что нужно, а не того что хочется — утомляет.
2) Вместо того чтобы в это время сидеть на кухне и поедать халявные печеньки ты развиваешься, а значит будешь писать лучше и быстрее.
3) Когда аврал чаще всего можно избежать овертаймов, просто отложив пет-проекты на время дедлайна и получив +20% к эффективности. А ведь овертайм не просто лишние расходы на его оплату, но и значительное падение производительности труда (как в овертайм, так и после выхода из дедлайна).
Из минусов тут только сложность в организации рабочего процесса так, чтобы не было проблем с переключением внимания и т.п.
Конкурентное преимущество человека с богатым гитхабом в первую очередь именно в том, что ему можно меньше платить.Это что еще за демагогия в стиле «белое — это черное, война — это мир»?
Кому-то стоит вспомнить про то, как работает капитализм. Если вы требуете от разработчика чего-то дополнительно (неважно чего — кода на гитхабе или умения вышивать крестиком в арктическом походе), то пул возможных кандидатов снижается и цена рабочего времени растёт…
Другое дело, что «вышивать крестиком в арктическом походе» в список требований для кандидатов не включается обычно, а «показать список проектов на гитхабе» — включается, как видим…
Больше требований (+github) → меньше пул подходящих кандидатов → выше з.п. (разумеется, у тех, кто умеет в github).
Если я требую от работника работать за зп ниже рыночной, то пул возможных кандидатов снижается и… цена растет?
Не кажется вам, что тут есть противоречие, и ваш тезис надо как-то переформулировать, чтобы он не был столь универсален?
Выполнение требования о низкой цене приводит к повышению цены? Это же явное противоречие, чего тут нормального? В вашей модели данное требование просто невыполнимо.
Подводя итог: цена вашего предложения начнет расти, когда пул кандидатов на текущую цену с вашими требованиями станет равным 0. Т.е. когда не найдется ни 1 человека, устраивающего вас и согласного работать за предложенные вами деньги.
Я не знаю в чем будет причина увольнения этого одного, но я точно знаю что набор сотрудников у такого «нанимателя» начнется не с того что Вы описали а с увольнения того самого «одного». Даже если с ним будет «всё так», то он просто уйдет сам, повысив свой уровень или еще чего, не суть.
То есть, было в пуле 100 кандидатов, мы добавили условие «кандидат имеет опыт работы с технологией Х», в пуле осталось 90 кандидатов, т.к. отсеялись 10 студентов, которые не имеют соответствующего опыта работы. Причем эти студенты как раз претендовали на минимальную зп => необходимая зп возросла, мы уже не можем нанять дешевых студентов, их не осталось в пуле.
Другой случай — в пуле было 100 человек, добавляем условие «кандидат должен быть студентом». В итоге в пуле останется 10 тех самых студентов (то есть в 9 раз меньше человек, чем в прошлом случае!) но зп не вырастет, т.к. остались ровно те люди, которые претендуют на ту самую минимальную зп в пуле.
Таким образом, если добавление к списку требований требования «наличие сторонних проектов на гитхабе» не отсеивает людей, претендующих на минимальную зарплату из пула без этого требования, то это добавление не ведет к росту зп.
А вот когда придут полторы калеки, и из них придется выбирать… (Нет, изменить требования когда полторы калеки есть — не получится.) Чтобы понять необходимость этого нужен немалый опыт, ведь полторы калеки есть, максимум еще немного покрутим объявление… плюс как правило наем работника процесс коллегиальный: партнеры, начальство, HR, нач.отдела где работник будет работать, тимлид — много кто еще. И если с нулем пришедших всем более-менее понятно что надо что-то делать, то когда пришли, но недостаточно — понятно не всем.
Я вас прекрасно услышал, а вот вы сделали поспешный вывод из неполных данных.
Я всегда принимаю решения на основе неполных данных.
Такой уж я человек.
Собирать полные данные обычно слишком дорого.
Вот вы например сколько лет потратили на собеседования сотен соискателей чтобы выяснить что те кто контрибьютят в опенсорс имеют меньшие зарплатные ожидания? Наверное лет пять потратили да? </сарказм
Вы несете полнейшую чушь, причем вам КАЖЕТСЯ что вы несете ее с серьезным лицом, и не расплескиваете.
Человек СЛИШКОМ увлеченный натащит тебе стек технологий которые самые модные, а значит сырые. А если не натащит, то ему будет не интересно и он будет плохо работать или убежит. Ну а притащив этот сырой стек он все равно убежит. Туда где можно будет еще интереснее работать. За неделю до дедлайна да. Зато такому человеку да, можно будет платить чуть меньше.
А тот кто увлечен, но не маньяк, тот у кого есть чуть в репе, или даже нет, но на вопрос честно ответит «оно у меня на битбакете закрытое ибо мне стыдно выкатывать сырое» — тот дешевле работать не будет. Просто в силу того что с интересными технологиями он может поработать и вечером, когда будет писать очередной пулреквест в очередной новый и супер-модный движок. А на работе нужно деньги зарабатывать, чтобы оплачивать квартиру и удобный диван. И ради этого можно и не очень модный стек технологий потерпеть.
А вот человек который никогда ничего не писал для фана, не контрибьютил в чужие репы… если мы говорим о мидле, то будет слишком ограничен в своих способностях. Будет плохо понимать архитектурные моменты, ему нужно будет подробнее разжевывать, ведь он никогда не писал сам, только допиливал чужое или работал в команде. Он не знает (на своей шкуре, а не в теории) о том почему нужно принимать те или иные решения. Не имеет интуитивного опыта того где технический долг уместен, а где нет, где стоит закладывать гибкость на будущее (еще не известно какое), а где наверняка будет только один сценарий и можно спокойно все хардкодить… Все это приобретается с опытом, и только с самостоятельным опытом. А самостоятельно вести ентерпрапрайз-проект человеку без опыта не дадут. Ну а своих он не ведет. Если случайно он окажется толковым (ну мало ли, просто у человека не хватает времени саморазвиваться, а не просто жлоб), то постепенно сможет этот опыт частично перенять. Задавать вопросы тимлиду/техдиру — красиво, мол объясни, научи почему, сидеть в обед медитировать над тем почему именно так написана спецификация, писать пулреквесты в ядро написанное «старшими товарищами» и т.п… Но скорее всего будет как всегда — справляться с работой будет хреново и в перерывах между авралами будет искать другую работу. Где больше платят и меньше требуют. Ведь коллеги не более квалифицированные и более опытные — они просто идиоты которые себя не ценят…
И да, меня очень забавляет как люди без опыта собеседования людей — пишут сотни комментариев о том как правильно нужно принимать людей на работу. По моему мнению хоть немного понимать что такое собеседование с точки зрения работодателя и рассуждать об этом может человек имеющий за плечами минимум пять… увольнений. Ну рассуждать то может любой, но вот категорические выводы, утверждения навязывать — тут без опыта никуда.
Вы были с другой стороны, пусть даже может быть ваш голос был лишь совещательным, но вы там были, и вы возможно и не бог рекрутинга, но уж чушь то нести не будете.
Оффтоп: в воскресенье были на одном семинаре в одной организации где работала моя жена. Раньше подобные семинары организовывала она. Сейчас она была в роли посетителя, и по ее словам это совершенно другой опыт, и воспринимается оно все совсем иначе.
Безусловно, не будет. Вы тут такую простыню накатали, спорили. А с чем спорили-то, если с озвученными тезисами я согласен и нигде их не оспаривал?
Поэтому, когда я встречаю работодателя с такими закидонами, как у тебя, я просто прохожу мимо. А ты остаешься без нужного тебе специалиста.
Буду счастлив не иметь у себя в команде такую звезду которая не способна увидеть весь «алгоритм целиком» и заметить что «звезды» и сеньоры попадают в третий пункт.
Ничего личного. Я достаточно «взрослый» чтобы понимать что сухую спецификацию которая не трогает ваших эмоций вы прочитаете лучше. Но мне оно не нужно. Как и вам не нужно работать со мной. Ну бывает, чЁ.
И вот когда такие люди начинают принимать решения, очень часто приходит беда.
Шучу конечно, но что плохого если даже вот так утрированно взять — отказать кандидату потому что не понравилась фотография, это плохо?)
Нет, серьезно.
Если есть выбор, если ты понимаешь что это необъективно и т.п., но такой тип лица или стиль или еще что — будут вызывать дискомфорт в работе с этим человеком, то что плохого в таком выборе?
У меня в свое время было предложение от одной очень крупной частной корпорации от которого я отказался. Да, з/п была примерно в десять раз выше той что была у меня тогда, но я честно ответил что меня не устраивает их дресскод и я лучше приду раз в год к ним в гости как сторонний эксперт и получу намного меньше чем в штате, но зато приду в свитере а не в галстуке.
Что кто-то был не прав? Я тут выбрал натурально по фотографии, и это было разумно. И для работодателя было разумным не делать для меня исключений (к слову когда я работал в государственном секторе для меня исключения были).
Ну и по «диагнозам» в этой теме:
1) Druu — человек с довольно очевидными психологическими проблемами, он в этой теме их очень хорошо продемонстрировал и да, тут и фотографии не нужно
2) Павел Майоров — единственный «диагноз» который я ему поставил, так это несовместимость со мной. Тут и фотографий не надо. Второе — отсутствие публичной активности повышает цену найма что при прочих равных будет жирным минусом да. Но это не к нему лично а ко всем. А так то с ним бывает интересно подискутировать, даже когда он и «не прав» (по моему мнению конечно).
3) Ты — ну тут просто всё. Эмоциональная оценка изначально была твоя, так что да, эмоционально мы не совместимы, ну и ок.
По поводу эмоций… Ну есть такое, бесит меня когда человек вообще не в зуб ногой в той или иной сфере начинает «отчитывать» тех кто этим занимается профессионально. На Druu вон время трачу. Говорю свою позицию прямо не обращая внимания на размер обратной связи. Ну эмоционально, да. Но… имею право, мы на хабре а не на работе).
Павел Майоров — единственный «диагноз» который я ему поставил, так это несовместимость со мной. Тут и фотографий не надо.
Да ну? Кажется, вы это формулировали по-другому. Но сейчас вы, конечно же, правы: я и правда несовместим с человеком, который сначала делает неверные обобщения, потом из них делает кривые выводы, и при этом не слушает других.
У меня нет пулреквестов на гитхабе, потому что, когда я нахожу ошибку в библиотеке, я описываю баг вбагтрекере. У меня полно своей работы и физически нет времени делать чужую.
И? Что дальше? От того, что баг описан — он никуда не делся. И он прямо сейчас мешает работать лично Вам, конкретно в Вашей "своей работе". Обычно в этот момент частью "своей работы" становится исправление этого бага, разница только в том, насколько грязно это делается и насколько сложно потом это исправление поддерживать.
А речь не про раскрытие. Речь про то, что эти правки во-первых сделать необходимо, и во-вторых крайне желательно сделать достаточно чисто, чтобы не создавать лишних проблем с их поддержкой. А дальше, имея чистые правки создание PR — дело пары минут, и отказываться от этого просто глупо: PR даёт возможность получить бесплатное ревью от автора плюс если автор его примет то это избавит нас от самостоятельной поддержки этой правки.
В половине случаев достаточно почитать вдумчиво код и использовать другую апишку. А автору зарепортить что текущее апи не достаточно очевидно и легко попытатся использовать апи Х для задачи Y.
В таких случаях можно иногда унаследоваться от классов библиотеки и чуток добавить от себя в основной набор функций класса. Я так часто делаю с пхп библиотеками, если разработчик не стал принимать мою идею по доработке, или я сам понимаю, что мои потребности перекрывают то, что изначально решает библиотека, и нет даже смысла делать пул реквест на ее расширение.
И еще второй способ, в случае больших систем — это создание плагина к ним, вместо добавления кода в основной репозиторий.
Разработчиков основного проекта тоже можно понять, когда они не хотят иметь дополнительный код в их проекте. Ведь любой код надо будет поддерживать, ошибки в не исправлять..
В таких случаях всё равно стоит создать пул (мерж)-реквест и предложить доработать его кому-нибудь другому. Было дело, я поднимал такие пул-реквесты других людей и допиливал, после чего их мержили в апстрим.
Людая работа опенсорс-сообществу может пригодиться.
Если отказывается по делу, то надо поправить тесты. Если нет, то надо посчитать, что дешевле: поддержка своего форка или сделать то, что хочет автор.
Это не обязательно плохо. В зависимости от ситуации это может означать, что автор прав, и библиотека просто используется не так, как было задумано или не по назначению, или что автор не прав, но у него слишком большое эго, чтобы признавать свои ошибки. В обоих случаях продолжать использовать эту библиотеку (текущим образом в первом случае, или в принципе во втором) — явно становится слишком рискованно. И то, что благодаря отклонённому PR вы об этом узнали раньше, чем это стало проблемой для вашего проекта — хорошо.
«Проблемы с потреблением памяти» — это одна из функций требовала памяти в 16 раз больше, чем реально могло бы потребоваться (а когда памяти не хватало — функция кидала die() ).
В конечном счете библиотеку пришлось форкнуть, исправить и жить дальше с этой несовместимой с «оригинальным кодом» версией. То, что там автор раз в полгода вносит какие-то правки — про это пришлось забыть. Если он не может исправить потребление памяти одним из скриптов в библиотечке — где гарантия, что следующие его «исправления» не приведут к подобному?
Оставляете пул реквест и ждете. Иногда год.
Но моя правка заключается в одной (!) строчке, снабжена подробнейшим описанием в комментариях и issue. ЧСХ, проблема такая не у меня одного.
Оставил пулл-реквест, пулл-реквест отвергнут почти сразу же. Комментарий автора выше писал.
что в ней есть баг.
После чего вы его исправляете в дереве исходных кодов вашего софта, куда включён код библиотеки. В случае, если это GPL, исправленный вариант вы где-то выложите (а желающие при большом желании сами найдут и закоммитят куда надо исправление, не тратя на это ваше время). Если не GPL, и ваш продукт не опен-сорс, то у вас будет просто правильно работающая программа, т.е. свою задачу вы выполнили, а оповещать об исправлении всех заинтересованных в ваши обязаности не входит.
На а дальше — всё зависит от ваших устремлений. Если вы чувствуете активное желание обязательно делиться со всем миром своими наработками — делитесь. Если вы хотите понравиться потенциальным работодателям чем бы то ни было — делайте это. Если ни первое ни второе не про вас — тратить время на присылание кому-то патчей будет ни к чему.
Обычно хорошие разработчики стараются всего этого избежать, поэтому пропихивание патча в апстрим решает чисто ваши собственные проблемы.
После чего вы его исправляете в дереве исходных кодов вашего софта, куда включён код библиотеки.
За бандленные версии библиотек в дереве опенсорс-проекта надо делать что-то нехорошее с лидом такого проекта.
Разве что, если автор либы категорически отказывается принимать фикс или новую фичу, но тогда лучше форкнуть и выложить библиотеку отдельно.
За бандленные версии библиотек в дереве опенсорс-проекта надо делать что-то нехорошееА как надо? Подключить remote/external к определённой ветке-релизу другого проекта? Но это, по сути, замораживание версии.
Или подключиться к master/trunk другого проекта? И думать, почему перестало компилироваться в самый неудобный момент, или стало глючить, когда автор мутит какие-то эксперименты и новые API.
А вообще это от языка и его инструментария зависит. Я-то, считайте, два языка использую, плюсы и хаскель. В хаскеле всё просто, последние пару лет там принято использовать stack, а до того — cabal, они сами когда надо и зависимости выкачают, и соберут их, и так далее. В плюсах пакетного менеджера нет, поэтому авторы проекта Foo, как правило, пишут в своих Makefile/CMakeLists.txt/etc директивы для нахождения сторонних пакетов, а мейнтейнеры проекта Foo в соответствующих дистрибутивах следят за тем, чтобы оно всё собиралось, чтобы версии были правильными, и так далее.
А когда автор мутит эксперименты и новые API, он не делает новые релизы этих библиотек.
mva, мейнтейнящий ряд вещей в Gentoo, может вам поболе рассказать, думаю.
Ну не знаю, в Windows (и в Android) давно от такого отказались из-за проблемы Dependency Hell, там предпочитают, чтобы каждая софтина включала внутри себя все библиотеки, 50 МБ кода никакой погоды не сделают.
В ОС/дистрибутивах, где софт собирается централизированно, такой проблемы заведомо нет (наоборот, возникают проблемы с проприетарным софтом, поставляемым со своей джавой-бустом-кутями-libGL.so). А при сборке вашего проекта под Windows или Android или OS X никто не мешает в процессе сборки подтягивать все нужные зависимости и класть их в .msi/.dmg/etc. Зато ваша репа с исходным кодом чистая и содержит только ваш код, а не кучу очередных копий очередных библиотек в непонятно каком состоянии (а патченные ли они, например?). И история коммитов отвечает только вашим изменениям.
Один мой опенсорс-проект именно так собирается: в репе ничего, кроме него (и в одном месте выдранных кусокв libqxt, потому что оно, похоже, сдохло), а при сборке под макось macdeployqt и самописные костыли кладут куда надо все вспомогательные библиотеки (которые при этом при разработке под макосью тащатся из homebrew).
Ровно так и запускается все это старье.
В любом случае, это представляется очень маргинальным юзкейсом.
В вашей репе при этом всё равно ничего стороннего нет, есть только указание списка и набора версий сторонних библиотек.
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…
Эм, причём хедеры к dependency hell? Это ж исключительно вопрос сборки и пакетирования.Такой подход подразумевает, что библиотека установлена в системе, и строго последней версии?
Если в коде проекта написано
#include <pcre.h>
то в проект референсится последняя версия, а не та, с которой тестировал автор собираемого проекта.Такой подход подразумевает, что библиотека установлена в системе, и строго последней версии?
Нет, почему? Версии не меньше той, которая поддерживается автором, и той же major-версии.
В системе, кстати, может стоять несколько версий одной и той же библиотеки, включая хедеры (см. слоты в генте, например).
то в проект референсится последняя версия, а не та, с которой тестировал автор собираемого проекта.
А вы правда тестируете с новыми релизами pcre, openssl и glibc?
Бессмысленно получить более оплачиваемую работу? Кому как. Если вы и так получаете максимум, доступный или желаемый для вас (или вообще не работаете, потому что не хотите), тогда никакая дополнительная ачивка не нужна.
Просто посчитай количество человеческой работы, которой ты пользуешься бесплатно как программист.
Начиная ОС, языка, ИДЕ, сторонних либ. И тебе жалко потратить несколько часов своего времени чтобы поддержать open source? Это звучит жалко...
А приведите свой фрагмент кода для обозрения в подтверждении вашего многозначительного " то..."
И почему-то только у программиста считается НЕ НОРМАЛЬНЫМ не заниматься своей РАБОТОЙ в нерабочее время бесплатно ради «ачивки», а иметь ДРУГИЕ УВЛЕЧЕНИЯ.Не «почему-то», а вполне понятно «почему»: Хороший программист в 10 раз более продуктивен, чем средний. Отличный программист в 20-100 раз более продуктивен, чем средний. И это не преувеличение — исследования, проводящиеся с 1960-х годов, чётко это показывают. Плохой программист не просто непродуктивен: он не только не выполняет свою работу, но ещё и создаёт проблемы, которые приходится решать другим.
Вы можете нанять дерьмового почтальона и фигового уборщика и компенсировать качество зарплатой — ну придётся вам нанять 5 уборщиков вместо 4, снизите зарплату на 20% и всё будет нормально.
Но даже самый паршивый программист не будет работать за 1/10 той зарплаты, которую вы платите хорошему программисту — он просто не выживет. Особенно в силиконовой долине.
Так нафига брать его на работу и переплачивать за него?
P.S. Наличие кода на github не доказывает, конечно, что перед вами — хороший программист. Но увеличивает вероятность этого. Вот и всё…
Я вот в нерабочее время предпочитаю программировать для души. Но моя основная работа с программированием не связана никак. Если у меня будут проекты на 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 мы «пока» не поддерживаем?
Почти всегда в ТЗ есть что-то, что «забыли», «не учли», «не расписали»…
А вообще, ТЗ- лучший друг программиста и заказчика функционала.
Другое дело, когда я — разработчик. Там я могу задать вопросы или не задать и сделать на свое усмотрение или сделать опять же ровно то, что заказано. Больше фич — пожалуйста, больше денег. А то оказывается, что хотелок у клиента на 50 листов, а оплата — на студента. Оплатил как студента, задачу поставил как эээ профан (сэкономив на предпроектной стадии, ага), получил соответствующий результат. Можно вместе с клиентом составить этот 50 страничный документ, но будет ли он его оплачивать? Будет ли он оплачивать все эти фишки, которые всплыли во время формализации? Нет, он подготовил бюджет на «сделать подписку на поступление товара». Плевая задача на часок работы и 10 баксов.
К тому же, какие вопросы правильные никто не знает. Для клиента мои вопросы могут показаться глупыми (например, вам файлы с BOM или без?), а важные для клиента вопросы могли быть и не озвучены… Simplevolk прав, читать мысли мы еще не умеем.
О эта любовь айтишников спихивать с себя обязанности.О эта любовь неайтишников — требовать дополнительной работы бесплатно.
Ваша задача написать модуль.Ok.
Правила хорошего тона — переменные настраиваются в админке (или вы и переменные жестко в код зашиваете?)Нет — переменные у меня в текстовом конфиге. Иногда — передаются в командной строек или кладутся в базу. От проекта зависит. Никакого UI для их модификации нет — потому что мне он не нужен и его написание — это дополнительная работа.
Всякие хотелки по отображению это уже хотелки, а вот базово показывать список подписок, что бы минимально понять работает модуль или нет, имхо, очевидно.Совершенно неочевидно. Это увеличивает обьём работы примерно вдвое (а то и в несколько раз) и в первоначальную постановку задачи не входит от слова «совсем».
Если вы закажите плотнику прорубить «чёрный вход» в дом — вы от него тоже будете ожидать что он дорожку булыжником выложит и калитку в ограде сделает? Ну это же «правила хорошего тона»?
Так вот — «в тз кой-чего не учли» оно одинаково для любого программиста.Нет, конечно. Хороший программист — вынесет настройки в базу. Средний — в текстовый файл конфигурации. Плохой — всё захардкодит и даже CSS напишет через style="".
В результате модуль у третьего может даже и раньше «поспеть» — но «на долгих дистанциях» оно таки выстрелит.
Пока что наша дискуссия выглядит примерно так:
— Veyron в 10 раз быстрее мопеда
— да ладно вам: я вчера на мопеде задирал телевизир из ремонта — так быстрее соседа с таким агрегатом управился
— но ведь ремонт телевизоров — в вашем доме находится!
— да — но с другой стороны дома!
То же самое с тут: невозможно ничего сказать о качестве программиста по заданию на 50-100 строк кода. Отсюда, собственно, и статья, которую мы обсуждаем, взялась…
Хороший пример. Заказали вы сделать черных ход в дом у плотника. Он вам зарядил 50 тысяч с дверью. Вы выбрали дверь и платите 50 тысяч. Приходите, а в стене дыра и дверь рядом лежит. Ну а чо? Черный ход с дверью, а про установку в тз ничего и не сказано. Вы в ты не написали, а мне чего?Извините, но пользоваться лежащей на полу дверью — нельзя. Модулем без красивого интерфейса в админке — можно.
Статья взялась вообще с затеи, что программиста проверять на его работу вне рабочего места и делать какие-то выводы как минимум ограниченно для HR.Почему? При выдаче кредитов заёмщика оценивают по тому, что у него лежит в холодильнике, а почему при приёме на работу нельзя оценивать по тому, что лежит на GitHub'е? Тот же «холодильник», только для кода, по большому счёту…
Заемщика оценивают потому, что если у него ничего нет в холодильнике — очевидно кредит он не выплатит.
Вот ведь блин.
А если у него полный холодильник то значит выплатит?)
Вот так скажешь пять фраз из целого рассказа, запомнят одну, и ту упрощенно, а потом будет как всегда.
Особой корреляции между полнотой холодильника и добросовестностью заемщика нет.
Зато есть большая корреляция между несоответствием холодильника образу жизни внешнему виду заемщика и добросовестностью.
Тут больше сходство с тем как на паспортном контроле могут спросить «какой у вас знак зодиака?». При этом если ты его не знаешь то это вовсе не значит что у тебя паспорт поддельный, но приглядеться к тебе повнимательнее стоит…
Если вам потом поддерживать этот проект, сможете ли вы признаться заказчику, что доработка вашего модуля займет не 3 часа, а 20
А откуда 20? Один программист сделал модуль за 3 часа, вынес настройки в конфиг, другой программист при доработках нашел конфиг и поменял. Занимает 2 минуты.
Если вы под доработками подраузмеваете UI в админке, которое все-таки пришлось сделать, то вам так сразу и сказали — админка это дополнительная работа. Либо вы эти 17 часов оплатили сразу тому же программисту, либо потом другому.
Заказали вы сделать черных ход в дом у плотника. Он вам зарядил 50 тысяч с дверью. Вы выбрали дверь и платите 50 тысяч.
Итак, установим соответствие между сущностями в этой аналогии. Черный ход — это модуль. Дверь — это дизайн модуля. Дом — это сайт. Сделать черный ход в доме с красивой дверью — добавить модуль на сайт с понравившимся дизайном. Дверь лежит рядом — модуль отправлен вам в архиве, устанавливайте сами. Черный ход 40x40, не позволяет им воспользоваться человеку — модуль размера 1x1 пискель, либо кнопки невидимые, не позволяет пользователю его использовать.
Где в этой аналогии админка?
А я скажу где она может быть. Админка — это например сигнализация. Или счетчик прошедших в дверь. Или камера наблюдения. То есть дополнительная работа, которая использует результат изначальной.
Если Вам нужны программисты, которые поправляют ТЗ на предмет что «забыли», «не учли», «не расписали», отправляйте Вашего продакта/постановщика/архитектора/техлида
Мы тут о программистах говорим, или о супер-пупер-мега-левшах-и-на-дуде-игрецах? Про последних недавно хорошая статья была, вот: Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо приняли.
Потому что хобби «для души» никак не должно быть работой и наоборот.
А о том, чтобы дома решать рабочие задачи, никто и не говорит.
Хобби-сварка это же по любому не гаражные ворота, а или пет-проект типа Химейерского бульдозера, или какое-то прикладное или не очень искусство.
Вы бы когда писали такой модуль додумались бы до очевидного — вывести где-то в админке список подписавшихся и список товаров на которые подписались? Ведь надо только подписку и письмо.
С чего вы решили, что это очевидно? Речь идет о конкретном функционале за конкретные деньги. Вывод в админке — это другой функционал, и работы там больше, чем для самой кнопки. Это как электрика попросить "Установите мне электросчетчик", а потом удивляться, почему это он вам всю проводку в доме не развел, очевидно же, что электросчетчик вам сам по себе не нужен.
Если вы электрика попросите УСТАНОВИТЬ счетчик, а он придет и вкрутит вам счетчик в электрический шкаф прямо на шурупы на старый, не подключая провода и не опломбировав его потому, что вы не указали, что вам еще старый отключать (в тз же установить- про демонтаж там ни слова) и провода подключать надо и пломбировать, а еще и документы, наверное, надо? Это будет считаться УСТАНОВКОЙ или все-таки нет?Прекрасный пример! Просто-таки великолепный! Ну просто у меня мама как раз недавно этим занималась.
Так вот: установка и замена счётчика — разные вещи. Демонтаж оплачивается отдельно. И установка УЗО — тоже отдельно. И нет, она не является «само-собой разумеющейся».
Так что если вы заключите договор на установку счётчика, то обнаружив, что в шкафу один уже есть электрик потребует изменения договора — но что-то не заметил в вашем примере никаких препятствий, требующих «вкручавать вам счетчик в электрический шкаф прямо на шурупы на старый»… Вроде как речи о том, чтобы новый модуль требовал удаления какой-то функциональности.
Любой модуль должен иметь необходимые настройки
а так же показывать результаты своей работы хотя бы для отладки
Да, только не в админке и не в коде. А там, где программе удобнее их взять, а программисту поменять.
Да, только не в UI. Для проверки и отладки есть специальные инструменты. Да, клиент к БД один из них.
И уж точно обязательно для уровня ТОП программистов
Вы неправильно представляете ситуацию. Сторонний программист, нанятый для одного модуля, и постоянный, который работает на поддержке проекта, имеют разное отношение к работе и разную информацию о нем.
Стороннего вы нанимаете сделать конкретный объем работ, он даже не в курсе, может вы админку другого наняли делать.
А постоянный знает, кто работает на проекте и что уже сделано, и может предположить, что потом все равно задача появится на вывод списка, и возможно спросит заранее.
Если вы электрика попросите УСТАНОВИТЬ счетчик...
Он сделает то, что указано в процедуре оказания услуги "Установка счетчика". В этом случае ТЗ находится в нормативных актах и правилах его фирмы. В вашем случае ТЗ вы делаете сами.
Так что да, если он выполнит все что указано, это будет считаться установкой. Независимо от того, что вы сами об этом думаете.
> Средний программист потратит 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
в деструкторе.
читаю, гуляю, смотрю фильмы, общаюсь с друзьями и семьёй, занимаюсь домашними деламиНу вот видите, как у вас много хобби.
Хо́бби (от англ. hobby — увлечение, любимое дело) или увлечение — вид человеческой деятельности, некое занятие, которым занимаются на досуге, для наслаждения.Сомневаюсь, что вы ловите какое-то особое наслажение от дыхания. А вот чтение, фильмы и все остальное, что вы перечислили выше, вполне подходит под определение.
Весьма честный подход, что компания платит за результат (работу на хорошо известных, проверенных временем технологиях), а программист в свободное время педалит никому не нужные проекты на новых «горячих» технологиях, чтобы быть востребованным через год-два.
Безусловно, компания. Она же хочет, чтобы ее работник и через год-два был хорошим работником?
Если их это устраивает, то все хорошо. А если нет, то единственный вариант стать ценнее на рынке (и не важно, уйти на новые технологии, или остаться на Delphi, но с прибавкой к ЗП) — выучить что-то новое, экспериментируя по вечерам.
А вообще, никто здесь не должен. Но и программист и компания могут, если считают для себя целесообразным.
А если это не работник а соискатель, и таких соискателей достаточно, поскольку компания и соцпакет дает хороший, и зарплату, и обучение и даже время на написание опенсорса выделяет, а значит желающих хватает.
И вот значит приходит к такому работодателю два кандидата — у одного есть гитхаб с репами/коммитами, а у другого нет. Первичное собеседование одинаковое. Код на гитхабе нравится, а где не нравится так все понятно почему («ну я это писал когда только начинал, а дальше вынужден был поддерживать ибо многие используют» или еще почему).
Выбор простой — взять того что с гитхабом, или отказать ему, и усиленно тестировать второго, авось он лучше окажется. Потратив на его тесты время, и возможно деньги.
Ваш выбор?
У меня к этому такое отношение — компания платит мне не за часы, и даже не за результат, а за вклад в компанию.
А поэтому, я считаю вправе тратить время на то, что я посчитаю нужным, а компания — платить столько, сколько считает нужным за мой вклад.
Главное, чтобы ожидания с обеих сторон выполнялись.
При этом, понятно, что есть тёмная сторона, можно соответствовать ожиданиям делая примерно нулевой вклад (чем, на мой взгляд, занято далеко ненулевое количество сотрудников), но тут уж только личные моральные устои помогут.
понятно, что есть тёмная сторона, можно соответствовать ожиданиям делая примерно нулевой вклад (чем, на мой взгляд, занято далеко ненулевое количество сотрудников)Если верить Принципу Парето (и применить его три раза), то половина сотрудников делает один процент работы, а один процент сотрудников — половину работы.
0.2*0.2*0.2 = 0.008
Если 1% сотрудников делает половину работы (50%) и ещё половина сотрудников делает 50% работы, то что тогда делает 49% сотрудников? :)Половина сотрудников делает не 50% работы, а 1% (в сумме, а не каждый процент сотрудников по проценту работы).
Тогда на остальные 49% сотрудников остаётся 49% работы.
Так что выкладывать всё, что не является вашим конкурентным преимуществом (то есть не то, что позволяет вашей фирме зарабатывать, а всякие вспомогательные вещи) на github — очень пользительно.
Делать реально нормальный опенсорс это труд причем не малый. Зачастую стоит пожалеть нервы и время людей которые вдруг используют ваш код. Т.к. саппорт или даже ответ на свой вопрос они врят-ли получат
Чтобы было видно, что контора не дно днищенское.
Вы ж знаете, эйчары льют кисель на уши, а по факту как не спросишь хотя бы про Джоел-скор, так никто не в курсе. Так хоть соискатель видит уровень конторы.
Речь не о личных проектах, а о конторах, которые свои полезные фичи, которые не корные и не НДАшные опенсорсят. Обычно это конторы высокого уровня.
Вообще много таких. Возьмите любую мейнстримовую контору, хоть Гугл, хоть MS — у них тонны OpenSource. И ведь кто-то это все писал…
Как правило там есть определенные правила, и в некоторых из cабреддитах правила строже, чем здесь с песочницей.
А писать куда попало в комментариях о своем проекте — ну, тоже, в общем-то не очень выигрышная стратегия.
Меня весьма настораживает, когда у соискателя много выложено на гитхаб. Особенно если количество своих разработок (или сильно развитых форков) переваливает за десяток — это верный знак того, что человек на работе хронически чувствует себя не на своём месте, и находит отдушину в программировании на стороне. Мне, как злобному капиталисту, ставящему ценности моего текущего работодателя выше личных, в команду не очень нужны такие сотрудники.
А вот пустой гитхаб (ну, форки с точечными изменениями конкретных багов не считаются) — это как раз нормально. Если у программиста нет свободного времени на собственные проекты, значит он востребован на основной работе, и загружен там по полной. От такого работника можно ожидать большей самоотдачи.
Хотя, он может быть и просто лентяй. Но это выясняется на испытательном сроке.
что человек на работе хронически чувствует себя не на своём месте, и находит отдушину в программировании на стороне.
o rly?
Я сейчас занимаюсь разработкой ММО РПГ. ТОчнее я её довожу. Проект многие годы разрабатывался ребятами на энтузиазме. Сейчас у них появились деньги и они начали активнее работать. В частности наняли меня, чтобы допиливать проект.
Я чувствую себя на своём месте. Мне нравится код проект, сеньор который его писал — написал его так, как на его месте этот код написал бы я. Используется стэк близких мне технологий. Я каждый рабочий день с радостью погружаюсь в проект и пилю такси из джиры.
Но я не удовлетворен. Потому что у меня есть старая идея терраформинговой РТС, которую я иногда пилю потихоньку. Потому что мой дрифт-таз остро нуждается в электронных обвесах самого разного рода, которые я тоже с радостью делаю. НЕ говоря уж об умном доме, который каждый день ставит новые интересные задачи передомной.
Я удовлетворен своей работой, я на своем месте, но в свободное время я с удовольствием пилю самые разные вещи. Потому что если бы я тупо работал работу и больше бы ничего не делал — я бы очень быстро свалился в депрессуху. Потому что кровавый энтерпрайз лишь на 20% дает творчества, а остальные 80% — это нудная и тяжелая работа.
Вопрос о системе ценностей, на самом-то деле.
Я вот за творчество. А удовлетворение клиентов мне в целом побоку.
Поэтому в свободное время я творю. А вы, видимо, об удовлетворении клиентов думаете только во время работы.
Это я к тому, что ценности у меня одинаковые и на работе, и вне работы. А у вас раздельные.
Поэтому работодатели и хотят видеть энтузиастов своего дела на ответственных должностях. А не тех, кто о работе забывает сразу после 17:00.
Энтузиазм вспыхнул и погас, а обеспечение «деливери» должно тянуться годами, и неважно, что с тобой, и кто ты такой. И уж тем более, чем ты занимаешься в нерабочее время.
Но если ты будешь думать о деливери круглые сутки, свихнёшься. Лучше не надо.
Но прошли годы. И я больше так не отвечаю. Потому, что я могу работать в интересном проекте, могу работать в неинтересном, могу работать с хорошей командой, с плохой, один могу работать, в субподряд кого-то взять — как угодно.
Потому, что это и есть профессионализм. Ты делаешь то, что должен, настолько качественно, насколько способен. Каждый день. А интересно оно там мне или не интересно — клиента не должно заботить. Представьте, если бы вам хирург отказался проводить операцию, потому что «она какая-то скучная».
Другое дело что часто и от людей, «лабающих» формочки для внутренних нужд компании в 10 человек применяется этот же подход…
Да, я рискую нарваться на минусы, написав такое, но почему-то внутри ИТ сообщества процветает зашкаливающее ЧСВ, поэтому им нужны печеньки, теннис, комната для подремать и прочие блага. По моему мнению — многие просто зажрались. Считают себя избранными, творцами и т.д., а остальные — быдло, даже другие программисты — тоже быдло. Бесконечные холивары и прочее. Это очень хорошо прослеживается на русскоязычных форумах, посвященных ИТ тематике. Каждый считает своим долгом облить оппонента грязью, ведь именно О-О-О-Н ЕДИНСТВЕННЫЙ все делает правильно, а остальным это недоступно по определению, и лишь единицы отвечают по теме вопроса. На буржуйских ресурсах я такого не встречал.
Я не раз сталкивался с таким отношением к себе всяких новичков, которые приходили на мое место. Я старался им все объяснить подробно, что и как, какие мелочи нужно помнить, но они слушали свысока, мол — давай, хватит уже, до свидания. Однако через время (месяцы) некоторые признавались (в переписке или при встрече), что зря меня не слушали и что я им действительно говорил по делу.
Почему когда кто-то пишет статью, обязательно найдутся такие, кто скажет — я даже не буду читать эту чушь и сразу ставит минус. Не нравится статья и ты уже знаком с этой темой — промолчи, пройди мимо. Но ка можно? Это ведь такая удачная возможность запустить грязью в кого-то. Откуда столько агрессии в наших людях?
Ну, разве что речь о нейрохирургах. Да и то у нейрохирургов сейчас масса компьютерного оборудования с таким набором фантастических свойств, но все благодаря программам, блокирующие не только дрожание рук хирурга. Все стало слишком связанным…
А в остальном все верно. )))
Но большинства программистов, меня в том числе, такой уровень отвественности не касается.
Вот! Это ключевая фраза! Мы же говорим об обычных людях, а не о тех единицах, которые пишут прошивку для кардиостимулятора или руля высоты.
Когда Буран, во время автоматического полета, при снижении вдруг стал набирать высоту, его хотели уже взорвать, как потерявшую контроль машину (но что-то их остановило). Оказалось, что он пошел на второй круг. Посадка в результате прошла успешно и позже выяснилось, что машина определила, что при таком ветре правильную посадку при движении по выбранной траектории выполнить не удастся и Буран пошел на второй круг, чтобы скомпенсировать ветер… Вот где верх мастерства! Когда я впервые услышал эту историю, мне захотелось снять шляпу и поклониться до земли этим программерам! Однако картинка вокруг выглядит так, будто каждый второй именно тот, кто писал автоматику для Бурана ну или как минимум написал бы ее без труда, если потребует Родина…
Однако что-то мне подсказывает, что эти «Бурановские» программеры с виду совершенно обычные ребята, у них нет профиля на Хабре и Гитхабе и нет пафоса. Поговорив с ними никогда не догадаешься, что это были именно они!
Дико извиняюсь за некропостинг, но не смог пройти мимо. Отвечу с точки зрения врача — еще как спросят!
Сейчас от хорошего доктора при трудоустройстве треьуется не только подтверждение квалификации, но и раскрученный аккаунт в соцсетях и пул пациентов.
Особенно это проявляется в "продающих" специальностях, типа дерматолога, стоматолога, пластического хирурга, но постепенно расползается на все.
Про обучение в свободное время уже даже не обсуждается — узаконено и обязательно для всех врачей причём в очном и платном формате. И это мировой тренд.
А удовлетворение клиентов мне в целом побоку.Я бы вас не взял на работу.
Поэтому в свободное время я творю.Все кругом такие творцы, просто офигеть можно :) Из вашего предыдущего комментария мы в принципе поняли, какой вы просто офигительный энтузиаст и творец.
Поэтому работодатели и хотят видеть энтузиастов своего дела на ответственных должностях. А не тех, кто о работе забывает сразу после 17:00.Работодатели хотят видеть энтузиастов, потому что им можно меньше платить. Но не на ответственных должностях. Точнее, работодателю выгодно приложить усилия, чтобы энтузиасту его должность казалась ответственной — так он будет еще больше работать.
Но еще есть в мире компании, где нужны сеньоры. Там не нужен энтузиазм, а нужно ответственное отношение к деливери и способность принимать верные решения и делать задачи с срок. Это настоящие ремесленники, знающие свое дело, и получающие удовольствие от создания успешного продукта, приносящего прибыль компании и пользу заказчику, а не от какого-то воображаемого «творчества». То, о чем говорит PastorGL и чего вы (пока) не понимаете. Эти ребята уже слишком позвзрослели и обрасли цинизном, чтобы работать на одном «творческом» энтузиазме.
Так вот работа, работа — она не такая, работа и правда должна приносить удовольствие, а не его навяызвать, а уж тем более, навязывать (ложные) идеи удовольствия.
Насколько было бы удобнее, если бы в описании вакансии прямо было сказано: большой гитхаб-профиль обязателен, или наоборот, opensource-контрибуторам просьба не обращаться.
Если взять ваш довод за основу, то м.б. как раз у вас такому товарищу будет интереснее?
Если у программиста нет свободного времени на собственные проекты, значит он востребован на основной работе, и загружен там по полной. От такого работника можно ожидать большей самоотдачи.
Ищете тех, кто готов работать на вас по 16 часов в сутки?
А если у программиста силы на семью и детей, или, не знаю, каякинг остаются, он тоже недозагружен?
Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет заниматься другой работой бесплатно вместо того, чтобы провести время с семьей?
Почему по 16?
Потому что речь шла об отсутствии времени, а не желания.
Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет заниматься другой работой бесплатно вместо того, чтобы провести время с семьей?
Вообще-то от врача, инженера и учителя вполне ждут, что они будут читать новые статьи и прочие материалы в свободное время, а не ставить эксперименты в рабочее время на рабочие деньги над рабочими проектами.
Да и никто ни от кого ничего не ждёт. Просто тот человек, который сидит и кодит вечерами ради фана, имеет в среднем больше конкурентных преимуществ.
>Вообще-то от врача, инженера и учителя вполне ждут, что они будут читать новые статьи
Не надо заниматься подменой понятий. Читая статьи, код на гитхаб не выложишь.
>Просто тот человек, который сидит и кодит вечерами ради фана, имеет в среднем больше конкурентных преимуществ.
Это заблуждение.
10 часов на работу (включая дорогу), 8 на сон, 2 на еду и мыльно-рыльное, 4 на семью и хобби. И где взять время на гитхаб?
Ну вон же у вас 4 часа в том числе на хобби. А ещё и выходные есть.
У меня 8.5 часов на работу (включая дорогу), 7 на сон, час на еду и мыльно-рыльное, остаётся много.
Не надо заниматься подменой понятий. Читая статьи, код на гитхаб не выложишь.
Ну так и не занимайтесь подменой понятий, если не надо. Вы говорили об ожиданиях занятий другой работой (а самообразование — это элемент работы), я вам привожу примеры таких ожиданий.
Это заблуждение.
Опять же, почему, если у него больше практики и больше шансов познакомиться с новыми инструментами?
Ну так и не занимайтесь подменой понятий
Всего вам хорошего. Общаться с демагогом не имею желания.
4 часа на хобби, на гитхаб времени нет. Вы вообще читаете, что вам пишут или у вас монолог?
Значит, программирование для вас не хобби. Бывает. Ничего в этом плохого нет, в общем, и вы вроде не жалуетесь (тут никто особо не жалуется, кроме автора переведённой статьи).
Всего вам хорошего. Общаться с демагогом не имею желания.
Да и вам не хворать. Постарайтесь только в следующий раз вместо «Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет заниматься другой работой бесплатно» написать «Почему никто не ждет от врача, инженера, водителя, учителя, что он после основной работы будет коммитить на гитхаб», что вы, вероятно, имели в виду.
4 часа на хобби, на гитхаб времени нетЗначит, программирование для вас не хобби
Извините за вопрос, Вы — идиот? Или просто тролль?
У меня есть хобби — и оно программирование, и оно опенсорс, но гитом я не пользуюсь, НЕ ОБЯЗАН!
Плюс, из контекста и из этого комментария вытекает, что в хобби программирование не входит.
Просто тот человек, который сидит и кодит вечерами ради фана, имеет в среднем больше конкурентных преимуществ.
Ровно также, как и житель страны 3 мира, нашедший себя на помойке, имеет преимущество при получении работы перед жителем страны 1 мира, которому и страховки, и кредиты, и детей в университеты отправлять надо.
в точку
А теперь вопрос — кому она на этом самом GitHub нужна?
А если не на гитхаб, то куда выкладывать? В google play после переделки под Android?
Или всю папку игры слать как образец кода? Или класс из неё?
И второй вопрос — а если я разработчик баз данных / кубов, то тогда что слать?
Просто гит удобен для ведения разработки и даже не только кода. Можно откатиться, можно разные ветви развития впилить. Я может быть и хранил всё на личном закрытом гит сервере. Но правда в том, что никому ж дела нет до того, что у тебя там лежит, даже если оно открыто.
А конкретно гитхаб. Я раньше хранил проекты на google code. Так вот даже они закрылись. Что говорить про личные какие-то серваки, которые живут год-два. И всё на помойку улетает. А тут хоть шанс есть, что кому-то что-то и прогодится. Кто-то время жизни сэкономит
А если вдруг понадобиться на собеседовании свой код показать, то можно просто открыть доступ только потенциальному работадателю, а не на весь интернет.
Я тоже с недоверием отношусь когда гитхаб у разработчика пустой
А почему все ОБЯЗАНЫ писать на гитахбе?
У меня что не может быть иного хобби кроме гитхаба?!
PS то чем я занимаюсь, когда у меня на это есть время и настроение http://www.moddb.com/mods/wolfgl-3d — это проект с открытым кодом, и его на гитхабе нет.
Проблемы начинаются, когда другие работодатели увидев, что-то кто ФОРСИТ гитхаб (или иную модную штучку), начинают делать из него Культ Карго.
Поддерживаю.
Умиляет меня, когда нанимают сантехника, чтобы сделать водопровод в квартире, но не тестируют его, а ведь от его качества зависит, будет ли пролитие, и сколько проработает.
А вот погромистов трахают как только могут, во все места — тестовые задачки, собеседования и т.п.
Видимо, на рынке много непрофессионалов и джуниоров, поэтому так и происходит.
Что? Может в пост СССР какая-то альтернативная реальность, в Израиле наоборот, только программисты могут позволить себе ставить условия труда как у госслужащих. Адвокаты пашут по 12 часов в сутки, иначе не жди карьерного роста (а первая работа с зарплатой уборщика), бухгалтеры сидят по 10 лет в одном офисе, где им совсем не нравится, просто потому, что иначе на новом месте себя надо будет опять годами доказывать. Что уж говорить о профессиях попроще. А на разработчиков такой спрос, что они могут сказать "больше 9 часов работаю только в случае ЧП". И первая зарплата студента после окончания учебы уже как средняя по рынку (если бывший студент кончено не штаны просиживал, иначе эту работу найти будет очень трудно).
Это нездоровая фигня, с ней надо бороться и я рад, что есть места, где это получилось.
Эффективно бороться с этим можно только на уровне государства. И события 100лет назад как раз прекрасное напоминание о том, что и как надо делать, если хочешь отношения к себе как к человеку, а не к бесправному скоту. Ибо бизнес чем крупнее, тем менее договоропригоден без ствола в пузо.
Отнять и поделить, поставить за руль
Но раз уж пост у нас менеджерский, то давайте порассуждаем.
Есть такая легенда, что в одном ВУЗе студенты достали одного препода своими рассуждениями о крутизне социалистической модели общества, и он наглядно объяснил им в чем суть. Он объявил о том, что вся группа будет получать одинаковые оценки за контрольные, а именно среднюю арифметическую от всех.
На следующей контрольной все сдавали как обычно — троечники на тройки, отличники на пятерки, хорошисты на четверки. И все получили четыре.
К следующей контрольной отличники уже не так тщательно готовились, ведь пятерку все равно не получить, да и троечники расслабились. В итоге все получили тройбан. На третий раз результат был закономерен. Пара да. И все естественно попросили вернуть «капиталистический» вариант оценок.
Теоретический разбор данной притчи приводит нас к ошибочному выводу — «а вот если бы они скооперировались, и отличники стали бы помогать двоечникам...». но нет. Двоечникам много не надо. Им бы тройку. Они и рады помочь отличникам, но лишь чтобы до тройки дотянуть. Вытянуть троечников на четверку — дохлый номер. Как троечник говорю. У нас в школе было шесть «четвертей» и после каждой считали рейтинг. Если я слишком хорошо учился, то в следующей части я расслаблялся, чтобы больше времени оставалось на чтение того что мне нравится и т.п. Не уговорить меня было бы… Так что из-под палки, если бы не вернули «капитализм» можно было бы выжать максимум троечку. Ну а если взять сферических учеников, которые ну очень замотивированы и способны «подтянуть» троечников, то… что им мешает делать тоже самое в «капитализме»?
На практике единственный минус рыночно-капиталистического подхода к управлению (любому) — монополизация. Однако в данном конкретном случае, а именно в вопросах ценообразования зарплат в сфере ИТ монополизм невозможен, поскольку если вам платят меньше чем вы стоите то вы легко организуете собственный стартап, возьмете самых классных спецов (ведь картельный сговор конкурентов не дает им платить нормальные зарплаты, а вы сможете), и цены сразу выровняются. Для програмистского стартапа надо очень мало — хорошая команда, хорошая идея и т.п. Не нужны баснословные вложения как в медицине или электронике. Не нужны глубокие связи как у оборонки. Все что нужно это голова. Так что тут монополизм не опасен.
Миф о классах забавен, но не более.
Капиталист за рулем корпорации работает не в интересах некоего «класса» капиталистов а в своих собственных. Т.е. в интересах одного конкретного капиталиста. Соответственно кухарка во главе государства будет действовать не в интересах всех кухарок в мире а в интересах одной конкретной кухарки. Ну а дальше уже по цепочке разваливается и весь миф.
Следовательно — надо попробовать посмотреть на два носа вперед, прежде чем сделать вывод, когда тебе кажется, что в другой профессии как-то проще. (это уже не вам, а так, просто)
С программистами действительно беда, потому что приходят ДЕСЯТКИ людей и не могут решить элементарную задачу, в которой не требуется знаний каких-то протоколов или технологий — банальная задача на смекалку, а ее нет. А если грунт нестандартный, как ему доверить фундамент?
Хотя и з/п очень даже хорошая, но лишь 1 из 10 решает задачу правильно и в срок.
Вас не умиляет, что можно купить автомобиль и разобрать его до винтика и никто за это слова не скажет, а вот купить программу и дизассемблировать (не модифицировать, а просто посмотреть) — нельзя, копирайт, лицензия! Можно учить наизусть, переписывать в тетрадку стихи Пушкина и воспроизводить бесконечное число раз со сцены для миллионов ушей, а вот музыку копировать нельзя и кино тоже — копирайт, лицензия! Или Пушкин был опенсорсником?
Можно учить наизусть, переписывать в тетрадку стихи Пушкина и воспроизводить бесконечное число раз со сцены для миллионов ушей, а вот музыку копировать нельзя и кино тоже — копирайт, лицензия! Или Пушкин был опенсорсником?
Нет, у него просто срок авторского права давно истёк.
Музыку Моцарта и Баха — Вы можете свободно копировать в виде нот, и фильмы Чарли Чаплина — тоже можно свободно копировать.
Вас не умиляет, что можно купить автомобиль и разобрать его до винтика и никто за это слова не скажет
На Гиктаймс была тема про трактор защищённый копирастами от нелицензированной разборки, и то как судили фермера починившего свой трактор.
А ещё, была новость про то как Apple пытается продвинуть законы запрещающие нелицензированно чинить их телефоны под страхом уголовного наказания.
Согласно логике таких работодателей, после 10 часов написания кода (а также документации, сравнительных исследований платформ и библиотек, и т.п. фигни) на работе, я должен ещё и дома код писать, чтобы мне было что показать им? Причём, мне обязательно необходимо участвовать в опенсорсе?
Н-да. Но, пожалуй, нет.
В молодости я, конечно, так и делал, но гитхаб существует с 2008 года, а моя молодость закончилась несколько раньше, а вытаскивать своё старьё на всеобщее обозрение я не вижу смысла. А с тех пор, как я стал
Точно так же и люди из других предметных областей проветривают голову участием в опенсорсных проектах в качестве программистов, но качество кода у них — любительское, к сожалению, так что личные гитхабы это не всегда положительный показатель.
Дело вовсе не в том, что надо в чём-то обязательно участвовать. Это получается само собой — при определённом подходе к работе. И, соответственно, наличие PRов в сторонние библиотеки и собственных проектов служит индикатором этого подхода к работе. А подход очень простой:
- Сейчас практически не существует проектов, которые не используют сторонние опенсорсные библиотеки/утилиты. А когда используешь что-то в таких количествах — обычно сталкиваешься с проблемами. И при наличии достаточной квалификации нередко проще решить проблему самостоятельно — форкнув и пофиксив что нужно. Мы все это постоянно делаем. Вопрос в том, что будет сделано дальше: будет ли этот фикс правильно оформлен и отправлен PRом в оригинальный проект? Компании тратить на это свои ресурсы выгодно по ряду причин (качество фикса/фичи увеличится если её отревьювит автор проекта, а главное дальнейшая поддержка этого изменения будет на авторе, а не на нашей компании). Так что если этого не делается, то либо изменение кривое и вы заранее знаете, что автор его не примет, либо не хватает квалификации корректно его оформить (угу, дока, тесты, кодстайл — всё это действительно необходимо для дальнейшей поддержки этого изменения, кто бы ей не занимался), либо не хватает ума объяснить начальству почему компании это выгодно (и не хватает ума работать в компании, в которой это и так понимают). И какова бы не была причина — в любом случае это минус лично Вам.
- При правильной декомпозиции в большинстве задач возникают небольшие универсальные кусочки, не связанные с бизнес-логикой текущего проекта. Если такие куски не оформлять полноценными библиотеками, с докой и тестами — этот код быстро загниёт и не будет повторно использоваться даже в проектах этой же компании, так что нормально оформлять эти библиотеки компании выгодно. А дальше их можно выложить в публичный доступ — выгода от этого для компании уже не столь очевидна, но она есть — плюс в карму, больше привлекательности для сильных разработчиков работать в этой компании, возможность дополнительно пиариться на этих проектах, и если эти проекты заинтересуют кого-то ещё то сторонняя бесплатная помощь в развитии этих проектов, … (здесь троеточие не потому, что больше нечего добавить, а потому что многое зависит от специфики и размера компании — например когда крупная компания выкладывает свои инструменты/фреймворки в паблик у неё появляется возможность со временем нанимать людей уже знакомых с используемыми в компании инструментами/фреймворками). Отсутствие же таких проектов говорит либо о том, что у вашей компании проблемы с корректной декомпозицией или оформлением библиотек, либо о том, что компания пока не доросла до осознания пользы от выкладывания таких проектов в паблик. В первом случае это минус и Вам, во втором нет, но… как говорится, серебряные ложечки нашли, но осадочек всё-равно остался.
Сейчас практически не существует проектов, которые не используют сторонние опенсорсные библиотеки/утилиты. А когда используешь что-то в таких количествах — обычно сталкиваешься с проблемами.Мне кажется, это не везде так. Я в последние годы работаю в крупных компаниях, над крупными проектами (1kk+ LOC). Да, в каждом проекте используются какие-то сторонние библиотеки, но, во-первых, своего кода гораздо больше, чем стороннего, а во-вторых, лишь очень малая часть этого стороннего кода используется повсеместно — большая его часть скрыта под внутренними обертками, с которыми работают лишь соответствующие команды.
Итого: пока все работает нормально, я вижу сторонние библиотеки только в виде вызовов API, причем лишь наиболее известных его частей. Ситуаций, когда что-то вроде boost::iterator_facade работает неверно, пока что не было. А исправления во внутреннем SDK на GitHub не выложишь.
В итоге там, где я был, обычно предпочитают менее оптимальный путь, который дает дивиденды сейчас, а не когда-то потом.
Да, вкладываться в поддержку/доку/тесты нужно сейчас. Вне зависимости от того, планируется ли выкладывать этот код в опенсорс. Но дивиденды будут не когда-то потом, а практически сразу же — при дальнейшей отладке и поддержке этого кода. Не существует выбора между "тратить время на тесты" или "не тратить время на тесты" — на самом деле это выбор между "тратить время на отладку" или "тратить время на тесты", и последнее обычно значительно выгоднее.
Всё это можно не делать только в одном случае — если данный код планируется запустить один раз (вариации — использовать его ближайшие несколько дней), после чего выкинуть. Если же код потребуется в будущем поддерживать или развивать или повторно использовать — дока и тесты (в разумных объёмах, конечно же) сэкономят ресурсы компании, а не растратят их. Максимум — можно отложить написание доки до момента, когда потребуется объяснять работу этого кода новому сотруднику, а написание тестов до момента, когда потребуется этот код отлаживать/фиксить/развивать. (Но откладывать — не очень хорошая идея. Потому что доку проще и быстрее написать пока код в голове, желательно даже до написания кода, а не когда он кому-то понадобился через три месяца. А тесты морально намного проще писать небольшими кусками, по мере написания кода, а не одним героическим рывком покрывать весь код спустя месяцы.)
Там, где я работал, обычно пилятся фичи по принципу «Работает — не трогай». Модуль пишется один раз, и после этого подвергается минорным доработкам. После этого фичи релизятся и проводится большой регресс по всему функционалу продукта. После чего всплывающие баги фиксятся уже в релизной ветке, которая после прохождения QA попадает в прод.
В таком процессе потратить месяц на написание фичи в составе продукта, без документации и тестов (либо с минимальными тестами на критический функционал) и прогон на регрессе продукту нравится больше, чем оформление правильного отдельного репозитория за 3 месяца. Я не считаю, что это правильно, но видимо в ближней перспективе год-два такой подход получается дешевле.
А Вы начните отдельно считать абсолютно всё время, которое уходит на отладку/поиск и исправление ошибок, плюс время потраченное на дополнительные перепроверки после исправления ошибок тестировщиками во время этого большого регресса. А потом сравните его с тем, сколько бы заняло написание юнит-тестов, которые бы позволили практически все эти ошибки найти и исправить ещё в процессе разработки (причем исправить намного быстрее, потому что во-первых очевидно что ошибка в только что написанном коде и во-вторых потому что этот код ещё в голове и в-третьих потому что можно не сильно беспокоиться о том, что может сломаться в других местах из-за исправления ошибки потому что это моментально поймают юнит-тесты). Обычно на юнит-тесты уходит примерно столько же времени, сколько на код, который они проверяют. Так что если на всё вышеописанное у Вас уходит больше времени — то писать тесты выгоднее уже прямо сейчас.
Нет, у меня нет сторонних проектов, чтобы вам показать