История изменений

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

И самое грустное то, что такие из таких вот джунов собираются целые команды, где один джун становится лидом, других джунов делят по стажу джунства, и начинает команда месяцами писать серьезный проект уровня «hello world» или даже выше, регулярно отчитываясь об эффективности разработки. Результат разработки низкоквалифицированной команды настолько плох, что даже лучшие программисты не смогут его исправить, только переписать, как нельзя из деревянного корыта сделать болид Формулы 1.

Эта закономерность действует для многих других профессий, и сформулировать ее можно примерно так: нужно делать то, что нужно для решения задачи, а не то, что написано в книжке или просто модно/популярно. Самый тупейший пример из айтишной сферы: какие-то гении на пике хайпа написали биткоиновую биржу на самых модных технологиях, то есть ­— монга, блокчейн, React JS. Еще на той монге, которая была без транзакций. Мне нужно пояснять, чем это закончилось?

Нельзя создать идеальную архитектуру с первого раза, да и не может её существовать в принципе на фоне меняющихся требований, можно лишь адаптироваться к требованиям. А можно, наоборот, петь оды руководителю, который «безошибочно» создал архитектуру, получая взаимное выгораживание перед начальством, и вуаля — вместо рабочего решения мы имеем закрытые задачим и высокие показатели эффективности:
https://habr.com/articles/593167/
Когда же подходят дедлайны, а решения нет... ну, можно что-то придумать. Например, это из-за byko3y, который недостаточно активно участвует в работе над нашим, с его слов, неисправимо кривым кодом. Или, как сделали ребята из Facebook, рассказать о том, что да, ничего нового мы не сделали, но зато заложили базис для новых перспективных разработок. Это как в школах/институтах, где преподов порой ставят перед фактом «к вам люди приходят и от вас уходят с теми же знаниями. Какой тогда смысл был учиться» — тогда преподы отвечают «мы научили их учиться. Да, они ничего не знают и не умеют, но смогут научиться», а пока ты пойдешь проверять и ловить их на балабольстве — они уже три раза выпустят партию таких же бездарей.

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

Возвращаясь ближе к твоим вопросам: худ литература нужна, чтобы красивее балабольствовать, многим людям нравятся красивые слова и символопоклонничество нынче популярно, выдавай как из пулемёта редкие эпитеты, рассказывай истории про каких-то малоизвестных китайских императоров — всё, можешь идти прямиком в телевизор. То есть, отжимать чужие ресурсы с навыком балабольства проще, правда, при чем тут «хороший, кодный код» — ума не приложу.

Если же говорить о том, кого читать именно по теме кодинга... Даже не знаю. Я изредка находил в интернетах отдельных блогеров, которые пишут о том, как просто писать код, а не применять методики, но там как бы и особо писать не о чем. Раньше модно было советовать книжки по алгоритмам от Кнута и Вирта, но с тех пор настолько много всего изменилось, что даже банальные Quick Sort и черно-белые бинарные деревья уже стали неактуальны. Потому что сортировка вставками на современных процессорах на малых наборах данных работает быстрее, чем Quick Sort (не говоря уже о спорной необходимости сортировки), и черно-белые деревья на тех же современных процессорах имеют очень грустные показатели производительности.

Технологий и готовых решений стало так много, что рулит тот, кто с ними быстрее разберется, а не тот, кто перепишет черно-белые деревья и создаст иерархию наследования классов в JavaScript. И в этом плане «знать меньше» значит «знать больше». Хотя бы потому, что умниками, знающих старые знаний, забиты все галеры, какой-то особенной ценности они не представляют именно в плане «решить новую задачу». Даже человек, который просто сядет, прочитает чужой код, и доработает его в нужную сторону — это бесценный кадр, а человек, который знает десять алгоритмов сортировки, даром не нужен.

К сожалению, программирование — это скорее навык, как футбол, чем знания, как география. Потому в идеале тебе нужен опытный игрок-тренер, с которым ты будешь оттачивать свой навык. Заочное обучение тоже имеет ненулевую эффективность, но всё же намного меньшую. Например, мне понравилась лекция:
https://www.youtube.com/watch?v=otAcmD6XEEE — Kevlin Henney - Procedural Programming: It's Back? It Never Went Away
Но я еще раз подчеркну, что это лекция больше про «выкиньте из головы тот мусор, который в нее накидали авторы книг», чем про преподавание еще одного метода программирования. В этом плане мне нравятся аналогичный «промывающий» материал, вроде:
https://www.youtube.com/watch?v=QM1iUe6IofM — Object-Oriented Programming is Bad - Brian Will
И дальше всё просто: если у тебя пишется фукнция на 500 строк, то ты пишешь функцию на 500 строк. Что кто-то не сможет ее прочитать? 500 функций по одной строчек он тоже не сможет прочитать. У меня был реальный чел, с которым я работал и он жаловался, что мой код сложно читать. Потом выяснилось, что свой код он тоже с большим трудом читает. Пофигу на твои метрики красоты кода, если задача не решена.

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

И самое грустное то, что такие из таких вот джунов собираются целые команды, где один джун становится лидом, других джунов делят по стажу джунства, и начинает команда месяцами писать серьезный проект уровня «hello world» или даже выше, регулярно отчитываясь об эффективности разработки. Результат разработки низкоквалифицированной команды настолько плох, что даже лучшие программисты не смогут его исправить, только переписать, как нельзя из деревянного корыта сделать болид Формулы 1.

Эта закономерность действует для многих других профессий, и сформулировать ее можно примерно так: нужно делать то, что нужно для решения задачи, а не то, что написано в книжке или просто модно/популярно. Самый тупейший пример из айтишной сферы: какие-то гении на пике хайпа написали биткоиновую биржу на самых модных технологиях, то есть ­— монга, блокчейн, React JS. Еще на той монге, которая была без транзакций. Мне нужно пояснять, чем это закончилось?

Нельзя создать идеальную архитектуру с первого раза, да и не может её существовать в принципе на фоне меняющихся требований, можно лишь адаптироваться к требованиям. А можно, наоборот, петь оды руководителю, который «безошибочно» создал архитектуру, получая взаимное выгораживание перед начальством, и вуаля — вместо рабочего решения мы имеем закрытые задачим и высокие показатели эффективности: https://habr.com/articles/593167/ Когда же подходят дедлайны, а решения нет... ну, можно что-то придумать. Например, это из-за byko3y, который недостаточно активно участвует в работе над нашим, с его слов, неисправимо кривым кодом. Или, как сделали ребята из Facebook, рассказать о том, что да, ничего нового мы не сделали, но зато заложили базис для новых перспективных разработок. Это как в школах/институтах, где преподов порой ставят перед фактом «к вам люди приходят и от вас уходят с теми же знаниями. Какой тогда смысл был учиться» — тогда преподы отвечают «мы научили их учиться. Да, они ничего не знают и не умеют, но смогут научиться», а пока ты пойдешь проверять и ловить их на балабольстве — они уже три раза выпустят партию таких же бездарей.

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

Возвращаясь ближе к твоим вопросам: худ литература нужна, чтобы красивее балабольствовать, многим людям нравятся красивые слова и символопоклонничество нынче популярно, выдавай как из пулемёта редкие эпитеты, рассказывай истории про каких-то малоизвестных китайских императоров — всё, можешь идти прямиком в телевизор. То есть, отжимать чужие ресурсы с навыком балабольства проще, правда, при чем тут «хороший, кодный код» — ума не приложу.

Если же говорить о том, кого читать именно по теме кодинга... Даже не знаю. Я изредка находил в интернетах отдельных блогеров, которые пишут о том, как просто писать код, а не применять методики, но там как бы и особо писать не о чем. Раньше модно было советовать книжки по алгоритмам от Кнута и Вирта, но с тех пор настолько много всего изменилось, что даже банальные Quick Sort и черно-белые бинарные деревья уже стали неактуальны. Потому что сортировка вставками на современных процессорах на малых наборах данных работает быстрее, чем Quick Sort (не говоря уже о спорной необходимости сортировки), и черно-белые деревья на тех же современных процессорах имеют очень грустные показатели производительности.

Технологий и готовых решений стало так много, что рулит тот, кто с ними быстрее разберется, а не тот, кто перепишет черно-белые деревья и создаст иерархию наследования классов в JavaScript. И в этом плане «знать меньше» значит «знать больше». Хотя бы потому, что умниками, знающих старые знаний, забиты все галеры, какой-то особенной ценности они не представляют именно в плане «решить новую задачу». Даже человек, который просто сядет, прочитает чужой код, и доработает его в нужную сторону — это бесценный кадр, а человек, который знает десять алгоритмов сортировки, даром не нужен.

К сожалению, программирование — это скорее навык, как футбол, чем знания, как география. Потому в идеале тебе нужен опытный игрок-тренер, с которым ты будешь оттачивать свой навык. Заочное обучение тоже имеет ненулевую эффективность, но всё же намного меньшую. Например, мне понравилась лекция: https://www.youtube.com/watch?v=otAcmD6XEEE — Kevlin Henney - Procedural Programming: It's Back? It Never Went Away Но я еще раз подчеркну, что это лекция больше про «выкиньте из головы тот мусор, который в нее накидали авторы книг», чем про преподавание еще одного метода программирования. В этом плане мне нравятся аналогичный «промывающий» материал, вроде: https://www.youtube.com/watch?v=QM1iUe6IofM — Object-Oriented Programming is Bad - Brian Will И дальше всё просто: если у тебя пишется фукнция на 500 строк, то ты пишешь функцию на 500 строк. Что кто-то не сможет ее прочитать? 500 функций по одной строчек он тоже не сможет прочитать. У меня был реальный чел, с которым я работал и он жаловался, что мой код сложно читать. Потом выяснилось, что свой код он тоже с большим трудом читает. Пофигу на твои метрики красоты кода, если задача не решена.