Комментарии 14
Мы не верим в себя? А я слыхал о прямо противоположном явлении. Интересно, от чего зависит, что из этого проявляется в конкретном случае
Тот разработчик, которого вы описываете, встречается один на миллион.
Почему ты выбрал такой подход к решению?
Не знаю. Прочитал в какой-то статье.
Не знаю. Скопипастил его из X.
Не знаю. Такой же подход я использовал в предыдущем проекте.
Не знаю. Кто-то мне посоветовал.
Почему не знаю? Знаю. Потому что это сработало.
Потому что уже есть какой-то опыт по сопровождению. Или наоборот, потому что новая технология - единственный шанс сделать "как надо", а готовых решений нет. Или потому что проверенная технология исхожена вдоль и поперёк и я готов взять ответственность на себя во внедрении чего-то нового.
Замените "Не знаю" на "Я проанализировал все доступные решения и выбрал наиболее оптимальное" и получится, что разработчик взял на себя часть функциональности ПМ по защите решения перед заказчиком. Если нужно навалить ещё BS и обосновать, почему именно этот копипаст с SO лучший - ну, во первых, потому что он работает, а остальные не проверяли, а во-вторых, пусть у ПМ голова болит по этому поводу.
Я бы примерно так же ответил. Выбор подхода к решению — это моя задача. Все остальное вытекает из этого. И если это сработало — то да, дальше никого не волнует, как я этого добился. Даже если «мне посоветовали», или я это «прочитал в какой-то статье» — моя квалификация, за которую мне платят деньги, как раз и состоит в том числе в том, чтобы знать, у кого просить совета, или какие статьи читать, а какие отсеивать. И кстати да, мне платят не за творчество и полет мысли, а за решение задач бизнеса или заказчика. В идеале — чтобы быстро и качественно.
>пусть у ПМ голова болит по этому поводу
Ну, хороший разработчик не должен создавать своему ПМ лишнюю головную боль :)
Это называется культом карго, и, кажется, не требует какого-то нового термина или разбора каких-то особенностей именно программистских, всё уже тысячекратно пережёвано.
Знаю ответ на это "В любой непонятной ситуации - думай".
А так, нет ничего плохого взять решение из интернета, если ты только обдумал и проанализировал его, взвесив с другими решениями. Но это уже скорее называется аналитическим мышлением + банальный интерес к своей работе.
Мне лично очень интересно познавать и понимать крутые идеи, которые заложены в том-то решении или библиотеки. Я могу видеть их красоту и получать от этого кайф (и от дальнейшего их применения). Если этого нет, то да - то, что описано в статье может происходить.
Не знаю, может быть это из-за олимпиадного прошлого. Кто-то жалуется на спортивных программистов, но оно научило меня видеть красоту в классных решениях. Может быть этого людям и не хватает... Это уже становится не просто работой, а видом искусства.
С чем я сталкивался: человек городит какую-то запутанную архитектуру. "Почему ты так делаешь?" — "Так всегда делают". Убираю 80% кода к чертям, функционал не меняется, надежность возрастает. — "А что, так можно было?"
У меня дома есть 2 велосипеда. Один родом из СССР - внешнее не модный, но лёгкий и быстрый. Второй родом из России - внешне модный, но жутко тяжёлый от чего медленный.
В изобретении велосипедов нет ничего плохого, если вы понимаете, для чего нужен велосипед и что для него важно.
Есть довольно важная задача, есть сжатые строки решения этой задачи, есть знания и навыки в определенной технологии, есть уверенность в том, что применяя эти знания и умения вы решите задачу в заданные сроки.
И есть какая-то новая, "крутая" технология, которую вы не знаете, навыков в ней нет никаких, соответственно и нет уверенности что задача будет решена вовремя, да и просто будет решена.
Что вы выберете? Никому не хочется быть тем человеком, из-за кого сорвался важный проект.
С новой технологией прикольно поиграться, когда над головой не висит груз ответственности.
Для быстроты написания кода хорошо подходит методика задействования существующих примеров. Но без обдумывания и корректировки данный метод может привести к совершенно не обслуживаемому коду, который и весить будет несколько гигабайт. Когда программист ужат в сроки и не регламентирован по железу, то согласен, можно и использовать рабочие готовые примеры, если это будет конечный продукт. А если есть время и есть ограничение на ресурсы, то тут лучше писать самому. Я как бы сейчас поделил разрабов на Java и C++ (для микроконтроллеров). Сам так же использую чужой код, но только в качестве примера, для понимания как оно примерно должно работать. И часто в выходе получаю совершенно противоположный код, который и работает быстрее чем скажем в готовой библиотеке, и наглядно для меня более понятен.
По статье скажу так, что в основном, согласен с автором. И смысл мне кажется в другом, что современный разрабы обленились и перестали думать. Легко взять рабочий пример и применить у себя, но мозги с каждым разом начинают все хуже работать. Раньше практически каждый программист был и архитектором, а сейчас все больше становится кодеров.
Однако, апелляция к авторитету глубоко ошибочна.
Несколькими абзацами выше:
Да, конечно, когда Дэн Абрамов говорит мне, как правильно использовать React, или в документации написано, что это единственный способ применения API, то с этим нужно согласиться.
Иронично.
А менеджмент готов оплачивать возросшие в десятки раз объёмы работы и сдвинутые на несколько месяцев (лет) сроки то почему бы и не заняться колхозным велосипедостроением взамен отработанных технологий?
Ну и возросшую стоимость поддержки конечно же: зачем нам известная документированная технология, если можно использовать "дешевое" решение дяди Васи, рожденное сном его разума и обязательно недокументированное, для полной прожарки пятой точки всем кто будет после него!!!
Думаю, что смысл статьи не в "принятии решения"
Смысл в саморазвитии через "осознанный копипаст"
Как разработчику перестать быть потребителем технологий