Comments

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

Статья понравилась, поэтому не упущу возможности попридираться.
«любой разработчик должен разбираться в бизнес-процессах».
Что это за бизнес-процессы разработчик поймет уже во время работы, а не поняв — не сможет написать что-то здравое.
«изучайте необходимый срез математики».
Какой именно? Когда наш программист узнает какая математика ему нужна — будет уже поздно. Математика большая. Очень. А база дается всем в институте на первых двух курсах.
«2-3 базовые книги по организационной психологии, конфликтологии и социальной психологии сделают вас продуманным собеседником».
А две-три книги по самбо, карате и боксу сделают вас нормальным рукопашником. )
Какой именно?

Матлог, конечно же!


Эта база даётся, кстати, очень мало кому.

Психические способности, в отличие от физических, развиваются легче и быстрее. В крайних случаях их отсутствие можно замаскировать.
Например, «токсичному Сергею» можно не учить психологию, а просто чаще улыбаться и держать свое мнение при себе, если его не спрашивают. Градус раздражения коллектива сразу снизится.
Потому что в скором времени программы без хоть каких-то зачатков ML/AI/нейросетей/BigData будут в ряде отстающих.
И прикручиваться этот функционал будет парой строчек обращения к готовому фреймворку/библиотеке, а математикой лежащей в основе будут заниматься разработчики фреймворка.
У меня есть небольшой секрет, как начать: купить любую продвинутую энциклопедию для детей или научно-популярную книгу о математике и погрузиться в атмосферу, освежить базовые термины. А там пойдёт и даже затянет.
Что бы без профильного образования разобраться в математике на уровне необходимом для понимания работы тех областей о которых Вы писали выше, на это надо потратить не один год регулярных занятий.
И надо хорошо понимать, что Вы планируете изучать и зачем, иначе эти сотни часов занятий будут потрачены впустую.
Но в первые же рабочие дни на хорошем проекте начинаются проблемы и становится очевидно, что учебные задачки, которые сделали тебя классным кодером, не имеют ничего общего с кодом в продакшене. Чтобы написать хороший, профессиональный код нужно разбираться в структурах данных и алгоритмах, уметь проектировать программное обеспечение. Мне приходилось видеть весьма толковых программистов, которые не использовали в работе массивы, деревья, связанные списки, сортировки и т.д.
Это забавно. Контекст: PHP, на некоторых галерах PHP + Python, немного JS. Сколько не менял рабочих мест, аутсорс, продуктовые компании, проекты вроде платёжных систем, бэк для кассовых систем и т.п., нигде не получалось толком осознанно применить алгоритмы и структуры данных. И единственное где их удаётся применить — это программистические (учебные) задачки, которые как раз ничего общего с кодом в продакшене не имеют. Мне вот тупо любопытно, это у меня одного так, или это распространённый кейс?
Микросервисы. Микросервисная архитектура решает многие проблемы безопасности, управления и эксплуатации высоконагруженных проектов, работы с огромными базами данных. Микросервисные архитектуры пока востребованы, в основном, крупными компаниями, но совсем скоро они шагнут и средний бизнес. Спрос на программиста с таким навыком будет ещё долго (пока наносервисы не изобретут).
А это случаем не отголоски хайпа, которые добавили в статью просто чтобы символов до норматива добрать?

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

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

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

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

Первый случай — если компания с крупными R&D отделами, то и алгоритмы и математика в ней будут. В поисковиках с такими задачами сталкиваешься. Не то чтобы каждый день, но периодически во что-нибудь влипаешь.
Второй случай — считается, что железо дешевле программистов, но иногда у разросшейся компании наступает момент, когда оказывается выгоднее заняться оптимизацией, а не закидывать пожары железками. И в такие времена всплывают все аккуратно разложенные по кодовой базе тройные циклы for.
А иногда к коду сразу жесткие требования предъявляют, в HFT, например.


Другое дело, что на собесах задавать алгоритмические задачи любят сейчас все, вне зависимости от необходимости их использования в дальнейшем. Это такой удобный способ хоть что-нибудь проверить у человека, когда просто не знаешь что проверять.
Слюна не капает — чекд, разворот дерева написал — чекд. Ок, берем.

Итак, что вам нужно для полного программистского счастья соответствия набора в конце 2020?

Структуры данных, алгоритмы, бизнес-процессы ит.д.

Неправильный ответ! Правильный — "Конечно же, наш VDS сервер по специальному тарифу"

2061 год — Академик-программист ищет проекты на фриланс. Знаю все. Умею все. Под каждый новый проект создаю новый язык программирования. Если чего-то не существует, придумаю, реализую, покрою тестами и отдам заказчику. :)

а софт-скилы где? да знаете, таких академиков как вы на каждом углу, чем вы лучше других?
Лучше не нанять лишнего хорошего академика, чем потратиться на релокацию плохого.
Интриган манипулятор. Имею базу посреди тихого океана, штат приспешников и несколько проектов на гитхабе.
Спасибо, мы вам перезвоним! На позицию джуна придется подучиться еще конечно…

))) а вообще очень повеселил ваш коммент! Интриган манипулятор, блин...))))
И это большая проблема: разработчики создают продукт просто по ТЗ, не ради удобства конкретных клиентов.

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

Разработка «просто по ТЗ» и разработка «с учетом своего взгляда на потребности клиента» — это взаимоисключающие процессы, поэтому странно видеть обвинение программистов в одном и другом одновременно в соседних предложениях.
Запросите у пользователя требования, соберите информацию о том, как продукт используется, выявите неудобные и удобные модули и функции — тогда получится и лучше, и проще.

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

Увы, но "кто-то при составлении ТЗ хреново поработал" — обычное дело. Нечетко сформулированные ТЗ, ТЗ с грубыми ошибками и серьезными противоречиями, вариантов осложнить жизнь исполнителю масса.
А спросят таки с программиста по полной. Вот и приходится вникать в предметную область и делать "хорошо клиенту", иногда даже вопреки ТЗ, чтобы клиент удовлетворился и принял работу. А если делать строго по ТЗ, то клиент будет недоволен со всеми вытекающими (или вообще ничего не получится, если ТЗ внутренне противоречиво).
Часто такое бывает в небольших проектах-шабашках, когда заказчик и руководитель группы разработчиков сами с трудом понимают, как оно должно быть.


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

У таких ребят две отличительных черты: 1) они упрямы и уверены в своём превосходстве;

Вся статья пропитана этим же.
Статья класс.
Но стоит сделать отметку на массовость джунов или будущих джунов среди читателей.
Понимание бизнес-процессов джуну не нужно. Он будет работать по сторям, созданным аналитиками, которые разжевали эти бизнес-процессы для конкретных одной-двух недель работы по СКРАМ, которые ему нарежет на задачи тимлид или синьор.
В процессе роста себя до мидла джун изучит это как необходимость.

А вот про софт скиллы… Видя такую дыру во многих, необязетельно разработчиков ПО, людях, становится очень страшно за школьное образование, которое должно как раз этому обучать. 11 классов закончил и «бе-ме» связать не можешь в беседе. Плохо.

Что-то не наблюдаю я такого. А наблюдаю совсем обратное. Отрасль движется в сторону дальнейшей специализации.


Честно скажите, сколько человек в вашей текущей команде знают на приличном уровне два языка и два стека технологий? Критерий "приличности": если человека перевести на другой участок, сроки не просядут на месяц.

Мне приходилось видеть весьма толковых программистов, которые не использовали в работе массивы, деревья, связанные списки, сортировки и т.д. У таких ребят две отличительных черты:

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

Если пиарщица или менеджер проектов нервно поправляет каре и говорит, что в компании «джавист Сергей токсичный», я знаю, что скорее всего джавист Сергей угнетает коллег своим объёмом знаний

А если такого джависта, за токсичность, посылает бородатый дядя, за плечами которого +100 500 проектов на десятке языков, что вы тогда о нем тогда думаете?
«массивы, деревья, связанные списки, сортировки» — это школьная программа 9-10 класса, где учат ими пользоваться

У меня такого в школе и близко не было. Ну или я полностью это пропустил, хотя занятия вроде бы не часто прогуливал.
Раньше может и не было, но последние 10 лет точно есть, по крайней мере периодически имею дело с программой разных школ, но это в основном Москва и подмосковье. Конечно это профили или факультативы, которые могут выбирать ученики. Но даже у меня в 8 классе 90-x годах был урок информатики на БК где массивы проходили, примитивно на уровне «тык мык».

Просто тут речь идет явно не о школьниках. А такой уровень это совсем азы. Это в мое время все это изучалось по затертым до дыр книжкам, а сейчас у всех все под носом.
Ну, в моё время дальше if else не ушли, а самым полезным занятием было настраивать WiFi сетку между новыми ПК на летних каникулах.
Потому что в скором времени программы без хоть каких-то зачатков ML/AI/нейросетей/BigData будут в ряде отстающих.

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

Читаешь такие статьи, осознаёшь свою никчёмность, погружаешься в уныние, начинаешь фантазировать о хаках не для слабонервных… :)


Когда, решая сложную задачу, озаряет: две головы - лучше!

image


Имплементируешь

image
image


И уже работаешь тандемом, профит!

image

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

Нет. По многолетнему опыту работы в хайтеке США. Все уже написано до вас в 90% случаев. Нужно знать, что оно есть и найти правильную библиотеку.

Мне приходилось видеть весьма толковых программистов,… я видел изобретённые заново сортировки и деревья, это страшно и странно.

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

Все это «нужно обязательно знать математику» и С++ с указателями типа ***, если честно, пустое. Без обид, извините.
нужно разбираться в структурах данных и алгоритмах
Нет. (...) Нужно знать, что оно есть и найти правильную библиотеку.

Так а где противоречие? Понять, что именно тебе нужно — это уже означает разбираться в вопросе. Зачастую достаточно даже меньшего — примерно представлять, в каком направлении копать, а далее найти нужное решение — дело техники и нескольких минут: идёшь на форум и пишешь «нужен компонент, который сажает льва в клетку»
Я имел в виду «знать, как именно алгоритм работает» (то, что на интервью спрашивают) супротив «знать, что он есть, и сложность у него такая-то, а как устроено — хз». То есть программеру на С, конечно, нужно знать массив супротив списка, и как он там реализуется с указателями и памятью, а в .NET можно не помнить этого совсем.

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

Мы, как говорят, in a violent agreement ;-)
Полностью согласен со статьей.

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

Любой проффесионал будет делать больше того, чем от него требуется на работе. Будет смотреть вокруг, что делается в его индустрии, какие тенденции и новые технологии появляются. Будет смотреть базу и основы тоже, в том числе и алгоритмы сортировки, деревья и связанные списки. Хотя бы потому, что это интересно и правильно разбираться в основах своей области, в ее истории. Ну и чтобы не изобретать велосипед, например. Более широкий кругозор всегда способствует поиску лучшего решения в своей повседневной работе.
Only those users with full accounts are able to leave comments. Log in, please.