Преамбулка
Эта статья является анализом другой статьи: Если вы не нанимаете джунов, то не заслуживаете сеньоров
Стоит сразу оговориться, что я понятие не имею, что там и как в 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. Заметили большую и глупую ошибку, о которой говорил автор в начале статьи?
Комментарии (164)
dididididi
05.10.2018 09:44Автор про истинно технологичную фирму, где каждая задача — это челлендж для сеньора, а формочки и круды сами пояляются.
Вообще, удел джуниоров — кодить сложно, сеньор должен кодить просто, чтоб любой джун понял. Поэтому, если джун не может разобраться в Вашем коде, подумайте, а сеньор ли Вы, а не гуано ли ваша архитектура, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.Solexid
05.10.2018 10:00getUserById, проходит через 100 классов, прежде, чем добраться до базы.
О, выглядит как кишки андроида. Там считается нормой вложенность в 100 классов.
saag
05.10.2018 09:54Джуны по определению не так хороши, они в начале становления себя как специалиста, но это не повод не нанимать их…
s-kozlov
05.10.2018 13:19А еще это не повод их нанимать.
saag
05.10.2018 14:35Мне вот интересно, это такой шаблон мышления только в странах СНГ что ли…
nexus478
05.10.2018 14:48А вы статью-то прочитали? Там конкретные примеры даже есть.
saag
05.10.2018 14:53Статья статьей, но ведь и тот кто писал статью, да все были в свое время джунами в своей области и ведь их наняли где-то и кто-то, почему теперь такое отношение? Это мне напоминает покорителей дефолт-сити, которые через год себя считают себя коренными жителями и имеют высокомерное отношение к жителям провинции.
stul5tul
06.10.2018 00:07Статья статьей, но ведь и тот кто писал статью, да все были в свое время джунами в своей области и ведь их наняли где-то и кто-то, почему теперь такое отношение?
Когда то их наняли не из благотворительности, чтобы они могли научиться и стать потом специалистами.
А чтобы компания могла денег заработать.
Если же совсем другая компания работает по другой экономической модели и в ее модели не нужно экономить на программистах, нанимая джунов — то почему нет…
areht
06.10.2018 01:59> да все были в свое время джунами в своей области
Ну как… Я, например, первой работой программистом пошел на мидла. Почему люди в институте балду гоняют, что бы потом пойтиждуном(но какая описка)джуном и 2 года круды писать — не знаю. Какой опыт им эти круды принесут — тоже не знаю.
YemSalat
06.10.2018 11:45+1При чем тут СНГ вообще?
Если, например, частная клиника будет нанимать только лучших врачей, вам жe нe покажется это странным? Скорее всего именно в эту клинику вы захотите обратиться если надо будет, а не в ту где врачи интерны учатся на вас и пробуют новые подходы к лечению.saag
06.10.2018 12:34+1А откуда эти лучшие врачи возьмутся, если их в интернатуру брать не будут?
YemSalat
07.10.2018 10:00если их в интернатуру брать не будут
Я говорил про одну конкретную частную клинику. Пускай учатся там где берут интернов.
Моя мысль не в том что джунов не надо нанимать, а о том что не стоит судить компании со своей колокольни.
Сейчас я работаю в компании которая нанимает джунов и интернов — и все ОК, до этого работал в компании в которой были только синиоры и выше — и тоже все было ОК. Никаких негативных вещей из статьи вроде токсичной кутьтуры, невозможности ошибаться и т.п. Просто не было задач для младших разработчиков и не было времени их выращивать.
stul5tul
07.10.2018 14:03А откуда эти лучшие врачи возьмутся, если их в интернатуру брать не будут?
А че, где-то кто-то написал, что теперь «принципиально во всех до единой больницах не будут брать интернов без опыта»
Одна-единственная фирма, которая может себе позволить не иметь дела с неспециалистами — не берет не специалистов. Специалистов для нее готовят другие компании.
Больниц и фирм ИТ-шных много.
Где подготовиться джунам/интернам — проблемы нет никакой.
Да, я понимаю, всем нам бы хотелось начинать карьеру с Google/Netflix/Microsoft. Но это не обязательно. Гораздо проще — и реалистичнее — поступить сначала на работу в фирму попроще, набраться опыта. После чего вас возьмут в «бодишоп» уже с желанием, после него — уже можно попытать счастия в высокотехнологичной компании, ну а уж потом — Netflix, Google…
Начните уже с районной поликлиники (ну или что там у врачей считается аналогом мелкой фирмочки по клепанию веб-сайтиков)MacIn
07.10.2018 20:01Одна-единственная фирма, которая может себе позволить не иметь дела с неспециалистами — не берет не специалистов. Специалистов для нее готовят другие компании.
Больниц и фирм ИТ-шных много.
Где подготовиться джунам/интернам — проблемы нет никакой.
Проблема в том, что в пределе всем выгодно не готовить специалистов, а получать их падающими с неба.
s-kozlov
07.10.2018 20:42Какой еще шаблон? Смысл моего утверждения — то, что «джуны по определению не так хороши, они в начале становления себя как специалиста», — это не повод их нанимать. Поводом может быть что-то другое: более низкая з/п, потенциал и т.д. А нанимать джунов потому, что они хуже, — это какая-то… кхм… благотворительность получается.
saag
08.10.2018 07:27Это не благотворительность, это отложенная прибыль, специалист вырастает и начинает работать лучше, принося бОльшую прибыль, но хочетсяя прям здесь и сейчас, а это как раз менеджерская фича, определенному менеджеру хочется скорее доложить руководству, что работа сделана, чтобы получить свои плюшки, хотя если взять разработку в Нидерландах, то насколько я слышал там нет такой гонки, делается упор на качество, а не на скорость.
waxtah
05.10.2018 21:27+1Ну собственно говоря, при подборе людей, стоит обращать внимание не только на «джун/сеньор», есть ещё другие критерии.
StroboNights
06.10.2018 04:20Вот да. К слову, почему-то сейчас стало очень модно упускать из виду такую характеристику как потенциал человека. При наличии у человека соответствующих способностей, необходимыми знаниями вполне можно овладеть, но вот сами способности — это врожденное.
Katemare
05.10.2018 10:32Спасибо за разбор переведённой мною статьи! Статья была переведена из-за интереса к теме, и в комментариях и вашем разборе нашлось много пищи для ума.
DSLow
05.10.2018 10:50-1Каеф наверное писать статьи, выдирая куски из чужого материала и оставляя никому не интересные, свои собственные комментарии.
Автор, если твой подход к написанию — это паразитированние на чужих работах, а все твое мысленное усилие было приложено лишь к плевкам вида «комментарий: », то пожалуйста, не пиши ничего больше.hashtet
05.10.2018 12:21+1А я больше скажу — Весь хабр начал напоминать Пикабу.
Один накинул говна на вентилятор статьёй про собеседования — посетителей зацепило — автор получил награду… и давай всю ленту собеседованиями засирать. Причём ничего адекватного там не было. Каждый автор старается где-нибудь кого-нибудь зацепить, что бы было большое обсуждение.
Так же про Джунов/Сеньёров.
Напоминает редакцию AdMe в лучшие его годы — так и вижу кучу авторов бегающих за рейтинговыми постами и только и думающие «чего бы теперь написать». Да лучше пусть будет Спросите Итана, которого я не читал, но который не вызывает никаких негативных эмоций присутствуя в ленте.
Вместо авторов, которые хотят донести своё другим — авторы, которые сидят на зарплате и просто пытаются заработать себе на жизнь.nexus478
05.10.2018 13:40+1Каждый автор старается где-нибудь кого-нибудь зацепить, что бы было большое обсуждение.
Напоминает редакцию AdMe в лучшие его годы — так и вижу кучу авторов бегающих за рейтинговыми постами и только и думающие «чего бы теперь написать»
Вместо авторов, которые хотят донести своё другим — авторы, которые сидят на зарплате и просто пытаются заработать себе на жизнь.
Что же получается, если автор хочет высказаться на больную для сообщества тему (а т.к. он является участником сообщества, то скорее всего для него это тоже больная тема), то он «сидит на зарплате» и «гонится за рейтинговыми постами»? То есть никакой рефлексивности у сообщества нет, все гоняются за рейтингами, так что ли?hashtet
05.10.2018 17:00Нет, думаю вы правы. Тем более, что пользователи голосуют своими просмотрами/плюсами/комментариями — и по этим показателям — это интересно людям(или они просто не могут промолчать при виде провокационного текста).
Но в данном случае — всё что содержит этот пост — обсуждалось в комментариях к предыдущему посту и там же могло и остаться. Понимаю, что жалко большой текст оставлять для комментария, но общаться постами — тоже сомнительное занятие.
Это всё мои хотелки, и они могут не совпадать с желанием большинства, но мне ещё неприятен этот слог — «токсический». ТС хуесосит другого ТСа за то, что тот хуесосит Джуниоров… жуть какая!
Но я тут всё же не прав — комментатор ниже тоже прав — Хабр всегда был таким ресурсом, просто тематика немного разная. С одной стороны яжматери, с другой яжруководители. Просто видимо сам начал чаще замечать это, т.к. пикабу тоже всё меньше доставлять стал удовольствия от прочтения(так то портал не плохой… я сравнивал с Пикабу, не в негативном качестве)
balexa
05.10.2018 13:54А я больше скажу — Весь хабр начал напоминать Пикабу.
А он всегда таким и был. Люди везде одинаковы.
А насчет рейтинга — стоит все же взять на вооружение некоторые приемы Пикабу. Например в принудительном порядке ставить тег «без рейтинга» на подобные нетехнические посты и не давать за них карму.Aingis
05.10.2018 17:31Не забывайте, что карма на Хабре не имеет никакого отношения к статьям и голосованиям. Она абсолютно случайна, в том смысле, что почти не коррелирует с содержанием (разве что в экстремальных случаях). Это вам не рейтинг. Зачем нужно это дублирование, не понимает никто.
AngReload
07.10.2018 10:19У качества статей есть отпечаток на карме. Посмотрите на эти два профиля:
Ализару поставили больше трех тысяч оценок, но почти половину из них — в минус. Он выезжает на желтизне.
А у Нулевого Пациента всего семьсот оценок, зато все в плюс. Он переводит технические статьи.
Bedal
05.10.2018 10:59-1Когда ты тупо эксплуатируешь устаревающую технологию — нужны сеньоры, знающие её от и до.
Когда ты хочешь содрать бабло, обманув инвестора демонстрацией умных, у которых на любой вопрос ответ отлетает от зубов — нужны сеньоры.
Но, если ты заботишься о будущем компании — джунов набирать необходимо, и сразу группами! Пусть сеньоры продолжают «писать фортрановские программы на любом языке », это обеспечит текущую работу. А новые технологии джуны освоят гораздо быстрее и лучше, потому что примут их как данное, без ломки себя.Jef239
05.10.2018 12:59Как вы думаете, кто придумывает новые технологии? Джуны или сеньоры? Кто делает компиляторы на новые языки, джуны или сеньоры?
Bedal
05.10.2018 13:16Молодые сеньоры, вчерашние джуны — по большинству, подавляющему большинству.
И я думаю, Вам очень сильно повезло, если Вам встречались по преимуществу конторы, создающие новые компиляторы, а не использующие их.
Хм, посмотрел Ваш же коммент чуть ниже — Вы там подтверждаете мои слова, по сути.
Мне вот, кстати, повезло. Моя контора и конкретно мой отдел как раз создаёт новые технологии. И у их потребителей (приобретателей наших продуктов) очень характерная картина: там, где сеньора ставят на освоение, мы обречены месяцами выслушивать, как всё неправильно сделано и почему всё не заработает никогда. А там, где джуны — через короткое время уже идёт использование и профит. После чего джуна срочно повышают, и не дай бог, если его место займёт вытесненный вчерашним джуном сеньор :-)SiliconValleyHobo
05.10.2018 13:50+1И это херовая схема. Это не джун быстро станет сеньером. Это он станет тимлидом в лучшем случае. Задача лида — натягивать тех специалистов на бизнес задачи. Задача сеньера — сделать хорошо и с умом и на перспективу. В споре этих двух противоположностей рождаются годные продукты.
А джуны, нашлепавшие говнокод в продакшен лишь бы поскорее заработало, это просто сюр. Это вы глупость путаете с тонким расчетом.
Bedal
05.10.2018 13:56-1Вы несколько смешиваете пары джун/сеньор aka новичок/опытный и тупой/умный. «Тупой» (очень условно!) вполне может быть сеньором, если его хватает на то, чтобы сосредоточиться в узкой области. Тогда он может быть вполне успешен, успешнее многих умных с проблемой концентрации. Но ничего вне уже освоенноей технологии он не тянет. Таких сеньоров, на самом деле — подавляющее большинство. Я уже 40 лет программляю, насмотрелся.
А джуны принимают новую технологию, как просто часть окружающего мира, они ничего другого не пробовали, и не знают, как трудно эту новую технологию постичь. Потому и справляются, практически все, что умные, что тупые.
Научить их делать приличный код — совершенно параллельная, не пересекающаяся, задача. И говнокод, и изюминка — могут быть и в старой, и в новой технологиях. Но фокус в том, что старая технология, даже изумительно реализованная — не нужна. И потому-то не нужными становится большинство сеньоров. Другое дело, что сеньоры умеют очень хорошо защищать свои позиции, затаптывая джунов.
Обычные проблемы, приведшие, кстати, в природе к появлению механизма старения, насильственно устраняющего сеньоров из эволюционного процесса.Jef239
05.10.2018 14:31старая технология, даже изумительно реализованная — не нужна.
Почему? Мешает вам пилить бюджет?
На самом деле, не нужна большая часть новых технологий — они придуманы лишь для распила денег. Значительных преимуществ они не дают, зато недостатков — куча.
Ну как хрестоматийный пример — BGA. Достоинства — компактность, большое число выводов. Недостатки -совсем иное оборудование для изготовления и ремонта плат, обязательная многослойность платы, то есть невозможность ручного исправления ошибок разводки… Дикая компактность нам не нужна — на тракторах и ледоколах места хватает, даже для беспилотников без BGA уложились в полпачки сигарет. Большое число выводов — ну так себе преимущество, нам пока и без BGA хватает. Зато без BGA быстрый цикл выпуска и модернизации платы. И даже первые экземпляры, с наляпанными проводочками и разрезанными дорожками — вполне пашут.Bedal
05.10.2018 14:57Да-да, именно потому специалисты по изготовлению каменных рубил до сих пор настолько в цене.
Серьёзно: области, где нет нужды скакать по технологиям — есть, и они вполне многочисленны. Ну так да, там сплошь сеньоры и сидят.
Я — о другом, когда новая технология требуется. В этом случае коллектив, группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры. Ну да, к концу процесса они джунами быть перестают :-), но начинать нужно именно с таких.Jef239
05.10.2018 15:04Я — о другом, когда новая технология требуется.
Это огромная редкость. Обычно новые технологии — это попытка возложить свои затраты на тестирование и апробацию на другие фирмы. То есть придумывается технология, разводится хайп и куча глупых джуниоров начинают на своем опыте ощупывать границы её применимости.
группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры.
А выгоду получит тот сеньор, который новую технологию придумал. Потому что шишки будут набивать джуны из чужой компании.Bedal
05.10.2018 15:12Вот мы и вернулись к вопросу «а кто всё создаёт» :-)
И ответ по-прежнему — молодой сеньор, недавний джун. Который просто не появится, если не бросать джунов в терновый куст. Конечно, есть гениальные исключения — но на то они и исключения.Jef239
05.10.2018 15:24Да необязательно молодой. Важнее, что сеньор. Мало ли технологий придумано немолодыми?
balexa
05.10.2018 17:43В этом случае коллектив, группа джунов, брошенная на её освоение и применение,
Вы не путайте освоение и создание. Если взять любую хайповую технологию последних лет, она создается бородатыми дядями из больших контор.
То что туда набегает толпа джунов и начинает ее «применять и осваивать» не является созданием технологии.Jef239
05.10.2018 18:40Характерно, что толпа сеньоров не кидается, ибо и плюс и минусы видит до освоения. :-) Поэтому сеньоры новые технологии берут избирательно.
Xandrmoro
06.10.2018 00:27Рубила принципиально не меняются уже хреновы тыщи лет. Переход на качественно новые материалы пару раз был — можно считать мажорными релизами, и рубилами версии 3.0 мы пользуемся лет шестьсот. И таких областей — подавляющее большинство, и считать стартапы духа «а давайте встроим в топор блокчейн и сделаем рукоятку из перфорированного углеволокна» чем-то кроме попила бюджета что-то не выходит.
Jef239
05.10.2018 14:21Вы так говорите, как будто компилятор — это что-то сложное. У меня у самого три написано (довольно простых, кстати). Компилятор — это лишь способ ускорить выполнение кода. Просто у джунов мысли не возникает, что можно самому написать компилятор.
мы обречены месяцами выслушивать, как всё неправильно сделано и почему всё не заработает никогда
Угу, именно поэтому мы любим сеньоров. Помните туполевское "сломается здесь"? Так где джуниор через пару лет будет удивляться возникшим проблемам и ещё пару лет их расхлебывать — сеньор видит их с самого начала.
Моя контора и конкретно мой отдел как раз создаёт новые технологии.
Так и мы тоже не старьем занимаемся (высокоточная спутниковая навигация). И джуны из числа заказчиков — достали. Куча лишней писанины, требования, выставленные лишь потому, что «так в институте учили» и не имеющие отношения к реальности… Дурацкие просчеты в написанном джунами ТЗ…
К сожалению, джуны не отличают важное от неважного, а нужное от ненужного.Bedal
05.10.2018 14:51Вы так говорите, как будто компилятор — это что-то сложное. У меня у самого три написано (довольно простых, кстати). Компилятор — это лишь способ ускорить выполнение кода. Просто у джунов мысли не возникает, что можно самому написать компилятор.
При решении сколько-нибудь серьёзных задач инициатива по созданию компиляторов внутри неё почти всегда означает отвратительную потерю времени и отвратительно же сложную поддержку продукта. Области, где подобное приветствуется — есть, но это весьма узкие области, и приводить их в пример неправильно.
Угу, именно поэтому мы любим сеньоров. Помните туполевское «сломается здесь»? Так где джуниор через пару лет будет удивляться возникшим проблемам и ещё пару лет их расхлебывать — сеньор видит их с самого начала.
Там где сеньор пилит знакомую технологию — верно. Там, где нужно строить или осваивать новое — наоборот.
Так и мы тоже не старьем занимаемся (высокоточная спутниковая навигация). И джуны из числа заказчиков — достали. Куча лишней писанины, требования, выставленные лишь потому, что «так в институте учили» и не имеющие отношения к реальности… Дурацкие просчеты в написанном джунами ТЗ…
Удивительное пишете! Если эта область, где у заказчиков нет опыта вообще, то создаётся классическая IT-ситуация, когда заказчик вообще не способен составить ТЗ и вообще представить, что ему, на самом деле, нужно. Только в самых-самых общих словах. Всегда и везде в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
Если же область сколько-нибудь заказчиком освоена — то никаких джуниоров в составлении ТЗ и не будет. Сеньоры не настолько дураки, чтобы самое вкусное отдавать желторотым.
В описанном же Вами я могу только согласиться — кошмар. Заказчик настолько оторван от реальности, что сеньоров у него нет вообще, и даже более того — он не способен воспринять и предложения разработчиков, так что фонтанирует дистиллированной глупостью. Но… денег у него немерено, приходится за это страдать. Ну, могу только посочувствовать, в таких условиях тяжело работать.
Надеюсь, становится видно и Вам, что у нас не противоречия, а плавный переход на поболтать. Потому, если просто приятно пообщаться, вспомнить былое и помечтать о новом — я готов. А продолжать обсуждение или тем более спор — смысла уже нет, согласны? Если да, просто давайте остановимся.Jef239
05.10.2018 15:21При решении сколько-нибудь серьёзных задач инициатива по созданию компиляторов внутри неё почти всегда означает отвратительную потерю времени и отвратительно же сложную поддержку продукта.
Чушь какая-то. Компиляторы пишутся там, где они упрощают разработку. Ну как пример — электронные таблицы. На написание простейшего компилятора и простейшего интерпретатора байт-кода — два дня. А без компиляции сколько вы провозитесь, пока у вас начнет "(1+2)*3" считать?
Там где сеньор пилит знакомую технологию — верно. Там, где нужно строить или осваивать новое — наоборот.
Вспоминаем количество новых технологий, запиленных теми же Туполевым и Королевым.
никаких джуниоров в составлении ТЗ и не будет. Сеньоры не настолько дураки, чтобы самое вкусное отдавать желторотым.
Вы просто не сталкивались с конторами, созданными ради распила. Там одни джуны.
Всегда и везде в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
Вам очень сильно повезло, что вы с такими конторами не сталкивались. «Мы тут выиграли тендер, а теперь объясните нам, что мы нужно сделать. Ну и сделайте работу за нас, но за полцены». Это, практически, дословно.
А писать наукоообразные документы — это единственное, что эти джуны умеют. Так что ТЗ они пишут сами, вплетаю много-много красивых слов.
Ну, могу только посочувствовать, в таких условиях тяжело работать.
С момента падения цены на нефть это обычная ситуация по госзаказу. Выигрывают конторы-однодневки, сидящик под кем-нибудь из олигархов.
в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
Это если у заказчиков есть сеньор. А девиз джунов — «слабоумие и отвага». :-)0xd34df00d
05.10.2018 19:12А без компиляции сколько вы провозитесь, пока у вас начнет "(1+2)*3" считать?
Парсер этого счастья пишется за 50 минут с boost.spirit и за 7 минут с attoparsec. Потом ещё 10 и 2 минуты соответственно для рекурсивного сворачивания AST в результат.
Jef239
05.10.2018 19:23Вы считаете это не будет компиляцией? А чем тогда оно будет, интерпретацией? :-)
P.S. Я согласен, что компиляторные технологии очень просты и удобны. Просто джунам они кажутся чем-то космическим.0xd34df00d
05.10.2018 21:08+1> Вы считаете это не будет компиляцией? А чем тогда оно будет, интерпретацией? :-)
Эм, ну да, это и есть интерпретация. Если бы у вас там были переменные, это было бы ещё более ясно.Jef239
05.10.2018 21:10-4нет, как только появляется AST — это компиляция. А уж если вы храните AST — так это уже совсем классическая компиляция. Интерпретация — это как в калькуляторе.
0xd34df00d
05.10.2018 21:45+1Получается, все языки, кроме, возможно, брейнфака — компилируемые?
Не очень конструктивное определение, короче. Не понимаю, зачем отождествлять компиляцию с парсингом. Ну, разве что, «я написал компилятор» звучит круче, чем «я написал парсер».Jef239
05.10.2018 22:22Java — она как по вашему? Компилируется или интерпретируется?
Трансля?ция програ?ммы — преобразование программы, представленной на одном из языков программирования, в программу на другом языке.
Любой перевод в байт-код — трансляция.
Получается, все языки, кроме, возможно, брейнфака — компилируемые?
Не-а. Если у нас выполнения оператора может породить или не породить ключевое слово или идентификатор и мы не можем это узнать заранее — это будет чисто интерпретируемый язык.
То есть по сути так. В компилируемых языках мы можем откомпилировать модуль, а в интерпретируемых — только оператор.
Как минимум, не компилируемый FORTH — из-за динамического порождения ключевых слов.0xd34df00d
05.10.2018 22:42Java — она как по вашему? Компилируется или интерпретируется?
Тут есть разногласия (и топящие за то, что Java не компилируется, забывают, что у x86 давно внутре
неонкамикрокод). Я склоняюсь к определениям, в которых компиляция — это произвольный перевод[1] из external language в некий internal language, самодостаточный и со строго определённой семантикой.
Поэтому если у вас есть отдельно спека JVM и отдельно спека Java, то вы можете либо построить трансляцию (или, синонимично, компиляцию) из одного в другое и доказать эквивалентность (если спека джавы самодостаточна), либо же просто написать спеку джавы в терминах трансляции в JVM.
Или, например, я вам могу выписать подмножество джавы и формализовать его двумя способами: либо напрямую в терминах операционной семантики и правил типизации на термах этого языка (и тогда реализация этого в коде будет интерпретатором), либо в терминах дешугаринга в simply-typed lambda calculus с рекордами, сабтайпингом и оператором неподвижной точки (и реализация этого в коде будет компилятором, пусть и результирующий STLC будет, скажем, интерпретироваться).
Или, например, те же арифметические выражения после парсинга в AST я могу интерпретировать (бегая по дереву), либо скомпилировать в байткод для самописной стековой машины, скажем (и я так действительно делал, когда у меня вычислений этих выражений были, гм, миллионы, если не миллиарды, и получал кратный профит в производительности).
[1]При этом, когда я говорю о языке, я имею в виду AST этого языка, а не линеаризованный текст на этом языке, парсинг — скучная и не очень интересная часть анализа языков, поэтому вангуемый мной аргумент о переводе текста как external language в AST как internal language не прокатит.
Jef239
05.10.2018 23:08Я склоняюсь к определениям, в которых компиляция — это произвольный перевод[1] из external language в некий internal language, самодостаточный и со строго определённой семантикой.
И тут вступает в силу странный критерий. А можно ли сохранить внутренний язык? А можно ли загрузить код на внутреннем языке и использовать его? Если можно — это компиляция, какая бы примитивная она не была.
Или, например, те же арифметические выражения после парсинга в AST я могу интерпретировать (бегая по дереву), либо скомпилировать в байткод для самописной стековой машины,
Это менее значимый критерий. Если вы можете загрузить AST из файла — значит это компиляция.0xd34df00d
05.10.2018 23:24Какой-то странный критерий. Мне сложно придумать случай, когда я физически не мог бы сохранить что-нибудь в файл и потом загрузить обратно.
А, так сказать, identity transformation — это компиляция?
Jef239
05.10.2018 23:30А! вы неверно поняли слово «можно». Речь не о теоретической возможности. А о наличии функции в программе. А функция сохранения-вычитки делается в зависимости от того, имеет ли ценность результат компиляции. Или компиляция из исходного кода настолько быстрая, что нет смысла сохранять результат на внутреннем языке.
balexa
06.10.2018 10:08Я правильно понимаю, что если в «интерпретатор» — по вашей терминологии добавить метод save, то он сразу станет компилятором, а если из компилятора это убрать — то он будет интерпретатором?
Jef239
06.10.2018 14:58Угу. По аналогии «Если на транспортном средстве нет противоугонки, значит это
ржавое корытонечто дешевое, которое и так не угонят». Видели противоугонку на садовой тачке? А на детском трехколесном велосипеде? Но вы правы, порш со снятой противоугонкой по данному определению превращается в тыкву.
Это формальный признак. Если есть файл с откомпилированным представлением — значит, есть компиляция. Если откомпилированное представление не сохраняется, значит оно лишь этап интерпретации.
Я тут не вижу противоречий. Если у нас для каждого запуска нужен исходный текст — это интерпретатор, что бы ни было наворочено внутри. Если для запуска можно использовать откомпилированное представление — значит есть компиляция. Пусть очень простая, но есть.
P.S. А что любой формальный критерий может быть извращен до полного бреда — IMHO нормально. Чтобы было не извратить — нужно несколько формальных критериев. И то, специалисты по извращению найдут лазейку.qw1
07.10.2018 12:42Я предлагаю следующий критерий.
Если в процессе выполнения программы изменить исходный код и программа станет работать с учётом изменений, то это интерпретатор. То есть, любые промежуточные представления для интерпретатора запрещены.qw1
07.10.2018 13:44Точнее, в таком критерии промежуточное представление разрешено, но объёмом не более, чтобы выполнить 1 шаг программы на исходном языке (1 оператор языка). Для следующего оператора нужно готовить промежуточные данные непосредственно перед его выполнением.
Jef239
07.10.2018 14:55Исходный код кто меняет? Человек или программа? Без этого уточнения сложно оценить критерий.
Есть ещё один критерий. В интерпретаторе легко делается выполнение произвольного выражения, введенного оператором с клавиатуры.
Кстати, по всем трем критериям, SQL получается интерпретатором. Хотя у него довольно большая стадия компиляции и оптимизации скомпилированного кода.qw1
07.10.2018 15:10Исходный код кто меняет? Человек или программа?
Человек не сам действует, а всегда посредством программы. Я имел в виду, что исходный код лежит где-то в памяти интерпретатора или в файле на диске (менять его может другой процесс или тот же самый), в сам язык не обязательно встраивать возможность само-модификации.
Есть ещё один критерий. В интерпретаторе легко делается выполнение произвольного выражения
Это скорее следствие, но обратное не всегда верно (интерпретатор может быть зашит в железку без портов, через которые можно ввести выражение).
Кстати, по всем трем критериям, SQL получается интерпретатором.
Да пожалуйста. Хотя насколько я знаю по популярным СУБД, хранимые процедуры лежат в виде байт-кода. Получается, что у СУБД есть компилятор в байт-код и интерпретатор байт-кода. То есть, одиночный запрос выполняется в режиме интерпретации (по этому критерию), а блок запросов — компилируется.Jef239
07.10.2018 16:53Если изменить исходный код до точки чтения — точка чтения улетит. Да и буферизация чтения помешает увидеть изменения.
То есть, одиночный запрос выполняется в режиме интерпретации (по этому критерию), а блок запросов — компилируется.
На MS SQL и одиночный запрос компилируется, а потом оптимизируется. Им для оптимизации (составления плана выполнения) нужна промежуточная форма. Похоже там и кэширование промежуточной формы есть. То есть подав 100 однотипных запросов, время на компиляцию будет получено только на первом.
Увы, плотно работал с SQL лет 20 назад, так что уже не помню точно. Но вроде бы у первого запроса время компиляции было ненулевое, а у последующих — 0.qw1
07.10.2018 18:23На MS SQL и одиночный запрос компилируется, а потом оптимизируется
Внутри может быть что угодно, я говорю о том, что по предложенному критерию одиночные SQL выполняет интерпретатор, и это с наблюдаемым поведением не расходится (возможна интерактивная работа)Jef239
07.10.2018 19:30По моим понятиям MS SQL компилируется. И по вашему критерию — тоже. Ибо запрос считывается целиком и его изменение не повлияет.
qw1
07.10.2018 19:43Нет, потому что минимальный шаг выполнения в языке SQL это один запрос.
Jef239
08.10.2018 01:19Вы не правы. Теоретически минимальный шаг — это один оператор. А в запросе можно уместить сотню 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 лет прошло), но по рассмотрению плана запросов мне казалось, что так.
qw1
07.10.2018 18:27Если изменить исходный код до точки чтения — точка чтения улетит. Да и буферизация чтения помешает увидеть изменения.
Да, такое я наблюдаю на Windows 10 с cmd-файлами. Можно из критерия убрать про диск, оставить только оперативную память, куда загружена интерпретируемая программа.Jef239
07.10.2018 19:32А я — на linux с длинными bash-файлами. Подправил во время работы — получил баг от того, что точка чтения съехала.
qw1
07.10.2018 15:17В интерпретаторе легко делается выполнение произвольного выражения, введенного оператором с клавиатуры.
Антипример — классические BASIC-и времён 8-битных процессоров. Имея произвольное выражение (в виде строки, например), вычислить его сложно, т.к. интерпретатор не предоставляет таких ф-ций.Jef239
07.10.2018 16:46Исходный BASIC — это компилируемый язык, отсюда ограничение на 26 FOR (страница 55). В нем не было строк, даже в PRINT использовались метки (страница 31). Типов в нем тоже не было — все было FLOAT.
Имелся ли ввод строк в BASIC на 8080 — не знаю, скорее всего нет. А без ввода строк и строчных операций eval не нужен.qw1
07.10.2018 18:20Я про бейсики на всяких ZX-Spectrum, Commodore 64 и прочих БК-0010. Строки там есть, eval нет.
Jef239
07.10.2018 19:35Вики утверждает, что на БК-0010 бейсик компилировался:
была возможность отказаться от исходного текста и использовать только «скомпилированную» версию программы.
Про спектрум и коммондор — копайте сами.qw1
07.10.2018 19:49У меня спектрум был, и я очень неплохо разбирался в его внутренностях. Там ничего не компилировалось. Да, БК не было. Значит, классический BASIC таки компилируемый, но для меня он навсегда интерпретатор )))
Jef239
08.10.2018 01:10Самый простой способ реализациия для любого языка — это компиляиция в код виртуальной машины, очень похожей на этот самый язык. А уже вирт-машина
интерпретирует операторы. Ну то есть примерно как в FORTH.
Можно по скорости цикла посмотреть, была ли там компиляция. Скорость при чистой компиляции (без оптимизации, то есть фортран) — в 1.5-2 раза меньше скорости ассемблера. Скорость форт-систем — в 10-20 раз ниже скорости ассемблера. А скорость чистой интерпретации — намного хуже.
Чистая интерпретация была в FOCAL, по ощущениям — ну раз в 10-20 медленней FORTH. По ощущениям, фокал при каждом обращении искал значаение переменной по её имени.
Source
05.10.2018 22:20Это будет парсер выражений в данном случае.
Jef239
05.10.2018 22:25Парсера мало — нужно ещё и уметь вычислять выражения. Получается парсер + интерпретатор байт-кода + хранение скомилированного байткода. Примерно так и живет JAVA.
0xd34df00d
05.10.2018 22:42+1У вас там где-то пропущен этап преобразования из AST джавы в байт-код, что и составляет ядро компилятора, тащем.
Jef239
05.10.2018 23:03Для многих языков — это 100 строк. Сложный этап — это оптимизация AST и навешивание на него атрибутов. Байткодовую машину нет смысла делать слишком низкоуровневой.
Jef239
05.10.2018 19:27Чтобы вы понимали — технология без компиляции — это как в калькуляторе. Интерпретация каждого вводимого символа. Так (на конечном автомате) можно писать можно, но будет сложнее, чем с компиляцией.
0xd34df00d
05.10.2018 21:09Эм, а как вы будете парсить, скажем, описываемый регулярным языком поток байтиков в токены, например? Это вам и при компиляции пригодится.
Jef239
05.10.2018 21:16Поток байтиков в данном случае — не алгоритм, а данные. Поэтому он и «парсится», а не компилируется.
А вообще это лет 50 уже известно, что в интерпретируемых языках для скорости и отлаживаемости лучше вначале компилировать в AST или байт-код, а потом его исполнять.
Но есть и чисто интерпретируемые реализации, классические калькуляторы — это типовой пример.0xd34df00d
05.10.2018 21:47Текст программы на произвольном языке, тащем, тоже не алгоритм, а данные.
Jef239
05.10.2018 22:16Текст программы — это алгоритм. Это не мешает ему одновременно быть набором байтов или данными файла.
А вот трудовой договор — это не алгоритм. В нем нет последовательности действий. Так что приходим к странному результату — текст программы на декларативном языке алгоритмом не является.0xd34df00d
05.10.2018 22:24По вашему определению любые зачатки параллельности или конкурентности тоже перестают быть алгоритмом.
Определения в декларативном языке вполне задают себе частичный порядок, а этого, вообще говоря, достаточно для вывода последовательности.
В принципе, если начинать играть в логику и определения, то начинаются всякие забавные эффекты, вроде того, что текст программы без сопоставленного ей перевода в фиксированный формализм (МТ, например) тоже совсем не алгоритм. Между текстом, который надо прогнать через gcc для получения относительно рабочей программы, и текстом, который надо прогнать через xor по 1011, а уже потом через gcc, разницы не сильно много. Если вам охота пятничным вечером поупражняться в таких играх — я с радостью поддержу.Jef239
05.10.2018 22:26Нет, не охота. 6-) Давайте сойдемся на том, что если мы сохраняем на диск и читаем откомпилированное представление — у нас есть этап компиляции.
Jef239
05.10.2018 18:57На самом деле отличие в том, что для меня нормальный джун — это школьник или студент. А после окончания института — должен тянуть на миддла. Ну или человек неверно профессию выбрал и весь институт — учился вместо того, чтобы работать.
Джун после 25 лет — это нонсенс. Ну разве что человек пришел в программирование из физиков или строителей.
0xd34df00d
05.10.2018 18:48Вы так говорите, как будто компилятор — это что-то сложное.
Это зависит от языка. Компилятор регулярок — не особо сложное. Компилятор языка с зависимыми типами — ну уже довольно-таки.Jef239
05.10.2018 18:55Не зависит. :-) Следите за руками.
Если написанием компилятора мы упрощаем код и сокращаем время на разработку — значит компилятор менее сложен, чем остальной код. Ели компилятор сложнее, чем его замена — зачем его писать?0xd34df00d
05.10.2018 19:13Если написанием компилятора мы упрощаем код и сокращаем время на разработку — значит компилятор менее сложен, чем остальной код.
Это почему?
Ели компилятор сложнее, чем его замена — зачем его писать?
Чтобы сэкономить время.
Jef239
05.10.2018 19:22Разве можно сэкономить время, написав сложный код вместо простого? Время, если очень грубо, примерно равно квадрату сложности кода.
0xd34df00d
05.10.2018 21:09Можно, конечно, если простого кода надо много.
Jef239
05.10.2018 21:17Ну если очень много… :-))) Но пример как-то в голову не приходит.
0xd34df00d
05.10.2018 21:48Зачем есть boost.spirit, если написать конечный автомат руками куда проще, чем обмазываться шаблонным метапрограммированием на С++03?
Jef239
05.10.2018 22:05важнее, что проще понять и отладить. Учить библиотеку ради разового применения обычно не выгодно.
0xd34df00d
05.10.2018 22:44Я в бесконечное количество раз буду более счастлив поддерживать парсер на спирите или даже на каком-нибудь lex/yacc, чем самописную стейтмашину типа той, что выплёвывает lex/yacc/ragel.
Jef239
05.10.2018 22:59взаимоисключающие параграфы. Или самописную и понятную автору — или автосгенеренную и понятную лишь тому, кто писал код yacc.
0xd34df00d
05.10.2018 23:02Вы что, поддерживаете и ковыряете то, что вам выплёвывает кодогенератор, вместо его входной программы?
Jef239
05.10.2018 23:13Нет, самописная стейтмашина — это именно самописная. Написанная ручками, без кодогенераторов. Сделать из описания протокола БНФ — займет времени побольше, чем написать стейт-машину. Пример протокола.
fatronix
05.10.2018 11:58+1С блога автора оригинального поста:
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.
OnelaW
05.10.2018 12:25Не впадайте в крайности. Срединного подхода нет и никогда не будет. Новички необходимы в силу эволюционного развития каждой компании. Кто-то из старших разработчиков эволюционировал до руководящей или менторской работы, кто-то наоборот деградировал, кто-то остался на том же уровне. Да и по хорошему перетекание сотрудников с примерно одинаковым уровнем знания влечет к деградации к отрасли в целом. Пример не связанным с программированием это перетекание закостеневших ciso из одной компании в другую. Да у человека имеется огромный багаж знаний, но есть минус потребности в безопасности у компании эволюционируют, так же и с написанием кода. Предугадать какие библиотеки и какие языки будут востребованы и актуальны в проектах в следующем месяце или квартале не возможно.
Jef239
05.10.2018 12:57Однако тут есть маленькая проблемка: как их найти?
Это как просто. Любой программист младше 12 лет :-) — это будущий крутой сеньор.
Вопрос не в том, как их найти — места обитания таких людей известны. Вопрос в том, как их удержать. Слишком уж меняются интересы по мере взросления.
P.S. У меня был 17летний сотрудник, которого, по-хорошему нужно было ставить руководителем группы вместо меня. В 17 он был на третьем курсе и четвертый год программировал за деньги. Собственно многие его знают как человека, придумавшего идею языка Котлин и написавшего первую книжку по нему. Вот только даже в 14 — он уже был мидлом.
BiW
05.10.2018 13:01-1У меня есть вот вопрос — ну, ОК, все перестали нанимать джунов. Где через 5-10 лет вы планируете нанимать новых сеньоров, на замену умершим/вышедшим на пенсию? Ведь сеньоры получаются из джунов, но раз джунов никто не нанимает, то и новых сеньоров не появляется…
Jabher
05.10.2018 13:33Почему же. Если оглядеться на реальный мир — можно увидеть, что джунов нанимают аутсорс-конторы, чтобы продавать их как миддлов, а заодно тренируют их проходить собеседования на миддлов. Заодно они же занимаются раздуванием кода программных продуктов, чтобы нанимать и продавать больше разработчиков, и их как раз устраивает низкое качество кода — можно заодно QA продавать.
А в момент, когда человек понимает, что не способен в своей доменной области в компании отрабатывать с желаемым уровнем качества — он начинает искать компании из второй категории.
И да, скорее всего любая компания, которая говорит, что не нанимает джунов, наймет человека, который будет сидеть по 24 часа в сутки, переделывая собственные ошибки и подходя с вопросами ко всем. Просто джуны обычно сейчас ждут, что их будут носить на руках, потому что они прошли двухмесячные курсы. Увы, говорю как человек, который занимается интервью последние пару лет довольно часто — как себе, так и другим проектам.
s-kozlov
05.10.2018 13:41А что если все программистами станут? Дворы же некому будет подметать. И хот-доги делать. И операции на сердце. Ну на фиг, не пойду на программиста, а то вдруг вся планета побежит за мной повторять. Лучше поступлю в мед, стану кардиохирургом. И пол поменяю, а то что если все мужиками станут. Буду женщиной-кардиохирургом. Хотя, что если все станут женщинами-кардиохирургами…
Filippok
05.10.2018 14:26-1явный признак токсичной корпоративной культуры
Не вижу в этом ничего плохого, даже наоборот: токсичная культура способствует росту скила.
mkshma
05.10.2018 14:48Нанимайте джунов только в двух случаях: вы корпорация и коллекционируете программистов, либо вам очень тяжело заманить высокоуровневых программистов. Джунов которые пишут не говно — считанные проценты. Джунов, которые считают иначе — более 90%. И вот где-то среди тех долей процентов, где джун пишет не совсем говно и трезво оценивает свои возможности, пытаясь избавиться от недостатков, лежит ваш не ограненный алмаз. Так что тут нужно быть либо ну очень терпеливым, либо ну очень уверенным в своих оценках и методиках отбора.
Mimus_spb
05.10.2018 16:19-1Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.
Правильно ли я понял, что имеется в виду, что старшие разработчики будут экономить время за счет делегирования задач джунам?
если даа-ха-ха-ха-хаVyaza
05.10.2018 20:19Я дико извиняюсь, но разве комментарии к статьям не принято писать, собственно, в комментариях? А это именно комментарии, никакого анализа даже близко нет.
CyberMouse
05.10.2018 20:19Обычно компании, которые нанимают только сеньоров, на самом деле нанимаю джунов, которые маскируюся под сеньоров, так как если нету сотрудников разного уровня, то и сравнить их проблематично.
justjeckill1993
05.10.2018 20:19Всегда было интересно, из какого пальца высасывается то, чего не было в оригинальной фразе. Где было про долг и про бюджет? Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.
Мне вот больше интересно, автор, а где Вы выловили такую мысль в приведенной статье? Автор статьи, которого Вы местами нещадно критикуете, всего лишь делает вывод на основании представленных пунктов. В принципе, тоже самое делаете и Вы, вот только у него вывод намного ближе к истине, чем Ваш…
И таких недочетов, на самом деле, у Вас еще очень много.
HACKcAtt
05.10.2018 20:19Немного лирики: если в армии оставить одних генералов, то кто будет носить патроны и мыть полы?
По делу:
— Есть, как уже тут отмечали, более сложные задачи, есть более тривиальные (ну там CRUD'ы и иже с ними). Использовать на тривиальных задачах сеньоров (в случае, когда, нет автоматизации производства такого рода кода) — почти что как забивать микроскопом гвозди.
— Джун, действительно, может взглянуть более свежим и упрощённым взглядом на вопрос, и иногда это бывает полезно.
— Джун — это инвестиция компании в будущее. И если в компании хорошие условия, то джун станет расти и приносить ей пользу (за исключением экстремальных личных обстоятельств, когда джун вынужден куда-то переехать или по иным особым причинам покинуть работу).
USBLexus
05.10.2018 20:30Хочется еще обратить внимание что оригинальная статья это перевод статьи автора из США, где рынок программистов более другой чем в РФ. По сравнению с ним в РФ на рынке труда программистов «как грязи» и расслоение по зарплатам не так значительно. В РФ позиция сеньора закрывается за недели, в США многими месяцами с кучей собеседований. Где в РФ выгодно нанимать сеньоров у «них» имеет смысл обучить джуна.
Katemare
06.10.2018 09:23Так ли это — про сеньора за считанные недели? Мне, к сожалению, случалось наблюдать лишь обратное. Возможно, это как раз та разница в привлекательности компании и перспективности проекта.
stul5tul
07.10.2018 14:14По сравнению с ним в РФ на рынке труда программистов «как грязи» и расслоение по зарплатам не так значительно.
Шта? «Хорошо только там, где нас нет». Полюбопытствуете медианам зарплат в США — многое для себя откроете.
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 лет опыта.
Где в РФ выгодно нанимать сеньоров у «них» имеет смысл обучить джуна.
Ничуть.
Зависит не от страны, а от особенностей конкретной компании.
HACKcAtt
08.10.2018 00:38«Сеньор это от 7 лет опыта», — разрешите узнать, почему?
В IT разве есть строго формализованное понятие «выслуги лет» аки в армии? Мне думается, что развитие и приобретение большего опыта не всегда коррелирует с временем. Как тут и в других местах уже писали, можно и семь лет сидеть на тривиальных задачах, не став, разумеется, сеньором. А можно и за год-два плотной работы как в команде, так и над своими навыками, получить колоссальное развитие. Ибо всё это условно, и нельзя ставить рамки. Но даже если как-то попытаться усреднить, то семь лет — многовато для сеньора. Я вижу (сугубо личное мнение) эту планку где-то в 4-5 лет. Быстрее, если разработчик крайне талантлив и трудолюбив, плюс для него есть толковые задачи.
MacIn
05.10.2018 20:40+1Никто не говорит, что джуниоры — враги. Их просто не нанимают. А еще не нанимают, например, слесарей и художников.
Ну, передергивание же. «Джун» — это уровень квалификации, «слесарь» — представитель другой профессии вообще.
D01
05.10.2018 21:37+1Если не нанимать джунов, то кто-же будет выполнять рутинные простые операции?)
index0h
06.10.2018 01:54По вашему рутинные простые операции синьоров не достойны и просто будут отброшены, без наличия джунов?
D01
06.10.2018 08:37Конечно нет, но так более производительней и дешевле
index0h
07.10.2018 03:27На счет более производительней — очень сомневаюсь, на счет дешевле — согласен.
stul5tul
07.10.2018 14:21Конечно нет, но так более производительней и дешевле
Так их после джунов еще и проверять и перепроверять.
Netflix же может себе (благодаря финансовым возможностям) позволить сразу делать качественно.
NeverIn
05.10.2018 22:20Некоторые мысли настолько точны, что статью добавил в закладки, а тезисы выписал.
Zet_Roy
06.10.2018 02:53Только где компания возьмет столько сеньоров и мидлов? Я видел как некоторые тривиальные вакансии(JS/React) по 6-12 месяцев висят и пересоздаются раз в неделю чтобы быть в топе. Это наверное те компании которые называют себя «высокотехнологичными с уникальным программным продуктом».
Я боюсь представить сколько времени висят вакансии на С++ сеньора.
Искать сеньоров оправдано в таких областях как разработка нейросетей, игр, игровых движков, научный софт.
Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.stul5tul
07.10.2018 14:26Только где компания возьмет столько сеньоров и мидлов? Я видел как некоторые тривиальные вакансии(JS/React) по 6-12 месяцев висят и пересоздаются раз в неделю чтобы быть в топе. Это наверное те компании которые называют себя «высокотехнологичными с уникальным программным продуктом».
Я боюсь представить сколько времени висят вакансии на С++ сеньора.
Если в компании много, ну скажем, 100 разработчиков (а это еще не особо и большая фирма всего-то «малый бизнес»), то нескольких из них постоянно приходится донанимать.
Чисто статистически: кто-то заболевает или впадает в депрессию, кто-то умирает, кто-то вырастает из джуна, кто-то уходит в другую фирму, кто-то разочаровывается в профессии и становится таксистом, кто-то уезжает в другой город по семейным обстоятельствам, и это не считая того, что сама фирма может рости.
Чем больше сотрудников, тем больше в абсолютных цифрах (не в процентах, конечно) доля подобный флуктуаций численности.
Это не одна и та же вакансия, хотя и называется одинаково.
Ну вот скажите, зачем фирме проплачивать отдельно публикацию вакансии на каждого нанимаемого сотрудника, если должность одна и та же. Что там каждый раз изменяется? Новые контактные данные HR, что ли? Кадровичка на нового сотрудника новый сотовый себе покупает что ли?
stul5tul
07.10.2018 14:32Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.
Ну это если он до этого уже был сеньором в другой сфере разработки. И то, 2 недели тебе нужно просто чтобы войти в рабочий ритм фирмы, только чтобы понять «где какие файлы принято складывать» и т.п.
джун за 2-4 недели набирает нужный уровень.
Не всех заказчиков устраивают дико тормозящие сайты.
Не все заказчики довольствуются сайтами визитками или интернет-магазинами, где при изменении цены у поставщика приходится по всем 1000 товарам проходиться вручную меня цену.
Zet_Roy
07.10.2018 15:57Не всех заказчиков устраивают дико тормозящие сайты.
Не все заказчики довольствуются сайтами визитками или интернет-магазинами, где при изменении цены у поставщика приходится по всем 1000 товарам проходиться вручную меня цену.
Ты преувеличиваешь сложность создания сайтов.
gdt
06.10.2018 08:25Про библиотекарей совсем не в тему пример, джун — это в какой-то мере степень профессионального развития программиста, я не думаю, что библиотекарь или слесарь может считаться таковой.
third112
07.10.2018 13:25Когда занимался физ-хим. экспериментом в одном из ведущих НИИ АН СССР (РАН), часто заказывал нестандартные устройства/детали на опытном производстве при этом НИИ. Неоднократно слесари шестого разряда предлагали решение гораздо более технологичное для них и гораздо более удобное и надежное для меня. Там были «ювелирные работы». Но, к сожалению, не у всех слесарей 6-ой разряд. В том же НИИ пара опытных библиотекарей, часто не смотря в каталог, подсказывали наиболее востребованную книгу по узко-специальной теме. И физика и химия — очень большие, и в полном объеме их знать не в человеческих силах, и часто бывает нужной справка из области, с которой не имел до этого дела. Библиотекарши, проработав несколько десятков лет, запоминают десятки тысяч заголовков и могут сильно сэкономить время поиска нужного источника. Гуглу пока остается только мечтать о таком поиске. Чуть сложнее запрос — выбросит сотни тысяч ссылок, и только доли процента окажутся нужными (см., нпр., картинку — но это не самый тяжелый случай).
gdt
07.10.2018 13:50Я же не говорю, что библиотекари, или слесари — плохие и ненужные люди.
Моя мысль в том, что они ну никак не вписываются в квалификацию джун/миддл/сеньор, в их прямые обязанности не входит написание кода, и сравнивать найм джунов в IT-компании с наймом библиотекарей/слесарей в IT-компании, как минимум, неверно.third112
07.10.2018 14:07ИМХО в сравнении «джун vs сеньор» несколько факторов. Один из важных — это опыт. Программист-сеньор, как и опытный слесарь, как и опытная библиотекарша зачастую вспоминают похожую задачу, которую уже решали. Но иногда это решение может оказаться устаревшим и прилежный джун может найти (нпр., в инете) новое более эффективное решение, еще не успевшее стать общеизвестным. С этой точки зрения любой нетривиальный труд вписывается — такой своеобразный изоморфизм.
Scf
06.10.2018 10:12Имхо, джуны имеют смысл в четырех случаях:
- У руководства имеется мнение (почти всегда ошибочное) что хороший сеньор с командой джунов выдаст продукт сеньорного качества со скоростью команды джунов
- Нанимаем джуна, по-быстрому подтягиваем до миддла, продолжаем платить как джуну — чистый профит.
- Недорого, быстро и при этом работает — осознанная политика руководства.
- Нужны узкопрофильные или лучшие специалисты и при этом есть деньги на их выращивание.
stul5tul
07.10.2018 14:37Нанимаем джуна, по-быстрому подтягиваем до миддла, продолжаем платить как джуну — чистый профит
Это не лишено смысла.
Миддлом он конечно не станет быстро.
Но уровень «начинающего джуна» и уровень «джуна с опытом», действительно, разительно отличается.
Недорого, быстро и при этом работает — осознанная политика руководства.
Не всем нужны высокие технологии.
Разработка уже давно не является элитной профессией. Раскатать CMS и щелкнуть в ней пару галочек уже и головастые «менеджеры по продажам» способны.
У руководства имеется мнение (почти всегда ошибочное) что хороший сеньор с командой джунов выдаст продукт сеньорного качества со скоростью команды джунов
Как правило просто нет бюджета на сеньора + 3 миддлов.
Далеко не всегда имеется уверенность что проект взлетит, потому невозможно привлечь инвестиции. Дорогая ИТ-шная разработка — это риски.
qw1
07.10.2018 15:29Исходная статья говорит о том, что плохо не то, что принимаются только высокоуровненые специалисты, а плохо то, что Netflix выпячивает это как корпоративную ценность.
Посмотрите на Google — там есть и стажёрские позиции, и средние. Но, чтобы туда попасть, нужно на собеседовании показать такой же уровень, как у сеньора в Netflix. Зато сразу декларируется возможность роста. В Netflix, если тебя взяли синьором, то это уже потолок.
stranger777
07.10.2018 23:14Компания никому ничего не должна. Даже если она разорится — это ее право.
Вот это, среди прочих вполне здравых аргументов, крайне странная… эммм… сентенция. Компания должна — по определению. Начиная с налогов и отчётности и заканчивая зарплатой. А если она разоряется, то и говорить уже не о чем. Да, есть такое право — расформировать компанию. Но давайте не будем путать просто ликвидацию юрлица со стратегическими ошибками, которые приводят к упадку, либо невозможности исполнять то, что компания должна.
avraam_linkoln
Один вопрос автору — сеньор будет в восторге от того что 80% своего времени будет круды писать? И стоит ли за эти круды платить по 40-50 баксов в час?
some_x
А если в компании нет таких задач?
avraam_linkoln
Таких компаний крайне мало. Я думаю даже в Америке таких не большинство. В том же Гугле тысячи работников, думаешь они все решают сложные задачи? Большинство те же круды пишет. Читал как то статью чувака, который поработал там
stul5tul
Гуглевские джуны != обычным джунам.
Есть же статьи на Хабре от тех, кто там работал. Даже младшие программисты Гугля — это далеко не каждая компания таких сеньоров может себе позволить/не каждая компания нуждается в таких слишком over-квалифицированных сеньорах.
daiver19
Это неправда. Полно джунов только после универа. Не глупые, конечно, но и не мега-кодеры и уж тем более не сеньоры.
qw1
Джуны гугла знают, как умножать матрицы? Могут написать обход графа в ширину и в глубину? Имеют представление о системах управления версиями? Имеют базовые знания о протоколе HTTP, чтобы записать простой запрос и простой ответ?
Если всё это — да, то
daiver19
Я все это знал устраиваясь джуном в местную контору на 3-м курсе. Вроде как это базовые вещи, которым учат в универе.
qw1
Одно дело, учат, а другое дело — научили.
s-kozlov
Если человека учили умножению матриц, то не важно, насколько качественным был процесс. Даже если просто сказали, что есть вот такая штука — умножение матриц, уже можно пойти в интернет и погуглить, что это, как делать и зачем.
Zoolander
по моему опыту — в любой компании всегда есть пакет задач, в которых нужно поправить запятую, поменять цвет кнопки, исправить опечатки
как минимум один джун мог бы на этом сидеть, пока старшие решают хорошие проблемы
Ну и можно давать джуну время от времени настоящие задачи — чтобы рос
algotrader2013
По моему опыту, как раз в таких задачах, сеньоры и лиды показывают очень высокий перфоманс (когда не ленятся). Потому, что исправить сам цвет — 2 секунды. Найти это место в коде — до 30 секунд для сеньора и до часа для джуна.
SirEdvin
В 21 веке у вас есть кодогенерация и рефлексия, что бы круды писали сами себя, а вы только создавали модели и регистрировали ее.
Если у вас 80% времени нужно писать круды — вряд ли ваша компания может назвать себя высокотехнологичной.
dididididi
Истинный Сеньор!)) Там где можно за неделю написать круд, он за месяц напишет рефлексивный кодогенератор круда, или вы просто спринг дату имели ввиду?
SirEdvin
Зависит от того, что вы используете. У большинства популярных фреймворков уже есть библиотеки для быстрой имплементации crud.
Если же нет, то таки да, взял бы и написал. И вместо четырех месяцов был бы один. Вы же не пишете crud один раз и навсегда, обычно сущности потом добавляются.
Ну и месяц это как то дофига, правда.
dididididi
Ой, извините я про JAVA пишу, не думая, что есть другие ЯП, которые не обязаны знать наши библиотечки.
я не очень понимаю, что такое писать круд вообще, для меня это написать один родительский дженерик класс, который реализует 4 метода. Что имеет ввиду автор не до конца понятно, но он наверно имеет ввиду написание любого бойлерплейт кода))
RPG18
Вы не поверите, но тот же swagger есть и под Java.
dimkrayan
какой же он кривой этот сваггер (именно кодогенерация).
xpendence
Карма -9. По тонкому льду ходишь, Дмитрий ;)
0xd34df00d
Написал реализацию круда на дженериках где-то за один день, брат жив, теперь только структуры данных описываю.
algotrader2013
Хороший сеньор, написав 5 крудов, сделает генератор крудов, и после этого их будет писать БА. Либо этот же сеньор, но со скоростью 5 крудов в минуту. И чтобы достичь такой же производительности, надо ну очень много джунов + представьте себе каскадные изменения в таком копипастном коде.