Нет, у меня нет сторонних проектов, чтобы вам показать

https://www.codementor.io/ezekielbuchheit/no-i-have-no-side-code-projects-to-show-you-cz1tyhgdz
  • Перевод
Я точно знаю момент, когда потерял шансы пройти собеседование в фирму по разработке шоппинг-приложения в центре Остина. Они хотели посмотреть примеры моего кода. Конечно, они понимали, что я не могу им показать код своего нынешнего или прошлых работодателей. Но это не должно быть проблемой. Ведь они разрешают показать код одного из моих многочисленных сторонних проектов, которые у меня без сомнения есть.

Но у меня нет сторонних проектов. У меня нет аккаунта на GitHub. У меня нет open-source проектов, которые я строгаю по вечерам. У меня ровно ноль пулл-реквестов в любой из последних модных проектов, в которых участвуют все крутые кодеры. Я не вожусь с упражнениями в Haskel. И я ненавижу хакатоны.

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

И в какой-то степени это правда. Я не лучший. Я встречал некоторых из лучших, и это фундаментально иные существа. Если позволите сравнение из моего прошлого бега на длинные дистанции, то я мог финишировать среди первых 5-10%, но расстояние между мной и элитой равнялось расстоянию между мной и последними 1%. Да, я был увлечён бегом, пробегал по 80+ километров в неделю. Выжимал из себя всё для достижения совершенства. Совершенства, какое возможно в границах времени и того жизненного баланса, который я установил для себя. Чтобы достичь элитного статуса, мне бы пришлось пойти на жизненные жертвы, которые я не хотел делать. Это означало бегать за счёт всех остальных занятий.

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

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

Я принял за правило добавлять в резюме и онлайновые профили те вещи, которыми увлекаюсь. Тот нелепый арт-проект, который открыл в Остине. Мой бизнес, связанный с собаками. Бег, рисование, писательство. Для меня важно, чтобы эти качества ценились на рабочем месте. Если они ценят такие вещи во мне, то будут ценить их в других людях, а это многое говорит о корпоративной культуре.

Мир понемногу двигается к этой реальности. Сан-Франциско, Сиэтл, Нью-Йорк — это могут быть горячие, современные города для расположения вашего стартапа или гигантского конгломерата, но вы сильно ограничиваете выбор потенциальных кандидатов только крошечной горсткой людей, которые могут позволить себе жизнь в этих городах. У меня четверо детей. У меня целый отдельный бизнес по заботе и развлечению собак (playcare business) вместе с женой. Я активный участник местного художественного сообщества. Я никогда бы не смог жить ни в одном из этих городов. И хотя некоторые компании понимают, что таких как я много — Facebook, Google, Amazon, все они присутствуют в Остине в частности потому что в остальных местах таланты кончились — многие другие по-прежнему уверены, что «лучшие» живут ради программирования. Что «лучшего» можно привлечь в свою фирму, потому что у вас есть комнатка, чтобы подремать, у вас можно работать 80 часов в неделю и играть настольный теннис. Что в пятницу вечером «лучшие» напиваются в стельку и у них нет абсолютно никаких планов на вечера или выходные. Никогда.

Я не получил работу в фирме по разработке шоппинг-приложения в центре Остина. У меня нет сторонних проектов, чтобы вам показать. По вечерам в четверг я хожу в студию и вместе с другими художниками три часа делаю наброски нашей модели в разных позах. Чаще всего по вечерам, сделав ужин и проведя время с женой и детьми, я сажусь и пишу 2000 слов для своего пятого романа (как и четыре предыдущие мерзости, он останется в моём Уголке стыда и его никогда не увидит ни одно живое существо). По выходным хожу в походы. Глубоко погружаюсь в искусство. Я увлечённый разработчик, потому что я увлечённый человек. Но кода здесь я вам показать не могу.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 755
  • +25

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

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

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

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

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

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

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

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

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

            • –27
              В чужом — да. Не вижу смысла делать что-то бесплатно.
              • +7
                Ненавидишь — не делай. Но другим то чего указывать?
                • +18

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


                  про "ненавидишь" опечатка, полагаю. но удачная :)

                • +21

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

                  • +9

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

                  • +20

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                    Выполнение требования о низкой цене приводит к повышению цены? Это же явное противоречие, чего тут нормального? В вашей модели данное требование просто невыполнимо.
                                                                    • +1
                                                                      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 человека, устраивающего вас и согласного работать за предложенные вами деньги.
                                                                      • 0
                                                                        Я хочу видеть его глаза когда он будет этого одного потом увольнять. Не важно почему. Ведь выбирал то он его исключительно по «цене». Ведь чем ниже «цена» тем дешевле… вроде бы. А дешевых было не много, и выбирать было не из чего.
                                                                        Я не знаю в чем будет причина увольнения этого одного, но я точно знаю что набор сотрудников у такого «нанимателя» начнется не с того что Вы описали а с увольнения того самого «одного». Даже если с ним будет «всё так», то он просто уйдет сам, повысив свой уровень или еще чего, не суть.
                                                                        • 0
                                                                          Ваше исходное утверждение неверно, сужение пула потенциальных кандидатов не ведет к росту зп _само по себе_. К росту зп приводит отсечение из пула тех, кто готов работать за минимум.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                • +12

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

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

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

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

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

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

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

                                                                                              P.S. Наличие кода на github не доказывает, конечно, что перед вами — хороший программист. Но увеличивает вероятность этого. Вот и всё…
                                                                                              • +13
                                                                                                А почему у вас хороший программист и его продуктивность хоть как-то связаны с работой в нерабочее время?
                                                                                                Я вот в нерабочее время предпочитаю программировать для души. Но моя основная работа с программированием не связана никак. Если у меня будут проекты на github я автоматом становлюсь хорошим программистом?
                                                                                                Да и это НОРМАЛЬНО не заниматься работой в нерабочее время. Нужно переключать внимание для сохранения этой самой продуктивности. То что вы переключились с рабочего проекта на opensource это не переключение внимания. Примерно таким суррогатом пользуются когда на заводе в принудительном порядке работников конвеера переставляют на разные этапы. Что бы глаз не замыливался.
                                                                                                Про продуктивность в 20-100 раз — не верю (с). На длинной дистанции и сложном проекте с учетом выбора архитектуры на программисте и последующей выгоды от решения — может быть. На написании плагинов, модулей и логики (чем собственно занята минимум половина программистов) — нет 100%.
                                                                                                Математика обычно такая:
                                                                                                Если мне надо написать модуль, то хороший программист потратит на него условные 10 часов за 2000р в час = 20000р.
                                                                                                Средний программист потратит 12-20 часов по 750-1000р в час — от 8000 до 20000р — качество кода не хуже.
                                                                                                Плохой программист потратит 30 часов по 1000р в час.
                                                                                                Никакого варианта в 30 минут тут нет просто физически. Разобраться с тз и понять с какой стороны приступать занимает больше времени.
                                                                                                • +5
                                                                                                  Я вот в нерабочее время предпочитаю программировать для души. Но моя основная работа с программированием не связана никак. Если у меня будут проекты на 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 мы «пока» не поддерживаем?
                                                                                                  • 0
                                                                                                    Если вы этому уделите достаточно много времени — то да, можете стать лучшим программистом, чем те, кто получили диплом по этой специальности.

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

                                                                                                    Наверно у меня какая-то ни разу не репрезентативная выборка, но НИ ОДИН из встреченных мной программистов НЕ МОГ ничего лучше, чем написать по ТЗ. Никаких кой-чего не учли в ТЗ, а оно было сделано ни от одного программиста не получишь. А спросить это вообще из разряда…
                                                                                                    Банальный пример. Я тогда был неопытный и глупый и заказал простой в общем-то модуль. Если товара нет в наличии (остаток 0) вывести вместо кнопки «В корзину» кнопку «Подписаться», при нажатии кнопки вывести форму подписки. Ну и уведомить клиента как товар придет.
                                                                                                    Простой функционал?
                                                                                                    Вы бы когда писали такой модуль додумались бы до очевидного — вывести где-то в админке список подписавшихся и список товаров на которые подписались? А вот программист уровня MVP для того движка — нет. И ни один из программистов с которыми я работал — тоже не додумался бы. Ведь надо только подписку и письмо. Все.

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

                                                                                                    Github не покажет вам время постановки и проработки задачи. И коммиты вам покажут лишь насколько часто человек занимался своим проектом.

                                                                                                    Мой личный, правда старый, пример: у нас был драйвер для Windows (виртуальная файловая система, всё такое) и человек, который отвечал за этот драйвер потратил полгода на то, чтобы сделать так, чтобы драйвер не падал на Windows ME. Безуспешно. После чего был найден специалист, который за неделю написал такой же драйвер с нуля. И он работал. Недёшево обошлось, да — но результат того стоил: во сколько там разница в производительности была (притом, что кроме полугода борьбы с Windows ME там ещё было потрачено время и на другие вещи — до того, как наступил кризис)? А с учётом того, что всё это время приходилось клиентов «завтраками кормить» и обьяснять, что Windows ME мы «пока» не поддерживаем?

                                                                                                    Я непопулярно отвечу, но это ошибка менеджера, а не программиста. Если своими силами задача не решается за месяц, но отдать ее на аутсорс стоит $$ и 2 недели это значит что ее надо отдавать на аутсорс. Потому что ЗП своих программистов тоже стоит денег, которые выкидываются впустую.
                                                                                                    • +2
                                                                                                      Окей, предположим в ТЗ указали про админку… А список должен быть с группировками или без? А можно ли там ставить фильтры в этом списке по товарам или по подписавшимся? А нужно ли этот список потом выгрузить в csv (ваш_формат) или нет? ТЗ может быть очень и очень полным, но тогда на такую простую фичу оно займет прилично места и времени для его проработки.
                                                                                                      Почти всегда в ТЗ есть что-то, что «забыли», «не учли», «не расписали»…
                                                                                                      • 0
                                                                                                        Ну вот, снова придираетесь! Ясно же, что программист должен был угадать желания.
                                                                                                        А вообще, ТЗ- лучший друг программиста и заказчика функционала.
                                                                                                        • 0
                                                                                                          Если программист работает строго по ТЗ — в чем разница между средним и супер-программистом? И есть ли она в виде разницы в продуктивности в 20-100 раз как в комментарии, на который я отвечал?
                                                                                                          Если бы разница была бы такого порядка — разница в ЗП была бы такой же — ведь проще нанять супер-пупер чела с производительностью 100 человек, чем 100 человек и рулить ими с накладными расходами. Или выгода там все-таки 20-30%?
                                                                                                        • 0
                                                                                                          Я отвечал на комментарий, что хороший программист продумает функционал и сделает с высоты своего опыта. Так вот, если дальше ТЗ он не продумает, то где этот самый опыт?
                                                                                                          Наверное, имея супер-опыт, программисту стоило задать вопрос — А может вам в админке надо вывести список подписок? И дальше уже уточнять этот самый пункт в виде отдельного ТЗ?
                                                                                                          • +1
                                                                                                            Не-не, это вы возлагаете на программиста обязанности, которые свойственны или разработчику (инженеру), или консультанцу-внедренцу, или кому-нибудь еще. Вот когда я работаю как программист, я открываю ИТИЛЬ, открываю первую задачу в списке и делаю то, что написано. С некоторых пор, если я где-то в чем-то не уверен, я могу вопрос задать лишь менеджеру, а тот задаст его клиенту. Или ответит сам. Мое дело — кодить.
                                                                                                            Другое дело, когда я — разработчик. Там я могу задать вопросы или не задать и сделать на свое усмотрение или сделать опять же ровно то, что заказано. Больше фич — пожалуйста, больше денег. А то оказывается, что хотелок у клиента на 50 листов, а оплата — на студента. Оплатил как студента, задачу поставил как эээ профан (сэкономив на предпроектной стадии, ага), получил соответствующий результат. Можно вместе с клиентом составить этот 50 страничный документ, но будет ли он его оплачивать? Будет ли он оплачивать все эти фишки, которые всплыли во время формализации? Нет, он подготовил бюджет на «сделать подписку на поступление товара». Плевая задача на часок работы и 10 баксов.
                                                                                                            К тому же, какие вопросы правильные никто не знает. Для клиента мои вопросы могут показаться глупыми (например, вам файлы с BOM или без?), а важные для клиента вопросы могли быть и не озвучены… Simplevolk прав, читать мысли мы еще не умеем.
                                                                                                            • –1
                                                                                                              Не-не, это вы возлагаете на программиста обязанности, которые свойственны или разработчику (инженеру), или консультанцу-внедренцу, или кому-нибудь еще.

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

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

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

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

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

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

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

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

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

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

                                                                                                                То же самое с тут: невозможно ничего сказать о качестве программиста по заданию на 50-100 строк кода. Отсюда, собственно, и статья, которую мы обсуждаем, взялась…
                                                                                                                • –2
                                                                                                                  Нет — переменные у меня в текстовом конфиге. Иногда — передаются в командной строек или кладутся в базу. От проекта зависит. Никакого UI для их модификации нет — потому что мне он не нужен и его написание — это дополнительная работа

                                                                                                                  Мы же про хороших программистов, да? Если вам потом поддерживать этот проект, сможете ли вы признаться заказчику, что доработка вашего модуля займет не 3 часа, а 20 потому, что вы не предложили вариант с конфигом в админке сразу, а теперь вот вам еще в модуле разбираться. Или назначите часы и «чо париться, то?».

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

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

                                                                                                                  Хороший пример. Заказали вы сделать черных ход в дом у плотника. Он вам зарядил 50 тысяч с дверью. Вы выбрали дверь и платите 50 тысяч. Приходите, а в стене дыра и дверь рядом лежит. Ну а чо? Черный ход с дверью, а про установку в тз ничего и не сказано. Вы в ты не написали, а мне чего?
                                                                                                                  Ну или заказали сделать черный ход (без двери). Приходите, а там дыра 40 на 40 см. Ну а чо? В ТЗ же не сказано, какого размера, а мне и так сойдет.
                                                                                                                  Вот примерно так выглядят ответы программистов. Почему-то когда к ним приходит сантехник и, скажем, промывает засор, оставляя подставу от предыдущего сантехника (типа тройника в стене) то их бомбит. Ну он же знал, что через неделю засорится, а не сказал. А сантехнику чего? Заплатите за промывку и все. Мое дело маленькое — промыл, $$ получил, ушел.

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

                                                                                                                  То же самое с тут: невозможно ничего сказать о качестве программиста по заданию на 50-100 строк кода. Отсюда, собственно, и статья, которую мы обсуждаем, взялась…

                                                                                                                  Статья взялась вообще с затеи, что программиста проверять на его работу вне рабочего места и делать какие-то выводы как минимум ограниченно для HR. Примерно как по фоткам в VK делать выводы о работнике. Но у нас все такие «развивающиеся», что сама мысль о глупости подобного подхода их пугает)
                                                                                                                  • 0
                                                                                                                    Хороший пример. Заказали вы сделать черных ход в дом у плотника. Он вам зарядил 50 тысяч с дверью. Вы выбрали дверь и платите 50 тысяч. Приходите, а в стене дыра и дверь рядом лежит. Ну а чо? Черный ход с дверью, а про установку в тз ничего и не сказано. Вы в ты не написали, а мне чего?
                                                                                                                    Извините, но пользоваться лежащей на полу дверью — нельзя. Модулем без красивого интерфейса в админке — можно.

                                                                                                                    Статья взялась вообще с затеи, что программиста проверять на его работу вне рабочего места и делать какие-то выводы как минимум ограниченно для HR.
                                                                                                                    Почему? При выдаче кредитов заёмщика оценивают по тому, что у него лежит в холодильнике, а почему при приёме на работу нельзя оценивать по тому, что лежит на GitHub'е? Тот же «холодильник», только для кода, по большому счёту…
                                                                                                                    • –2
                                                                                                                      Извините, но пользоваться лежащей на полу дверью — нельзя. Модулем без красивого интерфейса в админке — можно.

                                                                                                                      Почему? Берешь за ручку и открываешь)
                                                                                                                      Почему? При выдаче кредитов заёмщика оценивают по тому, что у него лежит в холодильнике, а почему при приёме на работу нельзя оценивать по тому, что лежит на GitHub'е? Тот же «холодильник», только для кода, по большому счёту…

                                                                                                                      Заемщика оценивают потому, что если у него ничего нет в холодильнике — очевидно кредит он не выплатит. Про оценку