Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 103
Напомнило
Если бы водителей принимали на работу так же, как программистов, то выглядело это примерно так.
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимисяна вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих поизводителей — обязательны. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата: 1500-2500 рублей, определяется по результатам собеседования.
Если бы водителей принимали на работу так же, как программистов, то выглядело это примерно так.
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимисяна вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих поизводителей — обязательны. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата: 1500-2500 рублей, определяется по результатам собеседования.
Обычно еще не пишут зарплату, а пишут: испытательный срок 1-3 месяца, зарплата по результатам собеседования.
Продолжая аналогию, на собеседовании просят еще проехать гоночный круг, на время.
Иногда проще проехать гоночный круг на собеседовании и отказаться, чем потом на работе кататься по кругам в форме листа Мёбиуса.
Причем проехать его на убитой машине, за руль которой садишься впервые, с западающим сцеплением, заедающей коробкой, невнятной подвеской, лысой резиной, без АБС/ЕБД и прочего.
ну это как на права… учился на форде/автомате, а сдаешь на убитой копейке с западающими педалями :)
Со штурманом, который заводит тебя на какую-нибудь местную колхозную трассу, и сидит молча улыбается в ожидании его любимого поворотика блеать.
Меня безмерно радуют вакансии с фразой «зарплата достойная». За достойную зарплату я могу обещать только достойную работу. Критерии «достойности» каждый определяет сам.
Вот это позитив, давно так не хохотал.
Благодарю :)
Благодарю :)
Или такой вариант:
«Требуется бог. Оклад — 10000р.»
«Требуется бог. Оклад — 10000р.»
Вы успокоили меня таким сравнением.
Иногда, когда много работаешь, возникает ощущение, что программа функционирует, а ты не всегда помнишь/понимаешь как! И это очень напрягало. Ощущения утери контроля над проектом, напополам с желанием переписать все заново.
Теперь меня это будет меньше напрягать, спасибо!
Иногда, когда много работаешь, возникает ощущение, что программа функционирует, а ты не всегда помнишь/понимаешь как! И это очень напрягало. Ощущения утери контроля над проектом, напополам с желанием переписать все заново.
Теперь меня это будет меньше напрягать, спасибо!
Пишите тесты. С вменяемым тестовым покрытием можно хоть во время каждого приступа паники заглядывать в код и бесстрашно его рефакторить (улучшать, чистить), поднимя свое мироощущение в проекте.
А вы реально считаете, что где нить на строительстве корабля, есть инженер который знает все узлы и знает, как там все работает?! В больших инженерных проектах есть такие же объекты и методы, как и в программировании, когда инженер дает задание другому инженеру сделать балку с необходимыми параметрами на сжатие, растяжение и весом, и тот первый инженер даже не задумывается, над тем кто и как эту балку рассчитал и произвел, он ей пользуется в построении моста, так же как программисты пользуются библиотеками, который выполняют необходимые действия и не разбираются как.
Где-то была хорошая статья про «дырявые абстракции». У инженеров тоже такие есть, но их много меньше.
Ну как же, Закон дырявых абстракций. Хотя, на мой взгляд, в статье есть несколько спорных утверждений.
Хорошая статья.
Иными словами, TCP обязуется как-то работать надёжно, используя лишь ненадёжные детали.
Вот этот момент меня последнее время (месяц?) поражает. Что за волшебный нематериальный ингредиент добавляет совершенно новый функционал? TCP дает надежность, но состоит из IP. Компьютер умеет ого-го как считать, но состоит из кремния, металла и пластика, которые абсолютно тупы. Человек умеет страдать и любить, но состоит из воды, кальция и прочего праха.
Нельзя сказать что это новая информация для меня, но странно, что вот только сейчас я понял, что тут есть какое-то чудо (ну или подвох). Возможно когда-нибудь кибернетика (или другая похожая наука) дадут определение, насколько сложной должна быть система, чтобы она без всяких натяжек и аллегорий начала обладать чертой, которую мы называем «душой».
Иными словами, TCP обязуется как-то работать надёжно, используя лишь ненадёжные детали.
Вот этот момент меня последнее время (месяц?) поражает. Что за волшебный нематериальный ингредиент добавляет совершенно новый функционал? TCP дает надежность, но состоит из IP. Компьютер умеет ого-го как считать, но состоит из кремния, металла и пластика, которые абсолютно тупы. Человек умеет страдать и любить, но состоит из воды, кальция и прочего праха.
Нельзя сказать что это новая информация для меня, но странно, что вот только сейчас я понял, что тут есть какое-то чудо (ну или подвох). Возможно когда-нибудь кибернетика (или другая похожая наука) дадут определение, насколько сложной должна быть система, чтобы она без всяких натяжек и аллегорий начала обладать чертой, которую мы называем «душой».
Сложной называется такая система, свойства которой не сводятся к свойствам её составляющих.
Нет, вы дали определение понятию «система» — совокупность частей, которые вместе обладают свойствами, не присущими отдельным частям. Ну а понятие «сложность» определяется для каждой предметной области отдельно :)
"Система — множество взаимосвязанных элементов, обособленное от среды и взаимодействующее с ней, как целое." (Перегудов Ф.И., Тарасенко Ф.П. Введение в системный анализ. — М.: Высшая школа, 1989)
"Сложная система— система, состоящая из множества взаимодействующих составляющих (подсистем), вследствие чего сложная система приобретает новые свойства, которые отсутствуют на подсистемном уровне и не могут быть сведены к свойствам подсистемного уровня." В русской википедии ссылка на источник отсутствует, но в английской дано такое же определение (A complex system is a system composed of interconnected parts that as a whole exhibit one or more properties (behavior among the possible properties) not obvious from the properties of the individual parts.) и указан источник: Joslyn, C. and Rocha, L. (2000). Towards semiotic agent-based models of socio-technical organizations, Proc. AI, Simulation and Planning in High Autonomy Systems (AIS 2000) Conference, Tucson, Arizona, pp. 70-79.
"Сложная система— система, состоящая из множества взаимодействующих составляющих (подсистем), вследствие чего сложная система приобретает новые свойства, которые отсутствуют на подсистемном уровне и не могут быть сведены к свойствам подсистемного уровня." В русской википедии ссылка на источник отсутствует, но в английской дано такое же определение (A complex system is a system composed of interconnected parts that as a whole exhibit one or more properties (behavior among the possible properties) not obvious from the properties of the individual parts.) и указан источник: Joslyn, C. and Rocha, L. (2000). Towards semiotic agent-based models of socio-technical organizations, Proc. AI, Simulation and Planning in High Autonomy Systems (AIS 2000) Conference, Tucson, Arizona, pp. 70-79.
Это обычно называется «системный эффект»…
Один инженер конечно не знает. Он и не должен знать. Судно проектирует множество людей, не забывайте. Тут вот какое дело.
Я проектировал суда. Та часть, которой занимался конкретно ты, ты знаешь супер-детально, ты просто не можешь этого не знать. Там очень жесткий процесс разработки, т.к. на судне будут ходить живые люди.
Проектирование судна, это не написание ПО: если ты ошибешься, с тебя спросят сполна. Потому что там вопрос идет иногда на сантиметры. Там убрали, там трубу на 1,5 сантимерта вправо. Бывает ТЗ меняется в процессе: вот было судно простое, а теперь сделайте-ка мне братцы то же самое, только для неограниченного района плавания, и вот тут и начинается: при тех же размерах засунуть в него больше экипажа, движок более крупный. Вот пример — простые перила на крыше рубки, огораживающие электрощит (маленькая синяя штука на скрине) в котором дохера вольт я переделывал раз десять, сдвигая и поднимая на какие то сантиметры, высчитывая в силу возможностей возможную эргономику.
Серьезно, я этим занимался. Поэтому бывает каждая загогулинка проверяется и исправляется многократно. При таком подходе конечно по окончании проекта ты спишь и видишь его, и знаешь в нем каждый болтик.
В принципе разработка под embedded девайсы примерно так и выглядит. Каждая строчка кода перепроверяется и тестируется по 6 раз, потому что когда мобильный телефон/камера/приемник будет выпущен и там будет жесткий баг, ты уже не сможешь просто взять и наложить заплатку или скачать апдейт.
А вот и оно (РС-450 «Ураганный»), сделали же:
А вот скрин одной рабочей версии (кликабельно):
Я проектировал суда. Та часть, которой занимался конкретно ты, ты знаешь супер-детально, ты просто не можешь этого не знать. Там очень жесткий процесс разработки, т.к. на судне будут ходить живые люди.
Проектирование судна, это не написание ПО: если ты ошибешься, с тебя спросят сполна. Потому что там вопрос идет иногда на сантиметры. Там убрали, там трубу на 1,5 сантимерта вправо. Бывает ТЗ меняется в процессе: вот было судно простое, а теперь сделайте-ка мне братцы то же самое, только для неограниченного района плавания, и вот тут и начинается: при тех же размерах засунуть в него больше экипажа, движок более крупный. Вот пример — простые перила на крыше рубки, огораживающие электрощит (маленькая синяя штука на скрине) в котором дохера вольт я переделывал раз десять, сдвигая и поднимая на какие то сантиметры, высчитывая в силу возможностей возможную эргономику.
Серьезно, я этим занимался. Поэтому бывает каждая загогулинка проверяется и исправляется многократно. При таком подходе конечно по окончании проекта ты спишь и видишь его, и знаешь в нем каждый болтик.
В принципе разработка под embedded девайсы примерно так и выглядит. Каждая строчка кода перепроверяется и тестируется по 6 раз, потому что когда мобильный телефон/камера/приемник будет выпущен и там будет жесткий баг, ты уже не сможешь просто взять и наложить заплатку или скачать апдейт.
А вот и оно (РС-450 «Ураганный»), сделали же:
А вот скрин одной рабочей версии (кликабельно):
Спасибо за коммент :) Я сам из семьи кораблестроителей, тема очень близка :)
Каждый раз когда мне пытаются рассказать о том, что разработка софта — это нечто между магией, искусством и инжинирингом — я рассказываю, что такое спроектировать и главное — построить корабль. Например, военный. Например, авианосец :) Военная техника — она вообще закладывает в себе техрешения, которые должны будут работать спустя и 10, и 20 лет и это с учетом надежности и борьбы за живучесть — так что при её проектировании и постройке учитывается буквально всё.
Очень хочется увидеть пост о проектировании кораблей :)
Каждый раз когда мне пытаются рассказать о том, что разработка софта — это нечто между магией, искусством и инжинирингом — я рассказываю, что такое спроектировать и главное — построить корабль. Например, военный. Например, авианосец :) Военная техника — она вообще закладывает в себе техрешения, которые должны будут работать спустя и 10, и 20 лет и это с учетом надежности и борьбы за живучесть — так что при её проектировании и постройке учитывается буквально всё.
Очень хочется увидеть пост о проектировании кораблей :)
Дык, в том и разница, что могут быть различны требования к качеству, которые определяются ценой, временем разработки и другим. Понятно, что требования к качеству проектирования корабля выше, чем требования к качеству разработки сайта или даже офисной программы, но эти разница этих требований определена тем, рисками и ценой разработки. Это не меняет конечного смысла, что и там и там выполняется работа инженера.
Я старался, не касаться части сроков, но у меня например, есть сильные сомнения, что и в проектировке корабля заранее известны точные сроки окончания работ…
Я старался, не касаться части сроков, но у меня например, есть сильные сомнения, что и в проектировке корабля заранее известны точные сроки окончания работ…
имхо, там всё же попроще с типовыми узлами ;)
Расскажите вы мне, что собираетесь вырастить его быстрее, наняв больше садовников, и я буду смеяться до слёз.
Это выражение надо увековечить в камне!
Это выражение надо увековечить в камне!
Мой шеф часто повторяет фразу: «Если 1 беременная женщина может родить ребёнка за 9 месяцев, давайте найдем 9 беременных женщин чтобы они справились за 1»
наверно из этого:
Менеджер проекта — Думает что девять женщин могут родить ребенка за один месяц.
Разработчик — Считает, что для рождения ребенка нужно 18 месяцев.
Координатор проекта — Уверен, что одна женщина может родить девятерых детей за месяц.
Клиент — Уже сомневается, что ему вообще нужен ребенок.
Менеджер по продажам — Думает, что ребенка можно родить даже без участия мужчины и женщины.
Оптимизатор — Мужчина и женщина не нужны. Можно родить ребенка с нулевыми затратами ресурсов.
Разработчик документации — Не имеет значения когда родится ребенок, документация будет писаться девять месяцев.
Менеджер по контролю за качество — Недоволен на протяжении всего процесса создания ребенка.
Менеджер проекта — Думает что девять женщин могут родить ребенка за один месяц.
Разработчик — Считает, что для рождения ребенка нужно 18 месяцев.
Координатор проекта — Уверен, что одна женщина может родить девятерых детей за месяц.
Клиент — Уже сомневается, что ему вообще нужен ребенок.
Менеджер по продажам — Думает, что ребенка можно родить даже без участия мужчины и женщины.
Оптимизатор — Мужчина и женщина не нужны. Можно родить ребенка с нулевыми затратами ресурсов.
Разработчик документации — Не имеет значения когда родится ребенок, документация будет писаться девять месяцев.
Менеджер по контролю за качество — Недоволен на протяжении всего процесса создания ребенка.
Покажу шефу, спасибо!)
А как же тестеры?
Разработчик — Считает, что для рождения ребенка нужно 18 месяцев.
Между прочим, самый правильный подход. Женщина может забеременеть не сразу, может случится выкидыш, куча вариантов провала. Конечно, можно взять 10 женщин, чтобы повысить вероятность рождения ребенка через 9 месяцев до 99%, но клиент обычно считает, что это неоправданно дорого.
строго говоря, разработчик знает, что ребенок может и через неделю после зачатия каким-то образом выскочить, здоровый и красивый (и пару раз в жизни у него так и бывало), а может и десять лет пройти, и проект уже закроют, потому что за эти десять лет родов так и не произошло. Прогнозируемый срок проекта — это не скалярная величина, а распределение вероятностей, где площадь равна 100%.
Но интерфейс между программистом и руководителем не позволяет передавать распределения, а только скаляры, поэтому и приходится делать такую нелепую вещь, как называть прогноз требуемого времени в виде часов-дней, а не распределения.
Но интерфейс между программистом и руководителем не позволяет передавать распределения, а только скаляры, поэтому и приходится делать такую нелепую вещь, как называть прогноз требуемого времени в виде часов-дней, а не распределения.
Ну еще Брукс писал:
«Стоимость действительно измеряется как произведения числа занятых на количество затраченных месяцев. Но не достигнутый результат. Поэтому использование человеко-месяца как единицы
измерения объема работы является опасным заблуждением. Число занятых и число месяцев являются взаимозаменяемыми величинами лишь тогда, когда задачу можно распределить среди ряда работников, которые не имеют между собой взаимосвязи»
«Стоимость действительно измеряется как произведения числа занятых на количество затраченных месяцев. Но не достигнутый результат. Поэтому использование человеко-месяца как единицы
измерения объема работы является опасным заблуждением. Число занятых и число месяцев являются взаимозаменяемыми величинами лишь тогда, когда задачу можно распределить среди ряда работников, которые не имеют между собой взаимосвязи»
Есть даже прикол:
Менеджер проекта обращается к разработчикам:
— Я подсчитал что для реализации проекта необходимо 365 человеко-дней. Вас здесь ровно 365. Поэтому я ожидаю что к вечеру работа будет завершена.
Менеджер проекта обращается к разработчикам:
— Я подсчитал что для реализации проекта необходимо 365 человеко-дней. Вас здесь ровно 365. Поэтому я ожидаю что к вечеру работа будет завершена.
Огромное спасибо за перевод!
Когда пишу для души, могу напоминать садовника или художника, когда для решения насущной проблемы — инженера с претензией на художественность. Но я — не садовник-программист и не инженер-программист. Просто программист.
Увидев данный заголовок, я себя (извиняюсь) говном почувствовал))
Текст интересный, спасибо за перевод!
Текст интересный, спасибо за перевод!
А мне повезло меньше, чем садовникам. Я инженер-программист :D
И мои небоскребы могут рухнуть в любой момент и придавить создателя обломками.
И мои небоскребы могут рухнуть в любой момент и придавить создателя обломками.
Это неверное сравнение. Программисты все-таки гораздо ближе к инженерам, чем к садовникам. У программистов контроль над процессом создания продукта гораздо выше, чем у садовников. Столь детальное планирование продукта как у строителей небоскреба теоретически тоже возможно, просто оно стоит слишком много и накладывает слишком большие ограничения на заказчика при постановке требований, поэтому и редко используется.
Мне кажется, что данная аналогия расслабляет программистов, внушая им что не они ответственны за развитие продукта, деревья же растут сами.
Мне кажется, что данная аналогия расслабляет программистов, внушая им что не они ответственны за развитие продукта, деревья же растут сами.
Программисты не ближе к инженерам, они инженеры, у них абсолютно такой же контроль над производством, как и у строителей мостов и у других инженеров.
А автор статьи не понятно с какого бока приписывает файсбук, фликр и другое, это вообще то далеко не плод только инженеров, это плод кооперации десятка разных профессионалов в своей области. Плод работы программиста это программа, и она так же логична и в той же степени является готовым и оконченным продуктом, как и любая гайка, которую придумал ум инженера. И качество работы инженера определяется не тем, будет ли эта гайка в каждом автомобиле или мосте, а тем насколько он качественно рассчитал и спланировал ее для заданных требований и условий.
А автор статьи не понятно с какого бока приписывает файсбук, фликр и другое, это вообще то далеко не плод только инженеров, это плод кооперации десятка разных профессионалов в своей области. Плод работы программиста это программа, и она так же логична и в той же степени является готовым и оконченным продуктом, как и любая гайка, которую придумал ум инженера. И качество работы инженера определяется не тем, будет ли эта гайка в каждом автомобиле или мосте, а тем насколько он качественно рассчитал и спланировал ее для заданных требований и условий.
Не совсем согласен, что программисты и стоители мостов одинаковы. У гайки в мосте свойства со временем не меняются, ну кроме рассчитанного износа. А программный модуль может очень даже поменяться. Это вносит некоторый элемент случайности и делает весь продукт не полностью предсказуемым, он может быть похожим на растение, в какой-то мере.
Но проповедовать идеи садоводчества в программировании — зло, имхо. Мы должны добиваться предсказуемости продукта а не говорить что работоспособность программы зависит от погоды.
Но проповедовать идеи садоводчества в программировании — зло, имхо. Мы должны добиваться предсказуемости продукта а не говорить что работоспособность программы зависит от погоды.
Гайка это достаточно простой элемент моста, у которого достаточно легко рассчитывается износ и прочее, программные модулю сравнимые с гайкой так же меняются не сильно и последствия от изменений предсказуемы, если же мы берем крупный и сложный инженерный образец чего бы то ни было, что мы хотим использовать, то и там с течением времени могут быть не рассчитанные сюрпризы и не приятности. А если мы вокруг этого инженерного образца начнем менять внешнее окружение, то диву будешь даваться, с каких сторон у этого образца начнут всплывать всякие разные недоработки.
Основная разница в том, что при постройке мостов требования закладываются до начала строительства, а при разработке ПО они динамичные до конца разработки.
Другой момент что для программистов хотя бы теоретически возможно заложить эти требования до начала разработки, просто это редко применяется и может быть неоправданно дорого, где тут была статья про разработчиков ПО для шаттлов.
А вот у садовника ну хоть ты тресни, а изменить изгиб веточки заранее у тебя не получится.
А вот у садовника ну хоть ты тресни, а изменить изгиб веточки заранее у тебя не получится.
программы и правда ведь ведут себя как растения. Мы их постепенно улучшаем, они увеличиваются в объеме, требуют ухода. они меняются в процессе их создания. То что вчера был твердым сегодня уже желтое, а завтра будет теплым. Программа не стоит на месте и предсказать куда она повернет почти невозможно.
Исключением можно было бы назвать программы для которых полная спецификация известна изначально, и которые не менаются в процессе. Но я таких не встречал.
Исключением можно было бы назвать программы для которых полная спецификация известна изначально, и которые не менаются в процессе. Но я таких не встречал.
Я чем дальше, тем больше склоняюсь к том, что любые вложения в стадию планирования окупятся сторицей.
Странно полагать, что если невозможно нормально повесить даже полку без линейки, карандаша уровня и продумывания того, что на нее будут ставить, то возможно настрочить 10.000 строк описывающих сложный абстрактные конструкции из головы.
И чем дальше, тем больше ощущаю насколько даже правильно поставленная стрелка в UML-е или 10 строчек текста, описывающих конвенцию именования могут существенно улучшить качество проекта.
Странно полагать, что если невозможно нормально повесить даже полку без линейки, карандаша уровня и продумывания того, что на нее будут ставить, то возможно настрочить 10.000 строк описывающих сложный абстрактные конструкции из головы.
И чем дальше, тем больше ощущаю насколько даже правильно поставленная стрелка в UML-е или 10 строчек текста, описывающих конвенцию именования могут существенно улучшить качество проекта.
По мне так программисты больше похожи на врачей, чем на садовников.
Вопрос с ответственностью, конечно интересный.
Если в действительности программист может не все (как и врач), то накладывать на него бОльшую ответсвенность — значит заранее обманывать свои ожидания, и принижать его самооценку и мотивацию.
Если наоборот, то конкуренция все вернет на свои места
Вопрос с ответственностью, конечно интересный.
Если в действительности программист может не все (как и врач), то накладывать на него бОльшую ответсвенность — значит заранее обманывать свои ожидания, и принижать его самооценку и мотивацию.
Если наоборот, то конкуренция все вернет на свои места
До первого релиза. А потом приходит заказчик/клиенты/пользователи/open source и говорят «о, клево! но теперь нужно чтобыоно работало во-о-о-о-от так, и тут еще такой юз кейс...» — после чего кустик начинает расти не куда мы планировали, а туда где солнышко O_O
Я всегда думал, что приставка «инженер» подставляется для обозначения технического образования. Например, знание сопромата, материаловедения, физики и др. Ну по большей части это обосновано из за моей специальности :) Роботов делать же будем. Но всегда казалось, что в других университетах уклон такой же…
Очень точно, спасибо.
tl; dr…
Программирование очень похоже на строительство.
Многие из присутствующих здесь этого не понимают, потому что работа, которую они выполняют аналогична самой простой работе в строительстве (читай, джамшутинг). А ведь знаете, в серьёзных фирмах есть такая должность «архитектор приложения» вот его-то как раз и можно сравнить с архитектором в привычном смысле. В таких фирмах на должном уровне и качество и контроль.
И не зря шаблоны проектирования какими мы их знаем в программировании пошли из архитектуры (см. Alexander C. «The Timeless Way of Building»).
Надеюсь, у всех из вас рано или поздно развеется романтический образ непризнанного героя-программиста, выполняющего уникальную работу, непосильную никому более. И вы поймёте, что мы всего лишь строители, пусть строим не дома.
Многие из присутствующих здесь этого не понимают, потому что работа, которую они выполняют аналогична самой простой работе в строительстве (читай, джамшутинг). А ведь знаете, в серьёзных фирмах есть такая должность «архитектор приложения» вот его-то как раз и можно сравнить с архитектором в привычном смысле. В таких фирмах на должном уровне и качество и контроль.
И не зря шаблоны проектирования какими мы их знаем в программировании пошли из архитектуры (см. Alexander C. «The Timeless Way of Building»).
Надеюсь, у всех из вас рано или поздно развеется романтический образ непризнанного героя-программиста, выполняющего уникальную работу, непосильную никому более. И вы поймёте, что мы всего лишь строители, пусть строим не дома.
И вот поэтому очень неплохо прочитать книгу Алан Купера «Психбольница в руках пациентов», где очень хорошо описывается внутренний мир разработчиков.
Ну ну. Много лет управляю этим строительством. Вот только сильно это смахивает на садоводство.
Дело не в том, что не читал джамшутинг, а в том, что дома так не строят.
Мы не планируем точную архитектуру или устройство. Это конечно можно, но бесполезно. На каждом шаге исходя из полученного появляются новые видения и архитектуры и устройства, которые вносят свои немалые коррективы. При строительстве мостов это противопоказано, а в программировании должно присутствовать обязательно.
О, как бы я хотел, чтобы программирование походило на строительство!
Кстати а финансы на сопромат.
Не судьба…
Дело не в том, что не читал джамшутинг, а в том, что дома так не строят.
Мы не планируем точную архитектуру или устройство. Это конечно можно, но бесполезно. На каждом шаге исходя из полученного появляются новые видения и архитектуры и устройства, которые вносят свои немалые коррективы. При строительстве мостов это противопоказано, а в программировании должно присутствовать обязательно.
О, как бы я хотел, чтобы программирование походило на строительство!
Кстати а финансы на сопромат.
Не судьба…
Расскажите вы мне те же вещи о саде, и я скажу, что это дерьмо.bullshit — это ахинея, а не дерьмо.
с horseshit — тоже самое. Ну не лошадиное же дерьмо — а «полная чушь/ерунда/ахинея».
Сначала тоже так перевёл, но фраза «Well horse shit does grow gardens» изменила моё мнение.
Вот horse shit как раз лошадиное дерьмо, всмысле навоз. И именно как удобрение он здесь употреблен.
Remember that time when someone in your company unsuccessfully used an Agile gardening methodology, and then went around saying that it was horse shit that doesn’t work? Well horse shit does grow gardens, it just wasn’t enough to save your garden.
Помните то время, когда кто-то в вашей компании безуспешно использовал гибкую методологию (agile) садоводства, и затем ходил вокруг, приговаривая, что дело было в навозе, который не работает? Навоз помогает вырастить ваш сад, этого просто было недостаточно, чтобы сохранить его.
Как-то так, мне кажется.
Remember that time when someone in your company unsuccessfully used an Agile gardening methodology, and then went around saying that it was horse shit that doesn’t work? Well horse shit does grow gardens, it just wasn’t enough to save your garden.
Помните то время, когда кто-то в вашей компании безуспешно использовал гибкую методологию (agile) садоводства, и затем ходил вокруг, приговаривая, что дело было в навозе, который не работает? Навоз помогает вырастить ваш сад, этого просто было недостаточно, чтобы сохранить его.
Как-то так, мне кажется.
Разве лошадиный навоз используется как удобрение? В таком случае тут используется то, что horse shit кроме horse manure еще значит и bullshit. У нас же есть только одно значение. Тогда horseshit можно как просто дерьмо интерпретировать.
Это дерьмо. Хорошее дерьмо, конечно, поможет вырастить ваш сад, но его недостаточно, чтобы сохранить его.
>>Разве лошадиный навоз используется как удобрение?
Гугл говорит, что используется, я вдерьме удобрениях не очень разбираюсь.
>>В таком случае тут используется то, что horse shit кроме horse manure еще значит и bullshit.
Ну да, игра слов.
>>Тогда horseshit можно как просто дерьмо интерпретировать.
>>Это дерьмо. Хорошее дерьмо, конечно, поможет вырастить ваш сад, но его недостаточно, чтобы >>сохранить его.
Согласен, ваш вариант мне больше нравится.
Гугл говорит, что используется, я в
>>В таком случае тут используется то, что horse shit кроме horse manure еще значит и bullshit.
Ну да, игра слов.
>>Тогда horseshit можно как просто дерьмо интерпретировать.
>>Это дерьмо. Хорошее дерьмо, конечно, поможет вырастить ваш сад, но его недостаточно, чтобы >>сохранить его.
Согласен, ваш вариант мне больше нравится.
Спасибо за статью.
А я руководитель садовников-программистов. И должен действовать соответственно.
А я руководитель садовников-программистов. И должен действовать соответственно.
Конечно! А мы должны знать больше фактов из вашей биографии.
О Вашей биографии можно только догадываться!
Мне каждый день приходится спрашивать с десятка программистов когда и как будет выполнена поставленная задача. Как управленец я требую четких ответов и соответственно выполнения поставленных сроков и прочее. Я задумывался над тем, что управление созданием ПО не должно вестись по принципам строительства, поскольку результаты на практике от таких подходов неудовлетворительные.
Статья же поможет избавится от привычки руководить «обычно».
Наверное руководителям и подчиненным сложно понять друг друга, но я хотя бы стараюсь сделать это.
Мне каждый день приходится спрашивать с десятка программистов когда и как будет выполнена поставленная задача. Как управленец я требую четких ответов и соответственно выполнения поставленных сроков и прочее. Я задумывался над тем, что управление созданием ПО не должно вестись по принципам строительства, поскольку результаты на практике от таких подходов неудовлетворительные.
Статья же поможет избавится от привычки руководить «обычно».
Наверное руководителям и подчиненным сложно понять друг друга, но я хотя бы стараюсь сделать это.
Стив Макконелл в своем основополагающем труде «Совершенный код» рассматривал различные метафоры, помогающие понять разработку ПО, в том числе сельскохозяйственную и архитектурную.
Сельскохозяйственная признана им не слишком удачной, поскольку выходит так, что «программисты сеют зерна кода и ждут, когда они прорастут», не имея особых возможностей влиять на этот процесс. Цитату привел не слишком точно, по памяти, но смысл такой.
Все-таки архитектурная метаформа ближе к реальности.
Сельскохозяйственная признана им не слишком удачной, поскольку выходит так, что «программисты сеют зерна кода и ждут, когда они прорастут», не имея особых возможностей влиять на этот процесс. Цитату привел не слишком точно, по памяти, но смысл такой.
Все-таки архитектурная метаформа ближе к реальности.
Тем более даже нормальный садовник начинает с плана благоустройства и озеленения, календаря проведения технологических операций над растениями и т.п.
У автора поста слишком идеалистические представления о садовниках, приблизительно как о мастерах кунг-фу, почерпнутые из китайского треша.
Большинство профессиональных архитекторов, наверное, вспомнят про Гауди, который строил без чертежей. Однако это опять таки миф, базовые фасады, разрезы и планы его авторство — все это можно спокойно найти в интернете. Хотя на проектную документацию в ее полном объеме он, конечно, забивал. Что позволяло ему, помимо возведения шедеврально-диковинных построек, становиться рекордсменом по срокам и стоимости возведения, а так же благополучно банкротить заказчиков.
Даже египетские пирамиды возводились по в своем родепроектной документации. Отсутствие планирования — это миф, %username%
У автора поста слишком идеалистические представления о садовниках, приблизительно как о мастерах кунг-фу, почерпнутые из китайского треша.
Большинство профессиональных архитекторов, наверное, вспомнят про Гауди, который строил без чертежей. Однако это опять таки миф, базовые фасады, разрезы и планы его авторство — все это можно спокойно найти в интернете. Хотя на проектную документацию в ее полном объеме он, конечно, забивал. Что позволяло ему, помимо возведения шедеврально-диковинных построек, становиться рекордсменом по срокам и стоимости возведения, а так же благополучно банкротить заказчиков.
Даже египетские пирамиды возводились по в своем родепроектной документации. Отсутствие планирования — это миф, %username%
Он ещё говорил что если слишком серьёзно рассматривать эту аналогию, в один прекрасный момент вы начнёте поливать свой код.
А почему нельзя думать, что программисты — это программисты? Вот тупо просто без сравнений. У нас свои методики, которые имеют свои плюсы и минусы, которые вырабатывались годами.
Или инжинеров тоже сравнивают с садовниками/водителями/артистами/домохозяйками?
Или инжинеров тоже сравнивают с садовниками/водителями/артистами/домохозяйками?
Вот о том же выше писал, но читателям то ли слово «я» не понравилось, то ли аватаром в интерьер не вписался (:
Кстати, umputun в Радио-Т в таком же ключе высказался, что из нас, мол, инженеры такие же, как из бобра — птица, но и садовниками не являемся. Сказал, что мы больше художники или скульпторы, если вообще сравнивать.
Кстати, umputun в Радио-Т в таком же ключе высказался, что из нас, мол, инженеры такие же, как из бобра — птица, но и садовниками не являемся. Сказал, что мы больше художники или скульпторы, если вообще сравнивать.
Существуют квалификации: техник-программист и инженер-программист (wiki). А садовник-программист — это стеб над определениями.
Для объяснения некоторых нюансов работы людям, не имеющим 10+ лет опыта в разработке ПО :)
Пару раз смотрел передачи на Дискавери, про возведение больших зданий. Так у них все тоже самое, все те же срывы сроков, неучтеные обстоятельства и многие другие «прелести». Помимо этого и ошибки допускаются, и порой такие, от которых могут погибнуть люди.
Отличный текст, хороший перевод.
P.S. Мои 5 копеек — под rain forest обычно понимают тропический лес, а не дождевой.
P.S. Мои 5 копеек — под rain forest обычно понимают тропический лес, а не дождевой.
Хочу подробнее изложить, почему мне так понравилась эта метафора. Всю ночь думал, перечитал все комментарии к оригиналу.
Эта метафора позволяет ощутит другую крайность относительно программиста инженера и поискать каждому руководителю и программисту, по каждому проекту отдельно, свою истину, где-то посередине.
Во многих случаях разработки необходимо четко все планировать и рассчитывать на будущее, но так же часто необходимо начать разрабатывать, чтобы это будущее стало раскрываться. Мне на практике больше приходится иметь дело со вторым вариантом. Поэтому мне так понравился этот пост и эта метафора.
В моей команде программисты иногда по несколько раз переписывают код. Действительно, практически невозможно предсказать точно где и что и как прорастет.
Приближаясь ближе к садовникам, мы получаем шанс открывать что-то новое. Но велосипеды изобретать совсем не к чему. Поэтому если проект имеет достаточную конкретику, то и подходы должны быть больше взяты из инженерии.
В программировании возможно все сложнее чем у строителей и садовников. А может истина находится между не двумя, а тремя и больше точками. Но подобные метафоры позволяют и руководителям и программистам думать более гибко о подходах к реализации проектов и становиться более эффективными.
Спасибо еще раз за статью и перевод!
Эта метафора позволяет ощутит другую крайность относительно программиста инженера и поискать каждому руководителю и программисту, по каждому проекту отдельно, свою истину, где-то посередине.
Во многих случаях разработки необходимо четко все планировать и рассчитывать на будущее, но так же часто необходимо начать разрабатывать, чтобы это будущее стало раскрываться. Мне на практике больше приходится иметь дело со вторым вариантом. Поэтому мне так понравился этот пост и эта метафора.
В моей команде программисты иногда по несколько раз переписывают код. Действительно, практически невозможно предсказать точно где и что и как прорастет.
Приближаясь ближе к садовникам, мы получаем шанс открывать что-то новое. Но велосипеды изобретать совсем не к чему. Поэтому если проект имеет достаточную конкретику, то и подходы должны быть больше взяты из инженерии.
В программировании возможно все сложнее чем у строителей и садовников. А может истина находится между не двумя, а тремя и больше точками. Но подобные метафоры позволяют и руководителям и программистам думать более гибко о подходах к реализации проектов и становиться более эффективными.
Спасибо еще раз за статью и перевод!
Это довольно старая метафора, называется «органическое программирование». Здесь даже есть манифест.
Бывают действительно вредные статьи. Это одна из таких.
Автору и переводчику, а также всем кому «понравилось» для возвращения к конструктивному подходу в программировании настоятельно рекомендую перечитать «Совершенный код Макконнел С. 2005» Глава 2. Метафоры, позволяющие лучше понять разработку ПО.
Кому лень читать — просто поверьте — если вы будете «растить сад», то скорее всего закончите самым реальным садовником.
Вы именно инженер-строитель.
Лично мне больше нравиться просто инженер-механик, но там слишком много узкоспециализированных метафор, которые перестают быть метафорами.
Автору и переводчику, а также всем кому «понравилось» для возвращения к конструктивному подходу в программировании настоятельно рекомендую перечитать «Совершенный код Макконнел С. 2005» Глава 2. Метафоры, позволяющие лучше понять разработку ПО.
Кому лень читать — просто поверьте — если вы будете «растить сад», то скорее всего закончите самым реальным садовником.
Вы именно инженер-строитель.
Лично мне больше нравиться просто инженер-механик, но там слишком много узкоспециализированных метафор, которые перестают быть метафорами.
Наверное, профессиональный садовник с большей вероятностью предскажет, когда посаженное дерево даст плоды, чем инженер (в России) предскажет сроки строительства дома.
вы не инженер-программист, вы — ремесленник, всё правильно.
а ещё шаман и алхимик.
а ещё шаман и алхимик.
Эта аналогия скорее подходит для руководителя, чем для программиста (кстати, не зря в этом блоге статья расположена). Хороший управленец очень часто выступает в роли садовника. Он сам непосредственно ничего не строит, а лишь косвенно влияет на рост растений (своих подчиненных). Он приглядывает за ними, поливает и направляет вектор их дальнейшего роста. И они подрастая, возвращают плоды своего труда.
Ему также приходится садить новые растения. Однако если семена (новички-студенты) плохие, то взойти им не помогут даже хорошие условия (оборудование, атмосфера в компании и т.д.). И вдобавок ко всему, периодически приходится пропалывать грядки от сорняков, которые затесались в рядах «полезных» растений.
Ему также приходится садить новые растения. Однако если семена (новички-студенты) плохие, то взойти им не помогут даже хорошие условия (оборудование, атмосфера в компании и т.д.). И вдобавок ко всему, периодически приходится пропалывать грядки от сорняков, которые затесались в рядах «полезных» растений.
Странные сравнения, оттого и спорные. На мой взлгяд все попроще. Программист это не строитель небоскребов и мостов, это не разработчик кораблей, это не садовник, шаман, алхимик, механик или кто-то там еще. Это программист.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вы НЕ инженер-программист!