Мы работаем в странной индустрии. Потребность в разработчиках здесь значительно выше, чем кадровое предложение. Эта проблема существует многие годы, и со временем она становится острее.
Мы испытываем серьезную нехватку талантов, хотя индустрия довольно молода. Большинство софтверных проектов проваливаются, и практически все превышают бюджет. А лучшая идея, которую могут предложить сильнейшие умы, сводится к «Есть несколько стандартных способов решения подобных проблем, но наши решения часто не срабатывают. Единственное, что можно сделать — это попробовать и посмотреть на результат».
Реальность такова, что под «старшим разработчиком» понимается человек, который ваяет код более 3 лет. Его ставят на руководящую позицию, и обычно все заканчивается ожидаемо плачевно.
На самом деле, попытка оценивать людей временными интервалами – слишком упрощенный способ для таких тонких материй, как знание и профессиональный опыт. Но дела обстоят именно так. И если продолжать классифицировать специалистов подобным образом, то самое время нашей индустрии брать тайм-аут. Есть разница между человеком с 10-летним опытом, и тем, кто за то же время стал опытнее в 10 раз.
Постер из сериалa «Компьютерщики»
Этапы роста разработчика
Как программисты, мы живем в мире сложных систем и переменных. В этом мире даже простое выполнение хорошо поставленной конкретной задачи может вызывать затруднения. Особенно если нет огромного опыта с имеющимися инструментами или базой кода.
Кадр из сериалa «Компьютерщики»
Вот какова жизнь junior-разработчика. Закончив обучение, вы кажетесь себе всезнающим. Но внезапно приходит понимание, что школа слабо подготовила вас к тем проблемам, с которыми приходится сталкиваться. Реальность хаотична, не так приятна и далека от теории. Приходится крутиться в среде компромиссов, без возможности строить предположения о чем-либо.
Работа с учетом всего этого и будет вашим главным уроком и предметом сосредоточения. Младшим разработчикам требуются регулярные наставления, помощь и поддержка. В противном случае, они могут топтаться на месте очень и очень долго (недавно я столкнулся с товарищем, который делал софт почти 10 лет, но фактически остался все тем же начинающим разработчиком). Можно сказать, этот период целиком посвящен познанию тактических подходов к решению ежедневных задач.
Джуниор-разработчик зациклен на коде, а не на процессе разработки. Да и разницу он не особенно улавливает. Если программист говорит, что «с радостью кодил бы больше, если бы не эти пользователи» — с высокой вероятностью, вы общаетесь с новичком.
Хорошему junior-разработчику можно дать знакомую задачу и ожидать ее быстрого выполнения
Кадр из сериалa «Компьютерщики»
Разработчик среднего уровня уже начинает видеть в ошибках определенные закономерности (обычно, в собственных ошибках). Он понимает, что для написания работоспособного кода, который не развалится при первом же изменении, требуется много больше простого завершения своего участка работы. Еще он обычно проходит через тот уникальный опыт, когда смотришь на свою прошлую гордость (код годовалой давности) и понимаешь, что это полнейший хлам.
Такой человек изучает вопрос правильной разработки софта, и находит для себя ответы в экспериментах, литературе и обсуждениях с коллегами. На этом уровне все направлено на изучение теории разработки продукта, а не написания кода (этому учат в школе).
Написанные «средними» разработчиками самостоятельно системы проваливаются по совершенно иным причинам, чем творения молодых специалистов. Джуниор просто напишет гору условно-рабочих алгоритмов. А хороший «средний» частично воплотит содержимое книг “Design Patterns” и “Domain Driven Design”. Конечно, это прекрасные книги для изучения процесса разработки крупных систем. Но простое следование их постулатам приводит к построению излишне сложных систем, которые гибки там, где это не важно, и неповоротливы в значимых вещах.
“Среднему” программисту можно доверить разработку системы, которая проработает гораздо дольше творения молодого коллеги, но все равно приведет к непредсказуемым последствиям. Печально, но факт: абсолютное большинство не только старших разработчиков, но и тимлидов, являются обычными «средними» программистами. Многие из них этого не понимают и руководствуются лишь благими намерениями, но они просто никогда не работали с кем-то более квалифицированным.
«Мидлы» хорошо осознают свою роль в организации и ценность для нее. Хорошие middle-девелоперы также понимают, что кодинг для решения проблемы означает работу до логического завершения, а не просто до конца задачи. И все же они еще слишком увлечены постройкой башен из слоновой кости и поисками «Правильного Пути» в разработке софта.
Хороший «средний» разработчик требует меньше присмотра. Им можно доверять поиск проблемных участков проекта, и они играют важную роль в принятии ключевых решений. Еще они «рабочие лошадки» команды, но требуют более высокоуровневого наставничества.
Кадр из сериалa «Компьютерщики»
Старший разработчик близко знаком с собственными неудачами. Такие люди создавали как недоделанный, так и излишне сложный код – и видели плачевные результаты в обоих случаях. Они взвешенно подходят к работе, трезво и спокойно оценивая собственные удачи и поражения при возникновении проблем. Старший разработчик уже разлюбил сложность, которая захватывает умы «средних» коллег, и теперь одержим простотой.
Старший разработчик не классифицирует коллег по уровню их знаний, он понимает, что у всех есть сильные и слабые стороны. Он знает о своих преимуществах и недостатках больше кого бы то ни было и стремится по возможности использовать именно преимущества.
Senior учитывает контекст при применении теории. Он понимает, что не существует «Правильного Пути». Единственный способ построить хороший продукт – это адаптация теории к требованиям клиента, базы кода, команды, инструментов и организации. Такой человек понимает, что все вокруг нас требует компромиссов, и будет искать их для паттернов проектирования, библиотек, фреймворков и процессов.
Старшие разработчики думают не только о себе. Они прекрасно знают, как работает их компания и организация заказчика, какие у них ценности и что важно или не важно для успеха. Если мяч брошен, то старший программист сделает все возможное, чтобы его поймать. Вы никогда не услышите от него фразы «это не мое дело» в подобных ситуациях.
Сеньор девелопер понимает, что работа заключается в решении проблем, а не в написании кода. Именно поэтому он всегда будет смотреть на работу с позиции соотношения ее ценности для организации затраченным усилиям.
В то время как «средний» разработчик погрязнет в бесчисленных днях монотонной деятельности, «старший» сперва поинтересуется первопричинами ситуации. Он оценит затраты на нейтрализацию причины, и либо сразу ее исправит, либо направит процесс в нужное русло.
Еще он понимает, что нельзя сделать все самостоятельно. Его первоочередная роль – помочь команде стать лучше, часто теми же способами, какими самосовершенствуются отдельные участники. Ведь сила не во власти, а в делегировании. Не в управлении, а в поддержке.
Если у вас нет ни одного старшего разработчика на руководящих позициях, то проект обречен. Команда отличных «середнячков» может завести вас довольно далеко, но дни продукта все равно сочтены. И в финале вас ждет либо сворачивание лавочки, либо рискованные и дорогостоящие переделки. Единственный, кто способен выбрать правильную технологию и платформу – это старший разработчик. Поэтому его отсутствие в проекте с первых дней серьезно вам повредит.
Это просто гигантское упрощение
Реальность такова, что никто не подходит под описанные рамки в точности. Я уже устал смотреть, как программистов оценивают по «годам опыта». Безусловно, они что-то могут вам рассказать, но это практически бесполезная информация вне остального контекста.
Более того, в нашей индустрии принято ценить дерзких умных молодых ребят после университета. Эти парни действительно ценны и необходимы, но не более, чем их коллеги с 15-20 годами «полевого» опыта. Пора переставать стереотипно нанимать людей и начать больше думать о команде и сочетаемости талантов. Если все в команде будут думать одинаково – вы окажете медвежью услугу и проекту, и организации.
Переведено в Alconost Translations
Комментарии (99)
Dima_Sharihin
17.07.2015 11:56+29Хуже, когда учиться и набираться опыта попросту не у кого. То есть приходишь в организацию, и видишь тех же студентов, с которыми учился, и при этом я сам еще мог им что-то рассказать.
DnV
17.07.2015 15:48+5Наверно надо быть совсем экстравертом, чтобы «не у кого» было учиться в эпоху интернета, гитхаба и стековерфлоу.
Dima_Sharihin
17.07.2015 16:06+2Нет, ну если считать за обучение стековерфлоу и полезные статьи на хабре, то так учатся все.
Вот только я не сказал бы, что это так же эффективно, как иметь «семпая», который бы вовремя вправлял мозги в правильном направлении.DnV
17.07.2015 16:14+2Я имею ввиду статьи специалистов и исходники рабочих проектов. Тратить на каждого ленивого джуниора время опытного разработчика — вот это точно не эффективно.
edwardspec
17.07.2015 20:35+5> Тратить на каждого ленивого джуниора время опытного разработчика — вот это точно не эффективно.
Это смотря как тратить.
Стоять за их спиной и смотреть, что они пишут (в режиме реального времени) — неэффективно.
А выделить 30 минут в день на «полистать коммиты новичков», по замеченной кривизне и костылям отправляя им email «вот тут сделал криво, попробуй по-другому, например так» — вполне эффективно.
Flammar
17.07.2015 21:25Мне на первом проекте по методологии «scrum» «повезло» встретить «семпая» в виде scrum-мастера, который в критический для меня момент немного «вправил» мозги в неправильном направлении — чисто из желания возразить…
booomerang
17.07.2015 16:35Учиться нужно не только у кого-то, а и самому! набивая шишки, делая всё методом проб и ошибок и чаще 2-ое заводит нас намного дальше, чем просто учение у кого-либо.
Dima_Sharihin
17.07.2015 16:42+1Последние пару лет только «а и самому» и происходит…
И иногда понимаешь, что далеко не все системные/архитектурные решения, принятые в проекте, были правильными
Flammar
17.07.2015 21:20Учиться у кого-то можно только если разница уровней превышает определённую величину. Можно ещё учиться самому, используя кого-то в качестве наиболее частого учебного пособия, но это несколько другое, даже результат может быть противоположный. Но это надо хорошо уметь учиться самому.
booomerang
17.07.2015 16:59+2Гороздо хуже, когда приходишь в организацию, и видишь вроде умных ребят и постарше лет на 5-10 и при этом сам еще можешь им что-то рассказать…
Mrrl
17.07.2015 20:33+8Ага. Ты им рассказываешь, они вроде бы слушают, а делают всё равно по старинке. Ты говоришь, что «так пишет всё прогрессивное человечество», а завтра обнаруживаешь, что «прогрессивное человечество» стало новым ругательным термином :)
T-D-K
17.07.2015 22:26Одногруппник работал 1.5 года в одной фирме в отделе программистов, которые писали и обслуживали какие-то внутренние программы. Где-то через месяц работы у него случилось полное помешательство, т.к. тамошний тимлид утверждал что все паттерны и гибкие методологии зло и они только замедляют процесс разработки. На аргументы о техническом долге отмахивался. Системы контроля версий там не было. Тестирование всего проводили самым наивным методом: запускали и тыкали кнопки. На первые юнит-тесты, написанные одногруппником смотрели как на волшебство. ТЗ ни на одну задачу никогда не было. О Continuous Integration слышали что-то мельком. И чуть ли не главным принципом фирмы было то, что один человек отвечает за одну задачу и если он увольняется, то код проще переписать, т.к. он без тестов, комментариев, истории изменений и т.д. Зато у тимлида была гордая надпись в трудовой «Технический директор» и ещё у двоих была надпись «Ведущий программист», которыми они очень гордились.
Flammar
17.07.2015 23:43И чуть ли не главным принципом фирмы было то, что один человек отвечает за одну задачу и если он увольняется, то код проще переписать
Довольно частый паттерн организации разработки ПО.Flammar
18.07.2015 00:02+1Довольно частый паттерн организации разработки ПО.
В основном «в отделе программистов» в какой-нибудь фирме, для которой разработка ПО не является профильным занятием. Откуда и зачем там «тимлид» если команды фактически нет, только, непонятно…
monah_tuk
19.07.2015 18:22У меня вот тоже запись: ведущий. Что только значит — понять не могу: кого и куда веду? :)
kaichou
20.07.2015 11:24+4> Системы контроля версий там не было. Тестирование всего проводили самым наивным методом: запускали и тыкали кнопки. На первые юнит-тесты, написанные одногруппником смотрели как на волшебство. ТЗ ни на одну задачу никогда не было. О Continuous Integration слышали что-то мельком.
Вот вы перечисляете всё это как что-то, без чего нельзя создать нормальный продукт.
А ведь именно таким образом был создан варкрафт. И еретик. И дум. И первые версии винды.
Вот лохи те ребята, наверное, были, да? Никудышные программисты, поди, да?T-D-K
20.07.2015 11:33Вы либо очень жирный тролль, либо…
В 2015 году работать и писать код как в 1985 (первые версии винды), или даже как в 1993 (DOOM) будут только морально и технически отсталые идиоты, которых надо гнать из профессии на мороз палками.
corvette
20.07.2015 11:43+1Что-то мне подсказывает, что методы написания Windows и Doom были довольно продвинутыми. Иначе, почему они получили оглушительный успех? А если успех не зависит от методов работы, то может и идиотов не надо гнать из профессии.
gandjustas
20.07.2015 17:09-7Windows 1.0 был унылым тормозным отстоем, которому далеко до МакОси (прошло 30 лет и ничего не изменилось :) ). Это несмотря на 24 программиста и 110 000 человеко-часов работы (или 55-человеко-лет). Кстати к релизу Windows 1.01 большая часть системы была не протестирована.
Что касается Doom, то им занимался крутейший программист всех времен и народов. Очень сомневаюсь, что ему понадобилось писать юнит-тесты.
solver
21.07.2015 18:53+2Если дальше продолжать вашу логику, то машины и самлеты нахрен надо убрать. Раньше на лошадях ездили и через океан месяц на корабле плыли.
А что, популярностью же корабли пользовались? Пользовались.
Люди попадали в конечную точку своего пути? Попадали.
Значит эти подходы идеальны. Значит все ОК с тами подходами.
Flammar
27.07.2015 16:00Думаю, тут разница не только между 1985 и 2015, но и между а) оффшорным программированием либо разработкой системы для конкретного заказчика б) разработкой «коробочного» софта и в) разработкой системного и embedded софта. Между 1985 и 2005 много поменялось в части (а), меньше — в части (б) и ещё меньше — в части (в). В сфере «отделов программистов, которые пишут и обслуживают внутренние программы» поменялось ещё меньше.
inborn_killer
21.07.2015 12:27Может быть, всё же причина была в том, что тогда не было тех инструментов, что есть сейчас? На нынешнем рынке ПО совершенно другие требования, чем были в то время, поэтому и подходы 20-30 летней давности сейчас уже не работают.
Хотя, инструменты, конечно, должны оставаться инструментами, а не становиться самоцелью.
Flammar
21.07.2015 23:02Грубо говоря, тогда «не было интернета». Т.е. теоретически он в каком-то виде был, но сетевые технологии, на которых сегодня построены все перечисленные вами «фишки», использовались мало или вообще никак. Тем более, что для того, чтоб разрабатывать «в одно лицо», все эти вещи не критичны.
saboteur_kiev
23.07.2015 17:50+2С чего это вы взяли, что у тех ребят не было нормального ТЗ и организации работы?
Насколько я читал интервью сотрудников ID-software, там наоборот говорят что успех маленькой компании во многом получился благодаря тому, что каждый точно знал что ему делать, и организовано все было с запасом. IDSoft всегда славилась именно тем, что эти ребята кладут свою лыжню, и мгновенно осваивают все самое новое.
В то время, как в вышеуказанной компании, даже не пытаются освоить уже проверенные и рабочие методы, признанные в мире удобными инструментами.
Пусть не нужно пользоваться тестами, системами контроля версий, билд серверами, но тогда покажите ваше собственное рабочее решение, которое будет лучше этого?
Flammar
27.07.2015 14:53Вы мешаете в одну кучу «традиционное» ТЗ и «гибкие» систему контроля версий и сервер сборки. Хотя тогда «не было интернета» и, соответственно, не было серверов сборки и сетевых репозиториев, но ТЗ как «инструмент управления разработкой» уже давно существовало и использовалось.
Flammar
27.07.2015 01:55Ваш одногруппник надеялся найти в Калуге scrum-команду или оффшорных разработчиков ПО?
T-D-K
27.07.2015 08:20У нас в Калуге достаточно хороших фирм (DevExpress, CorePartners, ...). Вообще-то мой комментарий был про другое. Про то, что люди величают себя тимлидами и ведущими разработчиками, в то время когда они им не являются по сути в общем виде. Самый долго работающий программист != самый опытный. Собственно об этом я и писал.
petrovichtim
17.07.2015 13:18+7Потребность в разработчиках здесь значительно выше, чем кадровое предложение. Эта проблема существует многие годы, и со временем она становится острее.
Я как программист никакой проблемы в этом не вижу. Классики тему спроса и предложения на рынке труда раскрыли полностью.Постоянная промышленная резервная армия, как называл её Энгельс, позволяет капиталу всегда располагать доступным для эксплуатации человеческим материалом независимо от границ естественного прироста населения. Без этого капитализм не мог бы существовать, ибо потребности самовозрастания капитала подвержены большим изменениям. Конвульсивное и скачкообразное расширение производства в период подъёма (столь же характерное для капиталистического машинного производства, как и конвульсивное сокращение производства в периоды кризиса) непременно предполагает существование промышленной резервной армии, всегда готовой к услугам капитала. Из армии безработных капитал, в случае нужды, черпает добавочную рабочую силу, и в эту же армию он выбрасывает пролетариев, как только они становятся излишними. Следовательно, безработица порождается не извечным законом природы, как это изображают буржуазные идеологи, а общественными условиями определённой исторической формации; она порождается капитализмом, капиталистическими производственными отношениями.
Дальнейшее распространение в капиталистических странах процесса механизации и автоматизации производства создает серьёзную угрозу ещё большего увеличения масштабов массовой безработицы. Вместе с тем усиливается борьба рабочего класса за сокращение продолжительности рабочего дня без сокращения заработной платы, за снижение пенсионного возраста, за увеличение пособий по безработице и выплату их в течение всего периода безработицы, за использование государственных средств не на производство всё более разрушительных видов вооружения, а на стимулирование экономического роста, строительство школ, больниц, жилых домов. Если бы трудящимся удалось добиться осуществления подобных мер, это могло бы уменьшить масштабы безработицы и смягчить её тяжелые последствия. Однако никакие меры не могут полностью ликвидировать безработицу при капитализме. Окончательно избавиться от неё можно лишь путём уничтожения самого капитализма.
dyadyaSerezha
17.07.2015 15:34+3«Дальнейшее распространение в капиталистических странах процесса механизации и автоматизации производства создает серьёзную угрозу ещё большего увеличения масштабов массовой безработицы»
— лет 200 как всё механизируется и автоматизируется, но роста процента безработицы не наблюдается, а наблюдается переход рабочей силы в новые рынки труда, которые создаются этими самыми механизацией, автоматизацией, компьютеризацией. Вывод: утверждение ложное.
«Вместе с тем усиливается борьба рабочего класса за сокращение продолжительности рабочего дня без сокращения заработной платы, за снижение пенсионного возраста, за увеличение пособий по безработице и выплату их в течение всего периода безработицы, за использование государственных средств не на производство всё более разрушительных видов вооружения, а на стимулирование экономического роста, строительство школ, больниц, жилых домов»
— дадада, вся Россия «в демонстрациях и стачках» потому что: рабочий день не сокращают, пенсионный возраст не сокращают, а увеличивают (!), пособия не только не увеличивают, но и не платят вообще (!), военный бюджет не сокращается, а увеличивается (!), бюджет на образование, медицину и прочее не увеличивается, а резко сокращается (!). Так где же стачки и демонстрации? Наоборот, рейтинг 89% — за последние 50 лет выше был только у Брежнева.
Вывод: то ли все, написанное в посте выше, полная лажа, то ли Россия не подчиняется этим законам.petrovichtim
17.07.2015 15:46-1— лет 200 как всё механизируется и автоматизируется, но роста процента безработицы не наблюдается, а наблюдается переход рабочей силы в новые рынки труда, которые создаются этими самыми механизацией, автоматизацией, компьютеризацией. Вывод: утверждение ложное.
Мы видимо на разных планетах живем.
— дадада, вся Россия «в демонстрациях и стачках» потому что: рабочий день не сокращают, пенсионный возраст не сокращают, а увеличивают (!), пособия не только не увеличивают, но и не платят вообще (!), военный бюджет не сокращается, а увеличивается (!), бюджет на образование, медицину и прочее не увеличивается, а резко сокращается (!). Так где же стачки и демонстрации? Наоборот, рейтинг 89% — за последние 50 лет выше был только у Брежнева.
Если вы не следите за борьбой рабочего класса, это не значит что её нет. Итальянская забастовка медиков, 5 открытых забастовок на Форде, забастовки авиадиспетчеров, забастовки докеров… я могу очень долго этот список продолжать вплоть до того как на тачке выкатили директора Выборгского ЦБК. Вы что хотите доказать? Собственную безграмотность?
Вывод: то ли все, написанное в посте выше, полная лажа, то ли Россия не подчиняется этим законам.dyadyaSerezha
17.07.2015 23:15+6Свою безграмотность показываете вы, потому что не надо перечислять отдельные случаи, а надо привести статистику по кол-ву бастующих в мире и России по годам и показать ее рост за 100-150 лет. А рейтинг в 89% — это какая-никакая статистика.
Viacheslav01
17.07.2015 13:41+34Я не хочу уходить из разработки в управление, мне нравится моя работа и мое дело. К сожалению расти в таком случае очень трудно, уже начали задавать вопросы, вам столько лет и вы не «менеджер», а почему так, вы наверное очень плохой разработчик, раз не выбились в управленцы. Ответ «не хочу», до 99% оппонентов не доходит :)
AlexBin
17.07.2015 14:04+29Успех! Заработок! Власть! Ссаные ценности, продиктованные современным миром. Конечно до них не дойдет.
perfectdaemon
17.07.2015 14:06+19Такие доводы часто не доходят даже до близких людей, что куда плачевнее
Viacheslav01
17.07.2015 17:35+1Это точно, бывшая жена регулярно пилила на тему, «становись начальником» :)
monah_tuk
17.07.2015 18:02+8бывшая
Всё правильно сделал! Человек должен заниматься своим делом, тогда и получаться у него это будет лучше. И на человеческие отношения будет больше сил, времени и желания. А погоня за мнимым статусами: стресс, бутылка, скандалы и дальше по кругу.evans2094
23.07.2015 16:24С этой точки зрения мне у военных подход нравится.
Х***ый майор может получать меньше чем п***ый капитан или ох***ый прапор. Причем в случае конфликта такого прапора с майором — у майора есть большой риск замененным. Ибо толкового спеца на любом уровне искать проблематично от низшего до высшего, например наблюдал принципиально незаменимых тестеров, а бестолковый сотрудник даже высшего звена — это просто расходник, который выпнут при первом же сокращении или обнаружении более достойного кандидата.
Наблюдал несколько подполов уходивших с полковничьих должностей на майорские не только из соображений снижения ответственности, но и с точки зрения повышения добычи денюжков на карман. Да и комотд (сержант) при налиции хорошей классности может обходить свежевыпущенного лейтенанта, что вдвойне для последнего обидно.
Другое дело что зачастую сотрудников двигают вверх до достижения ими уровня полной некомпетентности, а назад двигать это уже считается некомильфо. Хотя тут сказывается тот факт что высшая ступенька гарантированно дает повышенную оплату, то есть мегаклассный программист (имея максимум по программистской зарплатной вилке) переходя в тим лиды обычно имеет в тим лидах больше чем в программистах. И обычно минимум вилки тим лида (а тем более РП) больше максимума вилки программиста. В результате имеем погоню за деньгами и некомпетентного РП или лида вместо отличного и полностью компетентного программиста. В очень редких компания сталкивался с тем что компетентный специалист мог обойти своего шефа по зарплате (это не значит что шеф некомпетентный, а скорее то что замена такого сотрудника компании не может обойтись любым кандидатом и потребуется вместо заполнения одной вакансии открывать еще две-три).
Flammar
17.07.2015 23:48+1Года через 3-5 вам перестанут задавать такие вопросы. Люди, их задающие, просто самоотфильтруются на дальних подступах к вашему кругу профессионального общения.
corvette
17.07.2015 14:23+1Сильные разработчики имеют очень большое влияние на коллектив. Да они могут не заниматься административной рутиной, но разработкой они управляют, и в некотором смысле являются менеджерами. Много сильных разработчиков вместе могут порвать команду в клочья и надо искать баланс между лидерами сильными программистами и ведомым молодыми дарованиями. С опытом лидерские навыки редко развиваются, они либо есть, либо их нет, возможно, поэтому способность стать сильным разработчиком не зависит от лет опыта.
dyadyaSerezha
17.07.2015 15:45+6«Много сильных разработчиков вместе могут порвать команду в клочья» — мне кажется, это может быть только при плохом/слабом менеджере. У меня была обратная проблема — меня, как опытного сеньерного программиста, в одной фирме в конце первого года работы побранили: «что же ты влияешь на проект, не учишь молодежь, не выступаешь с инициативами?»
А у меня:
1. Своей работы выше крыши и на полгода вперед и все «надо вчера».
2. Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди». А что будет, если я подойду к колеге и скажу: «я тут посмотрел твой кусок и, честно говоря, хреново он написан (или более мягкий вариант „его можно написать лучше“)? А будет то, что джуниор меня, может быть, и послушает, хотя не факт, а уже середнячок просто пошлет подальше — и правильно сделает, потому что мне никто не делегировал таких полномочий, а для него я такой же коллега. Да и не было времени смотреть код других, потому что см. пункт 1.
То есть, для меня часто ситуация выглядит так. В конце года:
— почему ты грядку не копал?
— а вы мне сказали ее копать? а вы лопату мне дали?
— нет, не сказали и не дали, но почему ты ее не копал??
KReal
17.07.2015 16:09+1Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди». А что будет, если я подойду к колеге и скажу: «я тут посмотрел твой кусок и, честно говоря, хреново он написан (или более мягкий вариант „его можно написать лучше“)? А будет то, что джуниор меня, может быть, и послушает, хотя не факт, а уже середнячок просто пошлет подальше — и правильно сделает, потому что мне никто не делегировал таких полномочий, а для него я такой же коллега. Да и не было времени смотреть код других, потому что см. пункт 1.
Отчасти для этого скрамы и прочие аджайлы нужны. В аджайл-команде это норма вещей.corvette
17.07.2015 16:45+3Их еще надо уметь правильно готовить. Я только сомнительного качества аджайлы пробовал.
monah_tuk
17.07.2015 18:40Я малость пытался, как стало почти до конфликтов доходить (момент вашего высказывания «просто пошлёт подальше») — забил. Сейчас процентов 20% времени у меня уходит на разного рода консультации (в т.ч. и на смежных проектах) — я своими знаниями помогаю коллегам, могу указать на ошибки, если увижу, но дальнейшая судьба оных мне не интересна: хотите повторно наступать на грабли — пожалуйста, лоб ваш, а не мой. Но на своём проекте, в своей компоненте в хвост и гриву за косяки, без купюр, хотя, формально, я не лид (просто разработчик, хоть и имею запись — ведущий /я даже не понимаю до конца что это значит — кого веду, куда веду? никто не объяснил/), но так бывает, что какую-то законченную функционально часть выходит разрабатывать самому, с архитектуры, до реализации (хотя бы изначальной) — тут работает «право первой ночи» (речь идёт о том, когда проект/компонент передают другому или расширяют первоначальную команду). При этом я просто в восторге когда кто-то находит ошибки, предлагает красивые решения или чётко обосновывает какое-то решение с которым я /ошибочно/ не согласен! Особенно в архитектурном плане.
ЗЫ я не сеньор :)dyadyaSerezha
21.07.2015 15:03Все это замечательно, но в жестокой реальности эти 20% времени должен кто-то оплачивать. Если вы просто крадете их у своего проекта, то оплачивает «владелец» проекта и это не есть хорошо. Опять же, не очень понимаю «хвост и гриву» и «20%», если «до конфликтов доходило» и «забил».
TheShock
19.07.2015 20:06+3Мне никто не поручал все это делать. Не писал даже письмо всем в группе, что «прислушивайтесь к замечаниям и идеям дяди».
Это просто означает, что вы не лид. Лидер берет, делает, потому что это его трогает и к нему в итоге прислушиваются. Ну вот скажут «прислушивайтесь к замечаниям и идеям дяди» мидлам, а они как не считали вас достойным давать советы — так и будут считать. И будут саботировать. Вы, конечно, скажете опять, что «ну и все-равно, это их проблемы, что не слушают советы опытного дяди», но опять же это от того, что вы не лид в душе.dyadyaSerezha
21.07.2015 16:59Это просто означает, что я люблю порядок, не люблю анархии, привык подчиняться правилам и соблюдать законы. И кроме того, я не хочу тратить свое личное свободное время и оставаться сверхурочно, чтобы смотреть по сторонам, проверять качество кода и решений других, а уж тем более переделывать что-то. Тот же самый начальник, которой побранил меня в конце года, в течение самого года постоянно наседал только с одним требованием: «это важный клиент, он ждет, почему так медленно??»
TheShock
22.07.2015 14:49Ну я и говорю, что вы не лид. Оправдываться не нужно, это не плохо.
dyadyaSerezha
23.07.2015 12:29К лиду или не лиду это не имеет отношения.
1. Я долго работал и работаю в большом корпоративном секторе.
2. Я долго работаю вообще, поэтому давно уже не «скиф, с раскосыми и жадными очами».
И таки да, это не плохо.TheShock
23.07.2015 13:31К лиду или не лиду это не имеет отношения.
Ну если вам так легче думать, то не буду настаивать.
Flammar
21.07.2015 22:47я тут посмотрел твой кусок и, честно говоря, хреново он написан
Тут нужны формализованные критерии качества кода и процедуры code review (не говоря уже о том, что с точки зрения «дефолтной» (хотя и обычно неправильной) прошитой в мозгах разработчика парадигмы «каждый отвечает за свой собственный код» право таких претензий на существование вообще сомнительно). И говорить лучше не абстрактно «твой код хреново написан», и тем более не «честно говоря» и не «можно написать лучше» — такие ослабленные варианты скорее воспримутся как придирки к несерьёзным мелочам — а конкретно «твой код написан так, что он мешает делать то-то».
Я вот лично, что такое «качество кода», зачем оно нужно, и как его обеспечивать парой нажатий на клавиши, понял только через десять лет после написания своей первой программы на Java — никто никогда не объяснял, только на последнем месте молча слегка подталкивали, и то, зачем это надо, я понял только после того, как ушёл оттуда.dyadyaSerezha
22.07.2015 02:42Какие нужны критерии и какая лучше парадигма — это не к сеньерному программисту, а к начальнику проекта. Если вы работали в больших фирмах, т должны знать, что изменить как правило ничего нельзя. В лучшем случае тебе назовут десяток важных ппичин, почему не надо ничего менять. В худшем просто скажут — нет.
И то, что лучше сказать коллеге, тоже не важно, потому что прежде, чем что-то сказать, надо проанализировать его код, а на это нет времени (скорость и корректность алгоритма или правильность иерархии классов не оценят никакие автопроверялки).Flammar
22.07.2015 04:07не к сеньерному программисту, а к начальнику проекта
Я это и подразумевал, говоря про формализованные критерии и процедуры. Конечно, они должны исходить от начальства и, лучше бы, быть частью внутрифирменного стандарта.
TheShock
22.07.2015 14:50Если вы работали в больших фирмах, т должны знать, что изменить как правило ничего нельзя.
Я работал. Было бы желание.
vit1251
17.07.2015 14:55+2Мне вот очень понравилась табличка из статьи «More Than Coding» в одном блоге:
(https://habrastorage.org/files/1c0/293/d3a/1c0293d3a3674655a7bfd609ff10e2e5.JPG)
Которая оценивает не собственно годы, а степень влияния и ответственности это куда важнее.
booomerang
17.07.2015 16:49+5На самом деле, попытка оценивать людей временными интервалами – слишком упрощенный способ для таких тонких материй, как знание и профессиональный опыт.
Это правда, но и крутым разработчиком не стать за 2 недели. Для того, чтобы стать кем-то очень успешным нужно потратить тонну времени, перечитать кучу книг, поняв, что там написано и применив это в деле, а также самому изобретать и строить. Старое, доброе правило 10 000 часов.
И в корне не согласен с этим вот обзацем:
Если у вас нет ни одного старшего разработчика на руководящих позициях, то проект обречен. Команда отличных «середнячков» может завести вас довольно далеко, но дни продукта все равно сочтены. И в финале вас ждет либо сворачивание лавочки, либо рискованные и дорогостоящие переделки. Единственный, кто способен выбрать правильную технологию и платформу – это старший разработчик. Поэтому его отсутствие в проекте с первых дней серьезно вам повредит.
Если нет старшего разработчика, проект еще не обречен. Важно, чтобы кто-то из членов команды стремился им стать!
strannik_k
17.07.2015 19:42+1Печально, но факт: абсолютное большинство не только старших разработчиков, но и тимлидов, являются обычными «средними» программистами.
То же самое можно сказать и про большинство компаний, менеджеров и т.д. Большинство компаний не выше среднего уровня и с такими же проектами. Откуда в них будут толпы крутых программистов?
Это конечно интересно беседовать на тему идеальных сеньоров, но кто бы взялся за решение проблемы? Откуда появятся крутые разработчики, если все их обучение пущено на самотек?
Институты плохо учат? Ну, так почему бы компаниям не замутить свой университет? То, на что в институтах тратиться 5 лет, можно за год научить при правильном подходе. Стажировки тому подтверждение.
Есть в некоторых компаниях короткое обучение на джуниора — «стажировка», так почему бы не пойти дальше и не ввести «дообучение на сеньора»?
Еще становлению истинными сеньорами мешает то факт, что и пожить хочется, а не угробить всю жизнь на развитие ради того, чтобы другие больше зарабатывали. Все хотят, чтобы сотрудник и работать и учиться успевал, а вот выделить время и деньги на это – далеко не каждый захочет.
0xd34df00d
17.07.2015 20:15+1угробить всю жизнь на развитие
Даже ухо как-то режет. Какая разница, ради чего?
Flammar
17.07.2015 20:38+1«дообучение на сеньора»
А всякая ли компания это сможет и всякой ли компании это нужно?strannik_k
17.07.2015 21:14+1А всякая ли компания это сможет и всякой ли компании это нужно?
Если не может или не нужно – то ок)
Если же может и ей постоянно не хватает разработчиков, но она ничего для этого не делает, то такой компании не стоит жаловаться на недостаток опытных разработчиков.
gandjustas
17.07.2015 20:41+1Начало статьи вроде об одном, а сама статья вовсе о другом.
Реальность такова, что под «старшим разработчиком» понимается человек, который ваяет код более 3 лет. Его ставят на руководящую позицию, и обычно все заканчивается ожидаемо плачевно.
Реальность такова, что руководителем группы\отдела становится тупо тот, кто дольше проработал. Особенно интересно бывает наблюдать картину, когда руководителем становится человек, проработавший 10 лет на одном месте, совершенно не знающий людей, рынка, технологий и вообще не видевший ничего за пределами организации.
Но основная идея статьи о другом — «не надо оценивать разработчиков по годам опыта». Как ни странно я очень редко встречался с ситуацией когда программистов оценивали по годам опыта. Все прекрасно понимают, что годов может быть много, в релевантного опыта мало.
Если посмотреть на форумах обсуждения собеседований программистов, то я не видел претензий чтобы кого-либо отфильтровали по количеству лет.
ИМХО статья скорее для HR, которые обычно не понимают специфики инженерной и творческой работы.Flammar
17.07.2015 21:32Если посмотреть на форумах обсуждения собеседований программистов, то я не видел претензий чтобы кого-либо отфильтровали по количеству лет.
Если такой фильтр и где-то и есть, он срабатывает до приглашения на собеседование…
justaguest
18.07.2015 00:21+3«Одни с годами умнеют, другие становятся старше» — ©, из подписи одного из модераторов форума «Исходники».
stranger777
18.07.2015 10:00+2Пост полезный, спасибо; замечу только, что Страуструп сказал об этом уже давно, написав, что «кодировщик» — кодирует в рамках поставленной задачи с поставленными условиями, а «программист» — решает проблему.
И, кстати, это уместно в абсолютно любой профессии. Хороший средний специалист работает в каких-то условиях и рамках, высокого уровня специалист — либо сам создаёт себе условия, либо решает проблему «с центра поля», либо то и другое.
andreycha
18.07.2015 14:00А кто-то говорит, что программист — кодирует, а вот разработчик или инженер — ого-го!
FireStorm
18.07.2015 22:48Возникает ощущение, что у Старшего Разработчика вообще нет недостатков. Зрит в корень, трезво оценивает, решает проблемы, ищет оптимальное решение… Просто идеал какой-то.
eaa
18.07.2015 23:09Это не описание реального разработчика, это больше описание того, каким он должен быть и какие задачи должен решать.
FireStorm
21.07.2015 16:00Я немножко о другом. Если это вполне достижимый этап, то что будет дальше? Если не указан ни один недостаток или слабая сторона, то значит ли, что нет дальнейших перспектив развития, кроме вширь (другие технологии, области и т. п.)?
Neonion
19.07.2015 23:17+1Хорошая статья, которая реально отображает положение вещей. Как по мне, так проблема роста еще часто заключается в отсутствии возможности у кого-то учиться.
Не всегда рядом будет «правильный» более старший разработчик, который сможет указать на твои недочёты или помочь с дальнейшим ростом. Это же касается и менеджмента, который в большинстве случаев страдает на нехватку технической подкованности и это мешает строить правильные команды и делать правильные выборы в пользу того или другого программиста.
rsi
20.07.2015 06:56Описаний уровней разработчиков очень много. Но прочитав эту статью и немного поразмыслив я бы сказал, так:
Джуниор — человек без опыта и понимания реального положения вещей. Он либо вообще не знает о том как можно разрабатывать, либо видит всего один правильный путь.
Мидл — человек который знает за чем все это происходит, знает в чем причина. Он знает, что важен факт решения проблемы, а не код. Он знает о проблеме поддержки проекта/ кода и знает как это упростить при проектировании и разработке. Он знает многие различные методики для различных стадий проекта (он знает что этих стадий много). Знает, что нет серебренной пули, и нужно выбирать инструмент/методику для каждого проекта в отдельности.
Сеньер — человек который знает все, что знает мидл, но у него есть опыт и он знает как все это применять. Человек который прочитав ТЗ может четко сказать, что и по какой причине лучше использовать. Какие подводные камни будут в этом проекте и скорее всего, он даже назовет точные сроки разработки проекта, потому что он «видит» весь жизненный цикл будущего проекта.
AMDev
28.07.2015 08:14+2Прочитав ваш комментарий вспомнилась
матрица компетентности программиста [EN] [RU]
engine9
20.07.2015 13:40В любой работе, связанной с решением практических задач и работы с клиентами помогает социализация и знание человеческой психологии.
kluwert
21.07.2015 21:58Статья — ниочём, вода водная. Это настолько всё индивидулаьно, что тут правил и шаблонов не подогнать. Писать такие статьи — пустая трата времени, читать — пустая в квадрате.
jia3ep
Моя теория нехватки хороших старших разработчиков — их не слишком много, так как я много раз видел, как люди из хороших разработчиков превращались в плохих менеджеров из-за желания увеличить влияние, зарплату или по еще каким-то причинам. Очень рад за компании, где у старших разработчиков нет, по крайней мере, финансовых причин делать такой, часто неудачный, вираж в карьере.
Еще с сожалением отмечу. что «дерзких умных» молодых ребят все меньше. Из университетов все чаще стали приходить просто «дерзкие».
Это все личная практика, не хочу никого обидеть.
SamKrew
Проблема скорее в том, что умные постоянно участвую в разного рода олимпиадах. Задачи из реального мира и некоторые приемы при их решении ставят выпускников в тупик. А те, кто может их решить быстро — скорее всего уже имеют неплохую работу.
dunmaksim
В одной книжке по менеджменту автор рассказывал, что многие его подчинённые зарабатывали гораздо больше него. Почему он платил им так много? Во-первых, чтобы они не пытались занять его место, а во-вторых, чтобы удержать их в фирме. К сожалению, в России только высокая должность может гарантировать высокий доход, профессиональные навыки часто уходят на второй план.
eaa
К сожалению, во многих компаниях рост возможен только из разработки в менеджмент, типа разработчик -> старший разработчик -> ведущий разработчик aka руководитель группы/отдела.
Если человек — прирожденный разработчик и в менеджменте ему делать нечего — то и вырасти он не сможет. А расти на позиции разработчика зарплата не позволяет, такие уж рамки заданы свыше. Вот и получается, что человек ради роста вынужден заниматься не своим делом, хотя вот решение-то на поверхности: плати больше и пусть человек делает то дело, которое он умеет делать, и все будет хорошо.
jia3ep
Кстати, в подтверждение пример с небезызвестным Марком Руссиновичем, который долгое время был в Майкрософте на должности Technical Fellow и только через 9 лет (в сентябре прошлого года) сменил должность на CTO. Что-то мне подсказывает, что все это время дело у него было интересное и платили ему не мало.
questor
Дело не только в конкретных компаниях и дело не только в конкретной профессии. Недавно проскальзывала статейка, в которой автор говорил (в том числе и) о том, что с развалом СССР был поломан и институт специалистов.
Поэтому «у них там» с сеньорами плохо, а «у нас тут» (в Росиии) ещё хуже, есть дополнительные факторы.
andreycha
«разработчик -> старший разработчик -> ведущий разработчик» — это классический рост (вертикальный). А вот из программиста в менеджера — это горизонтальное перемещение, потому как технический трек и менеджерский трек — это отдельные вещи, и нельзя сказать, что один находится ниже другого.
Fedcomp
Так может искать не в университетах?
Viacheslav01
Из личной практики, «дерзкие умные» без университета часто доходят до предела который ниже чем у тех кто имеет профильное ВО.
Ну да университет университету рознь, да что говорить смежные кафедры одного университета друг другу рознь!
monah_tuk
истину глаголите!
strannik_k
Скорее всего, такие же, какие и были. Просто с возрастом многие бывшие студенты все больше отдаляются от нынешних и смотрят на них свысока. Они подрастут, будут тоже самое говорить о следующем поколении. Поколение, предшествующее вам, также утверждает, что их поколение было лучше.
У многих родители говорили подобное «вот в мои времена все были такими-то ..., не то что в нынешние». Сейчас их выросшие дети тоже самое говорят своим детям. Если подобные утверждения были бы правдой, то самыми идеальными людьми были первобытные)
monah_tuk
Может и так, но только частично. Когда человек не может даже сказать что он делал, но при этом «крутой» программист. У меня к концу первого семестра была (а я инженер-электрик) хорошо продуманная платформа на VB для наших курсовых, в результате курсовики штамповались… Быстро. Да, приходлось время от времени делать какие-то мутации, что бы совсем уж преподов не раздражать, но из-за непрофильности — закрывали глаза (информатика была только 1 семестр). Система работала на меня два года, потом отошёл от дел и был удивлён, когда на 4 курсе меня цепляет препод и выдаёт: «вы надоели уж нас своими глистами кормить!» Глисты — там таблица главная называлась gList, и, пожалуй, единственное место, которое не подвергалось мутации :) Так вот, оказывается платформа стала работать на других людей, прожила почти до окончания учёбы. Сейчас улыбку умиления вызывает, да и скажи соискатель такое — я бы тоже улыбнулся, но не снисходительно, а по доброму — он как минимум продумал над унификацией задачи, сделал платформу легко, такой человек даже если что не знает — научится: главное придумать решение, а неэффективность кодирования можно на ревью обсудить (многие, наверное, прохидили через передачу std::vector по значению в функции...).
Дальше, после 3 курса я уже постигал «мягкий» embedded в лице RTOS ОС2000, спеки Posix, XLib, набивал первые шишки в многопоточном программировании. Повезло, подвернулась работка? Может, но обычно везёт тем, кто хочет. Плюс, считаю, что студенчество это огромная возможность для набора опыта, как никак поддержка от семьи ещё есть, можно браться за более интересную работу, нежели за более оплачиваемую, где можно что-то делать от и до, набивая свои шишки. К концу 4 курса такой бекграунд уже позволил устроиться в достаточно серьёзную контору в нашем городе (тот момент когда стало нужно больше денег, хотя интерсность работы снизилась разительно), да, багофикс, рутина, но: первый опыт работы в большой распределённой команде, первые понятия о качестве кода, первое знакомство с системами контроля версий, процесса ревью, тикетов и т.п.
Сейчас же и интернет копейки стоит и проектов куча, где-бы не помешало, что допилить, доделать и всегда можно ткнуть в свою фамилию в логе коммитов :) Или на свои проекты в сети. Тут кстати, минус некоторым собеседователям, которые резюме читают прямо на собеседовании и задают вопросы, ответы на которые там есть. Как полиция проверяет, твой ли паспорт: дата рождения, прописка :)
strannik_k
Некоторые вообще бред требуют — сделайте наше тестовые задание, чтобы мы могли понять, что вы умеете программировать. Тестовое задание частенько уровня «сделать поиск строки в файле и посчитать хэш файла». А по исходникам готового проекта на гитхабе они значит не могут понять, может ли человек программировать или нет.
То же самое и на собеседованиях. Не сделал на бумажке во время собеседования по каким-то причинам, всё, ты в их глазах не программист. Неважно, что ты проекты успешно делал на 100k строк и можешь показать исходники.
Была у меня мысль перед собеседованиях задавать вопрос, аналогичный вопросу «расскажите, что вы знаете о нашей компании»: «расскажите, что вы узнали обо мне».
franzose
Отличный вопрос! Надо запомнить :)
solver
Вы путаете базовый смысл в сказанном.
Речь не об общечеловеческих понятиях лучше/хуже. Речь о понтах.
В поколении моих родителей, большинство прекрасно знало, что надо закончить институт, потом пойти (условно) на завод, там проработать пару лет младшим помощником, потом стать инженером и т.д. и т.п.
Они понимали, что после института они, в общем-то, пока никто.
В моем поколении, большинство так же понимало, что надо пахать. Устраивались на любую работу лишь набрать опыта по своей специальности.
Текущее поколение, с которым приходится общаться, они начитались про всяких цукербергов и считают что им должен весь мир. (для тех кто на бронетехнике напомню, речь идет о большинстве, а не об абсолютно всех).
Они не могут толком двух слов столкнуть на собеседовании, не могут объяснить чем занимались. Не могут толком ничего. Но хотят ЗП «отстатыщьбаксов», отдельный кабинет, бентли и секретаршу.
Это чистой воды понты. Ничем не подкрепленные.
Вот об этом и речь. А не о том, кто лучше/хуже.
TheShock
Да, предыдущее поколение про ваше так же говорило.
hlogeon
Сократ
Ненавижу, когда начинают говорить такими категориями, как «поколение», «раса», «класс». Это недостойно красивого ума, я Вам гарантирую. Университеты в нашем делем непричем, вы, как связаный с IT человек должны прекрасно понимать, что мы живем в удивительную эпоху открытой информации. Я могу прослушать лекции лучших университетов мира(MIT, например), провести качественный контроль знаний и не получить «высшего образования».
monah_tuk
тут слово университет не ключевое. Я хоть и закончил его, но по образованию — инженер-электрирк. У нас информатика один семестр была. На вышке «забыли» теорию вероятности пройти. Зато на глаз могу определить на какое напряжение ЛЭП, где какое РУ на подстанции, где трансформаторы, где выключатели, а где размыкатели или сборные шины :) У меня коллега был без вышки — толковый малый. Короче, тут больше, ключ — «молодых ребят».
А самообразование это просто ахиважное и необходимое явление в нашей отрасли. Вышка сейчас, больше рудимент нашего трудового законодательства. Хотя и не везде: лечь под нож хирургу-самоучке я бы не решился. Хотя вероятность попасть на хирурга с образованием, но методом — тут срастили, там срастили, всё равно остаётся.
121212121
"… как люди из хороших разработчиков превращались в плохих менеджеров из-за желания увеличить влияние, зарплату или по еще каким-то причинам."
Не всегда это их желание, часто это давление со стороны начальства и семьи.
kloppspb
> давление со стороны… и семьи.
Так. Мы же говорим о взрослом нормальном мужике, которому хотя бы 35?
Ну, а не о безвольном существе, которого шпыняют и дома, и на работе.
corvette
Поразительно, но как раз к 35 воля и подводит некоторых. Семья становится больше, работа ответственнее, первые проблемы со здоровьем появляются. Груз такой большой, что никакой воли не хватит, что-то изменить. Да и зачем? Ведь ты так долго к этому шел.
121212121
Именно, мы говорим не о сферическом мужике из Болливудского блокбастера.
Да полно таких случаев, когда людям предлагают повышение, а отказаться они не могут, хотя и не готовы к новым требованиям.