[Перевод] Чему я научился, проработав два года разработчиком ПО в Microsoft
Так как завершается второй год моей работы разработчиком ПО в Microsoft India, логично будет порассуждать о том, чему же я научился за последние два года.
Я пришёл в Microsoft сразу после учёбы в колледже, Indian Institute of Technology Guwahati, и эта работа стала моим первым опытом. Со временем я очень сильно вырос и получил множество новых уроков. В этой статье я постараюсь структурировать свои мысли о них.
Итак, вот пять вещей, которым я научился.
«Общепринятые сегодня факты являются результатами вчерашних исследований», — Дункан Макдональд
Когда я говорю «исследования», то подразумеваю два значения:
Проведение исследований для выявления первопричины проблемы.
Я почти сразу понял: очень легко выработать привычку не вдаваться в подробности проблемы и не понимать её истинные причины. А если вы не знаете конкретной причины существования проблемы, это почти всегда сказывается, когда вы уже почти решите задачу. «Почти» — очень важное здесь слово.
Проведение исследований для нахождения самого эффективного решения текущей задачи.
Важно понимать, что мы не просто хотим решить задачу; столь же важно решить её наиболее эффективным образом. Именно это отличает великолепную работу от посредственной. Чтобы выделиться, нужно уделить какое-то время освоению такого взгляда на вещи, а не просто выполнять работу. Именно это даёт тебе наибольший рост.
Все знают, что предварительная подготовка и выполнение домашних заданий очень важно, но в то же время очень легко выполнить их не до конца, особенно если ты решаешь не одну, а множество задач.
Когда в твоём сознании несколько задач, очень легко пойти на компромисс и не добраться до глубин каждой из них. Поэтому чрезвычайно важно постоянно помнить об этом.
Тщательные предварительные исследования помогают нам не только взглянуть на задачу эффективно и найти её оптимальные решения, но и не потерять из вида общую картину.
Самое важное — помнить, что тебе платят не за быстрое, а за точное и полное решение задачи.
Для этого требуются исследования, исследования и снова исследования.
Закон Мёрфи:
«Если что-нибудь может пойти не так, оно пойдёт не так».
Спустя два года я отлично знаю этот закон, и он истинная правда!
Я постоянно сталкивался с ним во всех своих проектах, он применим всегда, а те, кто этого не знают, будут вынуждены узнать болезненным способом.
Поэтому очень важно в первую очередь разбивать большое решение на несколько отдельных очень мелких частей. Затем нужно потратить время на то, чтобы учесть все исключения/ошибки, которые могут произойти в этих мелких отдельных частях. В то же время нужно понимать, как эти части будут вести себя совместно и какие исключения/ошибки могут возникать из-за их взаимодействий.
Ключевым моментом является развитие в себе предусмотрительности.
Но что делать, пока развиваешь в себе предусмотрительность? Нужно создавать множество проверок и балансов для отлавливания подобных проблем заранее.
Многие из будущих проблем можно отловить на ранних этапах благодаря юнит-тестам, интеграционным тестам и тестам производительности. Одним из важнейших технических уроков, которые я получил, только когда начал работать в отрасли, была необходимость написания кода с покрытием тестами. Это поможет не только мне, но и всей команде, которая возьмёт мою работу и разовьёт её в будущем.
Для отлавливания проблем, упущенных тестами, существует инфраструктура, называемая средой препродакшена, в которой имитируется работа в реальном мире, то есть в среде продакшена. Очень важно проверить, что ваша часть кода какое-то время надёжно работает в среде препродакшена.
Но даже после применения всех этих проверок и балансов могут возникать проблемы.
Самое важное в таком случае — учиться на этих ошибках и не корить себя за них, потому что гораздо критичнее, чтобы они не возникали в будущем.
Работая в отрасли разработки ПО, я осознал важную вещь: у нас слишком много задач, которые нужно решить, но время ограничено.
Поэтому вполне приемлемо использовать приоритизацию и точную оценку ключевых компонентов, как для успешной команды, так и для отдельного человека. Так как мы не решаем каждую проблему по отдельности, я осознал, что любую проблему можно рано или поздно решить, но нужно оценивать время, которое будет на неё потрачено, и её важность.
Чтобы ответить на вопрос, насколько она важна, мы назначаем задаче приоритет, который может быть простым числом, обозначающим её важность. Также можно назначить число для обозначения количества дней, которое по нашей оценке потребуется для решения проблемы. Эти два параметра очень важны по следующим причинам:
- В большинстве случаев у проекта есть не один, а несколько ответственных лиц. Поэтому всегда полезно установить хорошую коммуникацию со всем руководством.
- Эти параметры помогают выбрать работу, которая оптимизирует использование вашего ограниченного времени.
Таким образом мы пытаемся дать ответ на важный вопрос, а именно: какую задачу решать первой?
Инцидент — это незапланированная приостановка работы клиентов, которые используют ваш сервис.
«Управление инцидентами — это максимально быстрый процесс журналирования, записи и разрешения инцидентов для восстановления бизнес-процесса или обычной работы сервиса».
Когда я учился в колледже, то всегда представлял, что моя работа будет заключаться в написании кода для решения задачи, то есть в творчестве. Но за последние два года я осознал, что очень важной частью моей работы является участие в устранении инцидентов с нашим продуктом.
Для управления этими инцидентами мы в команде по очереди берём на себя ответственность за весь продукт. То есть когда инцидент происходит, он может быть и не связан с тем, что я создал ранее.
Чему же меня научили эти инциденты?
Происходившие в прошлом инциденты заставили меня осознать, что очень важно быть в курсе того, над чем работают остальные.
Это не только развивает во мне привычку смотреть на их решения и находить в них проблемы ещё на ранних этапах, но и брать примеры с них, а также использовать ключевые компоненты в моих собственных решениях.
Эти инциденты приводят к серьёзным простоям у наших клиентов/руководства, и часто их решению отдаётся высокий приоритет.
Также они очень учат тонкостям различных аспектов, поэтому мы можем понимать их глубже. Приоритетность этих инцидентов развивает быстрое мышление и учит быстро предлагать чёткие, надёжные решения, чтобы клиенты могли продолжить свою работу.
Часто при разрешении таких инцидентов мы лицом к лицу сталкиваемся с более крупными проблемами, которые, в свою очередь помогают нам понять следующее:
Чего не хватает нашему продукту? Какие проблемы мы должны решать в будущем?
«Когда кто-то что-то говорит или делает, всегда предполагайте благие намерения. Вы удивитесь, что ваш взгляд на человека или проблему станет совершенно иным. Когда вы предполагаете плохие намерения, то ощущаете гнев. Если избавиться от этого гнева и предположить благие намерения, то вы поразитесь», — Индира Нуйи
Сотрудничество внутри команды — очень мощная вещь, усиливающая и индивидуальную работу.
Только в профессиональной среде я понял роль, которую играет группа личностей с их уникальными сильными сторонами и опытом в подходе к проблеме и её решению.
При поиске решения любой проблемы всегда полезна свежая пара глаз. Поэтому для преодоления препятствий очень важно бесконфликтное сотрудничество.
Сотрудничество в Microsoft подразумевает не только совместную работу с людьми в твоём офисе, но и работу с людьми на разных континентах и в разных часовых поясах. Как же его оптимизировать, особенно когда вам приходится взаимодействовать с кем-то, кого вы никогда не видели? Вы не знаете ни этого человека, ни трудностей, с которыми ему довелось столкнуться.
Кроме того, мы столкнулись с уникальной ситуацией: из-за пандемии COVID-19 всем пришлось работать из дома. В этот период размер наших команд значительно увеличился, и многие из наших коллег присоединились к организации виртуально.
Самый важный урок, который я извлёк из всех этих ситуаций, заключается в том, что лучше всего всегда предполагать благие намерения других людей и всегда понимать проблемы, которые у них есть.
Проявление терпимости и уверенности в такие времена всегда поможет создать хороший командный дух и позитивную культуру. Постепенно это будет сказываться и на результатах.
Я считаю, что по своей сути разработка ПО заключается в решении задач: хотя осознать и понять технические подробности довольно просто, гораздо сложнее оказывается понять нужное отношение, взгляд и подход к решению задачи.
Основная цель этой статьи заключается в том, чтобы повторить все те моменты, которые мы всегда знали, но постоянно игнорируем. Именно постоянное их осознание отличает профессионала от студента, и за последние два года мне удалось совершить этот переход.
На правах рекламы
Закажите и сразу начинайте работать! Создание виртуального сервера любой конфигурации в течение минуты, создайте свою конфигурацию в пару кликов.
Подписывайтесь на наш чат в Telegram.
