Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Это ах*ено!
Это ахуен*о!
Это охуенно, чего уж там.
Ну, ну. Покультурнее можно.
Использовать звездочки в матерных словах — все равно, что делать минет на площади и прикрывать рот ладошкой (с) bash
Неа. Это хабр :)
Судя по всему, у sainnr будет месяц, чтобы понять разницу между матом со звездочками и матом без оных
Блин, я это распечатаю и обклею стены офиса. Статья невероятно классная :) Большой респект автору и переводчику.
Отлично! Сейчас отправлю начальнику :D
Спасибо за перевод! Потрясающий текст! Уже разослал его всем своим менеджерам)
Статья шикарна!
Господи, как же я ненавижу моменты, когда сидишь себе погруженный в работу, а тут тебя просят СРОЧНО поправить форму на сбытовом сайте.
Господи, как же я ненавижу моменты, когда сидишь себе погруженный в работу, а тут тебя просят СРОЧНО поправить форму на сбытовом сайте.
Статья и перевод хороший.
Для меня, правда, ничего новым не оказалось в ней после своего опыта и статей Джоэла, а так же бизнес-моделей Google, но автор всё замечательно и кратко скомпоновал и выжал суть из многих проблем.
Для меня, правда, ничего новым не оказалось в ней после своего опыта и статей Джоэла, а так же бизнес-моделей Google, но автор всё замечательно и кратко скомпоновал и выжал суть из многих проблем.
М.б. заголовок поправить —
«Уход и кормление разработчиков (или почему мы такие ворчуны) „
или
“Кормление и уход за разработчиками (или почему мы такие ворчуны)»
да и в оригинале «or, why engineers are grumpy» — «почему инженеры (или пусть будет разработчики)...», а не мы.
«Уход и кормление разработчиков (или почему мы такие ворчуны) „
или
“Кормление и уход за разработчиками (или почему мы такие ворчуны)»
да и в оригинале «or, why engineers are grumpy» — «почему инженеры (или пусть будет разработчики)...», а не мы.
Не нашел ничего нового. Как хорошо осознавать, что я не один такой в этом заброшенном уголке Вселенной… :D
Отличная статья, однако часто вижу противоположное мнение (с которым согласен) относительно вот этого пожелания:
Из хабраперевода статьи Джоеля Спольски Как положить спасибо в карман:
Мы делаем лучше, больше, быстрее не ради премий, а потому что можем и хотим — это внутренняя мотивация, если оперировать терминами из статей.
Вот благодарить всю команду/отдел после выполнения ключевых этапов — вполне разумная идея.
Совсем здорово будет, если вы назначите что-то вроде награды, которую будут выдавать каждый квартал разработчику, который внес больше всего усилий, внедрил больше всего улучшений и т.п.
Из хабраперевода статьи Джоеля Спольски Как положить спасибо в карман:
Как только вы начнете отмечать хорошую производительность сотрудников премиями, они немедленно начнут сравнивать себя с коллегами: почему я получил меньше, чем он? И такие вопросы вполне правомерны. Как вы определите, что ценнее в денежном эквиваленте: баг, который Дэвид пофиксал во вторник, или фича, которую Тэд реализовал в среду? Если бы у нас был цех по пошиву мужских трусов, то все было бы гораздо проще: Дэвид сегодня сшил пять трусов, а Тэд — семь; значит, Тэд получит на 40% больше денег.
Мы делаем лучше, больше, быстрее не ради премий, а потому что можем и хотим — это внутренняя мотивация, если оперировать терминами из статей.
Вот благодарить всю команду/отдел после выполнения ключевых этапов — вполне разумная идея.
Да-да-да, меня это тоже сильно напрягло. Но тут уж ничего не поделаешь — из песни слов не выкинешь.
Есть вполне нормальная практика премирования групп разработчиков. Для каждой значимой порции работы выделяется премиальный фонд. При выполнении разработчиками ряда условий, как то сдача проекта в срок, отсутствие критических багов, и так далее, премиальный фонд раздается группе. При невыполнении, фонд урезается каждую неделю или за каждый баг.
Морковка должна быть в поле зрения и осязаема, тогда будет желание ее достать
Морковка должна быть в поле зрения и осязаема, тогда будет желание ее достать
Не хочу с вами спорить, а наоборот поизучать эту проблему.
Моё личное мнение, как и у Джоэла, состоит в том, что прибегать к средствам материальной стимуляции — последний аргумент. С одной стороны обезоруживающий руководителя (у него не остаётся резерва и других эффективных рычагов воздействия, что сводит к нулю его лидерство), а со второй — портящей систему ценностей и мотивации сотрудника. Что заставляет последнего просто как разработчика перегореть и перейти в лоно потребления в одном сценарии; и уйти из компании, но с достаточным уровнем дохода, позволяющего не думать о деньгах, а сосредоточиться на цели — в другом.
Разработчик — в первую очередь творческая личность с сильнейшим чувством справедливости, которого попросту вгонять в однобокую модель глупо.
В вашем случае — это хороший метод восстановление справедливости, реально работающий. Проблема в том, что создав такую машину руководитель перекладывает на неё и ответственность. А как бы не были бы странны разработчики, с ними можно и говорить, и обучать, и понимать. Не всегда косяк или просмотр так плох, так как самый безолаберный работник может приносить огромную пользу, например, мотивируя других сотрудников, что при механической\материальной модели не видно на уровне начальства, и его результаты будут всего «плохими» и «штрафными» лишь от того, что им не умеют пользоваться из-за непонимания.
Моё личное мнение, как и у Джоэла, состоит в том, что прибегать к средствам материальной стимуляции — последний аргумент. С одной стороны обезоруживающий руководителя (у него не остаётся резерва и других эффективных рычагов воздействия, что сводит к нулю его лидерство), а со второй — портящей систему ценностей и мотивации сотрудника. Что заставляет последнего просто как разработчика перегореть и перейти в лоно потребления в одном сценарии; и уйти из компании, но с достаточным уровнем дохода, позволяющего не думать о деньгах, а сосредоточиться на цели — в другом.
Разработчик — в первую очередь творческая личность с сильнейшим чувством справедливости, которого попросту вгонять в однобокую модель глупо.
В вашем случае — это хороший метод восстановление справедливости, реально работающий. Проблема в том, что создав такую машину руководитель перекладывает на неё и ответственность. А как бы не были бы странны разработчики, с ними можно и говорить, и обучать, и понимать. Не всегда косяк или просмотр так плох, так как самый безолаберный работник может приносить огромную пользу, например, мотивируя других сотрудников, что при механической\материальной модели не видно на уровне начальства, и его результаты будут всего «плохими» и «штрафными» лишь от того, что им не умеют пользоваться из-за непонимания.
Мне кажется, вы немного преувеличиваете связь мателиального вознаграждения и лидерства. Это не пересекающиеся понятия и не зависят друг от друга.
С остальным не спорю, можно любой механизм обратить во зло, если им неумело пользоваться или возводить его до абсолютизма или идиотизма.
С остальным не спорю, можно любой механизм обратить во зло, если им неумело пользоваться или возводить его до абсолютизма или идиотизма.
Я ещё в процессе анализа этой проблемы. Собираю факты и проверяю гипотезы.
Поэтому благодарю за ваше мнение.
Г-н Кови утверждает, что как раз-таки зависят, и что подобное управление не является проявлением лидерства.
Поэтому благодарю за ваше мнение.
Г-н Кови утверждает, что как раз-таки зависят, и что подобное управление не является проявлением лидерства.
Ну, г-н Кови тоже может ошибаться, или его слова были привратно поняты.
Лидер — это не «кормящая рука». Лидер — это тот человек, авторитет которого непререкаем, слова и действия которого всегда несут пользу коллективу, который может повести за собой людей или организовать процесс, который берет на себя отвественность и принимает решения. А раздавать морковки может кто-то другой, и не факт, что это будет другой лидер. Лидер не надзиратель с кнутом, он человек, который побуждает в других желание самостоятельно двигаться вслед за лидером, т.е. не вешает морковку, а подталкивает человека к самостоятельному решению, что за морковкой идти надо.
Я сам в свое время изучал проблему стимулирования работников. И пришел к весьма интересным выводам, что материальная сторона на определенном моменте перестает быть важной для работника, на первый план выходят совершенно другие ценности
Лидер — это не «кормящая рука». Лидер — это тот человек, авторитет которого непререкаем, слова и действия которого всегда несут пользу коллективу, который может повести за собой людей или организовать процесс, который берет на себя отвественность и принимает решения. А раздавать морковки может кто-то другой, и не факт, что это будет другой лидер. Лидер не надзиратель с кнутом, он человек, который побуждает в других желание самостоятельно двигаться вслед за лидером, т.е. не вешает морковку, а подталкивает человека к самостоятельному решению, что за морковкой идти надо.
Я сам в свое время изучал проблему стимулирования работников. И пришел к весьма интересным выводам, что материальная сторона на определенном моменте перестает быть важной для работника, на первый план выходят совершенно другие ценности
Ключевое здесь — это уметь озвучивать важность работы Дэвида и Тэда.
«Если я уйду — все рухнет»
Как вы будете это озвучивать, айфоном, благодарным поцелуем секретарши, или стулом по правую руку директора во время обеденного перерыва — не так важно.
Главное чтобы все видели и оценили.
«Если я уйду — все рухнет»
Как вы будете это озвучивать, айфоном, благодарным поцелуем секретарши, или стулом по правую руку директора во время обеденного перерыва — не так важно.
Главное чтобы все видели и оценили.
Шикарная статья, полностью поддерживаю её автора в его взглядах
Потрясающая статья!
Всё так и есть. И отдельное спасибо за хороший перевод.
>В оригинале использовался всем знакомый термин «software engineer». Так как в русском языке полноценного эквивалента нет
а чем не устраивает «инженер-программист»?
а чем не устраивает «инженер-программист»?
В русском языке инженер-программист — это в первую очередь запись в дипломе выпускника технического вуза, квалификация. На работу никто инженеров-программистов не нанимает (нет, есть и такие вакансии, но их меньшинство), нанимают разработчиков.
В английском языке «software engineer» — это именно должность, профессия. Аналог «инженера-программиста» в русском языке — это скорее «Bachelor of Software Engineering».
В английском языке «software engineer» — это именно должность, профессия. Аналог «инженера-программиста» в русском языке — это скорее «Bachelor of Software Engineering».
>На работу никто инженеров-программистов не нанимает
я на такой должности вполне официально работаю. И разработчики у нас в отделе тоже есть.
я на такой должности вполне официально работаю. И разработчики у нас в отделе тоже есть.
Ну я же написал — такие вакансии есть, но их меньшинство.
Суть в том, что четкой терминологии в русском языке для обозначения профессии software engineer не выработалось. Их могут называть разработчиками, программистами и, да, инженерами-программистами. Слово «разработчик» в русском языке как положительное и возвышенное прижилось лучше всего (ну да, по моему субъективному мнению, конечно), поэтому использовать решил именно его.
Если хотите (и нам тут разрешат), можем устроить тут более подробное исследование, мне самому правда интересно, как грамотнее всего это перевести. Можно даже опрос устроить.
Суть в том, что четкой терминологии в русском языке для обозначения профессии software engineer не выработалось. Их могут называть разработчиками, программистами и, да, инженерами-программистами. Слово «разработчик» в русском языке как положительное и возвышенное прижилось лучше всего (ну да, по моему субъективному мнению, конечно), поэтому использовать решил именно его.
Если хотите (и нам тут разрешат), можем устроить тут более подробное исследование, мне самому правда интересно, как грамотнее всего это перевести. Можно даже опрос устроить.
Вообще-то в трудовую книжку обычно пишут инженер-программист, поскольку в такому случае не требуется писать определение задач работника — такая должность есть в соответствующем классификаторе.
Вот, хорошо. Вижу, что здесь использован такой же перевод.
Теперь к практике, заходим на hh.ru, используем поиск, получаем следующую статистику:
Получается, что, да, переводить «software engineer» как «инженер-программист» теоретически должно быть верно. Но на практике «инженер-программист» используется в русском языке во много раз реже, чем аналогичное «software engineer» в английском. Приходится использовать нейтральное слово «разработчик», которое более возвышенное, чем «программист», но более естественное, чем «инженер-программист». Конечно, теперь размываются отличия между «developer» и «software engineer», но всем не угодишь. К счастью, в этой статье это совсем не важно.
Теперь к практике, заходим на hh.ru, используем поиск, получаем следующую статистику:
- по запросу «инженер-программист» — 185 вакансий
- по запросу «программист/разработчик» — 6506 вакансий
- по запросу «software engineer» — 721 вакансия
Получается, что, да, переводить «software engineer» как «инженер-программист» теоретически должно быть верно. Но на практике «инженер-программист» используется в русском языке во много раз реже, чем аналогичное «software engineer» в английском. Приходится использовать нейтральное слово «разработчик», которое более возвышенное, чем «программист», но более естественное, чем «инженер-программист». Конечно, теперь размываются отличия между «developer» и «software engineer», но всем не угодишь. К счастью, в этой статье это совсем не важно.
Извините, похоже вы не правильно меня поняли — я не против того перевода, какой есть. Просто неверно говорить, что на hh.ru вакансия менее востребованная — я сам устроился по подобной вакансии (Java developer), но в трудовой — всё равно инженер-программист.
А я не согласен. Во всём :)
1. Что касается статьи — использование «инженера-программиста» подчеркнуло бы инженерный характер работы. «Разработчик» тоже не плохо, конечно, и я понимаю ваши аргументы. Но, на мой взгляд, поскольку и в русском и в английском есть все варианты терминов, подозревать автора в том, что он использовал «инженер-», вместо «девелопера» только потому, что «инженер-» у них более распространено (относительно нас), а не потому, что он хотел подчеркнуть именно инженерный характер работы — это как-то неочевидно по отношению к авторской мысли.
2. Плохая статистика «инженера-» не повод не популяризировать этот термин :). И дело не в официальном наименовании — лично меня это меньше всего интересует. Сам до недавнего времени предпочитал именовать себя девелопером/разработчиком (собственно, им и был), а в определённый момент понял, что я всё-таки инженер. И статья, по-моему, именно о тех, кто осознал, что он — инженер.
1. Что касается статьи — использование «инженера-программиста» подчеркнуло бы инженерный характер работы. «Разработчик» тоже не плохо, конечно, и я понимаю ваши аргументы. Но, на мой взгляд, поскольку и в русском и в английском есть все варианты терминов, подозревать автора в том, что он использовал «инженер-», вместо «девелопера» только потому, что «инженер-» у них более распространено (относительно нас), а не потому, что он хотел подчеркнуть именно инженерный характер работы — это как-то неочевидно по отношению к авторской мысли.
2. Плохая статистика «инженера-» не повод не популяризировать этот термин :). И дело не в официальном наименовании — лично меня это меньше всего интересует. Сам до недавнего времени предпочитал именовать себя девелопером/разработчиком (собственно, им и был), а в определённый момент понял, что я всё-таки инженер. И статья, по-моему, именно о тех, кто осознал, что он — инженер.
Когда кто-то не согласен, это здорово, согласие порождает стагнацию. :)
1. Бесспорно, автор использовал слово «software engineer» именно потому, что оно подчеркивает инженерный характер работы, а точнее, указывает на большую ее сложность, о том, что речь идет не обычных «кодерах»-недоучках. Это особенно видно из его следующей записи в блоге (кстати, думаю перевести и ее) «Web developers are software engineers too».
Фишка в том, что в статье на сам инженерный характер работы упора практически не делается, делается упор на представителей этой профессии — а их на русском языке чаще все же называют «разработчиками» — при этом негативного оттенка такое название не несет.
2. Здесь согласен, очень хороший аргумент. Но я на него не решился. :)
В первую очередь потому, что, используя термин «инженер-программист», пришлось бы использовать его во всем тексте целиком — а это смотрелось бы слишком уродливо и неестественно.
1. Бесспорно, автор использовал слово «software engineer» именно потому, что оно подчеркивает инженерный характер работы, а точнее, указывает на большую ее сложность, о том, что речь идет не обычных «кодерах»-недоучках. Это особенно видно из его следующей записи в блоге (кстати, думаю перевести и ее) «Web developers are software engineers too».
Фишка в том, что в статье на сам инженерный характер работы упора практически не делается, делается упор на представителей этой профессии — а их на русском языке чаще все же называют «разработчиками» — при этом негативного оттенка такое название не несет.
2. Здесь согласен, очень хороший аргумент. Но я на него не решился. :)
В первую очередь потому, что, используя термин «инженер-программист», пришлось бы использовать его во всем тексте целиком — а это смотрелось бы слишком уродливо и неестественно.
Официально есть программисты просто «программисты», а есть «инженеры-программисты», все они входят в составную группу «Специалисты по компьютерам», слышал ещё «инженер по производству программного обеспечения» применительно к выпускникам по специальности «Программная инженерия».
Речь скорее о том, что в этом контексте «Так как в русском языке полноценного эквивалента нет» — слишком категоричное утверждение и это режет глаз.
это великолепная статья! opportunato, спасибо вам за перевод! как жаль, но я не могу плючануть вам карму больше одного раза
Небольшое исправление: waterfall model — каскадная модель, а не водопадная.
И вот тут зарыт главный корень проблемы — разработчики на самом деле не послушные строители. Разработчики — творцы.
Вам в фирме нужен молодой амбициозный, целеустремленны разработчик С++, с опытом работы в 1.5 года?
Потому что на моей, мне предлагают брать пример с дади Вася на заводе, вместо того что бы пытаться что то улучшить. И что все это выдумка, такая же как снежный человек.
Вам в фирме нужен молодой амбициозный, целеустремленны разработчик С++, с опытом работы в 1.5 года?
Потому что на моей, мне предлагают брать пример с дади Вася на заводе, вместо того что бы пытаться что то улучшить. И что все это выдумка, такая же как снежный человек.
Преждевременная оптимизация — это корень всех бед. Наберитесь опыта для начала, посмотрите что/где/зачем, а уж потом улучшайте. В начале карьеры всегда кажется что все вокруг идиоты, а ты видишь очевидный путь решения проблем. Иногда это так, конечно, но чаще всего устоявшееся поведение имеет под собой хорошее основание. Просто не очевидное.
www.youtube.com/watch?v=fEYceCWI_h0
Нецензурная лексика. Извините.
Нецензурная лексика. Извините.
Да, перевод — действительно, редкого хорошего качества. Спасибо. И автор оригинала — то же самое, редкого качества, книги его популярны, излагать мысли умеет (линк на русские переводы).
Читал в захлеб! Автору поста громадный респект и низкий поклон! Это нужно читать всем перед тем как постучаться к разработчику.
Отличная статья, спасибо за перевод, вы молодец!
Тронуло до глубины души. Автору и переводчику, непомерная благодарность!
Отличная статья. Завтра утром пошлю оригинал своего продакт менеджеру.
Замечательная статья! Респект автору и огромнейшее спасибо автору перевода!
Статья прекрасна чуть больше чем полностью.
Отличная статья, спасибо за перевод.
Интересные мысли есть, но как же автор любит растечься мыслью по древу… длинно очень в общем.
Компьютерные вузы не готовят вас к испытаниям, которые ждут вас в индустрии. Они в первую очередь дают вам концептуальные знания по большому спектру тем, чтобы потом не опозориться, столкнувшись с ними во время настоящей работы. Вас учат переменным, функциям и объектам, так как именно с ними вы будете работать большую часть своего времени. Вас учат базам данных и запросам к ним (хотя нормальные формы окажутся бесполезными на практике). Вы тратите ненормально большую часть времени на изучение алгоритмов сортировки и структур данных, которые во время профессиональной разработки будут скрыты от вас под слоем абстракций. Короче, компьютерные вузы рассматривают решение проблем, которые вам на практике никогда не придется решать. Если мне нужно что-нибудь отсортировать, я просто вызову метод sort(). Если мне нужна очередь или связанный список, я использую нативную реализацию языка, на котором я пишу. Все эти проблемы уже решены за меня.
Автор так говорит как будто фундаментальные знания бесполезны. Как будто все разработчики вызывают метод sort() и кладут кнопочки на форму.
И да, нормальные формы всё таки лучше применять чем не применять. По крайней мере там где есть ещё буфер по производительности.
Автор так говорит как будто фундаментальные знания бесполезны. Как будто все разработчики вызывают метод sort() и кладут кнопочки на форму.
И да, нормальные формы всё таки лучше применять чем не применять. По крайней мере там где есть ещё буфер по производительности.
Хорошая статья.
По себе скажу:
Не сажусь за решение минимального кванта проблемы, если не уверен, что успею решить его и написать код за неделимый промежуток времени. Всё по той же причине смены контекста. Вместо этого или просто готовлю почву для будущего решения или же решаю другой квант, который вписывается в промежуток времени.
По себе скажу:
Не сажусь за решение минимального кванта проблемы, если не уверен, что успею решить его и написать код за неделимый промежуток времени. Всё по той же причине смены контекста. Вместо этого или просто готовлю почву для будущего решения или же решаю другой квант, который вписывается в промежуток времени.
Спасибо за статью. Думаю не лишним будет почитать как менеджерам, так и разработчикам.
Друзьям скинул :)
Друзьям скинул :)
Всё же замечания, что деньги особо не волнуют программистов, по-моему, ближе к западным реалиям. В России зарплаты программистов вполне бывают поводом искать другую работу.
Скорее у программистов нет тяги к обогащению, главное чтобы хватало для комфортной «западной» жизни. Просто в Российских реалиях, это огромнейшая сумма. :)
Я вот сейчас работаю за 10к + стипендия 1к. Из них на дорогу уходит только 4 в месяц. На остальные 7к квартиру не снимешь, девушку на прокормишь.
Я вот сейчас работаю за 10к + стипендия 1к. Из них на дорогу уходит только 4 в месяц. На остальные 7к квартиру не снимешь, девушку на прокормишь.
ИМХО зарплата стоит в топе только до определенного уровня. После того, как тебе хватает на твой образ жизни все больше и больше ценишь и ищешь другие вещи. Так было у меня.
Статья определенно порадовала
Статья просто шикарна!
О Бруксе (и не только) — первому изданию скоро стукнет 40 лет, но много ли менеджеров прочитав книгу попытались и смогли изменить что-нибудь в своей компании? Судя по моим наблюдениям — исчезающе малый процент. С тех пор вышло немало других книг по теме, родилось немало баззвордов в области управления командами разработки, но старые проблемы — все на месте, кроме единичных компаний, которые как правило изначально создавались айтишниками и обслуживают айтишников. Разработчики прикладного софта все еще где-то в 1975-м году, будто и не было никакого Брукса. Дикая текучка кадров, особенно в российском IT, тому подтверждение.
К сожалению приходится констатировать, что книга в первую очередь нужна самим разработчикам для осознания, что где-то существуют люди, которые понимают их проблемы.
К сожалению приходится констатировать, что книга в первую очередь нужна самим разработчикам для осознания, что где-то существуют люди, которые понимают их проблемы.
Ээхх, прочитали бы эту статью в одной крупной российской софтверной компании (
Название компании раскрывать не хочется, компания делает проекты для нефтянки и гос. учреждений. Так вот в этой компании менеджеры проектов не являются бывшими разработчиками, не представляют процесс разработки, не знают языков программирования и часто говорят «ну это же просто, ты же сможешь это быстро сделать». Поработал там месяц и уволился.
Название компании раскрывать не хочется, компания делает проекты для нефтянки и гос. учреждений. Так вот в этой компании менеджеры проектов не являются бывшими разработчиками, не представляют процесс разработки, не знают языков программирования и часто говорят «ну это же просто, ты же сможешь это быстро сделать». Поработал там месяц и уволился.
А про тестировщиков совсем автор забыл, они злые — расстраивают разработчиков… уменьшают их производительность.
Спасибо за перевод. Только исправьте пож. имя баскетболиста.
Вместо «Джеймса Леброна» нужно «Леброн Джеймса». Джеймс — не имя, а фамилия :)
Вместо «Джеймса Леброна» нужно «Леброн Джеймса». Джеймс — не имя, а фамилия :)
Спасибо за перевод — у меня вот открытие века, статья прекрасна.
Единственное — почему-то при прочтении строк о новом дизайне страницы Yahoo! я полез на yahoo.com посмотреть, а какой же дизайн там сейчас. И что могу сказать — дизайн до сих пор по-моему редкостное говно, даже удивительно что они ничего не поменяют там.
Единственное — почему-то при прочтении строк о новом дизайне страницы Yahoo! я полез на yahoo.com посмотреть, а какой же дизайн там сейчас. И что могу сказать — дизайн до сих пор по-моему редкостное говно, даже удивительно что они ничего не поменяют там.
Срок жизни программного обеспечения — 3-5 лет, срок разработки — 1-2 года. Не стоит сравнивать себя со строителями, потому что здания стоят по 100 лет, а срок их строительства сравним с вашим.
При такой скорости разработки всегда будут проблемы. Я вижу пару выходов: 1. Существенно сократить скорость разработки — что, если верить статье не представляется возможным (сроки это не ваша сильная сторона), 2. бить функционал на модули(блоки) и внедрять на базе общей концепции помодульно (но с этим у вас так же огромные проблемы — вы обожаете переписывать чужой код заново и никогда не найдете правил совместной разработки).
В конце хотел бы сообщить, что бизнесу в 95% случаев не важно ваша творческая составляющая, бизнес ждет быстрого копирования вашей предыдущей разработки.
Недавно была статья про спутник «Вояджер-1» которому 34 года и который до сих пор присылает уникальные данные. Это супер успешный проект. Он стал успешным только потому, что его запустили в космос, в котором нет возможности допиливать и оптимизировать. Поэтому 3ий выход: увеличивать срок жизнедеятельности ваших разработок (а вот это уже проблема заказчика)
При такой скорости разработки всегда будут проблемы. Я вижу пару выходов: 1. Существенно сократить скорость разработки — что, если верить статье не представляется возможным (сроки это не ваша сильная сторона), 2. бить функционал на модули(блоки) и внедрять на базе общей концепции помодульно (но с этим у вас так же огромные проблемы — вы обожаете переписывать чужой код заново и никогда не найдете правил совместной разработки).
В конце хотел бы сообщить, что бизнесу в 95% случаев не важно ваша творческая составляющая, бизнес ждет быстрого копирования вашей предыдущей разработки.
Недавно была статья про спутник «Вояджер-1» которому 34 года и который до сих пор присылает уникальные данные. Это супер успешный проект. Он стал успешным только потому, что его запустили в космос, в котором нет возможности допиливать и оптимизировать. Поэтому 3ий выход: увеличивать срок жизнедеятельности ваших разработок (а вот это уже проблема заказчика)
Вы забываете что большинство зданий возводятся по типовому проекту. Это ближе к установке CMS в одной из базовых комплектаций, чем к разработке ПО. При строительстве здания по уникальному проекту только разработка арх.проекта и то легко займёт пару лет, не говоря уж про само строительство.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
А здания, которые стоят веками, составляют ничтожный процент от общего количества построенного за эти века. К тому же практически все они входят в 3 типа: совсем примитивные, совсем аварийные и памятники-архитектуры. Последние не используются по прямому назначению и для их поддержания в адекватном состоянии выделяются огромные бюджеты.
Однако ПО само по себе не изнашивается в отличии от зданий, т.е. срок жизни программного обеспечения ограничен только сроком жизни типа оборудования, на котором его можно запускать. Разумеется это как минимум десятки лет.
Другой вопрос в моральном устаревании, которое появляется из-за изменений требований к ПО, а отнюдь не из-за внутренних проблем в ПО. Так что пример с ПО для спутников вовсе не единственный, возьмите сотни программ для компьютеров 30 летней давности, они по-прежнему хорошо на них работают.
Самый верный совет — не бросаться в омут с головой. Сначала на разведку на месяц, а там уж решать — ваше это или не ваше. По поводу социализации могу сказать одно: будьте ДОБРЫМ и ХОРОШИМ. А если смотреть на тайцев как на врагов, то чего еще ожидать в ответ? И да, shit happens.
Мда. Программисты действительно отличаются от простых смертных, причем очень заметно:) Нам в универе препод говорил: «Если хотите стать кодерами — меняйте своё мировоззрение».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кормление и уход за разработчиками (или почему мы такие ворчуны)