Comments 38
Ещё Larry Wall (создатель языка Perl) говорил — Laziness is a virtue of a programmer.
Да все нормально, к тому что большинство тупо пишет код (не улучшая процесс) надо просто привыкнуть.
Кстати, есть такая забавная книга Алена Картера — Программистский камень, и там предлагается разделить программистов на паковщиков (обычные рабочие лошадки) и картостроителей (необычные рабочие лошадки, которые помогают обычным эффективно работать).
Это жизнь.
Кстати, есть такая забавная книга Алена Картера — Программистский камень, и там предлагается разделить программистов на паковщиков (обычные рабочие лошадки) и картостроителей (необычные рабочие лошадки, которые помогают обычным эффективно работать).
Это жизнь.
Да, конечно, это бесит, когда люди из той же лени(только в данном случае лени «подумать и сделать нормально») делают все механически и бездумно, но в этом-то и плюс для остальных. Пусть занимаются тем же самым — меньше конкуренции, тем кто думает — они в дальнейшем не будут заниматься нудной текучкой.
Кстати не сказано еще про то, что разовые затраты на автоматизацию этой текучки могут занять недели и даже месяцы.
Кстати не сказано еще про то, что разовые затраты на автоматизацию этой текучки могут занять недели и даже месяцы.
Можно ведь сначала прикинуть, стоит ли оно того… и если хоть небольшой выигрыш во времени — надо делать… хотя даже если нет выигрыша во времени, т.е. что с автоматизацией, что без автоматизации — будет потрачено одинаковое количество времени — все равно надо автоматизировать, ибо нудная работа выматывает до жути, а автоматизация превносит разнообразие в рабочий процесс. =)
Да, недели и месяцы. Но с другой стороны ежедневные затраты, на самом деле, еще больше. К примеру — 20 разработчиков теряют по 15 минут в день — это 5 человеко-часов в день. Если я потрачу 40 часов на автоматизацию, выйгрыш начнется уже через 8 дней.
А мне показалось, что именно ваши коллеги ленивы, а не вы.
я бы на вашем месте задумался б о том, чтобы из исполнителя превратиться в руководителя. т.е. замутить свое дело по вашей профессиональной линии (и сделать КАК НАДО, с блекджеком и шлюхами).
имхо, если все вокруг такие безынициативные, то пора брать ВСЕ в свои руки =))
имхо, если все вокруг такие безынициативные, то пора брать ВСЕ в свои руки =))
Не всем хочется переходить на административные должности.
проще говоря, не всем хочется брать на себя дополнительную ответственность? (но при этом хочется глобальных перемен в рабочем процессе). хм…
Можно совмещать приятное с полезным — быть инициатором глобальных изменений, но не нести ответственность: только инициативу надо проявлять не в курилке, а докладной на имя сначала непосредственного руководителя, а если нужно, то и через его голову, со всеми выкладками типа «20 разработчиков теряют по 15 минут в день — это 5 человеко-часов в день. Если я потрачу 40 часов на автоматизацию, выйгрыш начнется уже через 8 дней.» Чревато, конечно, испорченным «моральным климатом», но тут уж каждый выбирать должен, «шашечки или ехать»
P.S. Хотя обычно, насколько я знаю, люди не хотят быть руководителями, не потому что не хотят брать ответственность, а потому что не умеют руководить. Всё таки руководитель (менеджер, администратор) это, прежде всего, работа с людьми, а нас учили (кого учили :) ) работать с кодом (семестр психологии для зачёта не в счёт). Можно возразить: «а ты попробуй, вдруг получится и понравится» (на днях в одном из постов такой совет был, что каждому программисту стоит хотя бы год поработать менеджером проекта), но никто же не говорит «а ты попробуй людей полечить или жилой дом спроектировать» людям без медицинского или строительного образования, так и на руководителя, и вообще работе с людьми, надо учиться (и теорию изучать, и практика нужна). Осознание этого, кстати, может прийти после прочтения умных постов и комментов на хабре про контроль и оценку эффективности подчинённых, распределение обязанностей, делегирование ответственности и т. п. Есть, конечно, самородки, которые руководят интуитивно, и хорошо руководят, так и прогеры такие есть
P.S. Хотя обычно, насколько я знаю, люди не хотят быть руководителями, не потому что не хотят брать ответственность, а потому что не умеют руководить. Всё таки руководитель (менеджер, администратор) это, прежде всего, работа с людьми, а нас учили (кого учили :) ) работать с кодом (семестр психологии для зачёта не в счёт). Можно возразить: «а ты попробуй, вдруг получится и понравится» (на днях в одном из постов такой совет был, что каждому программисту стоит хотя бы год поработать менеджером проекта), но никто же не говорит «а ты попробуй людей полечить или жилой дом спроектировать» людям без медицинского или строительного образования, так и на руководителя, и вообще работе с людьми, надо учиться (и теорию изучать, и практика нужна). Осознание этого, кстати, может прийти после прочтения умных постов и комментов на хабре про контроль и оценку эффективности подчинённых, распределение обязанностей, делегирование ответственности и т. п. Есть, конечно, самородки, которые руководят интуитивно, и хорошо руководят, так и прогеры такие есть
Честно говоря, я уже начал задумываться. Но, с другой стороны, я вижу, сколько на самом деле бюрократии в работе руководителя, и как надо себя ломать, чтобы угодить заказчикам. А я гораздо больше люблю просто программировать.
2 года назад, я был участником проекта (довольно крупного). Использовали VSS в структура которого была очень громоздкой.
Была ветвь в которой было ~5000 элементов, мне необходимо было забрать штук 40.
В итоге примерные затраты:
1. Чтобы вытащить ресурсы, уходило порядка 20-30 минут.
2. Уходило порядка часа на сборку пакета (1 билд машина).
3. В случае малейшего изменения одного из ресурсов, все начиналось сначала.
Лень двигатель прогресса, я с более опытным разработчиком (в то время я вообще был в тестировании :) ) начали писать софт (он меня курировал).
В итоге сначала получилась программа забирающая файлы из хранилища (скормил список объектов, он сам их вытащил).
Потом начал раскладывать в каталоги.
Далее была попытка сборки пакета (то что в итоге должны получить).
Этот процесс был утвержден, в данный момент он кардинально переработан, но я могу гордо заявить, что был «у истоков».
Была ветвь в которой было ~5000 элементов, мне необходимо было забрать штук 40.
В итоге примерные затраты:
1. Чтобы вытащить ресурсы, уходило порядка 20-30 минут.
2. Уходило порядка часа на сборку пакета (1 билд машина).
3. В случае малейшего изменения одного из ресурсов, все начиналось сначала.
Лень двигатель прогресса, я с более опытным разработчиком (в то время я вообще был в тестировании :) ) начали писать софт (он меня курировал).
В итоге сначала получилась программа забирающая файлы из хранилища (скормил список объектов, он сам их вытащил).
Потом начал раскладывать в каталоги.
Далее была попытка сборки пакета (то что в итоге должны получить).
Этот процесс был утвержден, в данный момент он кардинально переработан, но я могу гордо заявить, что был «у истоков».
когда разработчик занят на нескольких проектах сразу и ему постоянно подкидывают задания, то тут не до обдумывания процесса улучшения — лишь бы успеть всё сделать в срок и бежать дальше.
Вот есть у меня пример — работаем с системой сайтов на ужасно написанной самопальной cms, хотя даже это cms назвать трудно. Логики — мизер, ооп или что-то подобное вообще рядом не лежало, чтобы в них разобраться новому человеку — надо потратить месяца два наверное. Так вот, если считать пресловутые человеко-часы, то уже давно было бы эффективнее перенести всё на ту же джумлу или друпал.
Но как вы думаете, поступают пм-ы и заказчики? Им пофиг, что добавление элементарного модуля может занять два-три дня, лишь бы работало.
Вот есть у меня пример — работаем с системой сайтов на ужасно написанной самопальной cms, хотя даже это cms назвать трудно. Логики — мизер, ооп или что-то подобное вообще рядом не лежало, чтобы в них разобраться новому человеку — надо потратить месяца два наверное. Так вот, если считать пресловутые человеко-часы, то уже давно было бы эффективнее перенести всё на ту же джумлу или друпал.
Но как вы думаете, поступают пм-ы и заказчики? Им пофиг, что добавление элементарного модуля может занять два-три дня, лишь бы работало.
Давно сказано: «Лучше день потерять, потом за пять минут долететь»
Как же вы плохо про коллег отзываетесь :-) Прямо таки все покорные? :)
Ну а если серьезно, то такие улучшения просто нужно правильно продавать менеджерам, рассказывая о текущих проблемах (и их последствиях в виде потраченных $$$) и способах решения, а также о том, сколько вы потратите этих самых $$$ (в виде своего времени) для того, чтобы потом эти $$$ сэкономить.
Проверено. Даже самые консервативные менеджеры в итоге соглашаются.
Ну а если серьезно, то такие улучшения просто нужно правильно продавать менеджерам, рассказывая о текущих проблемах (и их последствиях в виде потраченных $$$) и способах решения, а также о том, сколько вы потратите этих самых $$$ (в виде своего времени) для того, чтобы потом эти $$$ сэкономить.
Проверено. Даже самые консервативные менеджеры в итоге соглашаются.
Нет, не все, но большинство — по крайней мере мне так казалось.
Проблема с менеджерами тоже в том, что они привыкли. И заказчики не видят проблем в том, что приложение запускается долго, что настройка среды — нетривиальная задача. Их заботят фичи, попавшие в план, а значит, приносящие деньги. Экология, как я говорил, слишком долгосрочное капиталовложение — немногие заказчики готовы за это платить.
Проблема с менеджерами тоже в том, что они привыкли. И заказчики не видят проблем в том, что приложение запускается долго, что настройка среды — нетривиальная задача. Их заботят фичи, попавшие в план, а значит, приносящие деньги. Экология, как я говорил, слишком долгосрочное капиталовложение — немногие заказчики готовы за это платить.
чтобы одному глобально изменить ситуацию надо быть либо диктатором, либо мучеником
первое далеко не всем интересно, второе — пока наличествует оптимизм, дальше всё начинает сводиться к формуле «Кто не платит за работу — платит за безделье».
первое далеко не всем интересно, второе — пока наличествует оптимизм, дальше всё начинает сводиться к формуле «Кто не платит за работу — платит за безделье».
Не могли бы вы пояснить выражение «отсутствие kick-off для новых людей в команде»?
Вводной лекции/workshop, на которой рассказывают, что за проект, какая у него инфраструктура, где взять доки, кто за что отвечает и так далее. Знаю, что на старом проекте kick-off (правда, с рассказам и о нашей конторе) занимает пол-дня-день. На новом, к сожалению, практикуестся практика «кинуть в воду».
Как то препод говорил:
«программист должен быть ленивым и еще и немного туповат, и не должен быть слишком любопытен»
ленивым — чтобы не делать то что можно автоматизировать
туповат — чтобы мог описать алгоритм(и т.п.) на относительно ограниченном языке(программирования в сравнии, например с ествественным). Надо уметь думать как «тупая машина», знающая только «1» и «0».
не слишком любопытным — главное что работает, неважно как
(с)ББ
«программист должен быть ленивым и еще и немного туповат, и не должен быть слишком любопытен»
ленивым — чтобы не делать то что можно автоматизировать
туповат — чтобы мог описать алгоритм(и т.п.) на относительно ограниченном языке(программирования в сравнии, например с ествественным). Надо уметь думать как «тупая машина», знающая только «1» и «0».
не слишком любопытным — главное что работает, неважно как
(с)ББ
Sign up to leave a comment.
Экология программирования