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