Путевые заметки тимлида: творческое начало в программировании
Invite pending
Вечер пятницы проходил еще в той Москве, где не было пропусков, где не нужно было обязательно носить ни маски, ни перчатки. Пятница протекала в компании друзей, на кухне у подруги. Подруга элегантно забралась с ногами на столешницу, мы вели непринужденную беседу. Вдруг приходит сообщение от бывшего подчиненного с проекта, с которого я только что ушел. Он благодарит за то, какой опыт смог получить, за то, что ему была мной предоставлена такая возможность, несмотря на отсутствие у него опыта. Для меня это было неожиданностью, потому что я просто делал так, как считаю правильным и справедливым. Все что я пытался делать это слушать любые, самые глупые на первый взгляд идеи и доверять своим сотрудникам. А при подборе сотрудников в команду, самым главным критерием было то, что человек знает то, чего не знаю я. Это всегда гарантировало положительный отзыв на кандидата.
Однако, немного вернемся на два года назад, я только устроился на новое место работы разработчиком. В тот момент, я еще не понял насколько важно наравне с системным мышлением совмещать творческое, образное. Системное мышление идеально в теории, до момента соприкосновения с практикой. В противоположность для практики необходим теоретический базис.
Иными словами все хорошо до того, как ты получаешь баг на теоретически идеальный и покрытый тестами код. А если ты делаешь полностью новый, сложный сервис — ты этот баг получаешь в первый день промышленной эксплуатации. Или же возможна следующая ситуация: ты написал приложение, запустил, отладился, все работает. Пришел заказчик и сказал тебе, что вот тут твой фронтальный процесс не должен держать клиента в ожидании, и ты должен быстренько за неделю написать управление этим процессом, обеспечить отказоустойчивость и вообще, все должно быть идеально. Для заказчика это просто ветвление в дереве процесса, но для тебя это выливается в почти новый дополнительный сервис.
Ты пытаешься писать универсальные компоненты, выделяешь абстрактные базовые сущности. Тратишь время на то, что бы создать нечто, что будет учитывать такие внезапные снеговые осадки в жаркие июльские месяцы. Но если ты готовишься к усложнению системы, то заказчик с этим никто не придет. Закон подлости. Скорее твой стек технологий устареет и тебе будет нужно переходить на новый и обновлять версию Java.
Всем знакомы ситуации, когда ты сидишь целый день над куском кода в поисках ошибок, разозлившись, просишь коллегу посмотреть, а он тебе почти тут же показывает совершенно очевидную ошибку. Иногда ты описываешь баг коллеге — а он тебе почти моментально дает решение. Или ты прежде чем реализовывать — идешь к коллеге и рассказываешь свое архитектурное решение, а он тебе почти моментально выдает список рисков, из которого ты весьма быстро выбираешь те, которые действительно стоит учесть. С другой стороны, такой диалог может выдать тебе кучу совершенно несущественных рисков, на которые не нужно тратить время. Ведь нужно помнить, что разработка в настоящее время это бизнес, который должен нести вэлью. Твое красивое решение могут, элементарно, не оценить с точки зрения бизнеса. И казалось бы, методологический фреймворк для такого подхода гибкая методология Agile, но одно дело теория, и совершенно другое дело работающий проект с короткими циклами вывода нового функционала.
Любая крайность зло, но готовность отступить от теоретических догм, проявить гибкость, снисходительность и корректность, зачастую помогают сэкономить ресурсы. Более того, за частую такая готовность является необходимым условием работающего в боевых условиях приложения.
Зачастую молодые разработчики, окончившие бакалавриат, магистратуру, приходят с почти нулевым практическим опытом. Они могут вообще не знать теоретический базис разработки, хотя учились на информационные технологии. Иногда люди с десятилетним опытом настолько костенеют, что не в состоянии использовать новые фичи языков, да и вообще новые феймворки и дизайн паттерны современные. В итоге, мы получаем ситуацию: если человек понимает аббревиатуру SOLID — это достижение. А если он еще и понимает, что под ней скрывается, то это уже в некотором роде уникальный случай. Готовых, гибких специалистов за адекватные деньги на рынке почти нет.
Единственный вариант брать людей и учить. Хороший разработчик получится из человека, который не только легко воспринимает новое, но и разумно подвергает критике все входящее в его голову из вне. Для усвоения материала важно не брать все на веру, а перепроверять самому, пропускать через себя. Важно научить человека не конкретным инструментам, а дать возможность самостоятельно решать задачи, ошибаться, учиться исправлять ошибки, выстраивать диалог. Моя команда в какой-то момент стала состоять на половину из начинающих разработчиков.
Таким образом человек, который руководит группой разработчиков должен выступать в первую очередь в роли арбитра, поддерживающего баланс между теорией и практикой. Между новыми технологиями и работающим решением. Между интересами красивой и правильной архитектуры приложения и требованиями условного заказчика или потребителя.
Более того, неопределенность бушующего должна быть взята за аксиому. Вся команда разработки должна быть готова встретиться с незнакомыми ситуациями, никто не должен их бояться, они должны стать частью процесса. А единственный эффективный способ решать нетиповые проблемы, использовать воображение.
Однако, немного вернемся на два года назад, я только устроился на новое место работы разработчиком. В тот момент, я еще не понял насколько важно наравне с системным мышлением совмещать творческое, образное. Системное мышление идеально в теории, до момента соприкосновения с практикой. В противоположность для практики необходим теоретический базис.
Иными словами все хорошо до того, как ты получаешь баг на теоретически идеальный и покрытый тестами код. А если ты делаешь полностью новый, сложный сервис — ты этот баг получаешь в первый день промышленной эксплуатации. Или же возможна следующая ситуация: ты написал приложение, запустил, отладился, все работает. Пришел заказчик и сказал тебе, что вот тут твой фронтальный процесс не должен держать клиента в ожидании, и ты должен быстренько за неделю написать управление этим процессом, обеспечить отказоустойчивость и вообще, все должно быть идеально. Для заказчика это просто ветвление в дереве процесса, но для тебя это выливается в почти новый дополнительный сервис.
Ты пытаешься писать универсальные компоненты, выделяешь абстрактные базовые сущности. Тратишь время на то, что бы создать нечто, что будет учитывать такие внезапные снеговые осадки в жаркие июльские месяцы. Но если ты готовишься к усложнению системы, то заказчик с этим никто не придет. Закон подлости. Скорее твой стек технологий устареет и тебе будет нужно переходить на новый и обновлять версию Java.
Всем знакомы ситуации, когда ты сидишь целый день над куском кода в поисках ошибок, разозлившись, просишь коллегу посмотреть, а он тебе почти тут же показывает совершенно очевидную ошибку. Иногда ты описываешь баг коллеге — а он тебе почти моментально дает решение. Или ты прежде чем реализовывать — идешь к коллеге и рассказываешь свое архитектурное решение, а он тебе почти моментально выдает список рисков, из которого ты весьма быстро выбираешь те, которые действительно стоит учесть. С другой стороны, такой диалог может выдать тебе кучу совершенно несущественных рисков, на которые не нужно тратить время. Ведь нужно помнить, что разработка в настоящее время это бизнес, который должен нести вэлью. Твое красивое решение могут, элементарно, не оценить с точки зрения бизнеса. И казалось бы, методологический фреймворк для такого подхода гибкая методология Agile, но одно дело теория, и совершенно другое дело работающий проект с короткими циклами вывода нового функционала.
Любая крайность зло, но готовность отступить от теоретических догм, проявить гибкость, снисходительность и корректность, зачастую помогают сэкономить ресурсы. Более того, за частую такая готовность является необходимым условием работающего в боевых условиях приложения.
Зачастую молодые разработчики, окончившие бакалавриат, магистратуру, приходят с почти нулевым практическим опытом. Они могут вообще не знать теоретический базис разработки, хотя учились на информационные технологии. Иногда люди с десятилетним опытом настолько костенеют, что не в состоянии использовать новые фичи языков, да и вообще новые феймворки и дизайн паттерны современные. В итоге, мы получаем ситуацию: если человек понимает аббревиатуру SOLID — это достижение. А если он еще и понимает, что под ней скрывается, то это уже в некотором роде уникальный случай. Готовых, гибких специалистов за адекватные деньги на рынке почти нет.
Единственный вариант брать людей и учить. Хороший разработчик получится из человека, который не только легко воспринимает новое, но и разумно подвергает критике все входящее в его голову из вне. Для усвоения материала важно не брать все на веру, а перепроверять самому, пропускать через себя. Важно научить человека не конкретным инструментам, а дать возможность самостоятельно решать задачи, ошибаться, учиться исправлять ошибки, выстраивать диалог. Моя команда в какой-то момент стала состоять на половину из начинающих разработчиков.
Таким образом человек, который руководит группой разработчиков должен выступать в первую очередь в роли арбитра, поддерживающего баланс между теорией и практикой. Между новыми технологиями и работающим решением. Между интересами красивой и правильной архитектуры приложения и требованиями условного заказчика или потребителя.
Более того, неопределенность бушующего должна быть взята за аксиому. Вся команда разработки должна быть готова встретиться с незнакомыми ситуациями, никто не должен их бояться, они должны стать частью процесса. А единственный эффективный способ решать нетиповые проблемы, использовать воображение.