Мои 3-4 часа — это наиболее плодотворные часы, когда создается что-то новое в проекте, естественно, бывает и больше, но в среднем — примерно столько в день. Больше 4 часов такой активной работы по моим наблюдениям — это уже приглаживание кода, пробы, отладка и т.д., но никак не наращивание функционала проекта. Поэтому я свой день и делю на две половины — в первую у меня обычно творческий подъем, я с прошлого вечера наметил и обдумал что и как сделать — а с утра начинаю воплощать. Заряда и придумок хватает как раз где-то на 3-4 часа.
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
Плюсанул бы, но нет правов: ) Я в последние полтора года работаю на фрилансе. Точнее — на подряде, проектно и со свободным графиком — есть план с дедлайнами по этапам, а внутри этого периода я могу работать где и сколько угодно — моя задача принести в клювике к обозначенному сроку результат.
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Ну, раз вы за эти два с половиной года еще не устали, значит либо не всегда такой подход был, либо действительно за архитектурой приглядывают. Потому что говнокод — здесь я под говнокодом подразумеваю не забагованный и/или криво писаный код, а код, который пишется не в какую-то хорошо продуманную структуру, а произвольно лепится — неизбежно приводит к тому, что в продукте начинаются суровые проблемы согласованности работы компонентов. Это как строить здание без плана, прифигачивая, что в голову пришло. Я поэтому не люблю «хакеров», которые могут — да — сделать финт в каком-то фрагменте, но этот финт на самом деле часто представляет собой сокрытие проблемы архитектуры, в виду чего и приходится изворачиваться; да и даже будучи к месту — зачастую наращивается сложность проекта без крайней на то необходимости — а это, как говорят знающие люди, самое «дорогое» в разработке — сложность.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
А сколько времени проект существует с таким подходом к разработке?
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Тоже посчитал — 3-4 часа в день именно на написание кода. Тому несколько причин:
1. Прежде чем писать — надо понять что именно надо написать. Придумать архитектуру решения, если речь не идет об узкой задаче. На это уходит много времени, в рамках проекта — до 30%.
2. Поняв что надо сделать — надо понять как это сделать. Есть, конечно, наработки, но всегда есть и альтернативы, всегда есть что-то свежее. В итоге, требуется написать прототип решения, иногда — несколько, чтобы оценить что выбрать. Если сроки сильно ограничены — делаю так, как наиболее знакомо, но при этом заказчик получит возможно не лучшее решение. Это еще 30% времени.
3. Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость. Производительность со временем падает, ничего хорошего не получается. Можно работать больше, если не прикладывать усилий для разбирательства в делаемом — то есть шпарить по шаблонам, но это опять же в ущерб возможностям и не всегда вообще это доступно в силу специфики задачи. — Это еще 30%
Еще 10 оставшихся процентов — это развертывания всего на свете, деплои, тесты и прочая.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа — итого шесть, еще около 2-3 часов отвожу на изучение платформ, инструментов, технологий, на эксперименты. Работая больше — ловлю себя на том, что острота мысли падает и в итоге работаешь отнюдь не лучше и продуктивнее, а совсем напротив.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить… Что тут сложного! На всякие раздумья и прочее их жаба смотрит осуждающее и с полным непониманием.
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
1. Прежде чем писать — надо понять что именно надо написать. Придумать архитектуру решения, если речь не идет об узкой задаче. На это уходит много времени, в рамках проекта — до 30%.
2. Поняв что надо сделать — надо понять как это сделать. Есть, конечно, наработки, но всегда есть и альтернативы, всегда есть что-то свежее. В итоге, требуется написать прототип решения, иногда — несколько, чтобы оценить что выбрать. Если сроки сильно ограничены — делаю так, как наиболее знакомо, но при этом заказчик получит возможно не лучшее решение. Это еще 30% времени.
3. Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость. Производительность со временем падает, ничего хорошего не получается. Можно работать больше, если не прикладывать усилий для разбирательства в делаемом — то есть шпарить по шаблонам, но это опять же в ущерб возможностям и не всегда вообще это доступно в силу специфики задачи. — Это еще 30%
Еще 10 оставшихся процентов — это развертывания всего на свете, деплои, тесты и прочая.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа — итого шесть, еще около 2-3 часов отвожу на изучение платформ, инструментов, технологий, на эксперименты. Работая больше — ловлю себя на том, что острота мысли падает и в итоге работаешь отнюдь не лучше и продуктивнее, а совсем напротив.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить… Что тут сложного! На всякие раздумья и прочее их жаба смотрит осуждающее и с полным непониманием.