Comments 13
Но большинство обучающихся не будут следовать вашему примеру - и правильно сделают: индустрии производства ПО массово нужны исполнители, а не думатели. Так что, ради общей пользы - повышения производительности общественного труда - не надо убеждать их следовать вашему примеру.
Да, с такой позицией можно заходить в профессию. Но подана она слишком безапелляционно. Поэтому, для баланса, несколько соображений:
Тот, кто научился думать своей головой, и хорошо понимает изнутри используемые технологии, в конце концов дойдет и до прелести стандартных решений в стандартных случаях. Но кроме того, будет готов и к нестандартным.
Не стоит противопоставлять "думателей" и "исполнителей". Если вы исполнительны и умеете включать голову, любой здравомыслящий работодатель готов будет отдать за вас гораздо больше, чем если вы просто исполнительны.
Не могу говорить за всю индустрию, но все работодатели, с которыми мне довелось иметь дело лично - готовы были в той или иной мере вкладываться в изучение и эксперименты с технологиями своих сотрудников, а то и вовсе прямо требовали постоянного повышения квалификации. До сегодняшнего дня вообще считал это нормой, но, судя по цитируемому комментарию, видимо, ошибался.
Времена, когда можно не думая жать кнопки в рамках одной отработанной технологии, следуя стандартным рецептам, слишком скоротечны, они успевают неоднократно смениться за время жизни отдельно взятого программиста. Навык освоения новых технологий нужен вплоть до пенсии (посчитайте, сколько вам лет до нее), и метод "попробую сначала сам, а потом посмотрю, как другие делают" - работает неплохо, хоть, конечно, и не единственный.
Что касается практики, мы работаем часто в ограниченных условиях, где разворачивать "творческую лабораторию" просто некогда, не оптимально. Поэтому, иногда полезно взять готовое решение сразу, по принципам "достаточно хорошо", "кради как художник" или "цени время других".
Полностью согласен, прибегнуть к такой методике не всегда удаётся. Однако в вузах её достаточно полезно использовать, когда специалист еще на стадии обучения и не находится в "боевых условиях".
Мы живем в эпоху, когда программирование все чаще превращается в подбор существующих решений, а не в создание новых.
Пожалуй, я бы с этим поспорил. При обучении программированию – да, конечно, ибо оно по определению основывается на типовых задачах. В реальной же работе это не так: стандартные кейсы обычно покрываются библиотеками/фреймворками, а вот бизнес-логика (реализация которой, собственно, и составляет основной смысл программирования) обычно уникальна у каждого нового продукта – иначе не было бы смысла в его разработке, можно было бы просто взять готовый.
Давно хотел поделиться этими мыслями и получить обратную связь от более опытных разработчиков.
Скорее всего вы правы, вот как раз подобный фидбэк я ожидал услышать. Так или иначе, в статье по большей степени застрагиваются разработчики начального уровня, которым свойственно решать задачи таким образом, как мне кажется.
в статье по большей степени застрагиваются разработчики начального уровня
Если речь о рекомендации начинающим пробовать том числе собственные способы решения типовых проблем, то вопросов нет, это полезно. Но вот экстраполировать аж на целую эпоху – пожалуй, перебор 🙂
Я уверен, что этот подход может быть полезен не только новичкам, но и опытным специалистам, которые готовы взглянуть на привычные задачи под новым углом.
Да, так и есть. Возможно стоит чуть точнее написать (поправил).
Мысль была в том, что это хороший подход для начинающих специалистов, так как у них в голове нет еще готовых решений, как решать ту или иную специфическую задачу.
В случае с опытными специалистами, это скорее может сработать в рамках нового направления, к примеру другой язык программирования или фреймворка. Однако, с ростом опыта, эффективность такого метода пропадает.
иначе не было бы смысла в его разработке, можно было бы просто взять готовый.
Нельзя. Потому что готвый почти наверняка имеет другой интерфейс пользователя. Ну, а что до фреймворков и бизнес-логики, то туда фреймворки просто не успели добраться: в первую очередь на фреймворки была переведена наиболее трудоемкая часть разработки - интерфейс. Но, думаю, со временем это исправится.
Слишком наивно . Это может работать на простых или типовых задачах, но на практике недостаток опыта приводит к поиску кошки в темной комнате для сложной или нетиповой задачи если не знаешь куда двигаться из-за множества вариантов или недостатка знаний.
Я иногда забавы ради предлагаю решить какую-нибудь задачку детям. Причём, идеально, когда они в возрасте лет 10. Выясняется, что часто те самые первые быстрые "наивные решения" (читай - супердешевые для работодателя) можно улучшить и не раз. Забавно видеть, как дети итеративно могут придумать алгоритм выхода из любого лабиринта. А потом выяснится, что они придумали сами "поиск в ширину", например. Как сказал один из таких детей "каждый раз получается, что это кто-то придумал до нас. Так окажется, что скоро и придумывать будет нечего" ))
И вот тут возникает общий вопрос: а надо ли (есть ли на это время / ресурсы у компании), всегда и каждый раз изобретать велосипед? Часто ведь задачи очень схожи и довольно рутинны: круд, джейсоны туда-сюда, да и все. Ну, повертели данные и поизучали ещё. Но по итогу - ну все ж похоже? А, ну еще выяснили, что синяя кнопка дает +0.001% прибыли по сравнению с зеленой и надо теперь кнопки перекрасить.
Я понимаю, если речь идёт про науку и академическую работу. Тут вопросов нет. Свежий взгляд, незашоренность мышления и все такое. Но бизнес? Кажется, ему нужны не те, кто придумывает ежедневные велосипеды, а кто может прийти и начать сходу закрывать таски (читай - зарабатывать бабки для компании). Кстати, лучше бы их закрывать стандартными для индустрии методами, чтобы эти решенные задачи можно было ещё и дешево поддерживать потом.
На первый взгляд такой подход может показаться неэффективным. Ведь зачем тратить время, если можно просто найти ответ? Но на практике Naive Problem Solving помогает развить глубинное понимание технологий. Когда вы ищете решение самостоятельно, вы начинаете замечать связи, которые обычно остаются вне поля зрения. Постепенно вы не просто решаете задачи — вы учитесь думать иначе, анализировать проблему с разных сторон, предугадывать возможные сложности и находить пути их решения.
Всё это интересно, но кто вам это будет оплачивать?
Эффективность зависит от той цели, которая ставится. Вы тут пишете с позиции сосбственного повышения квалификации. Это хорошо, но для промышленного программирования это не нужно. А вот затраты труда на производство конкретной программы, нужной заказчику, такой подход повышает.
Поэтому заказчик предпочтет исполнителя, который не думает над нестандартными решениями, а умеет применять стандартные. Именно на таких работников (тех самых "крепких мидлов с коммепческим опытом") есть спрос. А потому, в ответ на этот спрос, потенциальные работники чаще учатся не умничать, а применять стандартные решения.
Короче, считаете себя самым умным, чтобы попытаться идти против тенденции - флаг в руки. Может быть, у вас даже всё получится, и ваш выигрыш будет в том, что вы получите больше денег за более интересную работу. Но большинство обучающихся не будут следовать вашему примеру - и правильно сделают: индустрии производства ПО массово нужны исполнители, а не думатели. Так что, ради общей пользы - повышения производительности общественного труда - не надо убеждать их следовать вашему примеру.
Статью скорее стоит воспринимать как рекомендацию для тех, у кого есть возможности, время и желание экспериментировать – подход, безусловно, зависит от специфики работы.
В коммерческом программировании зачастую важнее применять проверенные, стандартные решения, но если все будут ограничиваться только ими, мы рискуем утратить разнообразие идей, которое превращает локальные проекты или pet-проекты в полезные для сообщества (могу сказать за сферу фронтенда, так как не сильно углублялся в другие сферы и как с этим обстоят дела).
Но большинство обучающихся не будут следовать вашему примеру - и правильно сделают: индустрии производства ПО массово нужны исполнители, а не думатели. Так что, ради общей пользы - повышения производительности общественного труда - не надо убеждать их следовать вашему примеру.
Да, с такой позицией можно заходить в профессию. Но подана она слишком безапелляционно. Поэтому, для баланса, несколько соображений:
Тот, кто научился думать своей головой, и хорошо понимает изнутри используемые технологии, в конце концов дойдет и до прелести стандартных решений в стандартных случаях. Но кроме того, будет готов и к нестандартным.
Не стоит противопоставлять "думателей" и "исполнителей". Если вы исполнительны и умеете включать голову, любой здравомыслящий работодатель готов будет отдать за вас гораздо больше, чем если вы просто исполнительны.
Не могу говорить за всю индустрию, но все работодатели, с которыми мне довелось иметь дело лично - готовы были в той или иной мере вкладываться в изучение и эксперименты с технологиями своих сотрудников, а то и вовсе прямо требовали постоянного повышения квалификации. До сегодняшнего дня вообще считал это нормой, но, судя по цитируемому комментарию, видимо, ошибался.
Времена, когда можно не думая жать кнопки в рамках одной отработанной технологии, следуя стандартным рецептам, слишком скоротечны, они успевают неоднократно смениться за время жизни отдельно взятого программиста. Навык освоения новых технологий нужен вплоть до пенсии (посчитайте, сколько вам лет до нее), и метод "попробую сначала сам, а потом посмотрю, как другие делают" - работает неплохо, хоть, конечно, и не единственный.
Не соглашусь с большинством комментаторов и поддержу автора поста. Типовые решения - это хорошо, но даже если ты применяешь типовое решение - очень полезно разобраться, как именно оно работает, почему надо сделать именно так, какие в этом решении есть минусы и какие могут быть альтернативы.
Автор, вы далеко пойдёте, если не растеряете свою любознательность на пути от мидла до синьора. Кроличья нора программирования практически бесконечно глубока, удачи!
Naive Problem Solving: Почему неопытность в разработке может быть преимуществом