Почему программировать так тяжело?

Original author: Joe Armstrong
  • Translation
Привет, Хабр!

В феврале мы публиковали перевод крутой статьи "Почему научиться программировать так чертовски тяжело?", которую теперь показываем новичкам. Да, научиться программировать – это целая история, длинная, с кучей разных этапов, с эмоциональными взлетами и падениями. Мы все через это проходили (или еще проходим – так держать!).

К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.

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




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

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

Определение 1: Программа это то, что преобразует исходные данные в результат.
Программист это человек, который пишет программу, а программирование — процесс написания этой программы.

Теперь давайте добавим несколько условий к моему определению программы.

Определение 2: Программа это что-то, что преобразует исходные данные в результат и зависит от следующих условий:

  • Результат программы превосходен.
  • Исходные данные превосходны.
  • Программа превосходна.
  • Исходные данные качественно и чётко задокументированы.
  • Сама программа качественно и чётко задокументирована.
  • Программа хорошо протестирована и выполняется верно.
  • Решаемая задача чётко детализирована.
  • Поставленная задача чётко детализирована.

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

Программы, которые не нужно поддерживать


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

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

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

Программы, которые нужно поддерживать


Для поддерживаемых программ всё противоположно последнему сценарию. Исходные данные для программы и сама программа должны быть превосходными и хорошо задокументированными.

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

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

Что ещё усложняет программирование


Есть три вещи, которые делают программирование сложной задачей:
  • Исправление тех проблем, которых не должно было быть вообще.
  • Отсутствие времени на изучение нового
  • Плохая атмосфера для программирования

Давайте рассмотрим эти сложности — настоящих воров времени.

Исправление тех проблем, которых не должно было быть вообще


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

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

Что делать, если в документации сказано «выполните XYZ, тогда у вас получится PQR», вы выполняете “XYZ”, но “PQR” не получается? Если вы везунчик и те, кто написал программу находятся где-то поблизости, вы можете пойти и придушить их, а если не получится, можно попытаться найти ответ в Google или поковырять код в поисках ответа.

Пользоваться гугловской рулеткой для исправления багов чудовищно раздражает. Я гуглю немного и очень скоро нахожу где-нибудь печальный пост от такого же несчастного, как я, который нарвался на проблему, совершенно идентичную моей. Моё сердце бьётся в предвкушении. Трясущимися пальцами я ввожу магическую формулу, которая снимет проклятие, и… ничего. Проблема не исчезает.

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

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

Эта проблема, кстати, та самая вещь, которая отбирает у меня максимум времени, думаю, 60-70%. Однажды я потратил около недели пытаясь разобраться со сломанным LDAP-сервером (мой начальник запретил мне применить мой собственный LDAP-сервер), но спустя неделю сражений со сломанным сервером, хреново задокументированным и написанным на языке С, у меня случился провал в памяти, так что я забыл, что мне сказал начальник и случайно установил сервер на Erlang с нуля во время обеденного перерыва.

По правде говоря, это был не полный LDAP-сервер, но я и не хотел полный. Я хотел, чтобы заработали несколько команд, что оказалось легко исправить.

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

Решение проблем без получения новых знаний


Я лентяй. У меня отлично получается бездельничать. Но когда я хочу составить диаграмму в LaTeX, я не хочу читать 391-страничную инструкцию. Знаю, теперь вы обвините меня в лени и в том, что я морально испорчен, и я знаю, что должен вначале читать дружественную инструкцию, но я хочу иметь диаграмму в документе в течение 10 минут, исключив 391-страничную инструкцию.

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

Взять, например, создание документов. Я никак не мог выбрать между TeX/LaTeX и XSLT-FO и моим собственным Erlguten.

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

Думаю Джамбаттиста Бондони, когда он создавал свой Manuale Tipografico в 1818 году, не был особенно обеспокоен, что верстка одной страницы займёт несколько недель. Но теперь, когда у нас появилось гораздо больше времени, потому что мы можем заставить станки делать скучную и опасную работу, у нас не осталось времени, чтобы делать что-то качественно.

Я спросил начальника, не хочет ли он «симпатичные слайды» для следующей презентации, он согласился, при условии, что я сделаю их до завтра. Но времени для изучения TeX как следует не осталось (а на это, думаю, потребуется год или что-то около того), как его не осталось и для того, чтобы применить свой собственный язык верстки (что потребовало бы пять-десять лет) и для того, чтобы написать его непосредственно в PostScript (за неделю или около того). Так что, видимо, PowerPoint…

Плохая атмосфера для программирования


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

К счастью у нас есть место, куда мы можем уйти, чтобы не отвлекаться. Сон. Множество программных проблем решается, пока вы спите.
Есть два способа:

Первый: вы загружаете мозг проблемами, затем засыпаете, а на следующий день просыпаетесь, и некоторые из проблем решены. Легко.

Способ второй: вы постите проблему в интернете, или пишете об этом твит перед сном, и на следующий день кто-то присылает вам решение по мейлу.

Чтобы стать хорошим программистом нужно много времени: вам нужно получить много информации, и знать, к кому обратиться, если вы застряли.

Удивительно, но факт


Когда я закончил эту статью, я хотел проверить орфографию. Режим Emacs-Ispell решил провести забастовку. Он не смог найти aspell, программу, которую я использую для проверки правописания.

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

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

Я не вижу причин, почему мой орфографический контролёр мог сломаться — всё в порядке, я ничего не менял. Ну, я установил новую версию Erlang и Julia, написал несколько лекций, после того как в последний раз проверял документ на ошибки.

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

Думаю, существуют такие вещи, о которых мы просто никогда не узнаем.

Перевод: Наталия Басс / Hexlet.io
Hexlet
Практические уроки по программированию
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 111

    +14
    Любой минус можно превратить в плюс. Решать проблемы увлекательно, а решать их в фоне чертовски круто. Если вы программист, то вы столкнувшись с проблемой можете, изучить материалы по теме и пойти пить чай или играть в игру или выпить пива, вернувшись вы как правило будете знать решение своей проблемы. Если вы например работаете грузчиком, то столкнувшись с проблемой вы не сожмите ее решить выпив пива с друзьями.
      +11
      Плюсую за все предложения в абзаце кроме последнего.
      Если вы например работаете грузчиком, то столкнувшись с проблемой вы не сожмите ее решить выпив пива с друзьями.

      О как же вы не правы… ;-)
        +3
        Эм, вы намекаете, что грузчик может просто забить? Или на то, что он может призвать друзей на помощь?)
          +3
          На самом деле любую проблему можно решить выпив пива с друзьями, главное чтобы друзья были правильные :)
            –2
            Значит ли это, что непьющий программист не способен решить проблему? :)
          +1
          Ну надо понимать, что для этого надо обладать серьезной внутренней дисциплиной, это работает не всегда и сразу оно так получаться не будет. Иначе бы у студентов дипломные проекты, а у аспирантов диссертации придумывались за игрой в доту. Я так понимаю, данная статья все же больше общеобразовательная для новичков.
            +1
            Дело даже не в дисциплине, а в концентрации на проблеме, подсознание должно желать решить проблему, я не знаю как добиться этого, кроме как действительно желать. Конечно, я не утверждаю, что можно запустить игру/налить пива, а программа сама напишется и протестируется, над этим нужно работать и работать много, но перевести задачу в фон частенько бывает довольно полезно.
          +12
          Программа это то, что преобразует исходные данные в результат.

          Я бы сказал, что программа — это то, что решает проблему своего пользователя, человека или другой программы. Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время». Можно написать идеальную и никому не нужную программу программу. Соответственно, в условия я бы добаил еще ожидания пользователей и корректность поставленной задачи этим ожиданиям. Зачастую про пользователей программисты и думать не думают (простите за каламбур), и в итоге наши устройства заполнены приложениями, несущими боль и страдания.
            –3
            Я бы сказал, что программа — это то, что решает проблему своего пользователя, человека или другой программы

            Нет, программа решает проблему именно программиста. Проблему создания готового продукта.
            Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время».

            Все верно, а пользователь покупает приложение (и функции, которые оно даст), а не программу.
              +3
              Да понятно, что задача программиста — писать хороший код в нужные сроки и т.п., но программист, который не думает о том, что находится за пределами его зоны ответственности, так и будет всю жизнь писать код по спецификации сверху. Мне кажется, при обучении программистов их нужно обязательно приучать к тому, зачем нужен их код, и как он будет использоваться.
                +1
                что находится за пределами его зоны ответственности, так и будет всю жизнь писать код по спецификации сверху

                А что еще программист должен делать? Или вы про карьеру до генерального директора собственного стартапа?
                  +1
                  Ну Вы так говорите, как будто задача программиста — это только писать код. Вот тут в конце поста есть ссылка с примерным списком компетенций, предъявляемых к профессии «программист».
                    0
                    Программист прежде всего должен понять спецификацию, а иногда задать уточняющие вопросы. А затем написать хороший код и в нужные сроки. А иначе он не программист, а кодировщик.
                +3
                Как писал Котлер, «Человек, который покупает у вас перфоратор — на самом деле покупает не перфоратор, а дырку в стене в нужном для него месте и в удобное для него время».

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

                Можно написать идеальную и никому не нужную программу программу.

                Сегодняшние реалии таковы, что большинство существующих потребностей так или иначе удовлетворены и маркетологи выпрыгивают из штанов, чтобы придумать новые потребности и удовлетворить их. Ведь если разобраться, никаких особых преимуществ и 6 айфона ни перед 5 ни перед 4 нет. И речь не только про эппл. «Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место нужно бежать вдвое быстрее.» Поэтому трата огромного количества ресурсов, человеческого труда и т.д. по сути спускаются в унитаз ради сохранения статус-кво, как бы это обидно не звучало.
                  +3
                  Дырку в стене можно просверлить любым перфоратором, однако их продается over дофига моделей и каждая находит покупателя.

                  Ну так давайте представим воображаемый мир, где можно купить дырок в стене. Человек стоит перед выбором — купить набор дырок (по аналогии, например, с винтами разных размером и диаметров) и устанавливать их в стены при необходимости, или купить инструмент, который надо будет таскать за собой и использовать каждый раз, когда возникнет потребность в дырке. И что он выберет, зависит от того, какую свою проблему он хочет решить. Если ему нравится строительство, он, конечно, купит перфоратор, но просто потому, что не «получить удовлетворение от строительства» в магазине не продается.

                  Смысл цитаты был в том, что никто никогда не покупает что-то ради самой вещи, вещи выбирают, чтобы минимизировать усилия и ресурсы для достижения какого-то результата. Тот же айфон 6 покупается не для того, чтобы получить какую-то дополнительную функциональность, это уже давно элемент имиджа и статусности. Перефразируя цитату, «если бы человек мог напрямую купить +100 понтов, он бы напрямую купил понты и не покупал у вас айфон». Так что айфон — такой же инструмент для достижения цели, как и все остальное. В эту же категорию попадают и другие вещи, которые покупают просто потому, что могут.
                    +1
                    Ну так давайте представим воображаемый мир, где можно купить дырок в стене.

                    Зачем представлять что-то воображаемое? Это наш мир. Дырки в стене вполне себе продаются, спуститесь к доске объявлений у своего подъезда или возьмите любую газетенку бесплатную у метро или в почтовом ящике (если к вам в подъезд ходят разносчики бумажного спама). Искать ключевые слова «муж на час». Однако перфораторы все еще продаются, причем, обычным гражданам, профессионально строительством не занимающимся.

                    Тот же айфон 6 покупается не для того, чтобы получить какую-то дополнительную функциональность, это уже давно элемент имиджа и статусности.

                    Я именно об этом речь и веду. Создана новая потребность. Бедным и нищим людям (только не обижайтесь на формулировку, это не с целью кого-то оскорбить, я сам себя к бедным отношу) внушили, что у них тоже может быть «элемент статусности», пусть и жрать, порой, нечего. Хотя, как может быть «элементом статусности» массовый продукт стоимостью в $1000 я решительно не понимаю. Элемент статусности — это подлинник Дали или тот же айфон, но в бриллиантах или часы, выпущенные ограниченной серией в 1000 экземплярах и т.д., т.е. нечто «эксклюзивное» и недоступное большинству, но никак не ширпотреб.
                    Сам по себе смартфон — очень удобная и полезная штука, которая решает реальные потребности… 20% владельцев. А 80% владельцев спустили ресурсы в унитаз (и используют только звонки и смс), т.к. это «стильно, модно, молодежно». Об этом я и пишу.
                      0
                      По вашему, каждый раз, когда мне нужна отвёртка или дрель или молоток, я должен куда-то там звонить, впадать в зависимость от какого-то человека, который неизвестно когда придёт, неизвестно как сделает и каждый раз это будет рандомный уровень
                      если же я купил себе инструмент, я ни от кого не завишу ни в плане времени, ни в плане качества, плюс я сам со своей же работы набираю экспы и каждый следующий раз делаю правильнее, что может быть выгоднее этого?
                        0
                        Ну, т.е. вам тоже не только дырка нужна, как нас тут уверяли ранее?
                          +2
                          Нет, именно что
                          дырку в стене в нужном для него месте и в удобное для него время

                          Ключевое слово здесь не только дырка, а еще и в удобное время и в нужном месте. Еще можно дописать — с минимальным повреждением окружающего.
                          Сегодня мне нужно дырку дома, завтра на работе, послезавтра на даче, а в воскресенье в гараже.
                          Способов получить всё это бысто и с нужным качеством исполнения, не покупая дрель или перфоратор, я не знаю.
                            0
                            ну так а если бы дырки продавались в магазине на вес, переносились в обычном кармане и «вставлялись» в стену как-то очень просто, например, приклеиванием, Вы бы покупали именно дырки, а не перфоратор, правда?
                              +1
                              Хлеб продается в любом магазине. Какой хочешь сегодня можно купить. А у меня дома хлебопечка.
                                0
                                Ну потому что Вы этот хлеб как-то так делаете, видимо, что в магазине такой не продают. Вы предлагаете каждому писать софт под себя? :) Мы именно про софт говорили изначально.
                                  +2
                                  Ну потому что Вы этот хлеб как-то так делаете, видимо, что в магазине такой не продают.

                                  Продают. У меня гипермаркет с пекарней в 250 метрах от дома, он работает c 8 утра до 2 ночи. Проблемы купить какой угодно хлеб у меня нет. Но я хочу хлебопечку, а вы мне с Котлером усиленно пытаетесь хлеб продать.

                                  Вы предлагаете каждому писать софт под себя?

                                  Нет, я лишь сказал, что вы процитировали ерунду.
                                    –1
                                    Но я хочу хлебопечку, а вы мне с Котлером усиленно пытаетесь хлеб продать.

                                    Так Вы можете внятно сказать, зачем Вам хлебопечка? Она хлеб печет вкуснее или просто потому что хочу/люблю делать сам?
                                      0
                                      Так Вы можете внятно сказать, зачем Вам хлебопечка?

                                      Вот видите, вы даже не понимаете моих потребностей, но уже утверждаете, что знаете, как их удовлетворить. Но, на самом деле, это неважно. Важны 3 вещи:
                                      1. Я могу купить вкусный, устраивающий меня хлеб рядом с домом в любое время, когда я активен.
                                      2. В магазин сходить 15 минут, печка печет 2-4 часа, у меня нет проблем со здоровьем, мешающих мне передвигаться по городу.
                                      3. Я купил хлебопечку и пользуюсь ей, последний раз хлеб в магазине домой покупал 2 года назад.

                                      Отсюда легко можно сделать вывод, что покупая хлебопечку я покупал не (только) хлеб и ваш Котлер не прав. Sapienti sat.

                                      И самая большая беда, для меня, например, в том, что маркетологи этой ерундой засрали мозги производителям. Вместо хлебопечки они продают хлеб и найти печку с возможностью программирования ее как тебе нужно, а не как решил маркетолог, нереально. Либо ешь, что дают, либо сделай сам. Поэтому в сети полно рецептов типа: «для того чтобы сделать этот кекс, выберите программу для дефлопе, т.к. программа для кекса вам не подойдет». Поэтому в айфонах нет слотов для карт памяти, ешь, что дают, маркетолог подумал за тебя и решил, что тебе это не нужно. Ну и т.д.
                                        –1
                                        Отсюда легко можно сделать вывод, что покупая хлебопечку я покупал не (только) хлеб и ваш Котлер не прав.

                                        Вы так и не ответили на вопрос, который процитировали.
                                          0
                                          Ответил:
                                          это неважно [в контексте обсуждаемой проблемы]

                                            +1
                                            Понятно. Я думаю, стоит закрыть дискуссию :)
                                          0
                                          Стоимость хлеба получается как в магазине, или сильно дешевле? Какой период окупаемости хлебопечки?
                                            0
                                            Имхо некорректный вопрос т.к. рецептура изделия разная, в этом плюс хлебопечки — хлеб по индивидуальным пожеланиям.

                                            А дешевле не выйдет — хлебозавод это опт и субсидирование государством некоторых видов хлеба.
                                              +1
                                              Суть моих вопросов в том была, что хлеб — это лишь один из продуктов работы хлебопечки. Их целая куча: например, удовольствие от сделанного своими руками, независимость от супермаркета, индивидуальные предпочтения в сортах, коммерческая выгода, да или просто, простите, понты. И печку покупают, чтобы удовлетворить одну или несколько из этих целей, а не как «вещь в себе».
                                                –1
                                                Чего же вы на пол пути останавливаетесь? Ведь в конечном итоге все это лишь для того, чтобы покормить червей и стать удобрением :)

                                                И печку покупают, чтобы удовлетворить одну или несколько из этих целей, а не как «вещь в себе».

                                                Что такое «вещь в себе»? Приведите пример. Что покупают как вещь в себе?
                                                  +1
                                                  Да какой смысл? Вы мне про одно, я Вам про другое.
                                              0
                                              Я как-то не интересовался этим вопросом, стоимость меня меньше всего волновала.
                                              Самй простой хлеб, это 500г муки, столовая ложка сахара, столовая ложка масла подсолнечного, чайная ложка соли и пакетик дрожжей. Вода бесплатная. Несмотря на простоту рецепта, получается очень вкусно. Стоимость продуктов можете прикинуть сами. Электроэнергии съест примерно 1 кВт⋅ч за выпечку.

                                              Ну и печка, это не только ценный мех хлеб, но и всякие куличи, кексы, тесто и даже варенье.
                                                +1
                                                А сейчас ответ будет и на тот случай, если это в буквальном смысле было сказано, и на тот, елси это метафора.

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

                                                Хлеб при этом получается такой, как задумал хлебопёк. Условно говоря, в нём не будет лишних консервантов, усилителей вкуса, ногтей пекаря, мышиных фекалий. Да, в обычном хлебе тоже нет усилителей вкуса (дорого), ногтей пекаря (ну, во всяком случае, мне никогда не попадались, хотя такие страшилки я слышал) или тем более мышиных фекалий. Если надо, это будет безглютеновый хлеб из нутовой муки, если надо — это будет французский круассан, или сырный хлеб, или бог знает что ещё.

                                                Хлебопечка — это возможность выбора (и подгонки под свои требования) без грандиозных затрат по времени и сложной кривой обучения.
                                    +1
                                    Вы занимаетесь схоластикой, как и упомянутый выше Котлер. Способов сделать дырку я вам уже привел. Тот же перфоратор можно одолжить у товарища или взять в аренду. Однако их покупают. И, что самое главное, покупают 100500 разных моделей и спорят, какой лучше. А дырку можно любым просверлить.

                                    Можно продолжить и выяснить, что деньги, в общем-то, тоже никому не нужны. Всем нужны товары и услуги, которые на них можно купить. Аналогично с сексом, для удовольствия монтируем электрод в мозг, а для продолжения рода используем ЭКО. Ну и т.д.
                                      +1
                                      Можно продолжить и выяснить, что деньги, в общем-то, тоже никому не нужны.

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

                                        Да, но, как говорят, дъявол в деталях. Знаете анекдот про то, что «теоретически мы миллионеры, а практически в семье...»?

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

                                        Я с этим не спорю. Я люшь отметил 2 вещи:
                                        1. Сегодняшние маркетологи сначала создают «проблему», а потом ее решают.
                                        2. Не нужно цитировать ерунду, даже если ее сказал известный человек ;)
                                          0
                                          1. Сегодняшние маркетологи сначала создают «проблему», а потом ее решают.

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

                                          2. Не нужно цитировать ерунду, даже если ее сказал известный человек

                                          Вы, видимо, совсем не поняли, что он сказал.
                                            0
                                            Меня? Вы, видимо, совсем не поняли, что я до вас пытаюсь донести.
                                              0
                                              Не понял, да. Я говорил про то, что софт никогда не покупают просто так, а только чтобы решить какую-то свою задачу, которую без этого софта либо решать слишком долго, либо не решить вообще. А Вы мне про то, что люди покупают хлебопечки. Покупают, да, тоже чтобы решить какую-то задачу. Где я не прав?
                                                0
                                                Не правы вы в том, что вместе с Котлером всегда предлагаете продавать результат (дырку). А я вам тут пытаюсь втолковать, что иногда людям нужен инструмент (перфоратор).
                                                  +1
                                                  Зачем людям инструмент, если не для решения задач? Причем необязательно тех, для которых инструмент задумывался. К слову, коллекционирование перфораторов — тоже вполне себе задача, которую купленный перфоратор успешно решает.
                                                    +1
                                                    Решает, но он не был для этого предназначен производителем. Это проблема, которая есть у потребителя и о которой производитель ничего не знает.
                                                    Если бы продавались дырки, а не перфоратор, то коллекционер перфораторов был бы в пролете, потому что производитель банально не знает, что перфораторы коллекционируют и что они нужны людям не только для дырок.
                          0
                          О да, это ещё одна из сложностей программиста — быть психологом и провидцем, чтобы угадать, какие интерфейсы придутся его пользователям по вкусу.
                          +37
                          Извините, я увидел в картинке нечто иное:
                            +3
                            А до вашего комментария я был уверен в том, что это действительно динозавр, смотрящий в монитор!
                            Как только увидел вашу картинку, решил пересмотреть оригинальную, и тут-то я удивился.
                              +3
                              Динозавр? Я открыв статью, там пса в очках увидел…
                                +1
                                Я тоже увидел динозавра, но сначала постеснялся писать о своих ложноположительных багах в разпознавалке образов…
                                  +2
                                  Это всё леопардовый диван виноват
                                +16
                                черт, вы мне сломали восприятие
                                +35
                                Что немцу хорошо, то русскому — смерть. Это мое мнение по содержанию перевода.

                                В современных условиях я советую 4 принципа работы программистом в РФ

                                • Будь всегда администратором репозитория — иначе потеряешь работу
                                • Пиши так, чтобы читать код мог только ты — иначе потеряешь работу
                                • Оставляй всегда пару косяков — иначе потеряешь работу
                                • Минимальная единица планирования — неделя — иначе потеряешь работу


                                Перевожу последний пункт на язык попроще —

                                Никогда не говори
                                Тут работы на два часа


                                Все советы — для проектов, не нужных будущему. А таких — 90 процентов.

                                И самое главное.

                                Я программирую, потому что программирую
                                Портос

                                  +3
                                  Отличный саркастический коммент, жаль, что заминусовали :)
                                  Но, пожалуйста, поясните пункт насчёт репозитория.
                                    0
                                    Я так полагаю, чтобы пресекать попытки присваивания другими твоих заслуг.
                                      +7
                                      Нет, просто тебе еженедельном митинге будут ставить задачу — открыть доступ к репе для следующих персоналий. А это плановая задача. Смотри пункт 4.)
                                      +4
                                      Вот вы смеётесь, но особенности ведения бизнеса в России никуда не поменялись и от них не сбежишь, будь ты хоть трижды системный архитектор или разработчик глубокого бэкенда. У нас вот в прошлом году проект отжали, вместе с контрактами и доступом к боевым серверам. У заказчика поменялась власть, готовый проект передали своим подрядчикам на поддержку — политика… (Дорабатывать? Зачем дорабатывать? Это ж трудиться надо… И что, что баги и фич не хватает?) Единственное, что у нас осталось — репозитории с исходным кодом. Потому что они были у нас :-)
                                      +15
                                      — Пиши так, чтобы читать код мог только ты
                                      — Оставляй всегда пару косяков
                                      — Минимальная единица планирования — неделя

                                      Вот слова не мальчика, но мужа.
                                        +1
                                        Пиши так, чтобы читать код мог только ты

                                        Одна из причин, почему я стараюсь использовать Haskell.
                                        +5
                                        Программирование стало сложным сразу после того, как во главу угла были поставлены интересы серости. Пока программа вычисляла параметры ядерной реакции — программирование было удовлетворительно легким. Но с момента, когда результаты стало необходимо представлять в 32-битном 3D-изображении в реальном времени — программисты стали быстро седеть (некоторые — толстеть), потому что программы стали обрастать огромным наслоением «лишнего», тербующего постоянного обновления, поддержки, рефакторинга и т.п.
                                        Содержание подменяется оболочкой. Посмотрите на статьи на хабре — почти все они многие из них посвящены новым интерфейсам с пользователем: все эти кнопочки, иконочки, картиночки и т.п. рендеринги. Я не отрицаю, что есть области, где визуальный и звуковой интерфейс имеет первостепенную важность, но не все же аспекты деятельности человека!
                                        Конечно, когда вместо химической формулы, понятной только химику, программа выдает 3D изображение молекулы — это существенно усложняет жизнь программисту, но никак не облегчает жизнь химику и тем более не делает результат понятнее для профана. Зато картинка производит впечатление на инвесторов, менеджеров, покупателей и просто зевак (создающих сайтам ТИЦ, PR и другие «лайки») — соответственно возникают требования сделать в следующий раз «еще красивее, еще нагляднее, еще удобнее»… А это влечет разработку новых «инструментов»… и круг замыкается.
                                        Сегодня я вообще не понимаю, как можно стать программистом — даже если понимать под «стать» всего-навсего изучение какого-либо языка с наиболее популярным фреймворком для него, то к моменту завершения изучения появляется новая версия языка и две или три версии фрейморка…
                                        По-моему, необходимость обеспечить всех возможностью зарабатывать «легкие» деньги увела технологию программирования из предметной области в развлекательно-бесполезную, хотя это мало кем признается.
                                          +1
                                          А что Вы понимаете под «легким»? Я бы не сказал, что программирование для вычисления параметров ядерной реакции было простым и доступным. Чтобы получить результат обсчета, нужно было написать дифур, запрограммировать его, а потом долго разбираться, где ошибка, в уравнении, коде или железе. Почитайте Turing's Cathedral, например, там это все в деталях описывается. Сейчас это сделает на матлабе любой студент-первокурсник, несоизмеримо быстрее и качественнее.

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

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

                                          Эм, нет. Пролистайте, например, вот это. Не идеальный документ, но там кроме собственно написания кода к программисту предъявляется еще десятка два компетенций.
                                            +1
                                            Под легким я понимаю ровно то, о чем писал автор заметки — сопровождение, поддержка, улучшение и т.п.
                                            Задача, решенная сегодня современными средствами никогда не может перейти в разряд «законченный продукт» — программа вынуждена непрерывно изменяться/обновляться, т.к. постоянно и непрерывно изменяются второстепенные (по отношению к задаче, решаемой программой) требования — глубина цвета, DPI дисплея, новые стандарты интерфейса и т.п.
                                            Поэтому программист никогда не сможет сказать «я завершил работу над программой», даже если сама по себе задача действительно решена и удовлетворяет заказчика.
                                              +1
                                              Под легким я понимаю ровно то, о чем писал автор заметки — сопровождение, поддержка, улучшение и т.п.

                                              Так ну вот я Вам описал схематично, как происходила разработка и поддержка обсчета сложных математических задач. Вы всерьез считаете, что это проще, чем посидеть и переверстать GUI под новый экран или сделать отображение каких-нибудь свистелок в 3D?

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

                                              А это не программисту решать. Работа над программой (видимо, все же «продуктом» в данном случае) будет завершена, когда slakeholder'ы (как это сказать по-русски?) решат, что она удовлетворяет основным бизнес-целям и требованиям. Ну а как они эти бизнес-цели определят, это уже другой вопрос.
                                                +1
                                                Я не говорю проще или нет! Я говорю о том, что с каждым днем обязанностей, которые де-факто никому не нужны, все больше и больше — та же самая «переверстка GUI» — на примере MS Word кому конкретно в жизни помогла создавать тексты лучше, качественнее или производительнее? А ведь для того, чтобы MS Word получил «ленту» вместо «меню» пришлось трудиться огромной куче программистов, которые так и продолжают получать зарплату, непрерывно устраняя баги в этой ленте. (Лента — это образно, но аналогичных примеров полно и без нее).
                                                Современное программирование стало трудным потому, что доля бессмысленного труда в нем постоянно растет. Лично меня бессмысленный труд всегда утомляет больше осмысленного, не знаю, как других…
                                                  0
                                                  Как раз суть программиста в постоянном изучении нового и применения этого на практике. Программирование — это творчество, что подразумевает изучение нового. Вы же путаете программиста с ремесленником (например, плиточник, у которого десятилетия не меняется принцип работы и инструменты). Безусловно и в программировании можно найти сферы, где работает принцип ремесленничества, где не нужно изучать что-то новое, например, программирование каких-нибудь аппаратных контроллеров. Вот в такую сферу вам надо уйти, если изучение нового доставляет вам проблемы.
                                                  Еще у меня возникло ощущение, что вы против новых идей в интерфейсах. Безусловно не все они удачны и удобны, но без этого мы бы все до сих пор сидели в командной строке.
                                                    +1
                                                    не нужно изучать что-то новое, например, программирование каких-нибудь аппаратных контроллеров

                                                    Позвольте с Вами не согласиться. В embedded разработке тоже происходят изменения, контроллеры снимаются с производства, появляются новые, более мощные и дешевые. Также меняются средства разработки и отладки, даже в рамках одного производителя контроллеров. Может и ассемблер поменяться, хотя и не радикально. Конечно, эти изменения происходят реже чем в других областях разработки ПО, но они происходят и в последнее время эти изменения случаются все чаще. Так что совсем откосить от изучения чего то нового и при этом быть востребованным не получится. Да и вообще хороший профи в любой области должен учиться постоянно.
                                                      0
                                                      Согласен. Просто в этой сфере всё-таки реже происходят изменения. Просто не пришло в голову другой такой сферы, где изменения очень редки. Хотя, может быть на каком-нибудь заводе, где применяются станки с ЧПУ, можно найти такую работу. Стоимость таких станков очень большая, поэтому их там часто используют десятилетия без изменений. Вот и пожалуйста, работа где новые знания не потребуются очень долго.
                                                      0
                                                      С каких пор творчество стало изучением нового? Оно всегда было созданием нового!
                                                        0
                                                        Я говорил, что программирование это творчество. И не применяя какие-то новые подходы, создать что-то принципиально новое не получится. Также художник, когда рисует картины, он совершенствуется, открывает для себя какие-то новые техники рисования и т.д. Абсолютно схожие процессы происходят при программировании. Если вы 10 лет программировали один и тот же микроконтроллер, то это уже перестает быть творчеством. Поэтому неизбежно изучение новых библиотек, новых подходов, новых паттернов, чтобы не стоять на месте и продолжать совершенствоваться.
                                                          0
                                                          Новое можно делать и старыми подходами. Возможно, от этого оно будет менее востребовано, но не факт. Учиться — хорошо, но творчество — не это.
                                                      0
                                                      Мне помогла. В старом Ворде чёрт ногу сломит, в новом уже можно работать. Гораздо быстрее и приятнее.
                                                      При выборе между просто функциональной програмой и функциональной да ещё и красивой, я выберу красивую. Современный софт должен быть удобным, понятным, отзывчивым и приятным на вид. Это всё — юзабилити.

                                                      P. S. 5 лет работаю за деньги, с бессмысленным трудом не сталкивался. Приведите пример.
                                                  0
                                                  Извиняюсь, что не в одном посте все сказал…
                                                  К аналогии автопоилки — если бы автопоилка в коровнике создавалась на тех же принципах, что и современные программы, она имела бы 946 кнопок с иконками в 64-битном цвете, каждое действие доярки сопровождала бы 7-канальным звуком, при этом все шланги были бы «приятного глазу коровы цвета», а о наполнении подойинка отправляла сообщение в фейсбук. И тогда я сказал бы «автопоилка бессмысленно сложная» — когда доили руками, было лучше.
                                                  Это немного не то, что сказали вы…
                                                    +2
                                                    Так если Вы хотите сказать, что в настоящее время создаются продукты, подверженные creeping featurism, так я всецело согласен. Вот только это вряд ли вина программистов, это вопросы к маркетологам, аналитикам, менеджерам и прочим людям, которые собирают, анализируют и формулируют требования к разрабатываемому софту. Именно поэтому я вон выше и предлагал при обучении программистов заставлять их задумываться о том, как их поделки будут использоваться дальше, а не просто кодировать то, что было сказано.
                                                      0
                                                      Вот только это вряд ли вина программистов, это вопросы к маркетологам, аналитикам, менеджерам и прочим людям, которые собирают, анализируют и формулируют требования к разрабатываемому софту.А кто обвиняет программистов?!
                                                      Я говорю лишь о том, что их труд стал более сложным — статья-то ведь об этом!
                                                      А уж кого за это благодарить… Я назвал это «обслуживанием интересов серости». Извините, умных слов мало знаю, больше привык русскими простыми обходиться…
                                                        +3
                                                        Их труд просто стал немного другим. И для других задач требуются другие люди с другими навыками. Никто же не заставляет хардкорного линукс-кернел программиста формочки верстать. А если заставляют, ему несложно найти другое место, где будут ценить его навыки. Низкоуровневое программирование встроенных устройств, системное программирование, математические расчеты и все остальные «элитные» задачи то никуда не делись и не денутся никогда.
                                                          –1
                                                          Я пытаюсь говорить по теме статьи. При чем тут то, что говорите Вы? Это верно, но к теме статье отношения не имеет.
                                                          Кернельщик в конечном итоге так же будет вынужден обслуживать запросы верхнеуровневщика, т.к. из-за бессмысленного GUI требования к ресурсам ядра могут кардинально измениться… но это так же не имеет отношения к теме.
                                                            +2
                                                            Так Вы говорите — программирование нынче уже не то, теперь все формочки рисуют и кнопочки перекрашивают. А я Вам говорю, что тот хардкор, про который Вы писали с уважением, точно так же востребован, как и 50 лет назад. И учить таких специалистов тоже нужно.
                                                              +1
                                                              Уважаемый, я говорю о том, почему программирование стало сложным — статью-то Вы прочли? Там сказано о тяготах программиста. Так вот, я продолжаю о тяготах: их усугубляет то, о чем я ранее уже сказал, а именно «обслуживание интересов серости».
                                                                +1
                                                                Так я и говорю, что я знаю очень многих людей, которых не затрагивает «обслуживание интересов серости». Сидят тихо мирно пишут драйвера или алгоритмы обработки видео. Для них что изменилось?
                                                                  0
                                                                  Ок, Вы и минусы меня убедили: автор заметки не прав, жизнь программистов была и остается безмятежно легкой.
                                                                  Признаю свою ошибку, виноват, исправлюсь.
                                                    +1
                                                    Небольшая ремарка о матлабе. С интервалом в пару лет два доцента (один математик, другой физик) независимо сказали мне, что в матлабе есть баги, результат вычислений вызвал у них подозрения и они проверяли вычисления (один своей программой, другой изменив способ вычисления). Т.е. кроме умения пользоваться языком программирование или инструментом как матлаб, надо обладать знаниями чтобы понять результат.

                                                    Что-то вроде рассказа Роберта Шекли «Верный вопрос»:
                                                    Один на планете — не большой и не малой, а как раз подходящего размера — ждал ответчик. Он не может помочь тем, кто приходит к нему, ибо даже Ответчик не всесилен.
                                                    Вселенная? Жизнь? Смерть? Багрянец? Восемнадцать?
                                                    Частные Истины, полуистины, крохи великого вопроса.
                                                    И бормочет Ответчик вопросы сам себе, верные вопросы, которые никто не может понять.
                                                    И как их понять?
                                                    Чтобы правильно задать вопрос, нужно знать большую часть ответа.
                                                    0
                                                    А вот мне нравится визуализировать данные, и поэтому для меня хорошо, что это кому-то нужно :-)
                                                    +14
                                                    Для меня самое сложное в разработке это не собственно программирование, а оценка сроков.
                                                    Потому что программерскую задачу я могу осилить изучив матчасть, изучив новую технологию, посидев пару дней в дебаггере или просто в конце концов сказав, что проблема не решаемая.
                                                    Почему-то об оценке сроков никогда не говорят, когда обучают программированию. Когда я вышел на свою первую работу, для меня это стало неприятным сюрпризом. Я как-то никогда не задумывался об этом ранее, программировал в свое удовольствие. За годы работы я так и не смог выработать какой-то рациональный подход к этому, и как бы я не старался, называю сроки с потолка и надеясь только на свою интуицию.
                                                      +4
                                                      Ну и не переживай по этому поводу. На сомом деле оценить сроки в задаче, которую никогда не делал никто не может. Я так и говорю менеджеру, что сроки оценить не могу. Он конечно удивляется, но это уже его проблемы ;)
                                                        0
                                                        Почему-то об оценке сроков никогда не говорят, когда обучают программированию.

                                                        Ну потому что пошла дурная традиция считать, что задача программиста только в том, чтобы программировать. А если заменить «программиста», на «разработчика ПО», тогда сразу начинают казаться актуальными и курсы по работе с требованиями, основам управления проектами, тайм-менеджменту, и все остальные полезные штуки. Вот только где найти хороших преподавателей с такими навыками в ПТУ или каком-нибудь аграрном университете, кои сейчас массово «готовят» «программистов».
                                                          0
                                                          На днях в ФБ реклама онлайн курсов по обретению профессии программиста попадалась.
                                                          0
                                                          Оценку сроков легко сделать, если ты полностью контролируешь проект. А часто происходит, что приходится подстраиваться под реалии о которых никогда не задумывался. Задача с которой ты справляешься за пару часов при интеграции вдруг занимает пару дней. Хотя у меня самая большая проблема сесть и программировать, что нужно, а не то что ты хочешь.
                                                            0
                                                            А часто происходит, что приходится подстраиваться под реалии о которых никогда не задумывался.

                                                            Недостаток опыта решения подобных задач/планирования/оценки рисков? Ну и традиционный программистский оптимизм, видимо :)
                                                            0
                                                            По своему опыту могу предложить такой вариант оценки сроков:
                                                            — Полностью разбираем ТЗ и задаем все, даже глупые (если будут), вопросы заказчику.
                                                            — Разбиваем большие задачи на много мелких подзадач (чем подробнее декомпозиция тем лучше, но без фанатизма).
                                                            — Оцениваем каждую мелкую подзадачу по времени (при оценке мелких задач трудно пролететь по времени).
                                                            — Собираем общее время по всем задачам.
                                                            — Добавляем время на тестирование.
                                                            — Добавляем риски. Тут как раз учитывается необходимость изучения матчасти, новых технологий и прочее. У меня запас колеблется в пределах 10-25% в зависимости от проблематики задачи.
                                                            — Складываем все, что получилось (оценочное время, тестирование и риски) и получаем человеко-часы на решение задачи. От них уже определяем срок разработки.

                                                            С практикой, оценки будут становиться только точнее. То что мы посчитали может лечь и в политику ценообразования.
                                                              0
                                                              От них уже определяем срок разработки.

                                                              сумма всех этих часов == срок разработки?
                                                                +1
                                                                Срок разработки = сумма часовмагическая константа / sqrt(количество разработчиков),

                                                                Магическая константа выбирается от полутора до пяти.
                                                                  0
                                                                  Нет, не совсем.

                                                                  К примеру у нас получилось 100 человеко-часов. У нас два программиста, которые работают по 5 часов в день над этим проектом.

                                                                  Тогда срок разработки: 100 / (2 * 5) = 10 рабочих дней.
                                                                  Человеко_Часы / Время_закрываемое_работниками_в_день.

                                                                    +4
                                                                    И что, правда так работает? Я бы еще на 2-3 умножил. Или вот как г-н rusec ниже предложил, но с его подходом есть неслабый шанс получить за такие оценки в бубен от начальства.
                                                                      +1
                                                                      Да работает. Из моей практики факт с планом расходится в пределах 5%, что я считаю очень хорошим показателем.

                                                                      К тому же тут есть второй момент — продажа.

                                                                      Эти расчеты показывают минимально допустимый срок и стоимость проекта (при принятом уровне рентабельности).

                                                                      Если можешь продать заказчику этот проект в два раза дороже и в два раза дольше — то почему бы и не продать.

                                                                      К тому же если клиент начнет продавливать на скидки, то ты всегда будешь знать границу, ниже которой от проекта надо отказываться.
                                                                        0
                                                                        Могу предположить, что эти оценки Вы делаете для фиксированной команды и для более-менее похожих проектов. Угадал? Ну либо Вы реально гений планирования, что в риски закладываете 10-25%, и у Вас все сходится. В таком случае «респект и уважуха», как говорится. Но мне все же кажется, что тут без особых условий не обошлось. Уж слишком красиво получается. :)
                                                                          0
                                                                          Ну команда у нас действительно слаженная, уже более трех лет работаем в неизменном составе.
                                                                          Основная направленность это доработка и сопровождение готовых проектов (от магазинов до CRM систем).

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

                                                                          В целом надо признать, что тут важна постоянная практика. Два года назад, когда только внедряли такой подход расчета проектов, о 5% погрешности приходилось только мечтать.

                                                                          Один раз я пролетел примерно в два раза, благо что продали дороже — в минус не ушли.
                                                                            0
                                                                            Ясно, спасибо.
                                                                          0
                                                                          А, вот что еще меня смущает — в плане у вас нет никаких накладных расходов на интеграцию задач. Уж если строить классическое дерево декомпозиции, то в узлах его тоже работы небесплатные, причем довольно сильно. Ну и, я так понимаю, проекты у Вас не больше десятка человеколет и требования к ним у Вас не меняются по ходу выполнения. Верно?
                                                                            0
                                                                            Да проекты в основном связаны с доработкой. Самый большой проект был примерно на 6 человеко-лет в сумме по всем задачам.

                                                                            Интеграцию задач мы рассматриваем как отдельную задачу.
                                                                        +1
                                                                        А девять матерей у вас за месяц ребенка рождают?
                                                                      +4
                                                                      Полученное время умножаем на полтора и заменяем единицы измерения на следующие.

                                                                      4 часа => 6 дней
                                                                      2 дня => 3 недели

                                                                      Тогда есть шанс.
                                                                        0
                                                                        Это если задачи вроде монотонно ложить кирпичи в стену.
                                                                        А по-хорошему, нужно строить сетевой график выполнения задач. Ведь многие из них зависимы друг от друга и одна задача не может быть начата пока не выполнятся другие, потому же определить критический путь по графу и определять сроки.
                                                                        Но… и тут засада, некоторые задачи ведь можно определить точнее а у других будет большой разброс по времени — эти рамки надо определять для каждой задачи в отдельности, там же и закладывать все возможные коэффициенты а время по критическому пути графа уже брать как есть.
                                                                        В процессе выполнения задачи сетевой граф надо актуализировать, чтобы было понятно где еще время терпит а где надо бы ускорится. Ибо просто выполнять все задачи как можно быстрее — непродуктивно. Критичные по времени исполнения — только задачи на критическом пути, но может так статься что из-за задержки какой-то некритичной задачи сам критический путь внезапно поменяется.
                                                                          0
                                                                          Соглашусь с вами только отчасти.

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

                                                                          Для оценки сроков выполнения задачи, если вы работаете один, то тоже не суть важна зависимость между подзадачами.

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

                                                                          По терминологии (чтобы лучше понимать друг друга):
                                                                          Под временем выполнения задачи — я понимаю как раз ее трудоемкость.
                                                                          Под сроком выполнения задачи — период времени от начала разработки до реализации (запуска).
                                                                            0
                                                                            Так мы вон выше разобрались, что у человека более-менее отлаженные проекты и хорошо сработанная команда. Это позволяет со временем добиться очень точных оценок даже при таком упрощенном подходе.
                                                                              +1
                                                                              не ускориться, а перераспределить задачи. Ведь считается, что никто не тормозит просто так, что ему скажешь ускорься и он сразу вдруг всё сделает.
                                                                                0
                                                                                Очень часто бывает что человеку нужен пинок для ускорения, теряет ориентиры скорости.
                                                                              0
                                                                              А что скажете на счет сроков ответа на вопрос о сроках в такой ситуации? И как задача изучения новых технологий и матчасти попала в риски?
                                                                                0
                                                                                Новые технологии и платформы попадают в риски по одно простой причине — не зная их вы не сможете дать адекватную оценку сроков реализации задачи в рамках этих систем. Поэтому оценка ведется на основе статистики ранее освоенных платформ, плюс закладываются повышенные риски.

                                                                                Особенно это актуально для самописных систем.
                                                                            +2
                                                                            с консультантом по компьютерам, который разрабатывает веб-приложения

                                                                            Консультант по компьютерам! Охренеть просто!
                                                                              +1
                                                                              Программировать легко. Тяжело потом исправлять ошибки.
                                                                                0
                                                                                image
                                                                                  +1
                                                                                  Программирование — это автоматизация. Мало заставить автомат делать то, что нужно. Он автомат. Он не знает, что нужно вам, он вместо этого автоматически исполняет вложенную последовательность действий, а самому ему глубоко наплевать на то, что нужно нам.
                                                                                  И поэтому важно научить автомат ещё и не делать того, что он не должен. Отсюда — обработка исключений, фильтрация пользовательского ввода, вообще — уязвимости. Автомату всё равно. И вот это понять не так-то просто. Мне, по крайней мере, время потребовалось.
                                                                                  Программирование — это поэзия. Да! Поэзия математики. Поэтому мало просто заставить автомат работать именно так, как нужно. Нужно быть поэтом, внутри, чтобы программа работала для людей, на людей, ради облегчения жизни; нужно быть поэтом, чтобы написать понятную программу, ото взгляда на которую у коллеги не появится рвотный рефлекс; чтобы написать такую программу, которую было бы легко и приятно поддерживать.
                                                                                  В конечном счёте, программирование — образ мысли, образ жизни. Мало даже быть поэтом и уметь заставить автомат работать на тебя. Чтобы сделать что-то настоящее, долгоживущее (Windows XP, Linux, C/C++, C#, многотомные труды Кнута, «Совершенный код» и так далее...) нужно вот этим жить. Вот как-то так я думаю. Надеюсь, что не ошибаюсь.
                                                                                  Это сложно? Кому-то — да, сложно, а кому-то и нет, не сложно. Всё зависит от данных конкретных людей в данном конкретном месте и времени.

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