Ниже — все ИМХО
1. В статье проходит тезис: государство может служить в роли добра, а корпорации, превращающиеся в монополии, имеют тенденции быть злом.
Это так. Однако, государство и является монополией. Причем, без обратных связей в виде рынка и конкурентов, без нужды быть эффективными. А вот монополии регулярно обновляются — где сегодня Яху или Майспейс, или та же Нокиа?
2. Государство противопоставляется монополиям. Однако, если посмотреть открытые данные в упомянутых автором странах, то государство давно превратилось в источник извлечения прибыли чиновниками из корпораций (где чиновники пишут законы, а потом уходят в корпорации разъяснять, как его трактовать; и наоборот, корпорации приходят и донатят политикам, чтобы те либо приняли регуляции — которые, вопреки мнению автора, убивают чаще малый бизнес, ибо большие конторы тянут юристов и делопроизводителей, а мелкие нет — либо отложили принятие закона). Самым типичным итогом является штраф и хороший пиар для политика.
3. Современные люди настолько сильно погружены в социальные сети и медиа (которые в последние 5 лет перешли в модель извлечения денег на нагнетании зрителя — см. «Hate, Inc» Matt Taibbi), и их влияние настолько велико, что мы можем наблюдать в прямом эфире, где каждая половина пузыря верит в то, что вещает ее сторона, даже если факты и официальные результаты расследований / научные выводы противоречат narrative (и даже U-turn в вещании не отталкивает зрителей — например, про протесты в зависимости от повестки). Плюс, люди общаются в интернете в манере, к которой мы не эволюционировали (про это тоже много рассуждали), все продукты создаются с прицелом на подсаживание пользователя.
Это все гарантирует надежную защиту людей от рефлексии и от возможности организации в группы. И только принудительное отключение от системы, как в «Первому игроку приготовиться», или, скажем, кризис, может людей перевести в состояние реального мира.
4. В статье сделано неявное предположение, что именно инвестиции в образование дали результат в виде мозгов. Возможно, так оно и есть (хотя ИМХО тут много факторов). Однако это одна из частых мантр как раз одной из сторон в США. Тут первый вопрос — а что, если оно не так? В прошлом, в начале двадцатого века был взлет физиков. Сегодня нет такого количества гениев. Ранее был взлет математиков, или же художников. Вполне может быть, что появление талантов и гениев обуславливается множеством факторов — наличием спроса в историческом моменте, инвестициями в образование, перспективами больших зарплат в определенной сфере, общим духом общества и ожиданием инноваций и тд.
Во-вторых, само образование в США, за счет государственного регулирования, как показывает ряд исследований, имеет тенденцию ухудшаться в школах. Профсоюзы учителей делают замену слабых учителей невозможными, также они делают невозможными создание конкуренции среди школ. Не говоря про подгонку оценок. Не знаю, что там с колледжами, но когда вы создаете большое количество специалистов, не востребованных рынком, но со студенческим долгом — это создает отложенную проблему. Решится ли это просто вливом денег, а не перестройкой системы так, чтобы в ней были обратные связи, которые бы улучшали автоматически качество? Совсем не уверен.
Наконец, школы были созданы под рабочих времен индустриальной революции. Конвеерные рабочие, сидят в классе. Возможно, нам пора переосмыслить и индивидуализировать образование — оставить обязательную часть, но сделать больший упор на способности людей, чтобы их лучше подготовить к меняющемуся миру?
5. Монополизация рынка — естественное движение в процессе глобализации. Которая, как можно наблюдать, уже лет 10 плывет на заплатках. Когда управленческие силы, как это принято говорить в этих кругах, занимаются любимым «kick can down the road». Супердлинные логистические цепочки just-in-time, рынки с пузырями, корпорации, привыкшие к дешевому кредиту, перегруженный долгом потребитель — все это было очень хрупким (о чем не раз писал Талеб). На этой фазе роста неизбежно укрупнение, и какой-то из рисков должен был наступить (он и наступил).
В процессе перестройки системы и адаптации будет достигнут баланс между корпорациями и государством, бизнесами старыми и новыми. Возможно, новые поколения будут меньше подвержены влиянию информационного влияния — как сказал Джо Роган в одном из недавних подкастов, везде же есть магазины алкашки, но все же не стали алкоголиками.
Конечно, наступают роботы и автоматизация, где в новой экономике не нужно такое количество работников, и нужно будет искать выход. Как раз, кстати говоря, люди, которые живут и работают в системе корпорации, при этом продавая свои данные, которые генерят в результате ежедневной деятельности, за вознаграждение — вполне себе, на мой взгляд, нормальный вариант (лучше, чем раздача денег за красивые глаза в виде UBI). То есть если пользователи станут акционерами компаний с долей прибыли — почему бы и нет (см. AdSense). Или см. варианты Mark Blyth — Angrynomics (он рассматривает варианты решения неравенства иными способами).
В общем, процесс не столько фокусируется в противостоянии корпораций vs государство, сколько как результат глобальных изменений в результате информационной революции и смены технического уклада по всему миру, и грядущей смены экономической системы.
Отличный ответ на вопрос, зачем нужны алгоритмы и структуры данных (в комментариях нередко проскакивают эти темы).
Для решения крутых задач типа такой, и в ML / data science в целом.
и, кстати, если это вдруг утечка (хотя я склоняюсь к причудам природы, слишком уж часто и без лаборатории вирусы преодолевают межвидовой барьер), то учёные тут вряд ли виновны
Скорее, спонсоры исследований, ответственные за безопасность и менеджмент лаборатории
А найти причину очень важно
Ибо если он прыгнул со зверей — может быть там, и повторная вспышка неизбежна
А если утечка — надо менять стандарты и миром всем вырабатывать новые механизмы предотвращения
Для куда меньших мировых проблем делаются комиссии, которые разбирают все до мелочей. Будь то 9/11, авиакатастрофы, утечки в области атомной энергетики и тд
А тут — пандемия, грядущая рецессия и тд
Это нельзя оставить просто так. Нужно выявить причину, устранить ее и минимизировать вероятность повторения + повысить готовность мира к новым пандемиям
Так что да, мы все, обыватели, имеем в этом интерес и будем плотно следить и интересоваться
И даже, когда ученый правда виноват, — это должно обсуждаться в среде профессионалов, а не в телевизоре и интернет-порталах.
Дискуссия с опровержениями — правильный путь.
Снобизм и враньё «вирус мог быть только естественным», когда правильный ответ учёного-скептика звучит как «пока данных мало, есть только гипотезы» не делают чести.
Я понимаю for greater good, чтобы не оставлять поле дебилам-конспирологам, но давайте не будем думать, что все в публике тупые (как ВОЗ/CDC с их «маски не работают» на деле оказалось «лишь бы не скупили толпы, а то медперсоналу не хватит, а по маскам информация разная есть»).
Далее, 20 лет грантов и исследований. С кучи вспышек.
Почему уже 4 месяца люди методом проб и ошибок ищут лекарства, и нет вакцин опробованных? Зато куча исследований синтеза тех или иных вирусов?
Наймите пиар-менеджеров, спецы по коронавирусам уважаемые. Я знаю про решение для Эболы, которое распиарили. Напишите, как за 20 лет создали вакцины или лекарства от, не знаю, кошачьих коронавирусов, или там спасли миллионы жизней домашнего скота. Где выхлоп?
Вся соль в детализации требований, кто такой этот «программист».
Люди имеют в голове разные трактовки. При столкновении с чужим, отличным от своего, мнением возникает пресловутый когнитивный диссонанс, устранить который люди пытаются спором.
Вот на примере профессии «водитель».
1. Согласно ПДД
Водитель — лицо, управляющее каким-либо транспортным средством, погонщик, ведущий по дороге вьючных, верховых животных или стадо.
2. В бытовом понимании — водитель легковой или грузовой машины.
3. А еще есть водитель спортивного автомобиля.
Три этих трактовки под одним словом. И если пытаться требования к водителю спортивной машины предъявить рядовому водителю — это будет нелепо.
Так с чего же мы спорим о том, нужны алгоритмы или нет, или там знание определенных структур данных?
Точно так же
1. Если человек будет писать простые сайты на CMS — нафига ему алгоритмы? Гораздо важнее, чтобы он владел стэком front-endа, который сегодня переживает очередной бурный виток развития. Ибо за 1 день реакт или там ангулар не выучишь.
2. Если человек будет заниматься поддержкой и развитием, например, криптографического софта — его базовые алгоритмы, конечно, спросят. Но гораздо больше потенциальных работодателей будет интересовать знание матаппарата из соответствующей области (малая теорема Ферма какая-нибудь, гипотезу Танияма-Шимуры могут спросить ради интереса, или математику асимметричных алгоритмов шифрования типа RSA)
3. Если человека будут брать на Highload — скорее всего, спросят про архитектурный опыт. Про понимание, какие технологии он пробовал в боевых проектах, знает ли их слабые места (Redis, который забит весь, при падении не взлетит при перезагрузке сервера; какие-нибудь там распределенные файловые системы, тюнинг Postgres, или банальность, что нельзя кэш-файлы класть в одну папку — при огромном числе на определенных файловых системах читать оттуда будет очень долго).
4. Если человека будут брать на разработку SQL — спросят про индексы, про какие-то особенности работы оптимизаторов запросов, еще что-нибудь.
Ну а в конторы типа Гугла, Фейсбука и тд берут людей, которые имеют хорошее базовое фундаментальное образование — Computer Science + матан. Потому что да, там могут бросить человека и пилить фрэнд-фид в фейсбуке, и систему распознавания лиц на фотках, и даже вообще свою файловую систему или там транслятор PHP в плюсы / вариант виртуальной машины, чтобы не закупать 100500 новых серверов под растущий трафик.
И да, освоение базовой программы на уровне понимания дает гарантию, что у человека есть данные, такие, как талант к программированию в классическом понимании, хорошая память на технические штуки. Это дает гарантию, что мозги у него заточены от природы под такие задачи плюс в них вложено то, что должно быть вложено (=экономия средств компании на обучение).
В свою очередь можно сказать, что есть разные пути к успеху, и можно, не зная этих алгоритмов и не идя стандартным путем, при наличии большого таланта, сделать какой-нибудь крутой продукт (типа распознавания предметов или фильтрации спам-комментов — очень актуально, кстати), и тебя либо купят, либо возьмут вместе с командой.
tl;dr Конечным для компании является то, может ли человек решать задачи, которые будут перед ним вставать, хватит ли у него таланта и опыта. Отсеивают либо по стандартным параметрам (если освоил CS / матан => пойдет), либо по достижениям (успешные проекты на Гитхабе, или взлетевшие стартапы).
А вы, как кандидат, можете честно прикинуть, в чем вы сильны (или вас прет и вы можете стать сильны). И не пытаться втиснуться в прокрустово ложе чужих идеалов, а выбрать ваш путь.
Успехов вам в нашем нелегком деле. Ведь сегодня в мире — наше время.
Все норм.
А вообще то же умение дебажить — оно пипец как сложно.
Просто чем отличается мышление теоретика vs практика (если до предела упростить)?
Я строю алгоритм в голове/на бумаге, рассчитываю что он будет офигенно работать,
и запускаю… получаю какие-то баги. Работает не так, как задумано.
И если ПИПЕЦ УВЕРЕН что все правильно прикинул, сколько там памяти будет жрать и тд,
то ошибку не найдешь.
А если в голове имеешь опыт построения гипотез и их проверки (последовательно прикидывая возможные точки отказа),
то отладишь гораздо быстрее.
Тут стоит добавить, что есть типа еще BDD/TDD — в идеале и дебажить не нужно, сразу все работает и потом менять проще (сразу видишь по тестам, что поломал),
но в целом ряде областей веб-программирования, highload систем и тд многие вещи тестами
лишь имитируются (иногда через такую жопу, что страшно), либо вообще не воссоздаются в принципе.
В общем, чем больше знаешь и умеешь и в целом мозги круче — тем лучше из тебя программист
У вас открывается веб-страница, отрабатывают аякс-запросы, уходящие на поддомены.
Часть скриптов грузится с других поддоменов.
Удивительным образом один из поддоменов смотрит на сервак с другой версией кода,
чем тот, который вы тестируете (про дальнейшую цепочку распределения через балансировщики я не пишу).
Допереть, почему код в ответ на аякс запрос, возвращает не то, что нужно, хотя вроде бы работает,
могут далеко не все. Хотя когда знаешь ответ — это очевидно.
Кейс из жизни, если что.
Ну а про неверно прописанные NS-записи и глюки из-за этого думаю, у каждого полно историй из опыта.
Просто почему еще я про практику написал.
Дело в том, что есть немало тонких материй, которые пока слабо формализованы.
И более того, на деле теоретически верные штуки могут мешать.
Как пример, вспоминаю ООП и паттерны. Первая практика, красивый код, старался — вылизывал. И тут жестокие требования бизнеса вынудили раз переписать, два, три — и совсем по-другому начинаешь смотреть на красивости из классов-классов и более любовно на всякие DRY, KISS, YAGNI, unix way. Потом и как с SOLID готовить понимаешь, и прочие другие вещи.
То есть существуют разные способы сделать архитектуру внутри кода, спроектировать БД, выбрать стэк технологий и так далее. И нередко теоретически правильный и красивый может быть не нужен, а какой нужен, и когда нужно добавить правильности, а когда начисто делать сразу хорошо и идеально — дается только с опытом.
Я, кстати, за хорошую теоретическую базу, но без фанатизма. T-shaped, так они это называют.
А то мне вот нравится теория игр (и теория вероятностей, куда без нее), всякие там равновесия Нэша, но никогда не скажу человеку, если он не владеет ею, что он — не программист. Разве только спрошу, какая вероятность того, что среди группы из двух футбольных команд и тренеров будут одинаковые дни рождения ))
Кратко — не нужно противопоставлять теорию практике.
База нужна? во многих сферах, где трудятся программисты, без нее не подняться выше определенного уровня
Практический опыт и разный нужен? Да, без него в теории можно делать великие открытия и наука рулит. Но бизнесу нужна практика.
Можно ли неуважать коллег, кто не владеет знаниями/навыками, которые вы считаете мастхэв для тру? Можно, у нас свободная страна. Но это неэффективно для группы в целом, кмк.
1.Согласен про пользу понимания той же теории графов и тд для работы с сетями. Тут без нее никак, но и без знания теории работы сетей, и практического опыта сама по себе математика не делает вас сразу Developerом с большой буквы
2.Безопасность отнюдь не заключается только в криптографии.
Кстати, для ряда приложений различные алгоритмы шифрования. Я условил и детально разобрал для себя RSA (и ряд других известных), в дальнейшем остались лишь базовые принципы его работы в памяти. Но отнюдь не прошел полный курс, которые преподают шифровальщикам.
Мешало ли мне это в работе? Нисколько.
3.Вот в случае с архитектурой, стэком технологий, базой данных и так далее есть такая злая штука — в реальности они работают сильно сложнее и нередко совсем не так, как мы моделируем в нашем воображении. Иначе бы никаких тестов производительности, всяких A/B проверок архитектуры на устойчивость к нагрузке и прочее не требовалось бы.
Можно здесь вспомнить умную теорему про связь алгоритма, входных данных и предсказуемость результата; можно сказать про ненулевую вероятность ошибок в коде любого продукта, помноженную на сложность и объем современных систем и железа, что дает отличные от теории результаты.
Но я просто отмечу, что помимо теоретических расчетов и выбора тех или иных решений по масштабированию или оптимизации, всегда вылезают какие-нибудь баги кэша ядра FreeBSD и распределенные файловые системы, настроенные как рассчитано, сбоят; внезапно барахлит какая-нибудь мелочь в рейде и Гластер не работает, как ожидалось, или же банально разрекламированный в новой версии языка-не-будем-называть сборщик мусора при превышении определенных пределов устраивает дикие тормоза.
Поэтому знать и уметь основы Computer Science и… (допишите по вкусу) полезно и нужно. Но без практики и реальных боевых проектов, нагрузки, живого использования, развития и тд это сферический конь в вакууме (хотя и сферический конь в вакууме тоже может победить на скачках, как мы помним — только вот в каких)
Вообще, я имел в виду немного другое. Посылов несколько:
Утверждать, что алгоритмы являются необходимыми, можно.
Но что тогда мешает утверждать, что умение работать с указателями/памятью/подставьте сами также является необходимым, чтобы называться программистом с большой буквы.
Это вопрос точки зрения, и IMHO не к одним алгоритмам сводится минимальный набор знаний, навыков и паттернов мышления.
Также хотел подчеркнуть, что есть вещи, которыми мало озадачиваются те, кто бросается громкими фразами, по моей нерепрезентативной выборке. Про ту же архитектуру, про безопасность, про учет в разработке еще и как это будет поддерживаться админами хотя бы (аки учет всей стоимости владения автомобилем, а не его цены в салоне).
И что эти вещи приходят лишь с практикой, но начинаются с признания, что это тоже нужно изучать. They say, the first step is to admit you have a problem.
1. В статье проходит тезис: государство может служить в роли добра, а корпорации, превращающиеся в монополии, имеют тенденции быть злом.
Это так. Однако, государство и является монополией. Причем, без обратных связей в виде рынка и конкурентов, без нужды быть эффективными. А вот монополии регулярно обновляются — где сегодня Яху или Майспейс, или та же Нокиа?
2. Государство противопоставляется монополиям. Однако, если посмотреть открытые данные в упомянутых автором странах, то государство давно превратилось в источник извлечения прибыли чиновниками из корпораций (где чиновники пишут законы, а потом уходят в корпорации разъяснять, как его трактовать; и наоборот, корпорации приходят и донатят политикам, чтобы те либо приняли регуляции — которые, вопреки мнению автора, убивают чаще малый бизнес, ибо большие конторы тянут юристов и делопроизводителей, а мелкие нет — либо отложили принятие закона). Самым типичным итогом является штраф и хороший пиар для политика.
3. Современные люди настолько сильно погружены в социальные сети и медиа (которые в последние 5 лет перешли в модель извлечения денег на нагнетании зрителя — см. «Hate, Inc» Matt Taibbi), и их влияние настолько велико, что мы можем наблюдать в прямом эфире, где каждая половина пузыря верит в то, что вещает ее сторона, даже если факты и официальные результаты расследований / научные выводы противоречат narrative (и даже U-turn в вещании не отталкивает зрителей — например, про протесты в зависимости от повестки). Плюс, люди общаются в интернете в манере, к которой мы не эволюционировали (про это тоже много рассуждали), все продукты создаются с прицелом на подсаживание пользователя.
Это все гарантирует надежную защиту людей от рефлексии и от возможности организации в группы. И только принудительное отключение от системы, как в «Первому игроку приготовиться», или, скажем, кризис, может людей перевести в состояние реального мира.
4. В статье сделано неявное предположение, что именно инвестиции в образование дали результат в виде мозгов. Возможно, так оно и есть (хотя ИМХО тут много факторов). Однако это одна из частых мантр как раз одной из сторон в США. Тут первый вопрос — а что, если оно не так? В прошлом, в начале двадцатого века был взлет физиков. Сегодня нет такого количества гениев. Ранее был взлет математиков, или же художников. Вполне может быть, что появление талантов и гениев обуславливается множеством факторов — наличием спроса в историческом моменте, инвестициями в образование, перспективами больших зарплат в определенной сфере, общим духом общества и ожиданием инноваций и тд.
Во-вторых, само образование в США, за счет государственного регулирования, как показывает ряд исследований, имеет тенденцию ухудшаться в школах. Профсоюзы учителей делают замену слабых учителей невозможными, также они делают невозможными создание конкуренции среди школ. Не говоря про подгонку оценок. Не знаю, что там с колледжами, но когда вы создаете большое количество специалистов, не востребованных рынком, но со студенческим долгом — это создает отложенную проблему. Решится ли это просто вливом денег, а не перестройкой системы так, чтобы в ней были обратные связи, которые бы улучшали автоматически качество? Совсем не уверен.
Наконец, школы были созданы под рабочих времен индустриальной революции. Конвеерные рабочие, сидят в классе. Возможно, нам пора переосмыслить и индивидуализировать образование — оставить обязательную часть, но сделать больший упор на способности людей, чтобы их лучше подготовить к меняющемуся миру?
5. Монополизация рынка — естественное движение в процессе глобализации. Которая, как можно наблюдать, уже лет 10 плывет на заплатках. Когда управленческие силы, как это принято говорить в этих кругах, занимаются любимым «kick can down the road». Супердлинные логистические цепочки just-in-time, рынки с пузырями, корпорации, привыкшие к дешевому кредиту, перегруженный долгом потребитель — все это было очень хрупким (о чем не раз писал Талеб). На этой фазе роста неизбежно укрупнение, и какой-то из рисков должен был наступить (он и наступил).
В процессе перестройки системы и адаптации будет достигнут баланс между корпорациями и государством, бизнесами старыми и новыми. Возможно, новые поколения будут меньше подвержены влиянию информационного влияния — как сказал Джо Роган в одном из недавних подкастов, везде же есть магазины алкашки, но все же не стали алкоголиками.
Конечно, наступают роботы и автоматизация, где в новой экономике не нужно такое количество работников, и нужно будет искать выход. Как раз, кстати говоря, люди, которые живут и работают в системе корпорации, при этом продавая свои данные, которые генерят в результате ежедневной деятельности, за вознаграждение — вполне себе, на мой взгляд, нормальный вариант (лучше, чем раздача денег за красивые глаза в виде UBI). То есть если пользователи станут акционерами компаний с долей прибыли — почему бы и нет (см. AdSense). Или см. варианты Mark Blyth — Angrynomics (он рассматривает варианты решения неравенства иными способами).
В общем, процесс не столько фокусируется в противостоянии корпораций vs государство, сколько как результат глобальных изменений в результате информационной революции и смены технического уклада по всему миру, и грядущей смены экономической системы.
Для решения крутых задач типа такой, и в ML / data science в целом.
Авторам — респект.
Некоторые интересные материалы в тему.
— Типология культурных измерений Хофстеде
— Сергей Котырев — про национальные особенности менеджмента («Русская модель управления» + «Хофстеде» затрагиваются).
и, кстати, если это вдруг утечка (хотя я склоняюсь к причудам природы, слишком уж часто и без лаборатории вирусы преодолевают межвидовой барьер), то учёные тут вряд ли виновны
Скорее, спонсоры исследований, ответственные за безопасность и менеджмент лаборатории
А найти причину очень важно
Ибо если он прыгнул со зверей — может быть там, и повторная вспышка неизбежна
А если утечка — надо менять стандарты и миром всем вырабатывать новые механизмы предотвращения
Для куда меньших мировых проблем делаются комиссии, которые разбирают все до мелочей. Будь то 9/11, авиакатастрофы, утечки в области атомной энергетики и тд
А тут — пандемия, грядущая рецессия и тд
Это нельзя оставить просто так. Нужно выявить причину, устранить ее и минимизировать вероятность повторения + повысить готовность мира к новым пандемиям
Так что да, мы все, обыватели, имеем в этом интерес и будем плотно следить и интересоваться
Дискуссия с опровержениями — правильный путь.
Снобизм и враньё «вирус мог быть только естественным», когда правильный ответ учёного-скептика звучит как «пока данных мало, есть только гипотезы» не делают чести.
Я понимаю for greater good, чтобы не оставлять поле дебилам-конспирологам, но давайте не будем думать, что все в публике тупые (как ВОЗ/CDC с их «маски не работают» на деле оказалось «лишь бы не скупили толпы, а то медперсоналу не хватит, а по маскам информация разная есть»).
Далее, 20 лет грантов и исследований. С кучи вспышек.
Почему уже 4 месяца люди методом проб и ошибок ищут лекарства, и нет вакцин опробованных? Зато куча исследований синтеза тех или иных вирусов?
Наймите пиар-менеджеров, спецы по коронавирусам уважаемые. Я знаю про решение для Эболы, которое распиарили. Напишите, как за 20 лет создали вакцины или лекарства от, не знаю, кошачьих коронавирусов, или там спасли миллионы жизней домашнего скота. Где выхлоп?
Классная фраза, я бы взял как заголовок даже.
и я писал похожий по смыслу комментария пост
https://habrahabr.ru/post/279651/
Люди имеют в голове разные трактовки. При столкновении с чужим, отличным от своего, мнением возникает пресловутый когнитивный диссонанс, устранить который люди пытаются спором.
Вот на примере профессии «водитель».
1. Согласно ПДД
2. В бытовом понимании — водитель легковой или грузовой машины.
3. А еще есть водитель спортивного автомобиля.
Три этих трактовки под одним словом. И если пытаться требования к водителю спортивной машины предъявить рядовому водителю — это будет нелепо.
Так с чего же мы спорим о том, нужны алгоритмы или нет, или там знание определенных структур данных?
Точно так же
1. Если человек будет писать простые сайты на CMS — нафига ему алгоритмы? Гораздо важнее, чтобы он владел стэком front-endа, который сегодня переживает очередной бурный виток развития. Ибо за 1 день реакт или там ангулар не выучишь.
2. Если человек будет заниматься поддержкой и развитием, например, криптографического софта — его базовые алгоритмы, конечно, спросят. Но гораздо больше потенциальных работодателей будет интересовать знание матаппарата из соответствующей области (малая теорема Ферма какая-нибудь, гипотезу Танияма-Шимуры могут спросить ради интереса, или математику асимметричных алгоритмов шифрования типа RSA)
3. Если человека будут брать на Highload — скорее всего, спросят про архитектурный опыт. Про понимание, какие технологии он пробовал в боевых проектах, знает ли их слабые места (Redis, который забит весь, при падении не взлетит при перезагрузке сервера; какие-нибудь там распределенные файловые системы, тюнинг Postgres, или банальность, что нельзя кэш-файлы класть в одну папку — при огромном числе на определенных файловых системах читать оттуда будет очень долго).
4. Если человека будут брать на разработку SQL — спросят про индексы, про какие-то особенности работы оптимизаторов запросов, еще что-нибудь.
Ну а в конторы типа Гугла, Фейсбука и тд берут людей, которые имеют хорошее базовое фундаментальное образование — Computer Science + матан. Потому что да, там могут бросить человека и пилить фрэнд-фид в фейсбуке, и систему распознавания лиц на фотках, и даже вообще свою файловую систему или там транслятор PHP в плюсы / вариант виртуальной машины, чтобы не закупать 100500 новых серверов под растущий трафик.
И да, освоение базовой программы на уровне понимания дает гарантию, что у человека есть данные, такие, как талант к программированию в классическом понимании, хорошая память на технические штуки. Это дает гарантию, что мозги у него заточены от природы под такие задачи плюс в них вложено то, что должно быть вложено (=экономия средств компании на обучение).
В свою очередь можно сказать, что есть разные пути к успеху, и можно, не зная этих алгоритмов и не идя стандартным путем, при наличии большого таланта, сделать какой-нибудь крутой продукт (типа распознавания предметов или фильтрации спам-комментов — очень актуально, кстати), и тебя либо купят, либо возьмут вместе с командой.
tl;dr Конечным для компании является то, может ли человек решать задачи, которые будут перед ним вставать, хватит ли у него таланта и опыта. Отсеивают либо по стандартным параметрам (если освоил CS / матан => пойдет), либо по достижениям (успешные проекты на Гитхабе, или взлетевшие стартапы).
А вы, как кандидат, можете честно прикинуть, в чем вы сильны (или вас прет и вы можете стать сильны). И не пытаться втиснуться в прокрустово ложе чужих идеалов, а выбрать ваш путь.
Успехов вам в нашем нелегком деле. Ведь сегодня в мире — наше время.
А вообще то же умение дебажить — оно пипец как сложно.
Просто чем отличается мышление теоретика vs практика (если до предела упростить)?
Я строю алгоритм в голове/на бумаге, рассчитываю что он будет офигенно работать,
и запускаю… получаю какие-то баги. Работает не так, как задумано.
И если ПИПЕЦ УВЕРЕН что все правильно прикинул, сколько там памяти будет жрать и тд,
то ошибку не найдешь.
А если в голове имеешь опыт построения гипотез и их проверки (последовательно прикидывая возможные точки отказа),
то отладишь гораздо быстрее.
Тут стоит добавить, что есть типа еще BDD/TDD — в идеале и дебажить не нужно, сразу все работает и потом менять проще (сразу видишь по тестам, что поломал),
но в целом ряде областей веб-программирования, highload систем и тд многие вещи тестами
лишь имитируются (иногда через такую жопу, что страшно), либо вообще не воссоздаются в принципе.
В общем, чем больше знаешь и умеешь и в целом мозги круче — тем лучше из тебя программист
Часть скриптов грузится с других поддоменов.
Удивительным образом один из поддоменов смотрит на сервак с другой версией кода,
чем тот, который вы тестируете (про дальнейшую цепочку распределения через балансировщики я не пишу).
Допереть, почему код в ответ на аякс запрос, возвращает не то, что нужно, хотя вроде бы работает,
могут далеко не все. Хотя когда знаешь ответ — это очевидно.
Кейс из жизни, если что.
Ну а про неверно прописанные NS-записи и глюки из-за этого думаю, у каждого полно историй из опыта.
Просто почему еще я про практику написал.
Дело в том, что есть немало тонких материй, которые пока слабо формализованы.
И более того, на деле теоретически верные штуки могут мешать.
Как пример, вспоминаю ООП и паттерны. Первая практика, красивый код, старался — вылизывал. И тут жестокие требования бизнеса вынудили раз переписать, два, три — и совсем по-другому начинаешь смотреть на красивости из классов-классов и более любовно на всякие DRY, KISS, YAGNI, unix way. Потом и как с SOLID готовить понимаешь, и прочие другие вещи.
То есть существуют разные способы сделать архитектуру внутри кода, спроектировать БД, выбрать стэк технологий и так далее. И нередко теоретически правильный и красивый может быть не нужен, а какой нужен, и когда нужно добавить правильности, а когда начисто делать сразу хорошо и идеально — дается только с опытом.
Я, кстати, за хорошую теоретическую базу, но без фанатизма. T-shaped, так они это называют.
А то мне вот нравится теория игр (и теория вероятностей, куда без нее), всякие там равновесия Нэша, но никогда не скажу человеку, если он не владеет ею, что он — не программист. Разве только спрошу, какая вероятность того, что среди группы из двух футбольных команд и тренеров будут одинаковые дни рождения ))
База нужна? во многих сферах, где трудятся программисты, без нее не подняться выше определенного уровня
Практический опыт и разный нужен? Да, без него в теории можно делать великие открытия и наука рулит. Но бизнесу нужна практика.
Можно ли неуважать коллег, кто не владеет знаниями/навыками, которые вы считаете мастхэв для тру? Можно, у нас свободная страна. Но это неэффективно для группы в целом, кмк.
1.Согласен про пользу понимания той же теории графов и тд для работы с сетями. Тут без нее никак, но и без знания теории работы сетей, и практического опыта сама по себе математика не делает вас сразу Developerом с большой буквы
2.Безопасность отнюдь не заключается только в криптографии.
Кстати, для ряда приложений различные алгоритмы шифрования. Я условил и детально разобрал для себя RSA (и ряд других известных), в дальнейшем остались лишь базовые принципы его работы в памяти. Но отнюдь не прошел полный курс, которые преподают шифровальщикам.
Мешало ли мне это в работе? Нисколько.
3.Вот в случае с архитектурой, стэком технологий, базой данных и так далее есть такая злая штука — в реальности они работают сильно сложнее и нередко совсем не так, как мы моделируем в нашем воображении. Иначе бы никаких тестов производительности, всяких A/B проверок архитектуры на устойчивость к нагрузке и прочее не требовалось бы.
Можно здесь вспомнить умную теорему про связь алгоритма, входных данных и предсказуемость результата; можно сказать про ненулевую вероятность ошибок в коде любого продукта, помноженную на сложность и объем современных систем и железа, что дает отличные от теории результаты.
Но я просто отмечу, что помимо теоретических расчетов и выбора тех или иных решений по масштабированию или оптимизации, всегда вылезают какие-нибудь баги кэша ядра FreeBSD и распределенные файловые системы, настроенные как рассчитано, сбоят; внезапно барахлит какая-нибудь мелочь в рейде и Гластер не работает, как ожидалось, или же банально разрекламированный в новой версии языка-не-будем-называть сборщик мусора при превышении определенных пределов устраивает дикие тормоза.
Поэтому знать и уметь основы Computer Science и… (допишите по вкусу) полезно и нужно. Но без практики и реальных боевых проектов, нагрузки, живого использования, развития и тд это сферический конь в вакууме (хотя и сферический конь в вакууме тоже может победить на скачках, как мы помним — только вот в каких)
Но что тогда мешает утверждать, что умение работать с указателями/памятью/подставьте сами также является необходимым, чтобы называться программистом с большой буквы.
Это вопрос точки зрения, и IMHO не к одним алгоритмам сводится минимальный набор знаний, навыков и паттернов мышления.
И что эти вещи приходят лишь с практикой, но начинаются с признания, что это тоже нужно изучать. They say, the first step is to admit you have a problem.
Очень много инфраструктурных вещей и технологий под веб — Postgres, интерпретаторы PHP, Python (Cpython) и тд пишутся на нем
Крутой язык.