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

Воспользуюсь сообщением из другого топика.

Автор: Denwer
Дата: 09.07.21

ЭФ>Категорически не согласен. Их учат правильно физически защищать помещения,
ЭФ>анализировать трафик и куче другой админской специфики.

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

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

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

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

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

Избавить в том смысле, как научить "плохих" программистов, развиваться? Как заронить в их головах искру сомнения — а может я что-то делаю не так?

===

Тема очень актуальна для России, так как хакеров явно хватает, а вот технологов явно нет.
Что делать? Жесткая атестация? Принудительные курсы повышения квалификации?

I>Тема очень актуальна для России, так как хакеров явно хватает, а вот технологов явно нет.

Что-то сомневаюсь. Одни технологи кругом, своей головой подумать мало кто может.

I>Как избавить компанию от "плохих" программистов которые не хотят развиваться в сторону правильных архитектурных решений, а упорно стоят на позиции что хороший программист это тот который умеет писать сложный код. )
Никак, пока человек не пройдет весь путь:
1) Напишет свою архтектуру, а через пару лет вознинет необходимость переделывать
2) Проведет несколько лет на поддержке такого сложного кода, написанного другими
3) Прочитает аннотацию одного из банды четырех, где описано для чего писалась та книга
4) Узнает про парадокс, по которому больше работать, не означает больше получать денег
5) Поймет, что тупо кодить — уныло, а сложно кодить — вдвойне уныло, интереснее выходить за пределы проекта.

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

Здравствуйте, imh0, Вы писали:

I>Одни считают, что хороший программист, это тот который умный-умный и умеет писать алгоритмы! И пишет страшно маленькие и страшно быстрые программы.
I>Другие считают, что хороший программист, это тот который умеет разрабатывать промышленный код! Тот код который, страшно простой и понятный, и который потом можно сопровождать и самое главное потом легко развивать.

Если программист не умеет писать алгоритмы и быстрый код, то он плохой программист, очевидно. Если программист не умеет писать простой и понятный код, то он тоже плохой программист. Зачем тут выбирать? Хороший сферический программист в вакууме должен уметь делать и то и другое. А если некий программист умеет делать что-то одно, то для всех областей применять его не получится.

I>Избавить в том смысле, как научить "плохих" программистов, развиваться? Как заронить в их головах искру сомнения — а может я что-то делаю не так?

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

Здравствуйте, vsb, Вы писали:

vsb>Если программист не умеет писать алгоритмы и быстрый код, то он плохой программист, очевидно. Если программист не умеет писать простой и понятный код, то он тоже плохой программист. Зачем тут выбирать? Хороший сферический программист в вакууме должен уметь делать и то и другое. А если некий программист умеет делать что-то одно, то для всех областей применять его не получится.

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

Здравствуйте, imh0, Вы писали:

I>То есть у одного врожденный талант и нет знаний (хакеры не учатся), а у другого знания об архитектуре (слоистости, интерфейсах, минимизации связей и пр), и о жизненном цикле ПО.

Ну вот покойный мыщъх был хакером из настоящих, что называется. Неужто про него можно сказать, что он не учился? Я не о формальных корочках, а новых знаниях.

Здравствуйте, imh0, Вы писали:

vsb>>Если программист не умеет писать алгоритмы и быстрый код, то он плохой программист, очевидно. Если программист не умеет писать простой и понятный код, то он тоже плохой программист. Зачем тут выбирать? Хороший сферический программист в вакууме должен уметь делать и то и другое. А если некий программист умеет делать что-то одно, то для всех областей применять его не получится.

I>"писать алгоритмы и страшно быстрый код", так-то это был "сарказам". ) Это негодная оптимизация!

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

I>Алгоритмы и быстрый код нужны там где, есть узкое место.

Вот и я про то же. Не понимая хотя бы временной сложности того кода, который ты пишешь, очень легко создать на ровном месте тормоза. O(N^2) выстреливает очень быстро, причём, что самое неприятное, зачастую в продакшне.

I>Да пожайлуйста — вести хранение заранее посчитанных длинн и определять изменение по попытке доступа на запись в память строки. )

В C вообще идиотская манера хранить строки, не представляю, как это пролезло в мейнстрим. Длину надо хранить в -1, -2 и тд байте. И не придётся её считать. Ну или просто где-то рядом с указателем, как это делается в большинстве остальных языков. По-моему кроме С (и тех мест, где нужна совместимость с С) больше нигде так не делают.

Здравствуйте, imh0, Вы писали:

I>Да пожайлуйста — вести хранение заранее посчитанных длинн и определять изменение по попытке доступа на запись в память строки. )
I>Например. )

Емнип, в Паскале строки именно так хранились
Сперва длина строки, потом данные — вполне себе рабочий вариант представления строк.

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

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

Здравствуйте, ForestDront, Вы писали:

FD>Мне кажется, что задача обратная: как заставить компании понять, что программист натыркавшийся на литкоде с никому не нужным кодом не равно хороший программист.

Вроде как раз не обратная. )

Здравствуйте, imh0, Вы писали:

I>Одни считают, что хороший программист, это тот который умный-умный и умеет писать алгоритмы! И пишет страшно маленькие и страшно быстрые программы.
I>Другие считают, что хороший программист, это тот который умеет разрабатывать промышленный код! Тот код который, страшно простой и понятный, и который потом можно сопровождать и самое главное потом легко развивать.

I>То есть у одного врожденный талант и нет знаний (хакеры не учатся), а у другого знания об архитектуре (слоистости, интерфейсах, минимизации связей и пр), и о жизненном цикле ПО.

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

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

По поводу фильтра при найме. Я прошёл больше сотни интервью и могу уверенно сказать, что проблема тут чисто психологическая. IT-чмошник изначально идёт "валить" кандидата, ничем не брезгуя, лишь бы самоутвердиться. IT-инфузория искренне не понимает, как можно не знать содержимого её пробирки, и что даже узкая область не ограничивается её мембраной. Есть ещё варианты написания кода под секундомер с формальной проверкой по ограниченному списку критериев. Если нанимают таким способом, то откуда берутся многомесячные срывы сроков сдачи очередного этапа? Зашкварное количество брака вопросов у меня не вызывает. У всех этих случаев есть один общий признак -- строгие временные рамки, то есть важен сам процесс, а не результат.

А для специалиста для принятия решения достаточно 15 минут: несколько вопросов, связанных с вакансией, а не с тем, что чепушила когда-то учил или узнал только вчера.

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

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

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

Здравствуйте, namespace, Вы писали:

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

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

Здравствуйте, namespace, Вы писали:

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

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

Так это же прекрасно! Но каким боком тут сложность?

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

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

Здравствуйте, Умака Кумакаки, Вы писали:

УК>Здравствуйте, namespace, Вы писали:

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

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

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

Плохих программистов не бывает. Бывают плохие руководители (Ваш случай)

Здравствуйте, mgu, Вы писали:

mgu>Средним разработчикам как раз такое не под силу -- у них кругозор ограничен текущей задачей.
как раз таки под силу, потому что они слышали звон да не знали где он и большая часть разработки у них мотивирована как резюме-дривен-девелопмент, им главное вписать побольше умных слов в резюме чтобы выбить +20% зп у другого работодателя, но часть просто по дурости плодит слои абсракций, потому что никто по пальцам не бьёт линейкой

mgu>Выделенный кусок не понял: начали за здравие, а кончили за упокой.
какой именно пункт не понят?
1) питухи кукарекают о расширяемости и масштабируемости, генерят кучу бойлерплейта и абсракций для этого
2) читабельность кода падает, потому что там где был простой вызов, теперь куча промежуточных слоёв абсракций
3) никаких особых требований к расширяемости и масштабирумости никто не предъявлял, питухи возбудились просто потому что могут

Здравствуйте, Умака Кумакаки, Вы писали:

mgu>>Средним разработчикам как раз такое не под силу -- у них кругозор ограничен текущей задачей.
УК>как раз таки под силу, потому что они слышали звон да не знали где он и большая часть разработки у них мотивирована как резюме-дривен-девелопмент, им главное вписать побольше умных слов в резюме чтобы выбить +20% зп у другого работодателя, но часть просто по дурости плодит слои абсракций, потому что никто по пальцам не бьёт линейкой

Понимание абстракций и интерфейсов не входит в современный канон ключевых слов, от которых текут суровые технические директора (они дрочат на алгоритмы и структуры данных).

mgu>>Выделенный кусок не понял: начали за здравие, а кончили за упокой.
УК>какой именно пункт не понят?
УК>1) питухи кукарекают о расширяемости и масштабируемости, генерят кучу бойлерплейта и абсракций для этого
УК>2) читабельность кода падает, потому что там где был простой вызов, теперь куча промежуточных слоёв абсракций
УК>3) никаких особых требований к расширяемости и масштабирумости никто не предъявлял, питухи возбудились просто потому что могут

"ко-ко-ко расширяемо, ко-ко-ко, масштабируемо, ко-ко-ко", и как бы да, всё может быть и так

никаких особых требований к раширяемости и масштабируемости нет, не было и не будет,

Так пригодится расширяемость или нет?

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Плохих программистов не бывает. Бывают плохие руководители (Ваш случай)

Плохие программисты бывают, и их обычно повышают до руководителя (зачем же перемещать специалиста, хорошо пишущего код?)

Здравствуйте, mgu, Вы писали:

mgu>Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>>Плохих программистов не бывает. Бывают плохие руководители (Ваш случай)

mgu>Плохие программисты бывают, и их обычно повышают до руководителя (зачем же перемещать специалиста, хорошо пишущего код?)

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

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