Comments 35
Один только псевдо сленг написания сего опуса вызывает позывы. Все эти скиллы, токсичность и тд и тп.
"… тенденции подбора персонала тяготели к одному и тому же: модульности, дискретности.." ага. Зато сейчас все размыто и рамазано так, что концов не найти, а в качестве мега решений каждый тулит свою очередную поделку "фреймворк"…
«любой разработчик должен разбираться в бизнес-процессах».
Что это за бизнес-процессы разработчик поймет уже во время работы, а не поняв — не сможет написать что-то здравое.
«изучайте необходимый срез математики».
Какой именно? Когда наш программист узнает какая математика ему нужна — будет уже поздно. Математика большая. Очень. А база дается всем в институте на первых двух курсах.
«2-3 базовые книги по организационной психологии, конфликтологии и социальной психологии сделают вас продуманным собеседником».
А две-три книги по самбо, карате и боксу сделают вас нормальным рукопашником. )
Например, «токсичному Сергею» можно не учить психологию, а просто чаще улыбаться и держать свое мнение при себе, если его не спрашивают. Градус раздражения коллектива сразу снизится.
Потому что в скором времени программы без хоть каких-то зачатков ML/AI/нейросетей/BigData будут в ряде отстающих.И прикручиваться этот функционал будет парой строчек обращения к готовому фреймворку/библиотеке, а математикой лежащей в основе будут заниматься разработчики фреймворка.
У меня есть небольшой секрет, как начать: купить любую продвинутую энциклопедию для детей или научно-популярную книгу о математике и погрузиться в атмосферу, освежить базовые термины. А там пойдёт и даже затянет.Что бы без профильного образования разобраться в математике на уровне необходимом для понимания работы тех областей о которых Вы писали выше, на это надо потратить не один год регулярных занятий.
И надо хорошо понимать, что Вы планируете изучать и зачем, иначе эти сотни часов занятий будут потрачены впустую.
Хе. Такой же вопрос. Единственное где пришлось применять алгоритмы это собеседование в компанию в Германии. Там были и деревья поиска и динамическое программирование. На работе же все свелось к обычному рест апи и верстка сайта. Вы либо используете библиотеки и готовые решения и решаете пресловутую бизнес задачу, либо вы пишите алгоритмы и создаёте библиотеки для тех кто решает бизнес задачи.
Конечно, есть небольшой процент компаний, где алгоритмы нужны, но такие еще найти надо и попасть в них. А где нужна математика, таких еще меньше.
Я бы и сам с удовольствием на работе писал бы алгоритмы, т.к. это и интересно и для мозга тренировка. Но, реальные задачи совсем другие.
Мне вот тупо любопытно, это у меня одного так, или это распространённый кейс?
Первый случай — если компания с крупными R&D отделами, то и алгоритмы и математика в ней будут. В поисковиках с такими задачами сталкиваешься. Не то чтобы каждый день, но периодически во что-нибудь влипаешь.
Второй случай — считается, что железо дешевле программистов, но иногда у разросшейся компании наступает момент, когда оказывается выгоднее заняться оптимизацией, а не закидывать пожары железками. И в такие времена всплывают все аккуратно разложенные по кодовой базе тройные циклы for.
А иногда к коду сразу жесткие требования предъявляют, в HFT, например.
Другое дело, что на собесах задавать алгоритмические задачи любят сейчас все, вне зависимости от необходимости их использования в дальнейшем. Это такой удобный способ хоть что-нибудь проверить у человека, когда просто не знаешь что проверять.
Слюна не капает — чекд, разворот дерева написал — чекд. Ок, берем.
Итак, что вам нужно для полного программистского счастья соответствия набора в конце 2020?
Структуры данных, алгоритмы, бизнес-процессы ит.д.
Неправильный ответ! Правильный — "Конечно же, наш VDS сервер по специальному тарифу"
Evil Genius, Вы?
))) а вообще очень повеселил ваш коммент! Интриган манипулятор, блин...))))
И это большая проблема: разработчики создают продукт просто по ТЗ, не ради удобства конкретных клиентов.
Так суть в том, что ТЗ уже должен учитывать удобство продукта для конкретных клиентов. Если ТЗ этого не учитывает, то кто-то при составлении ТЗ хреново поработал.
Поэтому, если вам важно быть эффективным и создавать ценный, продаваемый (для пользы вашей зарплаты) продукт, создавайте его с учётом потребностей клиента, а не с учётом своего взгляда на потребности.
Разработка «просто по ТЗ» и разработка «с учетом своего взгляда на потребности клиента» — это взаимоисключающие процессы, поэтому странно видеть обвинение программистов в одном и другом одновременно в соседних предложениях.
Запросите у пользователя требования, соберите информацию о том, как продукт используется, выявите неудобные и удобные модули и функции — тогда получится и лучше, и проще.
Лучше возможно получится, но проще вряд ли. Потому что механики запросов у пользователя подобной информации — это отдельный пласт знаний, техник и т.д. И зачастую отдельная профессия.
Так суть в том, что ТЗ уже должен учитывать удобство продукта для конкретных клиентов. Если ТЗ этого не учитывает, то кто-то при составлении ТЗ хреново поработал.
Увы, но "кто-то при составлении ТЗ хреново поработал" — обычное дело. Нечетко сформулированные ТЗ, ТЗ с грубыми ошибками и серьезными противоречиями, вариантов осложнить жизнь исполнителю масса.
А спросят таки с программиста по полной. Вот и приходится вникать в предметную область и делать "хорошо клиенту", иногда даже вопреки ТЗ, чтобы клиент удовлетворился и принял работу. А если делать строго по ТЗ, то клиент будет недоволен со всеми вытекающими (или вообще ничего не получится, если ТЗ внутренне противоречиво).
Часто такое бывает в небольших проектах-шабашках, когда заказчик и руководитель группы разработчиков сами с трудом понимают, как оно должно быть.
Иногда нечеткие ТЗ — это не баг, а фича. ТЗ приходит изначально в максимально нечетком виде и уточняется уже в процессе разработки, причем в его формировании и трансформации принимают участие все, включая программиста, который оценивает возможность реализации в указанные сроки и свое видение "как лучше для конечного пользователя".
Может быть только самые младшие разработчики не принимают участие в разборках по ТЗ, а только смотрят, слушают и учатся.
У таких ребят две отличительных черты: 1) они упрямы и уверены в своём превосходстве;
Вся статья пропитана этим же.
Но стоит сделать отметку на массовость джунов или будущих джунов среди читателей.
Понимание бизнес-процессов джуну не нужно. Он будет работать по сторям, созданным аналитиками, которые разжевали эти бизнес-процессы для конкретных одной-двух недель работы по СКРАМ, которые ему нарежет на задачи тимлид или синьор.
В процессе роста себя до мидла джун изучит это как необходимость.
А вот про софт скиллы… Видя такую дыру во многих, необязетельно разработчиков ПО, людях, становится очень страшно за школьное образование, которое должно как раз этому обучать. 11 классов закончил и «бе-ме» связать не можешь в беседе. Плохо.
Что-то не наблюдаю я такого. А наблюдаю совсем обратное. Отрасль движется в сторону дальнейшей специализации.
Честно скажите, сколько человек в вашей текущей команде знают на приличном уровне два языка и два стека технологий? Критерий "приличности": если человека перевести на другой участок, сроки не просядут на месяц.
Мне приходилось видеть весьма толковых программистов, которые не использовали в работе массивы, деревья, связанные списки, сортировки и т.д. У таких ребят две отличительных черты:
Одна из них — мифические существа, которые разрабатывают фреймворки. Весь этот список «массивы, деревья, связанные списки, сортировки» — это школьная программа 9-10 класса, где учат ими пользоваться, а не реализовывать. Можно подумать что человека выгнали из школы, и вместо (вместе) профильного образования он решил заняться программированием вроде как для хобби.
Если пиарщица или менеджер проектов нервно поправляет каре и говорит, что в компании «джавист Сергей токсичный», я знаю, что скорее всего джавист Сергей угнетает коллег своим объёмом знаний
А если такого джависта, за токсичность, посылает бородатый дядя, за плечами которого +100 500 проектов на десятке языков, что вы тогда о нем тогда думаете?
Просто тут речь идет явно не о школьниках. А такой уровень это совсем азы. Это в мое время все это изучалось по затертым до дыр книжкам, а сейчас у всех все под носом.
Читаешь такие статьи, осознаёшь свою никчёмность, погружаешься в уныние, начинаешь фантазировать о хаках не для слабонервных… :)
Нет. По многолетнему опыту работы в хайтеке США. Все уже написано до вас в 90% случаев. Нужно знать, что оно есть и найти правильную библиотеку.
Мне приходилось видеть весьма толковых программистов,… я видел изобретённые заново сортировки и деревья, это страшно и странно.
Их проблема в том, что они не знают, что алгоритмы и реализации уже есть. Это не то же самое, что уметь воспроизвести из по памяти. По памяти лучше всего воспроизводят вчерашние выпускники ибо они только что экзамен по этому сдали. Хороший, годный, опытный разработчик уже забыл 90% этого. Но он знает, что таковые есть и найдет их.
Все это «нужно обязательно знать математику» и С++ с указателями типа ***, если честно, пустое. Без обид, извините.
нужно разбираться в структурах данных и алгоритмах
Нет. (...) Нужно знать, что оно есть и найти правильную библиотеку.
Так а где противоречие? Понять, что именно тебе нужно — это уже означает разбираться в вопросе. Зачастую достаточно даже меньшего — примерно представлять, в каком направлении копать, а далее найти нужное решение — дело техники и нескольких минут
Я интервьюировал довольно много народа по долгу службы, и не заметил, чтобы сильно подкованные в алгоритмах росли потом лучше. Бывало часто наоборот, эксперт уж слишком заморачивается с деталями, и теряет оную «big picture».
Мы, как говорят, in a violent agreement ;-)
Сейчас начал читать книгу Роберта Мартина «Чистая Архитектура» и возникает мысль что проффесионал, который хочет разбираться в архитектуре, не может этого сделать ничего не зная про бизнесс правила, например. Он не сможет правильно продумать архитектуру, правильно разделить классы между компонентами. Ничего не зная про предметную область, про потребности клиента, он не сможет адекватно и осознанно написать ни строчки кода под данную задачу. Он будет делать это слепо, механически. А любое слепое, механическое написание кода строго по спецификации может быть заменено на автомат, робот или ИИ с точки зрения парадигмы автоматизации процессов.
Любой проффесионал будет делать больше того, чем от него требуется на работе. Будет смотреть вокруг, что делается в его индустрии, какие тенденции и новые технологии появляются. Будет смотреть базу и основы тоже, в том числе и алгоритмы сортировки, деревья и связанные списки. Хотя бы потому, что это интересно и правильно разбираться в основах своей области, в ее истории. Ну и чтобы не изобретать велосипед, например. Более широкий кругозор всегда способствует поиску лучшего решения в своей повседневной работе.
Программист 2020: Терминатор отдыхает