Как стать автором
Обновить

Из инженеров в руководители: сохранение технических навыков

Время на прочтение 7 мин
Количество просмотров 19K
Всего голосов 34: ↑33 и ↓1 +32
Комментарии 8

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

Сколько я видел такого совмещения — чаще всего это заканчивается «программированием в PowerPoint», иногда — возвращением в «чистые инженеры». Уж больно разное всё — действительно «работать на двух работах», но в одно и то же рабочее время.
Но кто хочет попробовать — параграф «Ваш код не должен попадать в production» очень полезен.

Я наоборот переквалифицировался из руководителей (с дизайнерским бэкграундом) в разработчики и теперь кайфую от того, что мне проще самому что-то реализовать чем кому-то объяснять или кого-то заставлять во многих случаях. В итоге все получается делать быстрее а уважение коллег — бесценно.
А так — да, руководить и кодить одновременно — очень сложно, что-то одно всегда страдает, поэтому рисерч и участие в побочных проектах для поддержания квалификации руководителя — очень полезно, но не прямое участие в разработке основного проекта.

является более эффективным наставником команды инженеров и может быть для них примером;
— Вот это будто с устава воинской службы. Где власть по праву власти, там банальная дедовщина и нежелание работать. От забора и до заката тут не получится

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

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

Нахожусь на такой должности с той лишь разницей, что у меня не чисто софтверные, а софтверно-железные проекты. В простонародье — эмбеддерство.
В статье все, более или менее правомерно, что хотелось бы заострить:


  • Кодер или наставник? — Наставник. Вместо "создания" продукта целью должно быть "создание" людей, команды. Есть огромное желание все сделать самому, и от него надо избавляться путем делегирования заданий.
  • Все чаще себя ловлю на мысли, что важной частью работы компетентного технического руководителя является структурирование и распределение информации. Пришел e-майл извне с даташитом — загрузил в Вики, проинформировал команду. Кто-то из команды сделал отчет — а где запись в баг-трекере с сылкой? Напомнил. У кого-то появилась интересная идея? Записал в таск-лист, чтобы показать на следующем совещании по годовому бюджету. И т.д. и т.п. Программисты — разгильдяи и кто-то за них должен делать и такую работу.
Как ни крути, а быть наставником теряя квалификацию сложно. Двужильным быть надо, но ради чего?
Может «быть наставником сохраняя квалификацию сложно»? А то иначе двужильностью не пахнет))
Про «говорить последним» — полезный совет. При этом очень старый — я помню еще в Цусиме встречал упоминание этой традиции на флоте — первым на важных собраниях (типа решения вопроса о сдаче корабля врагу) всегда выступал самый младший офицер, и дальше по возрастанию званий, чтобы капитан или адмирал не давили младших офицеров своим авторитетом. Вот только до сих пор много кто это правило нарушает, хотя ему получается уже несколько сотен лет.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий