Comments 164
Что значит нет места творчеству? А демосцена? Его нет к примеру в иос_разработке где за пару рабочих дней нужно склепать РССридер и для этого надо знать стопицот фраймверков и постоянно доучивать. А попробуйте написать ОСь с нуля — нет нет, а творческий подход понадобится кое-где.
Уточнения для — вы не путаете программирование с проектированием архитектуры?
Нет, не путаю — всеже, я верю что творческий подход понадобится и на этапе написания кода, а не только на этапе проектирования.
Уточнения для — вы не путаете программирование с кодированием?
Я беру несколько шире, чем просто кодирование по готовой схеме. Но не настолько широко, чтобы выделять отдельно архитектора. Представляется, что таких программ довольно много. Они не настолько велики, чтобы выделять под них дорогие человекочасы архитектора и, возможно, интегратора, но и недостаточно просты, чтобы сесть и написать за неделю.
Но ведь это далеко не все случаи. И то, что не требуется отдельный архитектор, еще не значит, что в программе нет архитектуры.
Да, конечно не значит, архитектура всегда есть. Но — для таких программ проектирование архитектуры, в общем-то, идет в небольшом объеме, в основном игра с паттернами.
На самом деле такие программы это огромный рынок, вероятно больший чем рынок энтерпрайз софта. Всякие казуальные и не очень игры, веб приложения(тот же github, у них нет отдельных архитекторов), разработки на микроконтроллерах. И во многих из них требуются оригинальные решения, а не просто перекладывание данных из БД в БД.
Не следует проецировать свой опыт на всю индустрию.
Не следует проецировать свой опыт на всю индустрию.
Я описал конкретную ситуацию с конкретными людьми, плюс некоторые наблюдения «наружу». Если в вашем окружении регулярно возникают изобретательские задачи, и при этом соблюдаются требования качества кода — могу только порадоваться за вас, «склонный к насилию психопат» вам не угрожает.
Они не обязательно должны возникать так уж регулярно. Даже у скульпторов эскиз скульптуры занимает гораздо меньше времени, чем ее воплощение, и кроме творческих метаний, нужно уметь применять стамеску и молоток, а также знать свойства материалов.
И это не говоря о таких профессиях, как архитекторы, где творчество очень сильно смешивается с инженерным делом.
Кстати, насчет игровых движков. Если есть движок полностью подходящий под задачу, то не требуется программист, если же нужно делать какие-то вещи, например реализовывать сложную игровую механику, то тут уже в дело вступает творчество, ну а потом рутина.
Просто работа есть работа, даже в самой творческой работе рутины всегда больше. А где смешивается с инженерией — зачастую гораздо больше.
И это не говоря о таких профессиях, как архитекторы, где творчество очень сильно смешивается с инженерным делом.
Кстати, насчет игровых движков. Если есть движок полностью подходящий под задачу, то не требуется программист, если же нужно делать какие-то вещи, например реализовывать сложную игровую механику, то тут уже в дело вступает творчество, ну а потом рутина.
Просто работа есть работа, даже в самой творческой работе рутины всегда больше. А где смешивается с инженерией — зачастую гораздо больше.
И в кодинге есть творческий подход.
Вот разбирал модуль Акции
Вот разбирал модуль Акции
$shop->razvesti($loh, $id_order) // оформление заказа по акции, передается код пользователя и код заказа
Не только сцена. Геймдев — это искусство в чистом виде. От создания гейм-механики современных игр до написания саундтреков для игр 1980-х годов под разные звуковые чипы.
По геймдеву много написано, и есть чертовски удачные реализации движков, так что тут изобретать велосипед наверное не нужно. Демосцена — да, согласен. Ну и всё-таки изобретательские задачи под эту статью не попадают.
>> По геймдеву много написано, и есть чертовски удачные реализации движков,
Тем не менее, каждая уважающая себя студия из года в год старательно пилит именно свой движок. И это касается не только крупных студий. Куча инди-игр используют самописные движки, так как зачастую игра не сводится к стандартно-типовой.
Тем не менее, каждая уважающая себя студия из года в год старательно пилит именно свой движок. И это касается не только крупных студий. Куча инди-игр используют самописные движки, так как зачастую игра не сводится к стандартно-типовой.
Я предлагаю сойтись на том, что понятия «программирование» и «творчество» настолько абстрактные, что в одном понимании они могут быть похожи, а в другом совершенно различны или даже противоречивы.
Поэтому и вы, и автор статьи по-своему правы.
Поэтому и вы, и автор статьи по-своему правы.
Очень понравилась фраза про психопата.
А статья действительно заставляет задуматься над тем, что пишешь. Спасибо автору.
А статья действительно заставляет задуматься над тем, что пишешь. Спасибо автору.
Макконелл очень точно подметил, при переписывании одного из модулей проекта я очень хотел узнать адрес предыдущего разработчика
Вы не одиноки, бывший коллега рассказал про то, что они пустили на самотек одного из вновь прибывших разработчиков, и полезли в его код когда он уже уволился. Один из самых спокойных людей, которых я знаю, раскаивался, что не успел дать тому хлопцу в табло :) Сами виноваты конечно, но Макконелл оказался прав.
«Программирование — это не выражение себя» — да.
«программист — это робот» — нет.
Полное подчинение логике — не есть отсутствие творчества.
Если бы программисты были роботами, четко следующими инструкциям — их самих можно было бы заменить программами. Сейчас, же, не смотря на наличие множества систем метапрограммирования, полностью заменить кодера, ни одна из них не может.
Делать интересные вещи качественнее и пропускать неинтересные — издержки человеческого существа, и если вы считаете это ненормальным, возможно вам стоит подождать еще сотню-другую лет, и брать на работу настоящих роботов.
В целом статья понравилась, и я согласен, что нужен самоконтроль, но не тем методом к которому вы призываете. В таких ситуациях спасает правильная постановка задачи, организация команды и регулярные ревью кода, где «неинтересные» места можно будет обнаружить и переписать.
«программист — это робот» — нет.
Полное подчинение логике — не есть отсутствие творчества.
Если бы программисты были роботами, четко следующими инструкциям — их самих можно было бы заменить программами. Сейчас, же, не смотря на наличие множества систем метапрограммирования, полностью заменить кодера, ни одна из них не может.
Делать интересные вещи качественнее и пропускать неинтересные — издержки человеческого существа, и если вы считаете это ненормальным, возможно вам стоит подождать еще сотню-другую лет, и брать на работу настоящих роботов.
В целом статья понравилась, и я согласен, что нужен самоконтроль, но не тем методом к которому вы призываете. В таких ситуациях спасает правильная постановка задачи, организация команды и регулярные ревью кода, где «неинтересные» места можно будет обнаружить и переписать.
Не очень понял вашу мысль. Если бы существовал стопроцентный конвертер «бизнес-идея» -> «код», то программисты де-факто оказались бы не нужны, просто таких технических средств нет, и, ввиду сложности, вряд ли они появятся в обозримом будущем. Такой конвертер в настоящее время — это команда разработчиков и управленцев. И понятно, что сбои в таком конвертере — это плохо.
Насчет интересных и неинтересных вещей — это и отличает профессионала. Он просто делает дело с максимальной эффективностью.
Насчет интересных и неинтересных вещей — это и отличает профессионала. Он просто делает дело с максимальной эффективностью.
Вы когда программируете продумываете архитектуру? Ищете наиболее быстрые варианты, алгоритмы? Это и есть творчество. Почему вы считаете, что полное подчинение логике является отсутствием творчества?
Кстати, само определение творчества из Википедии:
Творчество — процесс деятельности, создающий качественно новые материальные и духовные ценности или итог создания субъективно нового.
Программирование полностью подходит под это определение, так как является создателем чего-либо нового (не всегда, но простор для творчества есть).
Кстати, само определение творчества из Википедии:
Творчество — процесс деятельности, создающий качественно новые материальные и духовные ценности или итог создания субъективно нового.
Программирование полностью подходит под это определение, так как является создателем чего-либо нового (не всегда, но простор для творчества есть).
Цитируйте до конца уж:
Что программист вкладывает такое, что нельзя свести к трудовым операциям или логическому выводу? Какие аспекты личности он выражает?
Таким образом, в процессе творчества автор вкладывает в материал некие несводимые к трудовым операциям или логическому выводу возможности, выражает в конечном результате какие-то аспекты своей личности
Что программист вкладывает такое, что нельзя свести к трудовым операциям или логическому выводу? Какие аспекты личности он выражает?
Я уже написал, что вы можете при программировании продумывать сами архитектуру и писать СВОИ алгоритмы. Если вы пишите СВОИ алгоритмы, а не списываете их откуда-нибудь — вы уже вносите, что-то новое, свое, если бы этого не было — все программы писались одинаково. Когда вы решаете алгоритмическую задачу — у вас может быть десятки вариантов, но вы выберете один, а кто-то другой найдет другой вариант, это уже творчество.
И если уж идете до конца, то читайте все:
Творчество — это:
-деятельность, порождающая нечто качественно новое, никогда ранее не существовавшее;
-создание чего-то нового, ценного не только для данного человека, но и для других;
-процесс создания субъективных ценностей.
Под какой из этих вариантов программирование не подходит?
И если уж идете до конца, то читайте все:
Творчество — это:
-деятельность, порождающая нечто качественно новое, никогда ранее не существовавшее;
-создание чего-то нового, ценного не только для данного человека, но и для других;
-процесс создания субъективных ценностей.
Под какой из этих вариантов программирование не подходит?
Зависит от уровня обобщения на самом деле, можно повернуть и в вашу, и в мою сторону, но, пожалуй, это софистика.
Ох, хочу автоматический написатель кода в таком случае.
Можно более-менее автоматизировать создание блоков кода, выполняющих определенные задачи. У меня есть смутное понимание, что это возможно на текущем этапе развития IT, требуется только время, деньги и желание.
А вот создать их таким образом, чтобы они были понятны человеку — вот это настоящая проблема.
А вот создать их таким образом, чтобы они были понятны человеку — вот это настоящая проблема.
Вы не правы, банальный пример: выбор адекватных имен переменных и методов.
В ближайшем обозримом будущем не предвидится способов автоматизировать этот процесс — раз, и даже правильные имена у разных людей могут быть разные. А имена тянут за собой интуитивную логику. А логика тянет за собой структуру кода реализации.
В итоге у разных разработчиков получится разный код, по-разному структурированный. И с разными плюсами и минусами в пределах допустимых значений. В зависимости и от личных предпочтений, и от задачи.
В ближайшем обозримом будущем не предвидится способов автоматизировать этот процесс — раз, и даже правильные имена у разных людей могут быть разные. А имена тянут за собой интуитивную логику. А логика тянет за собой структуру кода реализации.
В итоге у разных разработчиков получится разный код, по-разному структурированный. И с разными плюсами и минусами в пределах допустимых значений. В зависимости и от личных предпочтений, и от задачи.
Я говорил о том, что нельзя создать программу, которая бы из ТЗ, пусть и максимально точного — создала продукт, сделав это лучше чем программист. Просто потому, что в программировании тоже множество подходов, и выбрать из них оптимальный, или продумать новый — главная творческая задача программиста.
Вы смотрите на программистов, как на инструмент, а на продукт, как на результат. Программисты всё же люди, а продукт для них — процесс(творческий).
Интересные\неинтересные вещи отличают человека от машины. Профессионализм не дает человеку избавиться от эмоций и собственного мнения о какой то конкретной задаче.
Вы смотрите на программистов, как на инструмент, а на продукт, как на результат. Программисты всё же люди, а продукт для них — процесс(творческий).
Интересные\неинтересные вещи отличают человека от машины. Профессионализм не дает человеку избавиться от эмоций и собственного мнения о какой то конкретной задаче.
Вы правы, в рабочей обстановке я смотрю на разработчика как на ресурс, со своими сильными и слабыми сторонами. Различные отступления тут излишни и делу только мешают. По большому счету, всё равно, творит человек или играет в робота — если задача решена на приемлемых условиях и легка в дальнейшем сопровождении — абсолютно неважно, как и почему. Опыт общения и с первыми, и со вторыми описан в статье. Какой ресурс более ценен, и имеет больше привилегий — понятно без лишних слов.
Интересные вещи это очень здорово, эмоции в работе очень важны. Однако профессионал делает любую задачу, за которую он взялся, максимально хорошо, на то он и профессионал. И он испытывает при этом эмоции, однозначно, и по большей части положительные, потому что делает, получает результат, отдачу в финансовом плане, реализацию своих возможностей и пр. Согласитесь было бы странно получить заказ в дорогом ресторане с известным шеф-поваром сногсшибательную лазанью и безвкусный суп, только потому, что повару не очень нравится готовить супы.
Интересные вещи это очень здорово, эмоции в работе очень важны. Однако профессионал делает любую задачу, за которую он взялся, максимально хорошо, на то он и профессионал. И он испытывает при этом эмоции, однозначно, и по большей части положительные, потому что делает, получает результат, отдачу в финансовом плане, реализацию своих возможностей и пр. Согласитесь было бы странно получить заказ в дорогом ресторане с известным шеф-поваром сногсшибательную лазанью и безвкусный суп, только потому, что повару не очень нравится готовить супы.
Спасибо, я вас понял)
Но я склоняюсь всё же к варианту, о том, что лучше грамотно построить цикл разработки, чем играть в робота.
Роботы — эффективны для громадной системы, ибо там увидеть и понять всю архитектуру, даже на самом высоком уровне абстракции, одному человеку не под силу, и нужно строго придерживаться заданных правил, чтобы ничего не сломать. Вот только таких систем не так много.
С последним абзацем, согласен, я не совсем верно понял коммент выше, поэтому так отреагировал.
Но я склоняюсь всё же к варианту, о том, что лучше грамотно построить цикл разработки, чем играть в робота.
Роботы — эффективны для громадной системы, ибо там увидеть и понять всю архитектуру, даже на самом высоком уровне абстракции, одному человеку не под силу, и нужно строго придерживаться заданных правил, чтобы ничего не сломать. Вот только таких систем не так много.
С последним абзацем, согласен, я не совсем верно понял коммент выше, поэтому так отреагировал.
Видимо вам повезло не работать с «роботами». Которые напишут точно так как указано в ТЗ и ни грамму не подумают, что ТЗ писал сосед по палате того самого «склонного к насилию психопата».
И мысли не допустят что заказчик скажет: «да я написал это ТЗ, но вы что сами не видите что это не удобно. И вообще ваш продукт гавно, а вот у конкурентов видите какая конфетка. Все больше я с вами не работаю и вместо новой версии у вас куплю продукт конкурента».
И мысли не допустят что заказчик скажет: «да я написал это ТЗ, но вы что сами не видите что это не удобно. И вообще ваш продукт гавно, а вот у конкурентов видите какая конфетка. Все больше я с вами не работаю и вместо новой версии у вас куплю продукт конкурента».
Написать и согласовать ТЗ — тяжкий труд, это несколько за рамками статьи.
У меня есть три основных стратегии выполнения заказа:
— четкое выполнение ТЗ, шаг влево, шаг вправо… Я лучше сам застрелюсь.
— инициатива по изменению ТЗ, если вижу в нём неудачные положения или возможность расширить функциональность малой кровью
— практически полная свобода в рамках общего концепта при регулярных обсуждениях и согласованиях дальнейших шагов, иногда приводящих к расширению или даже изменению концепта.
Выбор осуществляется (когда явно для заказчика, когда нет, а иногда даже неявно для меня) в процессе обсуждения (формирования ТЗ). Следовать постоянно лишь одной из этих (или какой-то другой) стратегии постоянно — никаких нервов не хватит, не говоря об экономическом вреде, пускай и косвенном (одноразовое сотрудничество, вместо постоянного), прежде всего для меня.
— четкое выполнение ТЗ, шаг влево, шаг вправо… Я лучше сам застрелюсь.
— инициатива по изменению ТЗ, если вижу в нём неудачные положения или возможность расширить функциональность малой кровью
— практически полная свобода в рамках общего концепта при регулярных обсуждениях и согласованиях дальнейших шагов, иногда приводящих к расширению или даже изменению концепта.
Выбор осуществляется (когда явно для заказчика, когда нет, а иногда даже неявно для меня) в процессе обсуждения (формирования ТЗ). Следовать постоянно лишь одной из этих (или какой-то другой) стратегии постоянно — никаких нервов не хватит, не говоря об экономическом вреде, пускай и косвенном (одноразовое сотрудничество, вместо постоянного), прежде всего для меня.
Поздравляю!
Вы спрятали творчество за черным ящиком под названием «работа программиста» и утверждаете, что в нем нет творчества. По-моему, Вы пытаетесь сами себя обмануть, оперируя высоким уровнем абстракции без апелляции к сути процесса программирования.
Вы спрятали творчество за черным ящиком под названием «работа программиста» и утверждаете, что в нем нет творчества. По-моему, Вы пытаетесь сами себя обмануть, оперируя высоким уровнем абстракции без апелляции к сути процесса программирования.
ИМХО, творчество — это определённым образом сформулированная логика, набор правил и методик создания этого самого творчества (творческих прозведений) — иначе его бы никто не понимал. Возможно только, что эти правила плохо поддаются формализации.
Мне кажется, что причина этого — извращенное понимание «творческого подхода», созданное современной «попсовой» культурой, а программист — действительно творческая профессия, но творческая в плане нахождения нестандартных путей более удобного и красивого решения задачи (да, возможно, это гораздо больше относится к построению архитектуры, но, все же, это частично ложится и на программиста).
Золотые слова! Щас допишу этот камент и продолжу захардкодивать копипастой ЮРЛКИ в РСС читалку.
<занудство?>
Да, удобство и красоту тоже надо определить для себя :)
Для кого-то это — хардкод всего и вся или методы на пять листов а4, которые делают вообще все, что было в тз, а для кого-то — удобная для поддержания и понятная архитектура для сложного процесса, в которую новые фичи сможет добавлять без проблем тот же джуниор.
</занудство?>
Да, удобство и красоту тоже надо определить для себя :)
Для кого-то это — хардкод всего и вся или методы на пять листов а4, которые делают вообще все, что было в тз, а для кого-то — удобная для поддержания и понятная архитектура для сложного процесса, в которую новые фичи сможет добавлять без проблем тот же джуниор.
</занудство?>
Программист — в первую очередь инженер, а не художник. У него ровно столько же творчества, как у инженера подводной лодки, но не нужно путать это с объёмом каждодневного творчества дизайнера.
Эти белковые массы часто сами не понимают чего они хотят. Поэтому приходится за них творчески домысливать.
О, с этой стороны я заглянуть забыл
+100500. Собственно процесс воплощения размытой идеи, высказанной в ТЗ, в конечный продукт со всеми конкретными леталями и есть творчество. Это все равно что вам сказали: «нарисуйте портрет такого то человнка с такими то деталями» — это ТЗ. Но согласитесь — результат — сам портрет — творчество!
Мое мнение — искусство заключается в нахождении идельного решения со всех точек зрения. Умение сочетать в себе эффективность и простоту, скорость и безопасность и тд. А вы как-то однобоко рассмотрели ситуацию-либо слишком сложный код для восприятия, либо копипаст. Творческий процесс в нахождении золотой середины, а реализация — это уже набор правил и соглашений, будь то именование переменных, связанность классов и тд.
Программирование — инженерная профессия. Точка.
Так же как проектирования автомобиля или станка.
Есть ли доля творчества в работе инженера? Наверное, смотря как определить творчество.
Но самое главное — программист — инженер. Не ученый, не творец.
Так же как проектирования автомобиля или станка.
Есть ли доля творчества в работе инженера? Наверное, смотря как определить творчество.
Но самое главное — программист — инженер. Не ученый, не творец.
Точка-точка-запятая… На западе программист именно изучает computer science. Также логично вспомнить, что очень многое приходится «творить». В общем инженер — это учёный-творец. Как-то вот так.
Я — тот самый программист на западе, который изучал компьютер сайенс. Ну и что? Инженер, который делает автомобили или ракеты тоже учит физику, математику, сопромат. Это ничего не говорит о том, что он делает на работе
Т.Е. построение автомобиля/ракеты инженером не творчество ни разу? А заодно и к науке никакого отношения не имеет? Ну что ж, кодьте далее.
Имеет отношение и к науке и к творчеству. Но всё это называется работой инженера.
Так же как и работа программиста.
Так же как и работа программиста.
Ну тогда давайте уже придём к согласию, что программист — творец, зачастую занимающийся наукой и забудем этот глупый спор? Инженер обязан включать в себя это, иначе получится уныло и развития не будет.
работа портретиста тоже работа — спросите любого, кто на курортах за денюжку рисует портреты. Но при этом портретист занимается таки творчеством — несмотря на то, что это его работа. Одно другому не мешает.
Полностью согласен с вами. От себя добавлю, что очень многие люди считают программирование даром божьим, а любое напоминание о технических аспектах, вызывает у оных бурю негодования.
Более того, очень многие разработчики забывают зачем они работают на самом деле. И, вместо реализации задачи разумными способами в кратчайшие сроки, занимаются постоянным самоудовлетворением (во всех смыслах этого слова).
Более того, очень многие разработчики забывают зачем они работают на самом деле. И, вместо реализации задачи разумными способами в кратчайшие сроки, занимаются постоянным самоудовлетворением (во всех смыслах этого слова).
>> Программирование — инженерная профессия.
Мне кажется так можно было говорить в годах так эдак 80-90х
В слове программист уже столько всего, что говорить — программист это инженер, по крайне мере очень примитивно.
Мне кажется так можно было говорить в годах так эдак 80-90х
В слове программист уже столько всего, что говорить — программист это инженер, по крайне мере очень примитивно.
Автомобили тоже усложнились с 1920х, но проектирование автомобилей — всё еще инженерная профессия.
А кто Вы? Творец? Ученый?
Или всё таки вы работаете чтобы в сроки создать продукт в соответствии с требованиями?
А кто Вы? Творец? Ученый?
Или всё таки вы работаете чтобы в сроки создать продукт в соответствии с требованиями?
В программировании существует понятие программист-архитектор например, а есть ли инженер-архитектор?
Скажу Вам по секрету — я архитектор.
В автомобилях тоже самое — кто то создаёт конпепцию машины, выбирает технологии, список основных узлов и связи между ними, а кто то эти узлы проектирует.
В автомобилях тоже самое — кто то создаёт конпепцию машины, выбирает технологии, список основных узлов и связи между ними, а кто то эти узлы проектирует.
Я просто хотел сказать что инженер-программист это лишь подвид вида программист обычный. Иначе не писали бы инженер-программист, а просто программист. Программист != инженер
Есть научные дисциплины. Есть творческие дисциплины. И есть инженерные диспиплины.
Работа того, кто придумывает марсоход мало похожа на работу того, кто придумывает газопровод. Но оба они инженеры.
И, поверьте мне, тому, кто придумывате марсоход или шаттл творчества нужно не меньше чем тому, кто пишет драйвер или CMS.
Но все мы инженеры.
Работа того, кто придумывает марсоход мало похожа на работу того, кто придумывает газопровод. Но оба они инженеры.
И, поверьте мне, тому, кто придумывате марсоход или шаттл творчества нужно не меньше чем тому, кто пишет драйвер или CMS.
Но все мы инженеры.
Программист = инженер.
Аргументацию — «Профессиональная разработка программного обеспечения», Стив Макконнелл.
Аргументацию — «Профессиональная разработка программного обеспечения», Стив Макконнелл.
Проектирование узлов не творческая работа?
Тетя Бася — архитектор. (С) :)
Но кому хочется почувствовать себя полубогом, не растолкуешь, насколько противопоказана креативность в девятнадцати случаях из двадцати.
Но кому хочется почувствовать себя полубогом, не растолкуешь, насколько противопоказана креативность в девятнадцати случаях из двадцати.
Смотря что вы имеете ввиду под словом творец. Изобретатель — например это творец? Однозначно, так как он приносит, что-то новое в мир. А если почитать определение изобретателя, то он —
Изобрета́тель — человек, который создаёт новые изобретения, главным образом, технические устройства или методы. Хотя некоторые изобретатели могут быть также учёными, большинство из них — инженеры, создающие технические новшества на базе открытий других учёных. Часто изобретатели улучшают существующие устройства или комбинируют их для создания новых полезных устройств.
Следовательно, если программист — инженер, то он может быть изобретателем, следовательно творцом. Логично?
Изобрета́тель — человек, который создаёт новые изобретения, главным образом, технические устройства или методы. Хотя некоторые изобретатели могут быть также учёными, большинство из них — инженеры, создающие технические новшества на базе открытий других учёных. Часто изобретатели улучшают существующие устройства или комбинируют их для создания новых полезных устройств.
Следовательно, если программист — инженер, то он может быть изобретателем, следовательно творцом. Логично?
И да, я согласен с вами что программист — инженер:)
Логично. Но я что то не видел тех, кто проектирует машины или станки, кто обижается на то, что их называют инженерами, а не творцами. А вот программистов это задевает!
Поймите — Ваша главная задача — сделать вовремя продукт. Если для этого нужно творить — отлично, но это не самоцель, в отличие от писателя
Поймите — Ваша главная задача — сделать вовремя продукт. Если для этого нужно творить — отлично, но это не самоцель, в отличие от писателя
Вот если вы им скажете — вы инженер, то даже программисты не будут против. А если скажите — вы не творец, то даже инженеры работающие с узлами будут обижены.
Меня не задевает, я не согласен, только с тем, что в программировании нет творчества и доказываю что оно есть, а то что программист — инженер — верно.
100%.
Более того, большинство «профессиональных» творцов тоже связаны контрактами,
с достаточно жесткими временными рамками:
журналисты — статья в день, очень часто на заданную тему — это тврочество или нет?
писатели — роман к заданному сроку, и попробуй не успей, там у же типография ждет,
бумага нарезана, и т.п. — это творчество или не?
художники — куча примеров: художник оформитель, портрет на заказ, и т.д.
Так что вопрос, просто не корректный.
В большинстве специальностей есть место творчеству, но необязательно эту возможность использовать. Каждый решает для себя в каждом отдельном случае.
Другое дело, что некоторые специальности содержат в себе более широкий творческий потенциал:
можно быть прекрасным дворником, просто добросовестно следуя инструкциям, а вот прекрасным писателем или художником стать невозможно не привнеся что-то новое, уникальное.
Так что хороший вопрос, на мой взгляд, это: содержит ли програмирование в себе широкий творческий потенциал.
Ну и мой ответ, соответственно — да, содержит: невозможно стать прекрасным програмистом, не обладая своей собственной уникальной манерой. Можно стать неплохим, может, даже середнячком, но не одним из лучших.
Более того, большинство «профессиональных» творцов тоже связаны контрактами,
с достаточно жесткими временными рамками:
журналисты — статья в день, очень часто на заданную тему — это тврочество или нет?
писатели — роман к заданному сроку, и попробуй не успей, там у же типография ждет,
бумага нарезана, и т.п. — это творчество или не?
художники — куча примеров: художник оформитель, портрет на заказ, и т.д.
Так что вопрос, просто не корректный.
В большинстве специальностей есть место творчеству, но необязательно эту возможность использовать. Каждый решает для себя в каждом отдельном случае.
Другое дело, что некоторые специальности содержат в себе более широкий творческий потенциал:
можно быть прекрасным дворником, просто добросовестно следуя инструкциям, а вот прекрасным писателем или художником стать невозможно не привнеся что-то новое, уникальное.
Так что хороший вопрос, на мой взгляд, это: содержит ли програмирование в себе широкий творческий потенциал.
Ну и мой ответ, соответственно — да, содержит: невозможно стать прекрасным програмистом, не обладая своей собственной уникальной манерой. Можно стать неплохим, может, даже середнячком, но не одним из лучших.
Не знаю как редактировать:( Должно быть так:
100%.
Более того,большинство «профессиональных» творцов тоже связаны контрактами,
с достаточно жесткими временными рамками:
журналисты — статья в день, очень часто на заданную тему — это тврочество или нет?
писатели — роман к заданному сроку, и попробуй не успей, там у же типография ждет,
бумага нарезана, и т.п. — это творчество или не?
художники — куча примеров: художник оформитель, портрет на заказ, и т.д.
Так что вопрос, просто не корректный.
В большинстве специальностей есть место творчеству, но необязательно эту возможность использовать. Каждый решает для себя в каждом отдельном случае.
Другое дело, что некоторые специальности содержат в себе более широкий творческий потенциал:
можно быть прекрасным дворником, просто добросовестно следуя инструкциям, а вот прекрасным писателем или художником стать невозможно не привнеся что-то новое, уникальное.
Так что хороший вопрос, на мой взгляд, это: содержит ли програмирование в себе широкий творческий потенциал.
Ну и мой ответ, соответственно — да, содержит: невозможно стать прекрасным програмистом, не обладая своей собственной уникальной манерой. Можно стать неплохим, может, даже середнячком, но не одним из лучших.
Более того,
с достаточно жесткими временными рамками:
журналисты — статья в день, очень часто на заданную тему — это тврочество или нет?
писатели — роман к заданному сроку, и попробуй не успей, там у же типография ждет,
бумага нарезана, и т.п. — это творчество или не?
художники — куча примеров: художник оформитель, портрет на заказ, и т.д.
Так что вопрос, просто не корректный.
В большинстве специальностей есть место творчеству, но необязательно эту возможность использовать. Каждый решает для себя в каждом отдельном случае.
Другое дело, что некоторые специальности содержат в себе более широкий творческий потенциал:
можно быть прекрасным дворником, просто добросовестно следуя инструкциям, а вот прекрасным писателем или художником стать невозможно не привнеся что-то новое, уникальное.
Так что хороший вопрос, на мой взгляд, это: содержит ли програмирование в себе широкий творческий потенциал.
Ну и мой ответ, соответственно — да, содержит: невозможно стать прекрасным програмистом, не обладая своей собственной уникальной манерой. Можно стать неплохим, может, даже середнячком, но не одним из лучших.
В программировании нет места творчеству — начиная от именования файлов и переменных и заканчивая паттернами всё подчинено чёткой логике и имеет максимальную эффективность.
Если не секрет, а как из утверждения «все подчинено четкой логике» получается утверждение «нет места творчеству»? Эти концепции как-то связаны, влияют друг на друга? На уровне common sense совершенно непонятно, потому как механика тоже подчинена четкой логике (и сильно ограничена законами природы) а патентов на новые изобретения регулярно подается большое число, и далеко не все из них делались в строгом соответствии с методологией по ТЗ («ТЗ — изобрести что-то новое»). Взять хотя бы магнитное крепление кабеля питания к ноутбуку Apple.
Программист в любом случае, даже на низком уровне творческий. Архитектор это просто на более высоком уровне, а на низком уровне уже программист и все они творческие.
Несомненно, что любой код в лучшем случае должен писаться по паттернам проектирования, но не единственным образом можно сложить дом из этих паттернов, во одном будет крыльцо, а в другом 3 этажа, а в третьим вообще все сразу и монстроуниверерсально и неповоротливо.
Например сеть тоже можно построить по разному и она будет работать с точки зрения бизнес задачи, например кольцом или звездой, заказчик разницу не почувствует, а в то время каждый подход имеет свои преимущества и недостатки, с точки зрения архитектуры. Но как она будет дальше развиваться? вот это кстати применительно к бизнес задачам белковые массы никогда не говорят будущее развитие.
Есть такая поговорка: Недостатки есть продолжения достоинств, равно как и достоинства есть продолжения недостатков.
Несомненно, что любой код в лучшем случае должен писаться по паттернам проектирования, но не единственным образом можно сложить дом из этих паттернов, во одном будет крыльцо, а в другом 3 этажа, а в третьим вообще все сразу и монстроуниверерсально и неповоротливо.
Например сеть тоже можно построить по разному и она будет работать с точки зрения бизнес задачи, например кольцом или звездой, заказчик разницу не почувствует, а в то время каждый подход имеет свои преимущества и недостатки, с точки зрения архитектуры. Но как она будет дальше развиваться? вот это кстати применительно к бизнес задачам белковые массы никогда не говорят будущее развитие.
Есть такая поговорка: Недостатки есть продолжения достоинств, равно как и достоинства есть продолжения недостатков.
Интересная статья, и дискуссия после нее, только вот тут у меня внутри так и остался вопрос, творческий программист это хорошо? или плохо? или хорошо, но только в некоторых случаях?
Я бы не стал делить на «хорошо» и «плохо» в смысле абсолюта. С точки зрения тимлида — лучше тот, кто пишет хороший и легкий код. А с точки зрения конкретной личности… Человек — существо довольно сложное, и профессиональные навыки — лишь составляющая часть. Если человека устраивает его материальное положение и душевное состояние, обеспечиваемое всеми аспектами жизни (включая работу) — то это очень здорово. И тут уже вторично, пишет ли он эталонный код за 3000$ или подходит к коду как получится за 500$. Если же что-то не устраивает — то есть смысл задуматься и работать над собой.
> При работе над произведением художник/музыкант обычно начинает с этого самого «вектора зюйд-зюйд-вест» — с определенного настроения, концепции (рожденной внутри или выданной заказчиком, это в данном случае не столь важно). Конечный результат, в большинстве случаев, представляется весьма смутно. Справедливости ради отметим, что это — львиная доля удовольствия от творчества — делать как делается. Это, в сущности, и есть попытка «выразить себя».
Искусство и творчество — понятия очень широкие. Создать стройную систему — искусство. Написать шмат говнокода — тоже в каком-то смысле искусство… только уже ближе к области экспрессионизма в программировании.
Само по себе создание чего-то — творчество. Что же до конечного результата… проектируя систему, вы правда всегда себе представляете результат проектирования? Если действительно представляете, значит уже спроектировали, тем самым совершив акт творения.
Есть два крайних значения, когда в голове представления результата нет, и когда он уже есть. Переход — это и есть творчество. В первом случае нет ни ТЗ, ни документации. Во втором мы имеем идеальное ТЗ, которое целиком описывает систему, или же имеем саму систему, так как лишь готовая система может выступать в роли идеального ТЗ.
И до тех пор, пока мы не достигли этой второй точки, мы будем заниматься творчеством. Другое дело, что у джуниоров его не должно быть много, творчеством в основном должны заниматься бизнес-аналитики и архитектор.
Искусство и творчество — понятия очень широкие. Создать стройную систему — искусство. Написать шмат говнокода — тоже в каком-то смысле искусство… только уже ближе к области экспрессионизма в программировании.
Само по себе создание чего-то — творчество. Что же до конечного результата… проектируя систему, вы правда всегда себе представляете результат проектирования? Если действительно представляете, значит уже спроектировали, тем самым совершив акт творения.
Есть два крайних значения, когда в голове представления результата нет, и когда он уже есть. Переход — это и есть творчество. В первом случае нет ни ТЗ, ни документации. Во втором мы имеем идеальное ТЗ, которое целиком описывает систему, или же имеем саму систему, так как лишь готовая система может выступать в роли идеального ТЗ.
И до тех пор, пока мы не достигли этой второй точки, мы будем заниматься творчеством. Другое дело, что у джуниоров его не должно быть много, творчеством в основном должны заниматься бизнес-аналитики и архитектор.
фраза Стива Макконнелла — «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте»Мне это напомнило кадр из манги Асано Инио «Девочка у моря»:
![[кадр из манги]](https://habrastorage.org/getpro/habr/comment_images/030/47b/734/03047b7348f6d6d970311162aa9a3c35.jpg)
Программист — исключительно творческая профессия.
А вот херовый код не оправдывается никакой тягой к творчеству, равно как и не имеет к нему отношения.
А вот херовый код не оправдывается никакой тягой к творчеству, равно как и не имеет к нему отношения.
не в курсе как и где, но в наших краях в дипломах пишут «инженер-программист». этим всё сказано. да, есть место для выражения себя, есть место для творчества. но в целом — это техническая работа с небольшим уклоном нк своеобразному творчеству и на первом месте должен стоять инженер, который видит последствия каждого решения как в контексте исправления бага, так и в контексте будущего всего проекта и его архитектуры, который может что-то именно начертить, спроектировать и разработать а не взять холст и намазюкать чтоб было интересно. безусловно — соревнования на самый запутанный код на С или гигабайты текстур, которые генерируются 10-килобайтной программой на ассемблере — это намного ближе к творчеству, но в основе всё равно лежат инженерные решения.
Ответьте, положа руку на сердце — вы представляете все последствия исправления бага? Вы представляете все последствия того или иного технического решения некоторой задачи?
Инженер — не робот. Инженер это человек, обладающий способностью/умением высококачественного творения, в котором учитывается множество различных деталей. Ещё раз повторюсь — инженер это тот же учёный-творец, только поле зачастую сужено определённой специальностью и предполагается мощная само-ответственность.
Инженер — не робот. Инженер это человек, обладающий способностью/умением высококачественного творения, в котором учитывается множество различных деталей. Ещё раз повторюсь — инженер это тот же учёный-творец, только поле зачастую сужено определённой специальностью и предполагается мощная само-ответственность.
само собой, что это учёный-творец. но даже в вашем высказывании слово «ученый» на первом месте. имея математический склад ума (а также время, но это не по теме) вы можете выучить и понять любой язык программирования и сможете творить на нем что вам будет угодно или что от вас потребуют.
имея какой-то творческий/художественный (как правильно-то, а?) склад ума вы можете застрять еще на адресации памяти и на понятии функции. и всё. художник остался художником.
разумеется, что оба примера за уши притянуты и слишком абстрактны и не бывает в чистом виде математического склада ума, как почти ничего не бывает в чистом виде, но я просто хочу показать, что программирование — это в основе своей инженерный процесс, который не лишен (и не должен быть лишен) элемента творчества, без которого вообще никуда.
имея какой-то творческий/художественный (как правильно-то, а?) склад ума вы можете застрять еще на адресации памяти и на понятии функции. и всё. художник остался художником.
разумеется, что оба примера за уши притянуты и слишком абстрактны и не бывает в чистом виде математического склада ума, как почти ничего не бывает в чистом виде, но я просто хочу показать, что программирование — это в основе своей инженерный процесс, который не лишен (и не должен быть лишен) элемента творчества, без которого вообще никуда.
Адово Вас плюсую, Вы ловите самую суть! Программист — это инженер, и этим всё сказано — золотые слова!
Не широковато взяли? Программирование весьма широкое понятие, в сайтостроении, возможно, уникальных задач не так много, однако если отойти чуть в сторону, в программировании мобильных приложений, драйверов, нагруженных систем и т.п., как только появляется куча ограничений или приходится иметь дело с большими объемами и/или вчислительной сложностью, стандартные решения перестают работать и приходится выбирать и дорабатывать более экзотические алгоритмы и структуры, если не придумывать свои, а это уже совсем не рутина и не всякому по зубам.
UFO just landed and posted this here
Дело в том, что некоторые считают, что творчество — это разгильдяйство.
Словами «я творческая личность» они оправдывают опоздание на 3 часа и свою лень убраться в комнате. Словами «мне не нужны бумажки, я пойду туда, куда меня понесёт ветер» они отказываются что-либо формализовывать (тот же список продуктов) и делают много лишнего, не делая необходимого.
А на самом деле, творчество, с моей точки зрения, — это умение мыслить широко, выходя за рамки предложенного. Более точные определения уже обсуждались выше.
Так что вашу статью я бы переформулировал так: «не стоит быть разгильдяем». К.О.? :)
Словами «я творческая личность» они оправдывают опоздание на 3 часа и свою лень убраться в комнате. Словами «мне не нужны бумажки, я пойду туда, куда меня понесёт ветер» они отказываются что-либо формализовывать (тот же список продуктов) и делают много лишнего, не делая необходимого.
А на самом деле, творчество, с моей точки зрения, — это умение мыслить широко, выходя за рамки предложенного. Более точные определения уже обсуждались выше.
Так что вашу статью я бы переформулировал так: «не стоит быть разгильдяем». К.О.? :)
Некоторые музыканты играют произведения по нотам. НОТАМ! вы представляете?!!! Это не означает, что профессия музыканта нетворческая.
Так и в программировании/разработке необходимость придерживаться стандартов не означает отсутствия творчества.
Кроме того, забивать гвозди тоже определенное искусство.
Так и в программировании/разработке необходимость придерживаться стандартов не означает отсутствия творчества.
Кроме того, забивать гвозди тоже определенное искусство.
Хорошее сравнение, спасибо. Грамотно примененные правила построения музыки гарантируют, что слушатель не взвизгнет, например, при разрешении септаккорда в неустойчивую форму, но не гарантируют, что произведение будет приятно на слух. Грамотно же примененные правила построения программ, написания тестов и пр. как раз гарантируют, что программа будет жизнеспособной.
Да ничего они не гарантируют, в том то и проблема. Правила на то и правила, чтобы из них были исключения. А в мире разработки софта исключений — уйма.
Вы и вправду слишком широко взяли. То, что у вас задачи сводятся к поддержке существующей базы кода, и есть тот ограничивающий фактор, который не дает «кодеру» быть «разработчиком».
Но ваша ситуация, хоть и типична, не является настолько распространенной, чтобы стать правилом. Есть множество огромных других рынков, где выпуск нового — единственный шанс остаться на плаву. И там наоборот нет места механическому соблюдению правил и стандартов.
Увидел, что вы пишете на C/C++. Мне кажется, что если бы вашему коллеге дали задание построить какую-то нестандартную систему с нуля в виде прототипа, используя более высокоуровневые средства (Java, .NET — все, что эффективно скрывает детали реализации и не дает правому полушарию утонуть в омуте микрооптимизаций) — он бы оказался «в более своей» тарелке.
Вы и вправду слишком широко взяли. То, что у вас задачи сводятся к поддержке существующей базы кода, и есть тот ограничивающий фактор, который не дает «кодеру» быть «разработчиком».
Но ваша ситуация, хоть и типична, не является настолько распространенной, чтобы стать правилом. Есть множество огромных других рынков, где выпуск нового — единственный шанс остаться на плаву. И там наоборот нет места механическому соблюдению правил и стандартов.
Увидел, что вы пишете на C/C++. Мне кажется, что если бы вашему коллеге дали задание построить какую-то нестандартную систему с нуля в виде прототипа, используя более высокоуровневые средства (Java, .NET — все, что эффективно скрывает детали реализации и не дает правому полушарию утонуть в омуте микрооптимизаций) — он бы оказался «в более своей» тарелке.
Нет, задачи не сводятся только к поддержке кода — регулярно пишем новое, но со старыми результатами. Как вы и сказали, чтоб остаться на плаву нам приходится быть актуальными, и плюс к этому тащить груз прошлых проектов.
Попробовать высокоуровневые средства было бы любопытно, но мне кажется что дело не в них, а в привычном подходе к разработке. Ведь, окидывая взглядом ситуацию, такой подход кто-то может считать не таким уж и плохим, раз он позволил людям в течение длительного времени быть востребованными в условиях текущей нагрузки.
Попробовать высокоуровневые средства было бы любопытно, но мне кажется что дело не в них, а в привычном подходе к разработке. Ведь, окидывая взглядом ситуацию, такой подход кто-то может считать не таким уж и плохим, раз он позволил людям в течение длительного времени быть востребованными в условиях текущей нагрузки.
Просто каждый подход должен применяться к подходящей задаче. Мой взгляд на описываемую вами ситуацию: человек занимается не тем, чем он хочет/умеет заниматься. Возможно, что я ошибаюсь, конечно.
По поводу средств: могу сказать лишь одно — будучи тем самым «творчески-ориентированным» человеком, когда мне приходится писать на C/C++, я почти физически ощущаю, как начинаю тонуть в ненужных мне возможностях, вроде «а вот этот метод у нас будет возвращать ссылку или указатель? а константный ли он? а нужен ли мне сеттер на данное свойство?», и из-за этого теряют контроль и видение системы в целом. Это буквально бесит и сводит с ума.
По поводу средств: могу сказать лишь одно — будучи тем самым «творчески-ориентированным» человеком, когда мне приходится писать на C/C++, я почти физически ощущаю, как начинаю тонуть в ненужных мне возможностях, вроде «а вот этот метод у нас будет возвращать ссылку или указатель? а константный ли он? а нужен ли мне сеттер на данное свойство?», и из-за этого теряют контроль и видение системы в целом. Это буквально бесит и сводит с ума.
>регулярно пишем новое, но со старыми результатами.
А применили бы творческий подход, глядишь результаты станут другими
А применили бы творческий подход, глядишь результаты станут другими
Совершенно не могу согласиться с точкой зрения автора…
Программирование — это искусство.
Это творческий полёт мысли, во время которого идёт процесс материализации твоей идеи в виде кода. И никак иначе. Тогда бы и архитекторов творцами называть нельзя было. Конечно, всегда есть люди проектирующие гаражи или рисующие интерфейсы к базам данных, они востребованы, так и должно быть. Но из этого не следует, что архитектор или программист не творческий человек. Программирование же отличается от всего остального ещё и тем, что нет универсальных алгоритмов и чётких схем для решения не самых банальных задач.
Или бот для AI Challenge — это не искусство? Или программа собирающая кубик-рубика тоже не искусство? И ещё — мне бы хотелось узнать на чём программирует автор данной статьи (pascal или PHP программированием не считаю)
Программирование — это искусство.
Это творческий полёт мысли, во время которого идёт процесс материализации твоей идеи в виде кода. И никак иначе. Тогда бы и архитекторов творцами называть нельзя было. Конечно, всегда есть люди проектирующие гаражи или рисующие интерфейсы к базам данных, они востребованы, так и должно быть. Но из этого не следует, что архитектор или программист не творческий человек. Программирование же отличается от всего остального ещё и тем, что нет универсальных алгоритмов и чётких схем для решения не самых банальных задач.
Или бот для AI Challenge — это не искусство? Или программа собирающая кубик-рубика тоже не искусство? И ещё — мне бы хотелось узнать на чём программирует автор данной статьи (pascal или PHP программированием не считаю)
В комментариях выше я оговорился, что спортивное программирование и изобретательство несколько выбиваются из общей концепции, это правда.
99% времени автор пишет на C/C++.
99% времени автор пишет на C/C++.
А зря не считаете, люди такие шедевры на этих языках порой выдают… В свою очередь и на C и на C++ полно говнокода…
pascal или PHP программированием не считаю
О боже, еще один кулхацкер, чем вам хоть паскаль не угодил — процедурный, компилируемый язык, ассемблерные вставки есть, очень прост для начинающих. При должной прямоте рук можно зделать много хорошего.
О боже, еще один кулхацкер, чем вам хоть паскаль не угодил — процедурный, компилируемый язык, ассемблерные вставки есть, очень прост для начинающих. При должной прямоте рук можно зделать много хорошего.
Меня эстетически не удовлетворяет вид программы, написанной на паскале.
Я ничего против Paskal не имею, но вы, надеюсь, сами понимаете, что сейчас это в основном учебный язык. Я не вижу где его сейчас используют в реальной разработке (если не прав, поправьте, но даже если такие случае есть, то это редкость).
Вы ни разу не чувствовали эстетического удовлетворения от процесса написания красивой программы?
В пирамиде Маслоу есть интересных уровня (в других интерпретациях это 2 отдельных столбика по краям пирамиды) — стремление к систематизации, упорядочиванию и стремление к исследованию. Оба этих стремления находят выход в программировании и приносят эстетическое удовольствие, но при этом не являются средствами самоактуализации.
А вот Леонардо да Винчи был творцом или инженером?
Думаю, что такой жестокий флейм разгорелся из-за путаницы в терминах. Для кого-то «творец» это синоним художника-абстракциониста. Для такой точки зрения, действительно, программирование — не творчество.
Для других — программист это такой винтик энтерпрайзной корпорации, который целыми днями собирает готовые модули по алгоритму, который написал кто-то другой.
Но если «зрить в корень», то творец происходит от слова «творить». То есть «творчество» это создание чего-то нового, чего раньше ещё никто не делал. И тот кто в своей отрасли может отойти от шаблонных действий, внести что-то новое, что _улучшает_ и _изменяет_ продукт имеет полное право называться творцом.
Думаю, что такой жестокий флейм разгорелся из-за путаницы в терминах. Для кого-то «творец» это синоним художника-абстракциониста. Для такой точки зрения, действительно, программирование — не творчество.
Для других — программист это такой винтик энтерпрайзной корпорации, который целыми днями собирает готовые модули по алгоритму, который написал кто-то другой.
Но если «зрить в корень», то творец происходит от слова «творить». То есть «творчество» это создание чего-то нового, чего раньше ещё никто не делал. И тот кто в своей отрасли может отойти от шаблонных действий, внести что-то новое, что _улучшает_ и _изменяет_ продукт имеет полное право называться творцом.
Когда я вижу статью пр искусство программирования, первый вопрос, который меня интересует — кто ее написал. И когда я вижу что это скажем Макконелл, Фаулер, <Подставь своего любимого признанного писателя, который пишет код over 20 лет>, я думаю ОК, надо задуматься.
Но когда про автора известно, только что он Сергей из Питера, который работает в конторе, в которой вообще не слышали ничего о процессе разработки ПО и его этапов, возникает резонный вопрос, а стоит ли вообще верить словам автора? Неужели, он такой умудренный опытом человек, который не только знает как надо, но и учит этому других, будет работать в такой гнилой конторе.
Ничего личного, просто хочется в таких статья хотя бы в сноске:
Я Сергей, бла бла бла, занимаюсь разработкой ПО N лет, когда вы еще все пешком под стол ходили, работал в таких компаниях как N и M, но сейчас судьба нелегкая занесла вот в шарагу.
Хм… Резковато получилось, но смысл думаю понятен.
Но когда про автора известно, только что он Сергей из Питера, который работает в конторе, в которой вообще не слышали ничего о процессе разработки ПО и его этапов, возникает резонный вопрос, а стоит ли вообще верить словам автора? Неужели, он такой умудренный опытом человек, который не только знает как надо, но и учит этому других, будет работать в такой гнилой конторе.
Ничего личного, просто хочется в таких статья хотя бы в сноске:
Я Сергей, бла бла бла, занимаюсь разработкой ПО N лет, когда вы еще все пешком под стол ходили, работал в таких компаниях как N и M, но сейчас судьба нелегкая занесла вот в шарагу.
Хм… Резковато получилось, но смысл думаю понятен.
Я вот сейчас проверю одну теорию. Попробую возразить человеку с кучей красивых бейджиков и высокой кармой и посмотрю что из этого получится.
Есть у А.Азимова несколько рассказов: «Ловушка для простаков», «Профессия». Это из тех что я перечитывал недавно.
Там рассматривается как раз подобная ситуация, доведённая до абсурда, где на мнение человека без «корочек» не рассматривается, а мнение «профессионала» принимается как истина и не подлежит обсуждению.
Мой странный жизненный опыт показывает, что не стоит сбрасывать со счетов мнение человека, только потому, что он «не авторитет».
Есть у А.Азимова несколько рассказов: «Ловушка для простаков», «Профессия». Это из тех что я перечитывал недавно.
Там рассматривается как раз подобная ситуация, доведённая до абсурда, где на мнение человека без «корочек» не рассматривается, а мнение «профессионала» принимается как истина и не подлежит обсуждению.
Мой странный жизненный опыт показывает, что не стоит сбрасывать со счетов мнение человека, только потому, что он «не авторитет».
Никто не сбрасывает мнение человека, равно как глупо смотреть на мою кучу бейджиков (кстати спасибо что напомнили, пойду еще один добавлю :) ) — это всего лишь картинки.
Речь о том как это мнение оформлено — когда кто-то преподносит СВОЕ мнение как прописную истину, прямо таки подмывает спросить, а кто ты, чтобы мы тебе поверили? Когда человек, говорит именно о своем мнении, это просто повод для хорошей интеллектуальной дискуссии.
Сравните:
«Программирование — это не выражение себя, что бы ни утверждали романтически настроенные джуниоры. „
и
“По моему мнению, Программирование — это не выражение себя — всё подчинено чёткой логике и имеет максимальную эффективность»
Речь о том как это мнение оформлено — когда кто-то преподносит СВОЕ мнение как прописную истину, прямо таки подмывает спросить, а кто ты, чтобы мы тебе поверили? Когда человек, говорит именно о своем мнении, это просто повод для хорошей интеллектуальной дискуссии.
Сравните:
«Программирование — это не выражение себя, что бы ни утверждали романтически настроенные джуниоры. „
и
“По моему мнению, Программирование — это не выражение себя — всё подчинено чёткой логике и имеет максимальную эффективность»
Сам формат поста/статьи подразумевает, по-моему :), что автор излагает своё мнение и своё видение проблемы. Иногда автор может это подчеркнуть, но вовсе не обязан. Обязан, скорее, подчеркнуть именно в том случае, если действительно считает своё мнение истиной в последней инстанции. Нет таких акцентов, сомнительных риторических приемов типа «общеизвестно» или «не вызывает сомнения» или ссылок на авторитетов — это лишь личное мнение по умолчанию.
Хехе, прекрасно вас понимаю.
Никому не собираюсь ничего доказывать и пыжиться, пытаясь набрать вес в обществе, это — всего лишь статья, которая не претендует ни на гениальность, ни на абсолютную истинность излагаемых в ней идей.
Мне приятно, что к ней столько комментариев. Это значит, что тема интересна, и что идея статьи побудила людей высказать своё отношение к затрагиваемому вопросу, о чем то подумать, придти к какому-то выводу для себя, быть может скорректировать что-то. Цель достигнута.
P.S. И всё же, если интересно:
Я Сергей, разработчик ПО, имею два высших образования, участвовал в старте и развитии нескольких (~10) относительно немаленьких проектов, в основном в связках со специфическим оборудованием. Имею опыт тимлида в команде из четырех разработчиков, небольшой, около года, но вполне боевой. Текущее положение дел в плане трудовой деятельности относительно устраивает (хоть и хочется временами в тимлиды вернуться) поэтому я плодотворно и добросовестно работаю и раз в полгода пишу небольшие статьи.
Никому не собираюсь ничего доказывать и пыжиться, пытаясь набрать вес в обществе, это — всего лишь статья, которая не претендует ни на гениальность, ни на абсолютную истинность излагаемых в ней идей.
Мне приятно, что к ней столько комментариев. Это значит, что тема интересна, и что идея статьи побудила людей высказать своё отношение к затрагиваемому вопросу, о чем то подумать, придти к какому-то выводу для себя, быть может скорректировать что-то. Цель достигнута.
P.S. И всё же, если интересно:
Я Сергей, разработчик ПО, имею два высших образования, участвовал в старте и развитии нескольких (~10) относительно немаленьких проектов, в основном в связках со специфическим оборудованием. Имею опыт тимлида в команде из четырех разработчиков, небольшой, около года, но вполне боевой. Текущее положение дел в плане трудовой деятельности относительно устраивает (хоть и хочется временами в тимлиды вернуться) поэтому я плодотворно и добросовестно работаю и раз в полгода пишу небольшие статьи.
Разве в статье есть что-то, чему нужно верить?
Текст чёткий и понятный, автор рассказал о своём опыте и сделал свои выводы. Не надо этому верить. Надо почитать и подумать. Вне зависимости от того, кто это написал.
Текст чёткий и понятный, автор рассказал о своём опыте и сделал свои выводы. Не надо этому верить. Надо почитать и подумать. Вне зависимости от того, кто это написал.
Не буду оригинальным. Источник тот самый.
Пройдусь по утверждениям:
1) Разве не созданием чего-то нового занимается программист? Если нет и все решения уже созданы, тогда за что эти люди получают деньги?
2) Обратно. Не творческая профессия? Тогда почему результат работы программиста относительно не плохо оплачивается.
3) Для моей мамы, все что я делаю — пустой звук. Для моих заказчиков, как правило, важная часть их бизнеса. Компьютерная программа — субъективная ценность, которой нет равных в отношении субъективности.
Личное мнение: Всякая профессиональная деятельность всегда имеет творческий компонент.
Клево, чё…
Творчество — деятельность, порождающая нечто качественно новое, никогда ранее не существовавшее.
Творчество — это создание чего-то нового, ценного не только для данного человека, но и для других. Творчество — процесс создания субъективных ценностей.
Пройдусь по утверждениям:
1) Разве не созданием чего-то нового занимается программист? Если нет и все решения уже созданы, тогда за что эти люди получают деньги?
2) Обратно. Не творческая профессия? Тогда почему результат работы программиста относительно не плохо оплачивается.
3) Для моей мамы, все что я делаю — пустой звук. Для моих заказчиков, как правило, важная часть их бизнеса. Компьютерная программа — субъективная ценность, которой нет равных в отношении субъективности.
Личное мнение: Всякая профессиональная деятельность всегда имеет творческий компонент.
Программист — это робот, который ...
Клево, чё…
Мой дедушка был шахтером.
Казалось бы — стой себе в штольне и молоти уголь отбойным молотком. Стандарты все придуманы. Че тут можно выдумать. Какое творчество? Стена угля и отбойник. Негде мысли разгуляться.
Только он делал 2 обычных нормы и получал зп больше товарищей. За счет того, что он нашел способ выбивать пласты угля по особой схеме.
Шахтер это тоже робот, который… ?!
Казалось бы — стой себе в штольне и молоти уголь отбойным молотком. Стандарты все придуманы. Че тут можно выдумать. Какое творчество? Стена угля и отбойник. Негде мысли разгуляться.
Только он делал 2 обычных нормы и получал зп больше товарищей. За счет того, что он нашел способ выбивать пласты угля по особой схеме.
Шахтер это тоже робот, который… ?!
Я бы не стал приравнивать проявления житейской мудрости и смекалки к искусству и творчеству.
напрасно
Много дней я ходил до метро по большой широкой улице, и тратил на дорогу 20 минут. Однажды, по пути зайдя в магазин, я увидел проход дворами, который раньше не замечал, и решил пойти по нему. Теперь я трачу на дорогу 10 минут, поскольку путь оказался короче. Я совершил акт творчества? Тут есть искусство? Принципиальное отличие от ситуации с добычей угля?
Принципиальная разница есть. Случай vs. Осознанное стремление и поиск наилучшего варианта действий для решения задачи.
Если процесс осмысления в результате опытной деятельности повлиял на изменение ваших представлений о картине мира — то да — акт творчества был.
Меня в школе учили, что искусство (в некотором приближении) — это творчество + культурное наследие. Тут я точно не компетентен. Но, кажется, в ранг искусства возводить вашу когнитивную деятельность не стоит.
В университете меня учили, что важнейшим показателем успешного эксперимента (процесса подтверждения мнимой-творческой картины окружающей реальности) является его повторяемость. Вот если бы вы так и продолжили ходить старым путем — то да. Робот он и есть робот — бессознательная машина исполняющая программу.
И то! Роботы сейчас уже самообучаются.
И вообще. Извините, я сейчас пью вино и просто тупо хочу похоливарить. Несомненно вы затронули некоторые интересные темы. Спасибо за интересный диалог.
Если процесс осмысления в результате опытной деятельности повлиял на изменение ваших представлений о картине мира — то да — акт творчества был.
Меня в школе учили, что искусство (в некотором приближении) — это творчество + культурное наследие. Тут я точно не компетентен. Но, кажется, в ранг искусства возводить вашу когнитивную деятельность не стоит.
В университете меня учили, что важнейшим показателем успешного эксперимента (процесса подтверждения мнимой-творческой картины окружающей реальности) является его повторяемость. Вот если бы вы так и продолжили ходить старым путем — то да. Робот он и есть робот — бессознательная машина исполняющая программу.
И то! Роботы сейчас уже самообучаются.
И вообще. Извините, я сейчас пью вино и просто тупо хочу похоливарить. Несомненно вы затронули некоторые интересные темы. Спасибо за интересный диалог.
Хороший код — это чётко оформленный и построенный по определённым правилам документ.
«Хорошая музыка — это гармония поверенная алгеброй» — Сальери.
Вопрос в том, что большинство программистов работают не композиторами и даже не музыкантами. Они работают таперами. Поэтому ваша логика находит подтверждение. А так программирование — искусство способное приносить интеллектуальное наслаждение. И код написанный по шаблону может быть «хорошим» но ни как не «гениальным» НО деньги платят не за интеллектуальное удовольствие.
«Хорошая музыка — это гармония поверенная алгеброй» — Сальери.
Вопрос в том, что большинство программистов работают не композиторами и даже не музыкантами. Они работают таперами. Поэтому ваша логика находит подтверждение. А так программирование — искусство способное приносить интеллектуальное наслаждение. И код написанный по шаблону может быть «хорошим» но ни как не «гениальным» НО деньги платят не за интеллектуальное удовольствие.
Внесу свое ИМХО:
Ну, если у Вас на фирме программисты — роботы — это конечно хорошо — Вы получаете четкий стандартный код и всегда можете точно спрогнозировать сроки — круто!
Но есть одно но — я считаю, что не стоит путать ПРОГРАММИСТА и КОДЕРА, это разные, абсолютно разные веши — примерно как художник и копировальный аппарат :-D
Так вот про кодеров Все что Вы написали — абсолютная правда, а программист — это гораздо больше. Это Кодер + Творчество как раз.
Плохо это или хорошо — не знаю. Можно быть хорошим кодером — и это хорошо, но, ИМХО, грустно :-D
Ну, если у Вас на фирме программисты — роботы — это конечно хорошо — Вы получаете четкий стандартный код и всегда можете точно спрогнозировать сроки — круто!
Но есть одно но — я считаю, что не стоит путать ПРОГРАММИСТА и КОДЕРА, это разные, абсолютно разные веши — примерно как художник и копировальный аппарат :-D
Так вот про кодеров Все что Вы написали — абсолютная правда, а программист — это гораздо больше. Это Кодер + Творчество как раз.
Плохо это или хорошо — не знаю. Можно быть хорошим кодером — и это хорошо, но, ИМХО, грустно :-D
Термины, в которых вы описываете ситуацию, не позволяют её описать.
Творческий подход в программировании — критически важен. Ровно так же важна и архитектура.
Творческий подход в программировании — критически важен. Ровно так же важна и архитектура.
Вообще-то это старый древний спор. И ответ уже найден, примерно в 90-е года прошлого века.
Программист — это инженер. А инженер — это творческая специальность по определению. Только
специальность эта особая. Творчество инженера ограничивается стандартами и соглашениями, законами физики и т.д.
Судя по описаниям автор работает в компании, в которой мало кто думает
над выработкой стандартов и соглашений, поэтому ограничений мало и все творят кто как может и умеет. Есть и другие команды. В них ограничений столько, что даже хреновый кодер не сможет сильно накосячить.
Что касается программиста-робота, то это тоже уже «проехали». Это несбывшаяся мечта создателей CASE. Я лично наблюдал программы сгенерированные кодогенератором CASE. Они были логичны и наверное эффективны… однако пользователи с ними мучились и проклинали того, кто это написал.
Им конечно не говорили, что это не «кто-то», а «что-то». Все заканчивалась тем, что программеры садились и все это хозяйство допиливали.
Программист — это инженер. А инженер — это творческая специальность по определению. Только
специальность эта особая. Творчество инженера ограничивается стандартами и соглашениями, законами физики и т.д.
Судя по описаниям автор работает в компании, в которой мало кто думает
над выработкой стандартов и соглашений, поэтому ограничений мало и все творят кто как может и умеет. Есть и другие команды. В них ограничений столько, что даже хреновый кодер не сможет сильно накосячить.
Что касается программиста-робота, то это тоже уже «проехали». Это несбывшаяся мечта создателей CASE. Я лично наблюдал программы сгенерированные кодогенератором CASE. Они были логичны и наверное эффективны… однако пользователи с ними мучились и проклинали того, кто это написал.
Им конечно не говорили, что это не «кто-то», а «что-то». Все заканчивалась тем, что программеры садились и все это хозяйство допиливали.
> Есть и другие команды. В них ограничений столько, что даже хреновый кодер не сможет сильно накосячить.
Но не надо так же забывать, что чем больше внешних ограничений, тем менее продуктивен становится программист. Я знал команды, где чтобы хоть что-то сделать нужно было не нарушить ни одного пункта в 90-страничном coding guidelines. Любое элементарное изменение превращалось в тягомотину на неделю с непрекращающимися вмешательствами со всех сторон и предложениями типа: функция названа не в соответствии с guidelines, отступов не хватает, передавай параметры через указатели, вместо if(n>0) должно быть if(0<n), и тому подобные смехотворные замечания, которые убивают всякое желание сделать что-либо нужное.
Такая команда очень хорошо подходит для хренового кодера. Для профессионального программиста, который знает что делает, это просто убийство. Такие команды обычно ничего революционного не делают, а в лучшем случае поддерживают код который был написан не ими.
А революционные продукты пишутся так: небольшой косяк профессиональных программистов договариваются, что они пишут и по каким правилам (чисто условно, безо всякой волокиты и даже документации), делят большую задачу на части, после чего каждый свою часть делает практически независимо. Все друг другу доверяют, но команда все таки следует некоему легковестному процессу не обремененному бюрократией. Они за короткий срок пишут основной костяк продукта. Их продуктивность при этом превышает в десятки раз продуктивность нормальных программистов.
После того как костяк завершен, революция завершилась. Начинается эволюция, на проект набирается в 10 раз больше программистов, разрабатываются coding guidelines, coding reviews, design documents, architecture documents, и т.д. и т.п. Творчество вырывается с корнем. Людей в 10 раз больше, но проект движется в 10 раз медленнее. Все чем они теперь способны заниматься это поддержка и неторопливое введение небольших фич там и тут. Но написать еще один подобный продукт с нуля они не способны, даже если бы и хотели, потому что ограничениями и бюрократией они посадили самих себя в смирительную рубашку.
Во всех проектах, в которых я учавствовал, дело происходило именно таким образом. И хотя это не были стартапы, все характеристики стартапа были на лицо: мощный и короткий творческий всплеск, после которого следует долгое и медленное закостевание. Если ты видишь только процесс закостевания, то самый логичный вывод будет, что творчество вредит програмному продукту. Если же ты значешь как этот продукт начинался, то приходится признать, что творчество — это основной и необходимый фактор в успешности продукта.
Но не надо так же забывать, что чем больше внешних ограничений, тем менее продуктивен становится программист. Я знал команды, где чтобы хоть что-то сделать нужно было не нарушить ни одного пункта в 90-страничном coding guidelines. Любое элементарное изменение превращалось в тягомотину на неделю с непрекращающимися вмешательствами со всех сторон и предложениями типа: функция названа не в соответствии с guidelines, отступов не хватает, передавай параметры через указатели, вместо if(n>0) должно быть if(0<n), и тому подобные смехотворные замечания, которые убивают всякое желание сделать что-либо нужное.
Такая команда очень хорошо подходит для хренового кодера. Для профессионального программиста, который знает что делает, это просто убийство. Такие команды обычно ничего революционного не делают, а в лучшем случае поддерживают код который был написан не ими.
А революционные продукты пишутся так: небольшой косяк профессиональных программистов договариваются, что они пишут и по каким правилам (чисто условно, безо всякой волокиты и даже документации), делят большую задачу на части, после чего каждый свою часть делает практически независимо. Все друг другу доверяют, но команда все таки следует некоему легковестному процессу не обремененному бюрократией. Они за короткий срок пишут основной костяк продукта. Их продуктивность при этом превышает в десятки раз продуктивность нормальных программистов.
После того как костяк завершен, революция завершилась. Начинается эволюция, на проект набирается в 10 раз больше программистов, разрабатываются coding guidelines, coding reviews, design documents, architecture documents, и т.д. и т.п. Творчество вырывается с корнем. Людей в 10 раз больше, но проект движется в 10 раз медленнее. Все чем они теперь способны заниматься это поддержка и неторопливое введение небольших фич там и тут. Но написать еще один подобный продукт с нуля они не способны, даже если бы и хотели, потому что ограничениями и бюрократией они посадили самих себя в смирительную рубашку.
Во всех проектах, в которых я учавствовал, дело происходило именно таким образом. И хотя это не были стартапы, все характеристики стартапа были на лицо: мощный и короткий творческий всплеск, после которого следует долгое и медленное закостевание. Если ты видишь только процесс закостевания, то самый логичный вывод будет, что творчество вредит програмному продукту. Если же ты значешь как этот продукт начинался, то приходится признать, что творчество — это основной и необходимый фактор в успешности продукта.
Практически со всем согласен. Команды в которых ооочень много регламентирующих документов тоже видел и работать там мне не очень то и хочется.
Только хотел отметить, что когда профи собираются они, хоть и устно, но соглашения вырабатывают. Просто нормальным программисты друг друга понимают с полуслова, знают цену творчеству и умеют САМОограничиваться. Да и еще… профи хоть раз в своей жизни уже работали по этим нудным coding guidelines, coding reviews, design documents. И что-то оттуда уже почерпнули, даже если этого и не осознают.
Только хотел отметить, что когда профи собираются они, хоть и устно, но соглашения вырабатывают. Просто нормальным программисты друг друга понимают с полуслова, знают цену творчеству и умеют САМОограничиваться. Да и еще… профи хоть раз в своей жизни уже работали по этим нудным coding guidelines, coding reviews, design documents. И что-то оттуда уже почерпнули, даже если этого и не осознают.
Программист — это ремесленник. Такой же, как, к примеру плотник или резчик по дереву. Ведь фактически что отличает новичка, прослушавшего теоретические курсы и сдавшего практические занятия от матерого коллеги со стажем? Практика! Опытный программист, как бы ни пошло это звучало, уже «многое повидал» и грабли, вокруг которых новичок будет скакать несколько часов, заметит издали и обойдет.
Тут многие почему-то обособляют этап проектирования, утверждая, что это творческое по самые помидоры занятие. Грамотный (и опытный) архитектор при проектировании решений опирается на «опыт предыдущих поколений». Вместо построения красивой диаграмы классов, которая, будучи распечатанной на листе A3, введет в благоговейный треперт непосвященного, опытный архитектор озаботится составленией архитектуры с минимумом лишних сущностей и максимально приближенной к предметной области.
А презрительное упоминание «кодеров», которые, мол, макаки супротив «настоящего программиста» — несусветная чушь. Я лично считаю, что есть «быдлокодеры» и «опытные кодеры», более коротким синонимом для названия которых и является слово «программист».
Также кардинально не согласен с утверждением «программист — это робот». Ничего подобного! Робот строго следует заложенным в него инструкциям, к каким бы абсурдным результатом это следование не приводило. Программист же — это «естественный интеллект», решающий задачу «как при имеющихся инструментальных средствах решить ту или иную проблему».
Тут многие почему-то обособляют этап проектирования, утверждая, что это творческое по самые помидоры занятие. Грамотный (и опытный) архитектор при проектировании решений опирается на «опыт предыдущих поколений». Вместо построения красивой диаграмы классов, которая, будучи распечатанной на листе A3, введет в благоговейный треперт непосвященного, опытный архитектор озаботится составленией архитектуры с минимумом лишних сущностей и максимально приближенной к предметной области.
А презрительное упоминание «кодеров», которые, мол, макаки супротив «настоящего программиста» — несусветная чушь. Я лично считаю, что есть «быдлокодеры» и «опытные кодеры», более коротким синонимом для названия которых и является слово «программист».
Также кардинально не согласен с утверждением «программист — это робот». Ничего подобного! Робот строго следует заложенным в него инструкциям, к каким бы абсурдным результатом это следование не приводило. Программист же — это «естественный интеллект», решающий задачу «как при имеющихся инструментальных средствах решить ту или иную проблему».
Поскольку сентенция с роботом вызывает, судя по некоторым комментариям, недопонимание, пора бы пояснить.
Имелось ввиду следующее:
На каждом этапе написания программы — от объявления переменной до выбора паттерна — в рамках текущих условий по проекту имеется четко детерминированное решение (или набор равнозначно конкурирующих решений по сумме преимуществ и недостатков), которое следует применить.
Что имеется ввиду под рамками текущих условий — это регламенты написания кода, общий стиль проекта, квалификация программиста и прочие условия — эдакий срез ситуации. Остальные решения неоптимальны, выбиваются из регламентов, не соответствуют уровню кода, потенциально опасны, непереносимы и пр.
Алгоритмизации это не касается.
Имелось ввиду следующее:
На каждом этапе написания программы — от объявления переменной до выбора паттерна — в рамках текущих условий по проекту имеется четко детерминированное решение (или набор равнозначно конкурирующих решений по сумме преимуществ и недостатков), которое следует применить.
Что имеется ввиду под рамками текущих условий — это регламенты написания кода, общий стиль проекта, квалификация программиста и прочие условия — эдакий срез ситуации. Остальные решения неоптимальны, выбиваются из регламентов, не соответствуют уровню кода, потенциально опасны, непереносимы и пр.
Алгоритмизации это не касается.
Для меня «творчество» что то сродни интуитивного создания кода — выбор решения, возможно локально не самого оптимального, в условиях недостатка информации, но такого которое целом продукте/после n-дцати лет развития/после 10^m-ного переписывания ТЗ окажется более выгодным чем оказались бы другие.
Творчество это попытка найти решение не то которое на поверхности, а другое, не очевидное. То про которое не написал еще Кнут. Многие пытаются, мало кто находит, но те кто находят становятся Гейтсами, Фаулерами, Кнуттами.
Ну нет в программировании места роботам. Сгенерить из UML код можно, только он так себе получиться.
А все эти «доказательства 90х» годов и ведут к тому что банальному текстовому notepad 00-х годов ресурсов надо как хорошей такой игрухе 90-х.
Творчество это попытка найти решение не то которое на поверхности, а другое, не очевидное. То про которое не написал еще Кнут. Многие пытаются, мало кто находит, но те кто находят становятся Гейтсами, Фаулерами, Кнуттами.
Ну нет в программировании места роботам. Сгенерить из UML код можно, только он так себе получиться.
А все эти «доказательства 90х» годов и ведут к тому что банальному текстовому notepad 00-х годов ресурсов надо как хорошей такой игрухе 90-х.
имеется четко детерминированное решение (или набор равнозначно конкурирующих решений по сумме преимуществ и недостатков), которое следует применить.
…
Остальные решения неоптимальны, выбиваются из регламентов, не соответствуют уровню кода, потенциально опасны, непереносимы и пр.
Вы хотите перейти через дорогу и делаете это по некоторым существующим стандартам. Другие способы перейти дорогу могут быть опасны, наказываться законодательно и т.д.
Вы хотите купить что-то магазине и действуете по стандартному алгоритму. Попытка обойти алгоритм — например, взять товар и не заплатить деньги — может быть опасна т. д.
Множество решений в жизни Вы принимаете в рамках некоторых условий, ограничивающих выбор до «четко детерминированное решение (или набор равнозначно конкурирующих решений по сумме преимуществ и недостатков)». Остальные решения неоптимальны, выбиваются из регламентов, потенциально опасны, и пр.
Вы робот?
Давайте условимся о некоторых вещах, прежде чем конструктивно продолжить беседу.
Будем считать, что оптимальность — это совокупность «кушать-не-болеть-размножаться-самореализовываться». Соответственно робот выбирал бы единственное решение из набора равнозначно конкурирующих. И таки да, люди часто так и поступают, например, алгоритм «работа-дом-семья».
Но этим жизнь не ограничивается. Я могу полночи проиграть в новую игру, а потом с ущербом для организма и в противоречии с оптимальностью, о которой мы условились, не выспаться и идти трудиться.
Я могу купить новую железяку, которая меня не накормит, от болезней не избавит, секса (ну, по крайней мере, в ортодоксальном смысле) не принесет, и самореализацией это не назовешь. А потом полмесяца плохо кушать.
Это примеры примитивные и на поверхности, но, думаю, мысль понятна.
Вряд ли найдется человек, который всегда принимает оптимальное решение (относительно его понятия оптимальности).
Будем считать, что оптимальность — это совокупность «кушать-не-болеть-размножаться-самореализовываться». Соответственно робот выбирал бы единственное решение из набора равнозначно конкурирующих. И таки да, люди часто так и поступают, например, алгоритм «работа-дом-семья».
Но этим жизнь не ограничивается. Я могу полночи проиграть в новую игру, а потом с ущербом для организма и в противоречии с оптимальностью, о которой мы условились, не выспаться и идти трудиться.
Я могу купить новую железяку, которая меня не накормит, от болезней не избавит, секса (ну, по крайней мере, в ортодоксальном смысле) не принесет, и самореализацией это не назовешь. А потом полмесяца плохо кушать.
Это примеры примитивные и на поверхности, но, думаю, мысль понятна.
Вряд ли найдется человек, который всегда принимает оптимальное решение (относительно его понятия оптимальности).
Искренне рекомендую автору не разбрасываться терминами «творчество» и «робот», а прочитать «Может ли машина мыслить?» Тьюринга. В частности, «возражение леди Лавлейс»:
"… на одном заблуждении, которому в особенности подвержены математики и философы. Я имею в виду предположение о том, что коль скоро какой-то факт стал достоянием разума, тотчас же достоянием разума становятся все следствия из этого факта. Во многих случаях это предположение может быть весьма полезно, но слишком часто забывают, что оно ложно. Естественным следствием из него является взгляд, что якобы нет ничего особенного в умении выводить следствия из имеющихся данных, руководствуясь общими принципами."
/перевод издательства Физико-математической литературы, 1960г./
В связи с вышеизложенным: либо творческие личности, о которых автор говорит — те ещё роботы и весьма просто алгоритмизируются, либо — совсем не так просто создать «робота-программиста».
Мне ближе второй вариант.
"… на одном заблуждении, которому в особенности подвержены математики и философы. Я имею в виду предположение о том, что коль скоро какой-то факт стал достоянием разума, тотчас же достоянием разума становятся все следствия из этого факта. Во многих случаях это предположение может быть весьма полезно, но слишком часто забывают, что оно ложно. Естественным следствием из него является взгляд, что якобы нет ничего особенного в умении выводить следствия из имеющихся данных, руководствуясь общими принципами."
/перевод издательства Физико-математической литературы, 1960г./
В связи с вышеизложенным: либо творческие личности, о которых автор говорит — те ещё роботы и весьма просто алгоритмизируются, либо — совсем не так просто создать «робота-программиста».
Мне ближе второй вариант.
Программист — это человек, который решает задачу. Я бы не уходил в сторону от этого к творчеству или рутине. Суть же в эффективности. Чтобы в один момент быть эффективнее нужно придумать что-то новое, а в другой момент попридержать лошадей и делать рутинную работу.
Творчество ради творчества — это в литературе.
Творчество ради творчества — это в литературе.
При любой творческой деятельности следует включать мозги.
Программист, очень творческая профессия, очень напоминающая изобразительное искусство. А, простите, чтобы написать хорошую картину, надо не только быть творческим, надо еще сконцентрироваться и ответственно подойти к своей работе.
Так и в коде, можно наляпать тяп-ляп, протестировать по принципу «включил, вроде, работает», навязать веревочек и запихнуть в общий проект и потом всем коллективом расхлебывать результаты этого «творчества», а можно написать нормальный полноценный автономный модуль, с хорошо форматированным кодом и понятными именами, за который будет не стыдно.
При этом второй подход будет в сотню раз более творческий, чем первый. А первый подход, это, простите, пофигизм и безответственность.
Программист, очень творческая профессия, очень напоминающая изобразительное искусство. А, простите, чтобы написать хорошую картину, надо не только быть творческим, надо еще сконцентрироваться и ответственно подойти к своей работе.
Так и в коде, можно наляпать тяп-ляп, протестировать по принципу «включил, вроде, работает», навязать веревочек и запихнуть в общий проект и потом всем коллективом расхлебывать результаты этого «творчества», а можно написать нормальный полноценный автономный модуль, с хорошо форматированным кодом и понятными именами, за который будет не стыдно.
При этом второй подход будет в сотню раз более творческий, чем первый. А первый подход, это, простите, пофигизм и безответственность.
Бред. Одну и ту же задачу можно правильно решить бесчисленным числом способов. Неправильным — еще больше.
Программирование — это еще какое искусство. Если ваши программы строятся из одних лишь паттернов, то это конечно неплохо. Но паттерны — далеко не панацея. Настоящее искусство писать программы так, чтобы гармонично сочетать удобство разработки, масштабируемость, гибкость и производительность. А те умники, заучившие паттерны и игнорирующие творческую составляющую, обычно выполняют лишь 1-2 пункта из вышеперечисленных.
Программирование — это еще какое искусство. Если ваши программы строятся из одних лишь паттернов, то это конечно неплохо. Но паттерны — далеко не панацея. Настоящее искусство писать программы так, чтобы гармонично сочетать удобство разработки, масштабируемость, гибкость и производительность. А те умники, заучившие паттерны и игнорирующие творческую составляющую, обычно выполняют лишь 1-2 пункта из вышеперечисленных.
Программирование — это пока исскуство, но по той причине, что не изобретены (или повсеместно не внедрены) методы, позволяющие получать гарантировано ожидаемый результат. Как научимся, программирование станет инженерией. У Макконелла целая книжка про это есть.
Я где-то пример читал о том, что в 19-м веке половина построенных больших мостов разваливалось. И построение мостов каждый раз было исскуством. А теперь это уже инжененрия. Всё посчитали, организовали и вперёд.
Я где-то пример читал о том, что в 19-м веке половина построенных больших мостов разваливалось. И построение мостов каждый раз было исскуством. А теперь это уже инжененрия. Всё посчитали, организовали и вперёд.
Вы инженерию с ремеслом путаете. Инженер — это творческая профессия.
И современные мосты конструируются инженерами-конструкторами. И мосты то
все разные, а не одинаковые. А то, что они не падают, так это заслуга
механики. Мосты сегодня просто на прочность считают и ветровую нагрузку с
учетом собственной частоты колебаний, чтобы резонанса не было.
А конструкция современного моста, как и в 19 веке рождается в
творческих муках, а не муках от запора :)
И современные мосты конструируются инженерами-конструкторами. И мосты то
все разные, а не одинаковые. А то, что они не падают, так это заслуга
механики. Мосты сегодня просто на прочность считают и ветровую нагрузку с
учетом собственной частоты колебаний, чтобы резонанса не было.
А конструкция современного моста, как и в 19 веке рождается в
творческих муках, а не муках от запора :)
Статью я не читал, но осуждаю!
Разрешите не согласиться.
Сравнивая «творческих» людей и программистов забыли об одном:
Если «творческий» человек успешен, в хорошем смысле этого слова, то у него наверняка есть филигранная техника исполнения его работы, которая является очень кропотливой и требующая огромного количества человеко-часов.
То же самое читай у проф. программиста, соблюдения единообразия в подходах, code cov., в результате робастная функциональность.
Те программисты, которые упомянуты в статье и называют себя творческими личностями и лепят говнокод — просто разгельдяи, вот и всё.
Так что не важно куда сублимировать творчество в код или в музыку или живопись.
И там и там есть творчество и огромное количество черновой работы.
Сравнивая «творческих» людей и программистов забыли об одном:
Если «творческий» человек успешен, в хорошем смысле этого слова, то у него наверняка есть филигранная техника исполнения его работы, которая является очень кропотливой и требующая огромного количества человеко-часов.
То же самое читай у проф. программиста, соблюдения единообразия в подходах, code cov., в результате робастная функциональность.
Те программисты, которые упомянуты в статье и называют себя творческими личностями и лепят говнокод — просто разгельдяи, вот и всё.
Так что не важно куда сублимировать творчество в код или в музыку или живопись.
И там и там есть творчество и огромное количество черновой работы.
Есть один очень важный момент — не каждый работодатель/заказчик четко понимает, что такое программирование.
В итоге у нас программист очень часто должен делать «идею». Продумать интерфейс, спроектировать архитектуру, сверстать, нарисовать иконки и прочую лабуду.
При этом все так же должен оставаться «роботом».
В итоге у нас программист очень часто должен делать «идею». Продумать интерфейс, спроектировать архитектуру, сверстать, нарисовать иконки и прочую лабуду.
При этом все так же должен оставаться «роботом».
«программист — это робот, который, в зависимости от качества вложенных в него инструкций, с той или иной эффективностью объясняет другому роботу, чего от него хотят эти белковые массы.»
Эпитет просто бесподобен! )) Только за него можно плюс поставить, если он принадлежит автору :)
Эпитет просто бесподобен! )) Только за него можно плюс поставить, если он принадлежит автору :)
вот, смотрите, вас уже цитируют!
hebi-ao.livejournal.com/6476.html
hebi-ao.livejournal.com/6476.html
Еще одно. Если программист это робот, то может быть у кого нибудь найдется скрипт, который будет писать программы с описанием «Я пока не представляю как здесь нужно сделать, давай начнем, а дальше посмотрим, что у нас получится» или «Сделай, чтобы бегая по карте, робот обходил заборы и реки».
ИМХО виноваты не программисты, а организация труда, у вас там, похоже, бардак.
Ваше описание работы выглядит так, как будто у вас нет менеджера, который бы умел управлять людьми и использовать их особенности и ресурс. У каждого человека есть сильные и слабые стороны, которые менеджер должен учитывать и использовать на благо конторы.
Ваше описание работы выглядит так, как будто у вас нет менеджера, который бы умел управлять людьми и использовать их особенности и ресурс. У каждого человека есть сильные и слабые стороны, которые менеджер должен учитывать и использовать на благо конторы.
Ситуация с менеджментом понемногу исправляется, но мне кажется, что одним им не обойдешься. На мой взгляд, нужно внедрять нормальные программистские практики — нужны ревизии кода, юнит-тесты (их, кстати, некоторые относят к «неинтересным» частям проекта), грамотное тестирование, регламенты и пр. Тогда это всё имеет шанс запыхтеть и заворочаться как следует.
Вобще это задача менеджера организовать условия труда разработчикам: договориться на счёт покупки джиры, устновки круиз-контрола, написать гайдлайны. Дело программиста программировать, а не орг. вопросы решать.
В разделении обязанностей и ответственности сила.
В разделении обязанностей и ответственности сила.
Да, всё так. Глубина нововведений зависит от силы менеджера, ну и плюс ко всему — у всех разное видение ситуации (можно по комментариям и плюсам-минусам проследить всю радугу мнений), не факт что случится что-то глобальное.
Да это ж простой метод: подмена понятий. Слово «бардак» заменили словом «творчество» и получилась спорная статья.
Теперь прочитайте в википедии определение творчества:
Творчество — процесс деятельности, создающий качественно новые материальные и духовные ценности или итог создания субъективно нового. Основной критерий, отличающий творчество от изготовления (производства) — уникальность его результата.
Получите, что творческий программист — это не разгельдяй, а человек, способный создать свой новый подход к задаче, когда шаблонные решения не очень подходят.
Творчество, оно проивостоит не порядку, а шаблонности.
Робот — не способен к творчеству, так что ваше высказывание не корректно.
Теперь прочитайте в википедии определение творчества:
Творчество — процесс деятельности, создающий качественно новые материальные и духовные ценности или итог создания субъективно нового. Основной критерий, отличающий творчество от изготовления (производства) — уникальность его результата.
Получите, что творческий программист — это не разгельдяй, а человек, способный создать свой новый подход к задаче, когда шаблонные решения не очень подходят.
Творчество, оно проивостоит не порядку, а шаблонности.
Робот — не способен к творчеству, так что ваше высказывание не корректно.
Многое сказано. Хочу высказать свое мнение.
Если разделять разработчиков на архитекторов и кодеров, тогда пожалуй автора прав.
Если же это один человек (а так очень часто бывает), тогда с автором можно поспорить.
Ведь проектирование приложений это творческий процесс. А проектирование часть процесса разработки. И здесь бесполезно спорить ибо это true.
Только вот учится 5 лет на проектировщика приложений(если хотите архитектора) очень тяжело.
Если разделять разработчиков на архитекторов и кодеров, тогда пожалуй автора прав.
Если же это один человек (а так очень часто бывает), тогда с автором можно поспорить.
Ведь проектирование приложений это творческий процесс. А проектирование часть процесса разработки. И здесь бесполезно спорить ибо это true.
Только вот учится 5 лет на проектировщика приложений(если хотите архитектора) очень тяжело.
Осмелюсь сделать из этой статьи некоторые выводы.
Disclaimer: Все нижеследующее — мое личное, субъективное мнение, со всеми вытекающими.
Когда я впервые прочитал эту статью, я подумал, что она непременно вызовет большой резонанс, хотя бы из-за заголовка, и это конечно же случилось. Здесь прозвучало очень много различных реплик, но все их можно упрощенно свести к двум противоположным подходам:
1) Мы, программисты (за исключением быдлокодеров) — творческие личности, так что и профессия наша творческая!
2) Да нет в вашей (нашей) профессии ничего творческого, и вообще, не нужно выпендриваться и строить из себя касту «избранных».
Соответственно, все комментирующие, начиная с первого комментария, разделились на два противоположных лагеря.
С моей же точки зрения не правы, ни те, ни другие. Не правы в том, что употребляют словосочетание «творческая профессия», которое на мой взгляд не корректно по своей сути. Попробую это объяснить доступными словами, никого при этом не обидев.
Начну с того, что IMHO «профессия» и «творчество» — понятия, лежащие в разных плоскостях. Да, иногда они пересекаются, но это вовсе не повод для того, чтобы использовать прилагательное «творческий» как характеристику профессии.
Профессия это всего лишь набор знаний и подтверждающих это документов, плюс соответствующее положение в обществе. Можно даже сказать, что профессия это некий синоним ремесла.
С творчеством в этом смысле сложнее, в двух словах его не определить, каждый видит в этом понятии что-то свое. Но это не суть важно. А важно то, что, на мой взгляд, прилагательное «творческий» может применяться только по отношению к конкретному процессу (деятельности) либо к конкретному человеку в период творчества. Другими словами, профессия не может быть творческой, человек — может, но при этом не имеет значения, какая у него профессия и есть ли она у него вообще.
Наличие у человека профессии, которую принято считать творческой (художник, композитор, ..), вовсе не означает наличие самого факта творчества. Поэтому я бы использовал для таких профессий другой термин, допустим: «профессии с ожиданием творчества», т.е. профессии, от представителей которых ожидают проявления творчества.
Возвращаясь к теме статьи, я для себя вывел такую мораль: творчеством (любым) лучше заниматься в свободное от работы время, чтобы не было проблем с начальством.
Disclaimer: Все нижеследующее — мое личное, субъективное мнение, со всеми вытекающими.
Когда я впервые прочитал эту статью, я подумал, что она непременно вызовет большой резонанс, хотя бы из-за заголовка, и это конечно же случилось. Здесь прозвучало очень много различных реплик, но все их можно упрощенно свести к двум противоположным подходам:
1) Мы, программисты (за исключением быдлокодеров) — творческие личности, так что и профессия наша творческая!
2) Да нет в вашей (нашей) профессии ничего творческого, и вообще, не нужно выпендриваться и строить из себя касту «избранных».
Соответственно, все комментирующие, начиная с первого комментария, разделились на два противоположных лагеря.
С моей же точки зрения не правы, ни те, ни другие. Не правы в том, что употребляют словосочетание «творческая профессия», которое на мой взгляд не корректно по своей сути. Попробую это объяснить доступными словами, никого при этом не обидев.
Начну с того, что IMHO «профессия» и «творчество» — понятия, лежащие в разных плоскостях. Да, иногда они пересекаются, но это вовсе не повод для того, чтобы использовать прилагательное «творческий» как характеристику профессии.
Профессия это всего лишь набор знаний и подтверждающих это документов, плюс соответствующее положение в обществе. Можно даже сказать, что профессия это некий синоним ремесла.
С творчеством в этом смысле сложнее, в двух словах его не определить, каждый видит в этом понятии что-то свое. Но это не суть важно. А важно то, что, на мой взгляд, прилагательное «творческий» может применяться только по отношению к конкретному процессу (деятельности) либо к конкретному человеку в период творчества. Другими словами, профессия не может быть творческой, человек — может, но при этом не имеет значения, какая у него профессия и есть ли она у него вообще.
Наличие у человека профессии, которую принято считать творческой (художник, композитор, ..), вовсе не означает наличие самого факта творчества. Поэтому я бы использовал для таких профессий другой термин, допустим: «профессии с ожиданием творчества», т.е. профессии, от представителей которых ожидают проявления творчества.
Возвращаясь к теме статьи, я для себя вывел такую мораль: творчеством (любым) лучше заниматься в свободное от работы время, чтобы не было проблем с начальством.
Хороший код — это четко оформленный и построенный по определенным правилам документ
Единственное с чем согласен.
По поводу «творчества» на лицо заблуждение. Автор сам не считает профессию «творческой», и встретившись с ламерами считающими иначе, и провёл параллель между этими двумя совершенно не связанными явлениями.
Sign up to leave a comment.
Искусство программирования?