Фраза «управление временем» — одна из наиболее часто используемых фраз в менеджменте, продуктивности, заботе о себе и т. д. У нас в руках есть этот ценный ресурс, и у нас должна быть идея — или, лучше сказать, философия — как его использовать. В этой статье я хочу больше узнать о том, что значит время для программиста. То, как мы видим время, и наш подход к нему меняются, когда мы идентифицируем себя как программиста-ремесленника. Эта статья является второй частью цикла статей об искусстве программирования. Первую часть вы можете найти здесь:
Из-за рабочей среды подход программиста основан на сроках, в то время как для художника (в общих ситуациях) время — это набор вдохновляющих моментов. Эти два разных подхода ко времени могут быть одним из самых фундаментальных различий между художником и программистом. Дело не в том, что у художника нет дедлайна, а у программиста нет моментов вдохновения (можете сказать, потока). Но если мы посмотрим на это как на спектр от полного отсутствия дедлайна до строгого дедлайна, программист окажется ближе к строгому дедлайну, а художник будет ближе к полному отсутствию дедлайна.
Прежде чем мы углубимся в детали, давайте посмотрим, как мы занимаемся разработкой программного обеспечения сейчас и как сильно она изменилась за последнее десятилетие. Мы пришли от традиционного водопадного процесса к гибкой методологии. Поведение инженеров, рабочая среда и многие другие аспекты резко изменились. Когда мы смотрим на эти изменения, мы видим, что мы отходим от строгого дедлайна. Что изменилось? Соответствуют ли его требованиям? Я так не думаю. Если нам нужна заявка к определенному сроку, она нужна нам к этому времени. Что изменилось, так это то, как мы видим проблему времени. Это огромно. Все подходы, которые у нас есть сейчас, касаются определения проблем, связанных со временем, бережливых стартапов, MVP, прототипирования и т. д. Время похоже на неизвестное существо, и мы пытаемся найти язык для общения с ним с помощью этих подходов без ущерба для качества. .
Для программиста тайм-менеджмент и дедлайны неоспоримы. Мы не можем изменить характер работы. Каждое требование имеет крайний срок, и оно должно быть выполнено к этому сроку. Но мы видим, что время стало фактором качества, а не просто ресурсом.
Мы говорили о том, что программист-ремесленник не может писать плохой код. Если рассматривать время как фактор качества, то программист-ремесленник не может написать код, который не уложится в сроки (я не говорю о мелких промахах). Возможно, это самый простой и в то же время самый абстрактный способ описать время, связанное с программированием. Наши оценки времени, описания задач и решения будут по умолчанию учитывать время и управление временем. Мы не пытаемся управлять временем, но мы пытаемся изменить то, как мы определяем проблему и предлагаем решения, касающиеся времени. Разбиение проблемы на маленькие шаги и оценка на основе этих шагов — не единственное решение. Само решение должно быть достаточно умным и качественным, чтобы экономить время.
Тайм-менеджмент, временные ресурсы и все эти общие дисциплины в отношении времени являются действительными принципами. Но я вижу время как нечто большее, чем просто временную шкалу. У нас должна быть философия того, как мы ее используем в отношении требований. Придерживаясь этой философии, мы можем иметь лучшую оценку, лучшую рабочую среду и более высокое качество.
