Я хотел бы начать с истории:
Эта история из книги Art & Fear.
Признаюсь, я еще не прочитал ее, но я наткнулся на эту историю однажды, и она поразила меня.
Разработка ПО — сложная профессия. Довольно легко научиться программировать, но чтобы научиться, действительно строить полноценные программные системы, может потребоваться много лет обучения и практики.
Одна вещь, которую я заметил — разработчики ПО имеют тенденцию быть очень продуктивными.
Я помню дни, когда у меня была дискета с разными программами, над которыми я работал. Тогда казалось, я начал понимать разработку ПО лучше, в действительности я начал становиться менее продуктивным.
Почему так случилось?
У меня есть несколько теорий, но основная в том, что, когда мы не знаем, что мы делаем, мы просто пытаемся довести задачу до конца.
Помните, вы были ребенком? Скорее всего вы много рисовали. И наверняка эти рисунки не будут так хороши, если судить их по вашим сегодняшним стандартам, вы даже могли бы назвать их ужасными.
Почему вы перестали рисовать так много сейчас? (Может быть вы и нет, но большинство перестали.) Лучше поставить вопрос так: «почему вы рисовали так много тогда?»
Есть много ответов, но я думаю большинство из нас решит, что одна из причин в том, что дети просто познают и учатся, и они не скованы какими-то ограничениями.
В какой-то момент мы становимся старше, и понимаем, что такое искусство, и как оно должно выглядеть. Мы могли бы даже узнать, как рисовать правильно. В конечном итоге у нас появляется представление о том, что такое хорошая картина, которое приводит к тому, что очень сложно взять в руку этот карандаш.
Я знаю, что прошел через фазу в разработке, в которой не был и близко так продуктивен, как мог бы.
Я потратил много времени на «восхищение задачей», и еще больше на «превращение простого в сложное».
Как разработчики ПО мы имеем тенденцию ставить себе ограничения и искать идеальное решение проблемы.
Пока я не зашел слишком далеко: я ни в коем случае не советую писать говнокод и распространять его. Не делайте этого!
Я предлагаю лишь стараться искать решение оптимальное на 90 процентов, зная, что можно будет вновь вернуться к проблеме, если вам действительно нужно будет найти лучшее решение, делайте так вместо того, чтобы тратить время на решение оптимальное на 95 процентов и более.
Я писал ранее, что это самая сложная вещь, с которой я боролся, и я думаю, это актуально для многих разработчиков.
Проблема в том, что, когда мы начинаем как разработчики, мы не знаем «правильных путей» и менее ограничены в своих действиях. Мы просто идем вперед и делаем.
Когда мы начинаем учиться делать «правильно», нас часто душит это знание и ограничения, с ним связанные. Это делает нас менее продуктивными и заставляет изобретать избыточные решения для проблем.
Не во всех смыслах, но, возможно они лучше в чем-то. Может в том, что производят больше.
В моем понимании, решение в том, чтобы перестать бояться и отбросить ограничения, но умерить себя знаниями и мудростью опыта.
Я применил это сам, и в последние несколько лет моя производительность возросла невероятно.
Вот несколько практических советов, которые увеличили мою производительность, как разработчика.
Иногда быть хорошим, это плохо, потому что это мешает и парализует нас. Я обнаружил, что гораздо больше вещей делается исполнителями, а не мыслителями.
Не давайте своим знаниям «ремесла» разработки ПО быть помехой вашей производительности, или вы будете вынуждены наблюдать как те, у кого меньше навыков и знаний, постоянно превосходят вас, пока вы гневно и резко критикуете их со стороны.
Учитель керамического дела объявил в день открытия, что разобьет класс на две группы. «Те, кто сидят слева» — сказал он: «будут оцениваться только по количеству проделанной работы, те, кто справа — только по её качеству». Его методика была проста, в последний день он принесет весы и взвесит работу группы «количество»: 50 фунтов горшков это «5», сорок фунтов горшков это «4» и так далее. Те, кто оцениваются по «качеству», однако, должны сделать один, пусть и совершенный, горшок, чтобы получить «5». Время сдачи пришло, и обнаружился любопытный факт: работы лучшего качества были сделаны в группе, оцениваемой по количеству. Похоже, в то время, как группа «количество» упорно штамповала свои работы и училась на своих ошибках, группа «качество» теоретизировали об идеале и, в конце концов, только и могла показать свои старания и грандиозные теории об идеале, а также кучу бесполезной глины.
Эта история из книги Art & Fear.
Признаюсь, я еще не прочитал ее, но я наткнулся на эту историю однажды, и она поразила меня.
Чем лучше стараетесь сделать, тем хуже получается
Разработка ПО — сложная профессия. Довольно легко научиться программировать, но чтобы научиться, действительно строить полноценные программные системы, может потребоваться много лет обучения и практики.
Одна вещь, которую я заметил — разработчики ПО имеют тенденцию быть очень продуктивными.
Я помню дни, когда у меня была дискета с разными программами, над которыми я работал. Тогда казалось, я начал понимать разработку ПО лучше, в действительности я начал становиться менее продуктивным.
Почему так случилось?
У меня есть несколько теорий, но основная в том, что, когда мы не знаем, что мы делаем, мы просто пытаемся довести задачу до конца.
Помните, вы были ребенком? Скорее всего вы много рисовали. И наверняка эти рисунки не будут так хороши, если судить их по вашим сегодняшним стандартам, вы даже могли бы назвать их ужасными.
Почему вы перестали рисовать так много сейчас? (Может быть вы и нет, но большинство перестали.) Лучше поставить вопрос так: «почему вы рисовали так много тогда?»
Есть много ответов, но я думаю большинство из нас решит, что одна из причин в том, что дети просто познают и учатся, и они не скованы какими-то ограничениями.
В какой-то момент мы становимся старше, и понимаем, что такое искусство, и как оно должно выглядеть. Мы могли бы даже узнать, как рисовать правильно. В конечном итоге у нас появляется представление о том, что такое хорошая картина, которое приводит к тому, что очень сложно взять в руку этот карандаш.
Так что же произошло?
Я знаю, что прошел через фазу в разработке, в которой не был и близко так продуктивен, как мог бы.
Я потратил много времени на «восхищение задачей», и еще больше на «превращение простого в сложное».
Как разработчики ПО мы имеем тенденцию ставить себе ограничения и искать идеальное решение проблемы.
Пока я не зашел слишком далеко: я ни в коем случае не советую писать говнокод и распространять его. Не делайте этого!
Я предлагаю лишь стараться искать решение оптимальное на 90 процентов, зная, что можно будет вновь вернуться к проблеме, если вам действительно нужно будет найти лучшее решение, делайте так вместо того, чтобы тратить время на решение оптимальное на 95 процентов и более.
Я писал ранее, что это самая сложная вещь, с которой я боролся, и я думаю, это актуально для многих разработчиков.
Проблема в том, что, когда мы начинаем как разработчики, мы не знаем «правильных путей» и менее ограничены в своих действиях. Мы просто идем вперед и делаем.
Когда мы начинаем учиться делать «правильно», нас часто душит это знание и ограничения, с ним связанные. Это делает нас менее продуктивными и заставляет изобретать избыточные решения для проблем.
Итак, я предполагаю, что любители лучше профессионалов?
Не во всех смыслах, но, возможно они лучше в чем-то. Может в том, что производят больше.
В моем понимании, решение в том, чтобы перестать бояться и отбросить ограничения, но умерить себя знаниями и мудростью опыта.
Я применил это сам, и в последние несколько лет моя производительность возросла невероятно.
Вот несколько практических советов, которые увеличили мою производительность, как разработчика.
- Набрасывайтесь, прежде чем осмотреться. Я перестал читать так много теории по технологии, прежде чем погрузиться в нее. Я начал применять ее и потом уточнять мои знания, вместо того чтобы сначала прочитать, а потом делать.
- Перестаньте волноваться о том, как. Часто, когда я рассматриваю некое направление работы или новый проект, я в первую очередь я рассматриваю пути выполнения. Это убийство мотивации и пустая трата времени. Как не так важно, что и когда намного важнее. Как заставляет нас копаться в деталях. Я начал верить в себя и в то, что выясню как, когда понадобится.
- Не бойтесь сделать неаккуратно в первый раз. Много раз я хотел начать с чистого решения проблемы. Часто это просто трата времени, потому что вы не знаете о проблеме достаточно, чтобы разработать корректное решение, пока не начнете ее решать.
- Не бойтесь переписывать код. Это близко к моему прошлому утверждению, но я выделил это, потому что это важно само по себе. Переписывать что-то не так плохо и сложно, как кажется. Если вы не боитесь полностью переписать какой-то свой код, у вас больше шансов решить проблему почти оптимальным способом, который поможет двигаться вперед, и не застрять.
- Признайте, что нет идеального решения, есть только решения, оптимизированные по одному или нескольким параметрам. Некоторые решения имеют меньше компромиссов, чем другие, но все решения имеют компромиссы, которых нельзя избежать, как ни старайся.
- Не бойтесь потерпеть неудачу, но потому, что старались как могли, а не потому, что сдались. Лучше попробовать двадцать раз взяться за большое дело и на двадцатый раз достичь успеха, чем решать маленькие задачки, которые вы умеете решать с первого раза. Вы можете достичь ровно таких высот, с каких готовы упасть. Главное в неудаче то, что если вы упали, всегда можно подняться.
Мораль этой истории...
Иногда быть хорошим, это плохо, потому что это мешает и парализует нас. Я обнаружил, что гораздо больше вещей делается исполнителями, а не мыслителями.
Не давайте своим знаниям «ремесла» разработки ПО быть помехой вашей производительности, или вы будете вынуждены наблюдать как те, у кого меньше навыков и знаний, постоянно превосходят вас, пока вы гневно и резко критикуете их со стороны.
