если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
можно абстрактно, можно конкретнее.
например, сеньёр должен уметь делать, в зависимости от области, в которой он работает:
— тюнинг и оптимизация программ и sql запросов
— разбираться в реверс-инжиниринге
— понимать ассемблер
умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
upd1:
тогда вопрос — какими конкретно тех. навыками обычно обладают только сеньёры? какие тех навыки рассматриваются как высший пилотах?
не срывать сроки, понимать, прикидывать, общаться, руководить, просчитывать.... — вопрос не про это
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра? M>можно абстрактно, можно конкретнее.
решать задачи самостоятельно с хорошим качеством и в разумные сроки.
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра? M>можно абстрактно, можно конкретнее. ... M>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
Уметь проектировать, а не только конструировать.
Например, если используется ООП, тогда SOLID, Design Patterns — рисовать в UML'е таковые и внятно аргументировать каковы их недостатки в сравнении с высокой связностью и хрупкостью архитектуры, если их не применять должным образом.
Если работа связана с разработкой распределённых систем, то быть знакомым с классическими паттернами и недостатками в этой сфере: service-oriented architecture (SOA), enterprise service bus(ESB), микросервисы, пляски вокруг брокеров сообщений и т.д.
В плане навыков командной работы.
При конфликте мнений по техническим вопросам стремиться не к компромиссу, а синтезу — т.н. консенсусу. Чётко и внятно осознавая зачем и почему надо уходить от компромисса в эту сторону.
Никогда не давить авторитетом высказывая своё ценное мнение, а вначале давать высказаться всем остальным и только после этого излагать собственную позицию в чётко и однозначно аргументированном виде.
Короче, синьёр — это просто зрелый специалист, понимающий как применять системный анализ, близкий к архитектору и опора манагера в вопросах управления командной работой.
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
Умение работать самостоятельно. Чем сеньористей сеньор, тем больше полномочий он может на себя взять.
Программа минимум — умение закрыть тикет, при необходимости придумывая архитектуру, документируя, уточняя требования, общаясь с соседями/руководителями/клиентами, тестируя или плотно взаимодействуя с тестировщиком.
Программа максимум охватывает весь SDLC — умение получить от заказчика расплывчатые хотелки и выдать качественный продукт, при необходимости с поддержкой.
F>решать задачи самостоятельно
Часто под этим понимается "если смежники (аналитики, тестирование, поддержка) не выполнили свои функции, то пойти на их зону ответственности и сделать всё самому за них (и чтобы они при этом не жаловались, что ты им мешаешь), и не парить мозг начальству что оно не наладило процесс".
scf>Чем сеньористей сеньор, тем больше полномочий он может на себя взять.
Наоборот, заставить работать на свою задачу тех, полномочий командовать кем сеньор не имеет. Путём упрашивания, либо делая самому всё не сделанное другими службами.
Здравствуйте, Osaka, Вы писали:
scf>>Чем сеньористей сеньор, тем больше полномочий он может на себя взять. O>Наоборот, заставить работать на свою задачу тех, полномочий командовать кем сеньор не имеет. Путём упрашивания, либо делая самому всё не сделанное другими службами.
"моя хата с краю" mentality. Я понимаю, что в дурнопахнущих организациях иначе не выжить, но имхо лучше просто избегать компаний с плохим менеджментом.
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
прямо с этого форума, было хорошее определение — я для себя даже сохранил. Не благодарите:
* Синьор — опытный и ответственный человек, которому я могу дать достаточно большую и возможно не совсем четко сформулированную задачу. Он ее проанализирует, декомпозирует на подзадачи и сделает. В случае проблем эскалирует их лиду. Со стороны лида нужен минимальный надзор.
* Мидл — человек с опытом, но задачи которому нужно ставить по возможности четкие и сформулированные. Мидлу нужен более плотный контроль и возможно понадобиться помощь с начальным анализом/выработкой оптимального решения.
* Джуниор — человек без опыта или с минимальным опытом. За ним нужен надзор, обучение. Можно давать какие-то совсем простые задачи, к которым у остальных не доходят руки. Джуниора можна отдать в качества помощника синьору, который будет его менторить и давать задачи из своей зоны ответственности.
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
Нет таких "абстрактных знаний сеньора". Есть опыт, который возможно подходит какой-то компании.
M> — тюнинг и оптимизация программ и sql запросов
Не обязательно, просто пиши эффективный код.
M> — разбираться в реверс-инжиниринге
За каким якодзуном??
M> — понимать ассемблер
И формат 3.5" дискет. Тебя чё, разморозили что ли??
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
Младший -- не умеет решать проблемы.
Средний -- умеет решать проблемы (единственным способом, почерпнутым из книги "Also sprach %name%", все остальные подходы считаются богохульствомъ).
Старший -- умеет решать проблемы разными способами (знаком с понятиями "плюсы" и "минусы").
Старый -- умеет не создавать проблем (способен не только видеть конкретное задание, но и согласовывать его решение со всем проектом).
Здравствуйте, mizuchi, Вы писали:
M>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
Тех. навыки могут быть самыми разными, это зависит от конкретного места.
Но они должны позволять решить любую проблему в рамках проекта без необходимости контроля сверху.
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр
"Средний" это просто программер, без приставки "джуниор"? Тогда список не должен заканчиваться на синьоре. Выше синьора идут ещё "staff" и "principal".
Титул "Синьора" часто значит, что это просто хороший профессиональный программер, который может работать над сложными задачами, включая проектирование дизайна компонентов, при этом не дергает других по мелочам и умеет самостоятельно находить решение возникающих проблем. Джуниоры (совсем начинающие — стажеры, студенты) вообще толком работать еще не могут, а "средние" иногда косячат или нуждаются в помощи более опытных разработчиков.
Т.е. "синьор" это просто такой хороший девелопер, обычно — лет 5 опыта и выше. Для многих это вершина карьеры в CS, на следующие ступени переходить уже сложнее.
Здравствуйте, Osaka, Вы писали:
F>>решать задачи самостоятельно O>Часто под этим понимается "если смежники (аналитики, тестирование, поддержка) не выполнили свои функции, то пойти на их зону ответственности и сделать всё самому за них (и чтобы они при этом не жаловались, что ты им мешаешь), и не парить мозг начальству что оно не наладило процесс".
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
Сениор — это просто опытный программист.
Здравствуйте, mizuchi, Вы писали:
M>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра?
С какой целью ты задаешь этот вопрос?
M>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
Почему же? Чем выше должность, тем более важны soft skills, а не технические навыки.
Если рассматривать только технические навыки, то окажется что требования к senior могут быть ниже, чем к middle.
Здравствуйте, De-Bill, Вы писали:
DB>Это мидл где? В твоей компании? Или во всём IT мире?
Это везде. Сениор — опытный, мидл — обычный, джун — начинающий. Поэтому, кстати, "20-летний сениор" — это как "ортодоксальный еврей", оксюморон. Для того чтобы набраться опыта нужно время.
Здравствуйте, Max Mustermann, Вы писали:
MM>Здравствуйте, copypaste, Вы писали:
C>>Поэтому, кстати, "20-летний сениор" — это как "ортодоксальный еврей", оксюморон. MM>Э... Щито?
"ортодокс" в переводе с греческого означает "православный"
Здравствуйте, copypaste, Вы писали:
DB>>Это мидл где? В твоей компании? Или во всём IT мире? C>Это везде. Сениор — опытный, мидл — обычный, джун — начинающий. Поэтому, кстати, "20-летний сениор" — это как "ортодоксальный еврей", оксюморон. Для того чтобы набраться опыта нужно время.
в разных компаниях, на разных проектах могут быть и 20-летние сеньоры. для тех условий он был опытным.
в других условиях вполне может стать и джуном.
Здравствуйте, neFormal, Вы писали:
F>в разных компаниях, на разных проектах могут быть и 20-летние сеньоры. для тех условий он был опытным. F>в других условиях вполне может стать и джуном.
Ну какой опыт может быть в 20лет? Гонору, да, этого там хватает, а опыт — извините.
Здравствуйте, copypaste, Вы писали:
F>>в разных компаниях, на разных проектах могут быть и 20-летние сеньоры. для тех условий он был опытным. F>>в других условиях вполне может стать и джуном. C>Ну какой опыт может быть в 20лет? Гонору, да, этого там хватает, а опыт — извините.
маленький, но опыт же.
в каких-то проектах это имеет вес. но и проекты эти простые.
Здравствуйте, Ikemefula, Вы писали:
M>>>можно абстрактно, можно конкретнее. F>>решать задачи самостоятельно с хорошим качеством и в разумные сроки. I>Что такое хорошее качество? И что такое разумные сроки?
синьор должен понимать, что такое качество в его сфере и какие сроки разумны. сам. без чужой помощи.
если он не может соблюсти заявленные сроки или качество кода очень низкое, то время задуматься, синьор ли это.
I>А сложность задач куда деть?
сложность в код, код в яйцо, яйцо в утку, утку в зайца...
Здравствуйте, neFormal, Вы писали:
I>>Что такое хорошее качество? И что такое разумные сроки?
F>синьор должен понимать, что такое качество в его сфере и какие сроки разумны. сам. без чужой помощи. F>если он не может соблюсти заявленные сроки или качество кода очень низкое, то время задуматься, синьор ли это.
Должен понимать — это не понятно. Можешь выдать проверяемую формулировку?
Здравствуйте, Ikemefula, Вы писали:
I>>>Что такое хорошее качество? И что такое разумные сроки? F>>синьор должен понимать, что такое качество в его сфере и какие сроки разумны. сам. без чужой помощи. F>>если он не может соблюсти заявленные сроки или качество кода очень низкое, то время задуматься, синьор ли это. I>Должен понимать — это не понятно. Можешь выдать проверяемую формулировку?
не уверен, что могу, но давай попробую.
всё упирается в сроки и качество.
если на рынке или в команде присутствуют в большом числе люди, которые могут сделать быстрее и/или качественней на тех же технологиях, то планка смещается.
моё имхо в том, что синьор должен требовать минимум контроля в плане сроков и качества.
качество при этом зависит от рынка и конкретной команды. заключается оно в минимуме необоснованных сменой требований переделок и понятности для остальных членов команды. ну и в стабильной работе.
при этом это не зависит от задачи. синьор может быть как в технологии, так и в предметной области. терминология активно применяется и в некодерских областях.
а сроки... заявленные сроки надо выдерживать. предсказуемость — основная черта.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, mizuchi, Вы писали:
M>>если всех программёров условно побрить, помыть, выдать одинаковую форму поделить на 3 категории: джуниор, средний и синьёр, то какие знания и умения ожидаются от сеньёра? G>С какой целью ты задаешь этот вопрос?
он не связан с карьерой — не боись.
M>>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки. G>Почему же? Чем выше должность, тем более важны soft skills, а не технические навыки.
а я спрашиваю про тех навыки.
G>Если рассматривать только технические навыки, то окажется что требования к senior могут быть ниже, чем к middle.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
I>>>>Что такое хорошее качество? И что такое разумные сроки? F>>>синьор должен понимать, что такое качество в его сфере и какие сроки разумны. сам. без чужой помощи. F>>>если он не может соблюсти заявленные сроки или качество кода очень низкое, то время задуматься, синьор ли это. I>>Должен понимать — это не понятно. Можешь выдать проверяемую формулировку?
F>не уверен, что могу, но давай попробую.
F>всё упирается в сроки и качество. F>если на рынке или в команде присутствуют в большом числе люди, которые могут сделать быстрее и/или качественней на тех же технологиях, то планка смещается.
F>моё имхо в том, что синьор должен требовать минимум контроля в плане сроков и качества. F>качество при этом зависит от рынка и конкретной команды. заключается оно в минимуме необоснованных сменой требований переделок и понятности для остальных членов команды. ну и в стабильной работе. F>при этом это не зависит от задачи. синьор может быть как в технологии, так и в предметной области. терминология активно применяется и в некодерских областях. F>а сроки... заявленные сроки надо выдерживать. предсказуемость — основная черта.
неее, я не про это. вернее сначала был вопрос про это, но теперь я обновил его.
более конкертные тех навыки.
C>Ну какой опыт может быть в 20лет? Гонору, да, этого там хватает, а опыт — извините.
Ну не в 20, а в 20 с небольшим запросто. Самый простой пример Кармак, который в 26 был одним из самых "влиятельных" разработчиков индустрии компьютерных игр.
Здравствуйте, mizuchi, Вы писали:
M>неее, я не про это. вернее сначала был вопрос про это, но теперь я обновил его. M>более конкертные тех навыки.
никаких конкретных.
это может быть senior html developer, который шустро верстает по макетам и пишет клёвые css'ки
или senior c++ developer, который знает бузд на 60%
или senior blockchain developer, который знает клёвую смузячечную на Сретенке
думаю, схема такая:
— выбираешь технологию;
— 60-80% этой технологии нужно знать и иметь практический опыт, чтобы зваться синьором;
— 90%+ — это уже хорошие такие задроты, которые могут проконсультировать по поводу тонких нюансов реализации.
Здравствуйте, De-Bill, Вы писали:
DB>Ну не в 20, а в 20 с небольшим запросто. Самый простой пример Кармак, который в 26 был одним из самых "влиятельных" разработчиков индустрии компьютерных игр.
Ладно, давай от противного. Вот представь себе этакого дядю с 10-15+ лет опыта в разных сферах, с кучей выполненных (и работающих!) проектов, с опытом разгребания дерьма и факапов в продакшене и пр. пр. пр. Вот кто он тогда такой, если мальчик "в 20 с небольшим" — это уже сениор?
C>Ладно, давай от противного. Вот представь себе этакого дядю с 10-15+ лет опыта в разных сферах, с кучей выполненных (и работающих!) проектов, с опытом разгребания дерьма и факапов в продакшене и пр. пр. пр. Вот кто он тогда такой, если мальчик "в 20 с небольшим" — это уже сениор?
Сильно зависит от дяди. Ну там всякие факторы, типа:
1. На каких ролях он был на этих проектах? Может "ключи подносил".
2. Какого рода это были проекты? Может очередные бухгалтерии.
3. Какие уроки он вынес из разгребания дерьма и факапов в продакшене? Большая часть людей не способна учиться на ошибках.
4. Какие технологии использовались на этих проектах? Может он поддерживал системы на ASP (не .NET) или на других устаревших технологиях и вообще отстал от промышленности лет на 20.
5. Как вообще мозги у дяди работают? Может несмотря на огромное число проектов соображалка у него вполне посредственная.
И в зависимости от этих факторов и компании, куда он устраивается, ему может быть предложена роль как senior (lead/principal или чего там ещё придумают) developer, так и могут не взять на роль junior. При этом фактор компании, куда он устраивается, играет большую роль, чем факторы 1-5. Большинство senior developer, например, не пройдут начальный фильтр на junior в какой-нибудь google.
P.S. Седина — это не признак мудрости, это признак старости. Так и большое количество лет опыта это не признак хорошей квалификации или умения программировать.
Здравствуйте, De-Bill, Вы писали:
DB>Сильно зависит от дяди. Ну там всякие факторы, типа:
Я просто описал программиста с опытом, ты в какие-то частности пытаешься увести. Да, разумеется, можно 10 лет кнопки по формочке двигать и на пенсию уйти ничему не научившись.
DB>P.S. Седина — это не признак мудрости, это признак старости. Так и большое количество лет опыта это не признак хорошей квалификации или умения программировать.
"Мудрость не всегда приходит с возрастом, бывает что возраст приходит один" (c) И в 20 лет бывают хорошие программисты, но для того чтобы набраться опыта время таки необходимо.
DB>>Сильно зависит от дяди. Ну там всякие факторы, типа: C>Я просто описал программиста с опытом, ты в какие-то частности пытаешься увести. Да, разумеется, можно 10 лет кнопки по формочке двигать и на пенсию уйти ничему не научившись.
Программисты с опытом бывают очень разные. Как и компании, которые программистов набирают. На этой ветке периодически у некоторых программистов с опытом бомбит, что они не могут пройти начальный скрининг яндекса или амазона.
C>"Мудрость не всегда приходит с возрастом, бывает что возраст приходит один" (c) И в 20 лет бывают хорошие программисты, но для того чтобы набраться опыта время таки необходимо.
Очень сильно зависит от человека, его способностей и типа проектов. Некоторым вполне достаточно того, что они программировали в детстве и в университете, а потом поработали пару лет, чтобы работать на лидирующих позициях. А некоторым и 20 лет опыта не достаточно, чтобы устроиться не в госкомпанию.
Здравствуйте, copypaste, Вы писали:
DB>>Ну не в 20, а в 20 с небольшим запросто. Самый простой пример Кармак, который в 26 был одним из самых "влиятельных" разработчиков индустрии компьютерных игр. C>Ладно, давай от противного. Вот представь себе этакого дядю с 10-15+ лет опыта в разных сферах, с кучей выполненных (и работающих!) проектов, с опытом разгребания дерьма и факапов в продакшене и пр. пр. пр. Вот кто он тогда такой, если мальчик "в 20 с небольшим" — это уже сениор?
почему они оба не могут быть благородными донами синьорами?
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, mizuchi, Вы писали:
M>>неее, я не про это. вернее сначала был вопрос про это, но теперь я обновил его. M>>более конкертные тех навыки.
F>никаких конкретных. F>это может быть senior html developer, который шустро верстает по макетам и пишет клёвые css'ки F>или senior c++ developer, который знает бузд на 60% F>или senior blockchain developer, который знает клёвую смузячечную на Сретенке
F>думаю, схема такая: F>- выбираешь технологию; F>- 60-80% этой технологии нужно знать и иметь практический опыт, чтобы зваться синьором; F>- 90%+ — это уже хорошие такие задроты, которые могут проконсультировать по поводу тонких нюансов реализации.
ты забыл одну маааааленькую деталь.
чтобы сказать, что кто-то знает что-то на 90%, нужно определить 100%.
100% знания в какой-то области — невозможно. нельзя определить, что есть 100%.
поэтому и сказать, что ты знаешь это 90% или др. кол-во процентов — тоже нельзя.
Здравствуйте, neFormal, Вы писали:
F>почему они оба не могут быть благородными донами синьорами?
Потому что реальный опыт приобретается на реальных проектах, и для того чтобы их сделать нужно время, а 20-летний мальчик только институт закончил.
Здравствуйте, De-Bill, Вы писали:
DB>Некоторым вполне достаточно того, что они программировали в детстве и в университете, а потом поработали пару лет, чтобы работать на лидирующих позициях.
Это и есть те самы пресловутые "20-летние сениоры" и если они "лидирующих позициях", то это больше говорит не о "сениорах", а компании которая их берет. Те о ком ты говоришь — это (в лучшем случае) просто хороший или даже талантливый программист, но опыта у него нет, просто неоткуда взяться в следствии молодости.
DB>А некоторым и 20 лет опыта не достаточно, чтобы устроиться не в госкомпанию.
Что ты доказать пытаешься я не пойму? Чтобы приобрести опыт нужно время, но разумеется не только это, от тупого сидения перед монитором опыт волшебным образом не зарабатывается.
C>Это и есть те самы пресловутые "20-летние сениоры" и если они "лидирующих позициях", то это больше говорит не о "сениорах", а компании которая их берет.
Я как бы об этом и говорю, что компании бывают разные с разными задачами. Но говорить о компании должны её финансовые показатели, отзывы клиентов и удовлетворенность сотрудников, а не возраст сеньоров.
C>Те о ком ты говоришь — это (в лучшем случае) просто хороший или даже талантливый программист, но опыта у него нет, просто неоткуда взяться в следствии молодости.
Некоторые из тех, о ком я говорю, сейчас в 30 с небольшим владеют компаниями на 100+ человек или имеют проданный стартап.
Здравствуйте, De-Bill, Вы писали:
C>>Это и есть те самы пресловутые "20-летние сениоры" и если они "лидирующих позициях", то это больше говорит не о "сениорах", а компании которая их берет. DB>Я как бы об этом и говорю, что компании бывают разные с разными задачами.
Я с одной конторой пересекался, так там вообще одни студенты работают. Да, есть разные компании, некоторым и джунов хватает.
DB>Но говорить о компании должны её финансовые показатели, отзывы клиентов и удовлетворенность сотрудников, а не возраст сеньоров.
ну я понял, в твоем понимании сениор — это тот кого назначили сениором, похоже, что типа должности
DB>Некоторые из тех, о ком я говорю, сейчас в 30 с небольшим владеют компаниями на 100+ человек или имеют проданный стартап.
и они, по твоему, сениор-программисты?
C>Я с одной конторой пересекался, так там вообще одни студенты работают. Да, есть разные компании, некоторым и джунов хватает.
Не бывает проектов из одних джунов, всегда есть кто-то, кто является в нем движущей технической силой. Если в проекте одни молодые, то кто-то из берёт на себя ответственность и принимает технические решения.
DB>>Но говорить о компании должны её финансовые показатели, отзывы клиентов и удовлетворенность сотрудников, а не возраст сеньоров. C>ну я понял, в твоем понимании сениор — это тот кого назначили сениором, похоже, что типа должности
Ну, не только запись в трудовой, но роль, которую он играет в конкретной компании на конкретных проектах. И вполне вероятна ситуация, что опытного сеньора одной компании даже не будут рассматривать на должность стажера а другой.
DB>>Некоторые из тех, о ком я говорю, сейчас в 30 с небольшим владеют компаниями на 100+ человек или имеют проданный стартап. C>и они, по твоему, сениор-программисты?
Были в 20 лет с небольшим. Сейчас тоже иногда работаю со студентами (магистрантами), которые вполне дают фору разработчикам с опытом 10+ лет.
Здравствуйте, De-Bill, Вы писали:
DB>Сейчас тоже иногда работаю со студентами (магистрантами), которые вполне дают фору разработчикам с опытом 10+ лет.
У нас с тобой просто разное понимание того кто такой сениор-разработчик, спорить не о чем.
Здравствуйте, copypaste, Вы писали:
F>>почему они оба не могут быть благородными донами синьорами? C>Потому что реальный опыт приобретается на реальных проектах, и для того чтобы их сделать нужно время, а 20-летний мальчик только институт закончил.
20-летний senior ololo developer разбирается в ololo так же, как и 40-летний senior doxrena developer, который вкатился в ololo неделю назад.
почему надо дискриминировать того, кто младше?
чтобы старпёру не было обидно, что 20-летний умник зарабатывает столько же? потому что старпёр в свои 20 лет полы мыл за джунами?
Здравствуйте, De-Bill, Вы писали:
C>>Я с одной конторой пересекался, так там вообще одни студенты работают. Да, есть разные компании, некоторым и джунов хватает.
DB>Не бывает проектов из одних джунов, всегда есть кто-то, кто является в нем движущей технической силой. Если в проекте одни молодые, то кто-то из берёт на себя ответственность и принимает технические решения. DB>>>Некоторые из тех, о ком я говорю, сейчас в 30 с небольшим владеют компаниями на 100+ человек или имеют проданный стартап.
Так это джуны-миддлы пошедшие сразу в сторону ТимЛид -> ПМ -> своя контора. Полно таких видел, да и сам был в 23 тимлидом, в 24 менеджером, "брал-ответственность-принимал-решения" итп. И только сейчас, в 35, могу честно назвать себя сеньором
Здравствуйте, mizuchi, Вы писали:
M>например, сеньёр должен уметь делать, в зависимости от области, в которой он работает: M> — тюнинг и оптимизация программ и sql запросов M> — разбираться в реверс-инжиниринге M> — понимать ассемблер
M>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
А вот зря — это ключевое.
Сеньёр — не зависит от возраста. Это странно, если сеньёру 19 лет, но и 50 летний программист с 30 летним опытом не обязательно будет сеньором.
Главный критерий — это способность решать задачи. Т.е. если человек может взять задачу, добиться от заказчика то, что нужно сделать, понять как это встроить в систему, и что для этого нужно сделать. И после этого не будет "90 процентов уже сделано, осталось только потестировать", то он сеньор.
Если ему надо, чтобы кто-то сказал, что делать, то максимум мидл. Если нужна нянька, то джуниор.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, mizuchi, Вы писали:
M>>ты забыл одну маааааленькую деталь. M>>чтобы сказать, что кто-то знает что-то на 90%, нужно определить 100%.
F>достаточно отделить 100% от всего остального.
ну отдели. опиши, что значит знать c++ на 100% и определи кол-во процентов на которое ты его знаешь.
F>нашёл незнание какой-то редкой мелочи типа a[b]==b[a]? — уже не 100%
а если не нашёл? но они есть. и сколько их есть — как ты можешь знать?
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, mizuchi, Вы писали:
M>>например, сеньёр должен уметь делать, в зависимости от области, в которой он работает: M>> — тюнинг и оптимизация программ и sql запросов M>> — разбираться в реверс-инжиниринге M>> — понимать ассемблер
M>>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
A>А вот зря — это ключевое. A>Сеньёр — не зависит от возраста. Это странно, если сеньёру 19 лет, но и 50 летний программист с 30 летним опытом не обязательно будет сеньором. A>Главный критерий — это способность решать задачи. Т.е. если человек может взять задачу, добиться от заказчика то, что нужно сделать, понять как это встроить в систему, и что для этого нужно сделать. И после этого не будет "90 процентов уже сделано, осталось только потестировать", то он сеньор.
A>Если ему надо, чтобы кто-то сказал, что делать, то максимум мидл. Если нужна нянька, то джуниор.
я сказал — не рассматриваем, не предполагаем, что они не важны.
F>да и сам был в 23 тимлидом, в 24 менеджером, "брал-ответственность-принимал-решения" итп. И только сейчас, в 35, могу честно назвать себя сеньором
А я не парился и называл себя сеньором, запрашивал и зарабатывал соответствующе. Сейчас в 30+ просто пофиг, как моя должность называется, сам себя называю просто программистом.
Здравствуйте, neFormal, Вы писали:
F>20-летний senior ololo developer разбирается в ololo так же, как и 40-летний senior doxrena developer, который вкатился в ololo неделю назад. F>почему надо дискриминировать того, кто младше? F>чтобы старпёру не было обидно, что 20-летний умник зарабатывает столько же? потому что старпёр в свои 20 лет полы мыл за джунами?
А если еще на прошлой неделе сдавал зачет по методам используемым в ololo, то будет даже лучше 40-летнего разбираться
От 40-летнего я бы ожидал больше опыта при интеграции ololo в проект, обработке ошибок, предвидения каких-то подводных камней и построение более расширяемого решения.
Здравствуйте, mizuchi, Вы писали:
M>ну отдели. опиши, что значит знать c++ на 100% и определи кол-во процентов на которое ты его знаешь. M>а если не нашёл? но они есть. и сколько их есть — как ты можешь знать?
планка же меняется.
находятся баги, появляются новые фичи.
нельзя стать синьором навсегда, чтобы потом выделываться перед молодёжью, какой ты клёвый синьор и как седа твоя борода.
Здравствуйте, msorc, Вы писали:
F>>20-летний senior ololo developer разбирается в ololo так же, как и 40-летний senior doxrena developer, который вкатился в ololo неделю назад. F>>почему надо дискриминировать того, кто младше? F>>чтобы старпёру не было обидно, что 20-летний умник зарабатывает столько же? потому что старпёр в свои 20 лет полы мыл за джунами? M>А если еще на прошлой неделе сдавал зачет по методам используемым в ololo, то будет даже лучше 40-летнего разбираться
не, эта проекция не работает.
я понимаю, что вопросы по университетскому курсу на собеседовании многих выбивают из колеи. но вкатываться в алгоритмы, цитирую, "неделю назад" — это уже совсем другое
M>От 40-летнего я бы ожидал больше опыта при интеграции ololo в проект, обработке ошибок, предвидения каких-то подводных камней и построение более расширяемого решения.
да, вполне может быть.
а может, конечно, и не быть.
Здравствуйте, alzt, Вы писали:
A>Если ему надо, чтобы кто-то сказал, что делать, то максимум мидл. Если нужна нянька, то джуниор.
От предметной области зависит. Можно и для senior'а няньку приставить в случае сложной предметной области, чтобы каждый шаг обговаривать.
А так, согласен. Вопрос -- должен ли при этом разрботчик разбираться в предметной области?
Здравствуйте, mizuchi, Вы писали:
M>>>умение руководить другими, общаться и т.п. — не рассматриваем. только тех. навыки.
A>>А вот зря — это ключевое. A>>Сеньёр — не зависит от возраста. Это странно, если сеньёру 19 лет, но и 50 летний программист с 30 летним опытом не обязательно будет сеньором. A>>Главный критерий — это способность решать задачи. Т.е. если человек может взять задачу, добиться от заказчика то, что нужно сделать, понять как это встроить в систему, и что для этого нужно сделать. И после этого не будет "90 процентов уже сделано, осталось только потестировать", то он сеньор.
A>>Если ему надо, чтобы кто-то сказал, что делать, то максимум мидл. Если нужна нянька, то джуниор.
M> M>я сказал — не рассматриваем, не предполагаем, что они не важны.
Так это ключевое. Это не вопрос коммуникации, это вопрос может ли человек сам понять как решить конкретную задачу, либо надо, чтобы кто-то другой понял и объяснил.
Здравствуйте, Sharov, Вы писали:
A>>Если ему надо, чтобы кто-то сказал, что делать, то максимум мидл. Если нужна нянька, то джуниор.
S>От предметной области зависит. Можно и для senior'а няньку приставить в случае сложной предметной области, чтобы каждый шаг обговаривать. S>А так, согласен. Вопрос -- должен ли при этом разрботчик разбираться в предметной области?
Нянька — это человек, который будет присматривать за джуниором, чтобы тот не накосячил. Будет подсказывать ему, что делать, помогать планировать, рассказывать как тестировать и как писать тесты.
Разработчик абсолютно не обязан разбираться в предметной области, кроме нишевых (игры, банки, драйвера и прочее), но в этом случае ему выдаётся консультант. При этом консультант может вообще не уметь программировать и приглядывать за программистом он просто не может.
Здравствуйте, Kolesiki, Вы писали:
M>> — понимать ассемблер
K> И формат 3.5" дискет. Тебя чё, разморозили что ли??
Как можно быть хорошим программистом и не понимать ассемблер при этом ?
Это же не равносильно не понимать, как твой код в итоге работает. Даже если он на каком нибудь питоне. Ведь всё в итоге уходит в нейтив, и исполняется на CPU (GPU пока вычеркнем).
Здравствуйте, copypaste, Вы писали:
C>Поэтому, кстати, "20-летний сениор" — это как "ортодоксальный еврей", оксюморон. Для того чтобы набраться опыта нужно время.
Я начал программировать в 13 лет.
В 14 мне стало мало скорости ЯВУ, выучил ассемблер, по единственной доступной матричной распечатке таблицы команд, в которой опечатки были на каждой третьей строке.
В 15 написал первую игру полностью на высокооптимизированном ассемблере, порядка 4kloc. Предварительно отреверсив десяток фирменных игр, чтобы изучть все подходы к реализации быстрой графики. Плюс все сопутствующие утилиты сделал, включая редактор уровней и уровни в нём. По технологиям игра не уступает фирменным (на той платформе).
В 18 лет уже на IBM PC экспериментировал с 3D графикой, делал свой растеризатор, перспективную коррекцию при текстурировании. Иннер-лупы тоже на ассемблере, чтобы можно было анимации делать, а не рендерить кадр полчаса.
И это во времена когда не было или только начинал появляться интернет.
Тогда компьютер был у 1 из 100, компьютеры эти были в ТЫСЯЧИ раз слабее сегодняшнего недорого ПАЯЛЬНИКА , а основным источником знаний был отладчик и чужой код.
Сейчас набраться опыта в миллион раз проще. Проблема может быть только в отсутствии интереса (и лени).
Здравствуйте, De-Bill, Вы писали:
DB>Самый простой пример Кармак, который в 26 был одним из самых "влиятельных" разработчиков индустрии компьютерных игр.
Забавный факт: Blizzard, для своего Warcraft-1 сетевую часть по протоколу IPX писала, основываясь на сетевом коде из DOOM.
Здравствуйте, IID, Вы писали:
IID>Как можно быть хорошим программистом и не понимать ассемблер при этом ?
Легко! Достаточно иметь общие понятия: о памяти — что ОЗУ — его мало, харда — много, но медленно, что есть несколько ЦПУ, способных без труда перемолотить пару сотен потоков. Что сеть — это всегда потенциальная точка сбоя. Короче, не зная вообще ни одной ассемблерной команды, можно абсолютно спокойно писать хорошие, оптимизированные программы.
Я понимаю, что вам, старпёрам, очень жалко своё время, потраченное на изучение таблицы GDT, написание DOS-резидентов, выжимание тиков из каждой перделки... но просто прими это — асм больше не игрок, просто приятная вещь для ПОНТОВ в курилке.
IID>Это же не равносильно не понимать, как твой код в итоге работает.
Ну в такую-то дурь не надо скатываться! Надо знать язык, а не во что разворачиваются лямбды или итераторы. И уж тем более, пофигу во что они превратятся после JIT. Как я говорил выше, не надо понтов на пустом месте — даже зная АСМ трёх машин, я не вижу сколь-угодно полезной особенности этих знаний при написании C# кода.
Здравствуйте, IID, Вы писали:
IID>... а основным источником знаний был отладчик и чужой код.
Ну, как грится, п***ть — не мешки ворочать! Прям таки и вижу малолетнего усатого гения, который по дампам игр(!!!) изучил теорию 3D, вектора, перемножение матриц... Родной, остынь! От понтов уже тошнит и прямо скажем, ЗДЕСЬ ты никого не переплюнешь, тут полно людей, которые тоже много чего делали. Главное — приходи к нам в 21 век: тут уже лямбды, DSL'и, макроязыки всякие... для жизни больше не нужен "адрес памяти экрана".
K>Ну, как грится, п***ть — не мешки ворочать! Прям таки и вижу малолетнего усатого гения, который по дампам игр(!!!) изучил теорию 3D, вектора, перемножение матриц...
Для работы с 3D уровня того времени не нужна была никакая теория, вектора, перемножение матриц. Достаточно было знания математики 8го класса или просто 2х формул (синус суммы и косинус суммы), всё остальное выводилось соображающим школьником на бумажке. А основным челенжем была оптимизация быстродействия. Писать на голом ассемблере, конечно, уже и тогда смысла не имело никакого, но ассемблерные вставки были вполне полезными.
K>Главное — приходи к нам в 21 век: тут уже лямбды, DSL'и, макроязыки всякие... для жизни больше не нужен "адрес памяти экрана".
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, mizuchi, Вы писали:
M>>ну отдели. опиши, что значит знать c++ на 100% и определи кол-во процентов на которое ты его знаешь. M>>а если не нашёл? но они есть. и сколько их есть — как ты можешь знать?
F>планка же меняется. F>находятся баги, появляются новые фичи.
F>нельзя стать синьором навсегда, чтобы потом выделываться перед молодёжью, какой ты клёвый синьор и как седа твоя борода.
при чём тут меняется она или нет? если она менятся, то ты ещё более себе противоречишь
даже если бы планка не менялась, то нельзя было бы знать что есть 100% знания
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, IID, Вы писали:
IID>>Как можно быть хорошим программистом и не понимать ассемблер при этом ?
K>Легко! Достаточно иметь общие понятия: о памяти — что ОЗУ — его мало, харда — много, но медленно, что есть несколько ЦПУ, способных без труда перемолотить пару сотен потоков. Что сеть — это всегда потенциальная точка сбоя. Короче, не зная вообще ни одной ассемблерной команды, можно абсолютно спокойно писать хорошие, оптимизированные программы.
K>Я понимаю, что вам, старпёрам, очень жалко своё время, потраченное на изучение таблицы GDT, написание DOS-резидентов, выжимание тиков из каждой перделки... но просто прими это — асм больше не игрок, просто приятная вещь для ПОНТОВ в курилке.
ну напиши например майнер крипты, который быстрее всех тех, что уже есть.
Здравствуйте, mizuchi, Вы писали:
F>>нельзя стать синьором навсегда, чтобы потом выделываться перед молодёжью, какой ты клёвый синьор и как седа твоя борода. M>при чём тут меняется она или нет? если она менятся, то ты ещё более себе противоречишь
при том, что объём знаний, требуемых для заявления об их обладании, меняется. то, что вчера было доступно кр00тому синьору, сегодня преподают на первом курсе.
и нет тут противоречий. нужно бежать со всех ног, чтобы просто оставаться на месте.
M>даже если бы планка не менялась, то нельзя было бы знать что есть 100% знания
поэтому экспертов такого уровня у нас и нету.
а вот в старых стагнирующих технологиях это намного-намного проще.
Здравствуйте, IID, Вы писали:
DB>>Самый простой пример Кармак, который в 26 был одним из самых "влиятельных" разработчиков индустрии компьютерных игр. IID>Забавный факт: Blizzard, для своего Warcraft-1 сетевую часть по протоколу IPX писала, основываясь на сетевом коде из DOOM.
да что там. половина геймдева на рубеже тысячелетий была на основе Q2/Q3.
Здравствуйте, alzt,
A>Разработчик абсолютно не обязан разбираться в предметной области, кроме нишевых (игры, банки, драйвера и прочее), но в этом случае ему выдаётся консультант. При этом консультант может вообще не уметь программировать и приглядывать за программистом он просто не может.
К сожалению, это очень распространенное заблуждение. Программист, который абсолютно не разбирается в предметной области, способен наворотить таааакого!... Плавали, знаем-с. И "консультант" ему тут не помощник. Во-первых потому, что консультант не понимает, как будет работать программный код программиста. И во-вторых потому, что некие "мелочи", нечто, для консультанта само собой разумеющееся и даже не требующее пояснений, для программиста может оказаться нежданным неизвестным фактором, способным отправить в /dev/null всю разработку целиком.
Здравствуйте, Vlad_SP, Вы писали:
V_S>И во-вторых потому, что некие "мелочи", нечто, для консультанта само собой разумеющееся и даже не требующее пояснений, для программиста может оказаться нежданным неизвестным фактором, способным отправить в /dev/null всю разработку целиком.
Это что за архитектура такая, что некие "мелочи" могут отправить всю разработку в мусорку? Если предусмотреть возможность изменений, то максимум потребуются некоторые переработки архитектуры. А минимум дописывание недостающего.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, IID, Вы писали:
IID>>... а основным источником знаний был отладчик и чужой код.
K>Ну, как грится, п***ть — не мешки ворочать! Прям таки и вижу малолетнего усатого гения, который по дампам игр(!!!) изучил теорию 3D, вектора, перемножение матриц...
Как говорится — смотрю в книгу, вижу фигу
Своё первое 3D я сделал в 16, ещё в 11 классе, в 1996 году. Вывел формулы поворота на основе арктангенса.
Матрицы, аналитическая геометрия была на 1-ом семестре первого курса. Т.к. мехмат. Узнал что в школе мне буквально чуть-чуть не хватило, одного преобразования, чтобы остаться с чистыми синусами и косинусами. Ну а матричная форма — она и так интуитивно понятна. Вот обратные матрицы — это уже веселее. Причём за константное время и без циклов. Чтобы, например, камеру из произвольного положения вернуть в начало координат, повернув весь мир.
На первом курсе мне было 17 лет.
Так что да — в 18 я имел весь нужный математический аппарат для 3D, включая сплайны и диковинные кватернионы.
DB>>Самый простой пример Кармак, который в 26 был одним из самых "влиятельных" разработчиков индустрии компьютерных игр.
IID>Забавный факт: Blizzard, для своего Warcraft-1 сетевую часть по протоколу IPX писала, основываясь на сетевом коде из DOOM.
На сколько я знаю, это какой-то спец писал, не Кармак. На сколько я понял, при всем величии Кармака как программиста, весь rocket science в движках,т.е. математику, разработал/сделал Абраш.
Кармак все это дело грамотно написал. Могу и ошибаться.
Здравствуйте, De-Bill, Вы писали:
DB>Писать на голом ассемблере, конечно, уже и тогда смысла не имело никакого, но ассемблерные вставки были вполне полезными.
Имело всю дорогу, до появления массовых 3D ускорителей.
Вот любопытная дока от одной из ведущих финских демо-групп второй половины 90х-начала 00х.
В ней разбираются самые быстрые иннерлупы текстурирования полигонов, фиксированная точка, учёт субпиксельной и субтексельной точности (помните "дрожащие" текстуры в sofware render движках?)
И оптимизация этих inner loop с учётом линий кеша и U- V- конвееров массовых тогда Pentium.
