🎯 Key points for quick navigation: [00:14] 🌍 Нельзя определить синьора программиста по годам опыта [00:27] 🚫 Синьор - не всегда тот, кто писал сложные технологичные задачи [00:56] 📉 Зарплата не показатель уровня синьора [01:10] 📚 Опыт не всегда пропорционален зарплате [01:23] 💼 Зарплата - не показатель опыта [01:33] 💼 Синьор - не всегда старший разработчик [02:48] 👥 Синьора определяет совокупность факторов [03:05] 💡 Синьор плохо продавший себя, остается синьором [03:34] 📊 Синьором можно быть с небольшим опытом [03:48] 📈 Синьоры перед выполнением задачи собирают максимум информации [04:31] 🕵️♂️ Сначала уточняйте требования у заказчика, чтобы не делать бесполезную работу. [04:44] 💰Экономия времени и денег для бизнеса за счет поиска готовых решений и избегания "изобретения велосипеда". [05:11] 💡Не спешите писать код, сначала обсудите детали задачи, чтобы учесть все крайние случаи. [05:38] 🏁 Доводите каждую задачу до 100% завершения, без заглушек и отложенных дел. [06:20] ✔️Выполняйте задачи полностью, чтобы не оставлять "технических долгов" и повышать доверие тимлида. [07:00] 📚 Следуйте общепринятым и внутренним стандартам кода для повышения читаемости, расширяемости и поддерживаемости. [08:11] 🛠Используйте плагины для анализа кода (например, sonar lint) для выявления и исправления ошибок. [08:25] 📋 Документируйте свой код, чтобы облегчить его понимание для других разработчиков. [08:40] 📝 Давайте понятные и описательные имена переменным, методам и классам. [09:22] 🤖 Называй переменные понятно и по-нормальному, чтобы код был понятен и тебе самому, и команде. [09:36] 🛡️ На собесах обращай внимание на названия переменных, даже если это тестовое задание. Это показывает твой навык именования. [10:05] 💼 При ревью кода обращай внимание на названия классов и переменных. Плохой нейминг снижает читаемость кода. [11:32] 🛡️ Синие разработчики дают завышенную оценку времени выполнения задач, чтобы заложить запас на непредвиденные обстоятельства. [13:08] 🤖 Не бойся оценивать время выполнения задач с запасом, чтобы избежать оправданий и стресса. [13:37] 💼 KISS (Keep it Simple, Stupid) - принцип минимализма в разработке: код должен быть максимально простым и понятным. [13:50] 🇷🇺 Не усложняй код без надобности. [14:18] 🇷🇺 Пиши код максимально просто, не вноси лишнюю сложность. [14:31] 🇷🇺 Не рефлексируй, если это не твоя задача. Запиши в техдолг и вернешься к этому позже. Made with HARPA AI
Круто! Вот ответочка от яндекс.спойлер )) Как Senior-разработчики на САМОМ ДЕЛЕ пишут код 00:00 Введение в синер-программистов • Определение синер-программиста вызывает споры. • Опыт работы не всегда делает программиста синер. • Задачи, которые решал программист, также важны. 01:24 Зарплата и опыт • Зарплата не является единственным критерием синерности. • Опыт и сложность задач важнее. • Подготовка к собеседованию и умение продавать себя могут повлиять на зарплату. 02:34 Трудовая книжка и синерность • Трудовая книжка не всегда отражает реальную синерность. • Синерность определяется совокупностью факторов. • Важно понимать принципы работы синер-разработчиков. 04:00 Принципы работы синер-разработчиков • Синер-разработчики задают много вопросов перед началом работы. • Они анализируют задачи и ищут готовые решения. • Важно экономить время и деньги бизнеса. 05:33 Завершение задач • Синер-разработчики завершают задачи на 100%. • Они тестируют и документируют код. • Это повышает престиж и доверие к разработчику. 06:56 Следование стандартам кода • Важно следовать общепринятым и внутренним стандартам компании. • Изучайте SOLID принципы и используйте плагины для форматирования кода. • Документируйте код для его понимания и поддержки. 08:54 Правильное наименование переменных • Используйте понятные и длинные имена для переменных и методов. • Это облегчает ревью и понимание кода. • На собеседованиях и в задачах обращайте внимание на названия переменных. 10:17 Важность читаемости кода • Обращайте внимание на читаемость кода, это важно для команды и на собеседованиях. • Примеры прохождения собеседований можно найти на Boost. • Доступны бесплатные и платные консультации, а также групповые созвоны и личные консультации. 11:39 Правильная оценка задач • Синие разработчики закладывают больше времени на выполнение задач, чем кажется на первый взгляд. • Важно закладывать время на подводные камни, созвоны с аналитиком, написание тестов и документации. • Тимлиды предпочитают предсказуемость, поэтому закладывайте максимальное количество времени сразу. 13:46 Принцип "Кис Кипд Симпл Стип" • Не усложняйте код, избегайте сложных архитектур и абстрактных классов. • Пишите код максимально просто, чтобы его могли понять джуны. • Если хотите отрефакторить код, сначала обсудите это с тимлидом и занесите в техдолг. 14:45 Заключение • Не пытайтесь отрефакторить код без необходимости, сначала выполните задачу. • Если задача не стоит рефакторинга, не тратьте на это время. • Подписывайтесь на канал для дальнейшего развития.
"даже когда задача всё-таки поставлена и её нужно решать, он не бросается делать её сразу" ведь эстимейты завышены в три раза минимум, можно пойти кофеек попить и вздрочнуть пару раз
@@fensrg от проекта зависит и от твоего положения в команде. "Все должно быть ещё вчера" не отменяет того что на задачу будут выданы какие-то эстимейты. Тут скорее зависит от тимлида и менеджера и на сколько они понимают/контролируют уровень трудозатрат. Тебе задачу ставят говорят надо срочно. Ты говоришь ой ребят тут Х и У и Й ещё проверить нужно будет, займет два дня. А на самом деле работы на 4 часа.
@@aduditsky task переводится как задача. Любое дело которое ты делаешь целенаправленно и спланировано это в любом случае - задача. Для каждого видео ведь пишется план, сценарий, делается съемочная часть (камера, свет, звук), монтаж, заливка. Кроме того ведение Ютуб канала, это тоже работа, с графиками и планами по выпускам. Это видео, как и остальные, не просто по наитию снималось. И тайм-коды на самом деле это простая задача, просто найти для каждой части плана соответствующие отрезки видео, и указать название из плана
У кого-то подсмотрел такое определение junior-middle-senior: - Джуну надо ставить задачи и постоянно за ним приглядывать - Миддл может работать самостоятельно - Синьёр может ставить задачи другим. Это тоже, конечно, довольно условное деление, но мне это определение легло на душу :)
А может ставит задачи другим Проект-Менеджер? 🙂 Я на первой своей работе тоже ставил задачи коллегам. А затем, в течении около 10 лет, больше таким на занимался. А все потому, что на первом проекте у нас не было Проект-Менеджера. 🙂
@@KostopravHD чем тогда ПМ занимается в таком случае? Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером. А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык. Если раздачей задач занимается тех лид - то значит что в команде не настроено управление и делегирование.
@@KostopravHD чем тогда ПМ занимается в таком случае? Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся, что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером. А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык. Если раздачей задач занимается тех лид - то значит что в команде не сформирован менеджмент, управление и делегирование.
@@MrDarthat так у большинства сеньоров недоделанных нет опыта разработки. зато есть хождения по собесам и зубрежка алгоритмов и паттернов с методологиями.
@@KostopravHD Да нет, они только счастливы, что я за них уже все решил и им не пришлось стекхолдеров напрягать, хотя те тоже не знают. Я же не делаю другую функциональность, делаю заказанную, просто неосвещеные места сам уже проектирую. Ну и, с момента решения я их информирую, так что до момента реализации у них есть время внести изменения
Программист не обязан знать всё наизусть. Есть документация, которой нужно уметь пользоваться. Я работаю программистом более 25 лет, каждый раз задачи разные. Под каждую задачу изучается набор инструментов и потом уже она реализуется. Не факт что сразу получится и ты с первого раза все правильно сделаешь. Каждый пишет по своему.
@@rybiizhir , ну для работодателя логично, он же тебя нанимает не для того, чтобы свои деньги тебе просто так отдавать. Он хочет нанять человека, который УЖЕ в теме.
@@SeregaZinin Ухты, а если про сап знает один-два человека, а остальным он вообще не вперся - значит, директор попал? Будет вынужден платить бешеные бабки этому счастливчику? Все определяется местом, временем и ценой услуги :)))))
Хочу добавить пару пунктов к всему вышесказанному: - Реально решает опыт (не в конкретной технологии, а в разгребании дерьма вселенского масштаба по типу - "вот нам тут досталась система, с которой никто не знает как работать, и документации по ней нет особо. Нам нужен по ней стейджинг и внятный процесс по деплою доработок/фиксов") - Умение брать на себя ответственность.
Senior-разработчик знает почти все правила хорошего кода, многократно нарушал их и понимает, к чему это приводит. Поэтому он рационально распределяет свои ресурсы.
Для себя как-то выработал следующие критерии уровня разработчика: Джуну надо объяснять как делать задачу, контролировать выполнение, внимательно следить что он делает, обучать. Мидл уже может сам понять задачу и выполнить её. Может сам разработать отдельный элемент системы или часть приложения. Мидл уже учится сам. Сеньёр может поговорить с бизнесом, понять что ему надо, спроектировать системное решение и сам целиком его реализовать. Если он не знает какую-то технологию, то может сам разобраться, обучиться или найти того кто знает.
@@AGalilov В моем понимание синьор в такой системе это чувак, который на вход получает бизнес проблему, а на выходе выдает решение, и соответственно поговорить с бизнесом в данном контексте это прояснить непонятные моменты, донести возможные негативные последствия решений и так далее. Аналитик в такой системе выполняет свою привычную роль сбора бизнес требований.
@@AGalilov а зачем аналист нужен? джунов к кастомерам запускают дефайнить все юзкейсы. обычная практика. даже заявляют, что джун должОн знать инглишь как родной, чтобы с кастомером общаться. так и делает большинство. результат как у йордана в пути камикадзе - провальный проект. все говорят, что читали, но все на тех же граблях пляшут.
@@Roman-ej3xg "с бизнесом говорить"? этим занимается project manager. а не программашка, пусть даже якобы сеньор. программашка может быть консультантом у проджект мэнеджера. еще джуна пошлите "с бизнесом говорить", как некоторые делают. срамота.
Не, на работает. Видел нескольких разрабов с годами опыта, что соответствуют критериям: способны развиваться, сами выполняют задачи и понимают, что нужно бизнесу. Но пишут код, как джуны. Непонятные переменные, все перегруженно, никакого солид, одни проектные знания, комитят то, что не комитется и так до бессконечности. Так что в видео более верно
На самом деле прям база базированная. Я практически со всем согласен. По поводу комментариев не очень понравилось. Я бы раскрыл мысль, что код, сложный для восприятия, лучше комментировать, но ребята на опыте пишут и так очень просто, чтобы джун мог разобраться, либо прыгнуть в процедуру, где класс или функция определены и там прочитать
Все точно и по делу. Подписался. Рад, что нашел ментора, который может объяснить доступным языком решение "проблемных" мест в становлении высококачественным специалистом. Спасибо за контент. Продолжай в том же духе👍
15:05 Я бы добавил, что если по ходу решения задачи, разбор кучки вонючего кода выйдет дешевле за счёт того, что его будет проще использовать и не городить обходных путей, то стоит эту кучку разобрать без создания тех-долга. Лида можно и предупредить, если куча достаточно большая.
Не всегда эти принципы применимы в реальной практике. Например, бывает так, что времени в обрез, что фича нужна заказчику уже вчера, а красиво, со всеми тестами, с документацией и без костылей писать код слишком долго. Тогда приходится делать, как успеваешь, а остальное кидать в тех. долг. Или вот на счет рефакторинга. Бывает садишься пилить таску в какой-нибудь легаси, но без рефакторинга это сделать просто невозможно или крайне больно. Проще потратить время на переделку, чем пытаться впихнуть костыли в плохо написанное.
Так все равно рефачить IMO стоит после как минимум краткого обсуждения с Лидом о причинах сего действа. Поскольку этот говнокод работает и уже через qa прогнали. И чтоб потом не прилетело, кто у нас сборку порушил, чей комит сегодня самый лучший, стоит хотя б перед фактом поставить руководство… imo
@@КириллЧе-я5ы Понятное дело, что втихую такое не станешь делать. Все равно лид и другие разрабы будут в курсе, ведь от них апрувы нужны, чтобы вливаться в мастер. Подобное заранее обсуждается с командой и закладывается в оценку таски.
@@КириллЧе-я5ы костыли, которые пораждают другие костыли) если оценивал сам и не заложил в эстимейт рефакторинг - сам мудак. Если оценивал тимлид за тебя - соболезную) Всё это конечно идеализированно. На практике обычно получается либо мвп из круда смешанного с логикой и до реальных нагрузок все счастливы, либо что-то сложное которое в конечном итоге превратят в говнокод. Хороший проект может быть только если его архитектуру продумали правильно, в соответствии с бизнесом. И как только вы видите что вам нужно что-то рефакторить, значит либо вы пишите проект у которого начали меняться бизнес правила, либо изначально у вас неправильная архитектура и в том и в другом случае надо писать всё по новой. Но это в идеале, на практике вы просто набираете тех долг, и через какое-то время проект заканчивает свою жизнь)Бывают и промежуточные состояния))
@@MELkey3 бывают и промежуточные), особенно если этому проекту четверть века… и он до сих пор живее всех живых и периодически приходится что-то рефачить и надстраивать надстройки над старой архитектурой, поскольку староновое друг с другом практически не уживается))
Даже у бандарлогов есть своя иерархия :) Что действительно отличает высокорангового разработчика от низкорангового, это умение смотреть в глаза и убеждать всех в своей компетентности.
Nice video mate! Straight to the point. Seniors just don't write code any more, you know how to Google, how to ask GPT and later modify a little bit and that's it. Of course discuss with business PM's PO's before. Wothout it nowhere. Thumbs up.
Ну на самом деле да, главное отличие синьера от всех остальных, это способность решать высокоуровневые задачи, с минимальной постановкой. И не просто решать, а правильно и эффективно. Остальное всё уже бантики
Документация улыбнуло ( в Германии только под страхом расстрела) все списывают на clean code;) MyClass это Junior Понять 10% Залить 20% Тест ручной 10% Unit при покрытии в 90% 25% 35% документация, конфигурация, папки в системах клиента,,, и отдых В проектах со сложным бизнесом типа мед страховок
Там где сложно: не задавать вопросов самое оно (ты же сеньор, все понятно) - все сложно, все обсуждается в ходе процесса Там где легко: задавай вопросы, уточняй что-куда (ты же сеньор, вас на понт не взять)- все сложно, все обсуждается в ходе процесса Итого: везде затянут процесс, зарплата капает. Не благодарите
Ну,я работал старшим разрабом в трех конторах. Так меня не берут сейчас никуда, мол на джуна даже не тяну. Хотя, сложные ИИ проекты поднимаю с нуля. Сейчас не работаю, пишу статью на архив орг, медиум и готовлю презу по тому пооекту который разработал сам с нуля.
Есть выгорание какое-то. Я работал программистом 1С в течение 5 лет в нескольких конторах. Но потом решил почиллить на вольных хлебах. Теперь решил вернуться в разработку, только из-за появления ИИ. Что-то для себя создать. У вас что за проект и стек технологий ?
Сеньор разработчик, это который может и в проектирование архитектуры, и в производительность, и с какими-то узкими технологиями знаком, и джунам затрещину отвешает за кривой код (нетерпим к плохой архитектуре и плохому коду). Пожалуй, самый главный критерий - это владение бэст-практиксами (правильное проектирование, чистый код, юнит-тесты и пр.). Та или иная технология/фреймворк осваиваются без проблем. В какие-то нужно пару дней повтыкать, в какие-то пару месяцев, но глобально сложного ничего нет. Вчера ты не владел технологией Х, через две недели ты можешь лекции читать по технологии Х. Надо быть совсем уж тупым, чтобы не суметь освоить технологию Х. А вот к освоению бэст-практиксов приходят через 3-5-7-... лет практического опыта работы, кто-то вообще не приходит. Поэтому, на мой взгляд, умение в бэст-практиксы - главный критерий окукливания в сеньора
Всё предельно просто. Синьор может в одно лицо решить задачу. Да, может с гуглом, но сам разберётся и сделает. Миддл - решает, периодически прибегая к помощи коллег или синьора. Джун не может без постоянных консультаций. Разжевали, сказали чо делать - делает. Code monkey. Нет?
Кстати хороший критерий. На своем веку видел много кодеров. И что больше всего поразило, что очень многие не умеют пользоваться дебагером. Казалось бы элементарная вещь, но нет. Ну и очень многие вместо того что бы разобраться любят отрывать других от их задач. Вот эти особенно бесят.
Блин, вот с первой частью, кто такие сеньёры прям странно вышло, то по правилам - отлично! Из этих правил рождается простой критерий - сеньёр думает масштабом бизнеса. Мидл - архитектуры решения. Джун - локальным решением здесь и сейчас. Под "думает" не сидит и философствует, мол, а хорошо бы прикрутить фичу, которая круто выглядит. А именно, "как предсказуемо решить проблему бизнеса". И да, навык кодинга важен, но если ты головой сеньёр, то навыки наработаются быстро. Если ты головой джун, то знай хоть 500 фреймворков и умей с закрытыми глазами сделать красно-чёрное дерево да развёртывай хадуп в перерывах между красным и рыжим ютубом, всё равно ты джун. Хотя сложно знать столько фреймворков и не думать архитектурой приложения, но практика показывает, что есть и бывают такие люди)
имхо сеньор это тот кто на работе не хочет писать код и максимально избегает этого ) джину они сразу пишут и думают чем больше кода они напишут, тем лучше. но все с точности до наоборот
8:45 Не так давно столкнулся с кодом, коммантарии есть, а смысла нет, давно утерян, за аремя после написания комментария код правился множество раз и комментарий не соответствовал функционалу от слова совсем... Поэтому код должен документировать себя сам!
То что комментарии написан к старому коду, это проблема не комментария, а того кто его писал. Самадокументирующий код + понятный комментарии и минимально написанная документация, залог хорошего и понятного кода
@@x-grand-x нет, это не проблема того кто писал коммент, это проблема того, кто будет править код... а создал эту проблему тот, кто не обновил коммент!
ни разу не писал тесты и не комментировал свой код. а еще отправляю задачу в qa с багами и заглушками, потому что сроки. все работодатели очень довольны и не хотят отпускать, зп 500к
Приветствую автора! Давно интересует вопрос - кто устанавливает время на выполнение задачи для джуна (он сам или тот кто дает задачу), и какие сроки являются средними? Просто побаиваюсь, что если попросить, например, пару дней, то на меня вылупят глаза и зачмырят за то, что мне нужно столько времени на тукую простую задачу (а я еще не умею реально оценивать время, которое мне потребуется). Заранее спасибо!
Смотри, если ты официально джун на позиции джуна, то ожидать от тебя точных эстимейтов никто не будет (при условии что все адекватные вокруг) говори сколько чувствуешь, если не так то тебя поправят, а с опытом поймёшь как нужно. Не забывай что 99% задач слоднее чес кажется и времени уйдет куда больше. А те задачи которые ты точно знаешь и умеешь - ну если знаешь то ставь как знаешь. В разных компаниях ещё есть всякие приколы в зависимости от специфики. Где-то эстимейты ставит тимлид+аналитик, где-то играют в покер, это когда несколько человек заптсывают "в закрытую" сколько времени задача займет а потом "вскрываются" одновременно. Тех кто написал самое маленькое и самое большое просят пояснить, может есть решение которое они знают или есть подводные которые никто не заметил, а потом на основании этого выбирают средний эстимейт. Это делается чтобы нельзя было завышать жстимейты и потом пинать хер, всех разом подговорить почти невозможно. В общем и целом проблема - занизить эстимейты, по тому что не успеешь сделать. Завысить немного и сдать раньше - это не плохо. Завысить сильно тебе скорее всего не дадут. Да и если задача занимает несколько дней по твоему (особенно на джуна) то можно предложить её декомпозировать, это тоже норм, мол разбить на таски по меньше
лучше оговаривай время с запасом, чем каждый раз сдигай сроки. нужно понимать зачем сеньоры с тебя спрашивают время. никто не думают о чмырении, думают о планах выполнения, чтобы уложиться в сроки (ибо задач много, где есть блокеры, где-то нет). важное правило это быть предсказуемым. и лучше сразу уточнить, по естимейтам, т.е. идеально сказать, есть несколько вариантов подхода решения задачи - 1) быстрый день -два, но такие вот негативные последствия 2) неделя, но зато вот это вот
не ссы , ты не поверишь но у меня в команде все сеньоры 6+ лет опыта не умеют оценивать задачи и даже в открытую говорят, что хз скок делать будет о времени. если нет сроков от бизнеса то вообще п ох ер
А fullstack разрабочик наверно должен быть вообще богом. Ну как же... Он столько много языков знает. Многие в C++ плюхаются, а фулстек девелоперу вообще норм.
имхо.тех долг это нормально. кладется в бэклог и берется в следующем спринте. бизнесу нужны фичи и если "заглушка" позволяет фиче отвечать требованиям она должна заехать на прод.
Не кантрол, а контрол альт дел. И нажимать их не надо, всегда есть Галочка, форматировать при сохранении. Оптимизировать импорты и пр. Сеньор отличается тем, что умеет не делать лишнего и за ним нет шлейфа из косяков.
Прохожу вход в it такой же как и у Евгения. Первая работа в it тоже в Сбере. Правда в трудовой написали что я аналитик😅 Хотя по факту backend-разработчик Прошел год и хочется двигаться дальше. Евгений, что делать, если ты хочешь расти по ЗП? Кто-то советует, учитывая специфику Сбера искать другого работодателя, а кто-то пытаться через контроффер попытаься остаться и выбить условия лучше Что думаешь по этому поводу?
Существенное повышение зп только через смену работы. Контроффер это плохая практика. Со сбером врятли прокатит вообще, но если и прокатит, то появятся завышенные к тебе требования и ожидания, и ты станешь первым кандидатом на замену в случае чего.
а если увидел точно супер критичную ошибку (что обанкротит компанию) в не своем коде, то тоже оставить и дать катастрофе случиться, чтобы идти спрашивать что делать у тимлида?
Это больше похоже на навыки мидла над которым стоит контролирующий тимлид. От серьера у нас ждут максимальный опыт, обычно это чувак который наступил на все грабли и знает наилучшее решение.
По-моему senior больше понимает как все работает и критерии выбора. Типа почему тут такая архитектура, почему кафка, почему pgsql, а не mysql. И он способен объяснить почему то что он выбрал правильно, а не "всегда так делали и работало".
@@КоляКоронов-к9э видимо зависит от организации. Я видел что архитектор в основном красивые диаграммы рисует, но не выбирает. Тк для выбора нужно сделать прототип и провести нагрузочное тестирование, чтоб выбирать не от балды, а он не может
@@tsc472 В целом если это архитектор а не планировщик то он должен мочь в соляного вытянуть проект Вот только архитектор это дорого а сениор несколько дешевле А как мы помним экономика должна быть экономной
Нет, это все истории не про сениора. Это миддилы. Слово senior обозначает "зрелый", с не "опытный". Я пока нащупал два критерия, которые показывают именно ментальную зрелость, а не тезническую. Так, например, расстановка приоритетов от бизнеса, а не от качества кода - первое. Сениор не будет ультимативно следовать тому же DRY потому что он плчтив сегда больше врежа приносит. Второе - он обучает других людей (жто лучше формиоует ешо собственную базу).
В России очень мало программистов с классическим образованием, оисюда и отсутствие синьоров и мидлы и джуны, считающие себя "профи". Читаю резюме - толпы девчулек, купивших какой-то курс на пол-года и поработавших подносяиком кофе в компании-интеграторе, в итоге все надписи какие запомниди - переписаны в резюме с пометкой " внедряла, разработала, щадачи кодераи ставила". А простейшие вещи, которые должен знать любой грамотный программист - этого мы не знаем. Сортирлвка на основе бинарного дерева - нас пугает, теория баз данных - "ну я же другим занимаюсь", скуль - а что это? В общем ужас...
@Encrouter а всё просто, верят просто.. молодые же как сейчас... посидеди рядом с аналитиком и в резюме пишут "работал аналитиком, опыт 2 года, проект на 1500 армов" и за прлсят как опытный - а в голове ни-че-го (пара гениев была за всё время, прочие - мусор). Молодые верят, что за 2 месяца старовятся профи и гонору у них ппц сколько
Вот я автоматизатор (язык ST) и всё что говорится - я это прям всецело понимаю и принимаю. То есть это справедливо и для АСУ-ТП (на ST, ибо остальные "языки" МЭК это не языки, если кратко)
@@Evg_Af А еще интересно как ты борешься, или как бороться с такими ситуациями к примеру тебе дают задачу менеджер считает что она на 2-3 дня работы, однако при работе с данной задачей всплывают куча нюансов про которые вообще никто не знал, в результате задача затягивается на 2 недели. При этом менеджер начинает негодовать как это так почему она затянулась он не технический специалист и до конца не понимает всех нюансов при этом начинает тебя оценивать, что типо что ты за специалист почему так медленно все делаешь)? При этом тебе никто не дает возможность изначально оценить сколько времени понадобиться на данную задачу. Да и когда тебя начинают оценивать как специалиста это довольно неприятно. Были ли у тебя такие ситуации как с ними справлялся?
Насчет 2го пункта не соглашусь, не бывает такого. Когда пишется функционал по коду проставляются кучи TODO, т.к. эти места могут за собой потянуть такоооооее которое не влезет ни в какую оценку. Аналогично с тестами, тебе дают время только на поверхностные. И только потом, и то может быть, будет этап выполнения тудушек и детальных тестов... Задача должна быть выполнена на столько - сколько требуется бизнесу, но на уровне кода явно не будет даже 80процентов...
У меня на счет некоторых утверждений другое мнение. Как человек в 25 годами опыта скажу, синьёр это опора лида, которой можно поручить задачу и он в состоянии понять на какой уровень нужно вывести её решение. Поясню. Вот эти все "Выполнить до конца", это не из жизни. Так вы никогда не представите функционал бизнесу в срок(если вообще представите). Нужно уметь проводить четкую грань, где пора заканчивать с идеализмом и начинать делать задачу. Если в равных условиях дать задачу Синьёру и Мидлу, мидл обязательно сорвет срок, и не потому что у него меньше опыта(тоже фактор), а потому, что попытается комплексно закрыть задачу без оглядки на последствия, т.к. не имеет опыта оценки целесообразности в текущий момент. Бизнесу плевать на всякие тех долги и качество кода. Оценка приоритетов всегда следующая: 1. Предоставление результатов бизнесу. 2. Недопущение критических ошибок. 3. Закладывание тех долга в канву архитектуры(Это когда ты делаешь временное но быстрое решение, которое в последствии не придется полностью переписывать). 4. Решение тех долга. Обратите внимание, что Недопущение критических ошибок имеет меньший приоритет по сравнению с Предоставлением результатов. Следование этим простым правилам продержит проект на плаву долгие годы. В противном случае проекту хана.
Очень глупо гнаться за сроками, потом придётся выбросить огрызок и переписывать из-за множества причин. Взять ту же масштабируемость. Она невозможна без оптимизации, причем желательно на стадии проектирования. Погоня за сроками никогда не приводит к хорошему - ну погляди на хрущевки панельные, их сдавали даже с опережением графика ) А потом на сталинки посмотри.
В начала послышалось: синий разработчик 🤣 И второй момент, как можно задачу выполнить на 100%, не бывает так, ты вроде как всё сделал, вроде как работает, но в конце появляются идеи по улучшению кода, и оно зараза не заканчивается, у кого было такое?
Да миллион раз и всяко. Как-то уперлись рогом - нужны инструкции по работе. Херня вопрос - все сделал со скриншотами, как комиксы для детей. И все равно они где-то сделали херню, и получили не тот результат. Говорят - не работает :D Идоры! То есть ироды. Я беру на их глазах делаю по инструкции - нужный результат получен )
С if или for прокатит ещё но когда функция хотябы на 50 строк... и да пример кода на видео был написан за минуты 3, с помощью помощника от компилятора, а ручками писать минут 10.
@dbmongo9732 как зачем? на собесе могут спросить программашки. их чему учили - они то и спрашивают. например. алгоритмы сортировки. они думают. что лучше их реализуют, чем, например, это сделано в том же oracle или любой другой субд. не ответишь - не возьмут. так что зубрить надо. много и все. и по собесам шастать. вечным студентом.
Фильм был, старенький... Инженера приглашали сделать реверс новейшей технологии, платили бешеные бабки и по окончанию проекта стирали память!! Думаю, как тебя в сбер занесло? Синьер это должность, что удобно для конторы. А программист - это призвание, ярлык на всю жизнь!! В конце фильма, инженер сломал стереотип и начал думать своей головой и жить для себя ...!
На моменте про вопросы аналитикам/заказчикам немного тормознул просмотр. Ну, на собеседовании - пожалуй, но не в работе. Сейчас многие издадут усталый стон, но я скажу. На проекте должна быть качественная документация. Чтобы каждый раз каждому сотруднику не бегать куда-то, не дёргать кого-то по поводу, а как должно выглядеть/работать вот это? ОК, идеальной документации не бывает. Вопросы будут. Но первым делом всё-таки надо смотреть доки, а не сразу бежать расспрашивать. И если в них есть пробелы, то уже тогда хватать аналитика, бомбардировать вопросами и заставлять прописывать. Не просто ответить, а прописывать. Прописывать в документации. Качественным текстом. И зафиксировать факт правки. В присутствии свидетелей с других направлений. (Извините, немного гиперболизировал, но наболело) И я намеренно писал "сотрудник", а не "разработчик". Документация используется всеми. По ней будут писать гайды для пользователей и техподдержки, по ней разрабы пишут код, по ней тестеры проверяют продукт, по ней тимлиды и PM'ы планируют работу команд.
У нас, конечно, в аудите, зарплаты не айтишные, но деление почти такое. Только специалист (не осталось в СВА), ведущий специалист, эксперт и главный эксперт
Я на прошлой работе после сеньора дорос до маркиза, потом до герцога, уволился когда уже был лордом.
Хорошая шутка. Надо будет записать :)
Козырнуть как нибудь.
В свинопасы пошёл?
ржал
@@alekseev74 когда сеньор, надо пройти обряд помидоров, когда в тебя кидают помидорами
Ваша милость... 💂♀
🎯 Key points for quick navigation:
[00:14] 🌍 Нельзя определить синьора программиста по годам опыта
[00:27] 🚫 Синьор - не всегда тот, кто писал сложные технологичные задачи
[00:56] 📉 Зарплата не показатель уровня синьора
[01:10] 📚 Опыт не всегда пропорционален зарплате
[01:23] 💼 Зарплата - не показатель опыта
[01:33] 💼 Синьор - не всегда старший разработчик
[02:48] 👥 Синьора определяет совокупность факторов
[03:05] 💡 Синьор плохо продавший себя, остается синьором
[03:34] 📊 Синьором можно быть с небольшим опытом
[03:48] 📈 Синьоры перед выполнением задачи собирают максимум информации
[04:31] 🕵️♂️ Сначала уточняйте требования у заказчика, чтобы не делать бесполезную работу.
[04:44] 💰Экономия времени и денег для бизнеса за счет поиска готовых решений и избегания "изобретения велосипеда".
[05:11] 💡Не спешите писать код, сначала обсудите детали задачи, чтобы учесть все крайние случаи.
[05:38] 🏁 Доводите каждую задачу до 100% завершения, без заглушек и отложенных дел.
[06:20] ✔️Выполняйте задачи полностью, чтобы не оставлять "технических долгов" и повышать доверие тимлида.
[07:00] 📚 Следуйте общепринятым и внутренним стандартам кода для повышения читаемости, расширяемости и поддерживаемости.
[08:11] 🛠Используйте плагины для анализа кода (например, sonar lint) для выявления и исправления ошибок.
[08:25] 📋 Документируйте свой код, чтобы облегчить его понимание для других разработчиков.
[08:40] 📝 Давайте понятные и описательные имена переменным, методам и классам.
[09:22] 🤖 Называй переменные понятно и по-нормальному, чтобы код был понятен и тебе самому, и команде.
[09:36] 🛡️ На собесах обращай внимание на названия переменных, даже если это тестовое задание. Это показывает твой навык именования.
[10:05] 💼 При ревью кода обращай внимание на названия классов и переменных. Плохой нейминг снижает читаемость кода.
[11:32] 🛡️ Синие разработчики дают завышенную оценку времени выполнения задач, чтобы заложить запас на непредвиденные обстоятельства.
[13:08] 🤖 Не бойся оценивать время выполнения задач с запасом, чтобы избежать оправданий и стресса.
[13:37] 💼 KISS (Keep it Simple, Stupid) - принцип минимализма в разработке: код должен быть максимально простым и понятным.
[13:50] 🇷🇺 Не усложняй код без надобности.
[14:18] 🇷🇺 Пиши код максимально просто, не вноси лишнюю сложность.
[14:31] 🇷🇺 Не рефлексируй, если это не твоя задача. Запиши в техдолг и вернешься к этому позже.
Made with HARPA AI
Круто! Вот ответочка от яндекс.спойлер ))
Как Senior-разработчики на САМОМ ДЕЛЕ пишут код
00:00 Введение в синер-программистов
• Определение синер-программиста вызывает споры.
• Опыт работы не всегда делает программиста синер.
• Задачи, которые решал программист, также важны.
01:24 Зарплата и опыт
• Зарплата не является единственным критерием синерности.
• Опыт и сложность задач важнее.
• Подготовка к собеседованию и умение продавать себя могут повлиять на зарплату.
02:34 Трудовая книжка и синерность
• Трудовая книжка не всегда отражает реальную синерность.
• Синерность определяется совокупностью факторов.
• Важно понимать принципы работы синер-разработчиков.
04:00 Принципы работы синер-разработчиков
• Синер-разработчики задают много вопросов перед началом работы.
• Они анализируют задачи и ищут готовые решения.
• Важно экономить время и деньги бизнеса.
05:33 Завершение задач
• Синер-разработчики завершают задачи на 100%.
• Они тестируют и документируют код.
• Это повышает престиж и доверие к разработчику.
06:56 Следование стандартам кода
• Важно следовать общепринятым и внутренним стандартам компании.
• Изучайте SOLID принципы и используйте плагины для форматирования кода.
• Документируйте код для его понимания и поддержки.
08:54 Правильное наименование переменных
• Используйте понятные и длинные имена для переменных и методов.
• Это облегчает ревью и понимание кода.
• На собеседованиях и в задачах обращайте внимание на названия переменных.
10:17 Важность читаемости кода
• Обращайте внимание на читаемость кода, это важно для команды и на собеседованиях.
• Примеры прохождения собеседований можно найти на Boost.
• Доступны бесплатные и платные консультации, а также групповые созвоны и личные консультации.
11:39 Правильная оценка задач
• Синие разработчики закладывают больше времени на выполнение задач, чем кажется на первый взгляд.
• Важно закладывать время на подводные камни, созвоны с аналитиком, написание тестов и документации.
• Тимлиды предпочитают предсказуемость, поэтому закладывайте максимальное количество времени сразу.
13:46 Принцип "Кис Кипд Симпл Стип"
• Не усложняйте код, избегайте сложных архитектур и абстрактных классов.
• Пишите код максимально просто, чтобы его могли понять джуны.
• Если хотите отрефакторить код, сначала обсудите это с тимлидом и занесите в техдолг.
14:45 Заключение
• Не пытайтесь отрефакторить код без необходимости, сначала выполните задачу.
• Если задача не стоит рефакторинга, не тратьте на это время.
• Подписывайтесь на канал для дальнейшего развития.
"даже когда задача всё-таки поставлена и её нужно решать, он не бросается делать её сразу" ведь эстимейты завышены в три раза минимум, можно пойти кофеек попить и вздрочнуть пару раз
То у синьора эта задача уже сделана 4 года назад, скопипастит решение
Какие еб_ть эстимейты? Ты че там под спиртом?
я почему-то сталкивался с обратной ситуацией, когда всё уже должно быть сделано еще вчера, несмотря на то что получил задачу только что...
@@fensrg от проекта зависит и от твоего положения в команде. "Все должно быть ещё вчера" не отменяет того что на задачу будут выданы какие-то эстимейты. Тут скорее зависит от тимлида и менеджера и на сколько они понимают/контролируют уровень трудозатрат. Тебе задачу ставят говорят надо срочно. Ты говоришь ой ребят тут Х и У и Й ещё проверить нужно будет, займет два дня. А на самом деле работы на 4 часа.
Зависит от компании далеко не везде можно заэстимейтить в три раза больше времени
Жалко что Senior'ы не вставляют тайм-коды в видео
Занят просто таской. На этапе тестирования еще. Надо понимать.
@@aduditsky ну это видео тоже когда-то было таской, а таски надо доводить до конца, как сказал автор видео
@@porloc а это хобби. Не таска. Хобби он может отложить, в свободное время доделать.
@@aduditsky task переводится как задача. Любое дело которое ты делаешь целенаправленно и спланировано это в любом случае - задача. Для каждого видео ведь пишется план, сценарий, делается съемочная часть (камера, свет, звук), монтаж, заливка. Кроме того ведение Ютуб канала, это тоже работа, с графиками и планами по выпускам. Это видео, как и остальные, не просто по наитию снималось. И тайм-коды на самом деле это простая задача, просто найти для каждой части плана соответствующие отрезки видео, и указать название из плана
Это поток сознания. Он непрерывен и тайм-коды не поддерживает
Сеньеры сотку жмут от груди судя по ведущему
Я мидл и жму 140 от груди на 5 раз 😅
@@mihinov ну, ты бэкенд наверное 🤣
@@VelikiyZmey я работаю фронтом 😅 Но могу и бекенд написать и CI/CD настроить
не факт, а вдруг приседания нужно делать
@@mihinov а 145 уже не можешь? нет, не пойдет. в джуны переведут.
У кого-то подсмотрел такое определение junior-middle-senior:
- Джуну надо ставить задачи и постоянно за ним приглядывать
- Миддл может работать самостоятельно
- Синьёр может ставить задачи другим.
Это тоже, конечно, довольно условное деление, но мне это определение легло на душу :)
А может ставит задачи другим Проект-Менеджер? 🙂
Я на первой своей работе тоже ставил задачи коллегам.
А затем, в течении около 10 лет, больше таким на занимался.
А все потому, что на первом проекте у нас не было Проект-Менеджера. 🙂
задачи ставит тим лид чаще, у одного тим лида может вся команда из синьоров
@@ARGAMX ПМ может в технике не шарить, потому задачи лучше ставить тим лиду
@@KostopravHD чем тогда ПМ занимается в таком случае?
Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером.
А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык.
Если раздачей задач занимается тех лид - то значит что в команде не настроено управление и делегирование.
@@KostopravHD чем тогда ПМ занимается в таком случае?
Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся, что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером.
А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык.
Если раздачей задач занимается тех лид - то значит что в команде не сформирован менеджмент, управление и делегирование.
Есть два стандарта кода: которого придерживаюсь я и всякое говно.
абсолютно верно!
это только у тех у кого опыта командной разработки нет.
@@TheDelwish это у всех д'Артаньянов. потому что для них все остальные - п..сы. как в анекдоте.
Скорее это стандарты для тех, у кого нет опыта разработки)
@@MrDarthat так у большинства сеньоров недоделанных нет опыта разработки. зато есть хождения по собесам и зубрежка алгоритмов и паттернов с методологиями.
У меня 20+ лет опыта, я сразу делаю задачу без вопросов бизнесу потому что знаю лучше них что им нужно
а потом переделывать идешь или сразу увольняют?
@@KostopravHD
Да нет, они только счастливы, что я за них уже все решил и им не пришлось стекхолдеров напрягать, хотя те тоже не знают. Я же не делаю другую функциональность, делаю заказанную, просто неосвещеные места сам уже проектирую. Ну и, с момента решения я их информирую, так что до момента реализации у них есть время внести изменения
Программист не обязан знать всё наизусть. Есть документация, которой нужно уметь пользоваться. Я работаю программистом более 25 лет, каждый раз задачи разные. Под каждую задачу изучается набор инструментов и потом уже она реализуется. Не факт что сразу получится и ты с первого раза все правильно сделаешь. Каждый пишет по своему.
Это никому никому из работодателей не объяснить. О ты не умеешь в SAP - ну ты нам не подходишь.
@@rybiizhir , ну для работодателя логично, он же тебя нанимает не для того, чтобы свои деньги тебе просто так отдавать. Он хочет нанять человека, который УЖЕ в теме.
в какой то момент становится плевать, что и на чем писать, базовые концепции всегда одни и те же, как в самих языках, так и в программах.
@@SeregaZinin а наниматель сам в теме?
@@SeregaZinin Ухты, а если про сап знает один-два человека, а остальным он вообще не вперся - значит, директор попал? Будет вынужден платить бешеные бабки этому счастливчику? Все определяется местом, временем и ценой услуги :)))))
Лайк, полписка, благодарю за видео, сохраню, хоть мне до синьëра еще далеко, но ты дельные советы дал 👍
Хочу добавить пару пунктов к всему вышесказанному:
- Реально решает опыт (не в конкретной технологии, а в разгребании дерьма вселенского масштаба по типу - "вот нам тут досталась система, с которой никто не знает как работать, и документации по ней нет особо. Нам нужен по ней стейджинг и внятный процесс по деплою доработок/фиксов")
- Умение брать на себя ответственность.
Senior-разработчик знает почти все правила хорошего кода, многократно нарушал их и понимает, к чему это приводит. Поэтому он рационально распределяет свои ресурсы.
Классное видео. Последняя часть про говнокод вообще порадовала)
Для себя как-то выработал следующие критерии уровня разработчика:
Джуну надо объяснять как делать задачу, контролировать выполнение, внимательно следить что он делает, обучать.
Мидл уже может сам понять задачу и выполнить её. Может сам разработать отдельный элемент системы или часть приложения. Мидл уже учится сам.
Сеньёр может поговорить с бизнесом, понять что ему надо, спроектировать системное решение и сам целиком его реализовать. Если он не знает какую-то технологию, то может сам разобраться, обучиться или найти того кто знает.
Плюсую, использую такие же критерии
@@AGalilov В моем понимание синьор в такой системе это чувак, который на вход получает бизнес проблему, а на выходе выдает решение, и соответственно поговорить с бизнесом в данном контексте это прояснить непонятные моменты, донести возможные негативные последствия решений и так далее. Аналитик в такой системе выполняет свою привычную роль сбора бизнес требований.
@@AGalilov а зачем аналист нужен? джунов к кастомерам запускают дефайнить все юзкейсы. обычная практика. даже заявляют, что джун должОн знать инглишь как родной, чтобы с кастомером общаться. так и делает большинство. результат как у йордана в пути камикадзе - провальный проект. все говорят, что читали, но все на тех же граблях пляшут.
@@Roman-ej3xg "с бизнесом говорить"? этим занимается project manager. а не программашка, пусть даже якобы сеньор. программашка может быть консультантом у проджект мэнеджера. еще джуна пошлите "с бизнесом говорить", как некоторые делают. срамота.
Не, на работает. Видел нескольких разрабов с годами опыта, что соответствуют критериям: способны развиваться, сами выполняют задачи и понимают, что нужно бизнесу. Но пишут код, как джуны. Непонятные переменные, все перегруженно, никакого солид, одни проектные знания, комитят то, что не комитется и так до бессконечности. Так что в видео более верно
Думаю, автор с такой рамой ушатает несколько тимлидов враз. Синьор однозначно ✔
Я мидл, у меня тощая комплекция, но 2-й кю по Айкидо, так что получается, если я его ушатаю, то не факт?))
@@Artem1s-_- а разве в айкидо есть чем то ушатывать там же нет ударов
зашел посмотреть как пишет сеньор, а в итоге мне говорят половину видео кто такой синьор
здравые мысли. Очень ценю их практичность и то, что вызваны они сугубо практическими причинами. Спасибо
На самом деле прям база базированная. Я практически со всем согласен. По поводу комментариев не очень понравилось. Я бы раскрыл мысль, что код, сложный для восприятия, лучше комментировать, но ребята на опыте пишут и так очень просто, чтобы джун мог разобраться, либо прыгнуть в процедуру, где класс или функция определены и там прочитать
Ясно, полезно, классно, кратко! Спасибо!
Все точно и по делу.
Подписался.
Рад, что нашел ментора, который может объяснить доступным языком решение "проблемных" мест в становлении высококачественным специалистом.
Спасибо за контент. Продолжай в том же духе👍
ну всё, теперь точно стану серьёром!!!
Хорошее видео, спасибо автору!
Напоминает дискуссию в кинофильме «Дежавю»: «Это синкопа или не синкопа?»
15:05 Я бы добавил, что если по ходу решения задачи, разбор кучки вонючего кода выйдет дешевле за счёт того, что его будет проще использовать и не городить обходных путей, то стоит эту кучку разобрать без создания тех-долга. Лида можно и предупредить, если куча достаточно большая.
Не всегда эти принципы применимы в реальной практике. Например, бывает так, что времени в обрез, что фича нужна заказчику уже вчера, а красиво, со всеми тестами, с документацией и без костылей писать код слишком долго. Тогда приходится делать, как успеваешь, а остальное кидать в тех. долг. Или вот на счет рефакторинга. Бывает садишься пилить таску в какой-нибудь легаси, но без рефакторинга это сделать просто невозможно или крайне больно. Проще потратить время на переделку, чем пытаться впихнуть костыли в плохо написанное.
В реальной практике да, абсолютно согласен. Видео из разряда «в идеале делать так…»
Так все равно рефачить IMO стоит после как минимум краткого обсуждения с Лидом о причинах сего действа. Поскольку этот говнокод работает и уже через qa прогнали. И чтоб потом не прилетело, кто у нас сборку порушил, чей комит сегодня самый лучший, стоит хотя б перед фактом поставить руководство… imo
@@КириллЧе-я5ы Понятное дело, что втихую такое не станешь делать. Все равно лид и другие разрабы будут в курсе, ведь от них апрувы нужны, чтобы вливаться в мастер. Подобное заранее обсуждается с командой и закладывается в оценку таски.
@@КириллЧе-я5ы костыли, которые пораждают другие костыли) если оценивал сам и не заложил в эстимейт рефакторинг - сам мудак. Если оценивал тимлид за тебя - соболезную) Всё это конечно идеализированно. На практике обычно получается либо мвп из круда смешанного с логикой и до реальных нагрузок все счастливы, либо что-то сложное которое в конечном итоге превратят в говнокод. Хороший проект может быть только если его архитектуру продумали правильно, в соответствии с бизнесом. И как только вы видите что вам нужно что-то рефакторить, значит либо вы пишите проект у которого начали меняться бизнес правила, либо изначально у вас неправильная архитектура и в том и в другом случае надо писать всё по новой. Но это в идеале, на практике вы просто набираете тех долг, и через какое-то время проект заканчивает свою жизнь)Бывают и промежуточные состояния))
@@MELkey3 бывают и промежуточные), особенно если этому проекту четверть века… и он до сих пор живее всех живых и периодически приходится что-то рефачить и надстраивать надстройки над старой архитектурой, поскольку староновое друг с другом практически не уживается))
Даже у бандарлогов есть своя иерархия :)
Что действительно отличает высокорангового разработчика от низкорангового, это умение смотреть в глаза и убеждать всех в своей компетентности.
убеждением занимаются архитекторы
Nice video mate! Straight to the point. Seniors just don't write code any more, you know how to Google, how to ask GPT and later modify a little bit and that's it. Of course discuss with business PM's PO's before. Wothout it nowhere. Thumbs up.
Ну на самом деле да, главное отличие синьера от всех остальных, это способность решать высокоуровневые задачи, с минимальной постановкой. И не просто решать, а правильно и эффективно. Остальное всё уже бантики
Документация улыбнуло ( в Германии только под страхом расстрела) все списывают на clean code;)
MyClass это Junior
Понять 10%
Залить 20%
Тест ручной 10%
Unit при покрытии в 90% 25%
35% документация, конфигурация, папки в системах клиента,,, и отдых
В проектах со сложным бизнесом типа мед страховок
Там где сложно: не задавать вопросов самое оно (ты же сеньор, все понятно) - все сложно, все обсуждается в ходе процесса
Там где легко: задавай вопросы, уточняй что-куда (ты же сеньор, вас на понт не взять)- все сложно, все обсуждается в ходе процесса
Итого: везде затянут процесс, зарплата капает. Не благодарите
прошел skyeng по фулстэку на html и питоне. Устроился лидом и говорю какие коды надо написать мидлам и синьорам. Задачи делаются в срок и все довольны
зп?
Ну,я работал старшим разрабом в трех конторах. Так меня не берут сейчас никуда, мол на джуна даже не тяну. Хотя, сложные ИИ проекты поднимаю с нуля. Сейчас не работаю, пишу статью на архив орг, медиум и готовлю презу по тому пооекту который разработал сам с нуля.
Есть выгорание какое-то. Я работал программистом 1С в течение 5 лет в нескольких конторах. Но потом решил почиллить на вольных хлебах. Теперь решил вернуться в разработку, только из-за появления ИИ. Что-то для себя создать. У вас что за проект и стек технологий ?
Картинам отдельный коммент. Они мегакрутые, притягивают внимание!
Как только услышал про зарплату, бросил смотреть и взялся кодить 😂
если 10 лет красил кнопочки - значит краш-синьор!
@@EvgeniyYatsenko примерно так)
Старший разработчик в Сбере это джун джун, ведущий это может быть junior+/middle главный это может быть middle/senior, самое главное твойГрейд
Сеньор разработчик, это который может и в проектирование архитектуры, и в производительность, и с какими-то узкими технологиями знаком, и джунам затрещину отвешает за кривой код (нетерпим к плохой архитектуре и плохому коду). Пожалуй, самый главный критерий - это владение бэст-практиксами (правильное проектирование, чистый код, юнит-тесты и пр.). Та или иная технология/фреймворк осваиваются без проблем. В какие-то нужно пару дней повтыкать, в какие-то пару месяцев, но глобально сложного ничего нет. Вчера ты не владел технологией Х, через две недели ты можешь лекции читать по технологии Х. Надо быть совсем уж тупым, чтобы не суметь освоить технологию Х. А вот к освоению бэст-практиксов приходят через 3-5-7-... лет практического опыта работы, кто-то вообще не приходит. Поэтому, на мой взгляд, умение в бэст-практиксы - главный критерий окукливания в сеньора
А пока вы все гусеницы 😅😅😅
Если он может в проетирование и организацию то это уже не кодер это уже архитектор или планировшик
hr, перелогинся
Для меня синьер в 1С это тот, кто свободно использует обработку Конвертация Данных. Если может делать отчеты с помощью СКД средние, это миддл.
почему мне слышится "синий разработчик" ))))
Ты не один ))
ахаха, а реально, все мои сеньоры бухают))
Ну в принципе да, нервная работа, без бухла никуда )))
Всё предельно просто. Синьор может в одно лицо решить задачу. Да, может с гуглом, но сам разберётся и сделает.
Миддл - решает, периодически прибегая к помощи коллег или синьора.
Джун не может без постоянных консультаций. Разжевали, сказали чо делать - делает. Code monkey.
Нет?
Смотря что понимать под словом задача
@@КоляКоронов-к9э под словом "задача" понимают поставленую задачу.
Кстати хороший критерий. На своем веку видел много кодеров. И что больше всего поразило, что очень многие не умеют пользоваться дебагером. Казалось бы элементарная вещь, но нет. Ну и очень многие вместо того что бы разобраться любят отрывать других от их задач. Вот эти особенно бесят.
@@dmaraptor Поставленную кем ? Заказчиком ? Продоктом ? СЕО ?
Так я сеньор/миддл+, получается? С олним неполным годом работы после вуза
Чет даже орнул с превьюшки видео))
Ии забыли, это бомба
Все перевернула, гугл это наше Прошлое
Я бы еще добавил, что синьор не соглашается на костыльные решения, когда выигрыш во времени - пара дней
В общем согласен, но не всё так однозначно.
Для проверки каких-то вещей нет смысла делать полноценный билд с оптимизацией.
лайк за адекватность
Блин, вот с первой частью, кто такие сеньёры прям странно вышло, то по правилам - отлично! Из этих правил рождается простой критерий - сеньёр думает масштабом бизнеса. Мидл - архитектуры решения. Джун - локальным решением здесь и сейчас. Под "думает" не сидит и философствует, мол, а хорошо бы прикрутить фичу, которая круто выглядит. А именно, "как предсказуемо решить проблему бизнеса".
И да, навык кодинга важен, но если ты головой сеньёр, то навыки наработаются быстро. Если ты головой джун, то знай хоть 500 фреймворков и умей с закрытыми глазами сделать красно-чёрное дерево да развёртывай хадуп в перерывах между красным и рыжим ютубом, всё равно ты джун. Хотя сложно знать столько фреймворков и не думать архитектурой приложения, но практика показывает, что есть и бывают такие люди)
Все они кодеры
имхо сеньор это тот кто на работе не хочет писать код и максимально избегает этого ) джину они сразу пишут и думают чем больше кода они напишут, тем лучше. но все с точности до наоборот
По-факту что джун, что синьор просто кодеры. Если держишь весь проект и решаешь все, это руководитель проекта или архитектор.
я квесто-скриптер "корсаров" . это круто
8:45 Не так давно столкнулся с кодом, коммантарии есть, а смысла нет, давно утерян, за аремя после написания комментария код правился множество раз и комментарий не соответствовал функционалу от слова совсем... Поэтому код должен документировать себя сам!
То что комментарии написан к старому коду, это проблема не комментария, а того кто его писал.
Самадокументирующий код + понятный комментарии и минимально написанная документация, залог хорошего и понятного кода
@@x-grand-x нет, это не проблема того кто писал коммент, это проблема того, кто будет править код... а создал эту проблему тот, кто не обновил коммент!
@@fensrg сложные будние программистов. Соглашусь)
ни разу не писал тесты и не комментировал свой код. а еще отправляю задачу в qa с багами и заглушками, потому что сроки. все работодатели очень довольны и не хотят отпускать, зп 500к
ни разу не писал тесты, отправляю задачу в прод в багами и заглушками, потому что "ну а хули нет". все довольны. очень. зп 700к.
Ни разу не писал код, могу только заходить в зум и слушать. Зп 1,5 ляма
@@aki7162 пм?
@@aki7162 пм?
@@aki7162 давно продактом работаешь?
Если слюна не течет и помнит как его зовут, то это синьор обычно
Спасибо за отличное видео
Приветствую автора! Давно интересует вопрос - кто устанавливает время на выполнение задачи для джуна (он сам или тот кто дает задачу), и какие сроки являются средними? Просто побаиваюсь, что если попросить, например, пару дней, то на меня вылупят глаза и зачмырят за то, что мне нужно столько времени на тукую простую задачу (а я еще не умею реально оценивать время, которое мне потребуется). Заранее спасибо!
Смотри, если ты официально джун на позиции джуна, то ожидать от тебя точных эстимейтов никто не будет (при условии что все адекватные вокруг) говори сколько чувствуешь, если не так то тебя поправят, а с опытом поймёшь как нужно. Не забывай что 99% задач слоднее чес кажется и времени уйдет куда больше. А те задачи которые ты точно знаешь и умеешь - ну если знаешь то ставь как знаешь.
В разных компаниях ещё есть всякие приколы в зависимости от специфики. Где-то эстимейты ставит тимлид+аналитик, где-то играют в покер, это когда несколько человек заптсывают "в закрытую" сколько времени задача займет а потом "вскрываются" одновременно. Тех кто написал самое маленькое и самое большое просят пояснить, может есть решение которое они знают или есть подводные которые никто не заметил, а потом на основании этого выбирают средний эстимейт. Это делается чтобы нельзя было завышать жстимейты и потом пинать хер, всех разом подговорить почти невозможно.
В общем и целом проблема - занизить эстимейты, по тому что не успеешь сделать. Завысить немного и сдать раньше - это не плохо. Завысить сильно тебе скорее всего не дадут. Да и если задача занимает несколько дней по твоему (особенно на джуна) то можно предложить её декомпозировать, это тоже норм, мол разбить на таски по меньше
@@ВысоцкийАндрей-г5э Спасибо за развернутый ответ! Пока еще официально безработный, учусь)) Но вопросы, похожие на заданный, разумеется, беспокоят.
лучше оговаривай время с запасом, чем каждый раз сдигай сроки. нужно понимать зачем сеньоры с тебя спрашивают время. никто не думают о чмырении, думают о планах выполнения, чтобы уложиться в сроки (ибо задач много, где есть блокеры, где-то нет). важное правило это быть предсказуемым. и лучше сразу уточнить, по естимейтам, т.е. идеально сказать, есть несколько вариантов подхода решения задачи - 1) быстрый день -два, но такие вот негативные последствия 2) неделя, но зато вот это вот
не ссы , ты не поверишь но у меня в команде все сеньоры 6+ лет опыта не умеют оценивать задачи и даже в открытую говорят, что хз скок делать будет о времени. если нет сроков от бизнеса то вообще п ох ер
А fullstack разрабочик наверно должен быть вообще богом. Ну как же... Он столько много языков знает. Многие в C++ плюхаются, а фулстек девелоперу вообще норм.
имхо.тех долг это нормально. кладется в бэклог и берется в следующем спринте. бизнесу нужны фичи и если "заглушка" позволяет фиче отвечать требованиям она должна заехать на прод.
Не кантрол, а контрол альт дел. И нажимать их не надо, всегда есть Галочка, форматировать при сохранении. Оптимизировать импорты и пр. Сеньор отличается тем, что умеет не делать лишнего и за ним нет шлейфа из косяков.
В идеале, просто взять vim, и вынос блока в отдельную функцию будет занимать пол секунды а не минуту
Прохожу вход в it такой же как и у Евгения. Первая работа в it тоже в Сбере. Правда в трудовой написали что я аналитик😅
Хотя по факту backend-разработчик
Прошел год и хочется двигаться дальше.
Евгений, что делать, если ты хочешь расти по ЗП? Кто-то советует, учитывая специфику Сбера искать другого работодателя, а кто-то пытаться через контроффер попытаься остаться и выбить условия лучше
Что думаешь по этому поводу?
Существенное повышение зп только через смену работы. Контроффер это плохая практика. Со сбером врятли прокатит вообще, но если и прокатит, то появятся завышенные к тебе требования и ожидания, и ты станешь первым кандидатом на замену в случае чего.
@Evg_Af спасибо за ответ! Пойду тогда откликаться😄
Для постановки задачи есть аналитики, для тестирования тестировщики, для разворота кластера чего угодно есть девопсы.
а если увидел точно супер критичную ошибку (что обанкротит компанию) в не своем коде, то тоже оставить и дать катастрофе случиться, чтобы идти спрашивать что делать у тимлида?
Вы фантазируете
Я 10 лет крудошлеплю, делаю сложную бизнеслогику.
Я бы посоветовал книгу Чистая Архитектура
Это больше похоже на навыки мидла над которым стоит контролирующий тимлид. От серьера у нас ждут максимальный опыт, обычно это чувак который наступил на все грабли и знает наилучшее решение.
По-моему senior больше понимает как все работает и критерии выбора. Типа почему тут такая архитектура, почему кафка, почему pgsql, а не mysql. И он способен объяснить почему то что он выбрал правильно, а не "всегда так делали и работало".
Так выбирает не он выбирает архитектор на основе тз
@@КоляКоронов-к9э видимо зависит от организации. Я видел что архитектор в основном красивые диаграммы рисует, но не выбирает. Тк для выбора нужно сделать прототип и провести нагрузочное тестирование, чтоб выбирать не от балды, а он не может
@@tsc472 В целом если это архитектор а не планировщик то он должен мочь в соляного вытянуть проект Вот только архитектор это дорого а сениор несколько дешевле А как мы помним экономика должна быть экономной
Выглядит как пересказ книги "Идеальный программист" Роберта Мартина)
я закончил курсы за 3 месяца, сейчас я сеньор
реальный опыт лет 10 суммарно
так что дерзайте, у вас получится тоже
А что вам мешало до курсов(с 10 летним реальным опытом)стать сеньором?
@@bmerlin2010 отсутствие опыта
Хороший рофл автора канала) За 3 месяца с 0 стал сеньором, но 2 года обучал программированию)))
закончил курсы 3 месяца назад,и стал сеньором
Я думаю он имел ввиду, что до того как начал работать за 3 месяца прошел курсы и сейчас, спустя 10 лет стал сеньором
Нет, это все истории не про сениора. Это миддилы. Слово senior обозначает "зрелый", с не "опытный". Я пока нащупал два критерия, которые показывают именно ментальную зрелость, а не тезническую. Так, например, расстановка приоритетов от бизнеса, а не от качества кода - первое. Сениор не будет ультимативно следовать тому же DRY потому что он плчтив сегда больше врежа приносит.
Второе - он обучает других людей (жто лучше формиоует ешо собственную базу).
В России очень мало программистов с классическим образованием, оисюда и отсутствие синьоров и мидлы и джуны, считающие себя "профи". Читаю резюме - толпы девчулек, купивших какой-то курс на пол-года и поработавших подносяиком кофе в компании-интеграторе, в итоге все надписи какие запомниди - переписаны в резюме с пометкой " внедряла, разработала, щадачи кодераи ставила". А простейшие вещи, которые должен знать любой грамотный программист - этого мы не знаем. Сортирлвка на основе бинарного дерева - нас пугает, теория баз данных - "ну я же другим занимаюсь", скуль - а что это? В общем ужас...
Мне больше интересно, чем думают работодатели, которые ещё и нос воротят от программистов старой школы _любого_ возраста.
@Encrouter а всё просто, верят просто.. молодые же как сейчас... посидеди рядом с аналитиком и в резюме пишут "работал аналитиком, опыт 2 года, проект на 1500 армов" и за прлсят как опытный - а в голове ни-че-го (пара гениев была за всё время, прочие - мусор). Молодые верят, что за 2 месяца старовятся профи и гонору у них ппц сколько
@@mix5457 Ну ничего, касса 5-ки большинство исправит.
А некоторые может в процессе работы действительно чему-то научатся.
@@Encrouter беда в том, чтл их берут на работу и эти ребята потом с умным видом....
@@mix5457 Ни на что не способны при работе над реальными задачами ? :D
норм воды налил 👍
Лайков набрал))
видели бы вы исходники. Бог монтажа слил большую часть воды, оставил так, лужицу...))
Еще раз про переменные можно? ) А в целом, толковый список Благодарю за работу
судя попревью, сеньоры генерируют html код прямо из bash'a .
Интересно, а автор то откуда знает, как сениор разработчики код пишут ?
Вот я автоматизатор (язык ST) и всё что говорится - я это прям всецело понимаю и принимаю. То есть это справедливо и для АСУ-ТП (на ST, ибо остальные "языки" МЭК это не языки, если кратко)
Principal engineer -это senior?
Ну, конечно же нет! Откуда вы все повылазили?! Principal engineer - это просто очень принципиальный инженер.
Привет а было ли у тебя выгорание когда ничего не хочется делать но это не лень? Если да то как боролся с этим ?
@@sammygun84 было. Ничего не делал. Буквально. Не работал. Когда деньги начали кончаться выгорание быстро прошло.
@@Evg_Af Спасибо за ответ)
@@Evg_Af А еще интересно как ты борешься, или как бороться с такими ситуациями к примеру тебе дают задачу менеджер считает что она на 2-3 дня работы, однако при работе с данной задачей всплывают куча нюансов про которые вообще никто не знал, в результате задача затягивается на 2 недели. При этом менеджер начинает негодовать как это так почему она затянулась он не технический специалист и до конца не понимает всех нюансов при этом начинает тебя оценивать, что типо что ты за специалист почему так медленно все делаешь)? При этом тебе никто не дает возможность изначально оценить сколько времени понадобиться на данную задачу. Да и когда тебя начинают оценивать как специалиста это довольно неприятно. Были ли у тебя такие ситуации как с ними справлялся?
Сколько жим лёжа на 12 раз и разовый максимум?
@@vladislav262626 на 12 будет 90-95. На раз не знаю, у меня дома своя качалка, там максимум 108 повесить могу, на 5 раз сделаю))
Респект за чёткое изложение материала, практически без воды.
У нас в компании я ввел понятие «капролит» - это очень старый говнокод 😊
копролит. и это не твоя выдумка, а старый времен лурка и жж термин, который и я и все мои коллеги в разных конторах использовали.
@@TheDelwish Прикольно )). Значит совпало )
Ты сначала писать без ошибок научись, вводитель.
А кто такой principal software engineer?
Насчет 2го пункта не соглашусь, не бывает такого. Когда пишется функционал по коду проставляются кучи TODO, т.к. эти места могут за собой потянуть такоооооее которое не влезет ни в какую оценку. Аналогично с тестами, тебе дают время только на поверхностные. И только потом, и то может быть, будет этап выполнения тудушек и детальных тестов... Задача должна быть выполнена на столько - сколько требуется бизнесу, но на уровне кода явно не будет даже 80процентов...
У меня на счет некоторых утверждений другое мнение. Как человек в 25 годами опыта скажу, синьёр это опора лида, которой можно поручить задачу и он в состоянии понять на какой уровень нужно вывести её решение. Поясню. Вот эти все "Выполнить до конца", это не из жизни. Так вы никогда не представите функционал бизнесу в срок(если вообще представите). Нужно уметь проводить четкую грань, где пора заканчивать с идеализмом и начинать делать задачу. Если в равных условиях дать задачу Синьёру и Мидлу, мидл обязательно сорвет срок, и не потому что у него меньше опыта(тоже фактор), а потому, что попытается комплексно закрыть задачу без оглядки на последствия, т.к. не имеет опыта оценки целесообразности в текущий момент.
Бизнесу плевать на всякие тех долги и качество кода. Оценка приоритетов всегда следующая:
1. Предоставление результатов бизнесу.
2. Недопущение критических ошибок.
3. Закладывание тех долга в канву архитектуры(Это когда ты делаешь временное но быстрое решение, которое в последствии не придется полностью переписывать).
4. Решение тех долга.
Обратите внимание, что Недопущение критических ошибок имеет меньший приоритет по сравнению с Предоставлением результатов.
Следование этим простым правилам продержит проект на плаву долгие годы. В противном случае проекту хана.
Очень глупо гнаться за сроками, потом придётся выбросить огрызок и переписывать из-за множества причин.
Взять ту же масштабируемость. Она невозможна без оптимизации, причем желательно на стадии проектирования.
Погоня за сроками никогда не приводит к хорошему - ну погляди на хрущевки панельные, их сдавали даже с опережением графика ) А потом на сталинки посмотри.
В начала послышалось: синий разработчик 🤣
И второй момент, как можно задачу выполнить на 100%, не бывает так, ты вроде как всё сделал, вроде как работает, но в конце появляются идеи по улучшению кода, и оно зараза не заканчивается, у кого было такое?
Да миллион раз и всяко.
Как-то уперлись рогом - нужны инструкции по работе. Херня вопрос - все сделал со скриншотами, как комиксы для детей. И все равно они где-то сделали херню, и получили не тот результат. Говорят - не работает :D
Идоры! То есть ироды. Я беру на их глазах делаю по инструкции - нужный результат получен )
здравствуйте, хочу задать небольшой вопрос есть ли смысл записывать функции или какие-то примеры кода в тетрадку и потом это учить и запоминать
С if или for прокатит ещё но когда функция хотябы на 50 строк... и да пример кода на видео был написан за минуты 3, с помощью помощника от компилятора, а ручками писать минут 10.
@dbmongo9732 как зачем? на собесе могут спросить программашки. их чему учили - они то и спрашивают. например. алгоритмы сортировки. они думают. что лучше их реализуют, чем, например, это сделано в том же oracle или любой другой субд. не ответишь - не возьмут. так что зубрить надо. много и все. и по собесам шастать. вечным студентом.
@@KlausDrown помошника от компилятора нет это иде
@@КоляКоронов-к9э оговорился, извеняюсь.
должен всё спросить, затем скормить полученную информацию GPT4 и выдать готовый ответ через 5 минут
Фильм был, старенький... Инженера приглашали сделать реверс новейшей технологии, платили бешеные бабки и по окончанию проекта стирали память!! Думаю, как тебя в сбер занесло? Синьер это должность, что удобно для конторы. А программист - это призвание, ярлык на всю жизнь!! В конце фильма, инженер сломал стереотип и начал думать своей головой и жить для себя ...!
Когда в доте наиграл высокий рейтинг и понял что теперь уже синиор 😅
Если разраб (синюор или нет) задает милион вопросов по задаче, значит задачу поставил джун
сеньор
- В феодальном обществе: землевладелец с властью государя на своей территории.
я вот только синьора помидора знаю из "Чиполлино"
сколько раз он сказал "синьяр"?
Если не стал сеньером за 2 года опыта, то уже никогда не станешь. Останешься джуном с 10 годами опыта.
На моменте про вопросы аналитикам/заказчикам немного тормознул просмотр. Ну, на собеседовании - пожалуй, но не в работе. Сейчас многие издадут усталый стон, но я скажу.
На проекте должна быть качественная документация.
Чтобы каждый раз каждому сотруднику не бегать куда-то, не дёргать кого-то по поводу, а как должно выглядеть/работать вот это? ОК, идеальной документации не бывает. Вопросы будут. Но первым делом всё-таки надо смотреть доки, а не сразу бежать расспрашивать. И если в них есть пробелы, то уже тогда хватать аналитика, бомбардировать вопросами и заставлять прописывать. Не просто ответить, а прописывать. Прописывать в документации. Качественным текстом. И зафиксировать факт правки. В присутствии свидетелей с других направлений.
(Извините, немного гиперболизировал, но наболело)
И я намеренно писал "сотрудник", а не "разработчик". Документация используется всеми. По ней будут писать гайды для пользователей и техподдержки, по ней разрабы пишут код, по ней тестеры проверяют продукт, по ней тимлиды и PM'ы планируют работу команд.
1с - > java -> инфо цыган -> влад МИШУСТИН 😂
Как вам лямбда выражение?
саксесс стори!)
идеально!
Старший иженер/разраб в сбере это позиция джун-
От сеньора плавно перешли на базовые терминологии, стандарты, спецификации... Про сеньора мало что сказано.
В сбере😆
Старший - джун
Ведущий - мидл
Главный - сеньор
Все лучше чем этот наш англоязычный новояз. Middle, little и adult. Не названия, а какие-то тэги с порнхаба.
У нас, конечно, в аудите, зарплаты не айтишные, но деление почти такое. Только специалист (не осталось в СВА), ведущий специалист, эксперт и главный эксперт
ну тогда я Senior-разработчик
Поздравляю! ) Теперь осталось только прибавить уверенности )
По поводу похода к бизнесу - не лишку для синьёра? Разве не лиды общаются с бизнесом?
Вот бы все синиоры программисты кластеры разворачивали, особенно если пишешь под мобилки
так всё.. походу я синьор>))
Звучит как синий разработчик😊