Дети как раз справятся, а вот у некоторых взрослых с возрастом мозг действительно "стеклянеет" и начинает нести пассажи из серии "раньше была трава зеленее, да молодежь не та пошла". А молодежь 25-30 летней давности меж тем покупала ГДЗ(готовые домашние задания) и точно также не думала, а тупо списывала. Видимо надо было книги запретить?
Кто хочет учиться - будет ипользовать LLM для развития, кто не хочет - вы ему хоть всё запретите, он тупо домашку не будет делать и в школу не будет ходить.
У меня прямо противоположное мнение: в кино чудовищная монополия актеров, сутяжничество и сходящие с ума по звездам фанаты, готовые отрубить себе руку ради популярного взрослого дядьки, который мажет лицо гримом и кривляется на камеру. Да, Леонардо Ди Каприо крутой профессионал, но платят ему столько денег не за профессионализм, а за узнаваемость, потому что на фильм с Ди Каприо пойдут люди. А за его спиной куча актеров, которым не дали шанса, не хуже по профессионализму, да и фильм не сильно пострадает, если вместо Ди Каприо сыграет крепкий середнячок.
Приход ИИ в кино - это что-то вроде опенсурс в программировании, который удешевит съемки, представьте, что каждой команде не надо снимать взрыв грузовика за миллионы долларов, а можно скопипастить у чужого фильма, чуть модернизировав. Конечно при таком раскладе бенефициары/монополисты будут говорить, что ИИ не нужон, т.к. не будут получать свои миллионы благодаря Royalty.
начать писать сервис на тормознутом go, через пол года разработки, а потом + еще пару месяцев танцев с бубнами вокруг различного рода оптимизаций, в итоге поняв, что таки не можем выжать обещанный SLA, принять волевое решение переписать все на Assembler.
Возможно, тут я доверился автору, но в этой же книге, следующим абзацем он пишет, что был такой же холивар про языки высокого уровня(например, Delphi, Python) и языки низкого уровня. Вот эти споры я застал, так что суть особо не поменялась :)
Нет никакой базовой инженерной гигиены, спросите 10 разработчиков про неё, получите 10 различных определений.
API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн.
Вы следуете каким-то универсальным паттернам, а я говорю, что их нет. Каждый раз код пишется исходя из задачи и если у вас нет обоснования, почему нужно убрать лишних 50 полей, то значит вы зря потратили время на оптимизацию. "Нормальный дизайн" - это не обоснование, это маркер, что вы это делаете по привычке, а объяснить не можете.
Senior-а от Middle-а как раз таки отличает то, что Senior не делит подходы на черное и белое, а знает какой когда применять. В моем практике были кейсы и когда 50 полей хорошо и когда 50 полей зло. Когда нужны были uuid-ы, а когда делал внутренние id-и, чтобы не тратить время и их гораздо проще запомнить. Когда-то удобно было распилить монолит на микросервисы, а когда-то наоборот смержить в монолит.
Время идет, а старики всё также брюзжат на тему раньше было лучше.
И вот был разработан первый компилятор. Эту программу назвали Assembler, что переводится как "сборщик". Писать на нем практически так же сложно, как и в машинных кодах, однако теперь уже использовались не числа, а понятные, как показано на рис. 1.5, человеку слова.Теперь все та же команда копирования регистров выглядела так: mov eax, ebx. Да, код на ассемблере не совсем нагляден, но зато намного удобнее, чем то же самое, но в машинных кодах. Вроде все прекрасно и удобно, но почему-то среди программистов возникли споры и разногласия. Кто-то воспринял новый метод с удовольствием. А кто-то говорил, что машинные коды лучше, что программа, написанная в кодах, работает быстрее. Говорят, что эти споры доходили до драк и иногда лучшие друзья становились врагами.
Категорически не согласен, то, что вы называете путем добра - это преждевременная оптимизация и это путь зла. Сколько я таких мердж реквестов видел... Разработчик напишет, навертит и в итоге вместо 3х строчек кода я вижу 5 классов с кучей методов, я спрашиваю:
- Зачем?
- А вот когда у нас будет нагрузка, да 5 микросервисов, да шардинг бд...
- Ну щас же у нас такого нет, когда будет нагрузка, тогда и перепишем на твой варинт, а щас у тебя 5 классов по 3 метода в каждом вместо 3х строчек кода
- Ну нет, ну всё равно же, ну у меня же выдуманный мною мир рушится...
Оптимизация должна преследовать какую-то цель. Например, приходит бизнес и говорит: мы сделали исследование дизайна и обнаружили, что у нас страница грузится 500мс, часть пользователей не дожидается всей загрузки и уходит со страницы, если сократить загрузку до 5мс, то мы значительно повысим посещаемость. Разработчики: ок, переписываем на rust-е. У вас же цель, чтобы вам было прикольно, потому что вас триггерят слои абстракции и размер приложения - цель, которая нужна только вам и больше никому.
Аналогичная история, сначала годик был на ubuntu, но там как раз сменился gnome на unity, повылезали глюки и я решели попробовать Минт. А там сразу из коробки и java и проприетарные пакеты установились, короче всё работало без дополнительных настроек. Из минусов - постоянно спрашивали: "А чё за Минт, почему не Убунту?"
Можно плыть по течению, можно плыть против течения, а можно плыть туда куда надо. Хотите плыть, туда куда ведет вас Whoop - ваш выбор, для меня это пустой звук. А вот 13% жира - очень круто, я бы такое хотел.
Ну мне в зависимости от количества жира десятку скидывало. Причем разница была в 3кг(20% -> 17%). Приятно когда пишет, но это всё кликбейт. Да и вообще непонятно что это за метрика такая - биологический возраст
Так мотивация была понятна заранее - человек пришел, нелюбопытный, не задает вопросы. Вы сами же говорите - это неправильно, вот тебе инструкция, надо позадавать вопросы, такие задавай, такие не задавай. Сами его призываете "активно применять лабуду".
В заголовке, да и в самой статье вы сами пишите если хотите увеличить шансы пройти собеседования, то задавайте вопросы.
Про смысл я написал в 5 пунктах, начиная с "напишу, почему это так важно для руководителя:"
Можете пояснить, пожалуйста, я не пойму. Вот я кандидат пофигист, я не особо любопытен, мне неинтересна миссия компании, но я прочитал вашу статью и чтобы повысить шансы я подготоваливаю вопросы к собеседованию про миссию компании, про культуру в команде, про слабые и сильные места. Про печеньки не спрашиваю, но придумываю вопрос котороый вызовет азарт. Портрет мой не поменялся, как я был нелюбопытным, так им и остался. Что в итоге это дало руководителю?
Вообще не понимаю смысла таких статей. Ок, вы придумали какую-то свою корелляцию "не задает вопросы - плохо будет работать", но потом вы тут же пишите статью-инструкцию в которой объясняете,что чтобы попасть к вам надо позадавать вопросы. Канидаты её читают и понимают, чтобы пройти собеседование им надо задавать вопросы и, собственно, так и делают как их просят. Скил у них при этом не поменялся, кто был нелюбопытным, то нелюбопытным и остался. В чем смысл?
Ответ прост: чтобы заметить, что вам нужны алгоритмы, вам надо эти алгоритмы на достаточно хорошем уровне знать.
Как-то этот "простой" ответ идет вразрез с моим опытом. Если вы перечитайте мой первый пост, то увидите, что я замечал алгоритмы ДО того как знал на хорошем уровне, а когда знал их на хорошем уровне, то они мне не пригождались. Или может быть с вашей точки зрения хороший уровень знания по алгоритмам - это 2000 часов на литкоде?
Вообще, любая программа (если только не на HTML /s) - это алгоритм по определению.
А любой алгоритм/программа - это также еще и функция. Обязательно ли знать математический анализ, теоритическую логику(прям на таком уровне, что программисту университетскую задачу и просим решить) для того чтобы программировать? В общем случае - нет. В частных случаях бывает, что на какой-то работе прям потребуется(да ml тот же), ну и если вы хорошо знаете мат. анализ вполне возможно, что где-то вы воспользуетесь этим навыком и он поможет вам быстрее решить задачу по программированию. Мне, например, мат. база пригождалась, в так скажем, json-укладке, где вообще этого никто бы не ожидал. Но ходить и говорить, "люди математика - это база в программировании, все на stepic, вот у меня 10 кейсов- примеров", я точно не буду :)
Мой простой ответ таков(он собственно был уже написан в моем посте): есть программисты, которым пригождаются алгоритмы, есть, которым нет - возможно у последних задач нет по алгоритмам, а может они на другой навык ставку делают, что тоже вполне нормально, т.к. все навыки освоить невозможно.
Поскольку вы ответили на мой комментарий, то тогда продолжу дискуссию. Есть два человека: одному алгоритмы пригодились, другому нет. Какой тут вывод можно сделать? :)
Полностью согласен с вами, с языком очень хороший пример. Можно было бы сделать аналогичную статью про то, что fluent english - это база для программиста и вот у меня вот 45 примеров, как он пригодился в реальной жизни. Просто у людей так мышление устроено: они осваивают какой-то навык, начинают его применять, добиваются какого-то успеха и считают, что их путь единственно верный. Хотя на самом деле - это просто один из путей. Поговорка даже есть такая: освоивший молоток в каждой проблеме видит гвоздь.
Мне алгоритмы пригодились буквально 1 раз в начале моего карьерного пути, когда я был не то джуном и не то мидлом, в 2013 году. Я писал свой вариант поиска в ширину по графам, потому что библиотечная реализация не подходила. В то время алгоритмы не спрашивали ни в яндексе, ни в гугле(да, были и такие времена). Но вот сумел как-то без литкода разобраться, вспомнить университетскую программу по графам, да гугл помог. А уже потом появился тренд на собеседования по алгоритмам, тут уже хочешь не хочешь, но пришлось обогатить знания по ним. Я, конечно, не 2000, но часов 20-40 на теорию и практику потратил, в целом могу сказать, что на практике мне это пригодилось как "вложенный цикл - это O квадрат, так низя". Поскольку литкод я особо не нарешивал, то как результат имею 5-7 заваленных секций по алгоритмам(не в 0 конечно, но и не на 100% чисто), а также следующие из этого результата комментарии "фу, не программист, это база" на хабре :)
В реальности, чтобы погрузиться в проект на новой работе и начать приносить пользу нужно минимум 2-3 месяца
Я такое помню лет 12 назад, когда у нас не было никаких процессов, ни agile, мы наняли разработчика, он просидел месяц, чето там разбирался, пытался что-то накодить, но в итоге за этот месяц нифига не сделал, ни одного реквеста.
Сейчас то как такое возможно? В эпоху эффективности, софт-скиловости, agile, скрам-канбан. Ко мне приходили новички, нарезаешь им адекватные задачки, они за 2-3 дня их делают. И оценивать их как раз за 2 недели работы приходилось. Ну ок, потратят они день-два на то, чтобы проект поднять. Но потом пару задач он должен сделать, не сделал ни одной, ну тогда большие вопросы. Так что вообще не понимаю про что вы говорите и как так у вас процессы устроены.
Дети как раз справятся, а вот у некоторых взрослых с возрастом мозг действительно "стеклянеет" и начинает нести пассажи из серии "раньше была трава зеленее, да молодежь не та пошла". А молодежь 25-30 летней давности меж тем покупала ГДЗ(готовые домашние задания) и точно также не думала, а тупо списывала. Видимо надо было книги запретить?
Кто хочет учиться - будет ипользовать LLM для развития, кто не хочет - вы ему хоть всё запретите, он тупо домашку не будет делать и в школу не будет ходить.
Железка стоит миллион рублей, взрыв грузовика миллион долларов...
У меня прямо противоположное мнение: в кино чудовищная монополия актеров, сутяжничество и сходящие с ума по звездам фанаты, готовые отрубить себе руку ради популярного взрослого дядьки, который мажет лицо гримом и кривляется на камеру. Да, Леонардо Ди Каприо крутой профессионал, но платят ему столько денег не за профессионализм, а за узнаваемость, потому что на фильм с Ди Каприо пойдут люди. А за его спиной куча актеров, которым не дали шанса, не хуже по профессионализму, да и фильм не сильно пострадает, если вместо Ди Каприо сыграет крепкий середнячок.
Приход ИИ в кино - это что-то вроде опенсурс в программировании, который удешевит съемки, представьте, что каждой команде не надо снимать взрыв грузовика за миллионы долларов, а можно скопипастить у чужого фильма, чуть модернизировав. Конечно при таком раскладе бенефициары/монополисты будут говорить, что ИИ не нужон, т.к. не будут получать свои миллионы благодаря Royalty.
Я тоже так умею:
Возможно, тут я доверился автору, но в этой же книге, следующим абзацем он пишет, что был такой же холивар про языки высокого уровня(например, Delphi, Python) и языки низкого уровня. Вот эти споры я застал, так что суть особо не поменялась :)
Нет никакой базовой инженерной гигиены, спросите 10 разработчиков про неё, получите 10 различных определений.
Вы следуете каким-то универсальным паттернам, а я говорю, что их нет. Каждый раз код пишется исходя из задачи и если у вас нет обоснования, почему нужно убрать лишних 50 полей, то значит вы зря потратили время на оптимизацию. "Нормальный дизайн" - это не обоснование, это маркер, что вы это делаете по привычке, а объяснить не можете.
Senior-а от Middle-а как раз таки отличает то, что Senior не делит подходы на черное и белое, а знает какой когда применять. В моем практике были кейсы и когда 50 полей хорошо и когда 50 полей зло. Когда нужны были uuid-ы, а когда делал внутренние id-и, чтобы не тратить время и их гораздо проще запомнить. Когда-то удобно было распилить монолит на микросервисы, а когда-то наоборот смержить в монолит.
Время идет, а старики всё также брюзжат на тему раньше было лучше.
Библия Delphi, 2007й год.
Категорически не согласен, то, что вы называете путем добра - это преждевременная оптимизация и это путь зла. Сколько я таких мердж реквестов видел... Разработчик напишет, навертит и в итоге вместо 3х строчек кода я вижу 5 классов с кучей методов, я спрашиваю:
- Зачем?
- А вот когда у нас будет нагрузка, да 5 микросервисов, да шардинг бд...
- Ну щас же у нас такого нет, когда будет нагрузка, тогда и перепишем на твой варинт, а щас у тебя 5 классов по 3 метода в каждом вместо 3х строчек кода
- Ну нет, ну всё равно же, ну у меня же выдуманный мною мир рушится...
Оптимизация должна преследовать какую-то цель. Например, приходит бизнес и говорит: мы сделали исследование дизайна и обнаружили, что у нас страница грузится 500мс, часть пользователей не дожидается всей загрузки и уходит со страницы, если сократить загрузку до 5мс, то мы значительно повысим посещаемость. Разработчики: ок, переписываем на rust-е. У вас же цель, чтобы вам было прикольно, потому что вас триггерят слои абстракции и размер приложения - цель, которая нужна только вам и больше никому.
Жду когда будет статья с заголовком "Бессовестные волки заучивают решения лайвкодинг задач и ломают нам найм"
Аналогичная история, сначала годик был на ubuntu, но там как раз сменился gnome на unity, повылезали глюки и я решели попробовать Минт. А там сразу из коробки и java и проприетарные пакеты установились, короче всё работало без дополнительных настроек. Из минусов - постоянно спрашивали: "А чё за Минт, почему не Убунту?"
Можно плыть по течению, можно плыть против течения, а можно плыть туда куда надо. Хотите плыть, туда куда ведет вас Whoop - ваш выбор, для меня это пустой звук. А вот 13% жира - очень круто, я бы такое хотел.
Ну мне в зависимости от количества жира десятку скидывало. Причем разница была в 3кг(20% -> 17%). Приятно когда пишет, но это всё кликбейт. Да и вообще непонятно что это за метрика такая - биологический возраст
Так мотивация была понятна заранее - человек пришел, нелюбопытный, не задает вопросы. Вы сами же говорите - это неправильно, вот тебе инструкция, надо позадавать вопросы, такие задавай, такие не задавай. Сами его призываете "активно применять лабуду".
В заголовке, да и в самой статье вы сами пишите если хотите увеличить шансы пройти собеседования, то задавайте вопросы.
Можете пояснить, пожалуйста, я не пойму. Вот я кандидат пофигист, я не особо любопытен, мне неинтересна миссия компании, но я прочитал вашу статью и чтобы повысить шансы я подготоваливаю вопросы к собеседованию про миссию компании, про культуру в команде, про слабые и сильные места. Про печеньки не спрашиваю, но придумываю вопрос котороый вызовет азарт. Портрет мой не поменялся, как я был нелюбопытным, так им и остался. Что в итоге это дало руководителю?
Вообще не понимаю смысла таких статей. Ок, вы придумали какую-то свою корелляцию "не задает вопросы - плохо будет работать", но потом вы тут же пишите статью-инструкцию в которой объясняете,что чтобы попасть к вам надо позадавать вопросы. Канидаты её читают и понимают, чтобы пройти собеседование им надо задавать вопросы и, собственно, так и делают как их просят. Скил у них при этом не поменялся, кто был нелюбопытным, то нелюбопытным и остался. В чем смысл?
Как-то этот "простой" ответ идет вразрез с моим опытом. Если вы перечитайте мой первый пост, то увидите, что я замечал алгоритмы ДО того как знал на хорошем уровне, а когда знал их на хорошем уровне, то они мне не пригождались. Или может быть с вашей точки зрения хороший уровень знания по алгоритмам - это 2000 часов на литкоде?
А любой алгоритм/программа - это также еще и функция. Обязательно ли знать математический анализ, теоритическую логику(прям на таком уровне, что программисту университетскую задачу и просим решить) для того чтобы программировать? В общем случае - нет. В частных случаях бывает, что на какой-то работе прям потребуется(да ml тот же), ну и если вы хорошо знаете мат. анализ вполне возможно, что где-то вы воспользуетесь этим навыком и он поможет вам быстрее решить задачу по программированию. Мне, например, мат. база пригождалась, в так скажем, json-укладке, где вообще этого никто бы не ожидал. Но ходить и говорить, "люди математика - это база в программировании, все на stepic, вот у меня 10 кейсов- примеров", я точно не буду :)
Мой простой ответ таков(он собственно был уже написан в моем посте): есть программисты, которым пригождаются алгоритмы, есть, которым нет - возможно у последних задач нет по алгоритмам, а может они на другой навык ставку делают, что тоже вполне нормально, т.к. все навыки освоить невозможно.
Поскольку вы ответили на мой комментарий, то тогда продолжу дискуссию. Есть два человека: одному алгоритмы пригодились, другому нет. Какой тут вывод можно сделать? :)
Полностью согласен с вами, с языком очень хороший пример. Можно было бы сделать аналогичную статью про то, что fluent english - это база для программиста и вот у меня вот 45 примеров, как он пригодился в реальной жизни. Просто у людей так мышление устроено: они осваивают какой-то навык, начинают его применять, добиваются какого-то успеха и считают, что их путь единственно верный. Хотя на самом деле - это просто один из путей. Поговорка даже есть такая: освоивший молоток в каждой проблеме видит гвоздь.
А вам пригодились алгоритмы в реальной жизни?
Мне алгоритмы пригодились буквально 1 раз в начале моего карьерного пути, когда я был не то джуном и не то мидлом, в 2013 году. Я писал свой вариант поиска в ширину по графам, потому что библиотечная реализация не подходила. В то время алгоритмы не спрашивали ни в яндексе, ни в гугле(да, были и такие времена). Но вот сумел как-то без литкода разобраться, вспомнить университетскую программу по графам, да гугл помог. А уже потом появился тренд на собеседования по алгоритмам, тут уже хочешь не хочешь, но пришлось обогатить знания по ним. Я, конечно, не 2000, но часов 20-40 на теорию и практику потратил, в целом могу сказать, что на практике мне это пригодилось как "вложенный цикл - это O квадрат, так низя". Поскольку литкод я особо не нарешивал, то как результат имею 5-7 заваленных секций по алгоритмам(не в 0 конечно, но и не на 100% чисто), а также следующие из этого результата комментарии "фу, не программист, это база" на хабре :)
Я такое помню лет 12 назад, когда у нас не было никаких процессов, ни agile, мы наняли разработчика, он просидел месяц, чето там разбирался, пытался что-то накодить, но в итоге за этот месяц нифига не сделал, ни одного реквеста.
Сейчас то как такое возможно? В эпоху эффективности, софт-скиловости, agile, скрам-канбан. Ко мне приходили новички, нарезаешь им адекватные задачки, они за 2-3 дня их делают. И оценивать их как раз за 2 недели работы приходилось. Ну ок, потратят они день-два на то, чтобы проект поднять. Но потом пару задач он должен сделать, не сделал ни одной, ну тогда большие вопросы. Так что вообще не понимаю про что вы говорите и как так у вас процессы устроены.