Пару слов о неминуемом повороте в развитии IT-отрасли

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

    Мол, какой-то девайс, фреймворк или способ работы резко поднимает успешность предприятия. Например, «мы все используем MacBook, и у нас уже третий раунд инвестиций». Или «мы решили открыть travel-агентство, и нанимаем только тех программистов, которые не вылезают из путешествий; мы хотим, чтобы все сотрудники разделяли наши ценности, и у нас уже оборот 100 млн долларов». Или «как только мы внедрили React + Vue + Angular, наши дела пошли в гору, и нас купил Google». И так далее.

    На первый взгляд кажется абсурдом? — Да, но признаем: хайп и гвалт есть несомненные сопутствующие элементы современного IT-мира. Любое явление, находящееся на острие общественного внимания, а IT, безусловно, из таких, не может не впитать в себя характерные черты социума своего времени. В частности, тенденцию к превалированию формы над содержанием.

    image

    Частенько происходит типичная выдача желаемого за действительное. Рынок буквально сходит с ума, чтобы залить деньгами хоть кого-то, кто сможет выдать краткосрочный результат. Те, кому повезло с подливой от инвесторов, могут программировать хоть стоя на голове: для достижения быстрого результата, который нужно предъявить спекулятивному рынку, компаниям не обязательно, а иногда даже вредно выстраивать правильные, выверенные бизнес-процессы. Путь к первому успеху виден, а всерьёз займётся делом уже портфельный инвестор или крупный IT-гигант, который за миллиарды приобретёт выстреливший стартап. Пока все ждут роста акций и очередного рекорда в показателе «сумма, уплаченная за компанию / количество разработчиков», можно, не стесняясь, заявлять о любых своих капризах. Проблемы в человеческих капризах нет, но есть в том, что только ими теперь стараются обосновать успех всего предприятия.

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

    Любой, кто работает на работе хотя бы лет 10-15, наверное, вспомнит, как и он читал в своё время книжки про «100 секретов успеха», «200 причин бросить всё и сделать» и тому подобное. Единственный достоверный результат, к которому приводит следование этим остеровским советам, заключается в том, что вы болтаетесь ровно посередине. Нет, всегда есть пример васи, который выстрелил, но единичные выбросы статистики никогда не опровергали генеральную совокупность. Стало быть, теория не подтверждается практикой, и поэтому является не более чем спекуляцией.

    Парируя очевидные возражения, автор сего памфлета, безусловно, разделяет тот подход, что программист так или иначе учится на протяжении всей своей карьеры. Появляются новые языки, фреймворки, подходы к работе. Никто не желает верстать таблицами, как 15 лет назад, и SPA легче и эффективнее писать на специальных фреймворках, а не на старом родном jQuery. Развитие орудий труда неостановимо, как и человеческий прогресс в целом.

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

    Рискнём произнести весьма очевидные соображения насчёт секретов долговременного успеха в IT-отрасли. Рано или поздно, когда пузырь сдуется, и интерес мирового капитала переместится в новую отрасль (космос, биологию, медицину?), IT ждёт неминуемый консервативный поворот. Вдруг окажется, что любитель путешествий и кодинга из-под пальм элементарно работает 20 часов в неделю вместо 30-40. Вдруг окажется, что от программирования стоя через 10 лет разовьётся варикоз вен (спросите у любого парикмахера), а сидение на пуфиках, скрючившись над своим любимым макбуком, означает немалые затраты на невролога и мануального терапевта в будущем. Люди с удивлением обнаружат, что Agile не является панацеей от всех бед, и вообще должен применяться в весьма ограниченном круге задач, а новомодная геймификация прежде всего является способом саморазвлечения скучающих без реальной работы сотрудников кадровых отделов. Выяснится, что любимый лектор в очках в роговой оправе являлся обычным мошенником и смылся за границу с собранными через краудфандинг деньгами.

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

    Кто-то скажет, что станет скучнее. Возможно, кому-то новые времена покажутся пресными. Там, где качество кода компании не зависит от пятничной пиццы и настольного хоккея в офисе, ровно как и от командировок лучших сотрудников в Долину, прикольным весёлым ребятам делать особо нечего. Новыми героями статей вокруг IT-отрасли станут деловитые инженеры, копающие каждый свою тему, и добивающиеся пусть небольших, но фундаментальных улучшений для всех. Обществу станет всё-равно, добился тот или иной герой успеха в 19 лет или в 50. Станет неважным лейбл на корпусе ноутбука и умение держать себя на презентациях. Передовые разработчики перестанут называть друг друга «гуру», и станут просто инженерами.

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

    Взрыв инноваций и нововведений диалектически превратится в свою противоположность, сняв (в гегелевском смысле) все те реальные противоречия, которые накопились в отрасли в момент бурного роста. Возможно, настанет время решить давно назревшие вопросы, ведь следующий виток развития IT-технологий уже по-настоящему затронет всех и каждого: интернет вещей или кибер-терроризм не оставят выбора в вопросе «сделать быстро в надежде на будущие доработки» или «сделать сразу хорошо».
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 329
    • +21
      с подливой от инвесторов

      Вы знаете, если бы я был инвестором, я бы писал эти слова на чеках. :)


      По существу: ну наконец-то кто-то высказался о том, о чем все молчат. Браво, автор! Браво.
      Я считаю что в IT-сообществе категорически мало людей, которые просто делают свою работу, делают её качественно и за достойные деньги, решая при этом конкретные проблемы. Куда ни плюнь — везде сплошные хайперы и "скальперы", нацеленные на быстрые шальные деньги, славу и внимание, а не на качественный долгосрочный результат. При том как среди менеджеров, так и среди разработчиков.

      • +15
        «Мало людей просто делающих свою работу»- Их не мало, просто они не так заметны и меньше заинтересованны в хайпе
        Это как опрос по телефону -" а есть ли у Вас телефон"
        • +3

          Нет, ну так-то ясно что обычных разработчиков тоже много.
          Я говорю скорее о специфическом целеполагании, которое почему-то активно культивируется. Каждый мечтает свернуть горы, сделать свой стартап и продать гуглу, написать хайповый фреймворк, прославится, создать технологию… И это, без шуток, похоже, навязывается повсюду. На конференциях, при собеседованиях в компании, в университетах, на всяких сходках и тусовках. Не хватает только преславутого "ну что, когда свой стартап уже заведешь — часики-то тикают..". Почему-то не считается модным и достойным уважения просто делать свою работу. Разработчик, у которого "есть свой стартап" или "модная либа на гитхабе" почему-то имеет преимущество (например при собеседовании) перед обычным программистом, который решает поставленную перед ним задачу за деньги. Хотя подобное является никаким не убер-скиллом и не б-жьим даром, а просто опытом руководства (зачастую, посредственным).
          И нет, я не утверждаю что всем надо резко стать безынициативным офисным планктоном. Скорее — умерить пыл и действительно перестать тратить силы на то, чтобы "сделать мир лучше", а решить какую-нибудь небольшую, но предельно конкретную задачу, которая у всех на виду. И, соответственно, перестать смотреть свысока на людей, которые не делают свои стартапы, а просто день за днем, малыми делами, решают небольшие, но конкретные задачи.

          • +4
            Да, приходилось на собеседованиях сталкиваться с просьбами показать свои open source-проекты. После отрицательного ответа были реплики, мол, ну чё ж ты, вялый совсем, ничего не интересно?
            Да нет, почему, интересно, но я всё время работал на работодателя, и решал его задачи…
            • 0

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

              • 0
                Вот, кстати, мой работодатель наоборот официально не приветствует разработку собственных open source проектов (знакомит с соответствующим приказом под подпись).
                На резонный вопрос «А не все ли вам равно чем я в свободное от работы время дома занимаюсь» начальник отдела кадров дал вполне логичный ответ: «А вдруг вы и в рабочее время будете думать/работать над своим собственным/левым проектом», мол «Работаете у нас — будьте добры думать и радеть только за наши проекты».
                • +10
                  Вот, кстати, мой работодатель наоборот официально не приветствует разработку собственных open source проектов...

                  Мда… чего только на этом свете не бывает. Запрет на хобби.
                  • +16
                    Похоже на попытку снизить рыночную ценность своих сотрудников. Вполне объяснимо.
                    • +1

                      Ну да, именно так и есть. Зарплату не индексируют, в знания сотрудников деньги не вкладывают, постоянно мониторят сайты с работой ища размещенные резюме сотрудников. Если "палят" — то вызывают на долгий диалог к кадровикам, объясняя что "так нельзя" :D
                      Сам читаю то что написал… что то со стороны, реально, на какую то секту похоже.
                      А, да, и еще запрещают разглашать коллегам размер з/п.

                      • +1
                        Если «палят» — то вызывают на долгий диалог к кадровикам, объясняя что «так нельзя» :D

                        Чем они это объясняют? Своей неспособностью удовлетворить ожидания сотрудников? Если начинают шантажировать увольнением, можно смело заявить, что «так нельзя» не только потому что это подло, но и по закону.
                        • 0

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

                  • +1
                    это не в России? Иначе зачем подписывать эту чушь? А даже если кто и подписал сгоряча, то пусть подотрутся.
                    • +1

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

                      • +2
                        А вот не поверите — я всю эту кипу читаю. Да ещё и ошибки нахожу — заставляю перепечатывать. Хотите мою подпись, она будет после ознакомления. А то, что я уже третий день не пишу код, никак не виноват.
                    • 0

                      Нет, ну особо палку перегибать-то тоже не фонтан идея.

                      • +3
                        «А вдруг вы и в рабочее время будете думать/работать над своим собственным/левым проектом»

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

                        • 0

                          Сомневаюсь, что это законно — какое право они имеют на ваше свободное время?

                          • 0

                            Бывают такие. Один мой работодатель отказаля дать мне два дня в счет отпуска с примерно таким обоснованием: "Отпуск предоставляется работнику для отдыха и восстановления сил. За два дня полноценно отдохнуть и восстановить силы не представляется возможным, поэтому предоставление двух дней отдыха в счет отпуска нецелесообразно". С этой точки зрения по вечерам работних тоже должен отдыхать, а не фигней маяться.

                        • 0
                          Типа другие в рабочее время пилят свои проекты. Или вы свое свободное время тоже на работодателя тратите? Даже если это так, как вы это докажите? Допустим есть два кандидата, один в свободное время пилил свои проекты и есть что показать, другой заявляет что он трудоголик и ничего своего не пилил так как все время думает только о работодателе и допиливает на выходных свои рабочие проекты пока менеджер валяется где-то на пляжах Франции. Какой из кандидатов вызывает больше доверия?
                          • +1

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

                            • +1
                              Ну наличие или отсутствие Open-Source проектов не показатель ни хорошего, ни плохого программиста. С одной стороны у человека может быть 10 проектов на гитхабе, но как работник — он никакой. Просто потому, что он занимается тем, что ему нравится, а не тем, что нужно работодателю. С другой стороны если человек 8 часов работает на работодателя, а потом ещё 4 часа фрилансит чтобы прокормить семью, то вероятно от такого человека будет больше пользы.
                          • +2
                            > а решить какую-нибудь небольшую, но предельно конкретную задачу, которая у всех на виду

                            Т.е написать ту самую либу на гитхабе.
                            • 0

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

                              • +6
                                Не понимаю, в чем проблема либы которая фиксит косяки в других решениях?

                                Вот, например, у меня для magento 2 есть несколько либ среди которых 2 для фикса косяков системы. Суммарно их скачали 200 раз. Мне пойти удалить их?
                            • 0
                              Новыми героями статей вокруг IT-отрасли станут деловитые инженеры, копающие каждый свою тему, и добивающиеся пусть небольших, но фундаментальных улучшений для всех.

                              наверное, и есть «сделать мир лучше».

                              • 0
                                Эпидемия XXI века — стартап головного мозга.
                            • +3
                              Шальные деньги — всегда главная цель людей. Этого не изменить. А ИТ сейчас просто быстро развиваются именно из-за хайпа. И лучше, если хайп будет подольше, потому что как и сказал автор, как только капиталы уйдут, а они уйдут, тут станет просто нечего делать. Будет 10 больших компаний и какие-то студии, которых лопатой компай и которые делают на чём-то своём и под себя, никого не слушая. Останутся только профи, которые молятся на попадание в этот десяток компаний или подумывают о лучший временах, когда ты мог взять что-то неимоверно топовомодноафигительное и за 15 секунд заработать себе на чашечку чая с сырным бутербродом.

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

                              Пока есть хайп, есть деньги и люди, как только его не будет, то всё пойдёт лесом. Админь.
                              • +2
                                Ну программирование всё-таки творческая работа. Даже чтобы клепать формочки и работать с базой данных нужен талант, трудолюбие и интерес к профессии. Иначе будет быдлокодер и говнокод на выходе.

                                Я бы сравнил будущее ИТ с тем, как сегодня работают проектировщики и архитекторы в строительстве. Т.е. будут фирмы (и почти в каждом крупном городе) наподобие проектных институтов, в которых будут сидеть инженеры и что-то там делать. И в зависимости от наличия и качества заказчиков — это либо будут очень хорошие и солидные фирмы, либо шаражкины конторы.
                                • +1
                                  Байка про то, что программирование — творчество идёт с самого начала программирования. Чтобы управлять краном тоже нужен талант, трудолюбие и интерес к профессии. В любой профессии нужен талант, каменьщики тоже картинки выкладывать могут. А художники могут делать от балды совершенно бездарно. Короче это не творческая работа, потому что всё сводится к алгоритму: постановка задачи — решение задачи — кодинг — получение бабла, последний пункт может быть разбит на куски и выходит между каждым из остальных пунктов.

                                  Будущее у нас примерно одинаково смотрится. Вот только будет определённый стандарт, где будут клепать дома панельные, и будет 10 компаний, которые делают авторские таунхаусы или ещё что (я в архитектуре не сильно разбираюсь).
                                  • +3
                                    Тут вопрос, как вы сказали, о панельных домах и таунхаусах. Конечно для программирования простых вещей / сборки из готовых блоков + конфигурирования большого таланта не нужно, но стоит чуть усложнить задачу и такая потребность появляется. Программист, как архитектор, должен держать в голове множество взаимоисключающих вещей и балансровать ими. Это и производительность, и работа в многопоточной среде, и время разработки, и модифицируемость решений, и сами бизнес-процессы. Более того хороший программист не просто реализует задачу, а старается её понять и по-возможности улучшить/оптимизировать, а значит взаимодействовать с бизнес-аналитиком и/или заказчиком. Никакой алгоритм не скажет вам: «а давайте тут поле со статусом добавим, да историю будем в лог писать, а то не сможем потом пользователям ничего доказать». Умение предвидеть проблемы и предлагать нестандартные решения — это то, чему ещё ИИ долго не научится, а значит за нашу работу не стоит переживать…
                                    • +2
                                      Умение предвидеть проблемы — это опыт, его может получить любой верстальщик. Нестандартные решения — это уже конечно да, прямо профессионализм, хотя, нет. Этим наделён не опытный человек, который просто не знает стандартных подходов.

                                      Нашу работу уже начинают давать даже не ИИ, а каким-то системам. Наша работа уже заключается в том, что мы вывод одной библиотеки передаём на ввод другой. Это вполне можно сделать и в граф интерфейсе. Так что не надо обольщаться, мы ничего сверхестественного не делаем. Мы просто пишем алгоритмы, и уже даже можем не разбираться что именно делает та или иная функция внутри, мы её просто используем. Я даже больше скажу, разбираться во всём, что там происходит реально невозможно, потому что не нужно. Чтобы показать сообщение или закинуть в бд новую запись не нужно иметь высшего образования, достаточно знать библиотеку.

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

                                      Я же говорю, будет 10 компаний, где нестандартные решения будут ценится, но туда нужно будет попасть, а в остальных местах обитания можно будет всю работу заменить на скрипт, но этот скрипт придётся писать дорогому программисту из этих 10 компаний, который получил высшее образование и реально является молодцом. А сейчасешнее отношение «да меня за опенсорс возьмут» там уже скорее всего не пройдёт.
                                      • +4
                                        грустно Вам, должно быть)
                                        • +2

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

                                          • 0
                                            Интересно — делать что-то новое, чего раньше не делал. Работодателю не выгодно давать реальную работу человеку без опыта.

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

                                            И да, если ты обычно на jq формочки «лабаешь», то тебе будет неимоверно интересно сделать текстовую rpg на плюсах. Но…
                                            • 0

                                              Да просто и потребностей в решении интересных задач не так уж много. Компаний вроде Space X или Apple можно по пальцам пересчитать, и желающие там работать в очередь выстраиваются. Остальным приходится программировать системы учёта продаж туалетной бумаги и подобные "интересные" задачи.

                                              • +1
                                                Да ладно :) Задач много интересных. Посмотрите, как высыпало нейронки в последнее время, куча же интересных результатов и применений.
                                                • 0

                                                  Это примерно как Go: вроде как даже попал в топ-10, а попробуй ты найди работу, если ты не в США и не в ЕС.

                                                  • 0
                                                    «Не в США и не в ЕС» — это достаточно жесткое условие. Практически весь технологически развитый мир выкинули, кроме азиатских стран. Кстати, в Китае Go тоже популярен, AFAIK.
                                          • 0
                                            Судя по вашему комментарию вы предполагаете, что программисты умрут, верстальщики останутся? Я так не думаю.

                                            Конечно решить проблему коммуникации между двумя библиотеками можно с помощью ИИ. Хотя и это не так просто, т.к. в разных системах могут быть разные форматы данных, нужно знать зависимости и предметную область. Но впринципе это может сделать и непрограммист соединяя входы и выходы в графическом редакторе. Но ведь работа программиста, это не только рутина по написанию такого взаимодействия. Мне кажется, что у программиста соотношение задач между рутиной и созданием чем-то уникального — это 40 к 60. Т.е. только 40 процентов того что делает программист можно автоматизировать, а остальная часть его работы уникальна для текущего проекта и задачи.

                                            Насчёт высшего образования — да, оно действительно не особо важно для программистов. Потому что ни один из ВУЗов не учит Angular-у и React-у. Обучение идёт на устаревших языках и подходах. Другое дело, что там дают полезную теорию и учат изучать новое самому. Но с другой стороны 6 месяцев стажировки в какой-либо крупной софтвейной компании могут дать больше, чем 4 года университета.

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

                                            И про 10 компаний я не согласен. Всегда будут стартапы, которые будут хотеть сделать что-то уникальное. Инновации, это не удел гигантов вроде Эппла или Гугла, а как-раз наоборот…

                                            Короче не дождётесь вы смерти нашей профессии, а если будет плохо, то мы найдём выход… мыжпрограммисты…
                                            • 0
                                              Вы наверное тоже меня не поняли, я не говорил, что программисты умрут, наоборот, количество так называемых codemonkey на всё количество уменьшится, и уменьшится оно именно из-за того, что будет 10 компаний (я, если что утрирую, что их количество относительно сегодняшнего будет примерно такое).

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

                                              Давайте вспомним, что самый эффективный подход — подход, который видится незнакомому человеку со стороны. В вашем случае тоже самое, может быть. Мне вспоминается всегда картинка про квадратные колёса у тележки. Все новенькие, которые не имеют опыта всегда предлагают самое дубовое и рабочее решение. Вопрос в том, что сейчас люди делают на фреймворках, чтобы СТАНДАРТНЫЕ решения было легче понять человеку, пришедшему в проект с нуля, чем объяснять ему нестандартное.

                                              Эти 10 компаний никогда инновации делать и не будут, а вот вкладываться туда они будут, потому что это прибыльно. Не просто так гугль выкупает стартапы. У них есть капитал, а у людей есть идеи. Всё просто. И если человек захочет иметь стабильные денежки в кошельке за достаточно стандартную работу, то он будет тупо перется в эти 10 компаний, а если человек захочет иметь денежки и при этом делать что-то своё, то он пойдёт в те же 10 компаний, но уже с понтами и дипломом. А если человек просто хочет реализовать эту идеи и при этом чутка денежек поднять, то да, он пойдёт в стартап.
                                • +1
                                  Это да…

                                  В теме На пути к Go 2 я пытался пояснить различия между семантикой и структурой, а меня, похоже, так и не поняли.

                                  Зато я получил ссылку на мозговыносительную рекомендацию по использованию интерфейсов:

                                  ...Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values...

                                  заставляет задуматься о компетентности разработчиков на Go.
                                  • 0
                                    А что именно здесь не так? Как по мне то не только в Go интерфейс должен пренадлежать к тому пакету кому он нужен
                                    • +1
                                      Там же я это и пояснял, причем с картинками.

                                      Процитирую:

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

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

                                      В этом случае смысл интерфейса стремится к нулю...
                                      • 0

                                        А что не так? Попробуйте посмотреть на интерфейс как на контракт или протокол, на котором говорит потребитель. Потребителю его и публиковать. (Ну да, если несколько потребителей поддерживают этот протокол, вы его публикуете в отдельном пакете, но это всё ещё контракт потребителя.) Это прямо-таки by the book.

                                        • 0
                                          А что не так?

                                          То, что вы описали — все так.
                                          • 0
                                            Дополню. Go-разработчик, увидев рекомендацию о "...Go interfaces generally belong in the package that uses values of the interface type..." возьмет и размножит декларацию интерфейса во всех местах (пакетах), где он ему понадобится.

                                            Как вам такой поворот событий?
                                            • 0

                                              "Всё не так" — это как-то размыто. Хм, а вы, решив, что интерфейс принадлежит реализации, размножите интерфейс по реализациям? Это я просто пытаюсь следовать той же логике. :) Посмотрите на вторую иллюстрацию отсюда — про инверсию зависимостей. Верхние слои — потребители, они предоставляют абстракции (читайте — интерфейсы), которые реализуются нижними слоями. (Да, та же статья говорит, что размещать их в своих пакетах ещё гибче. Но это совершенно необязательно и зависит от задачи.)

                                              • 0
                                                Хм, а вы, решив, что интерфейс принадлежит реализации

                                                Что значит интерфейс принадлежит реализации? Интерфейс — это спецификация. Согласно этой спецификации можно использовать объект, либо согласно спецификации создать объект-реализацию.

                                                На всякий случай, прочтите обсуждение сначала, вдруг окажется, что мы говорим об одном и том-же.
                                                • 0

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


                                                  Вообще, если вы считаете некомпетентными разработчиков на Го (вот ведь, правда, начитаются книг про dependency inversion и размещают интерфейсы рядом с пользователями а не реализациями), то страшно подумать, что вы думаете о разработчиках на JS, Python, Ruby, вот этом всём. :) Го при компиляции всё равно проверит соответствие спецификации (вас не это смущает, кстати? отсутствие 'implements' где-то в реализации?), а у этих, с duck typing, и вовсе проверка в рантайме наступает, в недрах кода, когда у обьекта внезапно не оказывается нужной функции на борту. Некомпетентны от рождения?

                                                  • –2
                                                    … а у этих, с duck typing, и вовсе проверка в рантайме наступает, в недрах кода, когда у обьекта внезапно не оказывается нужной функции на борту. Некомпетентны от рождения?.

                                                    Чем отличает хороший специалист от плохого? Хороший, даже если и отступает по каким-либо причинам от канонов, то понимает всю тяжесть последствий. А плохой, делая ошибки, всецело уверен в своей правоте и будет упорно доказывать, что он прав.
                                                    • +1

                                                      К чему это сказано? Канон — это интерфейсы, а разработчики на JS/Python/Ruby от него отступают? Хм, вы лихо определили, что есть канон в разработке, а что нет… Ну и в своей правоте вы уверены настолько, что даже не комментируете ни ссылку к вики, ни отсыл к Clean Architecture который вам ниже привели. Я не настаиваю, конечно, да в комментариях к этой статье обсуждать всё это оффтопик, но вы очень категорично судите о других разработчиках, а своё мнение подкрепляете только оценочными "извращение", "смысл стремится к нулю" и прочими.


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


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

                                                      • 0
                                                        … не комментируете ни ссылку к вики...

                                                        Могу прокомментировать, что я описал то, что в статье относится к:
                                                        ...A more flexible solution extracts the abstract components into an independent set of packages/libraries...

                                                        А в первом варианте реализации DI (по ссылке в Wiki) упомянутый Go-программист упорно не видит, что есть связь между high-level и low-level components, потому что нет явного implements.

                                                        … и вторая, что конкретно в Го реализации не должны явно указывать, что они реализуют (этот ход мыслей мне понятен, но всё же спросите себя, так ли вам нужно видеть ...implements MyPrettyListener в исходнике...

                                                        Именно так. Да, мне хочется это видеть, что бы иметь представление о намерении разработчика, что бы иметь хороший инструмент рефакторинга и не иметь «false positive» ошибок срабатывания в IDE при поиске реализации интерфейсов.

                                                        Что плохого в желании иметь больший порядок в коде?
                                                        • 0
                                                          Кстати, по поводу первой реализации в wiki-статье прямо упомянуто:

                                                          ...In this version of DIP, the lower layer component's dependency on the interfaces/abstracts in the higher-level layers makes re-utilization of the lower layer components difficult...
                                                          • 0
                                                            … и еще дополню по поводу мозговыносительной рекомендации, что в том виде, в котором она приведена мне от нее виден только вред как минимум по двум причинам:

                                                            1) если смотреть на нее, как на вариант реализации DI, то «re-utilization of the lower layer components is difficult»;

                                                            2) без ясного пояснения причин, без понимания логических связей и без указания ссылок на её (рекомендации) намерения очень легко неправильно понять и наклонировать интерфейсов во всех местах, где используется один вариант реализации. И свойства языка Go не препятствуют этому.
                                                            • 0

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


                                                              • Вынося все интерфейсы в отдельные пакеты, вы умножаете их количество, и обычно без надобности. Размещать их вместе с потребителем логично всегда, а в отдельном пакете — только когда вы планируете повторно использовать реализации (lower layer components) ещё где-то (и вынос интерфейса в отдельный пакет в случае необходимости — это обычно очень простой рефакторинг). Если вы всегда делаете отдельный пакет, вы напрасно усложняете свой проект и плодите лишние сущности, это overengineering.
                                                              • В случае конкретно Go весь инструментарий (и средства парсинга языка, прямо в его собственной библиотеке) официально идут из коробки. Его парсер, в отличие от того же C++, не rocket science, поэтому у вас есть инструменты и нет ложных срабатываний.
                                                              • Вся информация о логических связях, о том, кто что реализует, у вас уже в коде. Разница только в том, смотрите ли вы на implements или на информацию в своей IDE. (Да что там — с тем же oracle/guru можно сделать так, что прямо в окне с кодом выноской будет надёжно отображаться, какие интерфейсы реализует тип, просто в файле этого не будет.) Я не вижу, почему это такая фундаментальная разница. Разработчики на языках с duck typing живут даже без этого, и делают вполне крупные проекты (и новые IDE в этом помогают даже без возможностей Go).

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


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

                                                              • 0
                                                                Разница только в том, смотрите ли вы на implements или на информацию в своей IDE.

                                                                Ну это похоже на «сначала создаем себе трудности, потом их героически преодолеваем».

                                                                но это не причина считать, что все остальные некомпетентны

                                                                Так если начинают спорить по «очевидным вещам», что еще думать? Одно дело понимать и признавать, что есть проблема/последствия. Другое дело упорно не хотеть это видеть.
                                              • 0

                                                Представим, что вы забрали интерфейс из модуля-потребителя и перенесли в модуль-производитель. Теперь модуль-потребитель не может существовать без модуля-производителя. У модуля-потребителя появилась ещё одна зависимость, без которой никуда. Где здесь выгода?


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

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

                                                  Например, когда сначала создается реализация, а под нее уже потом пишется интерфейс.
                                                  • 0

                                                    Всё именно так и происходит. Вы можете сделать любой интерфейс. Когда хотите. До появления реализации. После появления. Не важно. Это — свобода программиста и работа компилятора. Это — выгодно, ведь если программисту нужно меньше вещей держать в голове и меньше думать о деталях реализации, то ему проще работать. Значит, он за те же деньги сможет сделать больше. Вы предлагаете всё отменить и возложить обязанность про проверке всех типов и зависимостей обратно на программиста?

                                                    • 0
                                                      Вы можете сделать любой интерфейс. Когда хотите. До появления реализации. После появления. Не важно.

                                                      А вы не думали, что можно было вообще отказаться от интерфейсов и снять это ограничение? Зачем ввели интерфейсы?

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

                                                      Поэтому и придумали SOLID, а «Когда хотите» не рекомендуют.
                                                      • 0

                                                        Вы серьезно спрашиваете, или шутка такая? Отсылаю вас к документации. Это будет мой последний комментарий в ответ на ваши.

                                                        • +1
                                                          По ссылке написано, что интерфейс — это спецификация поведения объекта.

                                                          Спецификация пишется до реализации, а не после. И не спецификация зависит от реализации, а реализация от спецификации.

                                                          Это простая вещь, но почему-то многие ее не могут осознать.

                                                          См. так же: Контрактное программирование.
                                            • +2
                                              Так это же классика из Clean Architecture или Ports and Adapters.
                                              Правда я не видел еще ни одного проекта, который бы это реализовал грамотно.
                                              • 0
                                                Так это же классика из Clean Architecture или Ports and Adapters.

                                                По-моему, это здесь не причем, потому что под интерфейсом здесь понимается не User Interface (UI), а Protocol.
                                                • 0
                                                  Так и в Clean Architecture интерфейс это не UI.
                                                  • 0
                                                    Поясните, если не сложно, что конкретно имеется в виду.
                                                    • 0
                                                      Я думаю мы говорили об обном и томже, но не поняли друг друга, приведу пример.
                                                      Ну и когда я пишу «интерфейс» я имею ввиду Protocol. Собственно слово «интерфес» как раз оттуда: "In object-oriented programming, a protocol or interface is a common means for..."

                                                      Допустим мы разработываем модуль/пакет ShoppingCart.
                                                      Этот модуль может определить интерфейс ShoppingCartStore или ShoppingCartRepository.
                                                      В отдельном пакете имплементируем этот самый ShoppingCartRepository.
                                                      В таком случае наш ShoppingCart ничего не знает о том как хранятся данные — это хорошо.
                                                      А какой нибудь MySqlShoppingCartStore конечно же зависит от ShoppingCart. И это нормально, т.к. это конкретная имплементация механизма хранения (и таких имплементаций может быть несколько, например FileShoppingCartStore, MongoShoppingCartStore, DevNullShoppingCartStore).
                                                      • 0
                                                        Кроме комментария выше, так же упомяну мнение Go-разработчика(ов) из упоминаемого топика.

                                                        Якобы, в Go можно разделить интерфейс и реализацию, а, например, в Java-нет:

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

                                                        По-моему, каша у них в голове на этот счет.
                                                        • 0
                                                          Как я понял
                                                          … Правда, как здоровый минус, мы бы попутно убили гошную возможность отделения интерфейса от реализации, больше никаких интерфейсов не стороне пользователя...

                                                          Это ответ на вот это:
                                                          1. Все же отсутствие возможности (необходимости) задекларировать реализуемый интерфейс ухудшает естественную документируемость кода. Это важно при чтении кода.


                                                          И мне это понятно, в C# или Java нам нужно «импортировать» библиотеку/пакет который объявляет «интерфейс», а в Go не нужно.

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

                                                          • 0
                                                            И мне это понятно, в C# или Java нам нужно «импортировать» библиотеку/пакет который объявляет «интерфейс», а в Go не нужно.

                                                            «Они» думают, что если не нужно «объявлять интерфейс», то и сущности получаются несвязанными. Хотя логическая связь никуда не девается и должна упоминаться в документации.
                                                            • 0
                                                              Формально связи конечно же нет. Тоже самое ведь и в динамических языках.
                                                              По факту конечно же связь есть, как вы сказали «логическая».

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

                                                              Мне вот нравится Typescript с его опциональной системой типов, но разве это кого-то волнует.
                                                              • 0
                                                                И это формальное отсутствие связи дает языку дополнительную гибкость
                                                                Пожалуйста, расскажите про это подробнее или приведите ссылки на материалы. Давно думаю Go изучить, и этот момент смущает.
                                                                • 0
                                                                  Посмотрите в стороно этого: Go uses structural typing on methods to determine compatibility of a type with an interface. Wiki: Structural Type System

                                                                  Т.е. в отличие от C# и Java в Go немного другая система типов.
                                          • +2
                                            Да, хайповость в IT отрасли уже переваливает за все разумные пределы, полностью поддерживаю.
                                            • 0
                                              Плохо только, что именно хайповость приводит к пузырям. Доткомы как раз, к слову.
                                            • +2

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


                                              Или с другой стороны: человек покупает дорогой фотоаппарат и начинает считать, что это сделало его отличным фотографом. Покупает дорогое авто и считает, что это автоматически сделало его гонщиком.


                                              Люди, которые не разбираются в чем-то, бросаются на громкие слова. Допустим, кто-то хочет сделать интернет-магазин плюшевых мишек. 20 лет назад этот человек написал бы в объявлении, что нужна обязательно команда со знанием Oracle и Java (потому что каталог из 15 разных плюшевых мишек никакая база кроме Oracle не потянет, а Java — просто панацея). 10 лет назад было бы объявление со словами "MongoDB и C#", например. Сейчас будет Javascript/React. А что еще может сказать человек, который ничего не понимает в том, как устроены и делаются подобные проекты?.. Все равно будет повторять то, что на слуху.

                                              • +6
                                                человек покупает дорогой фотоаппарат и начинает считать, что это сделало его отличным фотографом

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

                                                Другими словами, метода кота Базилио: пока вокруг хватает дураков, сам себя хвали и живи на волне хайпа.
                                                • 0

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


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


                                                  Про феномен инстаграма молчу.

                                                  • 0
                                                    Одну мою фотографию, сделанную на цифромыльницу 2004 года выпуска (представьте себе качество), публиковали в крупном размере в «Русском Newsweek».
                                                    Фотография — это не только красота рисунка объектива. Хотя и она тоже, сейчас снимаю на L-ки и доволен как слон
                                                    • 0
                                                      Вы знаете, вы как раз и подтвердили мой тезис. Я видел много «знатоков», обвешанных суперкамерами, которые не снимали ровным счетом ничего, и видел профи, которые на сломанный пленочный аппарат с ужасным объективом снимал шедевры.
                                                      И хуже всего то, что первые из моего перечисления, не имея в голове таланта и ловкости снять нужный кадр в нужном месте в нужное время, вышли на рынок профессиональной съемки, и втирают доверчивым клиентам, что они-то — профи из профи!
                                                      На рынке свадебных фото очень заметно. На рынке рекламного фото меньше, там есть еще кто-то, кто кадры отбирает, и кто лажу не возьмет в тираж, а вот «счастливые» «молодые» сплошь и рядом хвастают перед друзьями альбомами — «вот, у нас на свадьбе был суперфотограф, как его, Вася Пупкин, чем крут — не знаю, но фотоаппарат у него большой, черный и дорогой!», при то что кадры отвратительные.
                                                      Да вы и сами можете зайти на фотосайты, и пооценивать фото, не глядя на информацию об оборудовании. Сильно удивитесь, думаю.
                                                • +2
                                                  (картинка для мема «тебе не нужно»)
                                                  тебе не нужно делать следующих доработок своего кода — если каждый раз писать на новом фреймворке

                                                  (а, с учётом скорости их появления — ИМХО именно это и будет нормой будущего ;) )
                                                  • –2
                                                    Да, еще в Библе предсказано что настанет эпоха когда глупого уже не будут называть мудрым.
                                                    • +3
                                                      ответом на вытеснение работников на надомную работу

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

                                                      • +1
                                                        В соседней теме обсуждается этот вопрос. По моему мнению, он совершенно не такой однозначный для работника. Будет, скорее всего, вот так: habrahabr.ru/post/337936/#comment_10416916
                                                        • 0

                                                          Так то, что там описано – это же замечательно. Например, лично я уже три с половиной года работаю фулл-тайм на почасовой ставке у зарубежного заказчика.

                                                      • +2
                                                        Людям всегда хотелось верить в чудо.
                                                        • +7

                                                          Не станет. Хайп происходит абсолютно во всех отраслях, просто в IT он более заметнее, потому что войти в отрасль можно с минимальными инвестициями, если сравнивать, например с космической отраслью. Это отлично видно на примере Илона Маска, например.


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

                                                          • +4
                                                            Как я указал в статье, современный хайп прежде всего результат огромного притока быстрых спекулятивных денег. С одной стороны, отрасли стали резко нужны новые кадры, и приходится привлекать не только тех людей, которые сами без прибауток садятся и кодят, но и сомневающихся, куда пойти — в программисты или в Макдональдс. С другой стороны, денег настолько много, что кроме кодеров и руководителей в отрасли пасутся многочисленные чирлидеры, гуру, опинион мейкеры и так далее — пока пирога хватает на всех.

                                                            Ввиду того, что кап.экономика циклична, рано или поздно этот весёлый базар съедет в другую отрасль. В IT, тем не менее, должны остаться все те достижения, которые были получены в результате взрывного роста. Все наработки, опыт, выводы. Просто процесс вольётся в более разумное русло.
                                                            • +2
                                                              С другой стороны, денег настолько много, что кроме кодеров и руководителей в отрасли пасутся многочисленные чирлидеры, гуру, опинион мейкеры и так далее

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


                                                              Ну и вы немного не правильно воспринимаете IT. IT — это не отдельная отрасль экономики, это практически составляющая значительного количества отраслей экономики. Уже практически не осталось отраслей, где можно было бы обойтись без программ, персональных компьютеров или чего-то подобного. А тут за этим сразу же приходят всякие CRM, интернет-магазины, админы и прочее.

                                                              • +1

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

                                                                • +3
                                                                  В том числе и в генную инженерию и давно. У меня есть книга по программным алгоритмам в генетике начала двух тысячных что ли. На русском даже :)
                                                            • +3
                                                              в IT он более заметнее
                                                              потому как мы общаемся в IT-сообществе.
                                                              Какое-нибудь сообщество нотариусов или рабочий коллектив городской больницы №3 вряд ли серьёзно относится к этим вопросам.
                                                            • +9
                                                              любитель путешествий и кодинга из-под пальм элементарно работает 20 часов в неделю вместо 30-40

                                                              Любимое заблуждение, только не модных программистов, а старых добрых квадратно-гнездовых директоров. Главное не сколько времени программист проводит на работе, а что он за это время успевает сделать. Причём важно не только сколько но и как.
                                                              • –15
                                                                Если ты за 20 часов сделал столько и так, то за 40 часов ты сделаешь вдыое больше, прикинь.
                                                                • +13

                                                                  Я тут на Хабре уже приводил пример со спритером и марафонцем, прикинь!
                                                                  Спритер за 40 часов непрерывного бега без перерыва не перегонит марафонца, а выдохнется и сдохнет.

                                                                  • +10

                                                                    А за 80 вообще горы свернешь, ага.

                                                                    • +4

                                                                      В неделе вообще-то целых 168 часов, а они тут про каких-то 40!

                                                                    • +5
                                                                      Я не видел программистов, которые пишут код 8 часов в сутки на протяжение долгого времени. Это или дедлайн-марафон, после которого люди пару месяцев «отходят», или 2-4 часа реального кодирования, разбавленные разного рода бездельем. Может где и не так.
                                                                    • +10
                                                                      вспомнилось из комментариев на хабре, «чтобы корова была эффективнее в четыре раза, её надо в два раза чаще доить и в два раза реже кормить»
                                                                    • +4
                                                                      Отличная статья. Побольше бы таких статей! Пусть молодые программисты вместо изучения модных фреймворков, методологий, участии в Open Source сообществе будут просто сосредотачиваться на результате. В таком случае мы, ленивые программисты, не будем чувствовать себя неконкурентоспособно.
                                                                      • 0
                                                                        Останутся те компании, которые будут зарабатывать на продукте и его обслуживании, а не на росте курса акций или даже просто на обещании хоть что-то сделать

                                                                        И вообще — будущее прекрасно.
                                                                        • –5
                                                                          Резюме — статья состоит из:
                                                                          — труизмы: 20%
                                                                          — критика новых модных заблуждений: 20%
                                                                          — критика того, чего автор не понимает: 10%
                                                                          — восхваление старых добрых заблуждений: 10%
                                                                          — неизбежность грядущего коммунизма: 40%
                                                                          • +7
                                                                            Почти любое высказывание попадает под Ваше определение, в том числе и Ваше собственное
                                                                            • +10
                                                                              Пожалуйста, соизмеряйте свои возможности написать что-то колкое и интересное со своим желанием это сделать
                                                                              • +4
                                                                                Прошу прощения, я не хотел никого обидеть. Я не сразу заметил, что вы — действительно коммунист.
                                                                            • +3

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


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


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

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

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

                                                                                Где же, по-вашему, заложен
                                                                                реальный успех
                                                                                ?
                                                                                • +2
                                                                                  Наверное, не стоит обвинять их в неумности.

                                                                                  Ошибка выжевшего в данном случае.

                                                                                • +3
                                                                                  Тут вопрос не в уме инвесторов. Люди с большими деньгами, как правило, и так умные.
                                                                                  Вопрос в устройстве системе. Период пузырения на любом рынке — время, когда покупают задорого, чтобы очень скоро продать ещё дороже. Серьёзные инвесторы своё получат.
                                                                                  А вот люди, поверившие в чудо-соковыжималку, на круг потеряли 400 млн, да
                                                                                  • +4

                                                                                    По моему скромному опыту, люди с большими деньгами наглые больше чем умные.

                                                                                    • +3
                                                                                      Да, количество денег у человека зависит от его наглости и жадности, а не от ума.
                                                                                      • +1
                                                                                        У меня самый отсталый троечник из класса сейчас самый богатый, на Х6 ездит :)
                                                                                        Но под умом тут имелось ввиду достигать поставленных целей.
                                                                                        • 0
                                                                                          Самым умным объявляется Харальд Крюгер, инженер, генеральный директор BMW, сумевший впарить вам кусок железа по десятикратной цене )
                                                                                          • 0
                                                                                            У меня самый отсталый троечник из класса сейчас самый богатый, на Х6 ездит :)

                                                                                            Это называется не ум, а социальные навыки = добиться того, чтобы за тебя всё делали умные люди: "когда мне нужно что-то узнать, то я нахожу человека умней себя, и спрашиваю" © громила Марв "Город Грехов"

                                                                                          • +1
                                                                                            Не поверите, до вашего комментария я считал, что я чуть ли не единственный кто видит положительную корреляцию с деньгами в основном лишь в наглости и щепотке везения. А не в безграничном трудолюбии и уме.
                                                                                            • 0
                                                                                              Странно, я таких людей как вы вижу вокруг сотнями.
                                                                                      • 0
                                                                                        хорошо сказано.
                                                                                        • +5
                                                                                          > Между «новый, стильный, прикольный» и «эффективный, разумный, достойный» нет прямой связи.
                                                                                          С добрым утром и добро пожаловать в наш дивный мир, где еда начинает лучше продаваться, если повесить на неё шильдик «без ГМО», а основатель компании, производящей космическую технику, просит сделать скафандр, который будет выглядеть круто.
                                                                                          > Исчезнет необузданная потребность членов сообщества встречаться на митапах, конференциях, хакатонах и кэмпах.
                                                                                          Разве обмен опытом между специалистами это что-то плохое? В других областях ничего подобного не происходит?
                                                                                          > Вдруг окажется, что без человека, владеющего серьёзным, проверенным временем инструментарием разработки, трудно поддерживать существующую, уже достаточно богатую инфраструктуру отрасли. Выяснится, что новые подходы, решения, разработанные внутри компании, как правило, дают больший реальный эффект, чем модные решения извне.
                                                                                          Но вы же сами себе противоречите, ведь проверенный временем инструментарий разработки это и есть модные решения извне.
                                                                                          > качество кода компании не зависит от пятничной пиццы и настольного хоккея в офисе, ровно как и от командировок лучших сотрудников в Долину
                                                                                          Качество кода не зависит от обучения и морали сотрудников?
                                                                                          > Станет неважным лейбл на корпусе ноутбука
                                                                                          А вот удачные инженерные решения владельцев этого лейбла не станут.
                                                                                          > и умение держать себя на презентациях.
                                                                                          Видимо в прекрасном IT будущего не нужно будет продавать результаты своей работы?
                                                                                          > давно назревшие вопросы (ожирение сайтов)
                                                                                          Здесь нет никакой проблемы. Никому не станет лучше, если сайты вдруг станут весить в 10 раз меньше.
                                                                                          Так же и во всей статье. Сначала выдумывается куча несуществующих проблем, потом делается вывод, что раз проблем так много, то это пузырь и он скоро лопнет. Но на самом деле эти «прблемы» являются нормальным состоянием индустрии.
                                                                                          • +2
                                                                                            а основатель компании, производящей космическую технику, просит сделать скафандр, который будет выглядеть круто.

                                                                                            Что в этом плохого?
                                                                                            • +2
                                                                                              Ну это ведь не ко мне вопрос, а к автору поста.
                                                                                              • +1
                                                                                                Наверное то, что обычно скафандр создают для надёжного решения определённых задач, а не для того, чтобы он _круто выглядел_. Тому кто его будет использовать, важнее удобство и надёжность, а не чтобы он круто выглядел.
                                                                                                • +3
                                                                                                  В том-то и дело, что время первопроходцев в этом месте давно закончилось, технологии отработаны, никаких особых неожиданностей не должно быть. Плюс полётный скафандр — это совсем не то, что лунный или для выхода в открытый космос. Тут можно и красоты добавить. А следуя вашей логике, дизайн вообще не нужен нигде.
                                                                                                  • 0
                                                                                                    Это, может быть в области создания просто скафандра для реальной работы они уже закончились. А в создании Футуристичного скафандра из фантастики — они только начинаются! ;-)
                                                                                                  • +2

                                                                                                    Разве одно другому мешает? Маск же не просил сделать круто выглядящий скафандр в ущерб надёжности и удобству. Эти два критерия и так есть и неотменяемы.

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

                                                                                                          Это не формула, это маркетологическая отмазка.
                                                                                                          Формула совсем другая — некрасивый самолёт не полетит.


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

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


                                                                                                          или то, что не понравилось маркетологам

                                                                                                          А тут всё просто. Скафандр будет принимать НАСА. Им будет пофиг на маркетологию.

                                                                                                          • 0
                                                                                                            Если бы вы были одним из тех инженеров, вы бы как поступили? Ну, значит вы очень херовый инженер.

                                                                                                            Более того, я думаю у Маска работают инженеры, которые этим горят и с удовольствием решили взяться за задачу «создать sci-fi-ный костюм»
                                                                                                            • 0
                                                                                                              Учитывая, сколько он им платит, они точно горят