Решаем нерешаемые проблемы.

Сначала немножко о себе. В какой-то момент, я заметил, что меня считают хорошим (а некоторые даже отличным) программистом. И вот, недавно я задумался, а собственно говоря с чего это меня им считают?

Вот некоторые мои характеристики:

— у меня плохая память (API на память я не помню)

— код чаще всего я пишу не слишком аккуратно

— архитектуру, конечно пытаюсь поддерживать, но тоже нельзя сказать, что я великий архитектор

— языки программирования (например тот же C++ на котором постоянно пишу) знаю весьма поверхностно

— техническую документацию читать не люблю

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

Итак, открывает секреты (повышая тем самым себе конкуренцию):

А) Я глубоко убежден, что нерешаемых задач нету. В тот момент, когда даже хорошие программисты бросают задачу с фразой: “Это сделать нереально”. Я продолжаю идти вперед и чаще всего мне таки нахальством/упорством удается ее добить.

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

Как сказал один мой знакомый (привет тебе Шура), что есть что-то в моем характере граничащее с понятием хуцпа (я этого слова год назад еще не знал).

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

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

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

В общем, решение таких задач лежит не в техническом поле, а в управленческом. И все, что нужно – задать себе вопрос, а какую задачу мы могли бы решить в нужные сроки и с нужными ресурсами?

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

Так, что я не хороший программист. Я человек, который умеет решать нерешаемые проблемы в программировании.

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

37 комментариев to “Решаем нерешаемые проблемы.”

  1. В «Криминальном чтиве» был такой персонаж «мистер Вольф». Он решал проблемы тем же способом. 🙂

    • Helen:

      «таким же способом» — это каким-же? упорство и наглоцелеустремленный подход к делу?

      • 1. Нет нерешаемых задач
        2. Чтобы нерешаемую задачу решить, ее надо переформулировать.

        • Helen:

          ОТЛИЧНЫЙ подход к жизни — в целом, сильный и мощный, с таким подходом можно действительно многое решить

    • Victor Ronin:

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

      Кстати, по воспоминаниям, все проблемы там решались добрым словом и пистолетом 🙂

      • Когда киллеры случайно в машине пристрелили кого-то, то им понадобилось быстро привести в порядок машину. Для решения этой задачки (по-моему, у них там был час времени) и был призван мистер Вольф.

  2. Helen:

    как по-мне, так такое качество как упорство и небоязнь,да еще и усидчивость (это своего рода выносливость — тоесть сила, что встречаеться в человекокачеств далеко не часто), да еще — повышеннаяагрессивность для решения сложных задач — где-бы-то это не встречалось: в обычной «бытовой» или в бизнесе-творчестве — это потрясающекласснонеобходимое, а местами и — жизненно необходимое качесво. С таким подходом можно решить любые преграды-задачи, ну — максимально решить.
    А, то что «профкакчества технические — другие» — это всего лишь все субъективно, потому как и «проф» — это хорошо, но их без «огонька» и порыва упорства и без умения ими управлять и, опять же — без усидчивости — это не всегда полноценно, особенно, если дело касается «трудных задач».

    • Victor Ronin:

      Да, я тоже думаю, что важное очень важно куда и как двигаться. А профкачества, это подспорье в движение в этом направление.

  3. rainy_sunny:

    «похоже эта не так просто»
    «нерешаемые проблемы в программирование»

    Отличный блог, но похоже, вы пишете текст в T9 и не проверяете..
    Это его немного портит 🙁

    • Victor Ronin:

      Я знаю, но увы ничего не могу с собой поделать 🙂

      T9 барахлит, и проверка не помогает….

      • Злостный оффтоп.
        Вчера дежурный наряд милиции задержал учительницу русского языка и литературы в состоянии сильного алкогольного опьянения, пытавшуюся исправить вывеску на магазине «ОБОИ» на «ОБЕИ»
        🙂

    • Helen:

      чем? как по-мне так все отлично «читабельно», ведь не в формате-ж-дело, а, собственно — в смысловой нагрузке, не так ли? это ж не «роман нью»…ведь все ж…

      • rainy_sunny:

        Ну лично мне глаза режет. Пытаешься понять, правильно ли угадал слово… А хочется просто читать 🙂

  4. vansickle:

    Важно кто вас таким считаем, т.е. это мнение коллеги-разработчика, менеджера, работодателя/заказчика? это все очень разные мнения.

    То что вы перечислили в качестве своих недостатков — это то за что вас ценили бы
    программисты, а секреты — ваша ценность для заказчика/работодателя/себя как предпринимателя.

    • vansickle:

      тег попутал, надо так:

      В какой-то момент, я заметил, что меня считают хорошим (а некоторые даже отличным) программистом.

      Важно кто вас таким считаем, т.е. это мнение коллеги-разработчика, менеджера, работодателя/заказчика? это все очень разные мнения.

      То что вы перечислили в качестве своих недостатков — это то за что вас ценили бы
      программисты, а секреты — ваша ценность для заказчика/работодателя/себя как предпринимателя.

      • Victor Ronin:

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

        Насчет того, кто меня считает хорошим программистом. Я бы сказал, все понемножку (включая программистов).

  5. GeF:

    Уверенность в себе и своих силах очень важное качество

    • Victor Ronin:

      Кстати, я не говорил о уверенности 🙂 Я говорил о настырности 🙂

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

    • Helen:

      и еще и «количество» не повредит такому «качеству» 🙂

  6. Витя привет 😉

    то есть по сути ты программист с менеджерским подходом 🙂

    • Victor Ronin:

      Я программист с подходом конечного потребителя.

      Именно конечному потребителю интересно чтобы проблема была решена или хотя бы переформулирована и решена. И конечный потребитель готов за это платить деньги.

      А вот все остальным интересно получить деньги, и взамен они готовы что-то делать.

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

      Получается, что я на время становлюсь программистом + конечным потребителем.

  7. […] Browse other articles in Время, Эффективность categories. « Решаем нерешаемые проблемы. […]

  8. Я думаю, все дело в том, что у нас (пост-СССР) слово программист заменяет собой два довольно разных понятия:
    software developer (разработчик ПО),
    coder, code monkey (кодировщик?, писатель исходного кода).

    Причем, первое, как бы включено в понятие «программист» (а в английском является синонимом для programmer), а второе вообще упоминается вскользь и не имеет литературного либо научного определения в русском языке (в английском — Code monkey).

    Отсюда и путаница в сравнениях :).
    Называйте себя всегда и везде разработчиком ПО, или инженером ПО, и не будете удивляться 🙂

    • Victor Ronin:

      Я думаю не стоит делить эти понятия на два. Раньше может это было актуально.

      Сейчас кодер в чистом виде не может приносить компании пользы. В свое время, такая профессия могла иметь смысл, например для набивки перфокарт (так как это занимало много времени). Сейчас же именно набивание текста на клавиатуре не является делом, которые тормозит программирование.

      Насчет того, как себя называть. Да, правильно себя действительно называть разработчик ПО или инженером ПО (звучит немного странно, так как прямая калька с software engineer).
      Но, честно говоря, я в последнее время скорее интересуюсь обязанностями людей, чем позицией. Так как сейчас есть куча VP of engineering, у которого нет не одно подчиненного. И software engineer который тянет на себе 10 человек, иногда с двумя уровнями находящимися ниже его.

      • GeF:

        Думаю просто надо называть вещи своими именами, тогда не будет возникать противоречий. Как раз на западе и более узко разграничены специализации, а у нас наоборот у народа мышление — мастер на все руки. Например мне долго приходилось один раз объяснять своему родственнику что я не чиню компьютеры, а программирую 😀

        • Victor Ronin:

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

          • Да, их там нет. Они есть в Индии и у нас, в аутсорсинге — когда западные (или даже наши) разработчики сгружают кучу рутины за небольшие деньги, те кто эту рутину разгребают, как раз кодингом и занимаются. Создать экземпляр такого-то класса, присвоить значения полей, вызвать функцию библиотеки фреймворка. Нажать «билд», втыкать в окна… Это разработка? Я так не думаю.

            • Victor Ronin:

              Я еще не разу не видел, где оффшорилась похожая последовательность:
              «создать экземпляр такого-то класса, присвоить значения полей, вызвать функцию библиотеки фреймворка.»

              Это быстрее и дешевле сделать программисту внутри фирмы чем оффшорить.
              Так как последовательность того, что придется делать:
              а) написать кому-то, чтобы сделали,
              б) объяснить конкретно зачем все это и как протестировать
              в) проконтролировать выполнение
              д) проверить качество результата
              г) оплатить выполнение

              Да, зачастую сгружают небольшие подсобные задачи (хотя чаще сгружают проект целиком). По большему счету есть минимальный размер задачи, который выгодно offshor’ить.

              Опять же например небольшая задача/проект — написать библиотеку по работе с версией GPS’а XXX, уже не является просто кодерской задачей.

              Да, естественно она не требует высшего пилотажа программирования, но она вполне требует понимания, как писать библиотеку, отладки, работы с скажем Serial или BT портом и т.п. И назвать это просто кодингом, как-то рука не поднимается.

              Кстати, offshore выгоден именно на больших объемах работ. Скажем, если оффшорить работу в 10 часов. То выгода этого 10 часов*$50/ч (США) = $500.
              Оффшор 10 часов*$15 (Восточная Европа) = $150. Чистой выгоды $350. Эту выгоду быстренько съедят накладные расходы.

              Вот, когда offshor’иться (а лучше открывается офис) на скажем 30 программистов, то цифры становятся интересные 30 программистов*160 часов в меся*50$/час = $240K в месяц в США и $72K в восточной Европе. Соответственно из-за разницы в $170K в месяц ($2M в год) вполне можно и подергаться. Даже если это потребует найма дополнительного человека в штатах и двух в offshore (для поддержки такой же эффективности), то все равно выгода будет $1M в год.

              Опять же из моего опыта (с обоих сторон offshore). Чаще всего выгружается внаружу либо проект целиком, либо его куски, которые требуют большого времени (зачастую таки не слишком сложные).

              • GeF:

                Интересные цифры наводишь и расчеты 🙂

                • Victor Ronin:

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

  9. […] зачастую переформулировка задач (как я писал в статье Решаем нерешаемые проблемы) помогает принять гораздо более правильные решения и […]