Во многом этот тред навеян заполнением своего Career Mapping в GitLab и обсуждением этого с многими людьми "а как у вас это происходит" :)
Начнём с самого простого - с иерархии. Если с первыми шагами у инженера всё просто - junior, middle, senior, то дальше всё нетривиальнее - часто с точки зрения _инженерных_ позиций наступает карьерный тупик
Когда я говорю о карьерном тупике инженерной работы, то имею ввиду, что часто "продолжением" этой лесенки рисуют всякое "тимлидство" - должности, направленные на управление людьми, а не кодом.
Структура карьерной лестницы целиком диктуется бизнес-потребностями компании, поэтому в том, что к примеру в аутсорсинговой небольшой компании будет такая градация нет ничего убедительного - инженеры выше сенйьора могут быть нужны в единичном экземпляре
По моему опыту, четким признаком такого места является наличие "высокой" технической должности (она может называться очень по-разному в разных компаниях - Solution Architect, CTO, Tech Lead ) без внятных критериев получения подобной должности.
Другими словами, речь идет не о развитии конкретного инженера, а о "заполнении" вакансии. Когда вакансия наверху освободится (или появится, к примеру, вследствие роста компании) - компания тем или иным способом её заполнит. До этого вы можете быть хоть трижды молодцом
Еще раз акцентирую внимание - подобная структура - ни хорошо ни плохо, но важно осознавать её, чтобы понимать, как она соотносится с вашими карьерными целями и задачами.
@dmtrKovalenko ванга мод он :) Ответил своим ответом в треде :)
@dmtrKovalenko Побочным эффектом того, что карьерная лестница коротка является огромное расстояние между её ступеньками в финансовом плане. Цифры $500 -> $2500 -> $5000 типичный пример такой лестницы (да, обычно между ними пара промежуточных шагов, но общая идея именно такова)
@dmtrKovalenko Подобные цифры обычно полностью обескураживают наших инженеров, когда они выходят на западные рынки и осознают, что разрыв в 20% зарплаты между грейдами - уже достаточно большой, а рост зарплаты больше чем на 10% за раз - выдающееся событие
@dmtrKovalenko Сейчас мне приятно, что все больше компаний принимают западную модель градации инженеров, которая длиннее. Опять же, названия могут быть разными, но у нас в GitLab эта цепочка называется junior->intermediate->senior->staff->principal->distinguished->fellow
@dmtrKovalenko При этом независимо от длины лестницы, есть два подхода к движению по ней.
Первый подход - "принцип молодца". Если вы "молодец" - двигаетесь дальше-выше по лестнице. Ключевой вопрос в таком подходе - кто и как определяет что вы "молодец". Самый простой сценарий - ваш менеджер
@dmtrKovalenko Если ваш менеджер - менеджер в "менеджерской иерархии" - это более-менее ок, если же ваш менеджер - это условный "тимлид", который находится в одной иерархии с вами - поздравляю, вы столкнулись с самым, наверное, распространённым в СНГ конфликтом интересов
@dmtrKovalenko Я привык видеть в людях только хорошее, но на позиции консалтера я не раз видел, к сожалению, как "тимлиды" долго "зажимали" талантливых сотрудников на нижних позициях, потому что понимали, что с их потенциалом они вполне рискуют поменяться местами в ролях "начальник-подчиненный"
@dmtrKovalenko Частично это решается фидбеком в стиле 360 - когда фидбек дают к примеру ваши коллеги, "продакт" (или представители заказчика), менеджер и так далее. В таких подходах скрывать "бриллианты" в грязи становится сложнее
@yevsyuhov у нас senior могут идти на engineering manager как раз
Я не раз видел как хорошие инженеры senior-уровня плохо справляются с функциональными задачами уровня выше
@dmtrKovalenko Еще одним печальным фактором, который очень сложно отследить в росте по принципу "молодец" (из-за отсутствия четких критериев) - когда компании невыгодно чтобы вы росли. Надеюсь ни для кого не станет секретом, что к примеру аутсорсу важно большое количество "пушечного мяса"
@dmtrKovalenko Часто бывают ситуации, когда команду продают наружу по "flat rate" - каждый час "тушки" стоит Х денег. При таком подходе самые сеньйористые могут даже работать в минус и в таком сценарии далеко не всегда компании выгодно продвигать сотрудников
@dmtrKovalenko Чаще всего компания испытывает кризис квалифицированных кадров (потому что ПОД условного сеньйора можно нанять еще Х джунов), но иногда если у компании бенч уже забит - это может стать тормозом в вашем развитии. И об этом вам никто не скажет
@dmtrKovalenko Но я отвлекся. Второй подход к развитию очевиден: чётко сформулированные критерии грейдов, плюс Career Path между ними (к примеру, именно такой путь применяется в GitLab)
@dmtrKovalenko К сожалению, этот путь тоже совсем не радужный и движение по нему у меня (к примеру) вызывает острые приступы депрессии, гнева пополам с синдромом самозванца
@dmtrKovalenko Итак, у нас есть чётко сформулированный список "поведений", которые вы должны показать, чтобы получить следующий грейд. Вы показываете доказательства того, что вы систематически демонстрируете эти "поведения". Вы понимаете чего вам не хватает и можете спокойно планировать
@dmtrKovalenko В итоге, проходя маппинг на условного Staff (мой следующий этап после Senior) - обнаруживаешь, что часть активностей у тебя закрыты и сильны, а часть - наоборот никак не представлены. И рекомендация менеджера в таком случае "фокусироваться на слабых местах"
@dmtrKovalenko В итоге, абстрактная компания вместо получения профита от того, что инженеры имеют чётко выраженную специализацию (вот те мифические 10х) должна "страдать" от того, что инженеры закрываются активностями, которые нужны чтобы хорошо "выглядеть" в карьерной матрице
@dmtrKovalenko Мне в принципе печалит идея "resume driven development", а это подозрительно близко к нему, но суть еще в другом.
Когда мы закрываем KPI (а наша матрица - это просто еще одна форма KPI) очень легко за деревьями не увидеть леса
@dmtrKovalenko Фактически, инженер делает выбор - двигаться вперед занимаясь тем что ему нравится, или вкладываться в то, что поможет ему продвинуться дальше. К сожалению, исключительно с моей невысокой _сеньйоровской_ колокольни - я не уверен что закрытие этих KPI улучшает проект в целом
@dmtrKovalenko Поэтому в этом контексте (как мне кажется) является регулярный контроль себя "как то что я делаю можно приложить в какой-то KPI", чтобы потом не поднимать историю за год или два доказывая, какой вы профессионал или проявляете те или иные качества, важные для бизнеса
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Итак urql. Если вдруг это буквосочетание прошло мимо-вас - это мощная и эффективная альтернатива apollo client в качестве graphql клиента
Когда я первый раз узрел formidable.com/open-source/ur… то-ли на Hacker News, то ли на Dev.to мой скепсис был столь же велик, как технический долг @vue/test-utils
Однако из этого выросла мощная библиотека с уникальными фичами
Более того, если бы в абстрактном GitLab я бы сейчас принимал решение - я бы взял именно urql и в этом треде попробую пояснить почему
Для тех, кто не в курсе - Apollo Client это "толстый graphql-клиент". Он автоматически выполняет нормализацию кеша, пользуясь тем, что в GraphQL строго типизированные данные
О недостатках, хотя нет, хм... ОСОБЕННОСТЯХ Apollo Client можно говорить очень долго - к примеру, они КРАЙНЕ react-centric, но есть у Apollo Client важная фича - это управление local state
Фактически, вы можете из своих компонентов, продолжать писать GraphQL-запросы и мутации и ваши компоненты __почти__ не будут знать работают ли они с локальным состоянием или с состоянием сервера.
Почему почти? потому что придется писать директиву @client
Спасибо всем за дельные замечания и вопросы. Как и обещал - делюсь своим видением проблемы стейт-менеджмента
Для меня сейчас - это основная и фундаментальная проблема в рамках GitLab. Я ее формулирую так "как реализовывать хранение и управление состоянием так, чтобы не рос технический долг и не страдал скорость деливери фич"
Нюанс начинается уже с определения: я осознанно ставлю вопрос технического долга важнее скорости деливери фич. Это связано с тем, что в случае "кризиса срочно-надо-на-вчера" (а так бывает и это нормально), когда мы ставим технический долг во главе угла - мы можем им пожертвовать
Хочу в качестве утренней разминки рассказать о сне, своих экспериментах с ним и, возможно, подсказать как спать лучше
Для меня сон - это всегда ощущение потерянного времени и маленькой смерти. Мне жалко спать. Поэтому я всегда относился ко сну как к необходимому злу и пытался его оптимизировать
Когда я работал в аутсорсинговой компании, практиковал полифазный сон. Спал 3 часа ночью и 2х45 минут днём. Первые две недели нереально тяжело, потом нормально. Прекратил после 3 месяцев, когда понял что начал тупеть - работать в таком режиме можно, придумывать что-то нет