Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 31
ВКР
ВКР -- многозначная аббревиатура, несложно в самом начале статьи и её спойлере написать, что это Выпускная квалификационная работа 🥸
Если это будет публичный/общепринятый метод, то просто под него будут затачивать код. Возможно даже не самостоятельно, а с помощью ИИ.
Не выживет на практике. Почему? На мой взгляд есть три причины:
Людям будет не особо интересно разбираться и внедрять
Значительная часть работы это не написание кода
Работу по написанию кода стремительно забирает ИИ и эта тенденция усилится (не вижу объективных причин для замедления тренда)
Даже одной из этих причин хватит, чтобы внедрение в индустрию было довольно сложным. А у нас все три имеются на данный момент. Так что без шансов)
Ещё одна причина, и очень существенная - какой процент кандидатов имеют личные open source проекты (где они единственные авторы)? 5%? 1%?
Из статистики просмотра резюме - где-то для 5% можно найти github (по никнейму или указан явно).
Нюанс в том, что у многих там нет кода по которому стоит оценивать людей с профессиональной точки зрения. Там могут быть просто эксперименты или какие-то форки. У меня вот только код с GSOC можно считать более менее. Но что людям скажет мой код на Clojure полезного? Не очень много)
Например, в computer vision, часто, можно увидеть код экспериментов с чем-то, вот только качество кода там будет стабильно отвратительное, потому что это write once код для проверки алгоритма.
Ну или другая крайность - у джунов/мидлов можно увидеть типовой проект на каком-то фреймворке который вообще о человеке мало что говорит. Потому что это что-то уровня Hello, world по How to гайду из оф дока.
Кроличья нора в целом)
Как раз собирался (но опоздал) дополнить свой комментарий, что даже в тех немногих случаях, когда есть код на гитхабе, он мало что скажет)
Потому что:
1) он часто не Prod-качества,
2) он часто совсем не в той области/языке/стеке, на который подаётся кандидат.
И кроме того, хочу ещё раз подчеркнуть неновую мысль, сказанную в статье тоже, что в требованиях на вакансии почти всегда пишется избыток требований, абсолютно лишенный всякого смысла. Эти требования настолько конкретны и настолько избыточны, что серьёзно относиться к ним просто не могу. Поэтому вся эта затея с сопоставлением требований и умений, хоть и хороша сама по себе, но практически не реализуема.
Архитектура слишком абстрактная тема(это я про пункт с джуновским монолитом) и определить правильная она или нет можно, когда знаешь требования к системе. Выбор подходящей архитектуры, библиотек, инструментов и тд - важный критерий для высоких позиций. Нужна экспертность(с умением объяснить почему было выбранно это а не другое) и насмотренность. А так проект интересный, желаю успехов.
Вначале поржал с темы статьи (новичок, толком не вкатившийся в IT, пытается оценивать навыки значительно более опытных коллег и классифицировать их), но по крайней мере один толковый вывод есть:
не количество навыков делает из миддла синьора, а образ его мышления.
(Напомнило классическое "знание некоторых принципов компенсирует незнание некоторых фактов").
Ну и вообще на удивление толково написано, и про эффект Гудхарта ("как только программистов начинают оценивать по багтрекеру – багтрекер превращается в тыкву") не забыли.
Да и дальше интересно, и про то, что код опытных разрабов проще ("пиши код так, будто поддерживать его будет склонный к насилию психопат, знающий, где ты живёшь"). Можно попробовать, кстати, сетке дать промпт – вообразить себя таким психопатом и оценить шансы, что она возьмёт топор и пойдёт к разработчику.
Женись на мне
Код Senior-разработчика алгоритмически проще, но архитектурно сложнее.
Журналистские штампы. Метрики где? Где исследования "я промаркировала этот и этот репозиторий сеньорским, потому что" (и не ошиблась)
Единственное чем определяется грейд разработчика - сколько за свою карьеру он совершил ошибок, настолько они были критичны и степень его готовности нести за них ответственность и исправлять.
Люди много тысячелетий изучают иностранные языки и неплохо преуспели в этом. Современные методики помогают учить язык достаточного эффективно и настолько быстро, насколько это возможно. Причем для оценки уровня вроде бы есть понятные и очевидные критерии - умение писать, разговаривать и запас слов в лексиконе. Тогда почему у нас не один экзамен, а целая россыпь - IELTS, TOEFL, TOEIC и дальше по списку, при этом каждый из них них признается только определенным кругом организаций, а для каких-либо специфических случаев свою версию экзамена может проводить лично условная городская администрация.
А теперь возвращаемся к вопросу о грейдах в относительно молодом ИТ, где как бы и таких очевидных критериев то и нет. Так ещё и компетенции от молода до стара хочет оценивать человек, который в профессии то и не был. Отличная затея, что может пойти не так? Статья отличная, много умных слов, списки и даже пара графиков - для КПИ по вузовским публикациям пойдет. Но вот методика? Если бы она существовала, ее бы вовсю использовали, ибо обе стороны найма увязли в болоте: и работодатель нанимает не способных, а прорешавших кучу литкода и прошедших курс по обману рекрутеров (те самые всеми любимыми "софт скилы), и сотрудники устали получать автоотказы, так что отправляют по тысяче нейрооткликов в день с фейковыми резюме.
степень его готовности нести за них ответственность
Это как измерить? Смотреть, кто выше руку поднимет, крича "Я готов!"? Откуда такие "небесно-воздушные" формулировки?
Меня аж задел ваш коммент. Смотрите. Я одно время работал инженером (не программистом). Так вот, погранично столкнулся с уголовной ответственностью. Пострадал человек и искали козла отпущения и пытались сделать им меня. Тут я понял, что такое ответственность. И когда кто-то говорит - я несу ответственность, особенно типа: выгонят с работы, деньги потерять, зарплату не получить - меня распирает дикий нервный истеричный смех. Когда над тобой не висит реальный домоклов меч в виде срока на зоне, или смерти/увечий, калетства от братков, либо других структур и прочего - то всё это не ответственность. (Понимать "степень ответственности слишком мала").
Вот программист пишуший софт по управлению системы безопасности АЭС, или просто АЭС - это теоретически человек несущий ответственность. Почему теоретически? Потому-что правда там тоже нужно постараться доказать, что виновен именно в взрыве программист, а не конструктор, идиот за пультом, строитель (условный, к прим. прораб укравший металл на дачу) или материалы некачественные. В любом случае у нас есть традиция - в случае больших жертв или потерь виновны директор, главный инженер. Даже, если они не виновны и даже рядом не стояли.
Вот тебе и ответственность.
А вот например, вы программист создающий банковский бекэнд, и чего-то ошиблись и чьи-то 100500 млн. денег ушли куда-то. И например это бабки Германа Грефа... И как-то кто-то нашел, где ошибка... Это тоже ответственность. Я не думаю, что вам простят например 100500 млн. долл. потерь..
Вернуть вы их в обозримой жизни вряд ли сможете. Отомстят (на части например покрошат, в прямом смысле слова) и забудут.
Кстати, директор Чернобыльской АЭС, во время взрыва тихо себе спал в кроватке. И ничего и никого не трогал. Получил 10 лет.
И абсолютно правильно получил.
Но вы про наступившую ответственность. А в тексте - про степень готовности её понести. Вы понимаете, насколько абсурдно это звучит?
Отвечу сразу тут, а не под свои комментарием, так как все же имел в виду не уголовные и прочие серьезные с юридической точки зрения ситуации, а штатные в рамках IT-инфраструктуры. В моем представлении практически любой сеньор за свою карьеру ронял прод, делал случайные рассылки клиенту, *вставьте вариант для своего стэка* и в таком духе. И, к сожалению, я встречал слишком много людей, которые в такой ситуации либо забьют, сокроют, либо будут пытаться переложить ответственность, а не побегут срочно писать фикс, даже если достаточно серьезный обнаружился в 7 вечера (опять же, не берем в оборот всякие Озоны и Яндексы, которые могут позволить себе нанять людей которые будут дежурить круглосуточно).
Если опустить ситуацию с огромными командами бигтеха, у которого свои представления о грейдах, то я вижу грейд как умение брать на себя ответственность за какой-то кусок функционала, иметь углубленные знания в определенной области, активно применяемой на работе и, порою, не бояться рисковать и принимать решения, которые иногда стоят за пределами твоего непосредственного функционала. В противовес вечным джунам, которые могут пять лет сидеть на разработке и поддержке одного и того же функционала, но знать и понимать его меньше коллег, пришедших в компанию год назад. Просто потому что они не хотят углубляться и развиваться, но при этом им все ещё достаточно навыка, чтобы закрывать задачи и делать это максимально топорным способом без применения практик, паттернов и не продумывая на несколько шагов вперед как с этим будет работать заказчик или о потенциальных негативных эффектах доработки. Как банальный пример: у нас есть таблица на миллион пользователей, с которой работает много менеджеров. Сценарий простой: открывается страница, через фильтры ищется что-то по ФИО/телефону/почте, далее менеджер открывает карточку с данными, все просто. И вот эффективный менеджер запросил доработку, чтобы прямо под этой таблицей динамически при открытии страницы считалась аналитика - сколько у клиентов заказов, возвратов по ним, кол-во товара, статистика по городам и невесть что ещё. Ну просто он хочет раз в месяц заходить туда, чтобы потешить свое самолюбие, любуясь на цифорки. И вот я понимаю, что вот такой "вечный джун" просто пошел бы и молча сделал эту задачу, ведь по сути там просто SQL запрос за час набросать. Подумаешь, что скорость загрузки страницы с 0.5 подскочила до 3 секунд, заказчик же попросил. "Сеньор" же во-первых зарубит такую доработку на ревью, а во-вторых все же, думаю, предложит альтернативные варианты решения - от ajax подгрузки данных или ежемесячной отправки данных на почту, до выноса этой аналитики в отдельный функционал, так как она не нужна сотрудникам 99% времени.
Можно либо забивать и делать максимально "в лоб" и что просят, придерживаясь позиции "моя хата с краю", либо быть вовлеченным и продумывать все наперед, предлагая альтернативные варианты решения. И, кстати, это именно то, что отличает сегодня хорошего разработчика о нейронки, которая тоже умеет писать код. Конечно, тут все зависит от ЗП, процессоров, отношений с руководством и взаимодействием с заказчиком. И именно на этом этапе видно, что даже оценивая одного и того же человека, можно увидеть как он выступает и в роли джуна и в роли сеньора в зависимости от предоставленных ему условий. И как это оценивать? Особенно с учётом того, что сотрудник, слишком долго проработавший в такой позиции "джуна" каким бы он сильным ни был, сильно деградирует в своих навыках.
Блин, как много слов, чтобы доказать, что я прав. Зачем? Я и так знаю, что прав)
Всё, что тут сказано, это: больше знаний, шире виденье, лучшее знание продукта, умение быстро фиксить баги, путь даже и в неизвестном коде (тут сразу ещё одно умение - быстро разбираться в чудом коже), и так далее в том же духе. Но главное - больший опыт и большая независимость мышления и мнения. Где тут про большую или меньшую готовность нести какую-то ответственность? Ни слова)
"не количество навыков делает из миддла синьора, а образ его мышления"
Достаточно однобоко, так и просится добавка "но именно набор навыков помогает изменить образ мышления".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Джун, который знает всё, или почему Senior пишет простой код: как я пишу ВКР по грейдированию программистов