5 блокеров для развития

Недавно общался с нашим разработчиком про развитие и порефеклексировал на тему того, что мне мешало или наоборот, помогало в развитии как инженера. Пришёл к выводам, что часто замедляет развитие следующее:

  1. Боязнь показаться некомпетентным. Часто амбиции и желание казаться умнее побеждают здравый смысл. Ты чего-то не понимаешь, но молчишь, потому что не хочешь в этом признаться. И чем дольше – тем сильнее это будет мешать. Если же всегда держать в уме, что ты чего-то не знаешь и это нормально – будет легче задавать вопросы. Спрашивай, ошибайся, даже тупи иногда! Ты никогда не будешь знать всё, но у тебя всегда будет шанс узнать что-то новое. Ты хочешь казаться топовым специалистом или быть им?
  2. Ожидание, что тебя всему научат. Да, в больших компаниях могут помочь сделать personal development plan, там даже может быть внутренняя школа/академия, но только ты отвечаешь за своё обучение. Любой мой бывший одногруппник скажет, что 80% информации на факультете информатики ему ничего не дали, так почему образование в какой-то компании будет лучше? Ищи информацию, анализируй свои сильные и слабые стороны, проси фидбек от коллег и руководителей, понимай свои цели и «создавай» образовательный курс под себя, а не ожидай, что это кто-то сделает за тебя
  3. Слепая вера авторитетам. «Тимлид сказал, что так делать нельзя». «Наш лучший бекендер говорит, что postgres лучше mysql». «В твиттере написали, что надо использовать redux». Инструменты развиваются. Ограничения устаревают. Почти для любого инструмента можно найти место, где он будет работать лучше самого популярного решения (а ещё это же утверждение справедливо для людей!). Лучшие умы не решали всех задач и не пробовали всё. «Оборотная сторона экспертов – то, что они слишком много знают о текущих ограничениях. Кто-то, взглянув свежим взглядом, может обойти эти ограничения практически благодаря своему невежеству» (с) Патти МакКорд – Сильнейшие. Анализируйте разные мнения, ищите противоположные точки зрения, задавайте вопросы!
  4. Вера в то, что можно всему научиться по статьям. Статьи помогают решать проблемы и могут помочь ответить на конкретный вопрос. Но что делать, когда даже вопрос не известен? Книги помогают опуститься на другой уровень абстракции – они читаются дольше и с бóльшим погружением, часто они помогают задавать вопросы, но не дают ответов. Стековерфлоу помогает использовать чужие ответы, книги – давать свои.
  5. Перекладывание ответственности. «Менеджер плохо сформулировал задачу», «На бекенеде сделали неправильное апи, не могу продолжать». Да, часто хочется написать такой коммент в jira/слак и пойти жаловаться кому-то на коллег, потому что никто не может НОРМАЛЬНО сделать свою работу. Но разработчики нужны для решения задач, а не для написания кода. Да, между простой и сложной задачей мозг выбирает понятную и не хочется тратить свои ресурсы на это, но в этом ценность профессионала – он потратит своё время и силы (а не менеджера или другого разработчика), разберётся в задаче (и не только с технической стороны, но и со стороны бизнеса) и сделает решение (или предложит своё, более простое/лаконичное/удобное). Будь инженером, который решает проблемы, а не бесполезным «кодером», который работает только в идеальных условиях!


Показать комментарии