Как Senior-разработчики на САМОМ ДЕЛЕ пишут код

[@alekseev74]

Я на прошлой работе после сеньора дорос до маркиза, потом до герцога, уволился когда уже был лордом.

[@GrayStrix]

Хорошая шутка. Надо будет записать :) Козырнуть как нибудь.

[@BB-ti9bf]

В свинопасы пошёл?

[@un_defined]

ржал

[@FigisBadralov]

@@alekseev74 когда сеньор, надо пройти обряд помидоров, когда в тебя кидают помидорами

[@CresisOne]

Ваша милость... 💂‍♀

[@ВысоцкийАндрей-г5э]

"даже когда задача всё-таки поставлена и её нужно решать, он не бросается делать её сразу" ведь эстимейты завышены в три раза минимум, можно пойти кофеек попить и вздрочнуть пару раз

[@ProGamerru]

То у синьора эта задача уже сделана 4 года назад, скопипастит решение

[@Maxim9575]

Какие еб_ть эстимейты? Ты че там под спиртом?

[@fensrg]

я почему-то сталкивался с обратной ситуацией, когда всё уже должно быть сделано еще вчера, несмотря на то что получил задачу только что...

[@ВысоцкийАндрей-г5э]

@@fensrg от проекта зависит и от твоего положения в команде. "Все должно быть ещё вчера" не отменяет того что на задачу будут выданы какие-то эстимейты. Тут скорее зависит от тимлида и менеджера и на сколько они понимают/контролируют уровень трудозатрат. Тебе задачу ставят говорят надо срочно. Ты говоришь ой ребят тут Х и У и Й ещё проверить нужно будет, займет два дня. А на самом деле работы на 4 часа.

[@SergMirny_yt]

Зависит от компании далеко не везде можно заэстимейтить в три раза больше времени

[@VelikiyZmey]

Сеньеры сотку жмут от груди судя по ведущему

[@mihinov]

Я мидл и жму 140 от груди на 5 раз 😅

[@VelikiyZmey]

@@mihinov ну, ты бэкенд наверное 🤣

[@mihinov]

@@VelikiyZmey я работаю фронтом 😅 Но могу и бекенд написать и CI/CD настроить

[@DANTECHNOKZ]

не факт, а вдруг приседания нужно делать

[@JohnDoe-ei8wx]

@@mihinov а 145 уже не можешь? нет, не пойдет. в джуны переведут.

[@z0mbiehunter]

Есть два стандарта кода: которого придерживаюсь я и всякое говно.

[@Evg_Af]

абсолютно верно!

[@TheDelwish]

это только у тех у кого опыта командной разработки нет.

[@JohnDoe-ei8wx]

@@TheDelwish это у всех д'Артаньянов. потому что для них все остальные - п..сы. как в анекдоте.

[@MrDarthat]

Скорее это стандарты для тех, у кого нет опыта разработки)

[@JohnDoe-ei8wx]

@@MrDarthat так у большинства сеньоров недоделанных нет опыта разработки. зато есть хождения по собесам и зубрежка алгоритмов и паттернов с методологиями.

[@porloc]

Жалко что Senior'ы не вставляют тайм-коды в видео

[@aduditsky]

Занят просто таской. На этапе тестирования еще. Надо понимать.

[@porloc]

@@aduditsky ну это видео тоже когда-то было таской, а таски надо доводить до конца, как сказал автор видео

[@aduditsky]

@@porloc а это хобби. Не таска. Хобби он может отложить, в свободное время доделать.

[@porloc]

@@aduditsky task переводится как задача. Любое дело которое ты делаешь целенаправленно и спланировано это в любом случае - задача. Для каждого видео ведь пишется план, сценарий, делается съемочная часть (камера, свет, звук), монтаж, заливка. Кроме того ведение Ютуб канала, это тоже работа, с графиками и планами по выпускам. Это видео, как и остальные, не просто по наитию снималось. И тайм-коды на самом деле это простая задача, просто найти для каждой части плана соответствующие отрезки видео, и указать название из плана

[@v_rot_tebe_nogi]

Это поток сознания. Он непрерывен и тайм-коды не поддерживает

[@iscanderkov9656]

Программист не обязан знать всё наизусть. Есть документация, которой нужно уметь пользоваться. Я работаю программистом более 25 лет, каждый раз задачи разные. Под каждую задачу изучается набор инструментов и потом уже она реализуется. Не факт что сразу получится и ты с первого раза все правильно сделаешь. Каждый пишет по своему.

[@rybiizhir]

Это никому никому из работодателей не объяснить. О ты не умеешь в SAP - ну ты нам не подходишь.

[@SeregaZinin]

@@rybiizhir , ну для работодателя логично, он же тебя нанимает не для того, чтобы свои деньги тебе просто так отдавать. Он хочет нанять человека, который УЖЕ в теме.

[@похуйпляшем-й1н]

в какой то момент становится плевать, что и на чем писать, базовые концепции всегда одни и те же, как в самих языках, так и в программах.

[@istinaanitsi3342]

@@SeregaZinin а наниматель сам в теме?

[@rmatveev]

У кого-то подсмотрел такое определение junior-middle-senior: - Джуну надо ставить задачи и постоянно за ним приглядывать - Миддл может работать самостоятельно - Синьёр может ставить задачи другим. Это тоже, конечно, довольно условное деление, но мне это определение легло на душу :)

[@ARGAMX]

А может ставит задачи другим Проект-Менеджер? 🙂 Я на первой своей работе тоже ставил задачи коллегам. А затем, в течении около 10 лет, больше таким на занимался. А все потому, что на первом проекте у нас не было Проект-Менеджера. 🙂

[@SegeyKravtsov]

🎯 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

[@mike-stpr]

Круто! Вот ответочка от яндекс.спойлер )) Как 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 Заключение • Не пытайтесь отрефакторить код без необходимости, сначала выполните задачу. • Если задача не стоит рефакторинга, не тратьте на это время. • Подписывайтесь на канал для дальнейшего развития.

[@primalconcretesledge9226]

Думаю, автор с такой рамой ушатает несколько тимлидов враз. Синьор однозначно ✔

[@Artem1s-_-]

Я мидл, у меня тощая комплекция, но 2-й кю по Айкидо, так что получается, если я его ушатаю, то не факт?))

[@antonkaster]

Для себя как-то выработал следующие критерии уровня разработчика: Джуну надо объяснять как делать задачу, контролировать выполнение, внимательно следить что он делает, обучать. Мидл уже может сам понять задачу и выполнить её. Может сам разработать отдельный элемент системы или часть приложения. Мидл уже учится сам. Сеньёр может поговорить с бизнесом, понять что ему надо, спроектировать системное решение и сам целиком его реализовать. Если он не знает какую-то технологию, то может сам разобраться, обучиться или найти того кто знает.

[@okke00]

Плюсую, использую такие же критерии

[@okke00]

@@AGalilov В моем понимание синьор в такой системе это чувак, который на вход получает бизнес проблему, а на выходе выдает решение, и соответственно поговорить с бизнесом в данном контексте это прояснить непонятные моменты, донести возможные негативные последствия решений и так далее. Аналитик в такой системе выполняет свою привычную роль сбора бизнес требований.

[@JohnDoe-ei8wx]

@@AGalilov а зачем аналист нужен? джунов к кастомерам запускают дефайнить все юзкейсы. обычная практика. даже заявляют, что джун должОн знать инглишь как родной, чтобы с кастомером общаться. так и делает большинство. результат как у йордана в пути камикадзе - провальный проект. все говорят, что читали, но все на тех же граблях пляшут.

[@JohnDoe-ei8wx]

@@Roman-ej3xg "с бизнесом говорить"? этим занимается project manager. а не программашка, пусть даже якобы сеньор. программашка может быть консультантом у проджект мэнеджера. еще джуна пошлите "с бизнесом говорить", как некоторые делают. срамота.

[@ivanssolovjovs2880]

Не, на работает. Видел нескольких разрабов с годами опыта, что соответствуют критериям: способны развиваться, сами выполняют задачи и понимают, что нужно бизнесу. Но пишут код, как джуны. Непонятные переменные, все перегруженно, никакого солид, одни проектные знания, комитят то, что не комитется и так до бессконечности. Так что в видео более верно

[@A_Kupin]

На самом деле прям база базированная. Я практически со всем согласен. По поводу комментариев не очень понравилось. Я бы раскрыл мысль, что код, сложный для восприятия, лучше комментировать, но ребята на опыте пишут и так очень просто, чтобы джун мог разобраться, либо прыгнуть в процедуру, где класс или функция определены и там прочитать

[@Prof-Shor]

У меня 20+ лет опыта, я сразу делаю задачу без вопросов бизнесу потому что знаю лучше низ что им нужно

[@dkvChannel]

Джун - обладает базой, способен выполнять базовые задачи. Не самостоятелен, зависим от мидла. Мидл - обладает базой, выполняет помимо базовых задач ещё и задачи средней сложности в которых нужно проводить анализ для решения проблемы. Управляет и натаскивает прикреплённого мидла. Синьор - обладает знаниями прилично шире своей области. Способен решать сложные и крайне сложные задачи которые не по зубам мидлам.

[@denismailing1419]

Хорошее видео, спасибо автору!

[@AlexandrPuzakov]

Сеньор разработчик, это который может и в проектирование архитектуры, и в производительность, и с какими-то узкими технологиями знаком, и джунам затрещину отвешает за кривой код (нетерпим к плохой архитектуре и плохому коду). Пожалуй, самый главный критерий - это владение бэст-практиксами (правильное проектирование, чистый код, юнит-тесты и пр.). Та или иная технология/фреймворк осваиваются без проблем. В какие-то нужно пару дней повтыкать, в какие-то пару месяцев, но глобально сложного ничего нет. Вчера ты не владел технологией Х, через две недели ты можешь лекции читать по технологии Х. Надо быть совсем уж тупым, чтобы не суметь освоить технологию Х. А вот к освоению бэст-практиксов приходят через 3-5-7-... лет практического опыта работы, кто-то вообще не приходит. Поэтому, на мой взгляд, умение в бэст-практиксы - главный критерий окукливания в сеньора

[@locktar-o-dark5664]

А пока вы все гусеницы 😅😅😅

[@КоляКоронов-к9э]

Если он может в проетирование и организацию то это уже не кодер это уже архитектор или планировшик

[@waltergibbs3041]

hr, перелогинся

[@Mobofilka]

Не всегда эти принципы применимы в реальной практике. Например, бывает так, что времени в обрез, что фича нужна заказчику уже вчера, а красиво, со всеми тестами, с документацией и без костылей писать код слишком долго. Тогда приходится делать, как успеваешь, а остальное кидать в тех. долг. Или вот на счет рефакторинга. Бывает садишься пилить таску в какой-нибудь легаси, но без рефакторинга это сделать просто невозможно или крайне больно. Проще потратить время на переделку, чем пытаться впихнуть костыли в плохо написанное.

[@Evg_Af]

В реальной практике да, абсолютно согласен. Видео из разряда «в идеале делать так…»

[@КириллЧе-я5ы]

Так все равно рефачить IMO стоит после как минимум краткого обсуждения с Лидом о причинах сего действа. Поскольку этот говнокод работает и уже через qa прогнали. И чтоб потом не прилетело, кто у нас сборку порушил, чей комит сегодня самый лучший, стоит хотя б перед фактом поставить руководство… imo

[@Mobofilka]

@@КириллЧе-я5ы Понятное дело, что втихую такое не станешь делать. Все равно лид и другие разрабы будут в курсе, ведь от них апрувы нужны, чтобы вливаться в мастер. Подобное заранее обсуждается с командой и закладывается в оценку таски.

[@MELkey3]

​@@КириллЧе-я5ы костыли, которые пораждают другие костыли) если оценивал сам и не заложил в эстимейт рефакторинг - сам мудак. Если оценивал тимлид за тебя - соболезную) Всё это конечно идеализированно. На практике обычно получается либо мвп из круда смешанного с логикой и до реальных нагрузок все счастливы, либо что-то сложное которое в конечном итоге превратят в говнокод. Хороший проект может быть только если его архитектуру продумали правильно, в соответствии с бизнесом. И как только вы видите что вам нужно что-то рефакторить, значит либо вы пишите проект у которого начали меняться бизнес правила, либо изначально у вас неправильная архитектура и в том и в другом случае надо писать всё по новой. Но это в идеале, на практике вы просто набираете тех долг, и через какое-то время проект заканчивает свою жизнь)Бывают и промежуточные состояния))

[@КириллЧе-я5ы]

@@MELkey3 бывают и промежуточные), особенно если этому проекту четверть века… и он до сих пор живее всех живых и периодически приходится что-то рефачить и надстраивать надстройки над старой архитектурой, поскольку староновое друг с другом практически не уживается))

[@Silver-iw3gj]

ни разу не писал тесты и не комментировал свой код. а еще отправляю задачу в qa с багами и заглушками, потому что сроки. все работодатели очень довольны и не хотят отпускать, зп 500к

[@betamvmt]

ни разу не писал тесты, отправляю задачу в прод в багами и заглушками, потому что "ну а хули нет". все довольны. очень. зп 700к.

[@aki7162]

Ни разу не писал код, могу только заходить в зум и слушать. Зп 1,5 ляма

[@Silver-iw3gj]

@@aki7162 пм?

[@Silver-iw3gj]

@@aki7162 пм?

[@Silver-iw3gj]

@@aki7162 давно продактом работаешь?

[@takiekakmi7532]

Хочу добавить пару пунктов к всему вышесказанному: - Реально решает опыт (не в конкретной технологии, а в разгребании дерьма вселенского масштаба по типу - "вот нам тут досталась система, с которой никто не знает как работать, и документации по ней нет особо. Нам нужен по ней стейджинг и внятный процесс по деплою доработок/фиксов") - Умение брать на себя ответственность.

[@troshenkov]

Даже у бандарлогов есть своя иерархия :) Что действительно отличает высокорангового разработчика от низкорангового, это умение смотреть в глаза и убеждать всех в своей компетентности.

[@ivekrok3730]

Ясно, полезно, классно, кратко! Спасибо!

[@HansVeidenkorb]

здравые мысли. Очень ценю их практичность и то, что вызваны они сугубо практическими причинами. Спасибо

[@akalashnikovAnd]

Ну на самом деле да, главное отличие синьера от всех остальных, это способность решать высокоуровневые задачи, с минимальной постановкой. И не просто решать, а правильно и эффективно. Остальное всё уже бантики

[@alexpizza72]

почему мне слышится "синий разработчик" ))))

[@zeleniumex]

Ты не один ))

[@Spider0444]

ахаха, а реально, все мои сеньоры бухают))

[@anonymus6312]

Ну в принципе да, нервная работа, без бухла никуда )))

[@EvgeniyYatsenko]

если 10 лет красил кнопочки - значит краш-синьор!

[@Evg_Af]

@@EvgeniyYatsenko примерно так)

[@АлександрМамзиков-х1у]

15:05 Я бы добавил, что если по ходу решения задачи, разбор кучки вонючего кода выйдет дешевле за счёт того, что его будет проще использовать и не городить обходных путей, то стоит эту кучку разобрать без создания тех-долга. Лида можно и предупредить, если куча достаточно большая.

[@santiagomunez5559]

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.

[@sauvage6534]

Я 10 лет крудошлеплю, делаю сложную бизнеслогику. Я бы посоветовал книгу Чистая Архитектура

[@daeriofrixell199]

прошел skyeng по фулстэку на html и питоне. Устроился лидом и говорю какие коды надо написать мидлам и синьорам. Задачи делаются в срок и все довольны

[@MaksimFedorov-w1o]

Там где сложно: не задавать вопросов самое оно (ты же сеньор, все понятно) - все сложно, все обсуждается в ходе процесса Там где легко: задавай вопросы, уточняй что-куда (ты же сеньор, вас на понт не взять)- все сложно, все обсуждается в ходе процесса Итого: везде затянут процесс, зарплата капает. Не благодарите

[@MexoOne]

На моменте про вопросы аналитикам/заказчикам немного тормознул просмотр. Ну, на собеседовании - пожалуй, но не в работе. Сейчас многие издадут усталый стон, но я скажу. На проекте должна быть качественная документация. Чтобы каждый раз каждому сотруднику не бегать куда-то, не дёргать кого-то по поводу, а как должно выглядеть/работать вот это? ОК, идеальной документации не бывает. Вопросы будут. Но первым делом всё-таки надо смотреть доки, а не сразу бежать расспрашивать. И если в них есть пробелы, то уже тогда хватать аналитика, бомбардировать вопросами и заставлять прописывать. Не просто ответить, а прописывать. Прописывать в документации. Качественным текстом. И зафиксировать факт правки. В присутствии свидетелей с других направлений. (Извините, немного гиперболизировал, но наболело) И я намеренно писал "сотрудник", а не "разработчик". Документация используется всеми. По ней будут писать гайды для пользователей и техподдержки, по ней разрабы пишут код, по ней тестеры проверяют продукт, по ней тимлиды и PM'ы планируют работу команд.

[@canniballissimo]

ну всё, теперь точно стану серьёром!!!

[@Rumandpepsicola]

Напоминает дискуссию в кинофильме «Дежавю»: «Это синкопа или не синкопа?»

[@leomak7580]

имхо сеньор это тот кто на работе не хочет писать код и максимально избегает этого ) джину они сразу пишут и думают чем больше кода они напишут, тем лучше. но все с точности до наоборот

[@владимиркарпов-т4ъ]

В идеале, просто взять vim, и вынос блока в отдельную функцию будет занимать пол секунды а не минуту

[@ЕвгенийВовк-ы7ь]

Картинам отдельный коммент. Они мегакрутые, притягивают внимание!

[@MrInfree]

Очень много воды и штампов. По существу ничего не сказал

[@Evg_Af]

@@MrInfree хотел как лучше, получилось как всегда

[@eugenemironov2919]

Все по делу сказал в самом начале - сеньор это зарплата.

[@JustDux]

Всё предельно просто. Синьор может в одно лицо решить задачу. Да, может с гуглом, но сам разберётся и сделает. Миддл - решает, периодически прибегая к помощи коллег или синьора. Джун не может без постоянных консультаций. Разжевали, сказали чо делать - делает. Code monkey. Нет?

[@КоляКоронов-к9э]

Смотря что понимать под словом задача

[@dmaraptor]

@@КоляКоронов-к9э под словом "задача" понимают поставленую задачу.

[@dmaraptor]

Кстати хороший критерий. На своем веку видел много кодеров. И что больше всего поразило, что очень многие не умеют пользоваться дебагером. Казалось бы элементарная вещь, но нет. Ну и очень многие вместо того что бы разобраться любят отрывать других от их задач. Вот эти особенно бесят.

[@КоляКоронов-к9э]

@@dmaraptor Поставленную кем ? Заказчиком ? Продоктом ? СЕО ?

[@All_C1212]

Так я сеньор/миддл+, получается? С олним неполным годом работы после вуза

[@snakekop]

норм воды налил 👍

[@noJobProgrammer]

Лайков набрал))

[@Evg_Af]

видели бы вы исходники. Бог монтажа слил большую часть воды, оставил так, лужицу...))

[@roman.chudov]

Если слюна не течет и помнит как его зовут, то это синьор обычно

[@АллаКлевер]

Вот я автоматизатор (язык ST) и всё что говорится - я это прям всецело понимаю и принимаю. То есть это справедливо и для АСУ-ТП (на ST, ибо остальные "языки" МЭК это не языки, если кратко)

[@bggstfrt]

Не кантрол, а контрол альт дел. И нажимать их не надо, всегда есть Галочка, форматировать при сохранении. Оптимизировать импорты и пр. Сеньор отличается тем, что умеет не делать лишнего и за ним нет шлейфа из косяков.

[@SinitcinTech]

Еще раз про переменные можно? ) А в целом, толковый список Благодарю за работу

[@goodvideobro]

Спасибо за отличное видео

[@alexanderandryukov2187]

Я бы еще добавил, что синьор не соглашается на костыльные решения, когда выигрыш во времени - пара дней

[@bloodjopa]

Я: опыта 0, закончил курсы от скилбокса, накрутил фэйкового опыта, зазубрил ответы на частые вопросы по собесам, дали 400к. Пока поняли, что я долбень, заработал 1.5кк и ушел в закат

[@jon4775]

скажи где можно найти работу за 400к ))

[@binzaricatalin6542]

Ebu4ii skam

[@vitalyl1327]

​@@jon4775 в хедж фондах легко $400k в год (плюс бонусы)

[@abbze8272]

Мм, боты скиллбокса подкатили рекламировать хлам.

[@yundon8182]

Это правда?

[@nikitakolmogorov]

Когда программист советует почитать книгу про программирование - видео выключается

[@mikerus59]

А fullstack разрабочик наверно должен быть вообще богом. Ну как же... Он столько много языков знает. Многие в C++ плюхаются, а фулстек девелоперу вообще норм.

[@azamatgaliyev9931]

Это больше похоже на навыки мидла над которым стоит контролирующий тимлид. От серьера у нас ждут максимальный опыт, обычно это чувак который наступил на все грабли и знает наилучшее решение.

[@mix5457]

В России очень мало программистов с классическим образованием, оисюда и отсутствие синьоров и мидлы и джуны, считающие себя "профи". Читаю резюме - толпы девчулек, купивших какой-то курс на пол-года и поработавших подносяиком кофе в компании-интеграторе, в итоге все надписи какие запомниди - переписаны в резюме с пометкой " внедряла, разработала, щадачи кодераи ставила". А простейшие вещи, которые должен знать любой грамотный программист - этого мы не знаем. Сортирлвка на основе бинарного дерева - нас пугает, теория баз данных - "ну я же другим занимаюсь", скуль - а что это? В общем ужас...

[@5gugorsky]

сеньор это тот, кто решает боевые задачи в срок любыми способами. Пока джуны и мидлы месяц бьются над кодом, сеньор потиху подвязывает соседнюю контору на аутсорсе платит им вменяемую копеечку, и через неделю у него худо бедно работающий готовый код, который он правит и вуаля... джуны и мидлы: а что так можно было? сеньор: пфф, сеньору всё можно)

[@TheFryOS]

я закончил курсы за 3 месяца, сейчас я сеньор реальный опыт лет 10 суммарно так что дерзайте, у вас получится тоже

[@bmerlin2010]

А что вам мешало до курсов(с 10 летним реальным опытом)стать сеньором?

[@TheFryOS]

@@bmerlin2010 отсутствие опыта

[@Василий_А]

Хороший рофл автора канала) За 3 месяца с 0 стал сеньором, но 2 года обучал программированию)))

[@kanstantsindziamidzenka4460]

закончил курсы 3 месяца назад,и стал сеньором

[@mar1n828]

Я думаю он имел ввиду, что до того как начал работать за 3 месяца прошел курсы и сейчас, спустя 10 лет стал сеньором

[@jgkdmdevienjjgg8866]

В целом все верно

[@faultier3773]

должен всё спросить, затем скормить полученную информацию GPT4 и выдать готовый ответ через 5 минут

[@igorcoolman]

название видео не соответствует содержимому.

[@shod76]

У нас в компании я ввел понятие «капролит» - это очень старый говнокод 😊

[@TheDelwish]

копролит. и это не твоя выдумка, а старый времен лурка и жж термин, который и я и все мои коллеги в разных конторах использовали.

[@shod76]

@@TheDelwish Прикольно )). Значит совпало )

[@dmaraptor]

Ты сначала писать без ошибок научись, вводитель.

[@dmitriz6496]

Возможно, дело в том, что "Senior" созвучно со словом "инженер". Но, когда говорят "инженер", всегда уточняют специализацию или конкретную область работы. В конце концов с какими бы технологиями ты не работал, ты не можешь знать всё, поэтому должна быть градация этого понятия.

[@tsc472]

По-моему senior больше понимает как все работает и критерии выбора. Типа почему тут такая архитектура, почему кафка, почему pgsql, а не mysql. И он способен объяснить почему то что он выбрал правильно, а не "всегда так делали и работало".

[@КоляКоронов-к9э]

Так выбирает не он выбирает архитектор на основе тз

[@tsc472]

@@КоляКоронов-к9э видимо зависит от организации. Я видел что архитектор в основном красивые диаграммы рисует, но не выбирает. Тк для выбора нужно сделать прототип и провести нагрузочное тестирование, чтоб выбирать не от балды, а он не может

[@КоляКоронов-к9э]

@@tsc472 В целом если это архитектор а не планировщик то он должен мочь в соляного вытянуть проект Вот только архитектор это дорого а сениор несколько дешевле А как мы помним экономика должна быть экономной

[@strelok_2k]

CRUD, Hadoop - я вообще не считаю программистами людей которые знают это слова )) Критерий синьера - один, может человек сам увидеть проблему и решить ее или не может. Мидл может решить проблему по указке лида, но сам как правило плохо понимает где проблема или в чем проблема, а вот синьер может пойти сам на мит сходить, сам послушать че вообще надо делать или найти заметить техническую проблему и решить в одно рыло, автономно.

[@soulwind7577]

Так наоборот, если объем задач бешенный и у вас дедлайн горит из за того что проект нужно выполнить в очень сжатые сроки, хорошего разраба сразу видно если он грамотно раскидывает TODO, что бы не делать задачу очень долгое время, а сделать заглушки для не очень важных модулей, а потом уже когда проект выйдет в MVP доделать их когда уже все остальное гореть не будет. Н-р из фронтовых задач которые я часто на потом в TODO закидываю Разные компоненты с большим кол-вом адаптивности: динамические тултипы которые сами будут выбирать как они отобразятся (н-р модалка или расположение лево/право/вверх/вниз), адаптивные модалки, анимации, валидации форм Делаешь вызов функции с заглушкой, когда запустили MVP доделываешь уже подключенные модули заглушки в порядке важности Вместо фейкового Api можно просто моковые данные из методов запросов отдавать и уже потом как время появится делаешь нормальный фейк бек на каком нить мираже. и еще куча всего остального. Но суть видео я понял, ваш опыт это больше опыт в каких нить энтерпрайз конторах, которые могут позволить ковыряться с любой задачей больше времени, что бы ее покрыть тестами, обсудить полностью и т.п, в стартапах такой подход как по мне совершенно не работает.

[@deuxego]

Shadcn закрывает задачи с компонентами, удобная штука

[@Evg_Af]

Все верно. Стартапы обхожу стороной. Мне не нужна гонка, мне нужен максимальный расслабон и побольше денег за минимум кодинга.))

[@landpro28]

Если хочешь вкатиться в разработку, пацан, ты не тупи, на бусти баблишка принеси 😂

[@r-n-i-n-yt]

От сеньора плавно перешли на базовые терминологии, стандарты, спецификации... Про сеньора мало что сказано.

[@silentium_noxe]

Купа води. Розмова ні про що. Senior це просто чувак з великим досвідом. Все згадане в відео обязан робити будь який програміст незалежно від досвіду. Тому чувак котрий має досвід просто не витрачає час на роздуми як це зробити, він це робить тут і зараз бо він цей код за свій досвід вже пише в тисячний раз. Він знає які підводні камені очікувати і як з ними працювати

[@sanya_s_parmezana]

1с - > java -> инфо цыган -> влад МИШУСТИН 😂 Как вам лямбда выражение?

[@Evg_Af]

саксесс стори!)

[@fensrg]

8:45 Не так давно столкнулся с кодом, коммантарии есть, а смысла нет, давно утерян, за аремя после написания комментария код правился множество раз и комментарий не соответствовал функционалу от слова совсем... Поэтому код должен документировать себя сам!

[@x-grand-x]

То что комментарии написан к старому коду, это проблема не комментария, а того кто его писал. Самадокументирующий код + понятный комментарии и минимально написанная документация, залог хорошего и понятного кода

[@fensrg]

@@x-grand-x нет, это не проблема того кто писал коммент, это проблема того, кто будет править код... а создал эту проблему тот, кто не обновил коммент!

[@x-grand-x]

@@fensrg сложные будние программистов. Соглашусь)

[@an2qzavok]

сеньор - В феодальном обществе: землевладелец с властью государя на своей территории.

[@Александр-ц5к3з]

Почему автор рассказывает про джуновские, максимум мидловые штуки и называет их сеньёрскими? 🤷‍♂️

[@Maxim9575]

Видимо рамки настолько незримые что для сеньеора ничего нет, выполняет джун на стероидах 😂

[@x-grand-x]

​@@Maxim9575+ так и есть. Четких рамок нет. Максимально модно отнести все это х20 и опыта накидать, совт скиллы, умение собрать ракету и запустить прод😊

[@MexoOne]

На мной взгляд, джун-мидл-сеньор делают-то одно и то же. Основная разница, если смотреть сверху, сколько контроля нужно за вот этим конкретным сотрудником. За джуном нужно постоянно проверять, мидлу уже можно сколько-то доверять, а синьор и без контроля всё сделает правильно. А определяется степень доверия качествами, описанными в видео.

[@x-grand-x]

@@MexoOne Тот самый "Реальный опыт" который на собеседованиях требуют) Но рамок и правда нет

[@Георгий-з3с6с]

ну тогда я Senior-разработчик

[@VictorKozmuliak]

Поздравляю! ) Теперь осталось только прибавить уверенности )

[@похуйпляшем-й1н]

адекватно

[@HiroPuko]

Когда в доте наиграл высокий рейтинг и понял что теперь уже синиор 😅

[@istinaanitsi3342]

короче проблема не в написании кода а в умении думать

[@АртемАлександров-б5д]

Духота, будто на созвонах тренировался)

[@IQ-120]

Фильм был, старенький... Инженера приглашали сделать реверс новейшей технологии, платили бешеные бабки и по окончанию проекта стирали память!! Думаю, как тебя в сбер занесло? Синьер это должность, что удобно для конторы. А программист - это призвание, ярлык на всю жизнь!! В конце фильма, инженер сломал стереотип и начал думать своей головой и жить для себя ...!

[@Никита-й7р6п]

Так если оценку времени не защитить и не объяснить - на планировании голосованием меньше времени поставят)

[@JamesBond-bu8co]

Приветствую автора! Давно интересует вопрос - кто устанавливает время на выполнение задачи для джуна (он сам или тот кто дает задачу), и какие сроки являются средними? Просто побаиваюсь, что если попросить, например, пару дней, то на меня вылупят глаза и зачмырят за то, что мне нужно столько времени на тукую простую задачу (а я еще не умею реально оценивать время, которое мне потребуется). Заранее спасибо!

[@ВысоцкийАндрей-г5э]

Смотри, если ты официально джун на позиции джуна, то ожидать от тебя точных эстимейтов никто не будет (при условии что все адекватные вокруг) говори сколько чувствуешь, если не так то тебя поправят, а с опытом поймёшь как нужно. Не забывай что 99% задач слоднее чес кажется и времени уйдет куда больше. А те задачи которые ты точно знаешь и умеешь - ну если знаешь то ставь как знаешь. В разных компаниях ещё есть всякие приколы в зависимости от специфики. Где-то эстимейты ставит тимлид+аналитик, где-то играют в покер, это когда несколько человек заптсывают "в закрытую" сколько времени задача займет а потом "вскрываются" одновременно. Тех кто написал самое маленькое и самое большое просят пояснить, может есть решение которое они знают или есть подводные которые никто не заметил, а потом на основании этого выбирают средний эстимейт. Это делается чтобы нельзя было завышать жстимейты и потом пинать хер, всех разом подговорить почти невозможно. В общем и целом проблема - занизить эстимейты, по тому что не успеешь сделать. Завысить немного и сдать раньше - это не плохо. Завысить сильно тебе скорее всего не дадут. Да и если задача занимает несколько дней по твоему (особенно на джуна) то можно предложить её декомпозировать, это тоже норм, мол разбить на таски по меньше

[@JamesBond-bu8co]

@@ВысоцкийАндрей-г5э Спасибо за развернутый ответ! Пока еще официально безработный, учусь)) Но вопросы, похожие на заданный, разумеется, беспокоят.

[@TheDelwish]

лучше оговаривай время с запасом, чем каждый раз сдигай сроки. нужно понимать зачем сеньоры с тебя спрашивают время. никто не думают о чмырении, думают о планах выполнения, чтобы уложиться в сроки (ибо задач много, где есть блокеры, где-то нет). важное правило это быть предсказуемым. и лучше сразу уточнить, по естимейтам, т.е. идеально сказать, есть несколько вариантов подхода решения задачи - 1) быстрый день -два, но такие вот негативные последствия 2) неделя, но зато вот это вот

[@zeleniumex]

Синий разработчик отличается от джуна тем что напишет код после любого количества алкоголя. Просто в некоторых моментах слышно не сеньор а синий )))) 😅😅😅

[@pavelbbb]

В сбере😆 Старший - джун Ведущий - мидл Главный - сеньор

[@lexxryazanov]

Все лучше чем этот наш англоязычный новояз. Middle, little и adult. Не названия, а какие-то тэги с порнхаба.

[@All_C1212]

У нас, конечно, в аудите, зарплаты не айтишные, но деление почти такое. Только специалист (не осталось в СВА), ведущий специалист, эксперт и главный эксперт

[@hfoen]

В начала послышалось: синий разработчик 🤣 И второй момент, как можно задачу выполнить на 100%, не бывает так, ты вроде как всё сделал, вроде как работает, но в конце появляются идеи по улучшению кода, и оно зараза не заканчивается, у кого было такое?

[@user-segadev]

я практически всегда рефакторю сразу код, который задевает мою задачу. Если конечно немного.

[@SergMirny_yt]

Как синьоры пишут код? Ставят таску и асайнят на Джуна 😂

[@textreanimator]

Как пишет код сеньера, принцесса, королева

[@romankuzmin6022]

Берешь и того кто считает тебя не синьером зерачишь об стол лицом, больно и красочно, отмазываешься от телесных (как синьор) и берешь всю задачу твоего хейтера и пишешь в одно лицо, долго и невпопад на незнакомой технологии. Если узнал себя - ты синьор.

[@noJobProgrammer]

Если разраб (синюор или нет) задает милион вопросов по задаче, значит задачу поставил джун

[@sammygun84]

Привет а было ли у тебя выгорание когда ничего не хочется делать но это не лень? Если да то как боролся с этим ?

[@Evg_Af]

@@sammygun84 было. Ничего не делал. Буквально. Не работал. Когда деньги начали кончаться выгорание быстро прошло.

[@sammygun84]

@@Evg_Af Спасибо за ответ)

[@sammygun84]

@@Evg_Af А еще интересно как ты борешься, или как бороться с такими ситуациями к примеру тебе дают задачу менеджер считает что она на 2-3 дня работы, однако при работе с данной задачей всплывают куча нюансов про которые вообще никто не знал, в результате задача затягивается на 2 недели. При этом менеджер начинает негодовать как это так почему она затянулась он не технический специалист и до конца не понимает всех нюансов при этом начинает тебя оценивать, что типо что ты за специалист почему так медленно все делаешь)? При этом тебе никто не дает возможность изначально оценить сколько времени понадобиться на данную задачу. Да и когда тебя начинают оценивать как специалиста это довольно неприятно. Были ли у тебя такие ситуации как с ними справлялся?

[@iex32]

Это сравнение программиста и вообще не программиста

[@ИмяФамилия-ь3е3п]

Старший иженер/разраб в сбере это позиция джун-

[@MrPavelFrolov]

По поводу похода к бизнесу - не лишку для синьёра? Разве не лиды общаются с бизнесом?

[@ЦенительКино-к5и]

Комментарии спорная вещь, по-хорошему твой код должен с помощью переменных и так читаться, а комменты ток запутывают и засоряют, их можно не так понять тоже.

[@Burburbirbur]

Видел где то пример хороших комментариев: Комментарии должны отражать то, чего нет в коде. Говорить что делают переменные и методы должны названия переменных и методов. Но например если какое то апи требует 5 раз закинуть логин, то в коде без комментария, который поясняет этот момент это будет выглядеть как бред полнейший

[@antonkaster]

Я видел много плохого когда, и каждый раз в нём был явный недостаток комментариев. Я видел много хорошего кода, и каждый раз там были комментарии и их было достаточно для понимания кода. Совпадение? Не думаю

[@TheDelwish]

ну он неверно потому что про комментарии все пояснил (особенно в части комментировать, что должно возвращать - особенно в java , где стат типизация, зачем еще комментарии?) комментарии нужны как верно выше написали, для того чего в коде нет, ссылки , референсы, описание причин написания какого-то куска. ибо код не отражает интенций и мыслей писателей. у меня был реальный такой случай, пришел в контору, где код написан был не приведи господь никому такое увидеть. и нашел сразу же (как мне казалось) баг. явный просто. сейчас уже не помню ибо давно было, что там было конкретно, но в итоге после опроса продукт owner и еще пары тестировщиков и бизнес аналитика, выяснилось, что это не баг, это фича как говорится - это криворуки предыдущие очень странно покрыли очень специфичный юзкейс. естесно это переписалось и добавился коммент про спецюзкейс. ибо без коммента понять логику написания такого странного кейса практически невозможно, а опрашивать всех подряд каждый раз ты не будешь.

[@TheDelwish]

@@Burburbirbur во во

[@un_defined]

так всё.. походу я синьор>))

[@svaig]

1 принцип - разве не дублирование работы тимлида/продакт манагера/аналитика? 2, 5 принципы - для идеального мира с драконами, понями и заказчиками, которые сами знают, чего хотят и могут это объяснить. А разраб - многорукий и многозадачный с бесконечным запасом времени. 3-4 принципы мидлов/джунов не касается? Или их надо каждый раз в криво оттабулированный код, повторения и прочие элементарные косяки носом тыкать?

[@КоляКоронов-к9э]

ну если у джуна код запустился это уже хорошо а если и делает что надо то это просто мечта

[@hermanarih239]

@@КоляКоронов-к9э Если код джуна запустился и делает то, что надо это уже мидл)

[@lobanovds]

А линтеры для кого придумали?

[@КоляКоронов-к9э]

@@hermanarih239 Я и говоря мечта мидл по цене джуна Скажите нет ?

[@Vitek_23]

3:50 14:40 Девушка посидела, попрограммировала, мужчина пришел за тот же комп и код, попрограммировал) Новая методика какая-то?

[@LonDevOfficial]

Сеньеры вообще не пишут код сами Это делают за них джуны

[@ПавелАбрамс]

В банках понятие "старший" - это мидл. Есть просто разраб, старший разраб, и ведущий разраб

[@torlant3742]

Не факт. Эта плашка мало что решает. По факту старший и ведущий разрабы в сбере могут быть как джунами, так и мидлами. Зависит от локации. Главный разраб - это мидл или сеньор. Руководитель разработки - это сеньор.

[@okke00]

Ведущий это по идее Principal, следующий после синьора грейд

[@locktar-o-dark5664]

В банках это по ходу возраст)))

[@eugenemironov2919]

судя попревью, сеньоры генерируют html код прямо из bash'a .

[@скз-л2в]

здравствуйте, хочу задать небольшой вопрос есть ли смысл записывать функции или какие-то примеры кода в тетрадку и потом это учить и запоминать

[@KlausDrown]

С if или for прокатит ещё но когда функция хотябы на 50 строк... и да пример кода на видео был написан за минуты 3, с помощью помощника от компилятора, а ручками писать минут 10.

[@JohnDoe-ei8wx]

@dbmongo9732 как зачем? на собесе могут спросить программашки. их чему учили - они то и спрашивают. например. алгоритмы сортировки. они думают. что лучше их реализуют, чем, например, это сделано в том же oracle или любой другой субд. не ответишь - не возьмут. так что зубрить надо. много и все. и по собесам шастать. вечным студентом.

[@КоляКоронов-к9э]

@@KlausDrown помошника от компилятора нет это иде

[@KlausDrown]

@@КоляКоронов-к9э оговорился, извеняюсь.

[@ox-po363]

огонь видео! спасибо!

[@mkostya]

Principal engineer -это senior?

[@Тестоубежало]

Звучит как синий разработчик😊

[@Mickey-agressor-pubg]

зашел посмотреть как пишет сеньор, а в итоге мне говорят половину видео кто такой синьор

[@duoduoo6732]

а если увидел точно супер критичную ошибку (что обанкротит компанию) в не своем коде, то тоже оставить и дать катастрофе случиться, чтобы идти спрашивать что делать у тимлида?

[@Evg_Af]

Вы фантазируете

[@hugoboss3741]

На мой взгляд Senior программист не владеет навыком сленгового языка в изложении своих мыслей. Этот рудимент отваливается сразу же после инаугурации в статус Senior.