Так ли хороши джуны?

    Преамбулка


    Эта статья является анализом другой статьи: Если вы не нанимаете джунов, то не заслуживаете сеньоров


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


    Я оставил по возможности оригинальное оформление, а свои комментарии отметил отдельно.


    Ну и желтый заголовок тоже оставил, немного видоизменив.


    Поехали.




    Позвольте рассказать вам историю об одной очень успешной компании, совершившей большую, глупую ошибку:


    Мы не нанимаем младших программистов и интернов… Если не заводить щенка, не придётся убирать лужи.
    --Netflix

    Комментарий. Заголовок желтый и введение говорит о том, что дальше будет раскрыта суть ошибки и стремительное падение этой компании. На самом деле нет.


    Я был совершенно поражён, как некое корпоративное нечто умудрилось представить щенков в отрицательном свете, да ещё кого-то этим убедило. Щенки — самые чистые создания на Земле, живая пушистая радость! Лучики света в одиноком мире. Но перейдём к сути.


    Комментарий. Щенки не могут поддерживать сами себя в чистоте и самостоятельно питаться.


    Многие компании последовали данной стратегии «нанимать только сеньоров». Они обосновывают это так:


    • У нас нет времени и ресурсов нанимать младших программистов; мы слишком быстро развиваемся.
    • Наша компания может себе позволить сеньоров, так что в джунах нет необходимости.
    • На текущем этапе мы не можем позволить себе ошибки. Ставки слишком высоки.
    • Наш процесс предоставляет сотрудникам большую автономность. Мы не готовы держать джунов за ручку, как они в том нуждаются.
    • Мы хотим заложить фундамент продукта прежде, чем начнём нанимать неопытных сотрудников.

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


    Комментарий. Всегда было интересно, из какого пальца высасывается то, чего не было в оригинальной фразе. Где было про долг и про бюджет? Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.


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


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


    Кстати говоря, в США более 100 000 IT-компаний, и что-то я не слышал, чтобы хоть один CEO сказал «подумаешь, ошибки!» или «надо бы спустить куда-нибудь лишний бюджет». Так что внимание, организации, где «джунам вход воспрещён»! Какими бы вы ни видели свои выгоды, как бы вы ни обосновывали свой лайфхак, реальность такова, что вы всё это себе выдумали. Нет никакого конкурентного преимущества в избавлении от джунов. И вы только что продемонстрировали миру свой проблемный менеджмент.


    Комментарий. Пока не видно доказательств, что эти 100 000 IT компании представляют собой эффективную среду для разработки, более эффективную, нежели у Netflix. Все это — жонглирование домыслами и эмоциями.


    Hostility to junior developers is an easy way to spot a toxic company culture.
    — April Wensel (@aprilwensel) 1 августа 2017 г.

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

    Комментарий. Где тут враждебность? Никто не говорит, что джуниоры — враги. Их просто не нанимают. А еще не нанимают, например, слесарей и художников. Тоже проявляют враждебность? Это называется "подмена понятий".


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


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


    Предотвращение проблем


    Если вы отказываете младшим программистам потому, что они «создают проблемы», то вы также машинально посылаете сотрудникам важное сообщение насчёт корпоративной культуры: ошибки недопустимы. Вы создаёте образ компании, которая увольняет кого-нибудь всякий раз, когда ложится сервер. Сколько бы вы ни платили, никто не хочет работать в среде, которая не даёт уверенности в завтрашнем дне. И попытки запугать программистов, чтобы те не совершали ошибок, множит культуру страха и угроз, что катастрофически сказывается на психологическом здоровье и продуктивности.


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


    Вы можете возразить, что такое отношение побуждает программистов проявлять осторожность и создавать процессы, защищающие от ошибок: например, автоматическое тестирование, QA, аварийное переключение, защита доступа и обратимые правки кода. Но данная теория ставит телегу впереди лошади. Если политика компании побуждает создание подобных подстраховок и компания сама предоставляет программистам достаточно времени и ресурсов для этого, тогда культура недопустимости ошибок не нужна и бесполезна; большинство проблем будет отловлено задолго до продакшена. И каждый программист, будь он младший или старший, предпочитает среду, где надёжные процессы защищают от катастрофических ошибок.


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


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


    Комментарий. Да, давайте поднесем обезьяну к атомному реактору и посмотрим, насколько системы безопасности надежны. Ну чтобы побыстрее вскрыть защиту. Я уже начинаю переживать за умственные способности автора.


    Само собой, вам понадобится несколько старших программистов и ops-лидов, чтобы заложить фундамент и создать прецеденты для отказоустойчивого цикла разработки. Никто не предлагает нанимать только младших программистов. Но если ваш офис действительно серьёзно относится к ошибкам — другими словами, ошибки отлавливаются рано и часто — то младшие программисты как раз пригодятся. И все уровни программистов будут больше удовлетворены своей работой, поскольку отказоустойчивость освобождает их для создания хорошего софта (вместо постоянного тушения пожаров) и охраняет их вечера и выходные.


    Комментарий. Речь не про боязнь ошибок, речь про эффективность и продуктивность. Эту ложную конструкцию автор повторяет из раза в раз, доказывая, что все плохо. Все плохо, да, но только с исходными посылками.


    Экономия денег


    Согласно Indeed, средний Junior Software Engineer получает $55 394 в год, в то время как Senior Software Engineer — $117 374 в год. Сеньоры стоят более чем в два раза дороже, чем джуны.


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


    Комментарий. Известно, что разница в продуктивности между разными программистами может достигать до 25 раз. Поэтому 2 раза просто ни о чем.


    Но этим картина не исчерпывается, и вам встанет в копеечку бездумное и ленивое обосновывание повышенных затрат как издержек ведения дел.


    Комментарий. Даже если вы нанимаете дворников для программирования, включая младших разработчиков, то это всегда справедливо, вне зависимости от.


    Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $28 в час за написание этого кода — или вы можете заплатить $59 в час написание того же кода. Так или иначе, результат будет мало отличаться. Если вы нанимаете только сеньоров, то вы платите втридорога за существенный объём простой работы.


    Комментарий. Если в компании существенный объем работы достаточно тривиален, то тогда да. Но вряд ли тогда компания может считаться высокотехнологичной. Сложность инфраструктуры задает серьезный первоначальный барьер, с которым может не справиться (или справиться с трудом) младший разработчик.


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


    Комментарий. Зависит от сложности проекта. Бывает, что проще уволить и нанять хорошего специалиста, чем ждать, когда "джуниор" начнет вдуплять в проект.


    Ранее упомянутый программный клей и предметно-ориентированный (domain-specific) код составляют по меньшей мере половину всей разработки. Оставшееся — тот код, который действительно нуждается во внимании старшего специалиста с пользой для результата. Но даже с этим кодом младший программист может проделать впечаляющую работу при достаточном доступе к образовательным ресурсам и советам опытного наставника.


    Комментарий. Бывает, что на луне растут грибы. Аргументация в стиле "а может быть и так", она, конечно, может иметь место, но основание для этого я не вижу никаких.


    Ввиду этого пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости. Если ваша цель — максимальная продуктивность с минимальными затратами, то такая пара джун+сеньор должна стать фундаментальной молекулой вашей организации.


    Комментарий. А может и не стать.


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


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


    Развитие карьер


    Если вы не нанимаете младших программистов, то посылаете ещё одно сообщение сотрудникам — что вы не знаете, как устроено развитие карьеры.


    Sometimes when companies say they're not hiring junior developers I want to shake them by their hoodies and yell, where do you think senior developers come from?!
    — Kate Heddleston (@heddle317) 13 сентября 2018 г.

    Иногда, когда компании говорят, что не нанимают младших программистов, мне хочется схватить их за грудки и закричать: а откуда, по-вашему, берутся старшие программисты?!

    Комментарий. Если в компании нет младших разработчиков, то как им можно посылать сигнал? Посылать сигнал в таком случае можно лишь вовне. У автора имеются многочисленные проблемы с получением и интерпретацией сигнала. Я вот почему-то получаю сигнал такой: "рядом с тобой будут работать крутые специалисты, ты сможешь научиться очень многому, и тебе не нужно будет объяснять очевидное."


    Опять же, речь не об исполнении корпоративного гражданского долга и не об «участии в развитии» IT-сообщества. Речь о превращении вашей компании в достойное рабочее место, куда программисты захотят устроиться и остаться достаточно надолго, чтобы внести ощутимый вклад.


    Комментарий. Без базара. Только за!


    Мне случалось слышать от программистов: «Надоело менять названия должностей. Я просто хочу навсегда уже остаться старшим программистом.» Однако никто ещё мне не говорил: «Надеюсь, я больше никогда не получу прибавку к зарплате, не узнаю ничего нового и не буду признан за свои заслуги». И, как ни странно, ресурсы, необходимые для поддержания и амбициозных карьеристов, и усидчивых, но увлечённых старших программистов примерно одинаковы. Необходимы способы изменения и признания хорошо сделанной работы, достаточный объём образовательных ресурсов и разнообразие проектов разного возраста в пайплайне разработки. Вам нужно создать чувство развития, даже для тех, кого продвижение по службе не интересует.


    Комментарий. Старший программист — это начало большого пути. И между ними тоже существуют градации. В любом сложном проекте старший программист будет развиваться. В современной разработке практически не существует потолка в развитии.


    Но не замыкайтесь на этих ребятах. Их меньшинство. Большинство тружеников IT не собираются 40 лет оставаться старшими программистами. Они мечтают стать программными архитекторами, тимлидами, техническими директорами и основателями студий. А компания, которая кичится своим безразличием к росту карьеры, обнаружит себя внизу списка перспективых работодателей.


    Комментарий. "Обнаружит себя внизу списка" — это про Netflix? Netflix topped a new list of “50 Best Places to Work for New Dads,” with several other Silicon Valley tech firms landing on the lineup and offering stiff competition to woo working fathers.


    I only recruit senior devs.

    The trick is, I recruit some of them earlier in their career.
    — Reginald Braithwaite (@raganwald) 17 сентября 2018 г.

    Я нанимаю только старших программистов.
    Хитрость в том, что некоторых из них я нанимаю в начале карьеры.

    Комментарий. Это самая офигенная хитрость. И я только за. Эти люди действительно решают и могут сделать многое для компании. Однако тут есть маленькая проблемка: как их найти? Примерно понятно, как увидеть в программисте "старшего": объем знаний у него в наличии. В перспективном начинающем программисте ты должен заглянуть в хрустальный шар и увидеть будущее. Я не встречал, чтобы такой подход хорошо масштабировался и работал в рамках большой компании. Это всегда риск и можно легко попасть в молоко.


    Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна». Очень впечатляет и очень большая редкость. Такой человек чрезвычаяно важен для компании — он знает всё о продуктовой линейке, он видел код всех проектов в радиусе ста метров, и он поработал со всеми сотрудниками компании. Он способен предлагать нововведения в рамках компании как никто другой. А компания зарабатывает несчётные дивиденды от труда этого человека, потому что смогла понять, как удержать его интерес восемь лет — примерно 1/10 средней продолжительности жизни. Это свидетельство успеха корпоративной культуры. Это признак офиса, в котором царит боевой дух, в котором признание находит всякую хорошо выполненную работу, а интересные проекты ждут за каждым поворотом.


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


    Заявлять «мы не нанимаем джунов» — это, напротив, открытое признание, что компания не готова сыграть роль в чьей-либо карьере. Это фактически демонстрация стагнации: компания хочет привлечь опытных и талантливых программистов, которые будут совершать свой вклад ради одного лишь оклада. Некоторые согласятся на такие условия, но их лучшей работы вы так и не увидите.


    Комментарий. Заявлять "Заявлять «мы не нанимаем джунов» — это, напротив, открытое признание, что компания не готова сыграть роль в чьей-либо карьере." — это открытое признание, что у автора проблемы с логическими цепочками и взаимосвязями.


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


    Комментарий. Интересно, почему гугл и фейсбук имеют высокую планку? Наверно, они "сужают пайплайн (?) найма и укорачивают время сотрудников в компании".


    Написание отличного софта


    У младших программистов есть ряд уникальных черт, которые их более опытные коллеги обычно утратили. Одна из них — незамутнённый оптимизм. Другая — готовность идти за лидером. Но, возможно, самая важная черта, которую предлагают младшие программисты — это отсуствие багажа. Старшие программисты видели восход и закат технологий, провалы проектов, команды, раздираемые внутренними конфликтами, и прочий быт IT-отрасли. Они накопили строгие убеждения и часто делают чересчур далекоидущие выводы, предполагая, что один сценарий успеха (или провала) развернётся точно так же и для другого проекта или команды. Что может привести к нежеланию разбираться в нюансах нового поля проблем.


    Комментарий. То ли дело "джуниор". Может наговнякать тонну неработающего бажного кода с незамутненным оптимизмом и отсутствием багажа без далекоидущих выводов. Просто мечта!


    Companies so eager to only hire senior people often forget that unlearning what doesn't apply can take longer than learning what does.
    — DHH (dhh) 31 июля 2017 г.

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

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


    Иногда задача проект-менеджера — это сказать «Я знаю, что это не сработало там, но, может, сработает у нас». А младший программист — обычно лучший кандидат, чтобы проверить такую теорию: он может собрать пробу идеи или прототип, не втягивая в это предрассудки, накопленные старшим программистом за годы. В качестве младшего программиста я часто выполнял такую работу, проверяя новые инструменты и технологии, переписывая фрагменты кода альтернативным образом, испытывая идеи, которые другие сотрудники поспешно отмели. Я часто открывал улучшения архитектуры, и софт компании становился осязаемо лучше. В некоторых случаях удавалось ускорить загрузку страницы на порядок; или несколько страниц соединить в одну, избежав недель поддержки в будущем; или избавиться от неэффективных технологий, которые привели бы к потере времени. Подобные преимущества неотягощённого, свежего взгляда нельзя упускать.


    Комментарий. Зависит от многих обстоятельств. Автору просто повезло самому с собой. По опыту могу сказать, что часто это не работает.


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


    Комментарий. Также можно убедиться в том, как легко отличный продукт превращается в помойное ведро. Достаточно вспомнить про Borland.


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


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


    One underrated programmer attribute is the ability to write code that average or mediocre engineers can easily read, modify, and extend.
    — Jamon Holmgren (@jamonholmgren) 17 сентября 2018 г.

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

    Комментарий. Во истину!


    Если заменить «средний или посредственный» на «младший», то сразу увидите систему. Кодовая база — абстрактный отпечаток критического мышления своих авторов. Здравое сочетание младших и страших программистов создаёт возможность для упрощения кода, которое ускоряет написание фич с течением времени.


    Комментарий. Типичный пример, как легко из базовой правильной посылки можно простым росчерком пера превратить логическую цепочку в неправильное следствие. Т.е. для того, чтобы писать просто, нужно иметь людей, которые бы сложное не понимали? Я почему-то всегда считал, что простое лучше сложного вне зависимости от. Для меня понимать простой код проще, чем сложный, извиняюсь за тавтологию. Т.е. это выгодно всегда, вне зависимости от степени прошаренности.


    Подводя итог: широко распространённый в IT принцип «только сеньоры» недооценивает младших программистов. Это плохо сказывается на всех, особенно когда организация считает, что без начинающих специалистов всё будет даваться легче. Хотя некоторые подобные компании финансово успешны, можно представить себе колоссальные растраченные суммы которые приходится сносить их бюджету из-за такого подхода.


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


    Если ваша компания обгоняет конкурентов по данному вопросу — то есть знает, как нанимать, обучать и удерживать младших программистов — то вы сами уже ощущаете все те преимущества, которые я лишь поверхностно описал в данной статье. У вас ниже текучка, выше разнообразие специалистов и меньше оверхеда, чем у конкурентов. В вашем софте меньше багов и больше радости. Есть, конечно, и другие факторы. Но положительный подход к младшим программистам — важный знак качества офиса на всех уровнях.


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




    Выводы


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


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


    Я не против джунов. Сам когда-то был таким. Джуны офигенны. Иногда смотришь на начинающего программиста и понимаешь, что тебе тут будет делать нечего после того, когда он подрастет. Ну а пока поработаю немножко.


    С моей точки зрения, в разных проектах требуются разные люди с разной квалификацией и специализацией. Невозможно сделать универсальный рецепт. Тем не менее, я считаю, что Netflix сделал очень интересный прецедент, и такой подход заслуживает, как минимум, внимания.


    P.S. Заметили большую и глупую ошибку, о которой говорил автор в начале статьи?

    Поделиться публикацией

    Похожие публикации

    Комментарии 230
      +12
      Один вопрос автору — сеньор будет в восторге от того что 80% своего времени будет круды писать? И стоит ли за эти круды платить по 40-50 баксов в час?
        0
        А если в компании нет таких задач?
          +6
          Таких компаний крайне мало. Я думаю даже в Америке таких не большинство. В том же Гугле тысячи работников, думаешь они все решают сложные задачи? Большинство те же круды пишет. Читал как то статью чувака, который поработал там
            –1
            В том же Гугле тысячи работников, думаешь они все решают сложные задачи?


            Гуглевские джуны != обычным джунам.
            Есть же статьи на Хабре от тех, кто там работал. Даже младшие программисты Гугля — это далеко не каждая компания таких сеньоров может себе позволить/не каждая компания нуждается в таких слишком over-квалифицированных сеньорах.
              +3
              Это неправда. Полно джунов только после универа. Не глупые, конечно, но и не мега-кодеры и уж тем более не сеньоры.
                –2
                Джуны гугла знают, как умножать матрицы? Могут написать обход графа в ширину и в глубину? Имеют представление о системах управления версиями? Имеют базовые знания о протоколе HTTP, чтобы записать простой запрос и простой ответ?

                Если всё это — да, то
                Гуглевские джуны != обычным джунам
                  +5
                  Я все это знал устраиваясь джуном в местную контору на 3-м курсе. Вроде как это базовые вещи, которым учат в универе.
                    0
                    Одно дело, учат, а другое дело — научили.
                      +3
                      Если человека учили умножению матриц, то не важно, насколько качественным был процесс. Даже если просто сказали, что есть вот такая штука — умножение матриц, уже можно пойти в интернет и погуглить, что это, как делать и зачем.
                        –3
                        Это не тот случай, когда забылось со временем за ненадобностью. А тот случай, когда в своё время не было понято, а на экзаменах списано/заучено/вымучено на тройку. Тут нагугленная статья не поможет.
                          0
                          Мне помогает. Умножение матриц мне требуется примерно один раз в год, и каждый раз я ее забываю и вспоминаю через гугл или записанную себе же на будущее шпаргалку.
                          +2
                          Честно признаюсь учили, но тк не надо то не помню с чем это едят, будет надо поищу
                            0
                            В плане «надо будет — погуглю» есть тонкая грань: чтобы нагуглить, надо знать хотя бы чуть-чуть. Если не знать совсем ничего, в гугл полетят запросы уровня «как сделать сайт».
                    0
                    Не глупые, конечно, но и не мега-кодеры и уж тем более не сеньоры.

                    В иных фирмах сеньорами называют 23-летних, как раз с двумя годами опыта (что, в самом лучшем случае, имхо, крепкий джун или начинающий миддл) после ВУЗа, не мега-кодеров, в Гугль бы собеседование не прошли.
                    Но они вполне себе «сеньоры».
                +2
                по моему опыту — в любой компании всегда есть пакет задач, в которых нужно поправить запятую, поменять цвет кнопки, исправить опечатки

                как минимум один джун мог бы на этом сидеть, пока старшие решают хорошие проблемы
                Ну и можно давать джуну время от времени настоящие задачи — чтобы рос
                  –2

                  По моему опыту, как раз в таких задачах, сеньоры и лиды показывают очень высокий перфоманс (когда не ленятся). Потому, что исправить сам цвет — 2 секунды. Найти это место в коде — до 30 секунд для сеньора и до часа для джуна.

                    +1
                    Для джуна это какое-никакое изучение проекта/инструментов, а для сеньора может оказаться еще одной унылой задачей, непосредственно сделать которую быстрее чем уйдет времени на около-задачную бюрократию.
                      0
                      Для джуна это какое-никакое изучение проекта/инструментов

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

                      Так может проблема в ней?
                        +2
                        Хм, знаете, я замечаю такую интересную вещь — чем сильнее программист, тем более понятный его код.
                        Так как в реальности действительно сложные в реализации штуки встречаются все таки не так часто, то весь остальной код, если он нормально написан, понимается даже непрограммистами в виде специалистов из смежных областей. Джунов в эти сложные штуки пускать не будут, а с остальным, при условии нормальных синьоров, не должно быть для них проблемой.
                        И причем тут уровень абстракции?
                          0
                          Хм, знаете, я замечаю такую интересную вещь — чем сильнее программист, тем более понятный его код.

                          К сожалению, это правило работает не всегда. Например, далеко не всякий код на C# с активным использованием Reflection (и особенно Reflection.Emit) будет понятен с ходу, даже если его написал крутой специалист.
                          0
                          Уровень абстракций как раз для джунов нужен высокий. Грубо, сеньоры пишут в машкодах, а джуны юзают fopen(). Сеньоры пишут ORM, а джуны объектики создают и только в теории знают, что в проекте есть и база данных.
                        0
                        По моему опыту — это зависит от времени, потраченного на изучении проекта. Сам пришел джуном, сначала искал долго, через 2 недели познакомился с очень удобными штуками в IDE и понял структуру проекта, после чего у меня весь поиск свелся к минимуму.
                    +2
                    В 21 веке у вас есть кодогенерация и рефлексия, что бы круды писали сами себя, а вы только создавали модели и регистрировали ее.

                    Если у вас 80% времени нужно писать круды — вряд ли ваша компания может назвать себя высокотехнологичной.
                      +15
                      Истинный Сеньор!)) Там где можно за неделю написать круд, он за месяц напишет рефлексивный кодогенератор круда, или вы просто спринг дату имели ввиду?
                        0
                        Зависит от того, что вы используете. У большинства популярных фреймворков уже есть библиотеки для быстрой имплементации crud.
                        Если же нет, то таки да, взял бы и написал. И вместо четырех месяцов был бы один. Вы же не пишете crud один раз и навсегда, обычно сущности потом добавляются.

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

                          я не очень понимаю, что такое писать круд вообще, для меня это написать один родительский дженерик класс, который реализует 4 метода. Что имеет ввиду автор не до конца понятно, но он наверно имеет ввиду написание любого бойлерплейт кода))
                            0
                            Вы не поверите, но тот же swagger есть и под Java.
                              +1
                              какой же он кривой этот сваггер (именно кодогенерация).
                              –1
                              Карма -9. По тонкому льду ходишь, Дмитрий ;)
                                0
                                для меня это написать один родительский дженерик класс, который реализует 4 метода.

                                а как именно он этим методы реализует? ручками или через библиотеки?
                              0
                              Написал реализацию круда на дженериках где-то за один день, брат жив, теперь только структуры данных описываю.
                            –2

                            Хороший сеньор, написав 5 крудов, сделает генератор крудов, и после этого их будет писать БА. Либо этот же сеньор, но со скоростью 5 крудов в минуту. И чтобы достичь такой же производительности, надо ну очень много джунов + представьте себе каскадные изменения в таком копипастном коде.

                            +4
                            Согласен с тезисами статьи. Не согласен с подачей.
                              +16
                              Автор про истинно технологичную фирму, где каждая задача — это челлендж для сеньора, а формочки и круды сами пояляются.

                              Вообще, удел джуниоров — кодить сложно, сеньор должен кодить просто, чтоб любой джун понял. Поэтому, если джун не может разобраться в Вашем коде, подумайте, а сеньор ли Вы, а не гуано ли ваша архитектура, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.
                                +8
                                getUserById, проходит через 100 классов, прежде, чем добраться до базы.

                                О, выглядит как кишки андроида. Там считается нормой вложенность в 100 классов.
                                  0
                                  Вы не правы. Если джун не знает про, к примеру, Observer, то ему любая реализация этого великолепного паттерна покажется гуаном в плане архитектуры, ведь можно и проще сделать — раз. Чтобы написать большой и сложный продукт, нужно использовать стратегические и сложные решения — два. Особенно, если компания высокотехнологична и, что называется, living on the edge, работая с тем, для чего еще не существует best practices.

                                  удел джуниоров — кодить сложно

                                  Это да. По факту, именно джуны создают решения, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.

                                  Поэтому, если джун не может разобраться в Вашем коде, подумайте, а сеньор ли Вы

                                  Про это — вывернутую логику — и автор этой статьи писал. Если джун не может разобраться в моем коде, то это далеко не означает, что моя архитектура плоха. Но это уже значит, что джун не понял. Что ж, ок, я подумал, и пришел к выводу, что я-таки сеньор, а джун по-прежнему не понимает мой код, мои действия?
                                    0
                                    ведь можно и проще сделать — раз
                                    И чем можно заменить Observer чтобы он сохранил свои свойства и это было проще?
                                    джун по-прежнему не понимает мой код, мои действия?
                                    Позвать мидла. Если ему понятно — учим джуна, если не очень — код в корзину.
                                      0
                                      Про сохранение свойств речь не идет. Проще в данном случае может означать «написать все ручками», а не мудрить с какими-то слушателями. Причем на первых этапах развития проекта это действительно может казаться джуну лучшим решением.

                                      Позвать мидла

                                      Гениально! Вот и разобрались)
                                  +3
                                  Джуны по определению не так хороши, они в начале становления себя как специалиста, но это не повод не нанимать их…
                                    +6
                                    А еще это не повод их нанимать.
                                      –7
                                      Мне вот интересно, это такой шаблон мышления только в странах СНГ что ли…
                                        +1
                                        А вы статью-то прочитали? Там конкретные примеры даже есть.
                                          +1
                                          Статья статьей, но ведь и тот кто писал статью, да все были в свое время джунами в своей области и ведь их наняли где-то и кто-то, почему теперь такое отношение? Это мне напоминает покорителей дефолт-сити, которые через год себя считают себя коренными жителями и имеют высокомерное отношение к жителям провинции.
                                            +2
                                            Статья статьей, но ведь и тот кто писал статью, да все были в свое время джунами в своей области и ведь их наняли где-то и кто-то, почему теперь такое отношение?


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

                                            Если же совсем другая компания работает по другой экономической модели и в ее модели не нужно экономить на программистах, нанимая джунов — то почему нет…
                                              +2
                                              > да все были в свое время джунами в своей области

                                              Ну как… Я, например, первой работой программистом пошел на мидла. Почему люди в институте балду гоняют, что бы потом пойти ждуном(но какая описка) джуном и 2 года круды писать — не знаю. Какой опыт им эти круды принесут — тоже не знаю.
                                            +2
                                            При чем тут СНГ вообще?
                                            Если, например, частная клиника будет нанимать только лучших врачей, вам жe нe покажется это странным? Скорее всего именно в эту клинику вы захотите обратиться если надо будет, а не в ту где врачи интерны учатся на вас и пробуют новые подходы к лечению.
                                              +2
                                              А откуда эти лучшие врачи возьмутся, если их в интернатуру брать не будут?
                                                +6
                                                Ну, где-нибудь, сами, на pet-project'ах научатся.
                                                  +3
                                                  Боюсь из ветеринаров в терапевты не очень то и возьмут)
                                                    +2
                                                    Ну пусть на фрилансе где-нибудь в Зимбабве попробуют, научатся. потом приходят. Кто хочет, тот ищет возможности, кто не хочет — ищет оправдания. Так-то!
                                                  +3
                                                  если их в интернатуру брать не будут

                                                  Я говорил про одну конкретную частную клинику. Пускай учатся там где берут интернов.

                                                  Моя мысль не в том что джунов не надо нанимать, а о том что не стоит судить компании со своей колокольни.

                                                  Сейчас я работаю в компании которая нанимает джунов и интернов — и все ОК, до этого работал в компании в которой были только синиоры и выше — и тоже все было ОК. Никаких негативных вещей из статьи вроде токсичной кутьтуры, невозможности ошибаться и т.п. Просто не было задач для младших разработчиков и не было времени их выращивать.
                                                    +1
                                                    А откуда эти лучшие врачи возьмутся, если их в интернатуру брать не будут?

                                                    А че, где-то кто-то написал, что теперь «принципиально во всех до единой больницах не будут брать интернов без опыта»
                                                    Одна-единственная фирма, которая может себе позволить не иметь дела с неспециалистами — не берет не специалистов. Специалистов для нее готовят другие компании.

                                                    Больниц и фирм ИТ-шных много.
                                                    Где подготовиться джунам/интернам — проблемы нет никакой.

                                                    Да, я понимаю, всем нам бы хотелось начинать карьеру с Google/Netflix/Microsoft. Но это не обязательно. Гораздо проще — и реалистичнее — поступить сначала на работу в фирму попроще, набраться опыта. После чего вас возьмут в «бодишоп» уже с желанием, после него — уже можно попытать счастия в высокотехнологичной компании, ну а уж потом — Netflix, Google…

                                                    Начните уже с районной поликлиники (ну или что там у врачей считается аналогом мелкой фирмочки по клепанию веб-сайтиков)
                                                      0
                                                      Одна-единственная фирма, которая может себе позволить не иметь дела с неспециалистами — не берет не специалистов. Специалистов для нее готовят другие компании.

                                                      Больниц и фирм ИТ-шных много.
                                                      Где подготовиться джунам/интернам — проблемы нет никакой.

                                                      Проблема в том, что в пределе всем выгодно не готовить специалистов, а получать их падающими с неба.
                                                        +3
                                                        Не знаю почему минусанули коммент MacIn, по сути он прав. Не многие компании согласны тратиться на обучение сотрудников, а с программистами такое не прокатит. Наблюдал в других отраслях проблему передачи знаний, в машиностроении и строительстве. Когда старые специалисты ушли на пенсию, а на их место никто не пришел. И свои знания они унесли с собой, так никому не передав их. Конечно, программирование остаётся молодой, востребованной отраслью и такое пока не грозит. Но раз взялись за пример из медицины, то сейчас там происходит подобное, что было в инженерных науках 25 лет назад. Из-за оптимизаций медицинский персонал, который занимается лечением сокращается, а административный увеличивается в разы. Талантливые врачи вместо лечения больных занимаются пластической хирургией в косметологических клиниках. Ну и для диагностирования и лечения ОРЗ вам не нужен светила мировой медицины, достаточен толковый терапевт. Надеюсь я правильно донёс свою мысль для читателей (если что, сильно не бейте).
                                                          +1
                                                          Но не у всех есть на это деньги) джунов чаще нанимают не кто кто растят специалистов, а те у кого денег только на них и хватает.
                                                            0
                                                            Точнее они их растят как могут, а потом ещё жалуются что этих выращенных переманивают зарплатами.
                                                            0
                                                            Вот только в этом пределе падать они не будут. И компании, которые начнут испытывать проблемы с кадрами и правильно поймут причины, изменят политику.
                                                              +1
                                                              Проблема в том, что в пределе всем выгодно не готовить специалистов, а получать их падающими с неба.


                                                              Никакие это не проблемы.
                                                              Реальная жизнь расставляет все по своим местам. И мечты работодателей испаряются тоже. Но Netflix может себе позволить.

                                                        0
                                                        Какой еще шаблон? Смысл моего утверждения — то, что «джуны по определению не так хороши, они в начале становления себя как специалиста», — это не повод их нанимать. Поводом может быть что-то другое: более низкая з/п, потенциал и т.д. А нанимать джунов потому, что они хуже, — это какая-то… кхм… благотворительность получается.
                                                          0
                                                          Это не благотворительность, это отложенная прибыль, специалист вырастает и начинает работать лучше, принося бОльшую прибыль, но хочетсяя прям здесь и сейчас, а это как раз менеджерская фича, определенному менеджеру хочется скорее доложить руководству, что работа сделана, чтобы получить свои плюшки, хотя если взять разработку в Нидерландах, то насколько я слышал там нет такой гонки, делается упор на качество, а не на скорость.
                                                            +1
                                                            Читайте внимательнее, с чем спорите.
                                                              0
                                                              Или специалист вырастет и уйдёт к конкурентам, которые смогут предложить немного больше за счёт того, что не платят джунам и не тратят время сеньоров на них.
                                                                0
                                                                Ну так надо заботиться о своих специалистах и тогда мысль уйти у них не будет возникать
                                                                  0
                                                                  У компании, которая не растит специалистов, больше материальных возможностей заботиться о специалистах при прочих равных. Грубо, при ФОТ на разработку в 100 000, одна компания может предложить 20 сеньорам по 5 000, а другая только по 4000, потому что ещё 20 джунов по 1000. Можно рассчитывать, что джуны варостут, будут получать по 4000 и отказываться получать 5000 из чувства благодарности, но несколько наивно это, по-моему.
                                                          +1
                                                          Ну собственно говоря, при подборе людей, стоит обращать внимание не только на «джун/сеньор», есть ещё другие критерии.
                                                            0
                                                            Вот да. К слову, почему-то сейчас стало очень модно упускать из виду такую характеристику как потенциал человека. При наличии у человека соответствующих способностей, необходимыми знаниями вполне можно овладеть, но вот сами способности — это врожденное.
                                                        +4
                                                        Спасибо за разбор переведённой мною статьи! Статья была переведена из-за интереса к теме, и в комментариях и вашем разборе нашлось много пищи для ума.
                                                          +26
                                                          Каеф наверное писать статьи, выдирая куски из чужого материала и оставляя никому не интересные, свои собственные комментарии.
                                                          Автор, если твой подход к написанию — это паразитированние на чужих работах, а все твое мысленное усилие было приложено лишь к плевкам вида «комментарий: », то пожалуйста, не пиши ничего больше.
                                                            +17
                                                            А я больше скажу — Весь хабр начал напоминать Пикабу.

                                                            Один накинул говна на вентилятор статьёй про собеседования — посетителей зацепило — автор получил награду… и давай всю ленту собеседованиями засирать. Причём ничего адекватного там не было. Каждый автор старается где-нибудь кого-нибудь зацепить, что бы было большое обсуждение.
                                                            Так же про Джунов/Сеньёров.
                                                            Напоминает редакцию AdMe в лучшие его годы — так и вижу кучу авторов бегающих за рейтинговыми постами и только и думающие «чего бы теперь написать». Да лучше пусть будет Спросите Итана, которого я не читал, но который не вызывает никаких негативных эмоций присутствуя в ленте.

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

                                                              Напоминает редакцию AdMe в лучшие его годы — так и вижу кучу авторов бегающих за рейтинговыми постами и только и думающие «чего бы теперь написать»

                                                              Вместо авторов, которые хотят донести своё другим — авторы, которые сидят на зарплате и просто пытаются заработать себе на жизнь.

                                                              Что же получается, если автор хочет высказаться на больную для сообщества тему (а т.к. он является участником сообщества, то скорее всего для него это тоже больная тема), то он «сидит на зарплате» и «гонится за рейтинговыми постами»? То есть никакой рефлексивности у сообщества нет, все гоняются за рейтингами, так что ли?
                                                                +3
                                                                Нет, думаю вы правы. Тем более, что пользователи голосуют своими просмотрами/плюсами/комментариями — и по этим показателям — это интересно людям(или они просто не могут промолчать при виде провокационного текста).

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

                                                                Это всё мои хотелки, и они могут не совпадать с желанием большинства, но мне ещё неприятен этот слог — «токсический». ТС хуесосит другого ТСа за то, что тот хуесосит Джуниоров… жуть какая!

                                                                Но я тут всё же не прав — комментатор ниже тоже прав — Хабр всегда был таким ресурсом, просто тематика немного разная. С одной стороны яжматери, с другой яжруководители. Просто видимо сам начал чаще замечать это, т.к. пикабу тоже всё меньше доставлять стал удовольствия от прочтения(так то портал не плохой… я сравнивал с Пикабу, не в негативном качестве)
                                                                +3
                                                                А я больше скажу — Весь хабр начал напоминать Пикабу.

                                                                А он всегда таким и был. Люди везде одинаковы.
                                                                А насчет рейтинга — стоит все же взять на вооружение некоторые приемы Пикабу. Например в принудительном порядке ставить тег «без рейтинга» на подобные нетехнические посты и не давать за них карму.
                                                                  0
                                                                  Не забывайте, что карма на Хабре не имеет никакого отношения к статьям и голосованиям. Она абсолютно случайна, в том смысле, что почти не коррелирует с содержанием (разве что в экстремальных случаях). Это вам не рейтинг. Зачем нужно это дублирование, не понимает никто.
                                                                    +2

                                                                    У качества статей есть отпечаток на карме. Посмотрите на эти два профиля:
                                                                    image
                                                                    Ализару поставили больше трех тысяч оценок, но почти половину из них — в минус. Он выезжает на желтизне.
                                                                    А у Нулевого Пациента всего семьсот оценок, зато все в плюс. Он переводит технические статьи.

                                                                      +2
                                                                      Извините, а где можно посмотреть эти данные(742 х (96 — 4)%)?
                                                                      0
                                                                      А откуда вообще дробная карма берется? В правилах об этом вроде ничего нет.
                                                                        +1

                                                                        Вычитал где-то в комментариях, могу ошибаться:


                                                                        1. Если повысил карму или сделал приглашение юзеру, которого потом его забанили, то снимают 0.1 или 0.5 кармы.
                                                                        2. Если два юзера повышают друг другу карму, то с них снимают по 0.1 кармы.
                                                                        3. Раньше была некая "сила голоса", когда в зависимости от достижений твои голоса считались больше единицы.
                                                                        4. Был баг в api хабра, когда можно было было поставить любое дробное число как свой голос, а не только +1 или -1.
                                                                        0
                                                                        Это экстремальные случаи: очень популярные аккаунты. Да, на больших числах будут закономерности. Но на Хабре мало аккаунтов с сотнями голосов, они не показательны.
                                                                –14
                                                                Когда ты тупо эксплуатируешь устаревающую технологию — нужны сеньоры, знающие её от и до.
                                                                Когда ты хочешь содрать бабло, обманув инвестора демонстрацией умных, у которых на любой вопрос ответ отлетает от зубов — нужны сеньоры.

                                                                Но, если ты заботишься о будущем компании — джунов набирать необходимо, и сразу группами! Пусть сеньоры продолжают «писать фортрановские программы на любом языке », это обеспечит текущую работу. А новые технологии джуны освоят гораздо быстрее и лучше, потому что примут их как данное, без ломки себя.
                                                                  +6
                                                                  Как вы думаете, кто придумывает новые технологии? Джуны или сеньоры? Кто делает компиляторы на новые языки, джуны или сеньоры?
                                                                    0
                                                                    Молодые сеньоры, вчерашние джуны — по большинству, подавляющему большинству.
                                                                    И я думаю, Вам очень сильно повезло, если Вам встречались по преимуществу конторы, создающие новые компиляторы, а не использующие их.
                                                                    Хм, посмотрел Ваш же коммент чуть ниже — Вы там подтверждаете мои слова, по сути.

                                                                    Мне вот, кстати, повезло. Моя контора и конкретно мой отдел как раз создаёт новые технологии. И у их потребителей (приобретателей наших продуктов) очень характерная картина: там, где сеньора ставят на освоение, мы обречены месяцами выслушивать, как всё неправильно сделано и почему всё не заработает никогда. А там, где джуны — через короткое время уже идёт использование и профит. После чего джуна срочно повышают, и не дай бог, если его место займёт вытесненный вчерашним джуном сеньор :-)
                                                                      +6

                                                                      И это херовая схема. Это не джун быстро станет сеньером. Это он станет тимлидом в лучшем случае. Задача лида — натягивать тех специалистов на бизнес задачи. Задача сеньера — сделать хорошо и с умом и на перспективу. В споре этих двух противоположностей рождаются годные продукты.


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

                                                                        –2
                                                                        Вы несколько смешиваете пары джун/сеньор aka новичок/опытный и тупой/умный. «Тупой» (очень условно!) вполне может быть сеньором, если его хватает на то, чтобы сосредоточиться в узкой области. Тогда он может быть вполне успешен, успешнее многих умных с проблемой концентрации. Но ничего вне уже освоенноей технологии он не тянет. Таких сеньоров, на самом деле — подавляющее большинство. Я уже 40 лет программляю, насмотрелся.

                                                                        А джуны принимают новую технологию, как просто часть окружающего мира, они ничего другого не пробовали, и не знают, как трудно эту новую технологию постичь. Потому и справляются, практически все, что умные, что тупые.
                                                                        Научить их делать приличный код — совершенно параллельная, не пересекающаяся, задача. И говнокод, и изюминка — могут быть и в старой, и в новой технологиях. Но фокус в том, что старая технология, даже изумительно реализованная — не нужна. И потому-то не нужными становится большинство сеньоров. Другое дело, что сеньоры умеют очень хорошо защищать свои позиции, затаптывая джунов.
                                                                        Обычные проблемы, приведшие, кстати, в природе к появлению механизма старения, насильственно устраняющего сеньоров из эволюционного процесса.
                                                                          +3
                                                                          старая технология, даже изумительно реализованная — не нужна.
                                                                          Почему? Мешает вам пилить бюджет?

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

                                                                          Ну как хрестоматийный пример — BGA. Достоинства — компактность, большое число выводов. Недостатки -совсем иное оборудование для изготовления и ремонта плат, обязательная многослойность платы, то есть невозможность ручного исправления ошибок разводки… Дикая компактность нам не нужна — на тракторах и ледоколах места хватает, даже для беспилотников без BGA уложились в полпачки сигарет. Большое число выводов — ну так себе преимущество, нам пока и без BGA хватает. Зато без BGA быстрый цикл выпуска и модернизации платы. И даже первые экземпляры, с наляпанными проводочками и разрезанными дорожками — вполне пашут.
                                                                            –2
                                                                            Да-да, именно потому специалисты по изготовлению каменных рубил до сих пор настолько в цене.
                                                                            Серьёзно: области, где нет нужды скакать по технологиям — есть, и они вполне многочисленны. Ну так да, там сплошь сеньоры и сидят.
                                                                            Я — о другом, когда новая технология требуется. В этом случае коллектив, группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры. Ну да, к концу процесса они джунами быть перестают :-), но начинать нужно именно с таких.
                                                                              +1
                                                                              Я — о другом, когда новая технология требуется.
                                                                              Это огромная редкость. Обычно новые технологии — это попытка возложить свои затраты на тестирование и апробацию на другие фирмы. То есть придумывается технология, разводится хайп и куча глупых джуниоров начинают на своем опыте ощупывать границы её применимости.

                                                                              группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры.
                                                                              А выгоду получит тот сеньор, который новую технологию придумал. Потому что шишки будут набивать джуны из чужой компании.
                                                                                0
                                                                                Вот мы и вернулись к вопросу «а кто всё создаёт» :-)
                                                                                И ответ по-прежнему — молодой сеньор, недавний джун. Который просто не появится, если не бросать джунов в терновый куст. Конечно, есть гениальные исключения — но на то они и исключения.
                                                                                  +1
                                                                                  Да необязательно молодой. Важнее, что сеньор. Мало ли технологий придумано немолодыми?
                                                                                    +1
                                                                                    В этом случае коллектив, группа джунов, брошенная на её освоение и применение,

                                                                                    Вы не путайте освоение и создание. Если взять любую хайповую технологию последних лет, она создается бородатыми дядями из больших контор.
                                                                                    То что туда набегает толпа джунов и начинает ее «применять и осваивать» не является созданием технологии.
                                                                                      +1
                                                                                      Характерно, что толпа сеньоров не кидается, ибо и плюс и минусы видит до освоения. :-) Поэтому сеньоры новые технологии берут избирательно.
                                                                                  +1
                                                                                  Рубила принципиально не меняются уже хреновы тыщи лет. Переход на качественно новые материалы пару раз был — можно считать мажорными релизами, и рубилами версии 3.0 мы пользуемся лет шестьсот. И таких областей — подавляющее большинство, и считать стартапы духа «а давайте встроим в топор блокчейн и сделаем рукоятку из перфорированного углеволокна» чем-то кроме попила бюджета что-то не выходит.
                                                                                    +1
                                                                                    просуммировав, делаю два выводы:
                                                                                    1. Писатели комментов сплошь считают себя сеньорами и хором защищают позицию. Ожидаемо :-)
                                                                                    2. Деление джун/сеньор [в том числе по причине пункта 1] проводят по «тупой автор говнокода» и «высоколобый крылатый ангел». Что показывает очевидно узкий взгляд (не сеньоровский) и приверженность простеньким приложениям массового веба.

                                                                                    Как «лид» по принятой тут терминологии, и достаточно успешный (в нашей области наши продукты безусловно лидируют в России, применяются в нескольких странах, включая США, причём в США шире всего после России), скажу: говнокод вообще не проблема программиста — это проблема команды. Говнокода не бывает вообще — при правильно организованной работе с ревизией кода и выстроенным взаимодействием. Разница между разработчиками пролегает во времени поиска решений в тех местах, где нужно решения принимать. Сеньор находит их легко, джун — бьётся долго и решения хуже. Но и это соотношение действует в рамках уже принятого направления. Когда же начинается совершенно новое направление — я формирую под него именно группу джунов. Группа довольно быстро сортируется, в ней выделяются сеньоры… и пошла работа по направлению. Для последующего развития уже ставшей на ноги работы действительно нужны сеньоры — но они и появились преимущественно из той самой группы.
                                                                                    Соглашусь, что такой подход работает, когда компания развивается. Если она [вполне успешно] жуёт какое-то одно направление работ, то уже существующих сеньоров нужно куда-то девать, это, кстати, проблема.
                                                                                    Ну и напоследок — терминология просто недостаточна. Настоящий сеньор сам вырабатывает новое направление и предлагает его либо своей, либо другой компании. Вот таких — безусловно нужно брать в первую очередь, если, конечно, компания способна потянуть предложенное. Но таких людей всё же единицы, в довольно-таки массовое понятие «сеньоров» они не вмещаются.
                                                                                      0
                                                                                      > Настоящий сеньор сам вырабатывает новое направление и предлагает его либо своей, либо другой компании.

                                                                                      Если речь о новых бизнес-направлениях, типа «а давайте из нашего сайта выделим движок и будем его продавать», то это уже точно не сеньор, а менеджер или даже предприниматель, случайно умеющий код писать. Сеньор решает бизнес-задачи техническими (обычно) методами, а вот постановки и продвижение новых бизнес-задач — это уже совсем другой вид деятельности.
                                                                                        0
                                                                                        разговор всё больше обретает абстрактные формы… давайте уже закроем?
                                                                                        0
                                                                                        > Писатели комментов сплошь считают себя сеньорами и хором защищают позицию. Ожидаемо :-)

                                                                                        Действительно, считаю, тут спорить не буду, но и позицию автора статьи защищать не буду, она порочна.

                                                                                        > Деление джун/сеньор [в том числе по причине пункта 1] проводят по «тупой автор говнокода» и «высоколобый крылатый ангел»

                                                                                        А вот этого я не говорил, не надо. Хватает и сеньорского говнокода (сам пишу иногда, каюсь), и высоколобых джунов. Разница в первую очередь в осознанности того, что ты делаешь, и, в меньшей степени, в глобальности задач, которые ты можешь успешно решить.
                                                                                        Если ты пятнадцать лет в отрасли, знаешь много умных слов и твой код работает, но дизайнишь ты его определённым образом не потому, что таковы условия, а потому, что умеешь только так — ты не сеньор; и, напротив, если ты можешь решить задачу с обоснованием, почему ты это делаешь так, а не иначе, и видишь альтернативные пути с их достоинствами и недостатками — ты не джун, даже если писать ты умеешь только псевдокодом и вчера пятый класс закончил.
                                                                                        И вот эти ваши джуны которые поднимают новое направление — совсем не джуны, если способны проявлять инициативу в решениях и вот это вот всё, равно как закостеневшие в древних технологиях сеньоры перестали ими быть в момент, когда перестали учиться.

                                                                                        Но общепринятая терминология всех этих нюансов не учитывает, тут абсолютно согласен.
                                                                                          0
                                                                                          C удовольствием отмечаю схождение позиций. Кроме одного пунктика: говнокод всё же — проблема руководителя группы и его косяк. Это страной можно руководить, перед этим поработав актёром или банщиком, а группой руководить — квалификация нужна. Сам, кстати, уже 15 лет не пишу ничего принципиально (для себя не в счёт, ессно), не верю в «играющих тренеров». Бывают, конечно, гении, но я не из тех. Когда пишешь сам — очень сильно желание спрятаться «вот, сейчас допишу и займусь группе работу выстраивать».
                                                                              +3
                                                                              Вы так говорите, как будто компилятор — это что-то сложное. У меня у самого три написано (довольно простых, кстати). Компилятор — это лишь способ ускорить выполнение кода. Просто у джунов мысли не возникает, что можно самому написать компилятор.

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

                                                                              Моя контора и конкретно мой отдел как раз создаёт новые технологии.
                                                                              Так и мы тоже не старьем занимаемся (высокоточная спутниковая навигация). И джуны из числа заказчиков — достали. Куча лишней писанины, требования, выставленные лишь потому, что «так в институте учили» и не имеющие отношения к реальности… Дурацкие просчеты в написанном джунами ТЗ…

                                                                              К сожалению, джуны не отличают важное от неважного, а нужное от ненужного.
                                                                                0
                                                                                Вы так говорите, как будто компилятор — это что-то сложное. У меня у самого три написано (довольно простых, кстати). Компилятор — это лишь способ ускорить выполнение кода. Просто у джунов мысли не возникает, что можно самому написать компилятор.
                                                                                При решении сколько-нибудь серьёзных задач инициатива по созданию компиляторов внутри неё почти всегда означает отвратительную потерю времени и отвратительно же сложную поддержку продукта. Области, где подобное приветствуется — есть, но это весьма узкие области, и приводить их в пример неправильно.
                                                                                Угу, именно поэтому мы любим сеньоров. Помните туполевское «сломается здесь»? Так где джуниор через пару лет будет удивляться возникшим проблемам и ещё пару лет их расхлебывать — сеньор видит их с самого начала.
                                                                                Там где сеньор пилит знакомую технологию — верно. Там, где нужно строить или осваивать новое — наоборот.
                                                                                Так и мы тоже не старьем занимаемся (высокоточная спутниковая навигация). И джуны из числа заказчиков — достали. Куча лишней писанины, требования, выставленные лишь потому, что «так в институте учили» и не имеющие отношения к реальности… Дурацкие просчеты в написанном джунами ТЗ…
                                                                                Удивительное пишете! Если эта область, где у заказчиков нет опыта вообще, то создаётся классическая IT-ситуация, когда заказчик вообще не способен составить ТЗ и вообще представить, что ему, на самом деле, нужно. Только в самых-самых общих словах. Всегда и везде в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
                                                                                Если же область сколько-нибудь заказчиком освоена — то никаких джуниоров в составлении ТЗ и не будет. Сеньоры не настолько дураки, чтобы самое вкусное отдавать желторотым.
                                                                                В описанном же Вами я могу только согласиться — кошмар. Заказчик настолько оторван от реальности, что сеньоров у него нет вообще, и даже более того — он не способен воспринять и предложения разработчиков, так что фонтанирует дистиллированной глупостью. Но… денег у него немерено, приходится за это страдать. Ну, могу только посочувствовать, в таких условиях тяжело работать.

                                                                                Надеюсь, становится видно и Вам, что у нас не противоречия, а плавный переход на поболтать. Потому, если просто приятно пообщаться, вспомнить былое и помечтать о новом — я готов. А продолжать обсуждение или тем более спор — смысла уже нет, согласны? Если да, просто давайте остановимся.
                                                                                  +1
                                                                                  При решении сколько-нибудь серьёзных задач инициатива по созданию компиляторов внутри неё почти всегда означает отвратительную потерю времени и отвратительно же сложную поддержку продукта.
                                                                                  Чушь какая-то. Компиляторы пишутся там, где они упрощают разработку. Ну как пример — электронные таблицы. На написание простейшего компилятора и простейшего интерпретатора байт-кода — два дня. А без компиляции сколько вы провозитесь, пока у вас начнет "(1+2)*3" считать?

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

                                                                                  никаких джуниоров в составлении ТЗ и не будет. Сеньоры не настолько дураки, чтобы самое вкусное отдавать желторотым.
                                                                                  Вы просто не сталкивались с конторами, созданными ради распила. Там одни джуны.

                                                                                  Всегда и везде в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
                                                                                  Вам очень сильно повезло, что вы с такими конторами не сталкивались. «Мы тут выиграли тендер, а теперь объясните нам, что мы нужно сделать. Ну и сделайте работу за нас, но за полцены». Это, практически, дословно.

                                                                                  А писать наукоообразные документы — это единственное, что эти джуны умеют. Так что ТЗ они пишут сами, вплетаю много-много красивых слов.

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

                                                                                  в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
                                                                                  Это если у заказчиков есть сеньор. А девиз джунов — «слабоумие и отвага». :-)
                                                                                    +1
                                                                                    А без компиляции сколько вы провозитесь, пока у вас начнет "(1+2)*3" считать?

                                                                                    Парсер этого счастья пишется за 50 минут с boost.spirit и за 7 минут с attoparsec. Потом ещё 10 и 2 минуты соответственно для рекурсивного сворачивания AST в результат.

                                                                                      +1
                                                                                      Вы считаете это не будет компиляцией? А чем тогда оно будет, интерпретацией? :-)

                                                                                      P.S. Я согласен, что компиляторные технологии очень просты и удобны. Просто джунам они кажутся чем-то космическим.
                                                                                        +1
                                                                                        > Вы считаете это не будет компиляцией? А чем тогда оно будет, интерпретацией? :-)

                                                                                        Эм, ну да, это и есть интерпретация. Если бы у вас там были переменные, это было бы ещё более ясно.
                                                                                          –5
                                                                                          нет, как только появляется AST — это компиляция. А уж если вы храните AST — так это уже совсем классическая компиляция. Интерпретация — это как в калькуляторе.
                                                                                            +4
                                                                                            Получается, все языки, кроме, возможно, брейнфака — компилируемые?

                                                                                            Не очень конструктивное определение, короче. Не понимаю, зачем отождествлять компиляцию с парсингом. Ну, разве что, «я написал компилятор» звучит круче, чем «я написал парсер».
                                                                                              +1
                                                                                              Java — она как по вашему? Компилируется или интерпретируется?

                                                                                              Трансля́ция програ́ммы — преобразование программы, представленной на одном из языков программирования, в программу на другом языке.

                                                                                              Любой перевод в байт-код — трансляция.

                                                                                              Получается, все языки, кроме, возможно, брейнфака — компилируемые?
                                                                                              Не-а. Если у нас выполнения оператора может породить или не породить ключевое слово или идентификатор и мы не можем это узнать заранее — это будет чисто интерпретируемый язык.

                                                                                              То есть по сути так. В компилируемых языках мы можем откомпилировать модуль, а в интерпретируемых — только оператор.

                                                                                              Как минимум, не компилируемый FORTH — из-за динамического порождения ключевых слов.
                                                                                                0
                                                                                                Java — она как по вашему? Компилируется или интерпретируется?

                                                                                                Тут есть разногласия (и топящие за то, что Java не компилируется, забывают, что у x86 давно внутре неонка микрокод). Я склоняюсь к определениям, в которых компиляция — это произвольный перевод[1] из external language в некий internal language, самодостаточный и со строго определённой семантикой.


                                                                                                Поэтому если у вас есть отдельно спека JVM и отдельно спека Java, то вы можете либо построить трансляцию (или, синонимично, компиляцию) из одного в другое и доказать эквивалентность (если спека джавы самодостаточна), либо же просто написать спеку джавы в терминах трансляции в JVM.


                                                                                                Или, например, я вам могу выписать подмножество джавы и формализовать его двумя способами: либо напрямую в терминах операционной семантики и правил типизации на термах этого языка (и тогда реализация этого в коде будет интерпретатором), либо в терминах дешугаринга в simply-typed lambda calculus с рекордами, сабтайпингом и оператором неподвижной точки (и реализация этого в коде будет компилятором, пусть и результирующий STLC будет, скажем, интерпретироваться).


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


                                                                                                [1]

                                                                                                При этом, когда я говорю о языке, я имею в виду AST этого языка, а не линеаризованный текст на этом языке, парсинг — скучная и не очень интересная часть анализа языков, поэтому вангуемый мной аргумент о переводе текста как external language в AST как internal language не прокатит.


                                                                                                Если у нас выполнения оператора может породить или не породить ключевое слово или идентификатор и мы не можем это узнать заранее — это будет чисто интерпретируемый язык.

                                                                                                Я сходу не вижу формального доказательства невозможности компиляции такого языка в более низкую форму, к слову. Просто парсинг этого языка неразрешим в смысле Тьюринга. Ну да ладно, ничего нового, у С++ он тоже неразрешим (для того, чтобы приписать токенам синтаксические категории, вам в общем случае нужно уметь выполнять произвольные тьюринг-полные constexpr-функции, да и C++03 неразрешим, просто там это не так наглядно), а язык — компилируемее некуда.

                                                                                                  0
                                                                                                  Я склоняюсь к определениям, в которых компиляция — это произвольный перевод[1] из external language в некий internal language, самодостаточный и со строго определённой семантикой.


                                                                                                  И тут вступает в силу странный критерий. А можно ли сохранить внутренний язык? А можно ли загрузить код на внутреннем языке и использовать его? Если можно — это компиляция, какая бы примитивная она не была.

                                                                                                  Или, например, те же арифметические выражения после парсинга в AST я могу интерпретировать (бегая по дереву), либо скомпилировать в байткод для самописной стековой машины,
                                                                                                  Это менее значимый критерий. Если вы можете загрузить AST из файла — значит это компиляция.
                                                                                                    0

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


                                                                                                    А, так сказать, identity transformation — это компиляция?

                                                                                                      0
                                                                                                      А! вы неверно поняли слово «можно». Речь не о теоретической возможности. А о наличии функции в программе. А функция сохранения-вычитки делается в зависимости от того, имеет ли ценность результат компиляции. Или компиляция из исходного кода настолько быстрая, что нет смысла сохранять результат на внутреннем языке.
                                                                                                        0
                                                                                                        Я правильно понимаю, что если в «интерпретатор» — по вашей терминологии добавить метод save, то он сразу станет компилятором, а если из компилятора это убрать — то он будет интерпретатором?
                                                                                                          +2
                                                                                                          Угу. По аналогии «Если на транспортном средстве нет противоугонки, значит это ржавое корыто нечто дешевое, которое и так не угонят». Видели противоугонку на садовой тачке? А на детском трехколесном велосипеде? Но вы правы, порш со снятой противоугонкой по данному определению превращается в тыкву.

                                                                                                          Это формальный признак. Если есть файл с откомпилированным представлением — значит, есть компиляция. Если откомпилированное представление не сохраняется, значит оно лишь этап интерпретации.

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

                                                                                                          P.S. А что любой формальный критерий может быть извращен до полного бреда — IMHO нормально. Чтобы было не извратить — нужно несколько формальных критериев. И то, специалисты по извращению найдут лазейку.
                                                                                                            0
                                                                                                            Я предлагаю следующий критерий.

                                                                                                            Если в процессе выполнения программы изменить исходный код и программа станет работать с учётом изменений, то это интерпретатор. То есть, любые промежуточные представления для интерпретатора запрещены.
                                                                                                              0
                                                                                                              Точнее, в таком критерии промежуточное представление разрешено, но объёмом не более, чтобы выполнить 1 шаг программы на исходном языке (1 оператор языка). Для следующего оператора нужно готовить промежуточные данные непосредственно перед его выполнением.
                                                                                                                0
                                                                                                                Исходный код кто меняет? Человек или программа? Без этого уточнения сложно оценить критерий.

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

                                                                                                                Кстати, по всем трем критериям, SQL получается интерпретатором. Хотя у него довольно большая стадия компиляции и оптимизации скомпилированного кода.
                                                                                                                  0
                                                                                                                  Исходный код кто меняет? Человек или программа?
                                                                                                                  Человек не сам действует, а всегда посредством программы. Я имел в виду, что исходный код лежит где-то в памяти интерпретатора или в файле на диске (менять его может другой процесс или тот же самый), в сам язык не обязательно встраивать возможность само-модификации.
                                                                                                                  Есть ещё один критерий. В интерпретаторе легко делается выполнение произвольного выражения
                                                                                                                  Это скорее следствие, но обратное не всегда верно (интерпретатор может быть зашит в железку без портов, через которые можно ввести выражение).
                                                                                                                  Кстати, по всем трем критериям, SQL получается интерпретатором.
                                                                                                                  Да пожалуйста. Хотя насколько я знаю по популярным СУБД, хранимые процедуры лежат в виде байт-кода. Получается, что у СУБД есть компилятор в байт-код и интерпретатор байт-кода. То есть, одиночный запрос выполняется в режиме интерпретации (по этому критерию), а блок запросов — компилируется.
                                                                                                                    0
                                                                                                                    Если изменить исходный код до точки чтения — точка чтения улетит. Да и буферизация чтения помешает увидеть изменения.

                                                                                                                    То есть, одиночный запрос выполняется в режиме интерпретации (по этому критерию), а блок запросов — компилируется.
                                                                                                                    На MS SQL и одиночный запрос компилируется, а потом оптимизируется. Им для оптимизации (составления плана выполнения) нужна промежуточная форма. Похоже там и кэширование промежуточной формы есть. То есть подав 100 однотипных запросов, время на компиляцию будет получено только на первом.

                                                                                                                    Увы, плотно работал с SQL лет 20 назад, так что уже не помню точно. Но вроде бы у первого запроса время компиляции было ненулевое, а у последующих — 0.
                                                                                                                      0
                                                                                                                      На MS SQL и одиночный запрос компилируется, а потом оптимизируется
                                                                                                                      Внутри может быть что угодно, я говорю о том, что по предложенному критерию одиночные SQL выполняет интерпретатор, и это с наблюдаемым поведением не расходится (возможна интерактивная работа)
                                                                                                                        0
                                                                                                                        По моим понятиям MS SQL компилируется. И по вашему критерию — тоже. Ибо запрос считывается целиком и его изменение не повлияет.
                                                                                                                          0
                                                                                                                          Нет, потому что минимальный шаг выполнения в языке SQL это один запрос.
                                                                                                                            0
                                                                                                                            Вы не правы. Теоретически минимальный шаг — это один оператор. А в запросе можно уместить сотню DELETE, UPDATE или INSERT.

                                                                                                                            За давностью лет уже и синтаксис помню нечетко, но мне кажется, что в транзацкии запросы типа
                                                                                                                            BEGIN TRANSACTION
                                                                                                                            DELETE FROM TABLE WHERE N=11
                                                                                                                            DELETE FROM TABLE WHERE N=12
                                                                                                                            END TRANSACTION
                                                                                                                            

                                                                                                                            Отрабатывали как
                                                                                                                            BEGIN TRANSACTION
                                                                                                                            DELETE FROM TABLE WHERE N IN (11,12)
                                                                                                                            END TRANSACTION
                                                                                                                            

                                                                                                                            То есть вроде как в MS SQL была межоператорная оптимизация. Не поручусь (20 лет прошло), но по рассмотрению плана запросов мне казалось, что так.
                                                                                                                              0
                                                                                                                              Хорошо, тогда пусть MS SQL Server будет компилятором.
                                                                                                                        0
                                                                                                                        Если изменить исходный код до точки чтения — точка чтения улетит. Да и буферизация чтения помешает увидеть изменения.
                                                                                                                        Да, такое я наблюдаю на Windows 10 с cmd-файлами. Можно из критерия убрать про диск, оставить только оперативную память, куда загружена интерпретируемая программа.
                                                                                                                          0
                                                                                                                          А я — на linux с длинными bash-файлами. Подправил во время работы — получил баг от того, что точка чтения съехала.
                                                                                                                      0
                                                                                                                      В интерпретаторе легко делается выполнение произвольного выражения, введенного оператором с клавиатуры.
                                                                                                                      Антипример — классические BASIC-и времён 8-битных процессоров. Имея произвольное выражение (в виде строки, например), вычислить его сложно, т.к. интерпретатор не предоставляет таких ф-ций.
                                                                                                                        0
                                                                                                                        Исходный BASIC — это компилируемый язык, отсюда ограничение на 26 FOR (страница 55). В нем не было строк, даже в PRINT использовались метки (страница 31). Типов в нем тоже не было — все было FLOAT.

                                                                                                                        Имелся ли ввод строк в BASIC на 8080 — не знаю, скорее всего нет. А без ввода строк и строчных операций eval не нужен.
                                                                                                                          0
                                                                                                                          Я про бейсики на всяких ZX-Spectrum, Commodore 64 и прочих БК-0010. Строки там есть, eval нет.
                                                                                                                            0
                                                                                                                            Вики утверждает, что на БК-0010 бейсик компилировался:

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

                                                                                                                            Про спектрум и коммондор — копайте сами.
                                                                                                                              0
                                                                                                                              У меня спектрум был, и я очень неплохо разбирался в его внутренностях. Там ничего не компилировалось. Да, БК не было. Значит, классический BASIC таки компилируемый, но для меня он навсегда интерпретатор )))
                                                                                                                                0
                                                                                                                                Самый простой способ реализациия для любого языка — это компиляиция в код виртуальной машины, очень похожей на этот самый язык. А уже вирт-машина
                                                                                                                                интерпретирует операторы. Ну то есть примерно как в FORTH.

                                                                                                                                Можно по скорости цикла посмотреть, была ли там компиляция. Скорость при чистой компиляции (без оптимизации, то есть фортран) — в 1.5-2 раза меньше скорости ассемблера. Скорость форт-систем — в 10-20 раз ниже скорости ассемблера. А скорость чистой интерпретации — намного хуже.

                                                                                                                                Чистая интерпретация была в FOCAL, по ощущениям — ну раз в 10-20 медленней FORTH. По ощущениям, фокал при каждом обращении искал значаение переменной по её имени.
                                                                                                0

                                                                                                Это будет парсер выражений в данном случае.

                                                                                                  0
                                                                                                  Парсера мало — нужно ещё и уметь вычислять выражения. Получается парсер + интерпретатор байт-кода + хранение скомилированного байткода. Примерно так и живет JAVA.
                                                                                                    +1

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

                                                                                                      0
                                                                                                      Для многих языков — это 100 строк. Сложный этап — это оптимизация AST и навешивание на него атрибутов. Байткодовую машину нет смысла делать слишком низкоуровневой.
                                                                                                0
                                                                                                Чтобы вы понимали — технология без компиляции — это как в калькуляторе. Интерпретация каждого вводимого символа. Так (на конечном автомате) можно писать можно, но будет сложнее, чем с компиляцией.
                                                                                                  +1
                                                                                                  Эм, а как вы будете парсить, скажем, описываемый регулярным языком поток байтиков в токены, например? Это вам и при компиляции пригодится.
                                                                                                    0
                                                                                                    Поток байтиков в данном случае — не алгоритм, а данные. Поэтому он и «парсится», а не компилируется.

                                                                                                    А вообще это лет 50 уже известно, что в интерпретируемых языках для скорости и отлаживаемости лучше вначале компилировать в AST или байт-код, а потом его исполнять.

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

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

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

                                                                                                          В принципе, если начинать играть в логику и определения, то начинаются всякие забавные эффекты, вроде того, что текст программы без сопоставленного ей перевода в фиксированный формализм (МТ, например) тоже совсем не алгоритм. Между текстом, который надо прогнать через gcc для получения относительно рабочей программы, и текстом, который надо прогнать через xor по 1011, а уже потом через gcc, разницы не сильно много. Если вам охота пятничным вечером поупражняться в таких играх — я с радостью поддержу.
                                                                                                            0
                                                                                                            Нет, не охота. 6-) Давайте сойдемся на том, что если мы сохраняем на диск и читаем откомпилированное представление — у нас есть этап компиляции.
                                                                                              +1
                                                                                              На самом деле отличие в том, что для меня нормальный джун — это школьник или студент. А после окончания института — должен тянуть на миддла. Ну или человек неверно профессию выбрал и весь институт — учился вместо того, чтобы работать.

                                                                                              Джун после 25 лет — это нонсенс. Ну разве что человек пришел в программирование из физиков или строителей.
                                                                                              0
                                                                                              Вы так говорите, как будто компилятор — это что-то сложное.

                                                                                              Это зависит от языка. Компилятор регулярок — не особо сложное. Компилятор языка с зависимыми типами — ну уже довольно-таки.
                                                                                                0
                                                                                                Не зависит. :-) Следите за руками.

                                                                                                Если написанием компилятора мы упрощаем код и сокращаем время на разработку — значит компилятор менее сложен, чем остальной код. Ели компилятор сложнее, чем его замена — зачем его писать?
                                                                                                  0
                                                                                                  Если написанием компилятора мы упрощаем код и сокращаем время на разработку — значит компилятор менее сложен, чем остальной код.

                                                                                                  Это почему?


                                                                                                  Ели компилятор сложнее, чем его замена — зачем его писать?

                                                                                                  Чтобы сэкономить время.

                                                                                                    0
                                                                                                    Разве можно сэкономить время, написав сложный код вместо простого? Время, если очень грубо, примерно равно квадрату сложности кода.
                                                                                                      0
                                                                                                      Можно, конечно, если простого кода надо много.
                                                                                                        0
                                                                                                        Ну если очень много… :-))) Но пример как-то в голову не приходит.
                                                                                                          0

                                                                                                          Пример уже вроде был — crud

                                                                                                            0
                                                                                                            crud именно компиляцией? Не интерпретацией? Теоретически возможно. Увы, уже лет 20 — не моя область. Я бы вообще делал этот слой на SQL через view.

                                                                                                            P.S. А почему вы считаете компилятор crud сложным? Там вроде все очень просто.
                                                                                                            0
                                                                                                            Зачем есть boost.spirit, если написать конечный автомат руками куда проще, чем обмазываться шаблонным метапрограммированием на С++03?
                                                                                                              0
                                                                                                              важнее, что проще понять и отладить. Учить библиотеку ради разового применения обычно не выгодно.
                                                                                                                0

                                                                                                                Я в бесконечное количество раз буду более счастлив поддерживать парсер на спирите или даже на каком-нибудь lex/yacc, чем самописную стейтмашину типа той, что выплёвывает lex/yacc/ragel.

                                                                                                                  0
                                                                                                                  взаимоисключающие параграфы. Или самописную и понятную автору — или автосгенеренную и понятную лишь тому, кто писал код yacc.
                                                                                                                    0

                                                                                                                    Вы что, поддерживаете и ковыряете то, что вам выплёвывает кодогенератор, вместо его входной программы?

                                                                                                                      0
                                                                                                                      Нет, самописная стейтмашина — это именно самописная. Написанная ручками, без кодогенераторов. Сделать из описания протокола БНФ — займет времени побольше, чем написать стейт-машину. Пример протокола.
                                                                                                                        0

                                                                                                                        Ну тогда зачем вам автосгенеренную-то ковырять?

                                                                                                                          0
                                                                                                                          Не зачем. Но я об этом и не писал.
                                                                                                0
                                                                                                Молодые сеньоры, вчерашние джуны

                                                                                                А мидлов не существуют?

                                                                                                  +1
                                                                                                  Это просто следующая стадия. Сначала ты джун, потом сразу сеньор, потом понимаешь что что-то не так и уходишь в более приличную контору где ты мидл
                                                                                            +10
                                                                                            С блога автора оригинального поста:
                                                                                            I am especially interested in helping beginners who identify with any of the following:
                                                                                            A minority because of race, gender, gender identity, sexual orientation, or religion.
                                                                                            Grew up in poverty.
                                                                                            A refugee.
                                                                                            Speaks Spanish natively and has limited English skills.
                                                                                            Вот и вся история. Ненаём джунов мешает его деятельности.
                                                                                              +1
                                                                                              Не впадайте в крайности. Срединного подхода нет и никогда не будет. Новички необходимы в силу эволюционного развития каждой компании. Кто-то из старших разработчиков эволюционировал до руководящей или менторской работы, кто-то наоборот деградировал, кто-то остался на том же уровне. Да и по хорошему перетекание сотрудников с примерно одинаковым уровнем знания влечет к деградации к отрасли в целом. Пример не связанным с программированием это перетекание закостеневших ciso из одной компании в другую. Да у человека имеется огромный багаж знаний, но есть минус потребности в безопасности у компании эволюционируют, так же и с написанием кода. Предугадать какие библиотеки и какие языки будут востребованы и актуальны в проектах в следующем месяце или квартале не возможно.
                                                                                                +1
                                                                                                Однако тут есть маленькая проблемка: как их найти?
                                                                                                Это как просто. Любой программист младше 12 лет :-) — это будущий крутой сеньор.

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

                                                                                                P.S. У меня был 17летний сотрудник, которого, по-хорошему нужно было ставить руководителем группы вместо меня. В 17 он был на третьем курсе и четвертый год программировал за деньги. Собственно многие его знают как человека, придумавшего идею языка Котлин и написавшего первую книжку по нему. Вот только даже в 14 — он уже был мидлом.
                                                                                                  –2
                                                                                                  У меня есть вот вопрос — ну, ОК, все перестали нанимать джунов. Где через 5-10 лет вы планируете нанимать новых сеньоров, на замену умершим/вышедшим на пенсию? Ведь сеньоры получаются из джунов, но раз джунов никто не нанимает, то и новых сеньоров не появляется…
                                                                                                    +4

                                                                                                    Почему же. Если оглядеться на реальный мир — можно увидеть, что джунов нанимают аутсорс-конторы, чтобы продавать их как миддлов, а заодно тренируют их проходить собеседования на миддлов. Заодно они же занимаются раздуванием кода программных продуктов, чтобы нанимать и продавать больше разработчиков, и их как раз устраивает низкое качество кода — можно заодно QA продавать.


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


                                                                                                    И да, скорее всего любая компания, которая говорит, что не нанимает джунов, наймет человека, который будет сидеть по 24 часа в сутки, переделывая собственные ошибки и подходя с вопросами ко всем. Просто джуны обычно сейчас ждут, что их будут носить на руках, потому что они прошли двухмесячные курсы. Увы, говорю как человек, который занимается интервью последние пару лет довольно часто — как себе, так и другим проектам.

                                                                                                      +1
                                                                                                      А что если все программистами станут? Дворы же некому будет подметать. И хот-доги делать. И операции на сердце. Ну на фиг, не пойду на программиста, а то вдруг вся планета побежит за мной повторять. Лучше поступлю в мед, стану кардиохирургом. И пол поменяю, а то что если все мужиками станут. Буду женщиной-кардиохирургом. Хотя, что если все станут женщинами-кардиохирургами…
                                                                                                      –3
                                                                                                      явный признак токсичной корпоративной культуры

                                                                                                      Не вижу в этом ничего плохого, даже наоборот: токсичная культура способствует росту скила.

                                                                                                        +4
                                                                                                        Нанимайте джунов только в двух случаях: вы корпорация и коллекционируете программистов, либо вам очень тяжело заманить высокоуровневых программистов. Джунов которые пишут не говно — считанные проценты. Джунов, которые считают иначе — более 90%. И вот где-то среди тех долей процентов, где джун пишет не совсем говно и трезво оценивает свои возможности, пытаясь избавиться от недостатков, лежит ваш не ограненный алмаз. Так что тут нужно быть либо ну очень терпеливым, либо ну очень уверенным в своих оценках и методиках отбора.
                                                                                                          0
                                                                                                          Есть еще третий случай: вам очень важен конкретный человек. Например, если вы хотите научить брата-джуна программировать, можно вместе сделать проект.
                                                                                                            +1
                                                                                                            Проектов без простых задач — мало.
                                                                                                            При нормально поставленном процессе — следить за джунами занимает меньше времени, чем реализовывать простые задачи силами сильных разработчиков.

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

                                                                                                            При том всем джуны имеют свойство расти и не сразу об этом понимать. Так что опять таки, при нормально поставленном процессе у конторы есть энное количество мидлов которые получают как джуны.

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

                                                                                                            Вот только это сразу же ошибка с точки зрения бизнеса, ведь эти деньги можно пустить на дело и приумножить.
                                                                                                            0
                                                                                                            Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.


                                                                                                            Правильно ли я понял, что имеется в виду, что старшие разработчики будут экономить время за счет делегирования задач джунам?

                                                                                                            если да
                                                                                                            а-ха-ха-ха-ха
                                                                                                              +3
                                                                                                              Я дико извиняюсь, но разве комментарии к статьям не принято писать, собственно, в комментариях? А это именно комментарии, никакого анализа даже близко нет.
                                                                                                                +2
                                                                                                                Обычно компании, которые нанимают только сеньоров, на самом деле нанимаю джунов, которые маскируюся под сеньоров, так как если нету сотрудников разного уровня, то и сравнить их проблематично.
                                                                                                                  0
                                                                                                                  Всегда было интересно, из какого пальца высасывается то, чего не было в оригинальной фразе. Где было про долг и про бюджет? Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.

                                                                                                                  Мне вот больше интересно, автор, а где Вы выловили такую мысль в приведенной статье? Автор статьи, которого Вы местами нещадно критикуете, всего лишь делает вывод на основании представленных пунктов. В принципе, тоже самое делаете и Вы, вот только у него вывод намного ближе к истине, чем Ваш…
                                                                                                                  И таких недочетов, на самом деле, у Вас еще очень много.
                                                                                                                    +1
                                                                                                                    Немного лирики: если в армии оставить одних генералов, то кто будет носить патроны и мыть полы?
                                                                                                                    По делу:
                                                                                                                    — Есть, как уже тут отмечали, более сложные задачи, есть более тривиальные (ну там CRUD'ы и иже с ними). Использовать на тривиальных задачах сеньоров (в случае, когда, нет автоматизации производства такого рода кода) — почти что как забивать микроскопом гвозди.
                                                                                                                    — Джун, действительно, может взглянуть более свежим и упрощённым взглядом на вопрос, и иногда это бывает полезно.
                                                                                                                    — Джун — это инвестиция компании в будущее. И если в компании хорошие условия, то джун станет расти и приносить ей пользу (за исключением экстремальных личных обстоятельств, когда джун вынужден куда-то переехать или по иным особым причинам покинуть работу).
                                                                                                                      –1
                                                                                                                      Хочется еще обратить внимание что оригинальная статья это перевод статьи автора из США, где рынок программистов более другой чем в РФ. По сравнению с ним в РФ на рынке труда программистов «как грязи» и расслоение по зарплатам не так значительно. В РФ позиция сеньора закрывается за недели, в США многими месяцами с кучей собеседований. Где в РФ выгодно нанимать сеньоров у «них» имеет смысл обучить джуна.
                                                                                                                        +1
                                                                                                                        Так ли это — про сеньора за считанные недели? Мне, к сожалению, случалось наблюдать лишь обратное. Возможно, это как раз та разница в привлекательности компании и перспективности проекта.
                                                                                                                          +1
                                                                                                                          По крайней мере в Томске это так. Ну и естественно зарплата и условия труда должны быть конкурентноспособными
                                                                                                                          +1
                                                                                                                          По сравнению с ним в РФ на рынке труда программистов «как грязи» и расслоение по зарплатам не так значительно.

                                                                                                                          Шта? «Хорошо только там, где нас нет». Полюбопытствуете медианам зарплат в США — многое для себя откроете.
                                                                                                                          habr.com/post/423695
                                                                                                                          110 000 в год сеньор с 15 летним опытом.
                                                                                                                          www.indeed.com/salaries/Junior-Developer-Salaries
                                                                                                                          62 000 джун

                                                                                                                          Разница в 2 раза.

                                                                                                                          Это в США разбег незначительный. Если не считать несколько самых крутых фирм, куда мало кому светит попасть.

                                                                                                                          В РФ типовой джун и 30 000 рублей в месяц может не получать.
                                                                                                                          Типовой сеньор — это далеко за 100 000 рублей в месяц, скорее ближе к за 150 000.

                                                                                                                          Разница в 5 раз.
                                                                                                                          И это если не считать, что можно из РФ работать «на западного дядю», где и 200-300 тыс. рублей в месяц не предел мечтаний, а можно и больше.

                                                                                                                          У нас более «дикий рынок». По зарплатам в том числе.

                                                                                                                          В РФ позиция сеньора закрывается за недели, в США многими месяцами с кучей собеседований.


                                                                                                                          То, что ради ЧСВ вакансию называют «сеньорской» вовсе не означает, что она таковой считается.

                                                                                                                          Неделю?

                                                                                                                          Мы по 2 месяца ищем. И дело даже не в зарплатах (они более чем достойные, существенно выше чем по региону).

                                                                                                                          Просто приходят в основном «23-х летние сеньоры». А то и вовсе «Я умею ставить Windows и являюсь администратором Linux, потому что сам поставил Ubuntu; что? командная строка? нет, не работал. зачем, GUI же есть».

                                                                                                                          Сеньор это от 7 лет опыта.

                                                                                                                          Где в РФ выгодно нанимать сеньоров у «них» имеет смысл обучить джуна.

                                                                                                                          Ничуть.
                                                                                                                          Зависит не от страны, а от особенностей конкретной компании.

                                                                                                                            +2
                                                                                                                            «Сеньор это от 7 лет опыта», — разрешите узнать, почему?
                                                                                                                            В IT разве есть строго формализованное понятие «выслуги лет» аки в армии? Мне думается, что развитие и приобретение большего опыта не всегда коррелирует с временем. Как тут и в других местах уже писали, можно и семь лет сидеть на тривиальных задачах, не став, разумеется, сеньором. А можно и за год-два плотной работы как в команде, так и над своими навыками, получить колоссальное развитие. Ибо всё это условно, и нельзя ставить рамки. Но даже если как-то попытаться усреднить, то семь лет — многовато для сеньора. Я вижу (сугубо личное мнение) эту планку где-то в 4-5 лет. Быстрее, если разработчик крайне талантлив и трудолюбив, плюс для него есть толковые задачи.
                                                                                                                              0
                                                                                                                              «Сеньор это от 7 лет опыта», — разрешите узнать, почему?
                                                                                                                              В IT разве есть строго формализованное понятие «выслуги лет» аки в армии? Мне думается, что развитие и приобретение большего опыта не всегда коррелирует с временем.


                                                                                                                              Разумеется, не коррелирует на 100% людей. Это всего лишь грубая прикидка для среднего разработчика.

                                                                                                                              Если брать основную массу:

                                                                                                                              2 года от трейни до джуна (у кого-то может и год занять, у кого-то и 3).
                                                                                                                              потом еще лет 5 через-миддла-к сеньору, и то не все придут.

                                                                                                                              7 лет — это еще по оптимистичному, для целеустремленного человека, который и сам учился по профессии и которому повезло работать с грамотными коллегами, что его поднатаскали.

                                                                                                                              Разумеется, в конкретной ситуации могут быть и другие цифры

                                                                                                                              Но «23-летний сеньор»? Извините, не верю. Оно конечно бывает, но исчезающе редко очень…

                                                                                                                              Я начал программировать в 14. В университете сам уже учил преподавателей новым методам разработки. К 23 годам точно был максимум что миддлом, если еще не джуном.

                                                                                                                              Опыт получаемый не в реальных проектах — он так себе опыт.

                                                                                                                              «От 7 лет опыта» — значит, «не менее».
                                                                                                                              Дольше — да, можно.

                                                                                                                              Немного быстрее, скажем за 5 лет — дано не многим.
                                                                                                                              Существенно быстрее — не дано никому.

                                                                                                                              «23-летние сеньоры» в реальной жизни если и существуют, то никому из нас они не встретятся.
                                                                                                                                +1
                                                                                                                                Спасибо за ответ! Я понял Вашу позицию. :)
                                                                                                                                «2 года от трейни до джуна (у кого-то может и год занять, у кого-то и 3)», — все кого я знаю, этот путь закрывали ещё в вузе.
                                                                                                                                До мидла от джуна почти все вырастали быстро (год-полтора), но ценой труда и усидчивости.
                                                                                                                                Ну, 23-летний сеньор — согласен полностью, едва ли реально.
                                                                                                                                Но 25-летний лично мне известен, мой хороший друг. Он начал программировать в реальных проектах со второго курса, ну а так для себя что-то — ещё в школе, разумеется. Упахивался на работах, по 2-2,5 года отпуск не видел, но зато к 25 годам он уверенный сеньор был. Ценой огромного труда, ну и сам он талантлив и не глуп в довесок к тому.
                                                                                                                              0
                                                                                                                              Я уже полюбопытствовал по поводу зарплат в США во время стажировки и работы там, и выводы для себя сделал, спасибо. До этого работал в Томске — город студентов, программистов много, с поиском сеньоров проблем не было, на каждое место был конкурс, за 2 недели закрывали. Последние 3 года за трендами зарплат в РФ не слежу, но в нашем регионе больше 100 очень мало кто получал. Чаще всего 60-70, когда джунов брали на 40
                                                                                                                                0
                                                                                                                                До этого работал в Томске — город студентов, программистов много, с поиском сеньоров проблем не было, на каждое место был конкурс, за 2 недели закрывали.


                                                                                                                                Вы работали в большой фирме Томске, которая регулярно нанимала сеньоров? Иначе откуда у вас статистика.
                                                                                                                                Меня больше интересует — откуда в Томске столько большая фирма, регулярно нанимающая сеньоров.

                                                                                                                                Последние 3 года за трендами зарплат в РФ не слежу, но в нашем регионе больше 100 очень мало кто получал


                                                                                                                                У нас с вами просто разное понятие слова «сеньор».
                                                                                                                                Полагаю, вы этим словом называете того, кто по моему «миддл».

                                                                                                                                HH.RU говорит про Томск следующее:
                                                                                                                                Имеется 283 вакансии «программист».
                                                                                                                                Из них 63 с зарплатой более 120 000 в месяц
                                                                                                                                Ну и 34 — более 150 000
                                                                                                                                И даже 10 — более 185 000

                                                                                                                                22% от вакансий — это от 120 000 рублей в месяц
                                                                                                                                На самом деле гораздо больше, так как нижний сегмент по зарплате это эникеи, а не разработчики, просто их традиционно называют программистами.

                                                                                                                                Скриншот с hh.ru, Томск, программист
                                                                                                                                image
                                                                                                                                  0
                                                                                                                                  22% от вакансий — это от 120 000 рублей в месяц
                                                                                                                                  Это еще оценка снизу, так как есть вакансии, по которым не указана зарплата
                                                                                                                            +4
                                                                                                                            Никто не говорит, что джуниоры — враги. Их просто не нанимают. А еще не нанимают, например, слесарей и художников.

                                                                                                                            Ну, передергивание же. «Джун» — это уровень квалификации, «слесарь» — представитель другой профессии вообще.
                                                                                                                              +1
                                                                                                                              Если не нанимать джунов, то кто-же будет выполнять рутинные простые операции?)
                                                                                                                                0

                                                                                                                                По вашему рутинные простые операции синьоров не достойны и просто будут отброшены, без наличия джунов?

                                                                                                                                  0

                                                                                                                                  Конечно нет, но так более производительней и дешевле