За что я люблю программирование

    Когда я был маленьким, я очень любил писать программы. Интерес был вызван, скорее, обидой. Почему это компьютер умнее меня? И игрой. Игрой, заставить его, компьютер, делать то что я хочу. Ты нажимаешь кнопку, а он говорит что не так, ты правишь ошибку, а он говорит что опять не так… И вот оно запустилось. А счастья нет. Ты начинаешь разбираться… искать… Ты чувствуешь себя строителем мира, так мне тогда казалось. Мне казалось что я создаю свою вселенную… Свой маленький мир…



    Со временем, количество ошибок уменьшается, и сводятся к «oops» и «typo» с разными не нормативными словами в истории scm вследствие того, что кто-то отвлек, или ты хотел спать. Разочаровался ли я в программирование? И да, и нет. Детские ошибки ушли. Программировать оказалось очень просто и очень скучно, действительно сложные и интересные задачи попадаются все реже и реже и это было незаметно ребенку, который чувствовал себя богом, который путается в клавишах и радуется, когда все запустилось. Но с возрастом и изменились проекты. Отлаживать pet project — хоть и не просто, но интересно. Правда нет ответственности. И нет ограничения по времени…

    То ли дело — работа. Проект, зависит от очень большого количества сторонних проектов, разной степени открытости и дружелюбности сообщества. Появляются баги в железе, компиляторах, окружении. Появляются пользователи, ответственность и первый миллион строк кода. Появляется непонимание как это работает… И появляются баги. И не просто баги, а баги в рамках. В рамках бюджетов и сроков. И появляется новая ответственность, ответственность потопить, вместе с собой, с своими багами, не только себя, но еще несколько человек. Может быть даже десятков. А если проект крупный — то и сотен. И большая часть из них твои друзья, ибо проводишь ты с ними весь осознанный день. Появляется риск, что люди окажутся на рынке труда, если ты не пофиксишь вот этот мерзкий баг, и еще те 5 штук до конца недели, а если пофиксишь — будут бонусы и роялти и обложки в журналах и слава и почет. А может и не будет. Риск большой, но и место для надежды есть.

    Каждый баг — это research. И чем больше проект, тем он занимательней. Я думаю, что не так много дипломов написано с таким же напряжением ума в вузах, честно, как попытки отловить баг, который воспроизводиться каждое первое воскресенье месяца на одной машине из десятка в кластере… Но самое важное в багах — это ценный духовный опыт, который большинство людей не получали ни разу в жизни — программист увидел свою ошибку. Признался в ней для себя, для окружающих… И исправил ее.

    Люди в большинстве своём живут с мыслью: «я ошибся только тогда, однажды, да и тогда, я подумал, что я неправ, в то время как на самом деле, я был прав!»

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

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

    Когда берешь новый баг, его в начале нет. Ты ищешь кусты, кусты в которых есть кролик. Тебе могут сказать что он тут есть. Или сказать в каких кустах на вашей полянке он есть. Ты находишь его. Ловишь. Даешь морковку. Он мягкий пушистый. Подходит человек и говорит что это не кролик никакой, это покрышка, которую соседские мальчишки выкинули в кусты. Что ты ему скажешь? Как на него посмотришь? А что почувствуешь, когда окажется, действительно, что это покрышка от велосипеда, и внутри лежит «съеденная» морковка, а нежная шерстка, это просто твои перчатки…

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

    Оригинал

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 314 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 116

      +5
      за это я и люблю программирование — иногда чувствуешь себя богом.
        +10
        Вот богом я перестал себя чувствовать еще в детсве. Сейчас остался просто ценный духовный опыт. К которому привык :(
          0
          Как будто сейчас нельзя создавать ничего нового…
            +3
            создавать новое конечно можно, вот только это получается как то гораздо быстрее. я, вот, уже в голове вырисовываю алгоритм решения той или иной программы еще даже не сев за компьютер, а когда уже сел, то просто код льется рекой и максимум что из ошибок тут допускается, как верно подметил автор, просто кто то отвлек или хочется спать, в общем по большей часи это синтаксические ошибки. В следствии всего этого потерялся тот детский интерес (
              +1
              Ты понимаешь меня ;)

              А я сейчас уже перешел грань, когда ты стараешься объяснить себе, что это не баг, и не ошибка, это космические лучи делают биты ломают… Старость?
                0
                Вы, наверное, не видите никакой идеи… Вам вдохновление надо… Найдите свою тему нишу, заболейте нею… И тогда Вас раздражать будет только то что почему же я не умею писать в 10 раз быстрее… :)
                  +1
                  Хм. А я считаю что лучшая программа, это та, которая не написана. И если можно сделать что-то не программируя, то стоит сделать это не программируя.
                    –1
                    Вручную? ;)
                    Слишком общими фразами бросаетесь, а без уточнений они ложны.
                      0
                      Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C”.

                      The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”

                      Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C”.

                      The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”

                      Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C”.

                      The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”

                      The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.

                      “And how many hours would you require to implement and debug that C program?” asked Nubi.

                      “Many”, admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him”.

                      “And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”

                      Upon hearing this, the programmer was enlightened.
                        0
                        А здесь кто-то говорил о С? о_О
                        Чем написание скриптов не программирование? Или, по-вашему, скрипт — это не программа, написанная на языке, доступном её интерпретатору?

                        Мало того, практически все скриптовые языки — полные по Тьюрингу.

                        Мне тут мерещатся следы какого-то глупого холивара на тему искусственного разделения «админов» и «программеров» с отдачей в ведомо первых писания скриптов, а вторых — писания на всяких «труЪ языках» вроде С.
                          +1
                          А мне кажеться, что вы ищете черную кошку в черной комнате.

                          Я хочу сказать ровно одно, что чем меньше ты пишешь программ, тем лучше. Лучшая программа, это не написаная программа, и если ты можешь сказать:

                          cat file | sort | uniq > file2

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

                          Основная идея поста, главного, была, что этот инструмент учит призновать свои ошибки. И в них, наверное, и есть духовная сила программирование. Она важна, не спорю. Но решить исходную задачу, важнее.
                            0
                            То есть, программирование действий интерпретатора коммандной строки вы за программирование не считаете? =)
                            cat file | sort | uniq > file2 — это, по вашему, не программа, написанная в одну строку? =)
                              0
                              Да, она использует просто вызов внешних исполняемых модулей с параметрами, но чем это отличается от вызова функций стандартных библиотек в С? ;)
                                0
                                А чем отличаеться программа от библиотеки? Тут ровно тоже и тут.
                                0
                                для меня в этом, намного больше программирования, чем в 100500 тысячах строк на Си. Ибо тут, ты программируешь (=решаешь задачу), не программируя (=не создавая не строчки кода).
                                  0
                                  По-моему, фразы вроде «программировать не программируя» — это просто запутывание в терминах и сродни <a href="«lurkmore.ru/Взаимоисключающие_параграфы»>кащенизму
                                  Не понимаю, почему строка команды не является строкой «кода».
                                    0
                                    Хм, я думаю вы просто не понимаете Дао, о котором я писал. Вот и все.
                                      0
                                      Я просто считаю, что даос-лайк фразы и выражения являются информативными не более, чем обычная мнемоническая запоминалка. Никакого смысла сами по себе — без дополнительных разъяснений — они не несут.
                    0
                    По-доброму завидую вам. Хотелось бы и мне так уметь. Интересно — да, но вот как получить эти знания…
                    +1
                    Создать новое и чувствовать себя богом — слишком разные вещи. Нет сейчас этой детской радости.
                      +2
                      Я старше на 9 лет. Регулярно испытываю приливы детской радости от изящно решённой программерской задачи :) Приливов божественности не было и в детстве, но радость примерно та же, хотя и несколько реже случается сейчас :)
                    –2
                    а было ли за что чувствовать себя богом в детстве? а за что чувствовать себя богом сейчас? Может стоит подвинуть планку повыше и таки бросить всё и допрыгнуть? А то слишком низкая планка не дает совести считать это достижением…
                      0
                      а не хочется себя чувствовать богом. Старый стал.
                        +2
                        так может это кризис среднего возраста и к программированию не имеет никакого отношения? :)
                          0
                          Про богом? Наверное.

                          А так, мысль основная текста была в силе бага для программиста.
                  +1
                  Вы как то выпускаете из виду результат.Меня очень радует пордукт который получается на выходе.Прикольно закончить большой долгий проект, подвести так сказать черту.
                    0
                    это само собой радует, но не так уже, не те уже ощущения, раньше пока кодишь был такой прилив адреналина, думаю не меньше чем у человека который с парашютом прыгает впервые, а теперь нету этого, программирование превратилось просто в написание текста понятного немногим, ей богу как в матрице ) просто смотришь в буквы и цифры, а видишь целую картину…
                      0
                      Проект, результат. Почему я это опускаю? Сдал продукт, молодец. Сдал хороший продукт, молодец, теперь ты богатый, у тебя есть яхта.

                      Но не это меня привлекает в программирование. Не результат.
                        +2
                        Нет причем тут молодец? я имел виду принцип «Любим процесс помним о результате».Я не о материальной стороне, а о чувстве удовлетворения хорошо проделанной работой.Чувстве гордости.
                        Ну знаете такая приятная пустота, как после закрытия сессии в институте...=))
                        Правда со временем я стал считать героизмом не добавление недокументированных фич, а просто сдачу качественного проекта в срок.
                        Касательно той части что «процесс»… но просто может не стоит романтизировать так сильно нашу с вами работу? Это такая же работа как все остальные.Просто делайте небольшие проекты для души.
                        Сделайте сайт любимому бару, любимой группе.Напишите маленькую Open Source утилиту.
                        И не забивайте себе голову всякими размышлениями, тем более перед новым годом.
                        «Никто не запомнит вас за ваши мысли»@Г.М. Маркес
                          0
                          Нет причем тут молодец? я имел виду принцип «Любим процесс помним о результате».Я не о материальной стороне, а о чувстве удовлетворения хорошо проделанной работой.Чувстве гордости.

                          а разве материальная составляющая не лудшая часть удоволетворения от работы?

                          Ну знаете такая приятная пустота, как после закрытия сессии в институте...=))

                          Хм. Нечего делать. Знаю, помню. Сейчас такого нет :)

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

                          Может с увелечением размера проекта? Просто чем больше проект, тем больше сложность его…

                          Касательно той части что «процесс»… но просто может не стоит романтизировать так сильно нашу с вами работу? Это такая же работа как все остальные.Просто делайте небольшие проекты для души.
                          Сделайте сайт любимому бару, любимой группе.Напишите маленькую Open Source утилиту.


                          Так получилось, что я давно стал прогматиком в плане программирования. Вы не увидели мысль, а может я ее не явно преподнес, но то, как вы поняли мои мысли, тоже интересно.

                          Делать маленькие проекты для души? В них нет того, что я ищу в программирование ;)
                    • НЛО прилетело и опубликовало эту надпись здесь
                        –1
                        Не, не ода. Скорее дао бага или даже дао программирования.
                        0
                        Для меня программирование интересно, пока есть нерешенные ПРОБЛЕМЫ (именно так, с большой, мелкие баги не так интересны). Не придуман алгоритм вычисления чего-то, нужна оптимизация сложнейшего запроса… Знакомство с новыми технологиями…
                          +1
                          А вам часто приходиться придумывать новый алгоритм? А технологии… А давно было что-то действительно новое, а не buzzwords?
                            0
                            Технологии (в данном случае) необязательно что-то глобально новое :) На самом деле даже знакомство с новым плагином/модулем для фреймворка можно сюда подогнать. Про алгоритмы то же самое — необязательно это должен быть алгоритм из области создания ИИ.

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

                                    да… старость не радость :)
                                      0
                                      Да уж.
                                      А я думал, человек под сорок делится опытом постижения дао.
                                      Хотя, может просто молодежь сейчас быстро стареет :)
                                        0
                                        Ненуачо, в этом возрасте программистам на пенсию уже пора :)
                                          0
                                          тут вопрос когда начать ;)
                                            0
                                            Мне кажется, как и в музыке начать можно в 3-4 года. Лично я начал в 8-9 лет, и вот щас в 24 чувствую себя «старым волком» :)
                                    0
                                    Не поймите неправильно, но у меня первый компьютер появился только после 9 класса в связи с тяжелой экономической ситуацией, впрочем это мне не мешало торчать в компьютерном классе школы вечерами и ходить в кружок программирования, изучая и познавая этот великий созидательный процесс программирования. Я к тому, что для программирования совершенно не обязательно иметь дома личный компьютер, и не все профессиональные программисты становятся ими из-за обиды на злой компьютер; мне в первую очередь нравится ломать мозг, придумывать что-то новое, я от этого получаю непередаваемый кайф, более того я думаю, что программирование — это источник неиссякаемого самоудовлетворения, главное это понять, и тогда, как вы выразились, «кризис среднего возраста» не будет вас тревожить в возрасте 22 лет.
                                    0
                                    >На самом деле даже знакомство с новым плагином/модулем для фреймворка можно сюда подогнать.

                                    Так только первые пару десятков. Потом это всего лиш еще один фреймворк который делает то что итак уже известно просто «впрофиль», ето еще один модуль который делает что то что итак уже делали 50 раз, просто ну чуть чуть подругому.
                                    И я не о интернет-магазин-девелоперах… :-) Вечная гонка за новыми тезнологиями надоела, всеравно ничего оно не меняет.
                                      0
                                      и это еще один язык программирования, который делает что-то в профиль. Вот malbolge был интересен. Я на нем даже программу написал :) Но только интересен.
                                        +1
                                        когда у тебя в профиле уже десяток, то ты прикрасно понимаеш что еще один ничего не даст.
                                        всеравно они подобны, чтобы не сказать идентичны.
                                        Интересно первый функциональный, первый процедурный, первый скриптовый, первый ОО.
                                        А пятый ОО, пятый скриптовый — увы ничего незначит
                                          0
                                          есть эзотерика. Ее интересно изучать. Но применять ее негде :)
                                            +1
                                            попробуйте lisp )
                                  0
                                  скучно программировать… ну добро пожаловать в менеджеры

                                  а вообще программизм это отличное место для реализации своей потребности в исследованиях и самосовершенствовании. Считаете что в совершенстве овладели каким-то языком программирования или парадигмой? Переходите на другую парадигму или язык! Считаете что вашу программу уже идеальнее не написать? Забросте ее, напишите другую, и через годик вернитесь к своей старой. Думаю «ох да тут сколько можно переделать понормальному» вы себе скажете.

                                  Но ни в коем случае не надо забывать, что программированием мир не ограничивается, если интересно, затягивает, дает драйв — занимайтесь. Если нет — оглянитесь вокруг!
                                    +4
                                    Знаешь, управление проектами, пока не привлекает.

                                    Надоело не программирование. Надоело что ценных и хороших задач там почти нет. С опытом понимаешь, что хорошую, годную задачу искать приходиться долго и попадается она иногда.
                                      0
                                      как это нет :) да дофига :) с заходу могу нагенерировать идей на то что хочется но того чего еще нет. Была бы возможность взялся бы сам за всё :)
                                        0
                                        Ты уверен что сможешь сделать хорошую, годную задачу? Которая меня заинтересует? :)
                                          0
                                          ну из сотен то не реализованных вещей которые_требуются_человечеству_так_или_иначе никак не найдется интересной задачки? :)
                                            +1
                                            есть. Её и решаем. Но то, что основной кайф от багов, это не меняет.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +2
                                      Я вообще человек не азартный, но однажды в школе я поспорил аж на 10 рублей о чем то, только потому что был прав на 120% как мне казалось. Я был готов дать голову на отсечение а не только 10 руб.

                                      Когда я отдал свои 10 руб, я долго думал как такое могло произойти.

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

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

                                        0
                                        а я вот нихера не умею программировать. Когда маленький был, родители говорили: «Накой х… тебе этот компьютер. Мы тебе уже вон норковою шапку заказали...» А я им мол: «Посмотрите вот на другана моего, у него же ...» Родители тогда умнее были, мол все-равно только играться будешь. А я и поверил, мол накой мне это надо. Универ окончил, работать начал. А потом не выдержал, сказал, а ну его все нах. Уехал далеко. Опять учиться начал. Повстречал компьютер. Тогда мне подарили старенький Siemens Scenic с PentiumII. Короче лет 7 прошло уже. Только угнаться теперь за тем что потерял не возможно.
                                          +1
                                          Очень жизненно и довольно приятно, что люди таким делятся. Да, это так — чувство «бога»/«строителя мира», называйте как хотите. Лично у меня не пропал интерес к этому с такой точки зрения, а только вновь он загорается, когда я изучаю новые технологии и тут же стараюсь их где-нибудь использовать. Я думаю всем знакомо чувство, когда ты ставишь перед собой цель, у тебя не сразу получается её достичь, а когда получается, то испытываешь неописуемое чувство восторга, но когда цель не такая большая, как затраченные усилия, то и «счастья» может не возникнуть такого =) Единственная проблема, с которой я сталкиваюсь по сей день — это нагрузки. Очень часто пытаюсь взвалить (вообще, характер такой: всё и сразу) на свои плечи сверх своих возможностей и сил, и к середине проекта мотивация начинает уходить (если проект свой, а не заказ), что очень обидно. Тут только спасение друзей и подруг как моральная и физическая поддержка. Хотя может есть какие-то другие способы добавить себе мотивации… =)
                                            0
                                            Вот новые технологии, сейчас, уже не дают вообще радости и чувств, ибо изучено, прочитано и понятно достаточно многое.

                                            А нагрузки. Да. Особенно не нравиться, что если отдаваться полностью программированию, у тебя тело уставать не будет. Т.е. мозг, того, измотан, а тело полно сил… :(
                                            0
                                            напишите свою ос. это увлекательно и быстро не напишете
                                              +1
                                              я лучше эмулятор терминала ;)
                                                0
                                                так неинтересно. где же полет мысли и битва с железом? ;))
                                              +1
                                              Быть может стоит попробовать макраме? Или сравнительную лингвистику?

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

                                                Впрочем, коммерческое программирование далеко от искусства, далеко от полёта идей и мыслей в свободном программировании. Возможно, что просто Вы дошли до той стадии программиста, когда требуется уйти в свободное плавание, до собственных проектов и изысканий? Возможно, что до стадии, когда начинаешь думать, что знаешь о программировании всё…
                                                  0
                                                  я активно участвую в развии opensource. Но opensource не многим лучше (:

                                                  Основная мысль в том, что если ты изучил 100500 разных языков, парадигм, фреймворков, то изучить еще 100500 других не бдует чем-то новым, сложным, интересным… А баги, баги да, баги бывают интересным. Да и духовный опыт.
                                                  +9
                                                  Вы, скорее всего, мне не поверите, но истинное «дао бага» заключается в том, что багов быть вообще не должно! Конечно, в реальности такого не бывает, баги есть всегда. Но баги бывают разные.

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

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

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

                                                  В качестве примеров реальных больших и сложных open source проектов, разработанных по этому принципу, можете посмотреть на операционки Inferno и Plan9, утилиты DJB (qmail, djbdns, ...), etc. Безусловно, сложные баги, наверняка, встречаются и там. Но их количество и запутанность на порядки ниже тех, которые встречаются в любой навороченной CMS-ке, в то время как объективная сложность и размер, например, той же OS Inferno, на порядки выше этих CMS-ок. И если смотреть с этой, относительной точки зрения, можно честно сказать, что кол-во сложных багов в проектах, разработанных по этому принципу, пренебрежимо мало.

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

                                                    К последнему абзацу так и хочется добавить: «ничего невозможно нет» и «лёгкие пути к успеху — ни есть успех». Это имхо.

                                                    з.ы. жаль галочку поставить не могу =(
                                                      0
                                                      А пути к успеху нет. Не легкого, не тяжелого. Есть твои желания. Есть попытки их удоволетворить.
                                                        0
                                                        Я имел ввиду не способы продвижения к успеху, а то, как ты строишь эти пути. Т.е. не отмахиваться: я не буду это реализовывать, т.к. этим вряд ли кто воспользуется, а времени я потрачу много
                                                      –2
                                                      Прямо в точку=) повысил бы карму если бы мог=))
                                                        0
                                                        Хм. qmail говорите. А он не умеет ничего, что от него хотят. На него накладывают 100500 патчей, и там появляются баги (года 4-5 назад у меня почта жила на qmail ☺).

                                                        Вы говорите, хорошие, красивые, правильные вещи. Но они, к сожалению, совместимы, только с идеальном миром. Наш мир, ну может быть для вас идеальный. А для меня, он, бука такая, вплоне реальный.
                                                          +3
                                                          Хм. Вы удивитесь, нужды скольких людей удовлетворяет qmail без всяких патчей! Ну, если совсем точно, то с абсолютными минимумом тривиальных патчей, просто чтобы он собирался современным gcc, etc. — это называется netqmail. Можете посмотреть сам патч netqmail-1.05.patch, который накладывается на последнюю версию qmail-1.03 — он абсолютно тривиален. И даже netqmail не меняется уже почти 6 лет, посмотрите changelog.

                                                          Да, функциональности qmail достаточно для многих, но не для всех. Кто-то решает эту проблему кривыми патчами qmail, кто-то переходит на альтернативные почтовые сервера. И я считаю это абсолютно нормальным — лучше иметь простую и надёжную утилиту решающую 95% задач чем навороченный, глюкавый, дырявый и тормозящий комбайн, решающий 100% задач. В большинстве случаев можно обойтись простой утилитой, а в остальных, если очень надо, можно и комбайн поставить, осознавая плюсы и минусы такого решения.

                                                          Что касается мира — как Вы точно подметили, он для каждого свой. И Вы, и только Вы сами выбираете, каков будет мир лично для Вас. У меня мир более чем реальный, хотя по сравнению с Вашим он запросто может казаться идеальным. Но это не делает его менее реальным. :) И не означает, что для Вас этот мир не может стать реальным, если Вы того захотите.
                                                          0
                                                          Слишком хорошо чтобы быть правдой. Сколько вы знаете коммерческих проектов у котороых бы проходило по 12 месяцев от начала проектирования до первой строчки кода? Спешка — основной фактор слабостей дизайна тяжелых багов, хотя остается еще незнание того что требуется получить, но это слишком тонкая материя.
                                                            0
                                                            А кто говорил про 12 месяцев? Чтобы большой проект развалить на кучку мелких достаточно от нескольких часов до нескольких дней — зависит от опыта архитектора и наличия необходимого минимума информации о проекте. Писать маленькие простые проекты намного быстрее и легче, чем один большой и сложный — тут уже нарисовывается нехилая экономия времени разработки. Поддерживать и тестировать маленькие проекты тоже на порядок проще — экономия времени достигает невероятных масштабов. После чего всё сэкономленное время сливается на то, что вместо того, чтобы кодить в поте лица, фиксить тучи багов, и жить от дедлайна до дедлайна — очень очень лениво, даже без вхождения в «поток», не спеша, пишется простой код. :)
                                                              0
                                                              Преждем чем делить на части требуется определить как эти части будут взаимодействовать, как оператор будет получать результат, определить форматы файлов наконец. Вот тут-то нужны совсем не часы и не дни, а иной раз месяцы. Чем лучше все проработано, тем меньше ошибок и тем точнее можно будет определить время окончания работ.
                                                                +1
                                                                Вы, вероятно, не до конца понимаете суть того, что я описал. Ничего такого, что Вы описываете, не требуется. Месяцы не нужны. Более того, если на эту работу нужны месяцы и всё получается настолько сложно — значит всё делается неправильно: Вы пытаетесь разделить большее приложение на меньшие части не в том месте. Именно из-за неправильного выбора этих меньших частей и возникают все сложности. И нужно не героически преодолевать эти сложности за месяцы напряжённой работы, а иначе разделить большее приложение на части — там, где оно более легко и естественно разделяется.
                                                                определить как эти части будут взаимодействовать
                                                                А что тут определять? Это как раз наименее принципиальный вопрос — любой подходящий способ взаимодействия подойдёт. Например, если эти мелкие задачи оформляются в виде сетевых сервисов, значит взаимодействовать они будут либо через некий единообразный протокол вроде JSON-RPC, либо у каждой будет свой собственный протокол, наиболее подходящий для конкретно этого сервиса — у одного RPC, у другого постоянно открытый tcp-сокет по которому он отправляет события по мере их возникновения, etc. Безусловно, таких сервисов скоро станет много, и для управления ими понадобится некий реестр сервисов — но это разовая задача, которая решается один раз и дальше можно этим реестром пользоваться во всех проектах. Мы, например, вообще свой не писали, а подняли стандартный реестр сервисов из OS Inferno. Если Вы работаете в какой-нить навороченной среде, и Вас не волнует куча лишнего мусора бегающего по сети — можно использовать стандартные решения типа WS-crap/SOAP, etc. В общем, берёте любое подходящее решение для организации взаимодействия между сервисами/проектами/объектами/etc.
                                                                как оператор будет получать результат
                                                                Это тоже абсолютно не важно. Как ему удобно, так и будет. Когда проект разделён на мелкие подзадачи, то результат для оператора подготавливается просто через несколько запросов к этим подзадачам. И эта задача подготовки результата для оператора выносится в отдельную подзадачу. Нужно будет оператору получить другой результат и в другом формате — просто пишется ещё одна маленькая подзадача для этих целей. Иными словами, этой «проблемы» на этапе дробления проекта на подзадачи практически не существует, любой интерфейс для оператора всегда без проблем навешивается сверху на имеющуюся систему.
                                                                определить форматы файлов
                                                                Не совсем понял, причём здесь форматы файлов. Если Вы про то, что разные подзадачи будут работать с одними и теми же файлами, поэтому нужно тщательно разработать их формат — так это в корне неверно. Задачи необходимо максимально изолировать друг от друга, никаких сильных связей между задачами создавать нельзя. И, разумеется, две задачи не должны лазить в один и тот же файл, или базу данных — фактически, этот файл/база играют роль громадных глобальных переменных разделяемых несколькими задачами! У каждой задачи должны быть свои файлы/базы, а всё взаимодействие между задачами должно идти через чёткие и максимально простые интерфейсы.
                                                                Чем лучше все проработано, тем меньше ошибок
                                                                Нет, чем на большее количество мелких подзадачек Вы разобьёте свой большой проект, тем меньше Вас будет волновать степень общей проработанности. Простой пример: авторы никсовых утилит grep, sort, uniq, etc. и не думали прорабатывать все возможные способы способы воспользоваться их утилитами. Просто сами утилиты настолько просты, и у них настолько чёткие интерфейсы, что ими можно пользоваться для множества задач, которые авторы этих утилит даже представить себе не могли. Вот и в Вашем проекте должны быть такие же простые и более-менее универсальные маленькие задачи, на базе которых в результате можно будет собрать требуемый Вам большой проект. И если возникает потребность тщательно всё прорабатывать, постоянно выявляются ошибки в структуре и интерфейсах — значит Вы идёте не в ту сторону, скорее всего Вы не в том месте разделили большую задачу на меньшие и у Вас из-за этого появляются гораздо более сложные и менее гибкие интерфейсы между подзадачами.

                                                                Eсть хорошее rule of thumb: вся эта возня с дроблением на маленькие подзадачи призвана сделать Вашу жизнь намного легче, код проще, а багов меньше. Если на практике вместо этого стало только хуже — значит Вы неправильно разделили большой проект на маленькие. И не бойтесь большого количества маленьких проектов — чем их больше, тем каждый их них меньше, писать его легче, и интерфейсы у него проще и универсальнее. (Когда в Вашем проекте появится отдельный сервис, единственной задачей которого является генерация уникальных ID по запросу другим сервисам — знайте, что Вы, скорее всего, на правильном пути. ;-))
                                                                  0
                                                                  А можно пример проекта, который вы смогли разделить на маленькие части? Хочу узнать хоть что-то, чему повезло.

                                                                  Да, вы брукса читали?
                                                                    –1
                                                                    Брукса все читали. Правда, я его читал настолько давно, что уже толком ничего не помню, кроме общего ощущения тривиальности излагаемых идей. Хотя, я слышал, для многих эта книжка была настоящим открытием.

                                                                    С примерами сложнее. Мой текущий проект не open source, так что показать не могу. Проекту уже 7.5 лет, 7 из которых он приносит доход моему заказчику. Было много проблем со скоростью развития проекта — чем он больше становился, тем сложнее было что-то менять, фичи добавлялись чуть ли не месяцами. Но с тех пор, как я проникся идеями OS Inferno, проект начали потихоньку дробить на подзадачи, переходить на сервис-ориентированную архитектуру, etc. и дышать чем дальше — тем легче. Код пишется быстрее и уже не требует глубокого «погружения», чтобы он был качественным и ничего не ломал в других местах проекта.

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

                                                                    В некоторых случаях после продумывания архитектуры и дробления на подзадачи выясняется, что часть задач уже реализована стандартными утилитами, и то, что осталось написать мне — даже стыдно немного называть «программой». Но если учесть изначальную (до дробления на подзадачи) постановку задачи, и количество кода, которое изначально планировалось писать — вполне можно гордиться результатом. Примеры таких утилит есть у меня на сайте, напр. powerbackup и powerwatchdog (к сожалению, никак руки не дойдут доку к последнему написать на сайт).

                                                                    Но самые главные примеры таких проектов, это, конечно, OS Inferno и Plan9. Лучше смотреть на них, а не на меня — я только учусь применять фишки обнаруженные в OS Inferno в своих реальных проектах. Вообще, изучение кода Inferno даёт очень много в плане самообразования! Я, при моих 20-ти годах программирования и непрерывного самообразования, признаться уже думал, что учиться мне нечему. К счастью — это заблуждение быстро прошло, спасибо OS Inferno. :)
                                                                      0
                                                                      ok. А сколько человек участвует в этом проекте и какую роль ты занимаешь в этом проекте?

                                                                        –1
                                                                        Я не совсем понимаю, какое отношение это имеет к обсуждаемой теме, но ответить могу: я ведущий разработчик, архитектор и, по совместительству, админ; в команде в разное время было разное количество людей, 10-15 в среднем.
                                                                          0
                                                                          Странно что для команды в 10-15 человек, один занимается фактически всем.
                                                                            0
                                                                            Ну, может оно и странно, но такая специфика. У нас много ресурсов уходит на написание, поддержку и тестирование парсеров (для работы системы требуется непрерывно выкачивать и обсчитывать данные с кучи разных сайтов), и этим занято много людей. А я ядро системы пишу и в целом за всё отвечаю. Активных разработчиков кроме меня не так много — от одного до трёх, в среднем. Возможно это так же связано со спецификой рабочего процесса — у нас по сути группа фрилансеров, а не компания, народ берётся за работу только если она интересна, заставить работать кого-то (в т.ч. и меня) если он не хочет — крайне проблематично. Так что я занимаюсь тем, что интересно лично мне, и меня мало волнует то, что это сразу несколько разных ролей/профессий — для разных видов работ клиенту просто выставляется разная почасовка. Вообще, для фрилансера это скорее норма, делать работу разных специалистов — и проекты искать, и с клиентами общаться, и тз составлять, и архитектуру делать, и код писать, и тестировать, и устанавливать, и сервер админить, и деньги как-то получать, с налогами разбираться, etc. — полный цикл, и никуда от этого не денешься. Зато, если у меня пропадает рабочее настроение, я могу просто проинформировать клиента, что в работе намечается очередной перерыв, и два месяца проваляться с книжками на диване, пока рабочее настроение не вернётся.
                                                                              0
                                                                              Ага, ясно, фактически пишешь проект один, тогда это объясняет многое.
                                                                                0
                                                                                Да, с некоторой натяжкой можно сказать и так. Но Inferno и Plan9 писал не один разработчик, не два и не три — например здесь перечислены 35 человек, и это без учёта вклада коммьюнити, только, так сказать, «родители» Plan9.

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

                                                                                Когда разработчик один, и он полностью контролирует архитектуру и код системы, он может написать и большой сложный проект избежав превращения кода и архитектуры в говно — группе разработчиков это уже намного сложнее. А в случае с кучей маленьких, независимых проектов с чёткими интерфейсами — всё наоборот, группе решить такую задачу качественно быстрее и проще, чем одиночке.
                                                                                  0
                                                                                  Да группе решить такую задачу быстрее и проще, пока задача не меняеться. Как только задача начинает расширяться, видоизменяться (а бизнес процессы и бизнес задачи меняються, это нормально, это жизнь) — начинаються проблемы. Вы не предусмотрели интерфейс. Надо переделывать пол системы. Или строить workaround. Такой workaround есть, например, сеть в unix. plan9 проектировали, учитывая, что сеть уже есть, например.

                                                                                  Вы, в своих рассуждениях, не учитываете ровно одну вещь — человеческий фактор. Пока вы работаете один, у вас его нет. Как только у вас появляется комманда — возникают эти вопросы.
                                                                        –1
                                                                        p.s. а у меня член 35 см, в ширину, в диаметре
                                                                          +1
                                                                          Я рад за Вас. А к чему это было? Я где-то проявил вопиющую нескромность? В пассаже про Брукса?
                                                                0
                                                                Да, что касается «незнания того, что требуется получить». Этот фактор имеет место быть, но… если вы вместо большого проекта пишете, условно говоря, два десятка небольших утилит а-ля никсовые grep|sort|uniq|etc., то при изменении задачи есть высокая вероятность, что вы выкинете пару утилит за ненадобностью, но остальные отлично подойдут под изменившиеся условия задачи. А в случае с большим проектом бывает так, что архитектура полностью не подходит под изменившуюся задачу и нужно либо переделывать вообще всё, либо ещё до первого релиза засирать архитектуру кривыми хаками и workaround-ами.
                                                                  0
                                                                  чем более гибкий дизайн проекта вы делаете, тем больше сил требуется на его поддержку, а значит и времени и денег. У вас есть const по времени релиза и бюджет.

                                                                  Вы можете сделать проект гибким, хорошим, красивым, но вы не уложитесь в бюджет. Вы не уложетесь в сроки. И оба ваших лучших программиста уйдут от вас, один отрпавиться на север, петь блюз, а другой уедет в тибет — вам придеться завершать проект горсткой дебилов, которые остались, ибо найти новых, вы не успеете.
                                                                    0
                                                                    Да, если ключевое слово гибкий — Вы абсолютно правы, именно так всё и будет. Но в том подходе, о котором я пишу, ключевые слова другие: маленький и интерфейс.

                                                                    Условно говоря, если разделить задачу «на месяц» на 4 задачи, что каждую из этих четырёх можно будет сделать не за неделю, а где-то за 3-4 дня. Просто за счёт того, что каждая из этих задач в несколько раз проще изначальной большой задачи. Это, в некотором смысле, аналогично тому, как локальные переменные сужают область видимости: когда пишется функция, у которой есть чёткий простой интерфейс (два параметра, одно возвращаемое значение, чётко определены типы и допустимые диапазоны принимаемых и возвращаемых значений), и которая работает только с локальными переменными (не лазит в общую базу данных, не лазит в общие файлы, не лазит в глобальные переменные, etc.), то в голове нет нужды держать весь проект, учитывать особенности взаимодействия этой функции со всеми остальными, и т.д. Так и здесь, если проект разбить на несколько меньших, и разграничить их чёткими и простыми интерфейсами, то писать код становится на порядок проще!

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

                                                                    Безусловно, за всё надо платить, в том числе и за все эти «бонусы». В данном случае, с увеличением количества подзадач/проектов из которых собирается в результате необходимая функциональность большого проекта, сильно увеличиваются накладные расходы на поддержку всего этого хозяйства — возникает потребность в выделенном реестре сервисов, усложняется deploy системы (ибо вместо одной программы нужно установить два десятка и настроить их для совместной работы), etc. Но, по моему опыту, всё это сторицей окупается за счёт общего упрощения кода системы.

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

                                                                0
                                                                очень хороший рассказ. Показывает суть любви к багам :)
                                                                –1
                                                                Я дауншифтер и фрилансер, так стабильно и корпоративно кодить не умею и не хочу учиться принципиально.
                                                                Т.е. как бы — сочувствую, но несогласен. Но за фавикон в виде конвеевской споры (или это фишки для Го?) — в любом случае однозначно зачет.)
                                                                  0
                                                                  и, да, я считаю, всегда есть масса проблем которые вы не закодите прям таки «плавным неотвратимым потоком»…
                                                                    +1
                                                                    Под не интересной задачей, я имею ввиду задачу, которую я понимаю как решать :) То, что ее еще написать надо, поянтно. Но мой интерес иссякает к задаче, когда она обретает пути к решению.
                                                                      0
                                                                      Да, есть такой эффект, сам от него немного страдаю. Но, дело в том, что написать ещё надо суметь. То, что у Вас в голове сформировалось некое идеальное :) решение проблемы, и Вам резко стало скучно — это ещё не означает, что найденное решение реально будет работать, что оно учитывает все имеющиеся нюансы (когда пишешь код — почти всегда всплывают совершенно неожиданные проблемы, чаще мелочь, но бывают и очень серьёзные), и что Вы сможете не менее идеально реализовать его в коде — элегантно, просто, читабельно, гибко, эффективно, безопасно… и без тех самых сложных багов.

                                                                      Фактически, умение именно написать код, а не решить задачу в уме, и есть программирование. Решение задачи в какой-то предметной области Вам может предоставить с самого начала специалист в этой предметной области, и Ваша задача, как программиста, это решение запрограммировать — корректно (т.е. без багов), эффективно и безопасно.

                                                                      Да, сейчас этот подход почти не встречается (в реальном мире :)), поэтому программисту приходится разбираться с предметной областью заказчика, и самому искать решение его задач. Но это — не программирование. Это, скорее, работа (бизнес-)аналитика. А если предметная область это само программирование — тогда архитектора. К сожалению, если архитектор не пишет живой код, а только разрабатывает в уме архитектуру — он такого наразрабатывает, мама не горюй!

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

                                                                          Мне нравиться строить лисапеды, писать всякие извращения; но «кушать» мне хочеться больше ;)
                                                                        0
                                                                        Вот расстрелял бы тех кто не умеет корпоративно кодить =) недавно был большой проект, взял программиста такого, быстро работает, результативно =) Ну а потом, он ушел. В его зоне лежал веб клиент, никто никогда туда не лез =) Разгребать запарились! В итоге чтобы проект сопровождать дальше и понимать что и как, сели и переписали все заново.
                                                                          0
                                                                          попробуйте добавить в незнакомый движок новый функционал — чем «корпоративнее» он спроектирован и написан, тем это сложнее. такой парадокс, дружок. я лучше залезу в код одиночки, если только он его камментил хоть немного, чем в битрикс.
                                                                        0
                                                                        Любой хороший фрилансер понимает, что можно часть работы отдать другим фрилансерам, а себе оставить интересную задачу, а с не интересных получить процент.
                                                                          0
                                                                          это верно)
                                                                        0
                                                                        Программирование — это искусство правильного ограничения абсолютной абстракции. (Из личных заметок)

                                                                        Как и в любом другом искусстве предела совершенству нет=)
                                                                          +1
                                                                          а мне нравится решать нестандартные алгоритмические задачи и получать кайф от того, что я смог их решить.
                                                                            0
                                                                            Попробуйте новый язык программирования, новую платформу освоить, авось, и придумаете, чем себя занять :) Хотя, конечно, если все уже изучено, то тогда — увы и ах, придется вам самим придумать что-нибудь совсем новое. :)
                                                                            //
                                                                            А я, к примеру, в программировании люблю возможность писать код по-разному. Таким образом, появляется возможность возвращаться к уже написанному коду время от времени и каждый раз балдеть от того, что ты можешь еще и еще улучшить безопасность по отношению к типам, согласованность интерфейсов, сделать код более прозрачным или более универсальным.
                                                                            Особенно полезным считаю разработку реюзабельного кода. Разработка библиотек, особенно с поддержкой концепции обобщенного программирования, — непростая и часто очень интересная задача.
                                                                              0
                                                                              возможность переписать код красиво для тебя в текущий момнет времени (а чувство прекрасного изменяться со временем, да) не всегда возможно. И часто глупо. Ну перепишешь ты этот кусок сейчас. А через 2 недели перепишешь еще, ибо чувство прекрасного измениться. Так и будешь ты его переписывать, не сделав людей счастливыми.
                                                                              0
                                                                              «еще те 5 штук до конца недели, а если пофиксишь » Эх хорошо бы )))))
                                                                                0
                                                                                Хорошо написано.
                                                                                Но почему «Каждый баг — это research» а не к примеру «Каждый баг — это исследование»? К чему столько слов на английском явно не обусловленных контекстом?
                                                                                  +2
                                                                                  Именно тут? Для рифмы.
                                                                                    0
                                                                                    вот тут понимаю)
                                                                                  0
                                                                                  Когда хочется почувствовать себя ребенком — пишу игры.
                                                                                    0
                                                                                    мммм? какие игры? Там же основная работа это создание т.н. «движка»
                                                                                    0
                                                                                    Моя статья на эту же тему: Как я люблю программировать. trurl123.blogspot.ru/2012/10/blog-post.html

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое