За последние несколько лет, в процессе работы и общения со множеством разработчиков, я заметила часто повторяющийся паттерн. Он меня сильно беспокоил и я продолжала о нём думать и говорить, пытаться найти понимание или даже оправдание ему.
Почему ты выбрал такой подход к решению?
- Не знаю. Прочитал в какой-то статье.
- Не знаю. Скопипастил его из X.
- Не знаю. Такой же подход я использовал в предыдущем проекте.
- Не знаю. Кто-то мне посоветовал.
Этот паттерн можно назвать "потреблением вместо творчества". Потреблением без сомнений и вопросов. Потреблением, потому что можно спрятаться за чьим-то авторитетом.
Я видела разработчиков, берущих решение других людей как должное. Без малейших раздумий о выбранном подходе, не заморачиваясь анализом. Да, конечно, когда Дэн Абрамов говорит мне, как правильно использовать React, или в документации написано, что это единственный способ применения API, то с этим нужно согласиться. Тем не менее, когда вы используете какой-то технический контент без хотя бы доли скептицизма, то вы всё равно сможете продвинуться в своей карьере, но есть вероятность, что это вам помешает.
Bullshit повсюду
В начале своей карьеры я бы ни за что не опубликовала ничего технического в Интернете. Я считала, что если кто-то достаточно смел, чтобы опубликовать пост в блоге или поучаствовать в обсуждении технологий, то он всегда знает, что делает. Как же я ошибалась!
В какой-то момент я осознала, что подавляющее большинство технического контента в Интернете — это bullshit (мой пост тоже может быть bullshit). В туториалах показывают вредные паттерны. В статьях полно концептуальных ошибок. Да и люди не идеальны! Сениор-разработчики — это не всегда хорошие разработчики. Решения технических руководителей могут быть далеки от идеала. Хорошо продающаяся и правильно работающая архитектура приложения может быть совершенно поломанной. Я встречала людей на должности сениоров, которые нифига не соображают в программировании! Но тем не менее, они пишут о нём в Интернете! А потом приходит кто-то и говорит: я использовал предложенное этим человеком решение, потому что он сениор в компании X. Разумеется, в этом есть определённая логика. Однако, апелляция к авторитету глубоко ошибочна.
«Одна из величайших заповедей науки — »не доверяй апелляции к авторитету"… Слишком многие такие утверждения оказывались ужасно ошибочными. Авторитеты должны доказывать свои доводы как и все остальные" — Карл Саган
Чем раньше вы поймёте, что bullshit повсюду, тем лучше. Все мы стараемся изо всех сил, но все мы люди, совершающие ошибки, и никакие годы опыта, количество постов в блогах или уровень зарплаты не определяют знания человека. В конце концов, все мы можем публиковать в интернете что угодно.
Почему так происходит?
Мы ленивы. В большинстве своём мы не глупы, но ленивы. Если кто-то даёт нам решение, и оно работает, то зачем задумываться? Почему бы просто не скопипастить его и не выпустить в продакшен?
Нам не хватает времени. Придумывание логичных аргументов может стоить кому-то пары часов на чтение исходного кода, написания кучи кода для доказательства своей точки зрения или траты значительного объёма времени на исследования! Но у всех нас есть дедлайны.
Это комфортно. Для логических рассуждений часто приходится выйти из зоны комфорта, потому что вам нужно получить новые знания, напряжённей размышлять для понимания каких-то концепций, или выполнять дополнительную работу. Нахождение же в зоне комфорта мы обычно (подсознательно) приемлем.
Мы не верим в себя. Люди, особенно в начале своей карьеры, склонны думать, что их решения никогда не будут достаточно хороши. Поэтому они полагаются на авторитеты и не подвергают их сомнению.
Как перестать быть потребителем технологий?
Осознайте, что в мире есть множество ложных представлений. Люди и их решения не безупречны.
Адаптируйте решения под свою конкретную ситуацию. Не существует единого решения, подходящего всем. Сравнивайте разные подходы, анализируйте их. Туториалы и статьи демонстрируют идею, но в них может и не быть готового к продакшену кода. Всегда анализируйте его, прежде чем использовать.
Верьте в себя. Ваши решения ничуть не хуже тех, которые есть в Интернете.
Продолжайте учиться, будьте любознательны. Быть разработчиком — значит постоянно учиться. Достигните понимания используемой вами библиотеки или фреймворка, так вы сможете применять их оптимальным образом. Иногда люди используют библиотеки без глубокого их понимания, это приводит к неправильному применению базовых концепций и написанию усложнённого или менее производительного кода.
Не потребляйте. Творите. Задавайте вопросы. Будьте любопытными.
Комментарии (12)
Loggus66
16.04.2022 19:27+10Почему ты выбрал такой подход к решению?
Не знаю. Прочитал в какой-то статье.
Не знаю. Скопипастил его из X.
Не знаю. Такой же подход я использовал в предыдущем проекте.
Не знаю. Кто-то мне посоветовал.
Почему не знаю? Знаю. Потому что это сработало.
Потому что уже есть какой-то опыт по сопровождению. Или наоборот, потому что новая технология - единственный шанс сделать "как надо", а готовых решений нет. Или потому что проверенная технология исхожена вдоль и поперёк и я готов взять ответственность на себя во внедрении чего-то нового.
Замените "Не знаю" на "Я проанализировал все доступные решения и выбрал наиболее оптимальное" и получится, что разработчик взял на себя часть функциональности ПМ по защите решения перед заказчиком. Если нужно навалить ещё BS и обосновать, почему именно этот копипаст с SO лучший - ну, во первых, потому что он работает, а остальные не проверяли, а во-вторых, пусть у ПМ голова болит по этому поводу.
sshikov
16.04.2022 22:11+4>Почему ты выбрал такой подход к решению?
Я бы примерно так же ответил. Выбор подхода к решению — это моя задача. Все остальное вытекает из этого. И если это сработало — то да, дальше никого не волнует, как я этого добился. Даже если «мне посоветовали», или я это «прочитал в какой-то статье» — моя квалификация, за которую мне платят деньги, как раз и состоит в том числе в том, чтобы знать, у кого просить совета, или какие статьи читать, а какие отсеивать. И кстати да, мне платят не за творчество и полет мысли, а за решение задач бизнеса или заказчика. В идеале — чтобы быстро и качественно.
>пусть у ПМ голова болит по этому поводу
Ну, хороший разработчик не должен создавать своему ПМ лишнюю головную боль :)
napa3um
16.04.2022 20:50Это называется культом карго, и, кажется, не требует какого-то нового термина или разбора каких-то особенностей именно программистских, всё уже тысячекратно пережёвано.
DrNefario
16.04.2022 23:46+5Знаю ответ на это "В любой непонятной ситуации - думай".
А так, нет ничего плохого взять решение из интернета, если ты только обдумал и проанализировал его, взвесив с другими решениями. Но это уже скорее называется аналитическим мышлением + банальный интерес к своей работе.
Мне лично очень интересно познавать и понимать крутые идеи, которые заложены в том-то решении или библиотеки. Я могу видеть их красоту и получать от этого кайф (и от дальнейшего их применения). Если этого нет, то да - то, что описано в статье может происходить.
Не знаю, может быть это из-за олимпиадного прошлого. Кто-то жалуется на спортивных программистов, но оно научило меня видеть красоту в классных решениях. Может быть этого людям и не хватает... Это уже становится не просто работой, а видом искусства.
agalakhov
17.04.2022 14:29+1С чем я сталкивался: человек городит какую-то запутанную архитектуру. "Почему ты так делаешь?" — "Так всегда делают". Убираю 80% кода к чертям, функционал не меняется, надежность возрастает. — "А что, так можно было?"
E_BEREZIN
17.04.2022 16:52+2У меня дома есть 2 велосипеда. Один родом из СССР - внешнее не модный, но лёгкий и быстрый. Второй родом из России - внешне модный, но жутко тяжёлый от чего медленный.
В изобретении велосипедов нет ничего плохого, если вы понимаете, для чего нужен велосипед и что для него важно.
vvbob
17.04.2022 23:09+1Есть довольно важная задача, есть сжатые строки решения этой задачи, есть знания и навыки в определенной технологии, есть уверенность в том, что применяя эти знания и умения вы решите задачу в заданные сроки.
И есть какая-то новая, "крутая" технология, которую вы не знаете, навыков в ней нет никаких, соответственно и нет уверенности что задача будет решена вовремя, да и просто будет решена.
Что вы выберете? Никому не хочется быть тем человеком, из-за кого сорвался важный проект.
С новой технологией прикольно поиграться, когда над головой не висит груз ответственности.
vsvleo
18.04.2022 09:37Для быстроты написания кода хорошо подходит методика задействования существующих примеров. Но без обдумывания и корректировки данный метод может привести к совершенно не обслуживаемому коду, который и весить будет несколько гигабайт. Когда программист ужат в сроки и не регламентирован по железу, то согласен, можно и использовать рабочие готовые примеры, если это будет конечный продукт. А если есть время и есть ограничение на ресурсы, то тут лучше писать самому. Я как бы сейчас поделил разрабов на Java и C++ (для микроконтроллеров). Сам так же использую чужой код, но только в качестве примера, для понимания как оно примерно должно работать. И часто в выходе получаю совершенно противоположный код, который и работает быстрее чем скажем в готовой библиотеке, и наглядно для меня более понятен.
По статье скажу так, что в основном, согласен с автором. И смысл мне кажется в другом, что современный разрабы обленились и перестали думать. Легко взять рабочий пример и применить у себя, но мозги с каждым разом начинают все хуже работать. Раньше практически каждый программист был и архитектором, а сейчас все больше становится кодеров.
DevilDimon
18.04.2022 09:41+1Однако, апелляция к авторитету глубоко ошибочна.
Несколькими абзацами выше:
Да, конечно, когда Дэн Абрамов говорит мне, как правильно использовать React, или в документации написано, что это единственный способ применения API, то с этим нужно согласиться.
Иронично.
Sergeant101
18.04.2022 09:41А менеджмент готов оплачивать возросшие в десятки раз объёмы работы и сдвинутые на несколько месяцев (лет) сроки то почему бы и не заняться колхозным велосипедостроением взамен отработанных технологий?
Ну и возросшую стоимость поддержки конечно же: зачем нам известная документированная технология, если можно использовать "дешевое" решение дяди Васи, рожденное сном его разума и обязательно недокументированное, для полной прожарки пятой точки всем кто будет после него!!!
dmitryvolochaev
Мы не верим в себя? А я слыхал о прямо противоположном явлении. Интересно, от чего зависит, что из этого проявляется в конкретном случае