Иногда в IT-компаниях или IT-подразделениях среди проектного менеджмента начинает появляться мнение, что разработчик после 25 лет — уже не тот (прим. автора — «не может быстро г… нокодить, а пишет медленно и аккуратно»), а программист после 30 — странное социальное явление, переросток (прим. автора — «сильно умный, придирается к требованиям»).
Менеджеры все чаще начинают злостно не понимать, отчего PHP разработчик, вроде опытный, тратит так много времени на… доверстывание куска веб-страницы, а с задачей исполнения javascript «во всех популярных браузерах» сражается два дня, расточительно тратя деньги компании на такие «мелочи».
Ахтунг! В вашу компанию просочились управленческие профаны с «рынка», которые понятия не имеют, что такое эффективная работа с творческой интеллигенцией, и они продолжают по привычке продавать картошку и втюхивать вам и руководству дешевые фаллоимитаторы.
Дальше будет только хуже, нельзя терять время и пора готовиться к перевороту.
ProductOwner с рынка:
Нам знаком путь типичного Программиста, вспомним его...
Начало пути
Некоторые, особо одаренные личности, начинают писать код в старших классах школы, некоторые участвуют в проектах по разработке в студенческие годы. Но наиболее активная фаза получения и применения знаний на практике наступает после окончания ВУЗа.
Первые проекты и команды
Разработчики впервые сталкиваются с большими системами и на практике постигают, почему нужно оставлять в коде комментарии, соблюдать модульность, писать автоматизированные тесты. Большие проекты вызывают активную переоценку академических знаний, особенно в области объектно-ориентированного программирования.
Немаловажным является опыт, получаемый в ходе работы в команде программистов. Нужно привыкнуть, что есть коллеги более опытные и умные, есть начинающие, есть неряшливые — нужно подавить брезгливость к чужому, особенно некачественному коду — а это непросто.
На освоение комфортной тактики работы с командными инструментами (трекеры, системы контроля версий) уходит немало времени. А еще инструменты в разных командах — разные, приходится переучиваться.
Первые библиотеки
Заметил, что разработчиков, способных создавать качественные библиотеки — мало. Один из десяти, возможно меньше. Думаю из-за того, что тут требуется понимание ПРИЧИН появления модульности, концепций ООП и внутреннее, а не «синтаксическое» постижение паттернов. Если удалось в прошлом запутать и завалить этим пару-тройку проектов — опыт пригодиться. А если посидели на поддержке/доработке г… нокода годик, еще лучше.
Понимание реляционной теории… на практике
Тут специалисту не помешает опыт проектирования и затем поддержки проектов с интенсивным использованием баз данных. С удивлением обнаружил, что программировать люди вроде умеют, а объяснить решение задачи в терминах реляционной алгебры — не могут :-) Нужна практика и чтение книжек — толстых, но зато интересных. Еще время.
Расширение кругозора
Иногда встречаются разработчики, изучающие одновременно конкурирующую технологию — чтобы лучше понять основную. Встречал такие пары: java — c#, java — php. Действительно полезная практика.
Узкая специализация
А технологиям свойственно бурно развиваться. Возьмем javascript. Мало того, что сам по себе язык «особенный» (одна модель прототипного наследования и замыканий чего стоит), так он еще собака по разному работает в разных браузерах. И чтобы профессионально решать на нем задачи — нужно имхо ежедневно висеть на профильных форумах, изучать отличия, читать статьи — в общем постоянно держать себя в форме. Аналогичная ситуация с другими популярными технологиями.
Назад к основам
А если тебя интенсивно потянуло к «основам», откуда все пошло — юниксам, C и системному программированию, то это точно займет ближайшие пару лет вечеров :-)
В общем, чем ты старше, тем глубже копаешь, специализируешься, начинаешь изнутри понимать постигнутые на практике концепции ООП, уже соглашаешься с несколькими паттернами программирования, оттачиваешь мастерство и видишь, чему еще можно поучиться.
Опс, разработчику уже 30, а кому и под 40 лет. А впереди столько еще интересного!
Планы на будущее — узкая специализация, экспертиза
Специалисты понимают, что путь в управленцы чреват быстрой потерей квалификации и приобретением бойцовских знаний выживания в аналоговых системах — противодействия троллингу, интригам, зависти и прочим духовно-нравственным фекалиям, далеким от стройных матмоделей, ООП и паттернов проектирования :-).
Поэтому лучше продолжать прокачиваться и расти в сторону эксперта с узкой квалификацией. Эксперты-разработчики действительно могут зарабатывать в максимуме немного ниже топ-менеджеров в определенных видах компаний. Неплохо и без грязи.
Идеальный рабочий день Специалиста
Приходишь к пониманию, что нужно ежедневно просматривать технологические новости, часик как минимум, чтобы быть в курсе событий. Еще часик неплохо использовать для погружения «в глубину» — повторить типы joins, исследовать тонкости работы репликации MySQL, понять и протестировать ключи команды top ;-)
Бац — принуждение к профанации
Ага, дошли до темы статьи. Бестолковый менеджмент с рынка отказывается понять, как программист, сидя за консолью последние 10 лет, не может за вечер разобраться с тонкостями работы БД Oracle, если на прошлой неделе оптимизировал запросы с БД MySQL? Или почему программист, работающий на PHP последние 5 лет и создающий отличные библиотеки, приходит в ужас, когда пытается создать переносимый между браузерами код на javascript.
Люди не понимают, что заставляют Специалиста заниматься ПРОФАНАЦИЕЙ, работая на слабо известно ему технологии, беря на свою душу грех :-)
Что же делать?
Имхо, такое нередко случается в наших отечественных компаниях и связано это с безграмотным менеджментом, управляющим высокотехнологичными специалистами.
Менеджеров нужно учить на курсах, как управлять в IT, черт возьми, а не набирать людей с улицы и сажать их на голову профессионалам — «орать умеешь и знаешь как зайти в браузер, значит будешь у нас менеджером проектов».
Дело может принять еще более печальный оборот. «Дешевый» менеджмент с рынка, чувствующий свою профессиональную непригодность, слабо развитый головной мозг (контраст с мозгами специалистов) при сильных амбициях и ощущении иллюзии власти — начинает просто ненавидеть разработчиков и безумно троллить.
Что делать. Бороться с этими оборотнями-управленцами. Выставлять их дураками на PlanningPoker и демонстрациях функционала. Подключить адекватных IT-шников компании: техдира, рук. разработки — пока не поздно выстроить открытый и формальный бизнес-процесс в котором тупость и неопытность проектного/продуктового менеджмента будет видна руководству компании.
Хотя бы процессы станут менее эмоциональными, предсказуемыми, более независимыми от рыночных фраз «мне нужен запуск сайта через неделю», «я тебя уволю», «я найду студента за пятьсот баксов, который работает быстрее».
Если ничего не получится, не терять надежду и постараться найти компанию, в которой хочется работать долгие годы, совершенствуя свое мастерство и отдавая себя ей.
Всем Разработчикам искренне желаю удачи и энергии в самореализации.
Менеджеры все чаще начинают злостно не понимать, отчего PHP разработчик, вроде опытный, тратит так много времени на… доверстывание куска веб-страницы, а с задачей исполнения javascript «во всех популярных браузерах» сражается два дня, расточительно тратя деньги компании на такие «мелочи».
Ахтунг! В вашу компанию просочились управленческие профаны с «рынка», которые понятия не имеют, что такое эффективная работа с творческой интеллигенцией, и они продолжают по привычке продавать картошку и втюхивать вам и руководству дешевые фаллоимитаторы.
Дальше будет только хуже, нельзя терять время и пора готовиться к перевороту.
ProductOwner с рынка:
Нам знаком путь типичного Программиста, вспомним его...
Начало пути
Некоторые, особо одаренные личности, начинают писать код в старших классах школы, некоторые участвуют в проектах по разработке в студенческие годы. Но наиболее активная фаза получения и применения знаний на практике наступает после окончания ВУЗа.
Первые проекты и команды
Разработчики впервые сталкиваются с большими системами и на практике постигают, почему нужно оставлять в коде комментарии, соблюдать модульность, писать автоматизированные тесты. Большие проекты вызывают активную переоценку академических знаний, особенно в области объектно-ориентированного программирования.
Немаловажным является опыт, получаемый в ходе работы в команде программистов. Нужно привыкнуть, что есть коллеги более опытные и умные, есть начинающие, есть неряшливые — нужно подавить брезгливость к чужому, особенно некачественному коду — а это непросто.
На освоение комфортной тактики работы с командными инструментами (трекеры, системы контроля версий) уходит немало времени. А еще инструменты в разных командах — разные, приходится переучиваться.
Первые библиотеки
Заметил, что разработчиков, способных создавать качественные библиотеки — мало. Один из десяти, возможно меньше. Думаю из-за того, что тут требуется понимание ПРИЧИН появления модульности, концепций ООП и внутреннее, а не «синтаксическое» постижение паттернов. Если удалось в прошлом запутать и завалить этим пару-тройку проектов — опыт пригодиться. А если посидели на поддержке/доработке г… нокода годик, еще лучше.
Понимание реляционной теории… на практике
Тут специалисту не помешает опыт проектирования и затем поддержки проектов с интенсивным использованием баз данных. С удивлением обнаружил, что программировать люди вроде умеют, а объяснить решение задачи в терминах реляционной алгебры — не могут :-) Нужна практика и чтение книжек — толстых, но зато интересных. Еще время.
Расширение кругозора
Иногда встречаются разработчики, изучающие одновременно конкурирующую технологию — чтобы лучше понять основную. Встречал такие пары: java — c#, java — php. Действительно полезная практика.
Узкая специализация
А технологиям свойственно бурно развиваться. Возьмем javascript. Мало того, что сам по себе язык «особенный» (одна модель прототипного наследования и замыканий чего стоит), так он еще собака по разному работает в разных браузерах. И чтобы профессионально решать на нем задачи — нужно имхо ежедневно висеть на профильных форумах, изучать отличия, читать статьи — в общем постоянно держать себя в форме. Аналогичная ситуация с другими популярными технологиями.
Назад к основам
А если тебя интенсивно потянуло к «основам», откуда все пошло — юниксам, C и системному программированию, то это точно займет ближайшие пару лет вечеров :-)
В общем, чем ты старше, тем глубже копаешь, специализируешься, начинаешь изнутри понимать постигнутые на практике концепции ООП, уже соглашаешься с несколькими паттернами программирования, оттачиваешь мастерство и видишь, чему еще можно поучиться.
Опс, разработчику уже 30, а кому и под 40 лет. А впереди столько еще интересного!
Планы на будущее — узкая специализация, экспертиза
Специалисты понимают, что путь в управленцы чреват быстрой потерей квалификации и приобретением бойцовских знаний выживания в аналоговых системах — противодействия троллингу, интригам, зависти и прочим духовно-нравственным фекалиям, далеким от стройных матмоделей, ООП и паттернов проектирования :-).
Поэтому лучше продолжать прокачиваться и расти в сторону эксперта с узкой квалификацией. Эксперты-разработчики действительно могут зарабатывать в максимуме немного ниже топ-менеджеров в определенных видах компаний. Неплохо и без грязи.
Идеальный рабочий день Специалиста
Приходишь к пониманию, что нужно ежедневно просматривать технологические новости, часик как минимум, чтобы быть в курсе событий. Еще часик неплохо использовать для погружения «в глубину» — повторить типы joins, исследовать тонкости работы репликации MySQL, понять и протестировать ключи команды top ;-)
Бац — принуждение к профанации
Ага, дошли до темы статьи. Бестолковый менеджмент с рынка отказывается понять, как программист, сидя за консолью последние 10 лет, не может за вечер разобраться с тонкостями работы БД Oracle, если на прошлой неделе оптимизировал запросы с БД MySQL? Или почему программист, работающий на PHP последние 5 лет и создающий отличные библиотеки, приходит в ужас, когда пытается создать переносимый между браузерами код на javascript.
Люди не понимают, что заставляют Специалиста заниматься ПРОФАНАЦИЕЙ, работая на слабо известно ему технологии, беря на свою душу грех :-)
Что же делать?
Имхо, такое нередко случается в наших отечественных компаниях и связано это с безграмотным менеджментом, управляющим высокотехнологичными специалистами.
Менеджеров нужно учить на курсах, как управлять в IT, черт возьми, а не набирать людей с улицы и сажать их на голову профессионалам — «орать умеешь и знаешь как зайти в браузер, значит будешь у нас менеджером проектов».
Дело может принять еще более печальный оборот. «Дешевый» менеджмент с рынка, чувствующий свою профессиональную непригодность, слабо развитый головной мозг (контраст с мозгами специалистов) при сильных амбициях и ощущении иллюзии власти — начинает просто ненавидеть разработчиков и безумно троллить.
Что делать. Бороться с этими оборотнями-управленцами. Выставлять их дураками на PlanningPoker и демонстрациях функционала. Подключить адекватных IT-шников компании: техдира, рук. разработки — пока не поздно выстроить открытый и формальный бизнес-процесс в котором тупость и неопытность проектного/продуктового менеджмента будет видна руководству компании.
Хотя бы процессы станут менее эмоциональными, предсказуемыми, более независимыми от рыночных фраз «мне нужен запуск сайта через неделю», «я тебя уволю», «я найду студента за пятьсот баксов, который работает быстрее».
Если ничего не получится, не терять надежду и постараться найти компанию, в которой хочется работать долгие годы, совершенствуя свое мастерство и отдавая себя ей.
Всем Разработчикам искренне желаю удачи и энергии в самореализации.
