Какой совет оказал наибольшее влияние на вашу карьеру в DevOps

Автор оригинала: Matthew Broberg
  • Перевод
Взгляните на практики, принципы и модели, которые повлияли на карьеры ведущих специалистов в DevOps, и поделитесь своей собственной мудростью.

image


Мне нравится изучать различные аспекты open-source проектов, особенно когда они набирают популярность в сфере DevOps. Проекты, которые относят к «технологиям DevOps», могут представлять собой масштабируемые системы для совместной работы, которые решают широкий спектр проблем – от методов передачи сообщений до мониторинга. Всегда есть что-то новое, что можно исследовать, устанавливать, раскручивать и исследовать.

Тем не менее, DevOps не может существовать без принципов. Некоторые из этих концепций – очевидные истины, для принятия которых требовалось некоторое время. В свою очередь, есть и другие идеи, которые помогают нам многое признавать и выходить за рамки наших когнитивных искажений.

Хотя, строго говоря, он не относится к DevOps, один из принципов, который изменил все для меня — это Канбан. Простая идея о том, что работа должна быть прозрачной и оптимизированной, была радикальной для такого хронически многозадачного человека, как я. Я поддерживаю наглядность рабочих процессов и по сей день. Возможность не теряться в задачах стала для меня огромным облегчением. Кроме того, я больше не радуюсь промежуточным успехам: теперь я радуюсь решенным задачам.

Чтобы узнать, что повлияло на моих коллег, я попросил членов DevOps-команды OpenSource.com поделиться своими мыслями по этому вопросу:

Какая из концепций DevOps (практика, принцип или модель) изменила вашу карьеру?


image

Алекс Бунарджич


Ошибайтесь быстрее, ошибайтесь как можно раньше, ошибайтесь так часто, как можете. До того, как я вник в эту удивительную концепцию, я тщетно бился и работал в стандартной водопадной модели. Моя карьера состояла из ряда неудачных проектов, и все они начинались с тезиса «Отказы недопустимы!». Это чрезвычайно утомительная модель, которая снижает эффективность работы и приводит к тому, что от одного разочарования к другому приходится переходить к другому.

Воплощение в жизнь шквала быстрых и неистовых отказов – лучшее, что случилось в моей карьере. Фрустрация сменилась ощущением полета. Это привело к массовому принятию/внедрению практик TDD [test-driven development – разработка на основе тестирования] и к осознанию того, что TDD — это не «test», а «DRIVING»!

image

Кэтрин Луи


Культурный хакинг. Я понятия не имела, что существует название метода, который я (как партизан) использовала, чтобы изменить корпоративную культуру, но потом я увидела видео Себа Паке «Ignite Montreal» и порадовалась, что этим занимаюсь не только я.

image

Клемент Верна


Постоянное улучшение. До тех пор, пока меня не познакомили с идеями непрерывного совершенствования, я не искал путей развития ни в своей работе, ни в карьере. Постоянное совершенствование заставило меня осознать, что именно зависит от меня. Я понял, что смогу бросить вызов самому себе, узнав что-то новое и выбравшись из своей зоны комфорта. Это привело к тому, что я начал вносить свой вклад в проект с открытым исходным кодом (Fedora), а затем начал работать в Red Hat. Это определенно изменило мою карьеру.

image

Джейсон Хиббетс


Все началось с «The Lean Startup» на моем первом саммите «Code for America Summit». Я отчетливо помню поворотный момент в моей карьере в 2012 году. Эрик Рис, автор «The Lean Startup» и член совета директоров “Code for America", был на сцене вместе с Тимом О'Райли. Они говорили о взломе кода, а также о культуре и неудачах при проверке знаний. Моим самым большим достижением было знакомство с «The Lean Startup». Я скачал книгу и прочитал большую ее часть во время полета домой. Она изменила мой подход к работе и к руководству командой.

Самым большим изменением, которое я внес, стало внедрение циклов обратной связи. Это критически повлияло на стиль работы и мою команду. Я сместил привычки моей команды в сторону принятия решений, основанных на данных. Мы стали обмениваться информацией и идеями в рамках циклов обратной связи. Также мы проводим еженедельные встречи для проверки здоровья и постоянно изучаем наши рабочие процессы и гипотезы. Кроме того, мы экспериментируем с новыми идеями и оцениваем эти эксперименты. Мы проводим встречи для в начале работы над задачей в процессе работы над ней и после ее завершения – это позволяет нам понять, что делать дальше, а что — нет, чтобы мы могли двигаться дальше.

image

Вилли-Питер Шауб


Во время двухмесячного академического отпуска в 2018 году меня осенило, что страх неудачи отбирает у меня энергию и страсть к разработке ПО, а я любил эту карьеру. Я понял, что ошибки – это не трагедия, а инструмент для инноваций, сотрудничества и непрерывного обучения, который подпитывает DevOps. И это осознание стало ключевым моментом в моей карьере. Прозрачность сотрудничества, прогрессивное воздействие, развитие, основанное на гипотезах и тестах, а также методы CD – все эти практики, создают возможности как можно скорее добиться отказа, провести проверки и адаптировать решения, над которыми мы работаем (и свою карьеру).

Ваша очередь


DevOps может многому вас научить, даже если вы ни разу не откроете терминал или какую-либо программу. Поэтому я задаю вам тот же вопрос:

Какая концепция из DevOps оказала наибольшее влияние на вашу карьеру?

Пожалуйста, поделитесь своими мыслями в комментариях.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:



Полезное


SkillFactory
Онлайн-школа Data Science и разработки

Комментарии 6

    +1
    Лично для меня главным советом был совет от моего студенческого друга — «Под лежачий камень вода не течет».
      0
      Прототипируй
        +1
        ...bash как собака сутулая
          +3

          А на меня в смысле карьеры сильное впечатление произвели видео Clickspring (https://www.youtube.com/channel/UCworsKCR-Sx6R6-BnIjS2MA). Там человек 4 fun работает с бронзой.


          А урок, который я для себя там вынес, что можно получать эстетическое удовольствие от базовой работы. Просто делать её тщательно и без булшита про MVP и Time to Market.


          И тогда:
          а) Резко возрастает экспертиза (потому что хорошо понимаешь то, что делаешь).
          б) Результат работы такой, что его можно потом переиспользовать не опасаясь за поток WTF
          в) Работа доставляет удовольствие.


          Быть хорошим инженером, который делает хорошие вещи хорошо — это хорошо! Быть инженером, который делает что-то кое-как — плохо.

            0
            Как говорится, дорогу осилит идущий!
              0

              Самый классный тезис, к которому пришло существо: "Быстрее сломаем, быстрее починим" :-)

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое