Когда быть хорошим плохо

Original author: John Sonmez
  • Translation
Я хотел бы начать с истории:

Учитель керамического дела объявил в день открытия, что разобьет класс на две группы. «Те, кто сидят слева» — сказал он: «будут оцениваться только по количеству проделанной работы, те, кто справа — только по её качеству». Его методика была проста, в последний день он принесет весы и взвесит работу группы «количество»: 50 фунтов горшков это «5», сорок фунтов горшков это «4» и так далее. Те, кто оцениваются по «качеству», однако, должны сделать один, пусть и совершенный, горшок, чтобы получить «5». Время сдачи пришло, и обнаружился любопытный факт: работы лучшего качества были сделаны в группе, оцениваемой по количеству. Похоже, в то время, как группа «количество» упорно штамповала свои работы и училась на своих ошибках, группа «качество» теоретизировали об идеале и, в конце концов, только и могла показать свои старания и грандиозные теории об идеале, а также кучу бесполезной глины.


Spot

Эта история из книги Art & Fear.

Признаюсь, я еще не прочитал ее, но я наткнулся на эту историю однажды, и она поразила меня.

Чем лучше стараетесь сделать, тем хуже получается

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

Одна вещь, которую я заметил — разработчики ПО имеют тенденцию быть очень продуктивными.

Я помню дни, когда у меня была дискета с разными программами, над которыми я работал. Тогда казалось, я начал понимать разработку ПО лучше, в действительности я начал становиться менее продуктивным.
floppy
Почему так случилось?

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

Помните, вы были ребенком? Скорее всего вы много рисовали. И наверняка эти рисунки не будут так хороши, если судить их по вашим сегодняшним стандартам, вы даже могли бы назвать их ужасными.

Почему вы перестали рисовать так много сейчас? (Может быть вы и нет, но большинство перестали.) Лучше поставить вопрос так: «почему вы рисовали так много тогда?»

Есть много ответов, но я думаю большинство из нас решит, что одна из причин в том, что дети просто познают и учатся, и они не скованы какими-то ограничениями.

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

Так что же произошло?

Я знаю, что прошел через фазу в разработке, в которой не был и близко так продуктивен, как мог бы.

Я потратил много времени на «восхищение задачей», и еще больше на «превращение простого в сложное».

Как разработчики ПО мы имеем тенденцию ставить себе ограничения и искать идеальное решение проблемы.

Пока я не зашел слишком далеко: я ни в коем случае не советую писать говнокод и распространять его. Не делайте этого!

Я предлагаю лишь стараться искать решение оптимальное на 90 процентов, зная, что можно будет вновь вернуться к проблеме, если вам действительно нужно будет найти лучшее решение, делайте так вместо того, чтобы тратить время на решение оптимальное на 95 процентов и более.

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

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

Когда мы начинаем учиться делать «правильно», нас часто душит это знание и ограничения, с ним связанные. Это делает нас менее продуктивными и заставляет изобретать избыточные решения для проблем.

Итак, я предполагаю, что любители лучше профессионалов?

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

В моем понимании, решение в том, чтобы перестать бояться и отбросить ограничения, но умерить себя знаниями и мудростью опыта.

Я применил это сам, и в последние несколько лет моя производительность возросла невероятно.

Вот несколько практических советов, которые увеличили мою производительность, как разработчика.
  • Набрасывайтесь, прежде чем осмотреться. Я перестал читать так много теории по технологии, прежде чем погрузиться в нее. Я начал применять ее и потом уточнять мои знания, вместо того чтобы сначала прочитать, а потом делать.
  • Перестаньте волноваться о том, как. Часто, когда я рассматриваю некое направление работы или новый проект, я в первую очередь я рассматриваю пути выполнения. Это убийство мотивации и пустая трата времени. Как не так важно, что и когда намного важнее. Как заставляет нас копаться в деталях. Я начал верить в себя и в то, что выясню как, когда понадобится.
  • Не бойтесь сделать неаккуратно в первый раз. Много раз я хотел начать с чистого решения проблемы. Часто это просто трата времени, потому что вы не знаете о проблеме достаточно, чтобы разработать корректное решение, пока не начнете ее решать.
  • Не бойтесь переписывать код. Это близко к моему прошлому утверждению, но я выделил это, потому что это важно само по себе. Переписывать что-то не так плохо и сложно, как кажется. Если вы не боитесь полностью переписать какой-то свой код, у вас больше шансов решить проблему почти оптимальным способом, который поможет двигаться вперед, и не застрять.
  • Признайте, что нет идеального решения, есть только решения, оптимизированные по одному или нескольким параметрам. Некоторые решения имеют меньше компромиссов, чем другие, но все решения имеют компромиссы, которых нельзя избежать, как ни старайся.
  • Не бойтесь потерпеть неудачу, но потому, что старались как могли, а не потому, что сдались. Лучше попробовать двадцать раз взяться за большое дело и на двадцатый раз достичь успеха, чем решать маленькие задачки, которые вы умеете решать с первого раза. Вы можете достичь ровно таких высот, с каких готовы упасть. Главное в неудаче то, что если вы упали, всегда можно подняться.


Мораль этой истории...

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

Не давайте своим знаниям «ремесла» разработки ПО быть помехой вашей производительности, или вы будете вынуждены наблюдать как те, у кого меньше навыков и знаний, постоянно превосходят вас, пока вы гневно и резко критикуете их со стороны.
Rus Wizards
0.00
Company
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 66

    +21
    есть такой хороший принцип
      +20
      очень сложно делать просто
        +22
        Особенно с современными enterprise-технологиями и «стандартами».
        +2
        stupid and short
          0
          Есть ещё один прекрасный девиз:
          «Fire! Aim! Ready!»
          +1
          Очень хорошая статья и очень неплохой перевод. Спасибо.
            +1
            Подпишусь под каждым словом! Спасибо за отличное изложение.
              0
              Очень интересно написано. Однажды мне сказал бывший директор, что нельзя вечно сидеть на снежной вершине горы в одиночестве и медитировать. И лично мое мнение, это то что «мыслитель» и «творец» в человеке должны жить в гармонии, все должно быть в меру и это будет настоящий дзен программист постигший все вершины.
              image
              у этого знака все ответы
                +2
                Если просто начать копать, то методом последовательных приближений, скатишься на дно потенциала сложности. Крутые стенки дна уже не позволят тебе легко из него выскочить.

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

                Либо нужно делать свои продукты так, чтобы избегать крутых стенок у ямы, так, чтобы в любой момент можно было свернуть в сторону. Собственно, все ООП и прочие способы блочного кодинга именно для этого и нужны.
                  0
                  Весьма важное уточнение, спасибо.

                  Сам сейчас нахожусь в подобной ситуации, когда костыли от предудыщих решений проблем мешают реализовать новые идеи — приходится много переделывать…

                  Но не будь текущего кода — не появились бы и эти новые идеи, как заменить его на более совершенный. Так что и кодить в поиске решения наощупь надо, и теорию прорабатывать предварительно тоже надо. Баланс необходим, как и везде )
                    0
                    надо отделять архитектуру от реализации и архитектуру продумывать. А вот реализацию, на первое время, можно делать саму наитопорную.
                    В вышеприведенном примере с копанием, нужно задуматься о стенках ямы, зато копать можно начинать даже руками или детским совочком, если нет лопаты.
                  –27
                  Автор, иди клепай горшки дальше, а то теоритизировать и иделы строить тут вздумал.
                    +26
                    Первое мое приложение для Android я начал писать по принципу «чтобы работало», я написал его быстро, хоть и писал на java впервые, все прекрасно работало, получилось около 5 тыс строк кода и всего 5-6 выполняемых операций. Затем я начал дополнять приложение новыми функциями и по мере надобности переписывать, и оптимизировать код. Все шло достаточно быстро и вот моя программа уже выполняла более 60 операций и имеела большое количество настроек, а код при этом умещался в 700 строк.
                    Но потом произошло страшное, я прочитал кучу теории о том как надо и как правильно писать приложения под Android, о том какими они должны быть внутри и снаружи, ровно в этот момент развитие приложения остановилось и теперь мне очень сложно заставить себя начать дальнейшее его развитие.
                    Согласен с автором, на все 100%
                      0
                      А что вас подтолкнуло читать теорию? Уж не 700 ли строк? :)
                        0
                        Задался вопросом «все ли я верно делаю?».
                          0
                          Ваше приложение работает и выполняет 60 функций — вы всё делаете верно.
                      +18
                      Наша математичка всегда говорила, задавая 40 интегралов на дом, что количество рано или поздно переходит в качество. Очень мудрая женщина, кстати говоря.
                        +3
                        … теперь когда я своим студентам задаю 40 и больше интегралов — говорю им то же самое. Нужно только придумать еще пару фраз, чтобы они еще и решали их дома.
                          0
                          Объясните им на кой черт они нужны. Когда я понял зачем они нужны, у меня была лишь огромнейшая дыра в знаниях :(
                          –2
                          Количество никогда не переходит в качество. Какое бы количество дерьма у вас не было, в мёд оно не перейдет. Оригинал звучал примерно так (по памяти): количесвенные измененеия, при определенных условиях *могут* переходить в качественные.
                            +3
                            Количество никогда...
                            количественные измененеия, при определенных условиях *могут*…
                            Хорошо, что Вы заметили ошибку с кванторами у оппонента. Жаль, что не заметили у себя.
                              0
                              Ошибки нет. Я говорю в первом предложении об абсолютных величинах, а во втором об изменениях. Вы даже сами их выделили, «количество» vs «количественные изменения».
                                0
                                Количество всегда переходит в другое качество.
                                  +1
                                  Количество абсолютно всегда переходит в качество, ибо закон сие есть. Вопрос лишь в критической величине этого количества и неизвестности получаемого качества. Ваш пример: собирая говно дома мед конечно не получите, однако в определенный момент в дом войти не получится, или к примеру крышу у него сорвет.
                                    0
                                    Количественные изменения == изменения в количестве, что и имеют в виду, говоря «количество».
                                  +1
                                  Не соглашусь — большое количество дерьма можно загнать как удобрение (или в биореактор на метан:)). Переход количества в качество — это скорее психологический феномен, нежели физический там или математический. Хотя в математике примеры есть такого перехода — счетные и континуальные множества например обладают разными качествами.
                                    0
                                    Это, скорее, философская категория прежде всего. Но и в физике имеет место быть — пробой диэлектрика в конденсаторе, например. Или изменение агрегатных состояний веществ и прочие фазовые переходы.
                                    0
                                    Зато вы научитесь превосходно делать дерьмо, намного лучше чем те кто делает мёд. А кто знает, может в вашей задаче вам нужно 100 кг дерьма а не ложка мёда?
                                  +5
                                  К Не бойтесь сделать неаккуратно в первый раз. и Не бойтесь переписывать код. можно добавить Делайте прототипы (которые точно не пойдут в production). Чтобы ещё больше снизить страхи можно делать прототип, на языке который не соответствует ТЗ. Иногда, когда требования не сформулированы ещё толком и подводные камни не ясны, я делаю прототип на RoR (очень удобны для этого), а после утверждения и нащупывания камней, пишу на PHP. Код, который писал на рельсах не жалко «выбрасывать», он с самого начала был для этого предназначен.
                                    +1
                                    Владимир, а можете статью написать об этом? Было бы интересно почитать.
                                      0
                                      А о чём собственно? Каких-то общих принципов нет вроде, прототипирование по сути является итеративным процессом сбора требований и формированию подробного ТЗ по ним, плюс проверка «на прочность» выбранного интуитивно на первом этапе разделения ответственностей между сущностями приложения. В общем слабоформализуемый процесс, по-моему, чтобы описать его в общем. Конкретные языки или фреймворки особого значения не имеют, разве что должны следовать одной парадигме (ООП в частности) и использовать схожую архитектуру (MVC). А так процесс можно считать комбинацией agile методологий и водопада — по первой создаем прототип, до его окончательного утверждения заказчиком, а по второй релизим продукт.
                                    +7
                                    Причина, думаю, в том, что сделав в первый раз и получив определенный опыт, в следующий раз хочется нового опыта. Начинаешь задумываться, а как лучше, универсальнее, эстетичнее. Вылезают такие вещи как архитектура приложения, шаблоны, абстракции, фреймворки. А реальный результат затягивается. Затем начинаешь применять различные теории, парадигмы, методологии типа TDD, etc… Результат становится практически недостижим, потому что ориентация уже становится на сам процесс, а не на результат. Потом становится мало языка программирования для элегантного выражения всей полноты мыслей. Наиболее талантливые изобретают свой язык, а другие начинают использовать что-то экзотическое. И под конец заканчиваешь карьеру как полный теоретик парадигм и импотент в продуктивном плане. Отсюда, кстати, идет извечная борьба между тем как «правильно» и тем как «удобно». Излишнее теоретизирование и повсеместное насаждение шаблонов и парадигм — одна из современных проблем IT.

                                    Поэтому главный рецепт — не терять цель из виду, быть ориентированным на результат, а программирование рассматривать как средство достижения результата.
                                      +1
                                      Все правильно.

                                      Но далеко не у всех цель сделать как можно проще с меньшими затратами времени. У некоторых цель выжать как можно больше денег с заказчика и сделать сложный продукт, который кроме них никто поддерживать не сможет.
                                        +3
                                        Надеюсь, скоро у них закончатся заказчики.
                                          0
                                          Обычно это не глупые люди и знают как удержать заказчика (применение сложных решений и тяжелых фреймворков — один из этих способов, кстати).
                                          0
                                          Разные цели, вернее подцели, могут быть. Например растянуть разработку по времени, если других заказов не предвидится. Или сделать хоть одну работу достойную упоминания в портфолио. Или изучить новую технологию, язык, фреймворк и т. п. за счёт заказчика. Много ещё можно перечислить мотивов по которым разработчик не хочет (иной раз на подсознательном уровне) сделать как можно проще с меньшими затратами времени. Особенно учитывая, что как можно проще зачастую сложно отделить от говнокода.
                                          0
                                          По большей части соглашусь с автором статьи. Однако, как выше написали, стоит не просто сразу “набрасываться“, а начинать с прототипа. Если речь о коммерческой разработке, то потенциальные ошибки в начале могут очень дорого обойтись в конце. Стоит с начала все-таки хоть немного подумать над проектом, в том числе задавая вопросы “Как?“.

                                          Если речь о разработке для себя или тренировке в освоении новой технологии, то конечно стоит полностью следоавать подходу автора.
                                            0
                                            Я предлагаю лишь стараться искать решение оптимальное на 90 процентов, зная, что можно будет вновь вернуться к проблеме, если вам действительно нужно будет найти лучшее решение
                                            Как быть, если принятое решение будет невозможно изменить впоследствии? Например, если речь идет о неправильно выбранной архитектуре.
                                              +4
                                              Архитектуру, правильную на 90%, уже не так сложно поменять, а практика показывает, что «идеально» выбранная архитектура, вдруг тоже становится неподходящей, когда меняются требования.
                                                +1
                                                Тогда тем более верно. Надо написать проект архитектуры — и потом рассуждать, чем хорош уже написанный проект, а не каким должен быть проект идеальный. В первом случае за 2-3 итерации у вас может уже появиться готовый проект, а во втором вы станете обладателем толпы отговорок, почему ничего делать не надо.
                                                –2
                                                Не вам всем точно книгу надо «Как перестать писать статьи и начать программировать».
                                                  +6
                                                  Вам надо перестать писать глупости.
                                                  0
                                                  Очень хорошо написано, вот только не пойму как TDD сюда привязать. С одной стророны хорошо подходит, ели код затестирован то изменяй его сколько влезет. А с другой стороны, разработка тестов столько времени занимает, а при TDD с помощью тестов вообще, так сказать, концепность закладывается.
                                                  Как вы считаете, нужны тесты, или это таки тормоза оптимальной разработки?
                                                    +1
                                                    Очень сложный вопрос. Лично я смотрю по задаче. Ключевые места архитектуры тестируются достаточно тщательно, а общая логика — весьма поверхностно. На моей практике тесты всегда не успевают за динамикой проекта, и просто требуют обновления, вместо того, чтобы давать уверенность. В любом случае нельзя считать, что корректный запуск тестов означает правильность очередного изменения.
                                                      0
                                                      Как минимум первые четыре совета хорошо ложатся на TDD, имхо:

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

                                                      Перестаньте волноваться о том, как. — тестами мы изолируем, что делает код от того, как он это делает.

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

                                                      Не бойтесь переписывать код. — тесты дают нам уверенность, что переписывание кода не изменит его (документированной) функциональности.
                                                      +1
                                                      Сильно от задачи зависит. Вот вам мысленный эксперимент:

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

                                                      Я уверен, что последний справится лучше.
                                                        +2
                                                        Хорошо напишет индекс только тот у кого будет реальная база с реальными пользовательскими данными, совсем в вакууме его написать не выйдет. А пользу книжек никто не оспаривал, тем более в таких тонких вещах как базы данных, или алгоритмы.
                                                          +2
                                                          Но если тот, кто напишет быстрее, напишет что-то, что работает хоть как-то, то вокруг этого можно уже состряпать презентацию и выбить кусок финансирования на проект в целом. К этому времени как раз уже подоспеет качественная реализация.

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

                                                          0
                                                          С чего-то всегда надо начать и наскок — довольно хороший вариант. Однако от теории не убежишь все равно. Согласен с автором выше, что должен быть баланс.
                                                          Если бы не было паттернов и стандартов, то сопровождение кода превратилось бы в сущий ад. Особенно при работе в команде.
                                                          Да и вообще, лучше немного поковыряться проблему, потом сесть подумать и уже начинать писать как надо.
                                                            0
                                                            Согласен, и у автора как раз о балансе, и это верно. Главное, не садиться думать надолго.
                                                            +3
                                                            Если бы дети сначала учились читать, то они бы потом не смогли научиться ходить.
                                                              0
                                                              Хороший пример — KDE.
                                                              Выход KDE4 был откровенным провалом, но она была построена на новой архитектуре, все было недопилено, но продумано, и вот прошло несколько лет — GNOME 3 проходит то же самое, а у KDE все уже сделано, осталось только тихо и спокойно фиксить мелкие баги, набирая при этом тонны новых юзеров каждый день.
                                                                0
                                                                В курсе Human-Computer Interaction на courcera рассказывали про эксперимент с рисованием баннеров или чего-то такого вместо горшков. Результат аналогичный.
                                                                  –2
                                                                  Я очень надеюсь, что военный, медицинский, банковский и транспортный софт пишут «непродуктивные» программисты, которые много думают, прежде чем что-то сделать.
                                                                    +3
                                                                    Все что касается чего-то государственного, исходит из других критериев: критерий вины.
                                                                    Ты должен написать так, чтобы ты не оказался виноватым. Это не обязательно ведет к качеству.
                                                                      +2
                                                                      за другие виды софта я отвечать не буду, но часть пограничного и военного софта пишут студенты в НИИшках в качестве первой работы (сам писал), и еще часть — срочники (друг был свидетелем). Но да, наверное, где-нибудь существуют много думающие боевые программисты. Российский государственный медицинский софт — я не советую вам много об этом думать. Ну а у финансистов всё хорошо, да.
                                                                        +1
                                                                        В этом софте важнее тестирование, чем программирование.
                                                                        +1
                                                                        Считаю, что в теме можно смело убрать слова «разработка» и «ПО», с точки зрения сисадмина полностью поддерживаю и соглашаюсь с приведенным подходом.
                                                                          +2
                                                                          Если горшки принимают по весу — я бы слепил один большущий кусок грязи и назвал его горшком. Если по количеству — много маленьких кусочков грязи. Без контроля качества никуда, ибо приемные показатели оптимизируются в ущерб всему остальному.
                                                                            +2
                                                                            видимо участники горшечного состязания все-таки хотели лепить именно горшки
                                                                              0
                                                                              Я тоже об этом подумал, видимо художники не склонны мыслить вырожденными решениями :) Хотя базовое качество скорее всего гарантируют механизмы группового поведения, и внутренней конкуренции.
                                                                              +4
                                                                              Нужна и теория и практика. Я знаю пару человек, которые очень любят изучать всё. Функциональную парадигму вдоль и поперек. Десятки языков, теории. На каждом могут программировать.
                                                                              И один из них мне жаловался, что он завидует профессионалам в программировании. Нет, он работает программистом, это не хобби. Но тем не менее, жалуется, что не может создать что-то сложное.

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

                                                                              Думаю, тут проблема, которая в статье описана, немного не так моделируется. Скоростью возможно и можно слепить горшок. Но программирование немного сложнее. Предлагаю такую модель. Человек не может одновременно концентрироваться на многих объектах. Допустим, может только на 5. Таким образом ему надо доводить работу до автоматизма. Именно кодированием, т.е. писать и читать код, пока эти навыки не уйдут в подкорку. Далее, приступать к изучению новых знаний.

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

                                                                              Тут пришло время поизучать функциональное программирование. Взглянуть иначе на программирование, на паттерны и рефакторинг.
                                                                              И также — ТДД. Вот как раз оно и заставляет отказываться от паттернов и набрасываться на код. Здесь человек уже настолько привык к языку программирования, что больше ему ничего не нужно. Не нужны паттерны, не нужны диаграммы.
                                                                              Как-то когда я был давно совсем маленьким, гладил рубашку. Никак не мог это сделать, расправлял ее, но не мог, где-то сминалась. Отец сказал: цель — чтобы утюг помещался и было еще немного места. Тебе не надо идеально расправлять. И тогда у меня начало получаться.
                                                                              Необычный, конечно, пример. Но из жизни и близкий.
                                                                              Вам не надо код представлять весь. Это нарушение инкапсуляции. Надо научиться работать с кодом на ограниченном участке. Видеть, что в нем не так, даже если вы всего не знаете о структуре. И это повышает и производительность и качество. Потому как качество кода в целом прямо зависит от качества его частей.

                                                                              Так, сумбурно описал то, к чему вы пришли.
                                                                                0
                                                                                Совершенно согласен! Раздражают очень люди, которые думают, что с количеством технологий становятся лучшими программистами. С другой стороны, люди которые не считают себя гениями или эрудитами работают лучше.
                                                                                +1
                                                                                У меня проблем схожего толка. В голову приходит мысль о проекте или модуле, после дня продумывания я вижу столько деталей и проблем, что опускаются руки. С другой стороны постоянно наблюдаю, как неопытные группы, не особо вникая в мелочи, бросаются на амбразуру… и чуда не случается, они вязнут в достаточно предсказуемых местах, но по факту создается чуть больше. Х/з кто тут прав и что с этим делать.
                                                                                  +1
                                                                                  Мой случай. Бывает, что вот есть идея интересная, реализовать суть можно за день, например, а как задумываешься, там после прототипа столько ещё пахать, что думаешь «ну нафиг». Жду кнопку «Сделать всё правильно», хотя вроде и сам могу. Тоже не знаю, что с этим делать.
                                                                                  0
                                                                                  Лучшее враг хорошего!

                                                                                  Only users with full accounts can post comments. Log in, please.