"даже когда задача всё-таки поставлена и её нужно решать, он не бросается делать её сразу" ведь эстимейты завышены в три раза минимум, можно пойти кофеек попить и вздрочнуть пару раз
@@fensrg от проекта зависит и от твоего положения в команде. "Все должно быть ещё вчера" не отменяет того что на задачу будут выданы какие-то эстимейты. Тут скорее зависит от тимлида и менеджера и на сколько они понимают/контролируют уровень трудозатрат. Тебе задачу ставят говорят надо срочно. Ты говоришь ой ребят тут Х и У и Й ещё проверить нужно будет, займет два дня. А на самом деле работы на 4 часа.
@@aduditsky task переводится как задача. Любое дело которое ты делаешь целенаправленно и спланировано это в любом случае - задача. Для каждого видео ведь пишется план, сценарий, делается съемочная часть (камера, свет, звук), монтаж, заливка. Кроме того ведение Ютуб канала, это тоже работа, с графиками и планами по выпускам. Это видео, как и остальные, не просто по наитию снималось. И тайм-коды на самом деле это простая задача, просто найти для каждой части плана соответствующие отрезки видео, и указать название из плана
@@MrDarthat так у большинства сеньоров недоделанных нет опыта разработки. зато есть хождения по собесам и зубрежка алгоритмов и паттернов с методологиями.
Программист не обязан знать всё наизусть. Есть документация, которой нужно уметь пользоваться. Я работаю программистом более 25 лет, каждый раз задачи разные. Под каждую задачу изучается набор инструментов и потом уже она реализуется. Не факт что сразу получится и ты с первого раза все правильно сделаешь. Каждый пишет по своему.
@@rybiizhir , ну для работодателя логично, он же тебя нанимает не для того, чтобы свои деньги тебе просто так отдавать. Он хочет нанять человека, который УЖЕ в теме.
@@SeregaZinin Ухты, а если про сап знает один-два человека, а остальным он вообще не вперся - значит, директор попал? Будет вынужден платить бешеные бабки этому счастливчику? Все определяется местом, временем и ценой услуги :)))))
🎯 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 Заключение • Не пытайтесь отрефакторить код без необходимости, сначала выполните задачу. • Если задача не стоит рефакторинга, не тратьте на это время. • Подписывайтесь на канал для дальнейшего развития.
Все точно и по делу. Подписался. Рад, что нашел ментора, который может объяснить доступным языком решение "проблемных" мест в становлении высококачественным специалистом. Спасибо за контент. Продолжай в том же духе👍
У кого-то подсмотрел такое определение junior-middle-senior: - Джуну надо ставить задачи и постоянно за ним приглядывать - Миддл может работать самостоятельно - Синьёр может ставить задачи другим. Это тоже, конечно, довольно условное деление, но мне это определение легло на душу :)
А может ставит задачи другим Проект-Менеджер? 🙂 Я на первой своей работе тоже ставил задачи коллегам. А затем, в течении около 10 лет, больше таким на занимался. А все потому, что на первом проекте у нас не было Проект-Менеджера. 🙂
@@KostopravHD чем тогда ПМ занимается в таком случае? Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером. А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык. Если раздачей задач занимается тех лид - то значит что в команде не настроено управление и делегирование.
@@KostopravHD чем тогда ПМ занимается в таком случае? Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся, что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером. А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык. Если раздачей задач занимается тех лид - то значит что в команде не сформирован менеджмент, управление и делегирование.
Senior-разработчик знает почти все правила хорошего кода, многократно нарушал их и понимает, к чему это приводит. Поэтому он рационально распределяет свои ресурсы.
Для себя как-то выработал следующие критерии уровня разработчика: Джуну надо объяснять как делать задачу, контролировать выполнение, внимательно следить что он делает, обучать. Мидл уже может сам понять задачу и выполнить её. Может сам разработать отдельный элемент системы или часть приложения. Мидл уже учится сам. Сеньёр может поговорить с бизнесом, понять что ему надо, спроектировать системное решение и сам целиком его реализовать. Если он не знает какую-то технологию, то может сам разобраться, обучиться или найти того кто знает.
@@AGalilov В моем понимание синьор в такой системе это чувак, который на вход получает бизнес проблему, а на выходе выдает решение, и соответственно поговорить с бизнесом в данном контексте это прояснить непонятные моменты, донести возможные негативные последствия решений и так далее. Аналитик в такой системе выполняет свою привычную роль сбора бизнес требований.
@@AGalilov а зачем аналист нужен? джунов к кастомерам запускают дефайнить все юзкейсы. обычная практика. даже заявляют, что джун должОн знать инглишь как родной, чтобы с кастомером общаться. так и делает большинство. результат как у йордана в пути камикадзе - провальный проект. все говорят, что читали, но все на тех же граблях пляшут.
@@Roman-ej3xg "с бизнесом говорить"? этим занимается project manager. а не программашка, пусть даже якобы сеньор. программашка может быть консультантом у проджект мэнеджера. еще джуна пошлите "с бизнесом говорить", как некоторые делают. срамота.
Не, на работает. Видел нескольких разрабов с годами опыта, что соответствуют критериям: способны развиваться, сами выполняют задачи и понимают, что нужно бизнесу. Но пишут код, как джуны. Непонятные переменные, все перегруженно, никакого солид, одни проектные знания, комитят то, что не комитется и так до бессконечности. Так что в видео более верно
@@KostopravHD Да нет, они только счастливы, что я за них уже все решил и им не пришлось стекхолдеров напрягать, хотя те тоже не знают. Я же не делаю другую функциональность, делаю заказанную, просто неосвещеные места сам уже проектирую. Ну и, с момента решения я их информирую, так что до момента реализации у них есть время внести изменения
На самом деле прям база базированная. Я практически со всем согласен. По поводу комментариев не очень понравилось. Я бы раскрыл мысль, что код, сложный для восприятия, лучше комментировать, но ребята на опыте пишут и так очень просто, чтобы джун мог разобраться, либо прыгнуть в процедуру, где класс или функция определены и там прочитать
Ну на самом деле да, главное отличие синьера от всех остальных, это способность решать высокоуровневые задачи, с минимальной постановкой. И не просто решать, а правильно и эффективно. Остальное всё уже бантики
Сеньор разработчик, это который может и в проектирование архитектуры, и в производительность, и с какими-то узкими технологиями знаком, и джунам затрещину отвешает за кривой код (нетерпим к плохой архитектуре и плохому коду). Пожалуй, самый главный критерий - это владение бэст-практиксами (правильное проектирование, чистый код, юнит-тесты и пр.). Та или иная технология/фреймворк осваиваются без проблем. В какие-то нужно пару дней повтыкать, в какие-то пару месяцев, но глобально сложного ничего нет. Вчера ты не владел технологией Х, через две недели ты можешь лекции читать по технологии Х. Надо быть совсем уж тупым, чтобы не суметь освоить технологию Х. А вот к освоению бэст-практиксов приходят через 3-5-7-... лет практического опыта работы, кто-то вообще не приходит. Поэтому, на мой взгляд, умение в бэст-практиксы - главный критерий окукливания в сеньора
ни разу не писал тесты и не комментировал свой код. а еще отправляю задачу в qa с багами и заглушками, потому что сроки. все работодатели очень довольны и не хотят отпускать, зп 500к
Ну,я работал старшим разрабом в трех конторах. Так меня не берут сейчас никуда, мол на джуна даже не тяну. Хотя, сложные ИИ проекты поднимаю с нуля. Сейчас не работаю, пишу статью на архив орг, медиум и готовлю презу по тому пооекту который разработал сам с нуля.
Есть выгорание какое-то. Я работал программистом 1С в течение 5 лет в нескольких конторах. Но потом решил почиллить на вольных хлебах. Теперь решил вернуться в разработку, только из-за появления ИИ. Что-то для себя создать. У вас что за проект и стек технологий ?
Даже у бандарлогов есть своя иерархия :) Что действительно отличает высокорангового разработчика от низкорангового, это умение смотреть в глаза и убеждать всех в своей компетентности.
В России очень мало программистов с классическим образованием, оисюда и отсутствие синьоров и мидлы и джуны, считающие себя "профи". Читаю резюме - толпы девчулек, купивших какой-то курс на пол-года и поработавших подносяиком кофе в компании-интеграторе, в итоге все надписи какие запомниди - переписаны в резюме с пометкой " внедряла, разработала, щадачи кодераи ставила". А простейшие вещи, которые должен знать любой грамотный программист - этого мы не знаем. Сортирлвка на основе бинарного дерева - нас пугает, теория баз данных - "ну я же другим занимаюсь", скуль - а что это? В общем ужас...
Там где сложно: не задавать вопросов самое оно (ты же сеньор, все понятно) - все сложно, все обсуждается в ходе процесса Там где легко: задавай вопросы, уточняй что-куда (ты же сеньор, вас на понт не взять)- все сложно, все обсуждается в ходе процесса Итого: везде затянут процесс, зарплата капает. Не благодарите
Джун - обладает базой, способен выполнять базовые задачи. Не самостоятелен, зависим от мидла. Мидл - обладает базой, выполняет помимо базовых задач ещё и задачи средней сложности в которых нужно проводить анализ для решения проблемы. Управляет и натаскивает прикреплённого мидла. Синьор - обладает знаниями прилично шире своей области. Способен решать сложные и крайне сложные задачи которые не по зубам мидлам.
Хочу добавить пару пунктов к всему вышесказанному: - Реально решает опыт (не в конкретной технологии, а в разгребании дерьма вселенского масштаба по типу - "вот нам тут досталась система, с которой никто не знает как работать, и документации по ней нет особо. Нам нужен по ней стейджинг и внятный процесс по деплою доработок/фиксов") - Умение брать на себя ответственность.
Блин, вот с первой частью, кто такие сеньёры прям странно вышло, то по правилам - отлично! Из этих правил рождается простой критерий - сеньёр думает масштабом бизнеса. Мидл - архитектуры решения. Джун - локальным решением здесь и сейчас. Под "думает" не сидит и философствует, мол, а хорошо бы прикрутить фичу, которая круто выглядит. А именно, "как предсказуемо решить проблему бизнеса". И да, навык кодинга важен, но если ты головой сеньёр, то навыки наработаются быстро. Если ты головой джун, то знай хоть 500 фреймворков и умей с закрытыми глазами сделать красно-чёрное дерево да развёртывай хадуп в перерывах между красным и рыжим ютубом, всё равно ты джун. Хотя сложно знать столько фреймворков и не думать архитектурой приложения, но практика показывает, что есть и бывают такие люди)
В начала послышалось: синий разработчик 🤣 И второй момент, как можно задачу выполнить на 100%, не бывает так, ты вроде как всё сделал, вроде как работает, но в конце появляются идеи по улучшению кода, и оно зараза не заканчивается, у кого было такое?
имхо сеньор это тот кто на работе не хочет писать код и максимально избегает этого ) джину они сразу пишут и думают чем больше кода они напишут, тем лучше. но все с точности до наоборот
Это больше похоже на навыки мидла над которым стоит контролирующий тимлид. От серьера у нас ждут максимальный опыт, обычно это чувак который наступил на все грабли и знает наилучшее решение.
имхо.тех долг это нормально. кладется в бэклог и берется в следующем спринте. бизнесу нужны фичи и если "заглушка" позволяет фиче отвечать требованиям она должна заехать на прод.
Не всегда эти принципы применимы в реальной практике. Например, бывает так, что времени в обрез, что фича нужна заказчику уже вчера, а красиво, со всеми тестами, с документацией и без костылей писать код слишком долго. Тогда приходится делать, как успеваешь, а остальное кидать в тех. долг. Или вот на счет рефакторинга. Бывает садишься пилить таску в какой-нибудь легаси, но без рефакторинга это сделать просто невозможно или крайне больно. Проще потратить время на переделку, чем пытаться впихнуть костыли в плохо написанное.
Так все равно рефачить IMO стоит после как минимум краткого обсуждения с Лидом о причинах сего действа. Поскольку этот говнокод работает и уже через qa прогнали. И чтоб потом не прилетело, кто у нас сборку порушил, чей комит сегодня самый лучший, стоит хотя б перед фактом поставить руководство… imo
@@КириллЧе-я5ы Понятное дело, что втихую такое не станешь делать. Все равно лид и другие разрабы будут в курсе, ведь от них апрувы нужны, чтобы вливаться в мастер. Подобное заранее обсуждается с командой и закладывается в оценку таски.
@@КириллЧе-я5ы костыли, которые пораждают другие костыли) если оценивал сам и не заложил в эстимейт рефакторинг - сам мудак. Если оценивал тимлид за тебя - соболезную) Всё это конечно идеализированно. На практике обычно получается либо мвп из круда смешанного с логикой и до реальных нагрузок все счастливы, либо что-то сложное которое в конечном итоге превратят в говнокод. Хороший проект может быть только если его архитектуру продумали правильно, в соответствии с бизнесом. И как только вы видите что вам нужно что-то рефакторить, значит либо вы пишите проект у которого начали меняться бизнес правила, либо изначально у вас неправильная архитектура и в том и в другом случае надо писать всё по новой. Но это в идеале, на практике вы просто набираете тех долг, и через какое-то время проект заканчивает свою жизнь)Бывают и промежуточные состояния))
@@MELkey3 бывают и промежуточные), особенно если этому проекту четверть века… и он до сих пор живее всех живых и периодически приходится что-то рефачить и надстраивать надстройки над старой архитектурой, поскольку староновое друг с другом практически не уживается))
15:05 Я бы добавил, что если по ходу решения задачи, разбор кучки вонючего кода выйдет дешевле за счёт того, что его будет проще использовать и не городить обходных путей, то стоит эту кучку разобрать без создания тех-долга. Лида можно и предупредить, если куча достаточно большая.
Всё предельно просто. Синьор может в одно лицо решить задачу. Да, может с гуглом, но сам разберётся и сделает. Миддл - решает, периодически прибегая к помощи коллег или синьора. Джун не может без постоянных консультаций. Разжевали, сказали чо делать - делает. Code monkey. Нет?
Кстати хороший критерий. На своем веку видел много кодеров. И что больше всего поразило, что очень многие не умеют пользоваться дебагером. Казалось бы элементарная вещь, но нет. Ну и очень многие вместо того что бы разобраться любят отрывать других от их задач. Вот эти особенно бесят.
По-моему senior больше понимает как все работает и критерии выбора. Типа почему тут такая архитектура, почему кафка, почему pgsql, а не mysql. И он способен объяснить почему то что он выбрал правильно, а не "всегда так делали и работало".
@@КоляКоронов-к9э видимо зависит от организации. Я видел что архитектор в основном красивые диаграммы рисует, но не выбирает. Тк для выбора нужно сделать прототип и провести нагрузочное тестирование, чтоб выбирать не от балды, а он не может
@@tsc472 В целом если это архитектор а не планировщик то он должен мочь в соляного вытянуть проект Вот только архитектор это дорого а сениор несколько дешевле А как мы помним экономика должна быть экономной
Фильм был, старенький... Инженера приглашали сделать реверс новейшей технологии, платили бешеные бабки и по окончанию проекта стирали память!! Думаю, как тебя в сбер занесло? Синьер это должность, что удобно для конторы. А программист - это призвание, ярлык на всю жизнь!! В конце фильма, инженер сломал стереотип и начал думать своей головой и жить для себя ...!
Я: опыта 0, закончил курсы от скилбокса, накрутил фэйкового опыта, зазубрил ответы на частые вопросы по собесам, дали 400к. Пока поняли, что я долбень, заработал 1.5кк и ушел в закат
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.
А fullstack разрабочик наверно должен быть вообще богом. Ну как же... Он столько много языков знает. Многие в C++ плюхаются, а фулстек девелоперу вообще норм.
Не кантрол, а контрол альт дел. И нажимать их не надо, всегда есть Галочка, форматировать при сохранении. Оптимизировать импорты и пр. Сеньор отличается тем, что умеет не делать лишнего и за ним нет шлейфа из косяков.
У нас, конечно, в аудите, зарплаты не айтишные, но деление почти такое. Только специалист (не осталось в СВА), ведущий специалист, эксперт и главный эксперт
На моменте про вопросы аналитикам/заказчикам немного тормознул просмотр. Ну, на собеседовании - пожалуй, но не в работе. Сейчас многие издадут усталый стон, но я скажу. На проекте должна быть качественная документация. Чтобы каждый раз каждому сотруднику не бегать куда-то, не дёргать кого-то по поводу, а как должно выглядеть/работать вот это? ОК, идеальной документации не бывает. Вопросы будут. Но первым делом всё-таки надо смотреть доки, а не сразу бежать расспрашивать. И если в них есть пробелы, то уже тогда хватать аналитика, бомбардировать вопросами и заставлять прописывать. Не просто ответить, а прописывать. Прописывать в документации. Качественным текстом. И зафиксировать факт правки. В присутствии свидетелей с других направлений. (Извините, немного гиперболизировал, но наболело) И я намеренно писал "сотрудник", а не "разработчик". Документация используется всеми. По ней будут писать гайды для пользователей и техподдержки, по ней разрабы пишут код, по ней тестеры проверяют продукт, по ней тимлиды и PM'ы планируют работу команд.
а если увидел точно супер критичную ошибку (что обанкротит компанию) в не своем коде, то тоже оставить и дать катастрофе случиться, чтобы идти спрашивать что делать у тимлида?
Вот я автоматизатор (язык ST) и всё что говорится - я это прям всецело понимаю и принимаю. То есть это справедливо и для АСУ-ТП (на ST, ибо остальные "языки" МЭК это не языки, если кратко)
8:45 Не так давно столкнулся с кодом, коммантарии есть, а смысла нет, давно утерян, за аремя после написания комментария код правился множество раз и комментарий не соответствовал функционалу от слова совсем... Поэтому код должен документировать себя сам!
То что комментарии написан к старому коду, это проблема не комментария, а того кто его писал. Самадокументирующий код + понятный комментарии и минимально написанная документация, залог хорошего и понятного кода
@@x-grand-x нет, это не проблема того кто писал коммент, это проблема того, кто будет править код... а создал эту проблему тот, кто не обновил коммент!
На мой взгляд Senior программист не владеет навыком сленгового языка в изложении своих мыслей. Этот рудимент отваливается сразу же после инаугурации в статус Senior.
Синий разработчик отличается от джуна тем что напишет код после любого количества алкоголя. Просто в некоторых моментах слышно не сеньор а синий )))) 😅😅😅
@@Evg_Af А еще интересно как ты борешься, или как бороться с такими ситуациями к примеру тебе дают задачу менеджер считает что она на 2-3 дня работы, однако при работе с данной задачей всплывают куча нюансов про которые вообще никто не знал, в результате задача затягивается на 2 недели. При этом менеджер начинает негодовать как это так почему она затянулась он не технический специалист и до конца не понимает всех нюансов при этом начинает тебя оценивать, что типо что ты за специалист почему так медленно все делаешь)? При этом тебе никто не дает возможность изначально оценить сколько времени понадобиться на данную задачу. Да и когда тебя начинают оценивать как специалиста это довольно неприятно. Были ли у тебя такие ситуации как с ними справлялся?
Я на прошлой работе после сеньора дорос до маркиза, потом до герцога, уволился когда уже был лордом.
Хорошая шутка. Надо будет записать :)
Козырнуть как нибудь.
В свинопасы пошёл?
ржал
@@alekseev74 когда сеньор, надо пройти обряд помидоров, когда в тебя кидают помидорами
Ваша милость... 💂♀
"даже когда задача всё-таки поставлена и её нужно решать, он не бросается делать её сразу" ведь эстимейты завышены в три раза минимум, можно пойти кофеек попить и вздрочнуть пару раз
То у синьора эта задача уже сделана 4 года назад, скопипастит решение
Какие еб_ть эстимейты? Ты че там под спиртом?
я почему-то сталкивался с обратной ситуацией, когда всё уже должно быть сделано еще вчера, несмотря на то что получил задачу только что...
@@fensrg от проекта зависит и от твоего положения в команде. "Все должно быть ещё вчера" не отменяет того что на задачу будут выданы какие-то эстимейты. Тут скорее зависит от тимлида и менеджера и на сколько они понимают/контролируют уровень трудозатрат. Тебе задачу ставят говорят надо срочно. Ты говоришь ой ребят тут Х и У и Й ещё проверить нужно будет, займет два дня. А на самом деле работы на 4 часа.
Зависит от компании далеко не везде можно заэстимейтить в три раза больше времени
Сеньеры сотку жмут от груди судя по ведущему
Я мидл и жму 140 от груди на 5 раз 😅
@@mihinov ну, ты бэкенд наверное 🤣
@@VelikiyZmey я работаю фронтом 😅 Но могу и бекенд написать и CI/CD настроить
не факт, а вдруг приседания нужно делать
@@mihinov а 145 уже не можешь? нет, не пойдет. в джуны переведут.
Жалко что Senior'ы не вставляют тайм-коды в видео
Занят просто таской. На этапе тестирования еще. Надо понимать.
@@aduditsky ну это видео тоже когда-то было таской, а таски надо доводить до конца, как сказал автор видео
@@porloc а это хобби. Не таска. Хобби он может отложить, в свободное время доделать.
@@aduditsky task переводится как задача. Любое дело которое ты делаешь целенаправленно и спланировано это в любом случае - задача. Для каждого видео ведь пишется план, сценарий, делается съемочная часть (камера, свет, звук), монтаж, заливка. Кроме того ведение Ютуб канала, это тоже работа, с графиками и планами по выпускам. Это видео, как и остальные, не просто по наитию снималось. И тайм-коды на самом деле это простая задача, просто найти для каждой части плана соответствующие отрезки видео, и указать название из плана
Это поток сознания. Он непрерывен и тайм-коды не поддерживает
Есть два стандарта кода: которого придерживаюсь я и всякое говно.
абсолютно верно!
это только у тех у кого опыта командной разработки нет.
@@TheDelwish это у всех д'Артаньянов. потому что для них все остальные - п..сы. как в анекдоте.
Скорее это стандарты для тех, у кого нет опыта разработки)
@@MrDarthat так у большинства сеньоров недоделанных нет опыта разработки. зато есть хождения по собесам и зубрежка алгоритмов и паттернов с методологиями.
Программист не обязан знать всё наизусть. Есть документация, которой нужно уметь пользоваться. Я работаю программистом более 25 лет, каждый раз задачи разные. Под каждую задачу изучается набор инструментов и потом уже она реализуется. Не факт что сразу получится и ты с первого раза все правильно сделаешь. Каждый пишет по своему.
Это никому никому из работодателей не объяснить. О ты не умеешь в SAP - ну ты нам не подходишь.
@@rybiizhir , ну для работодателя логично, он же тебя нанимает не для того, чтобы свои деньги тебе просто так отдавать. Он хочет нанять человека, который УЖЕ в теме.
в какой то момент становится плевать, что и на чем писать, базовые концепции всегда одни и те же, как в самих языках, так и в программах.
@@SeregaZinin а наниматель сам в теме?
@@SeregaZinin Ухты, а если про сап знает один-два человека, а остальным он вообще не вперся - значит, директор попал? Будет вынужден платить бешеные бабки этому счастливчику? Все определяется местом, временем и ценой услуги :)))))
🎯 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 Заключение
• Не пытайтесь отрефакторить код без необходимости, сначала выполните задачу.
• Если задача не стоит рефакторинга, не тратьте на это время.
• Подписывайтесь на канал для дальнейшего развития.
Все точно и по делу.
Подписался.
Рад, что нашел ментора, который может объяснить доступным языком решение "проблемных" мест в становлении высококачественным специалистом.
Спасибо за контент. Продолжай в том же духе👍
У кого-то подсмотрел такое определение junior-middle-senior:
- Джуну надо ставить задачи и постоянно за ним приглядывать
- Миддл может работать самостоятельно
- Синьёр может ставить задачи другим.
Это тоже, конечно, довольно условное деление, но мне это определение легло на душу :)
А может ставит задачи другим Проект-Менеджер? 🙂
Я на первой своей работе тоже ставил задачи коллегам.
А затем, в течении около 10 лет, больше таким на занимался.
А все потому, что на первом проекте у нас не было Проект-Менеджера. 🙂
задачи ставит тим лид чаще, у одного тим лида может вся команда из синьоров
@@ARGAMX ПМ может в технике не шарить, потому задачи лучше ставить тим лиду
@@KostopravHD чем тогда ПМ занимается в таком случае?
Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером.
А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык.
Если раздачей задач занимается тех лид - то значит что в команде не настроено управление и делегирование.
@@KostopravHD чем тогда ПМ занимается в таком случае?
Бизнес спрашивает с менеджмента. Проект менеджер - менеджмент. Тот кто задачу поставил - тот с неё и спрашивает. Иначе будет получатся, что Лид будет бегать и разработчиков пинать - но это не лидовская вотчина, людей пропинывать. Для этого не обязательно технарем надо быть, а нужно быть менеджером.
А если менеджеру нехватает технической квалификации - у него целая команда технарей, кому он может это делегировать. Сами же разработчики ему и должны техническую часть задачи перевести на менеджерский язык.
Если раздачей задач занимается тех лид - то значит что в команде не сформирован менеджмент, управление и делегирование.
Думаю, автор с такой рамой ушатает несколько тимлидов враз. Синьор однозначно ✔
Я мидл, у меня тощая комплекция, но 2-й кю по Айкидо, так что получается, если я его ушатаю, то не факт?))
Senior-разработчик знает почти все правила хорошего кода, многократно нарушал их и понимает, к чему это приводит. Поэтому он рационально распределяет свои ресурсы.
Для себя как-то выработал следующие критерии уровня разработчика:
Джуну надо объяснять как делать задачу, контролировать выполнение, внимательно следить что он делает, обучать.
Мидл уже может сам понять задачу и выполнить её. Может сам разработать отдельный элемент системы или часть приложения. Мидл уже учится сам.
Сеньёр может поговорить с бизнесом, понять что ему надо, спроектировать системное решение и сам целиком его реализовать. Если он не знает какую-то технологию, то может сам разобраться, обучиться или найти того кто знает.
Плюсую, использую такие же критерии
@@AGalilov В моем понимание синьор в такой системе это чувак, который на вход получает бизнес проблему, а на выходе выдает решение, и соответственно поговорить с бизнесом в данном контексте это прояснить непонятные моменты, донести возможные негативные последствия решений и так далее. Аналитик в такой системе выполняет свою привычную роль сбора бизнес требований.
@@AGalilov а зачем аналист нужен? джунов к кастомерам запускают дефайнить все юзкейсы. обычная практика. даже заявляют, что джун должОн знать инглишь как родной, чтобы с кастомером общаться. так и делает большинство. результат как у йордана в пути камикадзе - провальный проект. все говорят, что читали, но все на тех же граблях пляшут.
@@Roman-ej3xg "с бизнесом говорить"? этим занимается project manager. а не программашка, пусть даже якобы сеньор. программашка может быть консультантом у проджект мэнеджера. еще джуна пошлите "с бизнесом говорить", как некоторые делают. срамота.
Не, на работает. Видел нескольких разрабов с годами опыта, что соответствуют критериям: способны развиваться, сами выполняют задачи и понимают, что нужно бизнесу. Но пишут код, как джуны. Непонятные переменные, все перегруженно, никакого солид, одни проектные знания, комитят то, что не комитется и так до бессконечности. Так что в видео более верно
У меня 20+ лет опыта, я сразу делаю задачу без вопросов бизнесу потому что знаю лучше них что им нужно
а потом переделывать идешь или сразу увольняют?
@@KostopravHD
Да нет, они только счастливы, что я за них уже все решил и им не пришлось стекхолдеров напрягать, хотя те тоже не знают. Я же не делаю другую функциональность, делаю заказанную, просто неосвещеные места сам уже проектирую. Ну и, с момента решения я их информирую, так что до момента реализации у них есть время внести изменения
На самом деле прям база базированная. Я практически со всем согласен. По поводу комментариев не очень понравилось. Я бы раскрыл мысль, что код, сложный для восприятия, лучше комментировать, но ребята на опыте пишут и так очень просто, чтобы джун мог разобраться, либо прыгнуть в процедуру, где класс или функция определены и там прочитать
зашел посмотреть как пишет сеньор, а в итоге мне говорят половину видео кто такой синьор
Ну на самом деле да, главное отличие синьера от всех остальных, это способность решать высокоуровневые задачи, с минимальной постановкой. И не просто решать, а правильно и эффективно. Остальное всё уже бантики
здравые мысли. Очень ценю их практичность и то, что вызваны они сугубо практическими причинами. Спасибо
Сеньор разработчик, это который может и в проектирование архитектуры, и в производительность, и с какими-то узкими технологиями знаком, и джунам затрещину отвешает за кривой код (нетерпим к плохой архитектуре и плохому коду). Пожалуй, самый главный критерий - это владение бэст-практиксами (правильное проектирование, чистый код, юнит-тесты и пр.). Та или иная технология/фреймворк осваиваются без проблем. В какие-то нужно пару дней повтыкать, в какие-то пару месяцев, но глобально сложного ничего нет. Вчера ты не владел технологией Х, через две недели ты можешь лекции читать по технологии Х. Надо быть совсем уж тупым, чтобы не суметь освоить технологию Х. А вот к освоению бэст-практиксов приходят через 3-5-7-... лет практического опыта работы, кто-то вообще не приходит. Поэтому, на мой взгляд, умение в бэст-практиксы - главный критерий окукливания в сеньора
А пока вы все гусеницы 😅😅😅
Если он может в проетирование и организацию то это уже не кодер это уже архитектор или планировшик
hr, перелогинся
ни разу не писал тесты и не комментировал свой код. а еще отправляю задачу в qa с багами и заглушками, потому что сроки. все работодатели очень довольны и не хотят отпускать, зп 500к
ни разу не писал тесты, отправляю задачу в прод в багами и заглушками, потому что "ну а хули нет". все довольны. очень. зп 700к.
Ни разу не писал код, могу только заходить в зум и слушать. Зп 1,5 ляма
@@aki7162 пм?
@@aki7162 пм?
@@aki7162 давно продактом работаешь?
Хорошее видео, спасибо автору!
Ну,я работал старшим разрабом в трех конторах. Так меня не берут сейчас никуда, мол на джуна даже не тяну. Хотя, сложные ИИ проекты поднимаю с нуля. Сейчас не работаю, пишу статью на архив орг, медиум и готовлю презу по тому пооекту который разработал сам с нуля.
Есть выгорание какое-то. Я работал программистом 1С в течение 5 лет в нескольких конторах. Но потом решил почиллить на вольных хлебах. Теперь решил вернуться в разработку, только из-за появления ИИ. Что-то для себя создать. У вас что за проект и стек технологий ?
Даже у бандарлогов есть своя иерархия :)
Что действительно отличает высокорангового разработчика от низкорангового, это умение смотреть в глаза и убеждать всех в своей компетентности.
убеждением занимаются архитекторы
Если слюна не течет и помнит как его зовут, то это синьор обычно
норм воды налил 👍
Лайков набрал))
видели бы вы исходники. Бог монтажа слил большую часть воды, оставил так, лужицу...))
если 10 лет красил кнопочки - значит краш-синьор!
@@EvgeniyYatsenko примерно так)
В России очень мало программистов с классическим образованием, оисюда и отсутствие синьоров и мидлы и джуны, считающие себя "профи". Читаю резюме - толпы девчулек, купивших какой-то курс на пол-года и поработавших подносяиком кофе в компании-интеграторе, в итоге все надписи какие запомниди - переписаны в резюме с пометкой " внедряла, разработала, щадачи кодераи ставила". А простейшие вещи, которые должен знать любой грамотный программист - этого мы не знаем. Сортирлвка на основе бинарного дерева - нас пугает, теория баз данных - "ну я же другим занимаюсь", скуль - а что это? В общем ужас...
Там где сложно: не задавать вопросов самое оно (ты же сеньор, все понятно) - все сложно, все обсуждается в ходе процесса
Там где легко: задавай вопросы, уточняй что-куда (ты же сеньор, вас на понт не взять)- все сложно, все обсуждается в ходе процесса
Итого: везде затянут процесс, зарплата капает. Не благодарите
Джун - обладает базой, способен выполнять базовые задачи. Не самостоятелен, зависим от мидла.
Мидл - обладает базой, выполняет помимо базовых задач ещё и задачи средней сложности в которых нужно проводить анализ для решения проблемы. Управляет и натаскивает прикреплённого мидла.
Синьор - обладает знаниями прилично шире своей области. Способен решать сложные и крайне сложные задачи которые не по зубам мидлам.
Хочу добавить пару пунктов к всему вышесказанному:
- Реально решает опыт (не в конкретной технологии, а в разгребании дерьма вселенского масштаба по типу - "вот нам тут досталась система, с которой никто не знает как работать, и документации по ней нет особо. Нам нужен по ней стейджинг и внятный процесс по деплою доработок/фиксов")
- Умение брать на себя ответственность.
Блин, вот с первой частью, кто такие сеньёры прям странно вышло, то по правилам - отлично! Из этих правил рождается простой критерий - сеньёр думает масштабом бизнеса. Мидл - архитектуры решения. Джун - локальным решением здесь и сейчас. Под "думает" не сидит и философствует, мол, а хорошо бы прикрутить фичу, которая круто выглядит. А именно, "как предсказуемо решить проблему бизнеса".
И да, навык кодинга важен, но если ты головой сеньёр, то навыки наработаются быстро. Если ты головой джун, то знай хоть 500 фреймворков и умей с закрытыми глазами сделать красно-чёрное дерево да развёртывай хадуп в перерывах между красным и рыжим ютубом, всё равно ты джун. Хотя сложно знать столько фреймворков и не думать архитектурой приложения, но практика показывает, что есть и бывают такие люди)
Все они кодеры
Ясно, полезно, классно, кратко! Спасибо!
В начала послышалось: синий разработчик 🤣
И второй момент, как можно задачу выполнить на 100%, не бывает так, ты вроде как всё сделал, вроде как работает, но в конце появляются идеи по улучшению кода, и оно зараза не заканчивается, у кого было такое?
лайк за адекватность
Для постановки задачи есть аналитики, для тестирования тестировщики, для разворота кластера чего угодно есть девопсы.
Я бы еще добавил, что синьор не соглашается на костыльные решения, когда выигрыш во времени - пара дней
Интересно, а автор то откуда знает, как сениор разработчики код пишут ?
Старший разработчик в Сбере это джун джун, ведущий это может быть junior+/middle главный это может быть middle/senior, самое главное твойГрейд
имхо сеньор это тот кто на работе не хочет писать код и максимально избегает этого ) джину они сразу пишут и думают чем больше кода они напишут, тем лучше. но все с точности до наоборот
Это больше похоже на навыки мидла над которым стоит контролирующий тимлид. От серьера у нас ждут максимальный опыт, обычно это чувак который наступил на все грабли и знает наилучшее решение.
Выглядит как пересказ книги "Идеальный программист" Роберта Мартина)
ну всё, теперь точно стану серьёром!!!
почему мне слышится "синий разработчик" ))))
Ты не один ))
ахаха, а реально, все мои сеньоры бухают))
Ну в принципе да, нервная работа, без бухла никуда )))
имхо.тех долг это нормально. кладется в бэклог и берется в следующем спринте. бизнесу нужны фичи и если "заглушка" позволяет фиче отвечать требованиям она должна заехать на прод.
Я 10 лет крудошлеплю, делаю сложную бизнеслогику.
Я бы посоветовал книгу Чистая Архитектура
Не всегда эти принципы применимы в реальной практике. Например, бывает так, что времени в обрез, что фича нужна заказчику уже вчера, а красиво, со всеми тестами, с документацией и без костылей писать код слишком долго. Тогда приходится делать, как успеваешь, а остальное кидать в тех. долг. Или вот на счет рефакторинга. Бывает садишься пилить таску в какой-нибудь легаси, но без рефакторинга это сделать просто невозможно или крайне больно. Проще потратить время на переделку, чем пытаться впихнуть костыли в плохо написанное.
В реальной практике да, абсолютно согласен. Видео из разряда «в идеале делать так…»
Так все равно рефачить IMO стоит после как минимум краткого обсуждения с Лидом о причинах сего действа. Поскольку этот говнокод работает и уже через qa прогнали. И чтоб потом не прилетело, кто у нас сборку порушил, чей комит сегодня самый лучший, стоит хотя б перед фактом поставить руководство… imo
@@КириллЧе-я5ы Понятное дело, что втихую такое не станешь делать. Все равно лид и другие разрабы будут в курсе, ведь от них апрувы нужны, чтобы вливаться в мастер. Подобное заранее обсуждается с командой и закладывается в оценку таски.
@@КириллЧе-я5ы костыли, которые пораждают другие костыли) если оценивал сам и не заложил в эстимейт рефакторинг - сам мудак. Если оценивал тимлид за тебя - соболезную) Всё это конечно идеализированно. На практике обычно получается либо мвп из круда смешанного с логикой и до реальных нагрузок все счастливы, либо что-то сложное которое в конечном итоге превратят в говнокод. Хороший проект может быть только если его архитектуру продумали правильно, в соответствии с бизнесом. И как только вы видите что вам нужно что-то рефакторить, значит либо вы пишите проект у которого начали меняться бизнес правила, либо изначально у вас неправильная архитектура и в том и в другом случае надо писать всё по новой. Но это в идеале, на практике вы просто набираете тех долг, и через какое-то время проект заканчивает свою жизнь)Бывают и промежуточные состояния))
@@MELkey3 бывают и промежуточные), особенно если этому проекту четверть века… и он до сих пор живее всех живых и периодически приходится что-то рефачить и надстраивать надстройки над старой архитектурой, поскольку староновое друг с другом практически не уживается))
должен всё спросить, затем скормить полученную информацию GPT4 и выдать готовый ответ через 5 минут
Картинам отдельный коммент. Они мегакрутые, притягивают внимание!
15:05 Я бы добавил, что если по ходу решения задачи, разбор кучки вонючего кода выйдет дешевле за счёт того, что его будет проще использовать и не городить обходных путей, то стоит эту кучку разобрать без создания тех-долга. Лида можно и предупредить, если куча достаточно большая.
Напоминает дискуссию в кинофильме «Дежавю»: «Это синкопа или не синкопа?»
прошел skyeng по фулстэку на html и питоне. Устроился лидом и говорю какие коды надо написать мидлам и синьорам. Задачи делаются в срок и все довольны
зп?
Всё предельно просто. Синьор может в одно лицо решить задачу. Да, может с гуглом, но сам разберётся и сделает.
Миддл - решает, периодически прибегая к помощи коллег или синьора.
Джун не может без постоянных консультаций. Разжевали, сказали чо делать - делает. Code monkey.
Нет?
Смотря что понимать под словом задача
@@КоляКоронов-к9э под словом "задача" понимают поставленую задачу.
Кстати хороший критерий. На своем веку видел много кодеров. И что больше всего поразило, что очень многие не умеют пользоваться дебагером. Казалось бы элементарная вещь, но нет. Ну и очень многие вместо того что бы разобраться любят отрывать других от их задач. Вот эти особенно бесят.
@@dmaraptor Поставленную кем ? Заказчиком ? Продоктом ? СЕО ?
Так я сеньор/миддл+, получается? С олним неполным годом работы после вуза
По-моему senior больше понимает как все работает и критерии выбора. Типа почему тут такая архитектура, почему кафка, почему pgsql, а не mysql. И он способен объяснить почему то что он выбрал правильно, а не "всегда так делали и работало".
Так выбирает не он выбирает архитектор на основе тз
@@КоляКоронов-к9э видимо зависит от организации. Я видел что архитектор в основном красивые диаграммы рисует, но не выбирает. Тк для выбора нужно сделать прототип и провести нагрузочное тестирование, чтоб выбирать не от балды, а он не может
@@tsc472 В целом если это архитектор а не планировщик то он должен мочь в соляного вытянуть проект Вот только архитектор это дорого а сениор несколько дешевле А как мы помним экономика должна быть экономной
В идеале, просто взять vim, и вынос блока в отдельную функцию будет занимать пол секунды а не минуту
Фильм был, старенький... Инженера приглашали сделать реверс новейшей технологии, платили бешеные бабки и по окончанию проекта стирали память!! Думаю, как тебя в сбер занесло? Синьер это должность, что удобно для конторы. А программист - это призвание, ярлык на всю жизнь!! В конце фильма, инженер сломал стереотип и начал думать своей головой и жить для себя ...!
Если хочешь вкатиться в разработку, пацан, ты не тупи, на бусти баблишка принеси 😂
Очень много воды и штампов. По существу ничего не сказал
@@MrInfree хотел как лучше, получилось как всегда
Все по делу сказал в самом начале - сеньор это зарплата.
Если не стал сеньером за 2 года опыта, то уже никогда не станешь. Останешься джуном с 10 годами опыта.
Я: опыта 0, закончил курсы от скилбокса, накрутил фэйкового опыта, зазубрил ответы на частые вопросы по собесам, дали 400к. Пока поняли, что я долбень, заработал 1.5кк и ушел в закат
скажи где можно найти работу за 400к ))
Ebu4ii skam
@@jon4775 в хедж фондах легко $400k в год (плюс бонусы)
Мм, боты скиллбокса подкатили рекламировать хлам.
Это правда?
Если разраб (синюор или нет) задает милион вопросов по задаче, значит задачу поставил джун
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.
Старший иженер/разраб в сбере это позиция джун-
А fullstack разрабочик наверно должен быть вообще богом. Ну как же... Он столько много языков знает. Многие в C++ плюхаются, а фулстек девелоперу вообще норм.
По-факту что джун, что синьор просто кодеры. Если держишь весь проект и решаешь все, это руководитель проекта или архитектор.
Респект за чёткое изложение материала, практически без воды.
я вот только синьора помидора знаю из "Чиполлино"
Для меня синьер в 1С это тот, кто свободно использует обработку Конвертация Данных. Если может делать отчеты с помощью СКД средние, это миддл.
название видео не соответствует содержимому.
Не кантрол, а контрол альт дел. И нажимать их не надо, всегда есть Галочка, форматировать при сохранении. Оптимизировать импорты и пр. Сеньор отличается тем, что умеет не делать лишнего и за ним нет шлейфа из косяков.
В сбере😆
Старший - джун
Ведущий - мидл
Главный - сеньор
Все лучше чем этот наш англоязычный новояз. Middle, little и adult. Не названия, а какие-то тэги с порнхаба.
У нас, конечно, в аудите, зарплаты не айтишные, но деление почти такое. Только специалист (не осталось в СВА), ведущий специалист, эксперт и главный эксперт
Когда в доте наиграл высокий рейтинг и понял что теперь уже синиор 😅
От сеньора плавно перешли на базовые терминологии, стандарты, спецификации... Про сеньора мало что сказано.
На моменте про вопросы аналитикам/заказчикам немного тормознул просмотр. Ну, на собеседовании - пожалуй, но не в работе. Сейчас многие издадут усталый стон, но я скажу.
На проекте должна быть качественная документация.
Чтобы каждый раз каждому сотруднику не бегать куда-то, не дёргать кого-то по поводу, а как должно выглядеть/работать вот это? ОК, идеальной документации не бывает. Вопросы будут. Но первым делом всё-таки надо смотреть доки, а не сразу бежать расспрашивать. И если в них есть пробелы, то уже тогда хватать аналитика, бомбардировать вопросами и заставлять прописывать. Не просто ответить, а прописывать. Прописывать в документации. Качественным текстом. И зафиксировать факт правки. В присутствии свидетелей с других направлений.
(Извините, немного гиперболизировал, но наболело)
И я намеренно писал "сотрудник", а не "разработчик". Документация используется всеми. По ней будут писать гайды для пользователей и техподдержки, по ней разрабы пишут код, по ней тестеры проверяют продукт, по ней тимлиды и PM'ы планируют работу команд.
сеньор
- В феодальном обществе: землевладелец с властью государя на своей территории.
Это сравнение программиста и вообще не программиста
сколько раз он сказал "синьяр"?
а если увидел точно супер критичную ошибку (что обанкротит компанию) в не своем коде, то тоже оставить и дать катастрофе случиться, чтобы идти спрашивать что делать у тимлида?
Вы фантазируете
короче проблема не в написании кода а в умении думать
это самая главная проблема! И вторая - внимательность.
Вот я автоматизатор (язык ST) и всё что говорится - я это прям всецело понимаю и принимаю. То есть это справедливо и для АСУ-ТП (на ST, ибо остальные "языки" МЭК это не языки, если кратко)
1с - > java -> инфо цыган -> влад МИШУСТИН 😂
Как вам лямбда выражение?
саксесс стори!)
идеально!
ну тогда я Senior-разработчик
Поздравляю! ) Теперь осталось только прибавить уверенности )
8:45 Не так давно столкнулся с кодом, коммантарии есть, а смысла нет, давно утерян, за аремя после написания комментария код правился множество раз и комментарий не соответствовал функционалу от слова совсем... Поэтому код должен документировать себя сам!
То что комментарии написан к старому коду, это проблема не комментария, а того кто его писал.
Самадокументирующий код + понятный комментарии и минимально написанная документация, залог хорошего и понятного кода
@@x-grand-x нет, это не проблема того кто писал коммент, это проблема того, кто будет править код... а создал эту проблему тот, кто не обновил коммент!
@@fensrg сложные будние программистов. Соглашусь)
судя попревью, сеньоры генерируют html код прямо из bash'a .
так всё.. походу я синьор>))
По поводу похода к бизнесу - не лишку для синьёра? Разве не лиды общаются с бизнесом?
У нас в компании я ввел понятие «капролит» - это очень старый говнокод 😊
копролит. и это не твоя выдумка, а старый времен лурка и жж термин, который и я и все мои коллеги в разных конторах использовали.
@@TheDelwish Прикольно )). Значит совпало )
Ты сначала писать без ошибок научись, вводитель.
На мой взгляд Senior программист не владеет навыком сленгового языка в изложении своих мыслей. Этот рудимент отваливается сразу же после инаугурации в статус Senior.
Сколько жим лёжа на 12 раз и разовый максимум?
@@vladislav262626 на 12 будет 90-95. На раз не знаю, у меня дома своя качалка, там максимум 108 повесить могу, на 5 раз сделаю))
Синий разработчик отличается от джуна тем что напишет код после любого количества алкоголя. Просто в некоторых моментах слышно не сеньор а синий )))) 😅😅😅
Еще раз про переменные можно? ) А в целом, толковый список Благодарю за работу
В целом все верно
я закончил курсы за 3 месяца, сейчас я сеньор
реальный опыт лет 10 суммарно
так что дерзайте, у вас получится тоже
А что вам мешало до курсов(с 10 летним реальным опытом)стать сеньором?
@@bmerlin2010 отсутствие опыта
Хороший рофл автора канала) За 3 месяца с 0 стал сеньором, но 2 года обучал программированию)))
закончил курсы 3 месяца назад,и стал сеньором
Я думаю он имел ввиду, что до того как начал работать за 3 месяца прошел курсы и сейчас, спустя 10 лет стал сеньором
Principal engineer -это senior?
Ну, конечно же нет! Откуда вы все повылазили?! Principal engineer - это просто очень принципиальный инженер.
Привет а было ли у тебя выгорание когда ничего не хочется делать но это не лень? Если да то как боролся с этим ?
@@sammygun84 было. Ничего не делал. Буквально. Не работал. Когда деньги начали кончаться выгорание быстро прошло.
@@Evg_Af Спасибо за ответ)
@@Evg_Af А еще интересно как ты борешься, или как бороться с такими ситуациями к примеру тебе дают задачу менеджер считает что она на 2-3 дня работы, однако при работе с данной задачей всплывают куча нюансов про которые вообще никто не знал, в результате задача затягивается на 2 недели. При этом менеджер начинает негодовать как это так почему она затянулась он не технический специалист и до конца не понимает всех нюансов при этом начинает тебя оценивать, что типо что ты за специалист почему так медленно все делаешь)? При этом тебе никто не дает возможность изначально оценить сколько времени понадобиться на данную задачу. Да и когда тебя начинают оценивать как специалиста это довольно неприятно. Были ли у тебя такие ситуации как с ними справлялся?
Иногда я синьор, а иногда не очень. Динамический синьор. Так можно?
Вот бы все синиоры программисты кластеры разворачивали, особенно если пишешь под мобилки
Спасибо за отличное видео
Как пишет код сеньера, принцесса, королева
Как синьоры пишут код? Ставят таску и асайнят на Джуна 😂
Синьор... И 'называйте переменные понятно ', со второй страницы джунского туториала
четко