Разработка подходящего программного обеспечения
Старшие разработчики, эксперты, специалисты, наставники, рок-звезды. Это те, кто берет на себя инициативу во многих проектах. Иногда так и должно быть, но на своем опыте консалтинга я пришел к выводу, что зачастую это не лучшее решение. Вы можете быть одним из тех людей, которых я описываю, и я сочувствую этому менталитету, но такой образ мышления может привести к большому падению на пути к величию окончательного решения.
Как старшие разработчики в консалтинге и с нашим опытом, когда мы смотрим на проблему клиента, для решения которой они наняли нас, иногда может потребоваться несколько минут, чтобы придумать решение на высоком уровне. Мы извлекаем то, что узнали из предыдущей работы, и сразу же применяем это к нашему первому задуманному направлению решения. Это отличное умение. Это полезно для нас и клиента, снижая их затраты и повышая эффективность наших методов.
Однако (это ужасное «однако») этот импульсивный навык может привести нас к ошибочному пути намерений. Решение этой проблемы, судя по проектам, над которыми я работал в последнее время, состоит в том, чтобы привлечь к этому младшего разработчика. Пусть ведут!
Из-за отсутствия опыта они склонны задавать много вопросов, только если рабочая среда слишком подчеркивает их желание это сделать. С этой привычкой задавать вопросы они, как правило, задают вопросы, которые вы, возможно, не задаете. Это запускает новый диалог, который приводит к расширенному мышлению, философии дизайна, а иногда и совершенно другим парадигмам программирования. Это выводит старших разработчиков из их зоны комфорта. Со временем это заставляет нас думать как младший. Это здорово!
С моим нынешним работодателем, Scott Howard Consulting (скоро будет переименована в Moss Rock Consulting), наш девиз — «Разработка программного обеспечения, которое подходит». Мне нравится эта идея. Менталитет такой:
У плотника есть свой инструмент, что-то, чем можно резать и придавать форму дереву. Во время работы он не думает о ручке инструмента, он думает о кончике и кромке своего лезвия. Он становится продолжением его самого, позволяя ему совершенствовать свою работу. Сосредоточив внимание на краю своего инструмента, он может сосредоточиться на безупречной и детализированной эстетике и функциональности своего стола, стула или пороговой арки и колонн хупы. Создатель того инструмента, который он использовал, если все сделано правильно, разработал инструмент, который подходит для его процесса.
Это то, к чему должны стремиться разработчики программного обеспечения. Все мои статьи обычно заканчиваются призывом к действию для менеджеров и разработчиков в сфере консалтинга, и эта ничем не отличается: пусть джуниоры возьмут на себя ответственность за проект разработки, а вы будете их наставником и будете рядом с ними. Затем, старшие, приходите и завершите работу, убедившись, что программное обеспечение, над которым вы работали, действительно соответствует потребностям ваших клиентов и становится продолжением их рабочего процесса. Ничто не становится громоздким, заставляя их объективно думать о том, как с этим работать.
Это моя напыщенная речь на данный момент. Пожалуйста, найдите меня в твиттере по адресу @JShoemakerDev, тот же тег, что и мой блог здесь, и дайте мне знать, что вы думаете! И не забывайте продолжать кодировать!
