В своей работе творчество заключается в решении проблем, которые возникают на стыке ограничений разных ролей или системных уровней.
-
Можно начать с доминирующей роли по времени - роли программиста.
Задач много, проблем, которые еще не переведены в задачи - еще больше. Творчество начинается еще в момент перевода проблемы в задачу. Нужно учитывать текущий софт и его ограничения, также интересы заинтересованных в решении проблемы ролей, опыт индустрии в решении подобных проблем (спасибо llm с research режимом, с хорошим промтом можно в течении 10-20 минут узнать прикладные sota методы), и из этого всего превратить проблему в задачи и подзадачи (чтобы кусочек работы можно было сделать в один присест).
Далеко не всегда нужно “придумывать” решение, для 90% проблем уже в моей маленькой команде существуют типовые решения, скорее всего нужно использовать их. А если и попалась редкая проблема, для которой придется придумывать решение - это же решение может оказаться решением сразу для семейства проблем.
Удивительно, что для пяти похожих проблем ничего не получалось придумать, а на шестой задача попалась такая, что на ней додумались как ее решать, и после этого применили для пяти предыдущих нерешенных. Это похоже на теорию ТРИЗ Генриха Альтшуллера с переиспользованием изобретений. -
Потом добавляется роль тимлида в прошлом, и техлида теперь. В первом случае нужно думать о команде разработки, а там уже добавляется инженерия личностей, в которой я конечно же ничего не понимаю, поэтому я часто вслепую делал эксперименты над подчиненными, иногда успешно, иногда нет, но все равно это новый системный уровень “множество программистов, делящих общее пространство”. А в роли техлида нужно следить за состоянием софта, чтобы сложность не росла слишком быстро, и чтобы наши технологии были на таком уровне, на котором не будет проблемы с наймом из текущего рынка. Ограничения этих двух ролей влияют на то, как работу в роли программиста выполняю я и остальные люди в роли программистов.
-
Роль ответственного за качество - эта роль тоже накладывает свои ограничения, нельзя чтобы софт перестал работать, но при этом сложно внедрять что-то новое в систему, кроме как “на живую”
И в компоте этих ролей иногда рождаются интересные решения проблем, которые не были бы возможны, будь я по роли только программистом. Сам процесс творчества выглядит как медленное “отсечение лишнего”, то есть учет ограничений, пока не останется несколько единственно возможных путей. Конечно же это происходит с ручкой и бумагой, но процесс последовательный и предсказуемый, на входе неведомая проблема, а на выходе решение, которое потом используется для решения не только для типовых, а даже для совершенно других проблем.