Комментарии 251
отлично написано. мне лично очень понравилось. держите плюс в карму. пишите еще плиз в таком же духе. разделяю ваше мнение
Спорно это все, IMHO. Возможно, мне в этом плане «везло» (везение всякий может понимать как ему заблагорассудится), но мне чаще попадались именно «IT-художники» (в терминологии автора топика), или IT-перфекционисты (в моей собственной терминологии). И именно они благополучно запарывали весьма перспективные проекты, пытаясь внедрить нечто, «прямо или косвенно приносящеет прибыль Заказчику».
Причем речь здесь не о неудачных попытках внедрения. Попытки, и, соответственно, внедрения, как раз, чаще всего оказывались успешными. А вот сроки напрочь срывались.
Возможно, идеальным был бы некий вариант XP, когда за компом сидело бы 2 человека — перфекционист, трудяга (термин опять же мой — соответствие с терминологией поста каждый может отыскать самостоятельно) и менеджер. Трудяга остужал бы перфекциониста, перфекционист пинал трудягу, а менеджер, в случае, если пинание увенчалось бы успехом, уточнял бы у Заказчика — а надо оно ему, или нет.
Впрочем, сдается, мое предложение тоже панацеей не является.
Причем речь здесь не о неудачных попытках внедрения. Попытки, и, соответственно, внедрения, как раз, чаще всего оказывались успешными. А вот сроки напрочь срывались.
Возможно, идеальным был бы некий вариант XP, когда за компом сидело бы 2 человека — перфекционист, трудяга (термин опять же мой — соответствие с терминологией поста каждый может отыскать самостоятельно) и менеджер. Трудяга остужал бы перфекциониста, перфекционист пинал трудягу, а менеджер, в случае, если пинание увенчалось бы успехом, уточнял бы у Заказчика — а надо оно ему, или нет.
Впрочем, сдается, мое предложение тоже панацеей не является.
если сроки срывались, это может говорить о неверном планировании. Есть такое дело, программисты любят переоценивать свои силы. С другой стороны сжатые сроки позволяют мне держать себя в тонусе, стремится к может быть изначально невозможному. Выходом из этого является измерение и подсчет реальной скорости каждого программиста, и корректировка его прогноза. Этим редко кто занимается, обычно просто умножая сроки надва.
да нет — планирование вроде как на уровне. То есть со скидкой на переоценку. Вернее — в данном случае — со 100% наценкой. Менеджмент прихрамывал — то есть не замечал вовремя увлечения программистов улучшениями кода и архитектуры — а когда замечал, проект уже сильно отличался от изначального ТЗ. Отличался в лучшую сторону, но вот беда — Заказчик, даже если он все понимает и ему само по себе идея нравится, иногда бывает поставлен в условия, что ему просто надо ехать. То есть он готов ехать и на жигулях, и на мерседесе. Мы ему изначально собирались жигули предоставить, а тут такая бодяга — вместо жигуля — мерседес. Но не совсем собранный. ТО есть водительское место отличное, и левое переднее колесо, а уж какой у него домкрат…
Можно было бы попинать на никчемность менеджера проекта (и мы, разумеется, пинали), но автор топика чуть шире мыслит. Ну я в след за ним пытаюсь.
У меня есть ощущение (во многом сформированное собственным опытом — сам грешен внесением изменений по ходу разработки), перфекционист всегда будет пытаться сделать лучше, чем спроектировано, тем самым внося разброд и шатания в работу всей команды.
P.S. Это ни в коем случае не означает, что перфекционисты не нужны. Просто надо уметь правильно их готовить. И одного менеджерского надзора может не хватить (не говоря уже о том, что если этот надзор окажется слишком плотным, велика вероятность перфекциониста потерять — он либо уйдет, либо махнет на все рукой и превратится в трудягу)
Можно было бы попинать на никчемность менеджера проекта (и мы, разумеется, пинали), но автор топика чуть шире мыслит. Ну я в след за ним пытаюсь.
У меня есть ощущение (во многом сформированное собственным опытом — сам грешен внесением изменений по ходу разработки), перфекционист всегда будет пытаться сделать лучше, чем спроектировано, тем самым внося разброд и шатания в работу всей команды.
P.S. Это ни в коем случае не означает, что перфекционисты не нужны. Просто надо уметь правильно их готовить. И одного менеджерского надзора может не хватить (не говоря уже о том, что если этот надзор окажется слишком плотным, велика вероятность перфекциониста потерять — он либо уйдет, либо махнет на все рукой и превратится в трудягу)
В чем то согласен, но не совсем. Мы горим же что и менеджмент не таджики. То есть в их собственных интересах делать так что бы заказчик был доволен. Это главная мысль статьи. И почему менеджер сразу представляется как чувак с кнутом? Ведь есть и другие способы управления, чем тотальный контроль. Это даже скорее зависит не от контроля, а от созданной атмосферы в команде. Ну например, если менеджмент не терпит новых задач, и всяких улучшений, их постоянно отбрасывает, программист будет делать их тайно, не афишируя. Но если менеджмент открыт к рацпредложениям, мало того сам иногда корректирует процессы, вносит идеи, контролирует архитектуру, то программист всегда пойдет со своим предложением в начальству, ну что бы его хотя бы по головке погладили. И тут менеджмент может с легкостью контроллировать все творческие процессы, находя золотую середину.
Надеюсь понятно расписал. Это я к тому что не надо все сваривать на программистов. Чаще всего любые проблемы проекта — недоработка менеджмента.
Надеюсь понятно расписал. Это я к тому что не надо все сваривать на программистов. Чаще всего любые проблемы проекта — недоработка менеджмента.
Пригляделся — а автор топика — это же вы. Сорри, за обращение в третьем лице. Глаз замылился. Я сейчас как раз пишу для нашего сайта текст про внешний контроль исполнения, причем примерно на ту же тему, что и ваш топик, посему, видимо, мысли где-то «за витали».
программисты боятся показаться медленными, особенно когда видят как соседа по офису увольняют за «не эффективность»…
Не согласен. Бесталантливых людей (трудяг, исполнителей), работающих за еду, вообще не должно быть. Должны быть роботы, создать которых могут лишь талантливые творческие люди.
И вообще, бизнес — дерьмо, если главная его цель деньги. Деньги, которые затем разменивают на спокойствие, надежность, комфорт и еще уйму бездыханного преходящего дыма, который так дурманит узколобых исполнителей. Бизнес только тогда пристойная форма жизни, когда деньги и все что за ними (надежность, комфорт и т. д.) разменивают на дело.
Исполнители — это следствие недостатка культуры и самопознания, отсутствия чутья и воли к свободе. Исполнители — это чума доставшаяся нам от темного и безграмотного прошлого. Это хребет косных корпораций и оплот бессмысленных войн. Но грядет новое время, где власть не принадлежит купюре, где в креслах заседают не надменные скульптуры, где каждый сам себе голова и люди объединяют усилия ради прогресса всеобщего, а не личного (кстати, настоящий ум понимает, что по-настоящему хорошо может быть у тебя только тогда, когда хорошо у твоего соседа). Где идеал успеха замещен идеалом служения, как и завещал прекрасный муж Эйнштейн. Где технократия — форма правления. Где серая исполнительная мышь более не существует, потому что ей не дают есть, так как она всегда тормозит технологию, вместо того, чтобы ее двигать.
Говорят нам нужны еще рабы, чтобы делать грязную работу. Но я готов сам рубить дрова, варить кашу, собирать картошку, чистить туалет, если того еще требует отсутствие технологий. Это вранье, что исполнительные рабы как бы полезны. Если бы еще вчера хотя бы десятую их часть разменять на прекрасные творческие головы, сегодня было бы уже то время, когда рабы вообще не нужны.
Я бы хотел, чтобы все руководители никогда не брали на работу серых исполнителей. Тогда последние исчезнут как вид. А руководители только выиграют как личности. Ведь на самом деле, делать талантливых людей дисциплинированными — благое дело, а дисциплинированных людей талантливыми — пустая трата времени. Может быть это сложный подход, требующий нервотрепки, но зато он героичный и стоит того, что бы ради быть руководителем.
И вообще, бизнес — дерьмо, если главная его цель деньги. Деньги, которые затем разменивают на спокойствие, надежность, комфорт и еще уйму бездыханного преходящего дыма, который так дурманит узколобых исполнителей. Бизнес только тогда пристойная форма жизни, когда деньги и все что за ними (надежность, комфорт и т. д.) разменивают на дело.
Исполнители — это следствие недостатка культуры и самопознания, отсутствия чутья и воли к свободе. Исполнители — это чума доставшаяся нам от темного и безграмотного прошлого. Это хребет косных корпораций и оплот бессмысленных войн. Но грядет новое время, где власть не принадлежит купюре, где в креслах заседают не надменные скульптуры, где каждый сам себе голова и люди объединяют усилия ради прогресса всеобщего, а не личного (кстати, настоящий ум понимает, что по-настоящему хорошо может быть у тебя только тогда, когда хорошо у твоего соседа). Где идеал успеха замещен идеалом служения, как и завещал прекрасный муж Эйнштейн. Где технократия — форма правления. Где серая исполнительная мышь более не существует, потому что ей не дают есть, так как она всегда тормозит технологию, вместо того, чтобы ее двигать.
Говорят нам нужны еще рабы, чтобы делать грязную работу. Но я готов сам рубить дрова, варить кашу, собирать картошку, чистить туалет, если того еще требует отсутствие технологий. Это вранье, что исполнительные рабы как бы полезны. Если бы еще вчера хотя бы десятую их часть разменять на прекрасные творческие головы, сегодня было бы уже то время, когда рабы вообще не нужны.
Я бы хотел, чтобы все руководители никогда не брали на работу серых исполнителей. Тогда последние исчезнут как вид. А руководители только выиграют как личности. Ведь на самом деле, делать талантливых людей дисциплинированными — благое дело, а дисциплинированных людей талантливыми — пустая трата времени. Может быть это сложный подход, требующий нервотрепки, но зато он героичный и стоит того, что бы ради быть руководителем.
НЛО прилетело и опубликовало эту надпись здесь
Присоединюсь к предыдущим комментаторам и поблагодарю за интересную статью!
Возражаю, но постараюсь кратко, предметно :)
>> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
Нельзя.
>> Оглянитесь вокруг, в России это повсюду!
Отличный аргумент, когда нет аргументов.
>>Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать
Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.
ИМХО: статья более пафосна и менее логична, чем первая. Извините, если чем обидел.
>> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
Нельзя.
>> Оглянитесь вокруг, в России это повсюду!
Отличный аргумент, когда нет аргументов.
>>Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать
Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.
ИМХО: статья более пафосна и менее логична, чем первая. Извините, если чем обидел.
Мой опыт показывает что поделить можно. Опыт немаленький. Опыт работы во многих компаниях, в больших и малых командах. Статья не из пальца высосана, она полностью отражает мой опыт, и основана на нем.
Так я и не говорю, что из пальца ) С первой частью статьи я даже согласился.
Пусть мой комментарий останется ИМХОм =)
Пусть мой комментарий останется ИМХОм =)
>Опыт работы во многих компаниях, в больших и малых командах
Недавно слышал как директор одной довольно крупной компании отклонил кандидатуру программиста, потому что у него в трудовой книжке не было ни одной работы продолжительностью больше года. По его мнению это говорит о том что или человек не уживается в коллективе или не усидчив, или что «свалит при первой же проблеме».
Недавно слышал как директор одной довольно крупной компании отклонил кандидатуру программиста, потому что у него в трудовой книжке не было ни одной работы продолжительностью больше года. По его мнению это говорит о том что или человек не уживается в коллективе или не усидчив, или что «свалит при первой же проблеме».
У меня в трудовой есть работы продолжительностью год и более. Но в любом случае это может говрить о том что человек просто не нашел пока своей компании. Это может говрить об исключительно быстром прогрессе этого человека, и о том что компании в которых он работал не смогли его знания использовать.
Это может говорить о чём угодно, но если комания ищет стабильного сотрудника не на один год, то лучше для неё будет взять человека уже имющего опыт длительной работы.
Исключительно быстрый прогресс — звучит неправдоподобно. Даже в случаях сопровождения средних проектов, иногда может потребоваться около года, только на то, чтобы человек влился в проект. И что же получается, что после всех затрат на обучение, человек говорит: отлично, я всё понял, у меня быстрый прогресс, мне теперь здесь тесно, я пошёл развиваться дальше? =)
Исключительно быстрый прогресс — звучит неправдоподобно. Даже в случаях сопровождения средних проектов, иногда может потребоваться около года, только на то, чтобы человек влился в проект. И что же получается, что после всех затрат на обучение, человек говорит: отлично, я всё понял, у меня быстрый прогресс, мне теперь здесь тесно, я пошёл развиваться дальше? =)
>Естественное стремление вольных художников — бросать проект, когда баги начинаются.
Если у проекта нормальный менеджмент, баги никогда не станут его проблемой.
Если у проекта нормальный менеджмент, баги никогда не станут его проблемой.
Покажите мне, пожалуйста, то место в моём комментарии, где я говорил про то, что баги станут проблемой проекта.
>бросать проект, когда баги начинаются.
И где там про проблему? :)
Я о том, что вольных художников сложно заставить фиксить эти баги, потому что это скучно, рутинно, никаких инноваций. Я сто раз слышал в такой ситуации «мне это неинтересно».
Изложите, пожалуйста, каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
Я о том, что вольных художников сложно заставить фиксить эти баги, потому что это скучно, рутинно, никаких инноваций. Я сто раз слышал в такой ситуации «мне это неинтересно».
Изложите, пожалуйста, каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
если багов немного, и они занимают небольшое количество времени то никто никуда не убежит. если убегают значит баги занимают много времени, значит они являются проблемой.
>каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
Надо просто такой ситуации не допускать.
>каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
Надо просто такой ситуации не допускать.
Ну хз, хз. В моей текущей команде ведущий программист — такой вот художник. И когда его просят сделать мердж из бранча в транк (ну, перенести полезные изменения в побочной ветви) он говорит «это скучно и неинтересно заниматься этой рутиной, я не хочу это делать». Как быть тут?
>> Надо просто такой ситуации не допускать.
Ситуации, когда есть в проекте баги? Вы шутите, наверное :) В любом проекте есть дефекты на любой его стадии, это еще Брукс говорил; в противном случае тестировщики ПО не нужны бы были как класс.
Беда в том, что художника сложно заставить довести задачу до конца — как только он сталкивается с трудностями, он бросает эту задачу. Вы эту особенность упорно не замечаете в статье, списывая на то, что менеджер художник сможет справиться с этим.
И менеджер-художник будет поступать точно так же, как и рядовой программист — как только его заинтересованность спадет, ему будет «покласть» на прибыль заказчика.
В любом случае, за статью спасибо.
>> Надо просто такой ситуации не допускать.
Ситуации, когда есть в проекте баги? Вы шутите, наверное :) В любом проекте есть дефекты на любой его стадии, это еще Брукс говорил; в противном случае тестировщики ПО не нужны бы были как класс.
Беда в том, что художника сложно заставить довести задачу до конца — как только он сталкивается с трудностями, он бросает эту задачу. Вы эту особенность упорно не замечаете в статье, списывая на то, что менеджер художник сможет справиться с этим.
И менеджер-художник будет поступать точно так же, как и рядовой программист — как только его заинтересованность спадет, ему будет «покласть» на прибыль заказчика.
В любом случае, за статью спасибо.
>когда его просят сделать мердж из бранча в транк
не понял… это 15 секунд делов, как можно успеть соскучится? )))) Дайте ему, в конце концов звдвчу автоматизации процесса, что бы сократить время до 5 секунд. Задача интересная, времени займет не много, зато сэкономите его 10 сек. Шутко)))
не понял… это 15 секунд делов, как можно успеть соскучится? )))) Дайте ему, в конце концов звдвчу автоматизации процесса, что бы сократить время до 5 секунд. Задача интересная, времени займет не много, зато сэкономите его 10 сек. Шутко)))
Шутко хорошая, потому как боюсь, что результатов мы не увидим =)
Не, там в мердже не так просто, потому как выборочные коммиты переносятся. У меня ушло 2 дня только на то, чтобы понять, какие коммиты надо переносить, потому что проект очень большой, разбит на субпроекты :)
Ну так о чем это я… Собстно, о том, что это пресловутое «неинтересно» просто как серпом по… пульсу проекта :) А вот «IT-таджик» такое не скажет — он медленно, но верно доделает работу.
Видимо, тут прослеживается явная аналогия с темпераментом.
Не, там в мердже не так просто, потому как выборочные коммиты переносятся. У меня ушло 2 дня только на то, чтобы понять, какие коммиты надо переносить, потому что проект очень большой, разбит на субпроекты :)
Ну так о чем это я… Собстно, о том, что это пресловутое «неинтересно» просто как серпом по… пульсу проекта :) А вот «IT-таджик» такое не скажет — он медленно, но верно доделает работу.
Видимо, тут прослеживается явная аналогия с темпераментом.
ну вот значит у вас плохо поставлена работа с свн. Этим все объясняется в не проблемами IT-художников.
Это не регулярная, а разовая работа — порядка 2к коммитов в 11 ветках. Обычно все действительно проще, укладывается в 10 минут.
Но это должен же кто-то был сделать :) А художникам это — «не в жилу».
P.S. У нас не svn, а TFS; в нем есть свои проблемы мерджа, что еще более доставляет. Менять его на svn — политика компании не позволяет. Я себе поставил гейт tfs2svn, и работаю через него, но остальным художникам «технические трудности неинтересны» :)
Но это должен же кто-то был сделать :) А художникам это — «не в жилу».
P.S. У нас не svn, а TFS; в нем есть свои проблемы мерджа, что еще более доставляет. Менять его на svn — политика компании не позволяет. Я себе поставил гейт tfs2svn, и работаю через него, но остальным художникам «технические трудности неинтересны» :)
это должен делать тот кто работает в ветке. а не кто-то другой. я вообще никогда мержи не рассматривал в качестве нагрузки. это часть работы над задачей. я вообще никак в толк не возьму как это может вызывать проблемы. все проблемы с мержами были всегда виной менеджмента или разработчиков.
Извините, что пристал с прикладной проблемой :) Просто жизненая ситуация — в транке лежит «четверка», в одну из веток ушел «4.6» — для одного из заказчиков. Порядка полутора месяцев (пара длинных спринтов) 3+ведущий «педалят» 4.6, а затем понимают, что в 4.X хотелось бы видеть многое оттуда.
Надо переносить. А кому?
Имхо должен ведущий программимст, а он — крутит носом, потому что счас изучает фреймворк по стейт-машинам и думает, как его прикрутить.
Это пост не предполагает ответ, просто пояснял, что я имел в виду.
Надо переносить. А кому?
Имхо должен ведущий программимст, а он — крутит носом, потому что счас изучает фреймворк по стейт-машинам и думает, как его прикрутить.
Это пост не предполагает ответ, просто пояснял, что я имел в виду.
Добавлю насчет сложности мерджа. Бывают проекты (я в подобных участвовал, так что не абстрактно), которые длятся, скажем год-полтора с участием 50-100 человек. При этом код системы может состоять из 0.5-1 миллиона строк и в ней меняется примерно 20-30% существующего кода, помимо добавления нового. Естественно, в ходе выполнения проекта продолжают выходить небольшие апгрейды к существующей продакшен-версии, а большой проект ведется целиком в бранче. Иногда бывает и по два таких огромных проекта параллельно, и потом надо это «слить» в транк. Так вот автоматом тут совсем не прокатывает, и на мердж уходит иногда месяц-два. Это что, тоже ошибки менеджмента? Нет, это реальности бизнеса компании…
Да, ошибки менджмента. Если на обычный мердж уходит месяц извините))) Значит эта система контроля версий не подходит, либо необходима автоматизация, либо специальные люди (мантейнеры) и тд.
>Если на обычный мердж уходит месяц извините
Вы точно прочитали внимательно? Система в 1 миллион строк кода на С++. Многие компоненты в результате проекта изменены довольно сильно и не поддаются автоматическому мерджу (просто из-за конфликтов).
А вообще, если в двух словах расскажете, чем SVN так лучше и быстрее, чем CVS в плане мерджа, буду благодарен.
Вы точно прочитали внимательно? Система в 1 миллион строк кода на С++. Многие компоненты в результате проекта изменены довольно сильно и не поддаются автоматическому мерджу (просто из-за конфликтов).
А вообще, если в двух словах расскажете, чем SVN так лучше и быстрее, чем CVS в плане мерджа, буду благодарен.
Повторяю. Если мердж вызыввает такие проблемы, если появляется много конфликтов и тд. То это признак того что вы либо работатете с ним неправильно либо необходимы усилия по автоматизации процесса, либо смена системы контроля версий либо все вместе.
По поводу CVS не скажу ничего. Я с ним не работал потому что давно считаю эту систему умершей. Если вас не устраивает SVN есть еще например GIT и Mercurial. CVS позавчерашний день, и я удивлен что им еще кто-то пользуется. Не вижу ни одной причины на нем оставться, кроме лени что-то менять.
По поводу CVS не скажу ничего. Я с ним не работал потому что давно считаю эту систему умершей. Если вас не устраивает SVN есть еще например GIT и Mercurial. CVS позавчерашний день, и я удивлен что им еще кто-то пользуется. Не вижу ни одной причины на нем оставться, кроме лени что-то менять.
Хм… Прям обескуражили :) Хоть и добавил Вас в друзья, рискну поспорить.
Что означает «неправильная работа с мерджем» и как тогда правильно? Банальный пример конфликта: в проекте в бранче делается изменение в методе, а в транке в это время идет рефакторинг, в результате которого метод удален и заменен каким-то другим. Что здесь может поделать автомердж? И чем так поможет волшебный SVN? Вообще, в таких случаях самый быстрый способ — это сесть с каким-нибудь компарером типа Araxis Merge и вручную все это выправить.
Вы можете возразить, что неверно было решать рефакторить код, пока существует бранч. Но это не всегда возможно, просто по причине того, что бизнес требует быстрых решений, и зачастую невозможно приостановить большой проект ради какого-то рефакторинга, но сам по себе этот рефакторинг важен в рамках другого большого и срочного проекта, поэтому делают параллельно. Да, в идеале это все некрасиво и неудобно и приводит к лишним расходам времени, но на практике по-другому не выходит. Это как разница между точным и приближенным расчетом интеграла. Мне не нравится, что в результате расчета численными методами я получаю, скажем, 1.999997, тогда как обычный метод на бумажке по формуле дает 2.0. Но на практике разница не так важна, и можно без проблем пойти на издержки.
А насчет SVN vs CVS. Может быть, SVN гораздо более эффективен, я про него знаю столько же, сколько Вы про CVS, хотя SVN часто на слуху. Но представьте большую компанию, весь код которой хранится в CVS со всей историей изменений, с кучей скриптов и макросов, завязанных на другие внутренние системы компании. Все это отлажено и работает отлично годами. Перевод на другую систему контроля версий с переписыванием всех скриптов и их отладкой и интеграцией займет, думаю, с полгода точно. Причем это будет работа для целой команды. Ведь еще надо протестировать, что ничего не упущено, что все работает как требуется и т.д. Учитывая стоимость одного разработчика для компании, скажем, 150,000 рублей/мес (половина — зарплата, вторая половина — налоги и другие выплаты в бюджет), за полгода для команды даже из трех человек получим 2,700,000 рублей. Плюс почти гарантированно в эту сумму не уложатся из-за каких-то неожиданных проблем. А что в результате получим? Более удобный интерфейс для разработчиков и, может быть, пара функций будет выполняться проще. И совсем не надо быть менеджером-таджиком, чтобы отказаться от этой затеи.
Что означает «неправильная работа с мерджем» и как тогда правильно? Банальный пример конфликта: в проекте в бранче делается изменение в методе, а в транке в это время идет рефакторинг, в результате которого метод удален и заменен каким-то другим. Что здесь может поделать автомердж? И чем так поможет волшебный SVN? Вообще, в таких случаях самый быстрый способ — это сесть с каким-нибудь компарером типа Araxis Merge и вручную все это выправить.
Вы можете возразить, что неверно было решать рефакторить код, пока существует бранч. Но это не всегда возможно, просто по причине того, что бизнес требует быстрых решений, и зачастую невозможно приостановить большой проект ради какого-то рефакторинга, но сам по себе этот рефакторинг важен в рамках другого большого и срочного проекта, поэтому делают параллельно. Да, в идеале это все некрасиво и неудобно и приводит к лишним расходам времени, но на практике по-другому не выходит. Это как разница между точным и приближенным расчетом интеграла. Мне не нравится, что в результате расчета численными методами я получаю, скажем, 1.999997, тогда как обычный метод на бумажке по формуле дает 2.0. Но на практике разница не так важна, и можно без проблем пойти на издержки.
А насчет SVN vs CVS. Может быть, SVN гораздо более эффективен, я про него знаю столько же, сколько Вы про CVS, хотя SVN часто на слуху. Но представьте большую компанию, весь код которой хранится в CVS со всей историей изменений, с кучей скриптов и макросов, завязанных на другие внутренние системы компании. Все это отлажено и работает отлично годами. Перевод на другую систему контроля версий с переписыванием всех скриптов и их отладкой и интеграцией займет, думаю, с полгода точно. Причем это будет работа для целой команды. Ведь еще надо протестировать, что ничего не упущено, что все работает как требуется и т.д. Учитывая стоимость одного разработчика для компании, скажем, 150,000 рублей/мес (половина — зарплата, вторая половина — налоги и другие выплаты в бюджет), за полгода для команды даже из трех человек получим 2,700,000 рублей. Плюс почти гарантированно в эту сумму не уложатся из-за каких-то неожиданных проблем. А что в результате получим? Более удобный интерфейс для разработчиков и, может быть, пара функций будет выполняться проще. И совсем не надо быть менеджером-таджиком, чтобы отказаться от этой затеи.
делать рефакторинг в транке? ужас…
при этом, есть один рецепт от месячного сливания веток — частый мердж. То есть мержится надо по нескольку раз в день. Тогда версии не будут слишком сильно отходить друг от друга, и максимум повлекут небольшие быстро разрешаемые конфликты. При этом повторяю, можно придумать ряд автоматизированных решений.
Насчет CVS. Это настолько старая штука что наверняка существуют решения для быстрой конвертации репозиториев из одной системы в другую. Вместе со всей историей и тд. При этом я не вижу проблем написать подобную систему самостоятельно. Существуют различные шлюзы и враперы и тд. Переход вполне возможно сделать плавным. По крайней мере если это есть для других систем контроля то не вижу причин почему этого нет здесь. Я просто даже не думал что кто-то еще использует этот анохронизм.
И заметьте, вот вы говрите что не знакомы с SVN. Ну мне простительно мое незнакомство с CVS, ибо я не могу ковырять все допотопные системы. Но как вы можете утверждать о неизбежности проблем с переходом, даже не удосужившись в этом немного разобраться? Вы жалуетесь на проблемы с ветками, при этом даже не знаете как ветки организованны в других системах, SVN, GIT, Mercurial? Может там нет этих проблем? Может там существуют подходы, позволяющие их избежать?
при этом, есть один рецепт от месячного сливания веток — частый мердж. То есть мержится надо по нескольку раз в день. Тогда версии не будут слишком сильно отходить друг от друга, и максимум повлекут небольшие быстро разрешаемые конфликты. При этом повторяю, можно придумать ряд автоматизированных решений.
Насчет CVS. Это настолько старая штука что наверняка существуют решения для быстрой конвертации репозиториев из одной системы в другую. Вместе со всей историей и тд. При этом я не вижу проблем написать подобную систему самостоятельно. Существуют различные шлюзы и враперы и тд. Переход вполне возможно сделать плавным. По крайней мере если это есть для других систем контроля то не вижу причин почему этого нет здесь. Я просто даже не думал что кто-то еще использует этот анохронизм.
И заметьте, вот вы говрите что не знакомы с SVN. Ну мне простительно мое незнакомство с CVS, ибо я не могу ковырять все допотопные системы. Но как вы можете утверждать о неизбежности проблем с переходом, даже не удосужившись в этом немного разобраться? Вы жалуетесь на проблемы с ветками, при этом даже не знаете как ветки организованны в других системах, SVN, GIT, Mercurial? Может там нет этих проблем? Может там существуют подходы, позволяющие их избежать?
Давайте опять по пунктам :)
Делать небольшой рефакторинг пары методов в транке совсем даже не криминально. Но во время существования большого проекта в бранче таких вот небольших изменений может накопиться порядочно. Да пусть даже не в транке, пусть эти изменения стали результатом нескольких средних проектов, которые прошли каждый в своем бранче и затем были слиты в транк, тогда как наш большой проект все еще не был готов. В общем, примеров могу привести много.
Насчет частого мерджа. Во-первых, много частых мерджей станут равны по времени одному большому, ну разве что кое-каких конфликтов удастся избежать. А для больших проектов это вовсе невозможно. Например в ходе проекта пишется много новой бизнес-логики, которую, прежде чем выпускать в продакшен, необходимо тщательно протестировать, причем не по кусочкам, а целиком. И если каждый день мерджиться, то регулярно будут возникать сложности с заглушками для еще не протестированной функциональности, которая попала в транк, но не должна быть пока доступна. Можно возразить, что «правильный» ООП не позволит возникнуть подобным проблемам. Но беда в том, что в компании из тысячи человек невозможно всем писать идеально, даже если все художники. Да и не существует абсолютно идеального кода хотя бы потому, что языки программирования имеют ограничения и недостатки.
Насчет быстрой конвертации в SVN. Я более чем уверен, что она есть. Но Вы, возможно, не поняли о чем я говорил. У нас, например, во время чекина в CVS выполняется множество сопутствующих макросов, которые вносят информацию о чекине в другие системы коллективной работы, применяемые в компании. И не так-то просто заставить все это работать с новой системой контроля версий. А кое-что может стать и невозможным из-за различий в подходах. Тогда неизбежно придется доделывать или менять другие системы компании и так по цепочке заменить все. Я боюсь себе представить, во сколько это обойдется. А потом, когда все наконец завершится, выйдет еще более новая версия с еще более правильной идеологией :)
Насчет SVN, GIT etc, я пока не услышал от Вас объяснения преимуществ их работы с ветками. Предлагаю написать статью. Но тогда придется хотя бы бегло изучить CVS…
Делать небольшой рефакторинг пары методов в транке совсем даже не криминально. Но во время существования большого проекта в бранче таких вот небольших изменений может накопиться порядочно. Да пусть даже не в транке, пусть эти изменения стали результатом нескольких средних проектов, которые прошли каждый в своем бранче и затем были слиты в транк, тогда как наш большой проект все еще не был готов. В общем, примеров могу привести много.
Насчет частого мерджа. Во-первых, много частых мерджей станут равны по времени одному большому, ну разве что кое-каких конфликтов удастся избежать. А для больших проектов это вовсе невозможно. Например в ходе проекта пишется много новой бизнес-логики, которую, прежде чем выпускать в продакшен, необходимо тщательно протестировать, причем не по кусочкам, а целиком. И если каждый день мерджиться, то регулярно будут возникать сложности с заглушками для еще не протестированной функциональности, которая попала в транк, но не должна быть пока доступна. Можно возразить, что «правильный» ООП не позволит возникнуть подобным проблемам. Но беда в том, что в компании из тысячи человек невозможно всем писать идеально, даже если все художники. Да и не существует абсолютно идеального кода хотя бы потому, что языки программирования имеют ограничения и недостатки.
Насчет быстрой конвертации в SVN. Я более чем уверен, что она есть. Но Вы, возможно, не поняли о чем я говорил. У нас, например, во время чекина в CVS выполняется множество сопутствующих макросов, которые вносят информацию о чекине в другие системы коллективной работы, применяемые в компании. И не так-то просто заставить все это работать с новой системой контроля версий. А кое-что может стать и невозможным из-за различий в подходах. Тогда неизбежно придется доделывать или менять другие системы компании и так по цепочке заменить все. Я боюсь себе представить, во сколько это обойдется. А потом, когда все наконец завершится, выйдет еще более новая версия с еще более правильной идеологией :)
Насчет SVN, GIT etc, я пока не услышал от Вас объяснения преимуществ их работы с ветками. Предлагаю написать статью. Но тогда придется хотя бы бегло изучить CVS…
>много частых мерджей станут равны по времени одному большому
Это может в вашей CVS так. в SVN это далеко не так, и наоборот рекомендуется мержится и комитится как можно чаще. Это сэкономит массу времени.
>Например в ходе проекта пишется много новой бизнес-логики, которую, прежде чем выпускать в продакшен, необходимо тщательно протестировать
Правильно. Поэтому мержить надо из транка, а не в транк.
>в компании из тысячи человек невозможно всем писать идеально
Даже в компании из двух человек невозможно)))
>Я боюсь себе представить, во сколько это обойдется
Глаза боятся а руки делают. Повторяю, я больше чем уверен что переход можно осуществить плавно да так что никто не заметит. Зато результат может оказаться таким что окупит все. Та же скорость комита на svn по определению выше чем в cvs. Про меркуриал я вообще молчу. Работа с ветками намного быстрее. Так что переход окупится сторицей, и чем больше вы его затягиваете тем больше денег улетает в трубу.
Это может в вашей CVS так. в SVN это далеко не так, и наоборот рекомендуется мержится и комитится как можно чаще. Это сэкономит массу времени.
>Например в ходе проекта пишется много новой бизнес-логики, которую, прежде чем выпускать в продакшен, необходимо тщательно протестировать
Правильно. Поэтому мержить надо из транка, а не в транк.
>в компании из тысячи человек невозможно всем писать идеально
Даже в компании из двух человек невозможно)))
>Я боюсь себе представить, во сколько это обойдется
Глаза боятся а руки делают. Повторяю, я больше чем уверен что переход можно осуществить плавно да так что никто не заметит. Зато результат может оказаться таким что окупит все. Та же скорость комита на svn по определению выше чем в cvs. Про меркуриал я вообще молчу. Работа с ветками намного быстрее. Так что переход окупится сторицей, и чем больше вы его затягиваете тем больше денег улетает в трубу.
Насчет небольших частых мерджей готов согласиться. Поизучаю вопрос и best bractices в SVN.
Насчет мерджей из транка в бранч — да, так и делаем периодически. Наверное, если делать чаще, то будет еще эффективнее. Но это надо доказать сравнением.
Насчет скорости работы с ветками и т.д. Я почти никогда не ощущаю сложностей со скоростью работы с CVS. Репозитории у нас локальные по офисам с репликацией в один главный. К тому же у нас никто не колбасит код с такой скоростью, чтобы ему мешали те 30 секунд, которые нужны на чекин дневной порции кода :) Даже если мне надо делать чекин 10 раз в день — это в сумме 5-10 минут времени, большая часть из которого уходит на написание комментариев к чекинам.
Насчет мерджей из транка в бранч — да, так и делаем периодически. Наверное, если делать чаще, то будет еще эффективнее. Но это надо доказать сравнением.
Насчет скорости работы с ветками и т.д. Я почти никогда не ощущаю сложностей со скоростью работы с CVS. Репозитории у нас локальные по офисам с репликацией в один главный. К тому же у нас никто не колбасит код с такой скоростью, чтобы ему мешали те 30 секунд, которые нужны на чекин дневной порции кода :) Даже если мне надо делать чекин 10 раз в день — это в сумме 5-10 минут времени, большая часть из которого уходит на написание комментариев к чекинам.
>Но это надо доказать сравнением.
Это доказывается логикой. Чем чаще мерж тем меньше конфликтов. на мерж тратится 15 сек. на разруливание конфликта от нескольких минут до бесконечности. Надо взять за правило
1. часты комит. несколько раз в день. любое более или мение законченное изменение должно тут же комитится. не нравится длинную команду набирать, присовй элиас (или вы через гуи работаете?)
2. частый мерж. закомитил, тут же смержился. в svn это делается простейшей командой, не надо номера ревизий запоминать все помнится автоматически.
Вот в этом ваша проблема. У нас тоже подобные проблемы были. Ну никак не вдолбишь ты людям что надо часто комитится и мержится. работают днями, а потом часы тратят на разруливание конфликтов. причем не только те кто не комитится и не мержится, а и те кто работает правильно.
Это доказывается логикой. Чем чаще мерж тем меньше конфликтов. на мерж тратится 15 сек. на разруливание конфликта от нескольких минут до бесконечности. Надо взять за правило
1. часты комит. несколько раз в день. любое более или мение законченное изменение должно тут же комитится. не нравится длинную команду набирать, присовй элиас (или вы через гуи работаете?)
2. частый мерж. закомитил, тут же смержился. в svn это делается простейшей командой, не надо номера ревизий запоминать все помнится автоматически.
Вот в этом ваша проблема. У нас тоже подобные проблемы были. Ну никак не вдолбишь ты людям что надо часто комитится и мержится. работают днями, а потом часы тратят на разруливание конфликтов. причем не только те кто не комитится и не мержится, а и те кто работает правильно.
>любое более или мение законченное изменение должно тут же комитится
А вот это нам совсем не подходит. У нас любой код проходит предварительную инспекцию со стороны коллег. И только после этого можно чекинить. Не должно быть непроверенного кода в репозитории. К тому же иногда не полностью зачекиненный код ломает ночной билд. А на инспекцию тратится от нескольких часов до нескольких дней. Что делать в таком случае?
Сложности с мерджем отчасти связаны с первой проблемой.
А вот это нам совсем не подходит. У нас любой код проходит предварительную инспекцию со стороны коллег. И только после этого можно чекинить. Не должно быть непроверенного кода в репозитории. К тому же иногда не полностью зачекиненный код ломает ночной билд. А на инспекцию тратится от нескольких часов до нескольких дней. Что делать в таком случае?
Сложности с мерджем отчасти связаны с первой проблемой.
1. Какая проверка? Вы экономите на переходе на svn при этом впустую тратите людские ресурсы.
2. Для того что бы непроверенный код не попадал в ночной билд и существуют ветки. Закомитился, и проверяй сколько влезет. Проеврил, прогнал тесты комить в билдовую ветку.
щас я вас сэконосмлю несколько миллионов)))
2. Для того что бы непроверенный код не попадал в ночной билд и существуют ветки. Закомитился, и проверяй сколько влезет. Проеврил, прогнал тесты комить в билдовую ветку.
щас я вас сэконосмлю несколько миллионов)))
Хм… А Вы слышали что-нибудь про процессы разработки и стандарты качества? PSP, CMM и т.д. Инспекции кода не я придумал. Кратко описывал это здесь: habrahabr.ru/blogs/arbeit/46495/
я к тому что частый комит и мердж никак не мешает инспекции кода. хотя и сама инспекция это бред. есть тестирование, это да, это нужно. но инспектировать код не нужно.
1. нужно избегать говнокодеров еще на этапе собеседования
2. плохо написанный код, если при этом написаны тесты со временем вылизывается. это называется TDD. А если вы дрожите деньгами, вам просто необходим принцип минимализма. То есть все что требуется от кода это то что бы он выполнял поставленную задачу. НО это только в том случае если у вас в целом все процессы верные, если у компа не говнокодеры, если пишете юниттесты, если код изначально хорошо структурирован… то есть правильно поставленная работа не требует контроля именно кода. но это не отменяет необходимость его тестирования, что невозможно без комита, иначе откуда тестеры его возьмут
1. нужно избегать говнокодеров еще на этапе собеседования
2. плохо написанный код, если при этом написаны тесты со временем вылизывается. это называется TDD. А если вы дрожите деньгами, вам просто необходим принцип минимализма. То есть все что требуется от кода это то что бы он выполнял поставленную задачу. НО это только в том случае если у вас в целом все процессы верные, если у компа не говнокодеры, если пишете юниттесты, если код изначально хорошо структурирован… то есть правильно поставленная работа не требует контроля именно кода. но это не отменяет необходимость его тестирования, что невозможно без комита, иначе откуда тестеры его возьмут
Вы описали идеальную компанию с идеальным продуктом и идеальными процессами. Такой компании не то что инспекции, ей и тестирование не нужно. Но ведь где-то же должны получать опыт все Ваши художники программирования :) Поэтому нет ничего оскорбительного, если на ваш код внимательно посмотрит хороший архитектор с опытом работы в десяток лет, выскажет замечания и укажет на дефекты.
Еще инспекции полезны тем, что на чужом хорошем коде отлично учишься.
В общем, предлагаю на этом закругляться с риторикой :-) Вы исходите из своего опыта, я из своего. Очень полезно знать как работают другие и на основе этих знаний корректировать и улучшать свою работу. В Ваших статьях и хабракомментариях нашел много полезного.
Еще инспекции полезны тем, что на чужом хорошем коде отлично учишься.
В общем, предлагаю на этом закругляться с риторикой :-) Вы исходите из своего опыта, я из своего. Очень полезно знать как работают другие и на основе этих знаний корректировать и улучшать свою работу. В Ваших статьях и хабракомментариях нашел много полезного.
дело в том, что он итак посмотрит. но тогда, когда придет его очередь писать код в этом участке. смотрите, система проста. программист комитит код в свою ветку. мержит из транка последние изменения. после этого, отдает тестерам на тестирование. они тестируют, и если код правильно работает, он реинтегрируется в транк. но вдруг код недостаточно хорошо написан? в следующий раз менеджер, дает этот участок кода доработать более опытному. то есть не специально для ревизии, а для доработки функционала. более опытный смотрит на код, и проводит рефактроинг. и если считает нужным подзывает к себе джуниора и показывает его недочеты. таким образом не тратится время дорогого специалиста а убивается сразу 2 зайца.
так же полезна практика парного программирования. во первых и код пишется быстрее, и программисты друг у друга учатся и друг за другом следят.
но повторяю, даже если и использовать ревизии, это все равно нисколько не мешает частым комитам. Наоборот, если уж так важна инспекция, можно слать архитектору диф комита. И ему будет гораздо проще следить за кодом и видеть изменения.
так же полезна практика парного программирования. во первых и код пишется быстрее, и программисты друг у друга учатся и друг за другом следят.
но повторяю, даже если и использовать ревизии, это все равно нисколько не мешает частым комитам. Наоборот, если уж так важна инспекция, можно слать архитектору диф комита. И ему будет гораздо проще следить за кодом и видеть изменения.
Спасибо. Я попробую по тематике нашей дискуссии написать статью со своим видением ситуации. Тогда можно будет еще обсудить. Потому что в рамках комментариев сложно расписать все нюансы.
Про XP мы подумываем, но пока никак не соберемся применить. Тема однозначно интересная и многообещающая.
Еще постараюсь до написания статьи почитать про SVN. Если знаете какие-либо качественные обзорные статьи (не много! :) — буду благодарен.
Про XP мы подумываем, но пока никак не соберемся применить. Тема однозначно интересная и многообещающая.
Еще постараюсь до написания статьи почитать про SVN. Если знаете какие-либо качественные обзорные статьи (не много! :) — буду благодарен.
ну извините за нескромность, но могу порекомендовать свои :)
habrahabr.ru/blogs/development_tools/45203/
habrahabr.ru/blogs/development_tools/45222/
хотя лучшая статья это svnbook ;)
habrahabr.ru/blogs/development_tools/45203/
habrahabr.ru/blogs/development_tools/45222/
хотя лучшая статья это svnbook ;)
Прочитал Ваши статьи и немного посмотрел svnbook. Честно говоря, не вижу ни одной вещи, которой нет в CVS. Абсолютно та же система работа с ветками. Есть одно различие, которое у нас очень легко решили. В SVN, как я понял, при любом комите обновляется ревизия всего репозитория, что удобно. Можно тогда взять код по любой ревизии и сравнить, скажем, пару соседних комитов. У нас это решили так: в WinCVS добавлен макрос, который при комите просто выставляет новый тэг на репозиторий. Вот и все отличия, которые я вижу. Поэтому абсолютно не вижу смысла переходить нам на SVN.
Да, ну и, возможно, еще один плюс: SVN развивается, а CVS уже давно не обновлялся. Но работает он стабильно и веских причин обновлять что-то я не вижу. Вот если появится что-то принципиально новое и удобное, тогда есть смысл подумать о переходе.
Кстати говоря, я почитал комментарии и вижу, что Вы так же относитесь к GIT, как я к SVN, хотя люди, казалось бы, аргументированно объясняют преимущества GIT. В общем, просто мы привыкли к разным системам и абсолютно идеальной системы для всех не может быть в принципе :)
Кстати говоря, я почитал комментарии и вижу, что Вы так же относитесь к GIT, как я к SVN, хотя люди, казалось бы, аргументированно объясняют преимущества GIT. В общем, просто мы привыкли к разным системам и абсолютно идеальной системы для всех не может быть в принципе :)
я так и знал что вы это заметите :) Но дело в том, что после этих комментариев я начал использовать меркуриал в одном проекте, а недавно мне оне популярно объяснили что оказывается в другом моем проекте, который опен сорс, мне нужен GIT, но все не доходят руки под него проект перевести. Но то что это нужно сделать я не сомневаюсь. То есть скепсис понятен, и это нормально. А вот упертость это уже плохо.
ok.
а есть ли в CVS Externals Definitions?
как насчет отсутвия Merge tracking?
как вы думаете почему даже такой старый и большой проект как FreeBSD таки перешел на SVN?
а есть ли в CVS Externals Definitions?
как насчет отсутвия Merge tracking?
как вы думаете почему даже такой старый и большой проект как FreeBSD таки перешел на SVN?
Статью я писать не буду, потому что она неактуальна. Все умные люди давно перешли на более совершенные системы контроля версий, и мало кому нужно доказывать их приемущества.
Если интересно, то тут есть и про svn, и про cvs:
en.wikipedia.org/wiki/Comparison_of_revision_control_software
Самый большой плюс svn по сравнению с cvs — наличие atomic commits, и гораздо более стабильный и ловкий merge, не оставляющий мусора в файле. Плюс в целом быстродействие по сети заметно выше.
Из минусов svn (или недоплюсов) по сравнению с более поздними, такими как git, bzr или hg, — rename файла, хоть и автоматизирован, но по-прежнему через «не хочу», с удалением старого и добавлением нового (история изменений теряется); история мержей не хранится, так что по невнимательности легко можно смержить одну и ту же ревизию несколько раз :)
P.S. Тот же TFS отслеживает такой неприятный момент (хотя в режиме baseless merge карты в руки — можно что угодно с чем угодно мержить)
en.wikipedia.org/wiki/Comparison_of_revision_control_software
Самый большой плюс svn по сравнению с cvs — наличие atomic commits, и гораздо более стабильный и ловкий merge, не оставляющий мусора в файле. Плюс в целом быстродействие по сети заметно выше.
Из минусов svn (или недоплюсов) по сравнению с более поздними, такими как git, bzr или hg, — rename файла, хоть и автоматизирован, но по-прежнему через «не хочу», с удалением старого и добавлением нового (история изменений теряется); история мержей не хранится, так что по невнимательности легко можно смержить одну и ту же ревизию несколько раз :)
P.S. Тот же TFS отслеживает такой неприятный момент (хотя в режиме baseless merge карты в руки — можно что угодно с чем угодно мержить)
sse
zakhars
Это всё называется Форк. И это 100% просчёт менеджмента и архитектора.
zakhars
Это всё называется Форк. И это 100% просчёт менеджмента и архитектора.
Очень хорошо.
Давайте, я с вами соглашусь. Предположим, архитектор просчитался указанным образом — ну, с кем не бывает, от ошибок никто не застрахован ;)
Что делать дальше — смержить-то надо? 90% вероятности того, что художник закатит истерику «вот, вы меня не послушали, а теперь такая ж*па, и поэтому я не буду разгребать ваше гуано».
А смержить-то — все равно кому-то надо :-P
Давайте, я с вами соглашусь. Предположим, архитектор просчитался указанным образом — ну, с кем не бывает, от ошибок никто не застрахован ;)
Что делать дальше — смержить-то надо? 90% вероятности того, что художник закатит истерику «вот, вы меня не послушали, а теперь такая ж*па, и поэтому я не буду разгребать ваше гуано».
А смержить-то — все равно кому-то надо :-P
ну так пусть тот кто ошибся тот и мержит. или выписать художнику премию за то что был прав.
Тот, кто виноват, давно уже не работает, потому что понял, чем пахнет то, что он натворил :)
А премию художнику выпишем обязательно. По печени, бгг :) Потому что тут работа, а не танцы «я то не хочу, это не буду».
Почему из-за его каприза кто-то другой должен этим заниматься (например, я)?
А премию художнику выпишем обязательно. По печени, бгг :) Потому что тут работа, а не танцы «я то не хочу, это не буду».
Почему из-за его каприза кто-то другой должен этим заниматься (например, я)?
а потому что ему надоело уже вам говорить что надо делать что бы этого не приходилось делать никому. но вы же самый умный а он кто такой что бы советовать
вы наверное путаете работу и рабство.
вы наверное путаете работу и рабство.
Нет, это Вы, наверное, путаете меня и менеджера проекта; уверяю, я только технический лидер, и к распределению задач, ресурсов и приоритетов, не имею ни малейшего отношения :)
если вы технический лидер, то именно вам иделать. не ПМу же ветки мержить, не так ли?
Не, не так ) Работу должен делать тот, кому назначили делать эту работу. У нас не Индия, каст нет. Если его моральные принципы запрещают ему заниматься этим, пусть меняет — либо принципы, либо работу.
Я техлид на совершенно другом проекте, на этом — только аудитор. А коммитов художника в проекте большая часть, потому что ведущий программист там — он.
Я уже написал ниже про «истинного» художника. Надеюсь, в своем изложении вы имели в виду именно его, а не летуна-белоручку.
Я техлид на совершенно другом проекте, на этом — только аудитор. А коммитов художника в проекте большая часть, потому что ведущий программист там — он.
Я уже написал ниже про «истинного» художника. Надеюсь, в своем изложении вы имели в виду именно его, а не летуна-белоручку.
Ваши проблемы. Сам себе злобный Буратино. Менеджмент — в первую очередь ответственность.
Разгребать чужое гуано иногда сильно надоедает. Подумайте, стоит ли снижать мотивацию эффективного сотрудника? Или лучше дать ему нормальную задачу, а гуано пусть разгребает Джамшут. Ему всё равно где копать.
Разгребать чужое гуано иногда сильно надоедает. Подумайте, стоит ли снижать мотивацию эффективного сотрудника? Или лучше дать ему нормальную задачу, а гуано пусть разгребает Джамшут. Ему всё равно где копать.
Мне все равно, кому и что надоедает. Я в такой ситуации тоже не собираюсь выступать в роли Джамшута только потому, что кто-то капризничает громче, чем я:)
Вернее, так:
1. Джамшут меееедленно, печально и безынтересно прожует и выполнит работу;
2. «Художник» скажет «идите нах, моя гениальность не стоит того, чтобы тратить ее на то, чтобы проект заработал»;
3. Истинный художник возьмется за рутинную работу и выполнит ее; а за время, ушедшее на рутину, он постарается придумать, как сделать так, чтобы потребности в такой рутине больше не возникало — потом созовет всех в переговорную, и предложит обоснованные меры по увеличению эффективности.
P.S. Да и что такое «нормальную работу» художнику? Разве приведение проекта в приличное состояние — это не нормальная работа? Что еще надо вдобавок — пиво, девки, блэкджек?
Вернее, так:
1. Джамшут меееедленно, печально и безынтересно прожует и выполнит работу;
2. «Художник» скажет «идите нах, моя гениальность не стоит того, чтобы тратить ее на то, чтобы проект заработал»;
3. Истинный художник возьмется за рутинную работу и выполнит ее; а за время, ушедшее на рутину, он постарается придумать, как сделать так, чтобы потребности в такой рутине больше не возникало — потом созовет всех в переговорную, и предложит обоснованные меры по увеличению эффективности.
P.S. Да и что такое «нормальную работу» художнику? Разве приведение проекта в приличное состояние — это не нормальная работа? Что еще надо вдобавок — пиво, девки, блэкджек?
Согласен. Но всегда хочется большего ;)
> пиво, девки, блэкджек
А почему бы и нет? :)
> пиво, девки, блэкджек
А почему бы и нет? :)
все дело в том если он уже говрил о том что нам нужны тестеры, и делал это на протяжении полугода, созывал всех в переговорную, твердил это менеджеру каждый день, а ему говорили «да, да ты прав», но их так и не появилось. И он уже в который раз после выгрузки сидит все выходные и вылавливает баги, о которых почему то никто до выгрузки так и не слышал.
Тестеры есть, но если бы он говорил, как улучшить процесс, я бы первый его поддержал :D
Но на практике почему-то оказывается, что он рапортует, что багов нет и все у него работает, потому что снизойти до unit-testing-а ему не позволяет я не знаю что, а найденные за ним баги отказывается фиксить с пометкой «отклонено, неинтересно» :D
Я же говорил, у нас разное понимание художника, видимо ) Тот тип художника, о котором я говорю, даже Doxygen-комментарии для публичного API считает рутиной :D
Но на практике почему-то оказывается, что он рапортует, что багов нет и все у него работает, потому что снизойти до unit-testing-а ему не позволяет я не знаю что, а найденные за ним баги отказывается фиксить с пометкой «отклонено, неинтересно» :D
Я же говорил, у нас разное понимание художника, видимо ) Тот тип художника, о котором я говорю, даже Doxygen-комментарии для публичного API считает рутиной :D
дело в том что IT-таджик вообще не будет использовать ветки)))
>> Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.
С этой фразы я понял, что у нас, видимо, разное понимание «художника». *Пошел перечитывать обе статьи*
С этой фразы я понял, что у нас, видимо, разное понимание «художника». *Пошел перечитывать обе статьи*
IT-таджик (в Вашем определении) будет делать то, что ему скажет менеджер. Если в компании используются ветки, то он и мердж будет делать.
А если менеджер тоже тоже таджик? А если менджер вообще не знает что такое svn?
А почему только SVN? :) Чем так CVS, скажем, не устраивает? А по существу, мердж зачастую весьма нетривиальная операция, о чем я написал чуть выше.
потому что cvs это позавчершний день. Глупо сейчас его использовать.
Офигеть-довод по существу (;
нормальный довод. глупо использовать что-то старое если есть новое. я понимаю если это новое только появилось и непонятно как будет развиваться. но svnу сто лет. cvs это архаизм.
ой да ладно.
можно подумать у вас на дестопе виндоуз 7/последняя убунта, кодите вы в последней версии IDE (ганимед/ZDE)?
выбор новой технологии должен быть обусловлен только преимуществами, которые она дает. Если преимущества сводятся к «новее» — это не довод убивать время на перенос проекта с одного на другое.
можно подумать у вас на дестопе виндоуз 7/последняя убунта, кодите вы в последней версии IDE (ганимед/ZDE)?
выбор новой технологии должен быть обусловлен только преимуществами, которые она дает. Если преимущества сводятся к «новее» — это не довод убивать время на перенос проекта с одного на другое.
убунта последняя. а смысл старую испаользовать? Кодю да, под полседней верисией, а было что и под бетой кодил, это когда в нетбинсе серьезно улучшили поддержку php
и давайте не будем устраивать холивар. если есть две системы, и одна из них новее, при этом обе удовлетворяют задачам, надо переходить на более новую. я не говрю что сразу кидаться сломя голову, но по карйней мере сильно не затягивать.
и давайте не будем устраивать холивар. если есть две системы, и одна из них новее, при этом обе удовлетворяют задачам, надо переходить на более новую. я не говрю что сразу кидаться сломя голову, но по карйней мере сильно не затягивать.
да что там svn vs cvs! Как только появился svn 1.5 тут же заставил админа её поставить, хотя на серверах центос, и в репозиториях новые версии не появляются. то есть ему бедному пришлось ручками рпмку собирать. ну ничего. справился, и в награду мы получили выигрыш во времени при мерджах, и избавились от гемороя. хотя ведь старый свн по сути все наши задачи выполнял нормально.
Если что то работает и всех устраивает, зачем ставить новое? Новое ради нового это нонсенс.
не только svn. я например сейчас использую mercurial в одном своем проекте.
Во всех компаниях в которых я работал ветки внедрял я. Без меня о них даже не задумывались. Все, начиная от менджмента и заканчивая программистами о них слышали, но думали что это им или не нужно или это что-то очень сложное. После внедрения веток, большенство разработчиков их не использовали если не проследишь за этим лично, и не протрахаешь все мозги «Вася, ты ветку завел?».
>В любом проекте есть дефекты на любой его стадии
Естественно. Но их может быть разное количество, и баги бывают мелкими и крупными. Задача менджмента так поставить процесс разработки, что бы багов было немного, и они были мелкими. Вот тогда никто не будет убегать
>как только он сталкивается с трудностями, он бросает эту задачу
Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.
Естественно. Но их может быть разное количество, и баги бывают мелкими и крупными. Задача менджмента так поставить процесс разработки, что бы багов было немного, и они были мелкими. Вот тогда никто не будет убегать
>как только он сталкивается с трудностями, он бросает эту задачу
Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.
честно не понимаю почему вы считаете что художник так легко бросит свое детище. Я бы скорее предположил вариант крепко подумает, и предложит серьезную переделку дизаина проекта, которая должна будет вычистить множество багов, образовавшихся из-за постепенных внесений в проект.
> И когда его просят сделать мердж из бранча в транк (ну, перенести полезные изменения в побочной ветви) он говорит «это скучно и неинтересно заниматься этой рутиной, я не хочу это делать». Как быть тут?
А зачем вам такие долгие бранчи, что их муторно мержить?
А зачем вам такие долгие бранчи, что их муторно мержить?
А почему вас это интересует? Разве ответ на этот вопрос поможет вам изменить мое мнение насчет художников?
Безусловно. Когда художник считает, что его заставляют делать херню, он всеми силами избегает этой работы.
По моему мнению длинные бранчи с большими мержами — это не рутина, а самая настоящая херня.
По моему мнению длинные бранчи с большими мержами — это не рутина, а самая настоящая херня.
Мы счас не стратегии мержа обсуждаем, а отношение «художников» к своей работе.
Проблема в том, что нет гарантии, что проект _внезапно_ не «разонравится» художнику, и тот вдарит по тапкам. Проект уже неинтересен, и делать его «художник» не будет.
Пример с мержем — просто иллюстратив, не более.
Проблема в том, что нет гарантии, что проект _внезапно_ не «разонравится» художнику, и тот вдарит по тапкам. Проект уже неинтересен, и делать его «художник» не будет.
Пример с мержем — просто иллюстратив, не более.
внезапно знаете что бывает? :)
в реальности проект не может внезапно разонравится. вчера нравился а сегодня понял что херня. не бывает такого. обычно это происходит постепенно, и у этого есть причины. и чаще всего это ошибки управления.
в реальности проект не может внезапно разонравится. вчера нравился а сегодня понял что херня. не бывает такого. обычно это происходит постепенно, и у этого есть причины. и чаще всего это ошибки управления.
Если разонравится, значит проект — действительно говно, и с этим надо что-то делать.
Так что настроение художника в таком случае выгодно использовать по типу канарейки в шахте ;)
Так что настроение художника в таком случае выгодно использовать по типу канарейки в шахте ;)
Если приходится править чужие баги в больших количествах, то, конечно, радостного мало. Но приходилось и приходится исправлять и чужие баги и свои и ничего, просто исправсяется баг с повышением надёжности, функционала и эффективности, от чего получается приличное удовлетворение.
(себя считаю как раз художником в классификации данного поста)
> Я сто раз слышал в такой ситуации «мне это неинтересно».
И такое бывает, но это уже лень (или очень недостаточная финансовая мотивация), но это уже из другой оперы.
(себя считаю как раз художником в классификации данного поста)
> Я сто раз слышал в такой ситуации «мне это неинтересно».
И такое бывает, но это уже лень (или очень недостаточная финансовая мотивация), но это уже из другой оперы.
> Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.
Я считаю себя художником. И для меня баги — тоже вызов. Поэтому я исправляю их быстрее кого бы то ни было (иногда шпыняешь тестера по поводу правильного оформления бага, а сам его уже давно исправил ;) ).
Я считаю себя художником. И для меня баги — тоже вызов. Поэтому я исправляю их быстрее кого бы то ни было (иногда шпыняешь тестера по поводу правильного оформления бага, а сам его уже давно исправил ;) ).
НЛО прилетело и опубликовало эту надпись здесь
ИМХО хороший менеджер не может быть ни просто «таджиком» ни просто «художником» а должен сочетать эти качества вместе. Вы пробовали взглянуть на проблему со стороны руководства?
На руководстве штат сотрудников, которые хотят получать зарплату, причем стабильно и много, офис, арендодатель которого тоже хочет кушать, и далее по списку. Для того что бы эти затраты нести необходима стабильность — «художники» в том смысле, который Вы вкладываете в это слово стабильность не могут обеспечить в принципе, как в прочем и «таджики». для успешного развития компании необходим баланс стабильности, что бы спокойнее спать, и иновационности, чтобы спокойно спать в долгосрочной перспективе, и любые перекосы в одну из сторон ничего хорошего компании не принесут.
На руководстве штат сотрудников, которые хотят получать зарплату, причем стабильно и много, офис, арендодатель которого тоже хочет кушать, и далее по списку. Для того что бы эти затраты нести необходима стабильность — «художники» в том смысле, который Вы вкладываете в это слово стабильность не могут обеспечить в принципе, как в прочем и «таджики». для успешного развития компании необходим баланс стабильности, что бы спокойнее спать, и иновационности, чтобы спокойно спать в долгосрочной перспективе, и любые перекосы в одну из сторон ничего хорошего компании не принесут.
художники вполне могут обеспечивать стабильность и отсутвие перекосов. не надо думать что это всегда фанатики. но в терминах статьи таджик и художник это вещи прямо противоположные. нельзя быть одновременно плюсом и минусом.
нельзя дискретно разделять людей, тем более всего на две категории. каждый человек уникален.
Я считаю что Вы видите картину однобоко. Конфигурация Работник-Руководство-Заказчик может стабильно сосуществовать только при одном условии — совместная работа приносит всем прибыль, и чтобы так и было, необходимо учитывать интересы всех сторон, что практически всегда заставляет кого либо подстраиватся под ситуацию.
Вы же настолько эгоистичны, что не хотите даже видеть интересы других, а они далеко не всегда совпадают с Вашими (и с интересами описаных Вами «художников»)
Я считаю что Вы видите картину однобоко. Конфигурация Работник-Руководство-Заказчик может стабильно сосуществовать только при одном условии — совместная работа приносит всем прибыль, и чтобы так и было, необходимо учитывать интересы всех сторон, что практически всегда заставляет кого либо подстраиватся под ситуацию.
Вы же настолько эгоистичны, что не хотите даже видеть интересы других, а они далеко не всегда совпадают с Вашими (и с интересами описаных Вами «художников»)
совместная работа всегда приносит прибыль только одному — заказчику. всем остальным она приносит доход.
да ну? а прибыль разве не от размера дохода зависит?
прибыль это разница между вложенными и полученными средствами. для получения дохода вкладывать средства не нужно, и доход величина сравнительно постоянная.
выход — привязать запрплату к прибыли. но это технически сложно. например в майкрософте дают акции, таким образом каждый заинтересован в развитии компании. Но и это не выход. потому что часто рост прибыли требует вложения труда. многие предпочтут работать поменьше, получая поменьше, чем работать побольше и получать больше. не всегда деньги стимул, если их получение требует усилий.
выход — привязать запрплату к прибыли. но это технически сложно. например в майкрософте дают акции, таким образом каждый заинтересован в развитии компании. Но и это не выход. потому что часто рост прибыли требует вложения труда. многие предпочтут работать поменьше, получая поменьше, чем работать побольше и получать больше. не всегда деньги стимул, если их получение требует усилий.
У меня возникает вопрос — а вы вообще разбираетесь о том, что пишете или нет?
>для получения дохода вкладывать средства не нужно
для того что бы доделать какой либо проект необходимо — заплптить персоналу, который над этим проектом работает, оплатить аренду помещения, текущие платежи такие, как телефоны, интернет, свет и пр. — это по Вашему не вложение средств для того что бы по окончанию проэкта получить доход, вычесть из него все расходы, оплатить налоги и с удовольствием посчитать ПРИБЫЛЬ?!
>доход величина сравнительно постоянная
доход величина постоянная только при стабильности в работе о которой я писал раньше. это когда у вас есть постоянные заказчики, а им не интересно что там художник, работающие над его проектом хотят там сделать, им интересно решение ИХ задач за приемлимые для НИХ деньги и в приемлимые для НИХ сроки. Если же нет постоянных заказчиков, то доход по определению не может быть постоянной величиной.
В энный раз повторюсь Вы смотрите на проблему только со своей точки зрения, и не хотите учитывать потребности заказчика, а в любом проекте главный именно он
>для получения дохода вкладывать средства не нужно
для того что бы доделать какой либо проект необходимо — заплптить персоналу, который над этим проектом работает, оплатить аренду помещения, текущие платежи такие, как телефоны, интернет, свет и пр. — это по Вашему не вложение средств для того что бы по окончанию проэкта получить доход, вычесть из него все расходы, оплатить налоги и с удовольствием посчитать ПРИБЫЛЬ?!
>доход величина сравнительно постоянная
доход величина постоянная только при стабильности в работе о которой я писал раньше. это когда у вас есть постоянные заказчики, а им не интересно что там художник, работающие над его проектом хотят там сделать, им интересно решение ИХ задач за приемлимые для НИХ деньги и в приемлимые для НИХ сроки. Если же нет постоянных заказчиков, то доход по определению не может быть постоянной величиной.
В энный раз повторюсь Вы смотрите на проблему только со своей точки зрения, и не хотите учитывать потребности заказчика, а в любом проекте главный именно он
вы не поняли.
прибыль — разница между вложенными и полученными деньгами
доход — обычная зарплата.
прибыль — разница между вложенными и полученными деньгами
доход — обычная зарплата.
>и не хотите учитывать потребности заказчика
Эта статья как раз и написана для заказчиков, и в ней я потребности заказчиков учитываю. Потребность заказчика — прибыль. Наибольшую прибыль ему смогут обеспечить только художники. Точка.
Эта статья как раз и написана для заказчиков, и в ней я потребности заказчиков учитываю. Потребность заказчика — прибыль. Наибольшую прибыль ему смогут обеспечить только художники. Точка.
>доход — обычная зарплата
еще раз посоветую обратится к экономической литературе
>Наибольшую прибыль ему смогут обеспечить только художники
наибольшую прибыль ему сможет обеспечить только его голова. К вам он обращается только за решением его, конкретной задачи. критерии при отборе исполнителей с точки зрения заказчика — решение ЕГО (ни в коем случае не вашей) задачи, стоимость ее решения, сроки. Если его задачу можно решить испульзуя уже что то готовое, пусть и такое, которое не нравится «художнику», то это проблеммы только художника, а никак не заказчика, зато повышается скорость разработки и уменьшается цена.
Поймите с точки зрения заказчика — вы должны сделать так как хочет он, а не так как думаете вы, в лбом случае в своей области он разбирется лучше вас, поэтому что бы такого заказчика привлечь и удержать ва просто необходимо иметь качества в первую очередь «таджика»
еще раз посоветую обратится к экономической литературе
>Наибольшую прибыль ему смогут обеспечить только художники
наибольшую прибыль ему сможет обеспечить только его голова. К вам он обращается только за решением его, конкретной задачи. критерии при отборе исполнителей с точки зрения заказчика — решение ЕГО (ни в коем случае не вашей) задачи, стоимость ее решения, сроки. Если его задачу можно решить испульзуя уже что то готовое, пусть и такое, которое не нравится «художнику», то это проблеммы только художника, а никак не заказчика, зато повышается скорость разработки и уменьшается цена.
Поймите с точки зрения заказчика — вы должны сделать так как хочет он, а не так как думаете вы, в лбом случае в своей области он разбирется лучше вас, поэтому что бы такого заказчика привлечь и удержать ва просто необходимо иметь качества в первую очередь «таджика»
Цитирую википедию
Дохо́д — регулярное денежное пополнение бюджета экономического субъекта.
При́быль — превышение в денежном выражении доходов от продажи товаров и услуг над затратами
Регулярное денежное пополнение может быть обычным окладом. Прибыль — всегда разница между затратами и доходом. Андестенд?
>с точки зрения заказчика — вы должны сделать так как хочет он
Правильно. Но сделать это можно разными путями. Художник выберет всегда наиболее оптимальный путь. Таджик наиболее простой (не значит быстрый)
Дохо́д — регулярное денежное пополнение бюджета экономического субъекта.
При́быль — превышение в денежном выражении доходов от продажи товаров и услуг над затратами
Регулярное денежное пополнение может быть обычным окладом. Прибыль — всегда разница между затратами и доходом. Андестенд?
>с точки зрения заказчика — вы должны сделать так как хочет он
Правильно. Но сделать это можно разными путями. Художник выберет всегда наиболее оптимальный путь. Таджик наиболее простой (не значит быстрый)
Цитирую Вашу статью в моем понимании «Я такой модный и самый умный, а все остальные дураки, и только я знаю как решить все проблемы»
Хочу отметить — современное предприятие — это сложнейший механизм. и любой в этом механизме (будь то ген. директор или сантехник Вася) всего лишь шестеренка. этот механизм будет работать нормально только тогда когда каждая из шестеренок выполняет свою и только свою функцию хорошо.
как только какая либо из шестеренок начинает прыгать туда сюда и пытатся заменить собою весь механизм — этот механизм начинает работать только хуже.
Это я к тому, что каждый должен делать свою работу. и благо работы сейчас много (да я слышал про кризис), так что большинство может найти себе работу по вкусу и способностям.
Вам же в этой ситуации сложнее, потому что вы считаете истинно правильным только свое личное мнение и я сомневаюсь, что можете правильно оценить свои силы.
Я тоже по натуре художник и меня просто бесит тупая монотонная работа, но иногда оптимальное решение это сделать что то монотонно, а не изобретать велосипед или искать приключений на свою задницу, но вы этого не поймете.
Хочу отметить — современное предприятие — это сложнейший механизм. и любой в этом механизме (будь то ген. директор или сантехник Вася) всего лишь шестеренка. этот механизм будет работать нормально только тогда когда каждая из шестеренок выполняет свою и только свою функцию хорошо.
как только какая либо из шестеренок начинает прыгать туда сюда и пытатся заменить собою весь механизм — этот механизм начинает работать только хуже.
Это я к тому, что каждый должен делать свою работу. и благо работы сейчас много (да я слышал про кризис), так что большинство может найти себе работу по вкусу и способностям.
Вам же в этой ситуации сложнее, потому что вы считаете истинно правильным только свое личное мнение и я сомневаюсь, что можете правильно оценить свои силы.
Я тоже по натуре художник и меня просто бесит тупая монотонная работа, но иногда оптимальное решение это сделать что то монотонно, а не изобретать велосипед или искать приключений на свою задницу, но вы этого не поймете.
>всего лишь шестеренка
В отличии от вас я сравниваю любое предприятие не с механизмом а с организмом.
В отличии от вас я сравниваю любое предприятие не с механизмом а с организмом.
ладно, тогда не шестеренка, а орган.
подумайте как вы будете себя чувствовать если вдруг ваш пищевод решит что он не только пищевод но еще и прямой кишечник?
подумайте как вы будете себя чувствовать если вдруг ваш пищевод решит что он не только пищевод но еще и прямой кишечник?
а вы подумайте что будет, если ваша рука, схватившая горячую сковородку будет ждать когда мозг решит что же делать.
организм тем и отличается от механизма, что он способен подстраиваться под изменения окружающей среды, и чем в этом плане гибче организм тем лучше. в механизме шестеренка в случае поломки останавливает весь механизм. в организме поломка одного органа часто не является фатальной.
вот и думайте что лучше, когда каждый = шестренка, упорно пытающаяся делать свою работу, либо когда каждый = часть сложного организма, способного гибко реагировать на ситуацию. И что лучше, когда кадый орган такого организма может выполнять только свою работу, или когда каждый способен подменить или помочь соседу, послать сигнал о проблемах, и минимизировать вред, дожидаясь решения.
организм тем и отличается от механизма, что он способен подстраиваться под изменения окружающей среды, и чем в этом плане гибче организм тем лучше. в механизме шестеренка в случае поломки останавливает весь механизм. в организме поломка одного органа часто не является фатальной.
вот и думайте что лучше, когда каждый = шестренка, упорно пытающаяся делать свою работу, либо когда каждый = часть сложного организма, способного гибко реагировать на ситуацию. И что лучше, когда кадый орган такого организма может выполнять только свою работу, или когда каждый способен подменить или помочь соседу, послать сигнал о проблемах, и минимизировать вред, дожидаясь решения.
ключевое слово в вашем коментарии — подстраиватся, вы же категорически не хотите ни под кого подстраиватся.
Собрав несколько таких «художников» как вы получим классических лебедя рака и щуку — все хотят своего и в гробу видали интеремы других.
Дальнейшую дискуссию считаю бессмысленной.
Как нибуть когда подросту напишу отдеьлно про эту ситуацию со стороны заказчика, и то как все таки бесит когда вместо самоката за 100 ден ед, который действительно нужен, тебе в итоге пытаются всучить космический корабль за 100000000000 мотивируя это только тем что он круче и сделан с применением самых передовых технологий.
Собрав несколько таких «художников» как вы получим классических лебедя рака и щуку — все хотят своего и в гробу видали интеремы других.
Дальнейшую дискуссию считаю бессмысленной.
Как нибуть когда подросту напишу отдеьлно про эту ситуацию со стороны заказчика, и то как все таки бесит когда вместо самоката за 100 ден ед, который действительно нужен, тебе в итоге пытаются всучить космический корабль за 100000000000 мотивируя это только тем что он круче и сделан с применением самых передовых технологий.
а вы подумайте что будет, если ваша рука, схватившая горячую сковородку будет ждать когда мозг решит что же делать.
Если чего, в данном случае решение принимается в головном мозге. :)
Если чего, в данном случае решение принимается в головном мозге. :)
А вот хрен:
Сгибательный (флексорный) рефлекс — рефлекс защитного типа направленный на удаление повреждающего раздражителя (отдергивание руки от горячего).
ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D0%BD%D0%BD%D0%BE%D0%B9_%D0%BC%D0%BE%D0%B7%D0%B3
Сгибательный (флексорный) рефлекс — рефлекс защитного типа направленный на удаление повреждающего раздражителя (отдергивание руки от горячего).
ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D0%BD%D0%BD%D0%BE%D0%B9_%D0%BC%D0%BE%D0%B7%D0%B3
этим я хочу сказать что «художник» должен творить, а в суровой рыночной реальности, победит ремесленник с чертами художника, который сможет делать так как ему говорят, при этом только в действительно необходимых ситуациях советующий заказчику как необходимо поступить
>1.Менеджмент, состоящий из IT-художников стремится выполнить любую задачу быстро, как только может.
Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
Не потому что старая была плоха, просто писать на старой — скучно!
>2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать.
А когда баги вдруг все-таки случаются художники очень-очень удивляются, ведь они творцы! Багов не допускают! А нормально протестировать проект — лень, потому что это же рутина.
Вместо этого лучше почитать про новый фреймворк, и пофиг что из-за этого одного бага проект заказчика навернулся и фирмы вылетела в копеечку. Творец уверен — в перспективе он принес бы большую прибыль.
3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо.
Очень удобно, придти на новое место, назвать всех «таджиками», себя «д'артаньяном» и предложить переписать проект с нуля. Это постоянное желание «творцов» — переписать с нуля.
Вот только заказчику нужно совсем не это, заказчику нужна скорость реакции. И это именно та причина, почему «таджики» пробиваются в руководство, а «творцы» нет.
P.S. Напомнило из Пелевина «Криейторы нам нафиг не нужны! Нам нужны творцы!».
Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
Не потому что старая была плоха, просто писать на старой — скучно!
>2.Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать.
А когда баги вдруг все-таки случаются художники очень-очень удивляются, ведь они творцы! Багов не допускают! А нормально протестировать проект — лень, потому что это же рутина.
Вместо этого лучше почитать про новый фреймворк, и пофиг что из-за этого одного бага проект заказчика навернулся и фирмы вылетела в копеечку. Творец уверен — в перспективе он принес бы большую прибыль.
3.Как я и написал выше, динамика проекта это главное. Поэтому внесение изменений это не зло, это благо.
Очень удобно, придти на новое место, назвать всех «таджиками», себя «д'артаньяном» и предложить переписать проект с нуля. Это постоянное желание «творцов» — переписать с нуля.
Вот только заказчику нужно совсем не это, заказчику нужна скорость реакции. И это именно та причина, почему «таджики» пробиваются в руководство, а «творцы» нет.
P.S. Напомнило из Пелевина «Криейторы нам нафиг не нужны! Нам нужны творцы!».
В оригинале не «нафиг», но цитата в самое яблочко :)
>Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
И получат по шапке за срыв сроков. А это не в интересах художников, поэтому этого не будет. В крайнем случае хороший менджмент, взвесив все за и против, выделит на новый фреймворк время и одного разработчика, без остановки основного процесса. А вот таджики на новый фреймворк никогда внимания не обратят вообще ни при каких условиях.
>А нормально протестировать проект — лень
Этим должны заниматься тестеры. При этом художник уже давно использует юниттесты, а прогон тестов происходит каждую ночь автоматически, с рассылкой на мыло. Естетсвенно таджики даже не знают что такое тдд, дато тратят, прилежно кучу времени на тестирование. хорошие мальчики.
>Это постоянное желание «творцов» — переписать с нуля.
Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков, и им насрать на заказчика, потому все сделано тяп ляп. Вот об этом и написана статья. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
И получат по шапке за срыв сроков. А это не в интересах художников, поэтому этого не будет. В крайнем случае хороший менджмент, взвесив все за и против, выделит на новый фреймворк время и одного разработчика, без остановки основного процесса. А вот таджики на новый фреймворк никогда внимания не обратят вообще ни при каких условиях.
>А нормально протестировать проект — лень
Этим должны заниматься тестеры. При этом художник уже давно использует юниттесты, а прогон тестов происходит каждую ночь автоматически, с рассылкой на мыло. Естетсвенно таджики даже не знают что такое тдд, дато тратят, прилежно кучу времени на тестирование. хорошие мальчики.
>Это постоянное желание «творцов» — переписать с нуля.
Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков, и им насрать на заказчика, потому все сделано тяп ляп. Вот об этом и написана статья. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
у вас какие-то заказчики и менеджеры в вакууме. В моей практике случается по-другому.
>И получат по шапке за срыв сроков. А это не в интересах художников
Во-первых как получат? Лишат премии? Вы сами писали, художникам она не нужна. Поругают? Художник напишет пост зла о том как его не понимают и уйдет в другую фирму.
Во-вторых в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего.
>Этим должны заниматься тестеры.
Есть еще маленькие проекты, где тестеров, увы, нет.
>Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков
По моему опыту, когда проект активно меняется в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей. И это — нормально.
>И получат по шапке за срыв сроков. А это не в интересах художников
Во-первых как получат? Лишат премии? Вы сами писали, художникам она не нужна. Поругают? Художник напишет пост зла о том как его не понимают и уйдет в другую фирму.
Во-вторых в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего.
>Этим должны заниматься тестеры.
Есть еще маленькие проекты, где тестеров, увы, нет.
>Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков
По моему опыту, когда проект активно меняется в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей. И это — нормально.
>Во-первых как получат?
Уход у другую компанию — неудача. Проект незавершен, а значит удовлетворение не получено. Поэтому художник всегда будет стараться проект завершить.
>в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего
Вы слишком узко пониматете что такое менджмент.
>Есть еще маленькие проекты, где тестеров, увы, нет.
Это проблемы этих маленьких проектов.
>в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей
Это только следсвие работы таджиков и плохого управления проектом.
Уход у другую компанию — неудача. Проект незавершен, а значит удовлетворение не получено. Поэтому художник всегда будет стараться проект завершить.
>в интересах художника — сделать Вещь, дела менеджмента его интересуют меньше всего
Вы слишком узко пониматете что такое менджмент.
>Есть еще маленькие проекты, где тестеров, увы, нет.
Это проблемы этих маленьких проектов.
>в течении нескольких лет он физически уходит далеко от самых смелых расчетов создателей
Это только следсвие работы таджиков и плохого управления проектом.
когда вы уходили из своих проектов, вы все их завершали?
Вы с самого начала вели проект больше двух лет? Ядро ни разу не переписывали?
Только при положительном ответе на все три вопроса имеет смысл что-то обсуждать. Вы берете ситуацию «если бы в тиме и в менеджменте были бы одни такие программисты как я».
Вы с самого начала вели проект больше двух лет? Ядро ни разу не переписывали?
Только при положительном ответе на все три вопроса имеет смысл что-то обсуждать. Вы берете ситуацию «если бы в тиме и в менеджменте были бы одни такие программисты как я».
1. Не все. Радости это не приносило.
2. Больше двух лет нет. Примерно год и девять месяцев.
3. Переписывал, но этого требовало развитие проекта. Кстати получилось очень удачно, и проект работает удачно до сих пор.
2. Больше двух лет нет. Примерно год и девять месяцев.
3. Переписывал, но этого требовало развитие проекта. Кстати получилось очень удачно, и проект работает удачно до сих пор.
О! Это я и хотел услышать.
Теперь сравните эти ответы с вашими же словами выше:
1. Уход у другую компанию — неудача.
2-3. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
И еще раз говорю — это нормально. Это нормальный цикл развития продукта. И совсем не значит что те кто начинали продукт «таджики».
Теперь сравните эти ответы с вашими же словами выше:
1. Уход у другую компанию — неудача.
2-3. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
И еще раз говорю — это нормально. Это нормальный цикл развития продукта. И совсем не значит что те кто начинали продукт «таджики».
1. естественно неудача. неудачи у всех случаются. но все стараются их избежать. иногда не удается.
2-3. стоп, выразился не точно
тот проект в котором я участвовал почти 2 года, я взял не с нуля. Но решение его переписать было не мое, а начальства, потому что проект не держал возросшие нагрузки. Опять же меня взяли на него с изначальной мыслью о его неизбежном переписывании. То есть, грубо говоря, ситуация под вашу не подходит.
Но есть другой проект, над которым я работал с нуля больше года. Желания переписать не возникало ни разу, и не вижу причин почему оно может возникнуть.
2-3. стоп, выразился не точно
тот проект в котором я участвовал почти 2 года, я взял не с нуля. Но решение его переписать было не мое, а начальства, потому что проект не держал возросшие нагрузки. Опять же меня взяли на него с изначальной мыслью о его неизбежном переписывании. То есть, грубо говоря, ситуация под вашу не подходит.
Но есть другой проект, над которым я работал с нуля больше года. Желания переписать не возникало ни разу, и не вижу причин почему оно может возникнуть.
Добавлю. Желания переписать тот проект нет, но уйти с него пришлось. Потому что менеджмент занимается распилом бабла, в наглую его тормозя, и не давая ему ходу. Там заработали уже хорошие бабки.
> Вот только заказчику нужно совсем не это, заказчику нужна скорость реакции. И это именно та причина, почему «таджики» пробиваются в руководство, а «творцы» нет.
Обычно у джамшутов скорость реакции намного ниже, потому что:
а) «ну их нафиг с их требованиями»
б) интриги -> недостаток передаваемой информации -> отсутствие обратной связи
в) общий непрофессионализм в связи с отсутствием интереса к саморазвитию
Обычно у джамшутов скорость реакции намного ниже, потому что:
а) «ну их нафиг с их требованиями»
б) интриги -> недостаток передаваемой информации -> отсутствие обратной связи
в) общий непрофессионализм в связи с отсутствием интереса к саморазвитию
>Сам проект, если он вялотекущий, может надоесть, потому менеджмент стремится сделать проект динамичнее, что бы он развивался быстро, быстрее появлялись новые задачи
Не боитесь, что таджики, любящие размеренность и покой, перегорят от темпа, задаваемого менеджером художником?
Не боитесь, что таджики, любящие размеренность и покой, перегорят от темпа, задаваемого менеджером художником?
Как-то всё сильно идеализировано, нет в жизни такого. И художникам приходитя заниматся рутиной, когда это менеджеры (особенно когда менеджеры), и у «таджиков» проскакивает кретив
> Став начальником, это чувство остается.
Став начальником художник перестаёт быть художником ) А чувство может притупиться до нуля.
Став начальником художник перестаёт быть художником ) А чувство может притупиться до нуля.
Откуда такие выводы?
Личный опыт.
Сейчас я уверен, что мне лучше либо работать «на дядю» на должности «художника» либо работать на себя. Но уж никак не быть «начальником под управлением дяди».
(сейчас я уже давно не «начальник» =)
Сейчас я уверен, что мне лучше либо работать «на дядю» на должности «художника» либо работать на себя. Но уж никак не быть «начальником под управлением дяди».
(сейчас я уже давно не «начальник» =)
может быть вы и правы, хотя я всегда с интересом брал на себя работу менджмента, когда это удавалось. хотя менджмент всегда старался поставить меня на место, либо воспользоваться моей добротой. в первом случае боялись конкуренции, ибо прогресс был очевиден. во второй радовались что можно ничего не делать, а заказчик думает что прогресс это их заслуга)))
> всегда с интересом брал на себя работу менджмента
Согласен. Это интересно!
Но всё упирается в рамки. Ваши термины «художник» и «таджик» — это описание границ возможного поведения: «Художник» делает что хочет, а «Таджик» то, что ему говорят. «Менеджер среднего звена» — это «СуперТаджик», он отличается от обычного тем, что он начальник. И всё )
Согласен. Это интересно!
Но всё упирается в рамки. Ваши термины «художник» и «таджик» — это описание границ возможного поведения: «Художник» делает что хочет, а «Таджик» то, что ему говорят. «Менеджер среднего звена» — это «СуперТаджик», он отличается от обычного тем, что он начальник. И всё )
Складывается впечатление, что автору никогда не доводилось сталкиваться с по-настоящему талантливыми управленцами, как проектного так и корпоративного уровня.
доводилось. могу вспомнить даже двоих, и оба художники.
А менеджер он джумшутом быть не может. Управления без творчества не получается =) Я к тому что какой то совсем пессимистичный взгляд на нашу индустрию получается. По моему мнениею, важно вселить в команду веру не только в то что проект которым она занимается будет успешен (премии, профессиональный рост, признание какое-никакое), но и в то что за ним обязательно последует еще лучший проект. Можно конечно называть это эксплуатацией природного энтузиазма «художников» и корысти «джумшутов», но в конце концов перед нами стоит одна простая задача — делать софт, который будет удовлетворять заказчика.
«Художники» бывают разные. Я лично считаю за художников тех, кому нравится сам процесс. А они часто не особо стремятся к финальному результату. Им бы все что-нить улучшить. Таких надо все время одергивать, если они сами еще не научились =)
таких не бывает. это стеореотип. скорее это таджики которым не хочется работать. вот они и эмитируют какую-то деятельность, прикрывая это типа улучшением. для худолжника всегда важен результат. и если долгое время результата нет, он не может быть удовлетворен.
Такие есть, поверьте. Я однажды писал проект с таким. Ему периодически приходили идеи улучшения архитектуры и он переписывал половину проекта(не маленького, кстати). И такое было не раз. Притом что проект был не коммерческий, так что симулировать бурную деятельность было бесполезно =)
Да-да… Знаем таких. Для коммерческой стороны дела конечно катастрофично, но в долгосрочной перспективе метод «до основанья, а затем» иногда приводит к интересным технологическим прорывам местного значения.
это недостаток знаний/ума
когда-то я тоже стремился переписать свой же код спустя полгода. Потому что постоянно развивался и понимал спустя время свои ошибки. Но сейчас меня мой код вполне устраивает. Я пишу сразу хорошо, и желания переписывать у меня нет.
когда-то я тоже стремился переписать свой же код спустя полгода. Потому что постоянно развивался и понимал спустя время свои ошибки. Но сейчас меня мой код вполне устраивает. Я пишу сразу хорошо, и желания переписывать у меня нет.
> Я лично считаю за художников тех, кому нравится сам процесс. А они часто не особо стремятся к финальному результату.
Это не «Художники», это — «Лузеры»
Это не «Художники», это — «Лузеры»
>> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
Я целиком и полностью согласен с Джоелем Спольским — спец может быть умным и может делать дела. Художник в вашем понимании по определению делать второе не в состоянии (читаем про рутину и баги в топике — обычный процесс любого программиста). Ему важно что-то сделать на модных рюшечках, «предоставить инфраструктуру», как они любят говорить (а дальше с багами вы сами ебитесь).
У меня есть такой художник в команде — собственно, написал доменную модель и слой данных на проекте. Баги искать не хочет, тестировать не хочет — правит что-то только после того, как мордой тыкнешь. Уходить тоже не хочет — обиделся, надулся на всех, сидит сычем в своем закутке, что-то налево делает. В общем, иметь таких художников на проекте — врагу не пожелаешь.
Вообще, с делением на два вида я бы не соглашался. Как минимум любого разработчика можно классифицировать на четыре типа:
1) те, кто умен, и кто может доводить дела до завершения
2) те, кто умен, но не может доводить дела до завершения
3) те, кто не умен, но может доводить дела до завершения
4) те, кто не умен, и не может доводить дела до завершения
Как правило, тип 3 и 4 не проходят испытательный срок. Но тип 3 был очень распространен в докизисные времена, и, судя по всему, раз автору удалось поработать в РБК-Софте, то таджики — как раз про них.
Вообще, как писал один мудрый человек тут:
По симптомам это типичная ошибка, увы. Наверное, чуть ли не каждый разработчик в своей карьере пытается написать какой-нибудь обобщенный управлятор. Из этого ничего не получается, после чего возможны два варианта — либо разработчик ничего не понимает и считает, например, что управлятор был недостаточно обобщенным, либо переходит на светлую сторону и становится хорошим программистом.
А вы сами, судя по всему, что вы тут пишете про баги и рутину, тип 2 — истинный творец или еще не написали свой управлятор:)
И еще совет — МакКоннела прочитайте. Ну честно, прочитайте МакКоннела. Если читали, перечитайте еще раз, более вдумчиво — там с цифрами, с толком, с расстановкой. Как раз про то, что вы тут говорите, но с совершенно другими выводами. Может, поймете что.
Я целиком и полностью согласен с Джоелем Спольским — спец может быть умным и может делать дела. Художник в вашем понимании по определению делать второе не в состоянии (читаем про рутину и баги в топике — обычный процесс любого программиста). Ему важно что-то сделать на модных рюшечках, «предоставить инфраструктуру», как они любят говорить (а дальше с багами вы сами ебитесь).
У меня есть такой художник в команде — собственно, написал доменную модель и слой данных на проекте. Баги искать не хочет, тестировать не хочет — правит что-то только после того, как мордой тыкнешь. Уходить тоже не хочет — обиделся, надулся на всех, сидит сычем в своем закутке, что-то налево делает. В общем, иметь таких художников на проекте — врагу не пожелаешь.
Вообще, с делением на два вида я бы не соглашался. Как минимум любого разработчика можно классифицировать на четыре типа:
1) те, кто умен, и кто может доводить дела до завершения
2) те, кто умен, но не может доводить дела до завершения
3) те, кто не умен, но может доводить дела до завершения
4) те, кто не умен, и не может доводить дела до завершения
Как правило, тип 3 и 4 не проходят испытательный срок. Но тип 3 был очень распространен в докизисные времена, и, судя по всему, раз автору удалось поработать в РБК-Софте, то таджики — как раз про них.
Вообще, как писал один мудрый человек тут:
По симптомам это типичная ошибка, увы. Наверное, чуть ли не каждый разработчик в своей карьере пытается написать какой-нибудь обобщенный управлятор. Из этого ничего не получается, после чего возможны два варианта — либо разработчик ничего не понимает и считает, например, что управлятор был недостаточно обобщенным, либо переходит на светлую сторону и становится хорошим программистом.
А вы сами, судя по всему, что вы тут пишете про баги и рутину, тип 2 — истинный творец или еще не написали свой управлятор:)
И еще совет — МакКоннела прочитайте. Ну честно, прочитайте МакКоннела. Если читали, перечитайте еще раз, более вдумчиво — там с цифрами, с толком, с расстановкой. Как раз про то, что вы тут говорите, но с совершенно другими выводами. Может, поймете что.
>Ему важно что-то сделать на модных рюшечках
Это бред! Вы ничего не поняли.
>Баги искать не хочет, тестировать не хочет
И правильно! Этим должны заниматься тестеры.
>В общем, иметь таких художников на проекте — врагу не пожелаешь.
Да вы же сами во всем виноваты! С собой разберитесь, прежде чем на других вину спихивать.
>оработать в РБК-Софте
Я не работал в РБК-Софте. Это другое подразделение холдинга. И ум тут не причем вообще.
Это бред! Вы ничего не поняли.
>Баги искать не хочет, тестировать не хочет
И правильно! Этим должны заниматься тестеры.
>В общем, иметь таких художников на проекте — врагу не пожелаешь.
Да вы же сами во всем виноваты! С собой разберитесь, прежде чем на других вину спихивать.
>оработать в РБК-Софте
Я не работал в РБК-Софте. Это другое подразделение холдинга. И ум тут не причем вообще.
Хорошо, наверное, жить в черно-белом мире. Просто, и все схемы строятся логичные-логичные.
Знаете, я подумал что главный вопрос в том с какой стороны баррикад смотреть.
Давайте сделаем простой опросник. Я отпишу две ситуации, отдельно для тимлидов и отдельно для разработчиков. Вам я предлагаю плюсовать за тот вариант, который вам больше нравится.
Большая просьба не минусовать (иначе результат будет не точным) и не голосовать за оба варианта, т.е. Вы или программист или тимлид (как в жизни).
Давайте сделаем простой опросник. Я отпишу две ситуации, отдельно для тимлидов и отдельно для разработчиков. Вам я предлагаю плюсовать за тот вариант, который вам больше нравится.
Большая просьба не минусовать (иначе результат будет не точным) и не голосовать за оба варианта, т.е. Вы или программист или тимлид (как в жизни).
1. Вы — тимлид на фрилансе. Вам предложили сделать интернет-магазин, с очень сжатыми сроками (2 недели, скажем).
Вы можете взять в помощь двух программистов, кого вы выберете?
Вы можете взять в помощь двух программистов, кого вы выберете?
2. Вы — программист в тиме из трех человек, задача сделать тот же магазин в те же сроки. С кем бы вы хотели работать?
Идея не очень хорошая. По одной простой причине. Вы не сможете понять причины выбора. Я сразу скажу что всегда предпочту работу с художниками.
Но вообще тема статьи немножно все таки другая. В неё говорится о менджменте.
Но вообще тема статьи немножно все таки другая. В неё говорится о менджменте.
Про причины выбора можно посмотреть в комментариях.
Здесь же мы видим обобщения — работать с художниками в одном тиме народ не против (4/3), что не говорит практически ни о чем.
Но вот при жестком дедлайне никто (!) не хотел бы художником руководить.
И это именно то, с чем приходится сталкиваться IRL.
Потому что в критический момент может оказаться проще написать самому, чем долго спорить о преимуществах SVN перед CVS.
Здесь же мы видим обобщения — работать с художниками в одном тиме народ не против (4/3), что не говорит практически ни о чем.
Но вот при жестком дедлайне никто (!) не хотел бы художником руководить.
И это именно то, с чем приходится сталкиваться IRL.
Потому что в критический момент может оказаться проще написать самому, чем долго спорить о преимуществах SVN перед CVS.
вы не знаете что такое художник. это не тот человек кто несмотря ни на что хочет пробовать новые феньки. я уже устал говрить что для художника главное что бы его работой были довольны. и в дедлайн он прекрасно понимает что единственный путь это сдать проект вовремя. адекватный человек не будет переписывать всеь код зная что завтра проект должен быть на продакшене и приносить бабло. и не будет вдруг в последний день проекта менять cvs на svn. Это глупо просто.
поймите художник это не синоним фанатика.
поймите художник это не синоним фанатика.
моя любимая фраза, которую я часто повторяю «не доводи до фанатизма»
Я отвечу с позиции тимлида — с художниками.
Тупо потому что эффективнее. Тем более в сжатые сроки.
Тупо потому что эффективнее. Тем более в сжатые сроки.
Цитату «Пиление различных бюджетов это древняя русская национальная забава!», если Вы не против, добавлю в список любимых цитат. Так не против?
НЛО прилетело и опубликовало эту надпись здесь
1. Конечно я упростил. Но я считаю что все люди стремятся к этим двум типам.
2. правильно чувак уходит. от людей которые считают что sql + jdbc это хорошо, бежать надо как от огня. думаю вы объясняете свою лень и глупость тем что зарабатывает бабло для заказчика. ну чтож, флаг вам в руки. только вы как были говнокодером так им и останетесь.
>И в итоге имеет код, который понимает только большой специалист
Спешу вас разочаровать. Я не встречал программиста, для которого было бы проблемой понять подобный код. Из этого вывод что не специалист нужен а мозги. Когда их нет, и букварь сложной книгой покажется, так может отменим первый класс?
2. правильно чувак уходит. от людей которые считают что sql + jdbc это хорошо, бежать надо как от огня. думаю вы объясняете свою лень и глупость тем что зарабатывает бабло для заказчика. ну чтож, флаг вам в руки. только вы как были говнокодером так им и останетесь.
>И в итоге имеет код, который понимает только большой специалист
Спешу вас разочаровать. Я не встречал программиста, для которого было бы проблемой понять подобный код. Из этого вывод что не специалист нужен а мозги. Когда их нет, и букварь сложной книгой покажется, так может отменим первый класс?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
И знаете, как пофиксал?
catch (StackOverflowError)
нормальное временное решение. если он конечно понимает что это злостный костыль и в отпуске лучше не задерживаться, либо попросить коллегу исправить (поставив потом много пива). Если не понимает, и думает что это нормально, то конечно неуд. Но все мы когда-то чего-то не знали. Главное что он хочет знать.
catch (StackOverflowError)
нормальное временное решение. если он конечно понимает что это злостный костыль и в отпуске лучше не задерживаться, либо попросить коллегу исправить (поставив потом много пива). Если не понимает, и думает что это нормально, то конечно неуд. Но все мы когда-то чего-то не знали. Главное что он хочет знать.
нет, я так не считаю. конечно же не во всех, и даже считаю что хебернейт не очень хорошая штука для малых и средних проектов. Тут гораздо удобнее будет что-то на основе паттерна Активрекорд. Но заметьте, я ни слова не сказал что эта штука для меня слишком сложная, не разберешь ничего и тд. И уж точно в страшном сне я видел чистый sql в контроллере. спасибо, проходили.
но повторяю, есть нормальные критерии выбора того или иного решения. возможно в вашем случае лучше было бы выбрать что-то другое. но вы же сказали «понимает только большой специалист». То есть это для вас проблема. То есть по сути вы говрите «у нас не хватает мозгов для того что бы это понять, поэтому это плохо». Так вот, плох не хибернейт, а отстувие у вас мозгов.
но повторяю, есть нормальные критерии выбора того или иного решения. возможно в вашем случае лучше было бы выбрать что-то другое. но вы же сказали «понимает только большой специалист». То есть это для вас проблема. То есть по сути вы говрите «у нас не хватает мозгов для того что бы это понять, поэтому это плохо». Так вот, плох не хибернейт, а отстувие у вас мозгов.
В первом топике я постарался серьёзно подискутировать по данной теме. Увидев этот топик, испытал небольшое удивление — неужели снова будет о плохишах «IT-таджиках» и молодчагах «IT-художниках»? Казалось бы, что тут ещё можно нового придумать? Оказалось, что можно. Прочёл до конца, опять написал длинный комментарий. Хорошо, что нажал кнопку «предпросмотр». Потому что ничего очень нового в этом комментарии не оказалось. Всё те же вопросы, всё те же «не согласен». Стёр. И написал вот что:
1. Почему таджики и художники? Почему такое странное противопоставление? Да, я прочитал постскриптум. И всё же. Да, таджики едут в Москву работать. А задумывались ли Вы, почему? Да, именно, в Москве больше платят. Несоизмеримо больше. Так что же, не ехать теперь? Или Вы осуждаете всех тех, кто переезжает в другой город/страну, так как там они нашли более хорошую (высокооплачиваемую) вакансию? Ну тогда можете смело поменять на IT-американцев. В Америке, например, переехать в другой город/штат в поисках работы — обычное дело. Ладно, разобрались с таджиками и причинами их переезда. Почему в противовес алчным таджикам Вы ставите художников? Художник, в первую очередь, творит от души. Делает то, что ему нравится и делает так, как нравится. Захотелось написать картину, используя только жёлтую краску, и напишет… Только вот делает он это для себя. А потом, при необходимости/возможности, продаст эту картину. Зачем же художник осознанно идёт туда, где ему ставят задачу, да ещё и ограничивают сроками и средствами? Творчество не терпит приказов и слов «надо».
Я не хочу домысливать за Вас, но вывод начал напрашиваться уже после первой статьи. Вы мните себя художником, так как Вам скучно выполнять рутинные задачи, хочется «творить» и вообще художники офигенные ребята. А из-за того, что общество не принимает эту позицию и не приемлет подобного, конфликт. И конфликт решается на глазах хабра. Ай-яй, эти нехорошие «IT-таджики», художникам дорогу!
2. Где и в каких условиях Вы наткнулись на описываемых Вами IT-таджиков и непроглядно тупых менеджеров? Где водятся такие заказчики, которые спокойно смотрят, как проект затягивается на годы?
Не знаю, может мне повезло больше, но там, где я работаю, принята оплата человекочасов. Перед началом разработки некоего функционала, заказчику предоставляется план выполнения работ, оценка трудозатрат (в человекочасах), стоимость человекочасов для определённых типов задач. И всё. И заказчик заплатит определённую сумму. И спросит по полной программе, если задача не будет выполнена в срок. И тут уж как ни тяни, а надо успевать и укладываться. Конечно, это упрощённая модель, в действительности всё осложняется тем, что по ходу разработки заказчик придумывает новые задачи и сроки и оплата меняются, но не в этом суть.
3. Разработчик (не программист) в любом случае личность творческая. Более того, это адская смесь из творчества и науки. У нас, например, нет никаких дресс-кодов, можно самому выбирать, в какие часы будешь работать, да и вообще отношение к разработчикам очень трепетное и терпеливое. И это правильно. Не на заводе, не на конвейрной ленте работаем. Поэтому кичиться тем, что «художник» как-то даже странно. Ну да, ну и что?
4. Хочется ещё раз вернуться к теме работы и оплаты. Мне очень жаль, что я не запомнил, где я слышал и кто сказал очень интересные слова. Смысл был таков: Одного известного человека спросили, сколько он получает и нравится ли ему его работа. Тот ответил, что получает столько, что работа нравится. Был бы признателен, если кто-то напомнит, кто же это был. Так вот. Дело в том, что я отчасти разделяю эту позицию. И совсем не потому, что я такой алчный и меня интересуют только деньги. Но потому, что я не удовлетворил свою потребность в тех аспектах, которые требуют денег. Вспоминаем пирамиду Маслоу. Так вот деньги мне нужны для обеспечения своих естественных физиологических потребностей, чтобы чувствовать себя в безопасности. Возможно, получая больше, я бы больше задумывался над остальным. Но пока я себя не ощущаю достаточно обеспеченным и поэтому работу рассматриваю в плане заработка. И многие на постсоветском пространстве в этой же ситуации. Западнее зарплаты более адекватны и общество совсем другое и с другими потребностями.
5. Третья статья будет? Если будет, то от меня совет — пожалуйста, можно ещё менее пафосно и по делу? И очень хочется после слов «Ниже я докажу» увидеть доказательства.
1. Почему таджики и художники? Почему такое странное противопоставление? Да, я прочитал постскриптум. И всё же. Да, таджики едут в Москву работать. А задумывались ли Вы, почему? Да, именно, в Москве больше платят. Несоизмеримо больше. Так что же, не ехать теперь? Или Вы осуждаете всех тех, кто переезжает в другой город/страну, так как там они нашли более хорошую (высокооплачиваемую) вакансию? Ну тогда можете смело поменять на IT-американцев. В Америке, например, переехать в другой город/штат в поисках работы — обычное дело. Ладно, разобрались с таджиками и причинами их переезда. Почему в противовес алчным таджикам Вы ставите художников? Художник, в первую очередь, творит от души. Делает то, что ему нравится и делает так, как нравится. Захотелось написать картину, используя только жёлтую краску, и напишет… Только вот делает он это для себя. А потом, при необходимости/возможности, продаст эту картину. Зачем же художник осознанно идёт туда, где ему ставят задачу, да ещё и ограничивают сроками и средствами? Творчество не терпит приказов и слов «надо».
Я не хочу домысливать за Вас, но вывод начал напрашиваться уже после первой статьи. Вы мните себя художником, так как Вам скучно выполнять рутинные задачи, хочется «творить» и вообще художники офигенные ребята. А из-за того, что общество не принимает эту позицию и не приемлет подобного, конфликт. И конфликт решается на глазах хабра. Ай-яй, эти нехорошие «IT-таджики», художникам дорогу!
2. Где и в каких условиях Вы наткнулись на описываемых Вами IT-таджиков и непроглядно тупых менеджеров? Где водятся такие заказчики, которые спокойно смотрят, как проект затягивается на годы?
Не знаю, может мне повезло больше, но там, где я работаю, принята оплата человекочасов. Перед началом разработки некоего функционала, заказчику предоставляется план выполнения работ, оценка трудозатрат (в человекочасах), стоимость человекочасов для определённых типов задач. И всё. И заказчик заплатит определённую сумму. И спросит по полной программе, если задача не будет выполнена в срок. И тут уж как ни тяни, а надо успевать и укладываться. Конечно, это упрощённая модель, в действительности всё осложняется тем, что по ходу разработки заказчик придумывает новые задачи и сроки и оплата меняются, но не в этом суть.
3. Разработчик (не программист) в любом случае личность творческая. Более того, это адская смесь из творчества и науки. У нас, например, нет никаких дресс-кодов, можно самому выбирать, в какие часы будешь работать, да и вообще отношение к разработчикам очень трепетное и терпеливое. И это правильно. Не на заводе, не на конвейрной ленте работаем. Поэтому кичиться тем, что «художник» как-то даже странно. Ну да, ну и что?
4. Хочется ещё раз вернуться к теме работы и оплаты. Мне очень жаль, что я не запомнил, где я слышал и кто сказал очень интересные слова. Смысл был таков: Одного известного человека спросили, сколько он получает и нравится ли ему его работа. Тот ответил, что получает столько, что работа нравится. Был бы признателен, если кто-то напомнит, кто же это был. Так вот. Дело в том, что я отчасти разделяю эту позицию. И совсем не потому, что я такой алчный и меня интересуют только деньги. Но потому, что я не удовлетворил свою потребность в тех аспектах, которые требуют денег. Вспоминаем пирамиду Маслоу. Так вот деньги мне нужны для обеспечения своих естественных физиологических потребностей, чтобы чувствовать себя в безопасности. Возможно, получая больше, я бы больше задумывался над остальным. Но пока я себя не ощущаю достаточно обеспеченным и поэтому работу рассматриваю в плане заработка. И многие на постсоветском пространстве в этой же ситуации. Западнее зарплаты более адекватны и общество совсем другое и с другими потребностями.
5. Третья статья будет? Если будет, то от меня совет — пожалуйста, можно ещё менее пафосно и по делу? И очень хочется после слов «Ниже я докажу» увидеть доказательства.
1. Художник делает это не для себя. Иначе он бы никому не показывал бы свои картины.
2. Вы видимо работаете в слишком маленькой компании занимающейся клепанием сайтов на заказ. Я не знаю структуру вашей компании, но думаю в ней все равно можно выделить все три уровня. Но если она совсем небольшая, то ваш непосредственный начальник и является заказчиком. Таким образом описанной здесь проблемы нет. Вообще речь идет о долгосрочных проектах. А не о сайтах-визитках.
3. Не в любом случае. И это не связно с отношением к ним.
4. то что вы так рассматриваете работу не означает что это хорошо. у меня другое мировозрение.
5. хотелось бы что бы вы не просто увидели доказательства, но и постарались их понять.
2. Вы видимо работаете в слишком маленькой компании занимающейся клепанием сайтов на заказ. Я не знаю структуру вашей компании, но думаю в ней все равно можно выделить все три уровня. Но если она совсем небольшая, то ваш непосредственный начальник и является заказчиком. Таким образом описанной здесь проблемы нет. Вообще речь идет о долгосрочных проектах. А не о сайтах-визитках.
3. Не в любом случае. И это не связно с отношением к ним.
4. то что вы так рассматриваете работу не означает что это хорошо. у меня другое мировозрение.
5. хотелось бы что бы вы не просто увидели доказательства, но и постарались их понять.
1. Художник делает это для себя. Ему доставляет удовольствие сам процесс, мысли о нём. Показывают потом только самое лучшее, чтобы потешить своё самолюбие. А если творчество подвергается критике, то либо очень болезненно на это реагируют, что выливается в оскорбления, либо игнорируют, оправдывая себя тем, что остальные просто не могут понять, насколько крута «картина».
2. Мимо. Хотя, это и не очень важно, но если уж Вы затронули эту тему, то стоит ответить, пожалуй. Я работаю в очень крупной международной организации, которая имеет представительства по всему миру. Специализация — крупный outsourcing. Из «местных» клиентов — только крупные гос. предприятия, крупные банки. По миру, из известных — AIG, Canon, Standard & Poor's, Sun Microsystems, T-Mobile, На данный момент в нашем городе штат разработчиков (программисты, менеджеры, тестеры, архитекторы, админы, т.е. все те, кто так или иначе прикладывает свою руку к разработке) около 450 человек. В прошлом году было около 650. Лично я работаю в проекте, который длится с ноября 2007 (активная разработка с января 2008). Я в проекте с самого начала и до сих пор, в данный момент занимаюсь тех. поддержкой, параллельно помогаю в других проектах. С вебом(и сайтами-визитками тем более) никак не связано вообще. Ну да это мелочь. В Вашу теорию не вписывается, а значит моё мнение можно не учитывать.
3. Если разработчик не может творчески подойти к решению задачи, то это не разработчик, а кодер. Если разработчик не умеет мыслить логически и не дружит с технической составляющей разработки, то это в лучшем случае аналитик, а скорее «забавный системный архитектор». Хотя, нет… без логики никуда.
4. Это не хорошо и не плохо. Зато это объясняет то, что происходит. И это важно понимать. Не надо думать, что человек «таджик», если он думает о деньгах и как их заработать. Может, они ему нужны?
5. К сожалению, я не только доказательств не вижу, я ещё и не вижу ответов на вопросы. Вы стараетесь цепляться за фразы, а не отвечать по существу. А как понять доказательства и ответы, которых Вы не даёте — это уже из области фантастики.
Кстати, убедившись на живом примере меня, нетрудно сделать вывод, что в людях Вы разбираетесь не самым лучшим образом. Воздержусь от продолжения логической цепочки.
2. Мимо. Хотя, это и не очень важно, но если уж Вы затронули эту тему, то стоит ответить, пожалуй. Я работаю в очень крупной международной организации, которая имеет представительства по всему миру. Специализация — крупный outsourcing. Из «местных» клиентов — только крупные гос. предприятия, крупные банки. По миру, из известных — AIG, Canon, Standard & Poor's, Sun Microsystems, T-Mobile, На данный момент в нашем городе штат разработчиков (программисты, менеджеры, тестеры, архитекторы, админы, т.е. все те, кто так или иначе прикладывает свою руку к разработке) около 450 человек. В прошлом году было около 650. Лично я работаю в проекте, который длится с ноября 2007 (активная разработка с января 2008). Я в проекте с самого начала и до сих пор, в данный момент занимаюсь тех. поддержкой, параллельно помогаю в других проектах. С вебом(и сайтами-визитками тем более) никак не связано вообще. Ну да это мелочь. В Вашу теорию не вписывается, а значит моё мнение можно не учитывать.
3. Если разработчик не может творчески подойти к решению задачи, то это не разработчик, а кодер. Если разработчик не умеет мыслить логически и не дружит с технической составляющей разработки, то это в лучшем случае аналитик, а скорее «забавный системный архитектор». Хотя, нет… без логики никуда.
4. Это не хорошо и не плохо. Зато это объясняет то, что происходит. И это важно понимать. Не надо думать, что человек «таджик», если он думает о деньгах и как их заработать. Может, они ему нужны?
5. К сожалению, я не только доказательств не вижу, я ещё и не вижу ответов на вопросы. Вы стараетесь цепляться за фразы, а не отвечать по существу. А как понять доказательства и ответы, которых Вы не даёте — это уже из области фантастики.
Кстати, убедившись на живом примере меня, нетрудно сделать вывод, что в людях Вы разбираетесь не самым лучшим образом. Воздержусь от продолжения логической цепочки.
1. Не надо так буквально относится к метафоре, и упрощаете. Я говрю о тех художниках, которые любят демонстрироваться на выставках. Может быть есть и такие кто только для себя работает. Но таких меньшенство, иначе мы бы не видели их картин.
2. только крупные гос. предприятия
гы, видел я их сайты. это не вы берлогу для ЕР делали? )))
На самом деле, ничего не меняется. Вы заинтересованы раздвинуть сроки, как и описано в моей статье. Сами это признаете.
3. Может подойти, может и не подойти. Это смотря как попросите))) Самому ему это не надо.
4. они всем нужны. и мне в том числе. разница в том, что я готов сделать за эти деньги. Одни ничего лишнего делать не будут, потому что им за это не платят. Грубо говря если они видят что-то что можно делать а можно не делать, они не делают. Я же думаю как это поможет проекту. Если поможет я делаю, немотря на то что за это я не получу большую зарплату.
5. доказательства в логике которую я предоставил. я не виноват что вы её не поняли.
2. только крупные гос. предприятия
гы, видел я их сайты. это не вы берлогу для ЕР делали? )))
На самом деле, ничего не меняется. Вы заинтересованы раздвинуть сроки, как и описано в моей статье. Сами это признаете.
3. Может подойти, может и не подойти. Это смотря как попросите))) Самому ему это не надо.
4. они всем нужны. и мне в том числе. разница в том, что я готов сделать за эти деньги. Одни ничего лишнего делать не будут, потому что им за это не платят. Грубо говря если они видят что-то что можно делать а можно не делать, они не делают. Я же думаю как это поможет проекту. Если поможет я делаю, немотря на то что за это я не получу большую зарплату.
5. доказательства в логике которую я предоставил. я не виноват что вы её не поняли.
1. У меня есть друг — фотограф, знакомая художница и два двоюродных брата — оба художники-дизайнеры. Я имею представление, сколько их работ «мы» не видим. Удалились от изначального пункта 1.
2. Я не знаю, что такое берлога для ЕР. Я вообще сайтами не занимаюсь. В основном, мы занимаемся разработкой систем… Финансовых, банковских, телерадио, и.т.д. Ещё проще говоря — это не сайты. В том смысле, что если эти системы и имеют веб-интерфейс, то сугубо корпоративный. Я не заинтересован двигать сроки. На разработку нашего проекта сроки были поставлены и с нашей стороны соблюдены. Были задержки со стороны заказчика. Просто проект большой, поэтому и долго. Далее мне вообще не имеет смысла суетиться. Поддерживать проект ещё долго, ошибки исправлять надо в отведённые сроки. Где я признавал, что заинтересован что-то двигать?
3. Самому не надо. Для решения задачи — надо. Есть кодеры, которые выполняют чётко поставленные задачи. В основном, это junior developer-ы и простые программисты. Есть разработчики, которые присматривают за молодыми и решают сложные проблемы. Есть лиды, которые решают проблемы на уровне архитектуры и присматривают за всеми остальными. Из вышеописанных не иметь творческого подхода к делу могут лишь junior-ы. Так как остальным надо что-то придумывать. Так или иначе, в том или ином виде.
4. Я тоже стараюсь делать всё, чтобы проект был успешен и все оказались довольны. И зарплату не повышают ежесекундно. Но я работаю на перспективу. Если я поучаствовал в 5 проектах и все они оказались успешны, и я был активен — это даёт право надеяться на повышение в должности и на более тяжёлые задачи и проекты. А это всё даёт… деньги. Ну так вышло… опять эти бумажки…
5. А что есть доказательство? Доказательство — логическая цепочка утверждений, основанная на каких-либо аксиомах и подтверждающая или опровергающая какое-то другое утверждение. Ваши слова — "… рутина это то что нужно заказчику. Ниже я докажу что это ошибка." Не хочется сильно придираться, но само по себе утверждение, которое Вы хотите опровергнуть, как-то уже печалит. Заказчику не важно — рутина у разработчиков или творческий процесс с цыганами и медведями, которые на балалайках играют.
Давайте вернёмся к происхождению терминов «IT-художник» и «IT-таджик», пожалуйста! Можете рассказать, почему именно так, а не иначе?
P.S. Не надо быть таким категоричным. Не все живут в default-city, не все клепают сайты. не все йогурты одинаково полезны…
2. Я не знаю, что такое берлога для ЕР. Я вообще сайтами не занимаюсь. В основном, мы занимаемся разработкой систем… Финансовых, банковских, телерадио, и.т.д. Ещё проще говоря — это не сайты. В том смысле, что если эти системы и имеют веб-интерфейс, то сугубо корпоративный. Я не заинтересован двигать сроки. На разработку нашего проекта сроки были поставлены и с нашей стороны соблюдены. Были задержки со стороны заказчика. Просто проект большой, поэтому и долго. Далее мне вообще не имеет смысла суетиться. Поддерживать проект ещё долго, ошибки исправлять надо в отведённые сроки. Где я признавал, что заинтересован что-то двигать?
3. Самому не надо. Для решения задачи — надо. Есть кодеры, которые выполняют чётко поставленные задачи. В основном, это junior developer-ы и простые программисты. Есть разработчики, которые присматривают за молодыми и решают сложные проблемы. Есть лиды, которые решают проблемы на уровне архитектуры и присматривают за всеми остальными. Из вышеописанных не иметь творческого подхода к делу могут лишь junior-ы. Так как остальным надо что-то придумывать. Так или иначе, в том или ином виде.
4. Я тоже стараюсь делать всё, чтобы проект был успешен и все оказались довольны. И зарплату не повышают ежесекундно. Но я работаю на перспективу. Если я поучаствовал в 5 проектах и все они оказались успешны, и я был активен — это даёт право надеяться на повышение в должности и на более тяжёлые задачи и проекты. А это всё даёт… деньги. Ну так вышло… опять эти бумажки…
5. А что есть доказательство? Доказательство — логическая цепочка утверждений, основанная на каких-либо аксиомах и подтверждающая или опровергающая какое-то другое утверждение. Ваши слова — "… рутина это то что нужно заказчику. Ниже я докажу что это ошибка." Не хочется сильно придираться, но само по себе утверждение, которое Вы хотите опровергнуть, как-то уже печалит. Заказчику не важно — рутина у разработчиков или творческий процесс с цыганами и медведями, которые на балалайках играют.
Давайте вернёмся к происхождению терминов «IT-художник» и «IT-таджик», пожалуйста! Можете рассказать, почему именно так, а не иначе?
P.S. Не надо быть таким категоричным. Не все живут в default-city, не все клепают сайты. не все йогурты одинаково полезны…
1. И все они работают в стол)))) А то что им большенство своих работ стыдно показать, то это горит лишь об их профессионализме. Уверен они мечтают показывать все что делают.
2. Кто устанавливает сроки?
3. К решению задачи можно подойти творчески а можно в лоб. Иногда есть только один вариант, тогда он сможет и творчески, а так будет выбирать что проще для него.
4. Все так горят. Я был бы удивлен если бы вы сказали бы иначе.
5. Логика проста. Человеку работающему за бабло выгодно затягивать проект. Если проект укладывается в отведенные сроки, ему нет смысла его делать быстрее. Художнику есть смысл.
2. Кто устанавливает сроки?
3. К решению задачи можно подойти творчески а можно в лоб. Иногда есть только один вариант, тогда он сможет и творчески, а так будет выбирать что проще для него.
4. Все так горят. Я был бы удивлен если бы вы сказали бы иначе.
5. Логика проста. Человеку работающему за бабло выгодно затягивать проект. Если проект укладывается в отведенные сроки, ему нет смысла его делать быстрее. Художнику есть смысл.
1. Чужая душа — потёмки.
2. В самом начале было оговорено, как скоро мы (разработчики) должны отреагировать на полученную заявку о проблеме и в течение какого времени должны решить. Существует несколько уровней проблем — simple, important, urgent, critical. Для каждой есть объяснение. Конечно, можно оспаривать статус, но такое происходит крайне редко. Для critical сроки очень короткие, поверьте.
4. Мы всe тут просто говорим. Однако, я стараюсь говорить правду о том, что есть или то, что думаю или считаю нужным сказать. Мне кажется, что поводов сомневаться в искренности моих слов, я не давал. В подтверждение моих слов просто приведу два факта (чего и от вас хотел бы — фактов). Вчера (в пятницу) я ушёл с работы в 10 вечера, т.к. в последний момент обнаружил пару проблем в билде, который сегодня получит заказчик. Мог бы не заметить, никто бы мне ничего не сказал. Пару недель назад остался на работе до утра, т.к. остался помогать коллеге. Ни об одном из этих событий высшее руководство не знает. Зато знают коллеги, я услышал «спасибо». Цену этого слова я тоже знаю.
5. Нет тут никакой логики. Если проект укладывается в отведённые сроки — это уже хорошо, как минимум. Специально тянуть никто ничего не будет, но есть два момента. Заказчику не отдадут продукт намного раньше сроков. Выполнение задачи занимает всё время, отведённое на эту задачу. Да и потом, редко бывает, что совсем нечего делать. Завершённый раньше срока проект означает освободившийся ресурс. Свободный ресурс всегда полезен руководству компании. Его можно привлечь на помощь, его можно задействовать в новом проекте.
2. В самом начале было оговорено, как скоро мы (разработчики) должны отреагировать на полученную заявку о проблеме и в течение какого времени должны решить. Существует несколько уровней проблем — simple, important, urgent, critical. Для каждой есть объяснение. Конечно, можно оспаривать статус, но такое происходит крайне редко. Для critical сроки очень короткие, поверьте.
4. Мы всe тут просто говорим. Однако, я стараюсь говорить правду о том, что есть или то, что думаю или считаю нужным сказать. Мне кажется, что поводов сомневаться в искренности моих слов, я не давал. В подтверждение моих слов просто приведу два факта (чего и от вас хотел бы — фактов). Вчера (в пятницу) я ушёл с работы в 10 вечера, т.к. в последний момент обнаружил пару проблем в билде, который сегодня получит заказчик. Мог бы не заметить, никто бы мне ничего не сказал. Пару недель назад остался на работе до утра, т.к. остался помогать коллеге. Ни об одном из этих событий высшее руководство не знает. Зато знают коллеги, я услышал «спасибо». Цену этого слова я тоже знаю.
5. Нет тут никакой логики. Если проект укладывается в отведённые сроки — это уже хорошо, как минимум. Специально тянуть никто ничего не будет, но есть два момента. Заказчику не отдадут продукт намного раньше сроков. Выполнение задачи занимает всё время, отведённое на эту задачу. Да и потом, редко бывает, что совсем нечего делать. Завершённый раньше срока проект означает освободившийся ресурс. Свободный ресурс всегда полезен руководству компании. Его можно привлечь на помощь, его можно задействовать в новом проекте.
2. Не понял. То есть у вас есть 4 возможных периода времени, на каждый статус? И если задача требует больше времени чем есть, или скажем меньше чем минимальный срок, вы должны назвать строго один из четырех? Но это я так понимаю относится только к багам, а к новым задачам и проетам тоже только 4 возможных ответа? Или все таки вы подходите к этому вопросу более гибко?
4. Похвально. Но вы снова впадаете в крайности. Хотя я четко написал что описал крайние варианты, вы их почему-то только и рассматриваете. Безусловно таджики не роботы. Им присущи человеческие чувства, и взаимопомощь. Об этом вообще в статье ни слова небыло. Иногда они даже остаются до поздна, все бывает конечно же. Я смотрю на вопрос намного шире, в общем, а вы разбиваете его на частности.
5. Этого не понял. Почему вы не отдадите продукт раньше срока? Если вы его сделали, так чего ждать?
4. Похвально. Но вы снова впадаете в крайности. Хотя я четко написал что описал крайние варианты, вы их почему-то только и рассматриваете. Безусловно таджики не роботы. Им присущи человеческие чувства, и взаимопомощь. Об этом вообще в статье ни слова небыло. Иногда они даже остаются до поздна, все бывает конечно же. Я смотрю на вопрос намного шире, в общем, а вы разбиваете его на частности.
5. Этого не понял. Почему вы не отдадите продукт раньше срока? Если вы его сделали, так чего ждать?
Статусы для багов, конечно. Для нового функционала, новых проектов и.т.п. сроки устанавливает заказчик, на что получает в ответ человекочасы и комментарии и/или корректировки сроков. Если заказчик принимает предложение — всё хорошо. Если нет, то ведутся дальнейшие переговоры.
Насчёт багов — быстро исправленный simple баг отдаётся как можно быстрее. Вообще все баги исправляются по мере сил.
А не отдавать раньше срока — из области психологии и маркетинга. Допустим, заказчик дал на выполнение месяц. Договорились на 300 человекочасов. Все согласны, все довольны. Но тут за полторы недели до срока мы приходим к заказчику и говорим, что всё сделали, можем устанавливать систему. Что должен подумать заказчик? Что реально время для выполнения задачи было слишком велико, за человекочасы переплатили. Тут, конечно, не будет особых проблем с тем, чтобы обоснавать такую скорость, но в следующий раз этот заказчик будет спорить насчёт человекочасов и сроков. Кому это надо? Никому не надо. Слишком короткие сроки — всегда плохо. Есть определённые рамки, за которые выходить нельзя. Это касается как максимума, так и минимума. Невозможно спроектировать и реализовать целую систему за неделю. Даже, если, над этим будет трудиться 100 человек одновременно. Как впрочем и ускорить разработку, сильно увеличив количество программистов.
Насчёт багов — быстро исправленный simple баг отдаётся как можно быстрее. Вообще все баги исправляются по мере сил.
А не отдавать раньше срока — из области психологии и маркетинга. Допустим, заказчик дал на выполнение месяц. Договорились на 300 человекочасов. Все согласны, все довольны. Но тут за полторы недели до срока мы приходим к заказчику и говорим, что всё сделали, можем устанавливать систему. Что должен подумать заказчик? Что реально время для выполнения задачи было слишком велико, за человекочасы переплатили. Тут, конечно, не будет особых проблем с тем, чтобы обоснавать такую скорость, но в следующий раз этот заказчик будет спорить насчёт человекочасов и сроков. Кому это надо? Никому не надо. Слишком короткие сроки — всегда плохо. Есть определённые рамки, за которые выходить нельзя. Это касается как максимума, так и минимума. Невозможно спроектировать и реализовать целую систему за неделю. Даже, если, над этим будет трудиться 100 человек одновременно. Как впрочем и ускорить разработку, сильно увеличив количество программистов.
ну вот что и требовалось доказать. по факту вы, даже несмотря на то, что ваша работа с разными заказчиками, и вы должны держать марку, вы все равно по сути обманываете, не говоря что работа реально обошлась дешевле. Но я в статье писал немного не о таком случае. Я говорю о случае когда заказчик один, то есть это чаще всего владелец компании, и между ним, и программистами есть прослойка в виде менджмента. То есть он по сути не может сменить исполнителя, НЕ УВОЛИВ ВЕСЬ ШТАТ. Если вы умудряетесь даже в вашей ситуации обмануть заказчика, когда он может в любой момент отказаться от ваших услуг, представьте что происходит когда заказчик гораздо сильнее привязан к исполнителю? Наглось вообще не знает границ.
А в том и дело, что чаще всего расходуется примерно столько человекочасов, сколько было заявлено и сроки — реальный ориентир. А если что-то получается сделать быстрее — это не всегда обман. Это может быть из-за привлечения немного большего количество разработчиков (т.е. такое же количество человекочасов, но в более сжатые сроки). Делается для небольшой подстраховки, чтобы в любом случае успеть в срок. А вообще, знаете, не все заказчики глупы. Поверьте, американцы умеют считать деньги. Да и европейцы тоже. Да и именем и репутацией наша компания дорожит. В данном случае это дороже, чем обмануть заказчика 100к $.
я понял что у вас несколько другой случай, чем описан в статье. но все равно, речь даже может не идти об целенаправленном обмане. может даже перестраховка, сути это не меняет. Когда исполнитель заинтересован только деньгами, он намного неэффективные (для заказчика) того кто работает за идею, при прочих равных. Это следует просто из логики. Вам ВЫГОДНО выполнить ту же работу за меньшее количество человекочасов. Это вы не можете отрицать. Другое дело насколько вы сможете сроки расятгивать без ущерба репутации. Вы может меньше, а кото-то больше. Кто то вообще в наглую занимается симуляцией бурной деятельности, получая в свой карман хорошие бонусы.
ну и конечно же вы всегда стремитесь назвать максимальное количество человеко-часов, ибо чем больше вы назовете, тем больше бабла получите. Конечно вам наглеть не стоит, но и занижать нельзя. И опять же, вы репутацией рискуете. В компании где все 3 уровня внутри, наглеть можно пудрить заказчику мозги намного свободнее. Повторяю, это не догадки, это мой опыт и опыт знакомых. Я просто не могу назвать конкретных имен и компаний. Но исключений практически нет.
>Давайте вернёмся к происхождению терминов «IT-художник» и «IT-таджик», пожалуйста
Мне показалось что такие аналогии будут неплохо отражать суть. Повторяю, это метафоры, а метафора не должна пониматься буквально.
Мне показалось что такие аналогии будут неплохо отражать суть. Повторяю, это метафоры, а метафора не должна пониматься буквально.
вы забываете об одной главной детали — все «таджики» и «художники» разные
я знавал первых, которые работают за идею, и знавал вторых, кто работал тупо за бабло
так получилось, что во мне вообще совмещены 2 этих типажа — я могу делать рутину, но я знаю, что завтра я буду делать что-то за идею
и я никогда не прочь помочь своему боссу, даже если придется на 10 минут коробки потаскать, а не за компом посидеть — он видит мою благодарность за данную работу и помощь для компании
кстати, мне недавно повысили зарплату, хотя на дворе кризис и других увольняют
когда я спросил, за что (может это и тупо звучало) — ответ был дан простой и все могут догадаться, какой
в итоге я еще более улучшил отношения с боссом и поднялся по ступеньке вверх, мне доверили более важный проект
я знавал первых, которые работают за идею, и знавал вторых, кто работал тупо за бабло
так получилось, что во мне вообще совмещены 2 этих типажа — я могу делать рутину, но я знаю, что завтра я буду делать что-то за идею
и я никогда не прочь помочь своему боссу, даже если придется на 10 минут коробки потаскать, а не за компом посидеть — он видит мою благодарность за данную работу и помощь для компании
кстати, мне недавно повысили зарплату, хотя на дворе кризис и других увольняют
когда я спросил, за что (может это и тупо звучало) — ответ был дан простой и все могут догадаться, какой
в итоге я еще более улучшил отношения с боссом и поднялся по ступеньке вверх, мне доверили более важный проект
Есть мужик, а есть таджик
Мужик доведет проект до конца
Таджик облажается
Мужик доведет проект до конца
Таджик облажается
Может я чего не понимаю, но зачем так называем «ит-художникам» работать на текучке? Я бы таким художникам не доверил сделать корпоративный сайт компании, автоматизировать какие-то процессы, написать гуй-ую прогу. Это дело можно доверить только профессионалам, которые использует проверенные наработки в соответствующей области. Зарекомендовавшие себя фреймворки, репозитории, IDE и т.д. Т.е. у профессионалов должна быть налажена технология производства софта — должен быть конвейр настроенный на определённую область (сайтостроение, гуй строение, игростроение, автоматизация и т.д.).
А «ит-художники» пусть делают следующие прорывы, строят новые конвейры для «ит-таджиков», упражняются с новыми технологиями, разрабатывают новые гуи, оптимизирую алгоритмы и т.д.
Ну не верю я, что делая Basecamp (или как-там он называется), «ит-художники» так вот невзначай изобрели Ruby on Rails. Ну они еще могут эту легенду задвинуть студентам и своим бабушкам. Но я поверю в другое, что они мега извращенцы, либо просто у них бабла было немеряно и не знали куда девать. И поэтому заместо того, чтобы сделать своему заказчику с минимальными затратами проект на PHP, они извращались с Ruby, продирались через тучу подводных камней, тратили на это огромное время (время-деньги). И в конце-концов изобрели Ruby on Rails. Несомнено это прорыв. Но эти прорывы не нужны обычному заказчику за его счёт.
А то, что в ваших конторах были старые конвейры, что руководство не пытается постепенно делать переход на новый конвейр типа RoR или Django. Так это их проблемы, либо их съедят компании перешедшие на эти более эффективные конвейры, либо у них просто идёт распил бабла и все довольны.
А в это время «ит-художники» за счёт денег заказчика делают очередные прорывы… Не так уж это и плохо — попробуйте найти такую компании (тут вон хабре жаловался человек, что у них оплачиваемые простои по 3 месяца). Либо ищите те компании, где пытаются поставить новый конвейр — придите и помогите им :)
А «ит-художники» пусть делают следующие прорывы, строят новые конвейры для «ит-таджиков», упражняются с новыми технологиями, разрабатывают новые гуи, оптимизирую алгоритмы и т.д.
Ну не верю я, что делая Basecamp (или как-там он называется), «ит-художники» так вот невзначай изобрели Ruby on Rails. Ну они еще могут эту легенду задвинуть студентам и своим бабушкам. Но я поверю в другое, что они мега извращенцы, либо просто у них бабла было немеряно и не знали куда девать. И поэтому заместо того, чтобы сделать своему заказчику с минимальными затратами проект на PHP, они извращались с Ruby, продирались через тучу подводных камней, тратили на это огромное время (время-деньги). И в конце-концов изобрели Ruby on Rails. Несомнено это прорыв. Но эти прорывы не нужны обычному заказчику за его счёт.
А то, что в ваших конторах были старые конвейры, что руководство не пытается постепенно делать переход на новый конвейр типа RoR или Django. Так это их проблемы, либо их съедят компании перешедшие на эти более эффективные конвейры, либо у них просто идёт распил бабла и все довольны.
А в это время «ит-художники» за счёт денег заказчика делают очередные прорывы… Не так уж это и плохо — попробуйте найти такую компании (тут вон хабре жаловался человек, что у них оплачиваемые простои по 3 месяца). Либо ищите те компании, где пытаются поставить новый конвейр — придите и помогите им :)
Человек который каждый день по 8 часов сидит на работе — нифига не художник. В таких условиях, когда свыше тебе навязывают сроки, требования, конвенции, а то и инструментарий — быть художником просто невозможно. Фрилансер — может быть, но зависимость от заказчика остается.
По поводу фикса багов. Не существует способов полностью их устранить. При применении современных методологий разработки их количество можно минимизировать, но я бы не сказал что та же XP придумана для художников. Любая методология — это прежде всего наличие четкой дисциплины в команде. Художникам это чуждо.
По поводу фикса багов. Не существует способов полностью их устранить. При применении современных методологий разработки их количество можно минимизировать, но я бы не сказал что та же XP придумана для художников. Любая методология — это прежде всего наличие четкой дисциплины в команде. Художникам это чуждо.
А какой интригующей была первая часть…
Здесь можно сказать только одно если человек профи в своем деле, то он или она будут делать все качественно и в срок, независимо от своих личных желаний. Потому как основной признак профессионализма — ответственность.
И странное у вас какое-то представление об иерархии, это получается когда я нанимаю строителей, скажем, полы отшлифовать — значит я прибыль получать буду?????
Здесь можно сказать только одно если человек профи в своем деле, то он или она будут делать все качественно и в срок, независимо от своих личных желаний. Потому как основной признак профессионализма — ответственность.
И странное у вас какое-то представление об иерархии, это получается когда я нанимаю строителей, скажем, полы отшлифовать — значит я прибыль получать буду?????
А можно вопрос. Я так понимаю вы менеджером никогда не были, но судя по топикам очень хотите, правильно?!
А нужно ли толковому программеру становиться менеджером?
Да, это ступенька вверх по карьерной лестнице, но никак не по лестнице развития именно как программиста.
Лично я всегда был против такого подхода и, если честно, именно поэтому я не хочу становиться начальником. Пока-что хочется программировать и создавать, а не управлять и главенствовать, собирая все сливки, лавры и похвалы в свои закрома…
Да, это ступенька вверх по карьерной лестнице, но никак не по лестнице развития именно как программиста.
Лично я всегда был против такого подхода и, если честно, именно поэтому я не хочу становиться начальником. Пока-что хочется программировать и создавать, а не управлять и главенствовать, собирая все сливки, лавры и похвалы в свои закрома…
я бы хотел быть техническим директором, что вполне себе достойная цель для движения по карьерной лестнице для программиста.
ЧТД, по вашим топикам это очень видно — не реализованные амбиции. Просто личный совет, старайтесь подходить к проблеме с разных сторон, в дальнейшей карьере пригодиться. Сейчас ваша позиция слишком эмоциональная, юная и честно говоря не верная по большому счету. Как будете тех.диром, поймете надеюсь. Обосновывать не буду, вам тут обосновывали что-то, хотя я так понял что вы не готовы пока воспринимать другие точки зрения.
Я спокойно воспринимаю другие точки зрения. Но как я могу воспринимать токи зрения, когда они не относятся к теме моей статьи. Те кто здесь отписался, часто просто не поняли о чем я написал. Может это моя вина, может не достаточно четко выразил свою позицию, но большинство же поняли. Надо просто взглянуть на поднятую проблему под правильным углом и немножко с болльшего растояния, что бы лучше охватить. И все станет на свои места.
я, если быть точнее, не то что бы мечтаю о роли техдира. Нет, я не думаю что добился всего на своем поприще. Но я думаю что это единственный шанс доказать свою правоту. Говорить можно много, понимать все очень хорошо. Даже показывать на собственном примере эффективность тех или других методологий, и подходов. Но ничего не меняется. Не меняется потому что люди видят что да, если сделать так то скорость разработки повышается, качество растет и т тд. Но им это просто не нужно. Их устраивает спокойное и размеренное движение проекта. И тебя просто загружают задачами что бы не выпендривался. Иногда доходит до прмого запрета общения с вышестоящим начальством, что бы не дай бог не сболтнул лишнего. Это уже ни раз было. Причем запрет распространяется на всех программистов. Этакая вертикаль власти. Доходит до абсурда. Начальник спускает задачу через ПМа, тот тебе её объясняет, ты указываешь на недороботки и проблемы, он соглашается, идет наверх там меняют задачу он приходит… Если бы задачи обсуждались сообща, то проблемы можно было бы выявить сразу. Но никому этого не надо. Главное что зарплату дают.
*представил себя в роли менеджера* ну нах >_< что it-художники в менеджменте? это, мягко выражаясь, весьма разноплановые работы…
Вы — идеалист. Разделили всех программистов на две категории, как мир на чёрное и белое. А ведь так не бывает — наш мир цветной, также и люди бывают разные (а программисты — тоже люди ;)). Подход у вас поверхностный, потому и неверный. Человек — существо намного более сложное, программист (чаще всего интроверт) — сложное вдвойне, потому что со стороны вообще непонятно, что у него там в голове происходит.
Ознакомьтесь с соционикой, я думаю, будет проще разобраться в окружающем без черно-белого объектива.
Ознакомьтесь с соционикой, я думаю, будет проще разобраться в окружающем без черно-белого объектива.
я написал что рассметрел две крайние позиции. буду писать диссертацию на эту тему, обязательно рассмотрю и другие «конфигурации»
>Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников.
Это вроде как разделение на две части, а не крайние позиции =)
Дело не в научности поста, а в его корректности. Дело в том, что вы претендуете на авторитетность вашего мнения («Мой опыт показывает что поделить можно. Опыт немаленький. Опыт работы во многих компаниях, в больших и малых командах. Статья не из пальца высосана, она полностью отражает мой опыт, и основана на нем.»), значит, должны быть более достоверны. А я такое разделение «художник» — «таджик» не нахожу достоверным. Такое разделение, имхо, вообще никак не связано с административными способностями (которые должны быть у менеджера). Они могут как быть, так и не быть у обоих типов.
Это вроде как разделение на две части, а не крайние позиции =)
Дело не в научности поста, а в его корректности. Дело в том, что вы претендуете на авторитетность вашего мнения («Мой опыт показывает что поделить можно. Опыт немаленький. Опыт работы во многих компаниях, в больших и малых командах. Статья не из пальца высосана, она полностью отражает мой опыт, и основана на нем.»), значит, должны быть более достоверны. А я такое разделение «художник» — «таджик» не нахожу достоверным. Такое разделение, имхо, вообще никак не связано с административными способностями (которые должны быть у менеджера). Они могут как быть, так и не быть у обоих типов.
к сожалению вы просто не поняли статью
Я понял, что вы хотите ставить на руководящие должности одних, и не допускать к ним других =) Согласно разделению на два типа. Возможно, я просто не понял этого разделения. Возможно, оно как раз и заключается в том, что одни делают проект ради проекта, а другие ради зарплаты. Но в таком случае, не надо называть первый тип «художники» =) Не все не-творческие люди работают «за зарплату», некоторые управленцы просто умеют поставить процесс так, чтобы вся творческая деятельность производилась другими нужными людьми.
З.Ы. Нашел
>Конечно рассмотрены два крайних случая, наверное есть и некоторые срединные варианты.
Конечно, дело не в «крайности», а в том, что есть варианты, которые не находятся посередине — они вообще в другом подпространстве ;)
З.Ы. Нашел
>Конечно рассмотрены два крайних случая, наверное есть и некоторые срединные варианты.
Конечно, дело не в «крайности», а в том, что есть варианты, которые не находятся посередине — они вообще в другом подпространстве ;)
>не надо называть первый тип «художники»
Это всего лишь метафора. Её не надо понимать буквально.
>некоторые управленцы просто умеют поставить процесс так, чтобы вся творческая деятельность производилась другими нужными людьми.
такого не бывает. в твореческую деятельность надо вмешиваться и корректировать. то есть нельзя управлять не работая ежедневно. то что можно наладить процесс и ничего не делать а оно будет само вертеться это просто мечта лентяя. Такого не бывает.
>они вообще в другом подпространстве
может быть, но они не относятся к теме моей статьи.
Это всего лишь метафора. Её не надо понимать буквально.
>некоторые управленцы просто умеют поставить процесс так, чтобы вся творческая деятельность производилась другими нужными людьми.
такого не бывает. в твореческую деятельность надо вмешиваться и корректировать. то есть нельзя управлять не работая ежедневно. то что можно наладить процесс и ничего не делать а оно будет само вертеться это просто мечта лентяя. Такого не бывает.
>они вообще в другом подпространстве
может быть, но они не относятся к теме моей статьи.
Тут кроме соционики, явно не хватает Психологии, проверенного жизненного опыта… У автора этого просто нет…
Да еще и диссертацию написать решил… честно, немного смешно и грустно.
«Рассмотрю другие „конфигурации“» — уважаемый автор статьи, эта диссертация, может стать началом пути, длинною в вашу жизнь и вы так ничего и не поймете. Занимайтесь тем, что у вас лучше всего получается. Выстраивать рабочий процесс с людьми, видимо не ваш конёк.
Да еще и диссертацию написать решил… честно, немного смешно и грустно.
«Рассмотрю другие „конфигурации“» — уважаемый автор статьи, эта диссертация, может стать началом пути, длинною в вашу жизнь и вы так ничего и не поймете. Занимайтесь тем, что у вас лучше всего получается. Выстраивать рабочий процесс с людьми, видимо не ваш конёк.
Каждый предпочитает верить в такую модель мира, в которой он является д'Артаньяном, а все остальные — жалкими неудачниками. Вот вы и выдумали для себя маленький чёрно-белый мирок, в котором вы являетесь бесценным художником, а все остальные, непохожие на вас, никчёмными таджиками. Но к сожалению существует этот маленький мирок только в вашем субъективном восприятии, и нигде более. И судя по тому, что вы испытаваете потребность в создании такого мифического мира, да ещё и пытаетесь убедить остальных в его существовании — вы и являетесь тем самым никчёмным работником.
кто ж спорит. сотрудники, работающие за идею, похвалу и пятничное пиво — это очень полезно для компании. отличный результат за недорого — это то, что надо ;)
Я придерживаюсь такого мнения: чтобы стать художником нужно вначале стать ремесленником.
Потому как и интуиция и творческое чутье произрастают исключительно из опыта, а не появляются каким-то волшебным образом по щучьему велению.
Поэтому не поработав IT-таджиком нечего лезть в творцы.
Потому как и интуиция и творческое чутье произрастают исключительно из опыта, а не появляются каким-то волшебным образом по щучьему велению.
Поэтому не поработав IT-таджиком нечего лезть в творцы.
очевидно что это не так. потому что не знаю как сейчас, но я работал будучи студентом за <100$ и то если есть работа, не ради этих самых 100 долларов, а ради того что бы научится, получить опыт. То есть фактически ради идеи, ради самого процесса. А до этого, еще раньше, я писал сам для себя всякие тетрисы, базы данных, чаты и всякую другу дребедень. Просто потому что мне было интересно. Наоборот, что бы стать профи, необходимо побыть художником.
Тут вся фишка — научится быть востребованным другими безо всяких новшеств и гениальных идей — просто быть квалифицированным специалистом, быть мастером своего дела.
И уже когда вы на деле доказываете, что вы мастер, вот тогда люди готовы довериться вашим фантазиям, поскольку за них вы отвечаете репутацией.
И уже когда вы на деле доказываете, что вы мастер, вот тогда люди готовы довериться вашим фантазиям, поскольку за них вы отвечаете репутацией.
То, что вы писали что-то для себя или для друга вовсе не означает, что вы делали качественный продукт — важна внешняя оценка, и умение делать продукт для заказчика, а не для себя
НЛО прилетело и опубликовало эту надпись здесь
статья спорная, особенно это видно по комментариям. Мое мнение: в менеджеры должны идти не бывшие программисты, кем бы они там ни были(художниками или таджиками), а те, кто умеют руководить. Возможно имеет смысл нанять человека со стороны, чем повышать сотрудников, особенно, если у них нет лидерский качеств.
оффтоп: забавное наблюдение, те, кто в комментах заявил о своем согласии со статьей — получил минус, а те, кто наоборот — какие-то плюсы, хотя мнения несогласных разнятся между собой.
оффтоп: забавное наблюдение, те, кто в комментах заявил о своем согласии со статьей — получил минус, а те, кто наоборот — какие-то плюсы, хотя мнения несогласных разнятся между собой.
Ну и ладно, что кто то джамшут. Зато может он дома картины маслянные втихаря рисует на заработанные деньги — тогда выходит художник. Вот те раз, дома — художник. На работе — джамшут. )
не читали habraname.habrahabr.ru/blog/56340/? ;-)
кстати, есть желание поработать?
кстати, есть желание поработать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дайте мне работать-2