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