Comments 38
А вы не думали, что сама индустрия настолько выросла, что для "калибровки" правильности ведения деятельности требуется сильно больше времени. Одни только периодические таблицы технологий чего стоят... я о чем, требования соответствия сегодня сильно выше, чем раньше. А дальше будет еще хуже и сложнее. Ну и люди меняются, бумеры совсем отличны от зумеров. Тут все совсем не о способе мышления программиста. Я думаю, что сама отправная точка развития мысли неверна.
В 2004м меня кинули на большой проект saas мониторинга инфраструктуры и сказали "плыви", сейчас это нонсенс. Да и не было тогда индустрии как системы.
В 2004м меня кинули на большой проект saas мониторинга инфраструктуры и сказали "плыви", сейчас это нонсенс.
Щас, нонсенс — кое-где едва ли не норма жизни. Не далее как позавчера прилетела задачка — завести на ESXi макось, при том, что до того я макось только видел с приличного расстояния. До того в таком же темпе вальса была задача развернуть БД Oracle из дампа, при полном отсутствии опыта в оракле во всей компании. Конечно, задачи не программистские, но принцип-то один.
Местами сумбурно, но основная мысль понятна. И я тоже с таким столкнулся недавно. До этого я работал с людьми либо старше, либо ровесниками плюс минус. А вот довелось поработать с человеком лет на 5 младше - на каждый чих бежит ко мне с вопросами. Сам не делает и мое время еще тратит, хотя был сениором на своих предыдущих проектах. Но я думал, что это конкретный человек такой, а видимо нет...
Это было 2 отдельных статьи, объединил для публикации тут.
Да, это система, не один раз сталкивался, и все примерно одного возраста. Хотя исключения тоже бывают.
Возраст тут не при чем, это просто этапы взросления разработчиков. Кто-то их проходит быстрее, кто-то застревает. Если вы каждый раз сокрушаетесь, но при этом даете готовое решение проблемы, то вы не оставляете возможность человеку расти. Либо вам нужно объяснить почему вы приняли такое решение по шагам, либо помочь человеку пройти эти шаги самостоятельно. Человек существо ленивое, если ему проще прийти к вам за решением, чем потратить 15 минут на поиск, то он придет к вам. Если ему при общении с вами не будет "больно", то он будет приходить каждый раз.
Отличие джуниора от синьора не в том как он кодит или насколько хорошо знает интерфейсы стандартной библиотеки, в конечном итоге и тот и другой сталкиваются с какими-то задачами впервые. Вопрос что при этом они создают для команды:
- Джуниор создает "проблемы", при возникновении сложной ситуации он не разобравшись бежит за решением. При этом он сам может не понимать причин и ожиданий, поэтому приходится вместе с ним разбираться с нуля
- Миддл создает "вопросы", он может попробовать разные варианты решений, разобраться в сути проблемы, умеет ясно выразить входные данные и ожидаемый результат. Он приходит подготовленный за подсказкой, а не за готовым решением.
- Синьор создает "решения", он чувствует границу своих возможностей, он знает сколько времени стоит потратить на поиск решения, он приходит с четким вопросом и активно участвиет в поиске решения, если текущее решение не подходит, он предлагает разные варианты и понимает их преимущества и недостатки.
В зависимости от эмоционального состояния, усталости/нагрузки, сложности или новизны поставленной задачи люди могут откатываться на предыдущий этап. Иногда помогает просто напомнить что это просто еще +1 задача, чтобы вселить уверенность в себе.
На счёт "нагуглить за 1-2 минуты". Есть противоположное мнение.
Почему мне кажется, что попахивает нытьём скатывающийся "о боже, я старею!" и "раньше трава была зеленее и погроммисты погроммистее"?
Мало того, так сей труд ещё написан без каких-либо адекватных ссылок на какие-либо сторонние материалы, а половина советов, как минимум, спорные. Чего только стоит совет "проиграть" в голове. Что это значит? Запустить тот самый dry-run? Так это не в голове. Установить в голову ansible? Ранова то пока. Думать головой когда что-то делаешь? И сами то как оцениваете банальность совета от 0 до "капитан очевидность"?
Вообще, у меня так случилось, что почти не было сильных учителей (физика, математика и научрук не считаются). Причём не просто педагогов, а именно учителей, которые понимают как происходит процесс обучения. И это печально. Печально, что приходится всегда всё самому, от этого сильно устаёшь. А ещё есть страх. Да, банальный страх. Технологии сейчас такие, что надо обладать тотальной эрудицией, чтобы разбираться во всём, только вот профит небольшой, а страх всё равно не девается. Наоборот, перманентное "проигрывание" плейбуков в голове только вводит в бесконечное "ничего ли не забыл".
Наблюдая за сверстниками я заметил две интересные тенденции: пофигизм и отвага. Причём в разных пропорциях. Это позволяет быть более стремительным в своих начинаниях не заботясь о провале.
И лучше поблагодарите, что приходят и советуются. Вероятно, это больше говорит о Вас, чем о других.
Дело не в знании технологий, а в том что 30 летний «ребенок» бежит к мамке по любому поводу и без. Вы наверное просто не сталкивались именно с тем, о чем толкует автор.
Выглядит это примерно так:
Скидывает кусок кода - почему у меня тут null ref эксепшн? Ну зайди в отладку посмотри, сам же код писал, мне то в любом случае придется с твоим кодом разбираться
Скидывает кусок кода с вызовом стороннего апи - почему не работает? Ну доку почитай, мне же ведь тоже это придется сделать, этих интеграций миллионы разных
И так каждый час. Причем по хронологии событий - похоже что сам он вообще не пытается докопаться до истины. Или пасует после первого промаха. Он не может отладить и доку почитать, я не могу работать все время отвлекают. Из 10 таких вопросов найдется один реально нормальный. Сам же при этом сениор, проекты вел, командой рулил. Вот как так?
35 летний джун вошедший в айти - себе такого не позволял. Сидел копал, когда совсем уже закапывался, шел ко мне.
С одной стороны — да маразм бывает. Лично я таким не страдал. Я либо давил — делаем так (рассказывал как) и никак иначе (тоже своего рода маразм), либо обсуждаем и приходим к некому компромиссу. Но с возрастом и опытом получилось так, что оппонент и сам уже начинает понимать мой ход мыслей, когда я начинаю раскладывать все по пунктам и проблемам, которые за этим последуют.
С другой стороны — меня тоже били по рукам в свое время. Но разве это не повод стать лучше?
В точку, как раз про таких и писал.
Самое забавное когда скидывают скрин с ошибкой, при этом ответ уже есть на скрине, надо только прочитать вывод
Прибегающим "детям" с такими вопросами я готовлю в голове ответ, но вслух произношу вопросы, которые привели меня к этому ответу. Растущие "дети" сами отвечают на свои вопросы.
Если у меня нет быстрого ответа, то не выпендриваюсь, а благодарю за полезную информацию и расту сам.
У нас в командах действует правило 15 минут. Если небольшая проблемка не разрешается самостоятельно за 15 минут, ищется помощь среди коллег.
Тяжелые задачи (на которые отводится решение за один день) при пробуксовке озвучиваются на ежедневной летучке.
Это понятно, такая тенденция есть, разница в том, что представители младшего поколения при элементарных трудностях "поднимают лапки" вверх. И на трудолюбие это никак не влияет, потому что тот же представитель может вспахивать до 4-5 утра.
Вы обобщаете, не имея статистически значимых результатов на руках. Должен ли так поступать зрелый разработчик?)
Вообще выделение групп по возрасту — эйджизм, и это палка о двух концах. Поверьте, найдутся эксперты и по вашей возрастной группе
Когда мы следуем чьим-то указаниям, у нас подавляется критическое мышление. Особенно если тот, кто дал указания, считается умным и знающим, что делает.
Например, джун пришёл консультировался с синьором «как сделать эту штуку».
Синьор, не посмотрев, тыкнул в первый открытый у джуна хмл-ник и сказал «вот здесь делаешь валидацию», имея в виду «между этими двумя тегами»
Джуна это смутило, потому что обычно изменения происходят в другом хмл-нике, но ничего не сказал — «раз такой большой начальник сказал, что делать тут, значит, он знает что-то, что не знаю я». И сделал.
А потом на ревью звучит:
— А здесь-то зачем?
— Так вы же сказали…
— Мало ли что я сказал, у тебя своя голова есть?
А поскольку представители старшего поколения обычно опытнее и авторитетнее, мы получаем систематическую ошибку отбора.
Ответственный человек будет пытаться помочь заказчику — будет выяснять, что ему на самом деле надо, чего он хочет достичь поставленной задачей и т.д., и в итоге подберёт оптимальный вариант для решения именно проблемы заказчика, а не поставленной задачи.
А человек, который не ценит чужое время (и бегает отвлекать своими вопросами вместо погуглить), — ему без разницы что там за проблемы у заказчика, ему главнее решить поставленную задачу и получить за неё з/п.
Корреляция с возрастом и поколением может и есть, но ключевой фактор — ответственность человека.
Если в компании поощряется креативность (к работнику прислушиваются) и выделяют время на самостоятельные исследования вопроса (не спрашивают каждые 5 минут «Скоро уже?») — тогда у человека со временем появляется ощущение, что он может самостоятельно принимать решения, за которые не будет стыдно и его не выгонят (растёт).
Если человек прошёл собеседование, значит он уже не откровенный бездельник и какая-то база и желание развиваться у него есть (либо проблема в собеседованиях).
Спасибо за статью, практически полностью совпадает с моим опытом (более 20 лет :)
Тут уже многие указали, но я тоже к ним примкну:
Смешано два разных уровня. Верхний уровень понимания задачи, это РО и нечего мешать коней с мухами. Есть человек, который должен знать и понимать как должен выглядеть конечный результат конечного таска. Уровень ниже - конкретная реализация конкретной задачи в рамках конкретной архитектуры и код стайла и прочих стандартов компании. Тут да, миддл может к тимлиду сходить. Сениор поспорить с тимлидом))
Эйджизм. Люди одного возраста оооочень разные. Прям совсем. Ваша выборка это ваша выборка. Моя вполне может оказаться (и оказывается другой). Я тут еще могу накинуть про этнические особенности и они тоже оооочень разные могут быть. В этом месте действительно кажется что вам трава была зеленее. Опять вопрос в вашей выборке.
А итогом - очень все зависит от процессов найма в конкретном месте, а также от процессов в самой фирме, ее размере и области)) Потому что я вам сейчас пишу про свой опыт в эмбеддеде, но точно знаю что у тех же сайтостроителей и игросоздателей все по другому.
И это тоже нормально.
Часто доходило до крайностей — вопросы возникали такие, которые можно было нагуглить за 1-2 минуты, а ответ было в первых пяти ссылках на первой странице поисковика.
У меня лично нет возможности ни у кого ничего спросить, поскольку рядом нет программистов вообще. Однако к Гуглу у меня отношение двоякое. С одной стороны там можно нарыть много чего интересного, а с другой, на простейшие вопросы часто нет ответов по существу, вплоть до того, что приходится изобретать велосипед самостоятельно.
Пару примеров. Понадобились мне обычные меню в дочерних окнах. Как это сделать с помощью C++ / WTL? Перерыл весь интернет, ничего путного не нашел, кроме одной случайной фразы, где-то в комментариях по вопросу на аналогичную тему. Однако пока довел дело до практической реализации, без явных глюков, пришлось повозиться. Просто, M$ в свое время решил, что локальных меню, в подчиненных окнах, быть не должно в принципе, это блокируется на уровне системных библиотек. Контекстные меню – пожалуйста, эмуляция с помощью кнопок – то же, можно даже наваять собственное меню с нуля, но это все было явно не то.
Потом захотелось портировать опенсорсный консольный видеопроигрыватель FFplay.c в виндоуз приложение. Просто поменять main() на WinMain() не выйдет, ну, не любят линусоиды «форточки». Опять же, пришлось хорошо повозиться, пока удалось реализовать задуманное и даже поместить проигрыватель в отдельный поток.
Теперь вот кинулся делать плагины к своей собственной программе (чтобы реализовать идею бинарной модульности). Думал, тема то проходная, опенсорса тут валом, информации должно быть тоже. Однако болт! Кое-что есть, естественно, как же без этого, но так чтобы найти подходящий прототип это сами, сами, сами. Главные проблемы – во взаимодействии различных циклов сообщений (поскольку в dll реализуются дочерние окна). Но, постепенно, собственный велосипед получается и здесь.
Иногда думаю, как было бы здорово, если бы кто-то был рядом, кто мог бы ответить на все мои вопросы по программированию! Эффективность процесса программирования возросла бы на порядок.
Их еще в мифическом человекомесяце Брукс описывает вот так.
Обратите внимание на концовку «полученные данные не выявили никакой корелляции между стажем и производительностью».
Хорошие программисты хороши и на старте карьеры, а плохие пишут плохо и на старте и через 10 лет.
А никто не сталкивался с Senior-s которые боятся спросить, потому что "будут глупо выглядеть", и вместо этого любыми силами пытаются найти "решение" сами? У меня чаще так. Иногда до абсурда.
Это задача тимлида балансировать между "молодец, разобрался" и "зря время потратил".
А как это делать без микро менеджмента?
Один из критериев того, что пора повышать работника, это отсутствие необходимости микро менеджмента при работе с ним. Для новичков он необходим. Если старый работник требует такого подхода, значит его способности либо переоценены, либо что-то сломалось в конторе (как вариант — дали задачу не из области компетенции).
Ну а если отбросить в сторону шутки и говорить по существу, то мне кажется, что все проблемы автора происходят из-за его некомпетентности как руководителя. Я не сомневаюсь, что он отличный и опытный программист и, вероятно, просто хороший человек, но руководить людьми — это, прежде всего работа менеджера. И вместо того, чтобы изобретать велосипед, можно было обратиться к гуглу и найти хотя бы базовые методы постановки задач, такие как SMART, PURE, CLEAR, посмотреть как производится контроль выполнения этих задач, почитать про делегирование.
Читаем задачу думаем и пытаемся понять что же в итоге хочет получить постановщик задачи— это, простите, бред полнейший, читать, думать и пытаться понять можно до позеленения, но если задача сформулирована некорректно, то толку от этого не будет. Чётко и понятно сформулировать задачу, а главное убедиться в том, что исполнитель эту задачу понял — работа руководителя.
Если же Вы уже всё это пробовали, а сотрудники всё-равно косячат, то значит проблема в найме — почему наняли именно этого человека? Почему не отсеяли его во время испытательного? Почему вообще этого человека повысили с джуна до мидла? Опять же — вопросы к руководителю.
Про эйджизм написали выше. Если очень хочется делить людей на группы, то уже тоже давно всё придумали за Вас — рекомендую посмотреть DISC — самая простая для понимания и запоминания модель. Кстати, тип сотрудника по DISC нужно так же учитывать при постановке задач. По DISC есть интересная книжка — «Кругом одни идиоты» — там как раз описывается ситуация с руководителем, который считал что все его подчинённые плохие.
Сталкивался с таким программистом всего один раз. Что интересно - товарищ был старше меня, но вел себя именно так. Однажды даже сказал что-то в духе "у меня не вышло, я этого делать не буду".
Однако, справедливости ради, тот проект вообще не вызывал никакого желания в него вникать и разбираться, тк состоял из наслоений говнокода со спагетти. Присмотритесь к своему проекту, возможно причина нежелания разбираться самостоятельно вот в этом.
Как думает программист?