Мы не нанимаем младших программистов и интернов… Если не заводить щенка, не придётся убирать лужи.
--Netflix
Я был совершенно поражён, как некое корпоративное нечто умудрилось представить щенков в отрицательном свете, да ещё кого-то этим убедило. Щенки — самые чистые создания на Земле, живая пушистая радость! Лучики света в одиноком мире. Но перейдём к сути.
Многие компании последовали данной стратегии «нанимать только сеньоров». Они обосновывают это так:
- У нас нет времени и ресурсов нанимать младших программистов; мы слишком быстро развиваемся.
- Наша компания может себе позволить сеньоров, так что в джунах нет необходимости.
- На текущем этапе мы не можем позволить себе ошибки. Ставки слишком высоки.
- Наш процесс предоставляет сотрудникам большую автономность. Мы не готовы держать джунов за ручку, как они в том нуждаются.
- Мы хотим заложить фундамент продукта прежде, чем начнём нанимать неопытных сотрудников.
Посыл состоит в том, что младшие программисты представляют собой риск, некий шаг, на который компания идёт либо из чувства общественного долга, либо из-за нехватки бюджета. Получается, что другие компании, должно быть, могут позволить себе корпоративную благотворительность и второсортные результаты, но уж точно не мы.
Кстати говоря, в США более 100 000 IT-компаний, и что-то я не слышал, чтобы хоть один CEO сказал «подумаешь, ошибки!» или «надо бы спустить куда-нибудь лишний бюджет». Так что внимание, организации, где «джунам вход воспрещён»! Какими бы вы ни видели свои выгоды, как бы вы ни обосновывали свой лайфхак, реальность такова, что вы всё это себе выдумали. Нет никакого конкурентного преимущества в избавлении от джунов. И вы только что продемонстрировали миру свой проблемный менеджмент.
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 в год. Сеньоры стоят более чем в два раза дороже, чем джуны.
Эти затраты часто оправданы. От старших программистов ожидается бОльшая продуктивность, чем от младших. Но этим картина не исчерпывается, и вам встанет в копеечку бездумное и ленивое обосновывание повышенных затрат как издержек ведения дел.
Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $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 лет оставаться старшими программистами. Они мечтают стать программными архитекторами, тимлидами, техническими директорами и основателями студий. А компания, которая кичится своим безразличием к росту карьеры, обнаружит себя внизу списка перспективых работодателей.
I only recruit senior devs.
— Reginald Braithwaite (@raganwald) 17 сентября 2018 г.
The trick is, I recruit some of them earlier in their career.
Я нанимаю только старших программистов.
Хитрость в том, что некоторых из них я нанимаю в начале карьеры.
Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна». Очень впечатляет и очень большая редкость. Такой человек чрезвычаяно важен для компании — он знает всё о продуктовой линейке, он видел код всех проектов в радиусе ста метров, и он поработал со всеми сотрудниками компании. Он способен предлагать нововведения в рамках компании как никто другой. А компания зарабатывает несчётные дивиденды от труда этого человека, потому что смогла понять, как удержать его интерес восемь лет — примерно 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 г.
Компании, жаждущие нанимать только старших специалистов, часто упускают из виду, что забыть лишнее — зачастую сложнее, чем выучить нужное.
Иногда задача проект-менеджера — это сказать «Я знаю, что это не сработало там, но, может, сработает у нас». А младший программист — обычно лучший кандидат, чтобы проверить такую теорию: он может собрать пробу идеи или прототип, не втягивая в это предрассудки, накопленные старшим программистом за годы. В качестве младшего программиста я часто выполнял такую работу, проверяя новые инструменты и технологии, переписывая фрагменты кода альтернативным образом, испытывая идеи, которые другие сотрудники поспешно отмели. Я часто открывал улучшения архитектуры, и софт компании становился осязаемо лучше. В некоторых случаях удавалось ускорить загрузку страницы на порядок; или несколько страниц соединить в одну, избежав недель поддержки в будущем; или избавиться от неэффективных технологий, которые привели бы к потере времени. Подобные преимущества неотягощённого, свежего взгляда нельзя упускать.
Многие компании могут позволить себе такую расточительность, как решение проблемы или написание кода методом запирания нескольких старших программистов в переговорке, чтобы к чему-нибудь пришли. Но если туда добавить несколько джунов — то есть разработчиков, чьё время допустимо потратить на разовые эксперименты и необычные идеи — то можно убедиться, какие улучшения это даст вашим продуктам.
Что касается качества софта, младшие программисты обычно выполняют важную работу, которую мало кто замечает: они сдерживают заумный, перемудрённый код, который склонны писать их старшие коллеги.
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 принцип «только сеньоры» недооценивает младших программистов. Это плохо сказывается на всех, особенно когда организация считает, что без начинающих специалистов всё будет даваться легче. Хотя некоторые подобные компании финансово успешны, можно представить себе колоссальные растраченные суммы которые приходится сносить их бюджету из-за такого подхода.
Если ваша компания обгоняет конкурентов по данному вопросу — то есть знает, как нанимать, обучать и удерживать младших программистов — то вы сами уже ощущаете все те преимущества, которые я лишь поверхностно описал в данной статье. У вас ниже текучка, выше разнообразие специалистов и меньше оверхеда, чем у конкурентов. В вашем софте меньше багов и больше радости. Есть, конечно, и другие факторы. Но положительный подход к младшим программистам — важный знак качества офиса на всех уровнях.
Комментарии (258)
avraam_linkoln
04.10.2018 09:08-1Особенно смешит когда ищут сеньоров с минимум 5 годами опыта работы с языком, который появился 5 лет назад) По Go видел вакансии только на сеньоров, при том что еще 3-4 года назад на том же хабре его обсуждали как некий экзотичный язык, игрушку, которая вряд ли будет когда то использоваться в продакшене)
Neikist
04.10.2018 09:27Так может ищут сеньеров-независимо-от-языка знающих при этом go?
avraam_linkoln
04.10.2018 09:53Вот именно что нет
boblenin
05.10.2018 06:19Спрос рождает предложение. Если сильно будут искать — найдут таких. Сомнений нет :). Рано или поздно.
staticmain
04.10.2018 09:28Стоит отметить ещё один, неизмеримый фактор: тенденцию старших программистов к постоянным спорам на темы, которые в конечном итоге ничтожны — про алгоритмы, микрооптимизации и стиль кода.
ничтожны
алгоритмы, микрооптимизации
То-то я смотрю бурления комментариев до степени зависания страницы в соседнем топике не было. Пусть все, кто жалуются там купят себе еще три плашки RAM.springimport
04.10.2018 17:52Но это рано или поздно закончится: уже сейчас куча сложностей с процессорами и скорость ядер остается поднимать разве что частотами.
staticmain
05.10.2018 10:21Будут массово ставить два процессора на борду, подумаешь.
springimport
05.10.2018 16:18Да и уже сейчас некоторые ставят, бгг)
Но проблема в скорости одного ядра никуда не уходит, а распараллелить все не удастся.
b00taNik
04.10.2018 09:30пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости
Смелое заявление, к реальности не имеющее отношение к сожалению.
Не учтены такие вещи, как:
— Отвлечение сеньора на консультации
— Предварительное программирование на русском с переводом всего этого в программный код
— Готовность к нескольким этапам переделок.
В рамках статьи программисты воспринимаются, как некоторые черные ящики, которые на входе принимают кофе с тасками, а на выходе — код. Как бы вам не хотелось, это не так. Еще Брукс доказал, что введение даже равного специалиста в команду, сильно ее охлаждает. В статье же утверждается, что полтора программиста дадут выхлоп 150%, что противоречит Бруксу. В реальности эта цифра ближе к 110%, если вообще не ниже 100%, если джун совсем деревянный попался, или приходится менторить нескольких джунов.
Несмотря на некоторые спорные аргументы, в целом, с выводом статьи, согласен — в компаниях, которые не тратятся на развитие человеческого капитала, делать нечего — ни сеньорам, ни джунам.dimm_ddr
05.10.2018 14:33Вывод вне контекста правильный, но вот делать его только из того что компания не хочет нанимать именно джунов — уже нет. Компания вполне может заморачиваться развитием разработчиков, но при этом нанимать разработчиков уже с опытом. Даже сеньорам есть куда развиваться обычно.
YemSalat
05.10.2018 17:08> Не учтены такие вещи, как:
да эти 75% — вообще цифра из головы, че тут рассуждать
как и все рассуждения автора
судя по разделу about на сайте оригинальной статьи:
> I’m a software developer, a family man, a B.A. in English, and a Mormon. My writing is motivated by all of these things.
автор похоже все исследования провел в голове, сделал свои выводы и написал статью
aamonster
04.10.2018 09:33Не вижу проблемы. Не нанимают джунов одни — наймут другие: сеньоров на всех не хватит, и кому-то придётся учить своих. Так что в целом по индустрии найм джунов никуда не денется, а требовать его от конкретной конторы и делать о ней какие-то выводы на основании отказа — глупо.
P.S. Imho, в первую очередь найм джунов — это «хочешь стать женой генерала — выйди замуж за лейтенанта». Только тут всё быстрее — видел, как люди всего за пару лет раскрываются, не сильно косяча в процессе. Но из скольких надо выбирать для этого?
Aetet
04.10.2018 09:46Так и не увидел какую ошибку совершил Нетфликс и как это им помешало.
staticlab
04.10.2018 13:11+3Сложилось такое ощущение, что автора (или его протеже) в Нетфликс не взяли :)
werklop
04.10.2018 13:22Может он просто уволился, видя и картину происходящего
staticlab
04.10.2018 15:44voicetranslator
04.10.2018 18:24+1Судя по профилю на линкедине — автор сам еще порядочный «джуняра» (психологически), программировать начал менее 3-х лет назад, а до этого сидел в QA. Видимо, пока не пристроился в свою HealthCatalyst (а это не софтверная компания), пережил немало отказов из-за отсутствия практического опыта.
vac__pac
04.10.2018 09:56Возможно у Вас собеседовался разработчик не уровня «Middle»?
И столько компаний ищут разработчиков уровня «Middle», а оказывается, они не существуют в природе.
dom1n1k
04.10.2018 10:09+2Все аргументы — философское бла-бла и натягивание совы на глобус.
Описанный подход очень логичен и имеет право на существование.
Что, конечно же, абсолютно не значит, что не может быть других подходов.
rzerda
04.10.2018 10:52Бывает и обратная история: «сеньоров у нас уже вагон, давайте наймём табун джунов и научим их, заодно на ФОТе сэкономим». При этом все сеньоры либо не очень сеньоры, либо загружены работой по крышечку, либо не имеют интереса/способностей к обучению других. При этом как класс отсутствует тактика и стратегия обучения.
Netflix может передумать в любой момент и начать джунов набирать и учить. Описанные же товарищи, если решат поменять ситуацию, потратят на разворот хорошо если год, по дороге растеряв половину набранных и худо-бедно разбирающихся в происходящем людей.DistortNeo
04.10.2018 15:25+1Бывает и обратная история: «сеньоров у нас уже вагон, давайте наймём табун джунов и научим их, заодно на ФОТе сэкономим». При этом все сеньоры либо не очень сеньоры, либо загружены работой по крышечку, либо не имеют интереса/способностей к обучению других. При этом как класс отсутствует тактика и стратегия обучения.
Это уже особенности ведения бизнеса по-русски, где не считается нормальным, когда специалисты зарабатывают больше начальников.
a_e_tsvetkov
04.10.2018 10:53Существует всего две причины нанимать джунов: хорошая и плохая.
Джунам можно платить меньше. Это плохая причина. Потому что важно не сколько вы платите, а сколько получаете на потраченный рубль. От синьора вы получите больше.
Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.
Сеньоров не нанять. Это действительно причина. Если вам нужно много программистов, то может оказаться дешевле выучить их самим.
Если же вам нужно нанимать одного двух в год, то можно и подождать пока появится подходящий.
Я лично работал в синиор онли компании. Никаких проблем связанных с этим не заметил.WraithOW
04.10.2018 12:37Джуны справятся, но стоить это будет дороже.
Это сильно зависит от области и конкретных задач. Условно говоря, шлепать однотипные формочки — это задача больше механическая, и может больше зависеть от скорости печати чем от квалификации.dom1n1k
04.10.2018 12:52Вы недооцениваете таланты, коими богата страна. Я иногда, глядя в чужой код, ловлю себя на мысли, что не смог бы придумать такую дичь даже нарочно.
WraithOW
04.10.2018 16:00Не, ну я же не предлагаю просто взять пачку джунов, дать им стопку задач и забыть про них на месяц. Код-ревью, разбиение на небольшие задачи. Первое время, естественно, обратная связь будет отнимать много времени, но если джуны толковые — эти затраты довольно быстро сократятся.
И повторюсь — такой подход подойдет не всем и не на каждом проекте.a_e_tsvetkov
05.10.2018 06:53Т.е. все равно пока джуны не дорастут хотя-бы до мидлов на них будут тратить время сеньоры?
WraithOW
05.10.2018 13:27Конечно будут. И мидлы будут, и другие сеньоры (код-ревью и всё такое). Вопрос в пропорциях.
Чтобы говорить предметно: мы занимаемся мобильной разработкой. На приложение есть дизайн, спецификации на поведение и сеть. В самом приложении — куча типовых компонентов. Нужно сделать новый экран? Вот типовой класс, наследуйся, добавляй разметку и поведение. Персистентность? Вот типовой компонент, пропиши тип кеша, тип данных и используй. Запросы? Вот типовой… ну вы поняли. Это механическая работа, перемежаемая периодическими контактами с дизайнерами/аналитиками на предмет уточнить или добавить или поправить что-либо; для неё не нужно уметь проектировать высоконагруженные системы.
Можно ли вместо найма джуна написать суперфреймворк, который сам будет генерировать большую часть приложения по файлам с дизайном и документам со спецификациями? Мб можно, но джун дешевле. Можно ли посадить сеньора вписывать отступы и перебрасывать модели из одного компонента в другой? Можно, но джун дешевле, а сеньор может и сбежать от такой рутины.
a_e_tsvetkov
05.10.2018 06:52Вот тут и нужен опытный разработчик.
Чтобы написать скрипт/фреймворк и перестать шмалять однотипные формочки.
JediPhilosopher
04.10.2018 16:24+2и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже
Почему? Написать вагон бойлерплейта или пофиксить какие-нибудь мелкие баги джун вполне может. Он потратит больше времени, но в итоге оно может оказаться все равно дешевле.
Тут впрочем опять непонимание что такое «джун», так как формальных критериев никаких нет и каждый трактует как хочет. Если считать что это человек с нулевым опытом и посредственным знанием синтаксиса языка — то да, там лиду придется больше объяснять ему, чем если бы он взял и сделал сам. Но если это человек хотя бы с годом опыта работы, то мелкие задачи он может делать сам, и даже более-менее качественно (особенно если в компании реально используют всякие автоматизированные метрики качества — статический анализ, тесты и т.п., которые позволяют отсекать совсем уж криворукий новичковый говнокод без участия сеньоров)cyberly
05.10.2018 06:32Дороже это может начать стоить, когда написанное понадобится расширить. По метрикам качества есть сомнения. Если сеньоров нет, то реализация этих метрик с большой долей вероятности будет такой же, что и код. Тем более, я лично не очень представляю автоматическую оценку расширяемости.
a_e_tsvetkov
05.10.2018 06:57Написать вагон бойлерплейта
Не нужно писать вагоны бойлерплейта.
пофиксить какие-нибудь мелкие баги
Дешевле не будет, будет долше и все равно нужен синиор который отревьювит, объяснит как правильно. В конечном итоге потратив времени больше чем если бы сам фиксил баг.
Kroid
04.10.2018 18:32Аргумент что есть таски с которыми и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже.
А сеньоры поделают некоторое время джуновские таски, потом развернутся и уйдут. Потому что им у вас будет уже неинтересно.
a_e_tsvetkov
05.10.2018 06:59Не бывает джуновских тасков.
Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.cyberly
05.10.2018 07:43>> Не бывает джуновских тасков.
У вас разработана структура БД и есть ORM. Задача перевести эту структуру в то, что получит на вход ORM — чем не джуновская? Или с теми же формами, написать валидатор для очередной формы или добавить поле — чем не джуновская задача?
>> Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
Либо «поточное производство»a_e_tsvetkov
05.10.2018 08:42Первую задачу я не понял.
Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.
Поточное производство напрашивается на автоматизацию.cyberly
05.10.2018 08:57>> Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.
Во-первых, BA может и не быть. Во-вторых, в конфиг легко выносятся простые случаи, если же поля зависимы, то этот конфиг может превратиться в тьюринг-полный редактор макросов, который надо поддерживать, который непонятно когда окупится и в которым не факт, что пользователи захотят разбираться (и в итоге будет такая же джуновская задача по вбиванию условий в этот редактор). Ну и, банально, стоимость времени BA на «поиграться» может легко превысить стоимость правки кода.
>> Поточное производство напрашивается на автоматизацию.
То же самое, в конечном итоге все упрется в окупаемость. На заводе тоже не все гайки закручивают роботы.a_e_tsvetkov
05.10.2018 09:58Всегда есть кто-то кто ставит задачи. Если задачи тривиальные, то и ставить их можно в формальном виде и генерить из этого код.
Во-вторых, в конфиг легко выносятся простые случаи
Так мы и говорили про простые случаи. Если случаи не простые, то это задача для сениора. Он выполнит ее быстрее и надежнее.
упрется в окупаемость
т.е. ваш аргумент в том что джун это не только ценный мех, но еще и бесплатная машинистка?
Спорить не буду, но что-то мне подсказывает что профессиональная машинистка будет быстрее и дешевле.
dididididi
04.10.2018 11:16Граница между сеньорами и джунами весьма расплывчат — внезапно.
Сеньоры весьма различны. Один может проработал 10 лет на легаси проекте и спрингов в глаза не видел и тут джун его уделает легко.
Проблема оферквалифаед никуда не девалась. Сеньор, выполняющий джуновские задачи — печальное зрелище.
Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?DistortNeo
04.10.2018 15:22+4Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?
По-моему, таким страдают именно джуны.
cyberly
05.10.2018 06:37>> собенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка.
Это не сеньор, ИМХО. В моем понимании, сеньору можно дать задачу и быть уверенным, что он ее сделает так как нужно компании. Отсутствие перерасхода времени на оверинжениринг в это «как нужно» тоже входит.
>> Сеньор, выполняющий джуновские задачи — печальное зрелище.
Согласен. Но не в плане «лучше кодит». Тут, скорее, два момента. Первое, на задачах, где производительность упирается в скорость печати, он невыгоден. Второе, он может затосковать и потратить даже больше времени, чем джун.dididididi
05.10.2018 10:11Сеньору неинтересно в какой то момент становится, он начинает извращаться. И не докопаешься: например у нас он нормализовал базу по последнему уровню, так что она становится абсолютно нечеловекочитаема и непонятно никому кроме него. Да любой сеньор замучится собирать юзера по 8 таблицам, а там отмазка надо лучше учиться, база нормализована по правилам.
fatronix
05.10.2018 12:23Эм, нормализация не всегда полезна и синьор должен об этом знать. Чаще по ходу разработки возникает потребность в денормализации, когда в определенный момент производительность начинает упираться в БД.
PsyHaSTe
05.10.2018 12:29Первое, на задачах, где производительность упирается в скорость печати, он невыгоден.
Простите, а что это за задачи такие? Я всегда считал рабочим правило про «80% времени разработчик читает». И прочитать и понять, где нужны изменения сениор сможет сильно быстрее, нет? Хотя в с этим и не спорили, вы говорили на задачах, где скорость печати важна. Так что собственно повторюсь: это где такие задачи бывают?cyberly
05.10.2018 12:49Тупые «обезьяньи» задачи типа «сделать тут так же, как там, но только поменять это и это». Или даже просто «поменять это на то». В веб-разработке этого навалом. В таких задачах нечего читать и не о чем думать.
PsyHaSTe
05.10.2018 12:52+1Ну почему же, можно вынести компонент/пакет/… Копипаста ведь это не единственный способ решения задач.
cyberly
05.10.2018 13:22Можно, но только если понятно, что работать над проектом еще долго, а именно таких задач будет еще много. И, я чуть ниже приводил пример, если это какой-нибудь класс, представляющий конкретную форму, то это и так практически будет конфиг, только записанный на исполняемом языке. Список полей, их типы, функция валидации. Оттуда уже нечего выносить. Понятно, что когда есть десятки почти одинаковых форм, и притом в одном и том же проекте, можно что-то придумать, но когда их две и первый раз за год понадобилось добавить третью, при том что половина полей в них отличается… оно того не стоит.
Если проектов много, в режиме сделали-сдали-забыли, то версии компонента в них будут разные. Допустим в старом проекте нужно внести маленькую правку и снова на год про него забыть. Можно обновить версию компонента, тогда правка применится автоматически, но сломается что-то другое (ну например, понадобилась функция валидации ИНН, в новой библиотеке она есть, а в старой — нет, зато в новой несколько функций переименовано, несколько добавлено, и у нескольких поменялся интерфейс). В итоге вынос ничего не дал, а сделать «правильно» выходит сильно дороже.PsyHaSTe
05.10.2018 14:36Можно, но только если понятно, что работать над проектом еще долго, а именно таких задач будет еще много. И, я чуть ниже приводил пример, если это какой-нибудь класс, представляющий конкретную форму, то это и так практически будет конфиг, только записанный на исполняемом языке. Список полей, их типы, функция валидации. Оттуда уже нечего выносить. Понятно, что когда есть десятки почти одинаковых форм, и притом в одном и том же проекте, можно что-то придумать, но когда их две и первый раз за год понадобилось добавить третью, при том что половина полей в них отличается… оно того не стоит.
У меня одна из первых задач на первой работе состяла в том, чтобы написать две сотни однотипных конфигов (ну, не совсем однотипных). На задачу дали месяц. Месяц я потратил на написание генератора этих конфигов (парсинг powershell-скрипта, определение структуры конфига, и собственно генерация). После чего за 2 часа сделал все эти конфиги. В последующем, этот генератор мне не раз пригождался, и задача на день-два решалась за 15 минут.
Менеджмент тоже не видел тут массовости, просто я понимал, что каждую неделю приходят однотипные задачи. А вот руководство — не очень.
Если проектов много, в режиме сделали-сдали-забыли
Звучит очень печально.
Допустим в старом проекте нужно внести маленькую правку и снова на год про него забыть. Можно обновить версию компонента, тогда правка применится автоматически, но сломается что-то другое (ну например, понадобилась функция валидации ИНН, в новой библиотеке она есть, а в старой — нет, зато в новой несколько функций переименовано, несколько добавлено, и у нескольких поменялся интерфейс). В итоге вынос ничего не дал, а сделать «правильно» выходит сильно дороже.
Ага, и потом регрессия, потому что баги чинят в одних компонентах, а скопипащенные куски продолжают жить со своими багами, где их уже никто не починит, «дорого, да и сдали проект уже».
nick_gabpe
04.10.2018 13:21+3Я не совсем программист, я QA, но тем не менее очень обидно когда на российском it рынке люди не удосуживают даже копипастным ответом отклик Джуниоров на вакансию. Когда я был Джуниором это просто убивало. Сейчас я понимаю почему так происходит и что не везде так, но все равно это неправильно.
Вообще, по отношению к джунам, можно очень хорошо судить про отношению в компании к людям.
anatolymik
04.10.2018 14:38+7Во многом согласен. Де факто мы сталкиваемся с тем, что экономия денег сейчас, вырождается в последующие траты потом. Т.к. текучка не исключена, например. На мой взгляд, думать и делать на перспективу разучились почти все.
От себя могу добавить, что когда я был «джуном», меня никто также не хотел брать. Хотя я очень быстро обучался любой под-отрасли IT. Поэтому приходилось «шляться» по «помойкам». И через пару тройку лет, меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним. Ну и соответственно, работая на них, отношение к ним такое же. Я не буду думать о благе компании, я буду думать о своем благе поплевывая на их благо. И даже злонамеренно. Ну хотя бы потому, что я их ненавижу.
Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан. Это тоже правда. Возмущает сам факт циничности. Что только когда им надо. И дело не в том что мне должны. Дело в том, что им все должны.
Я и сейчас с этим сталкиваюсь, почему то я постоянно что-то должен. Я уже не говорю о том что отпуск в 2 недели, это не отпуск. 2 недели — это отходняк. И только потом ты начинаешь отдыхать. А объясняется это тем, что компании не выгодно…webcodecreate
04.10.2018 15:03Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан.
Вообще-то обязан, при найме на работу, вы, наверняка говорили об обязательствах за которые тебе платят зарплату.anatolymik
04.10.2018 15:08+3Сколько я себя помню, я всегда делал больше чем по договору. Я не помню чтобы меня за это хотя бы не упрекали. И что?
Назовите мне хотя бы одного добросовестного работника, который делал строго в соответствии с договором.
И не надо путать договор с текучкой. На практике, все не по договору.
Так что договорами можно причинное место вытирать. Они ничего не стоят. Потому что вас, все равно обманут.APXEOLOG
05.10.2018 09:10Я работаю по договору и на все попытки запрячь меня дополнительной работой четко и твердо ответил отказом. Это не сложно, если у вас с компанией чисто рабочие отношения, в случае прекращения которых вы без проблем найдете работу.
Проблемы начинаются тогда, когда вы боитесь работу потерять или у вас не хватает силы воли сказать "нет" — вот тогда на вас сядут и поедут
anatolymik
05.10.2018 10:51Вы описываете подход работника, который делает работу на «отвяжись». Если конечно деятельность у вас не творческая. Мешки таскать, нормальный подход.
В творческой деятельности, постоянно сталкиваешься с тем что надо что-то менять, по ходу разработки того или иного. Причем менять в областях за которые ты не отвечаешь, а сделать хочешь. Потому что хочешь сделать хорошо. Все эти разговоры можно не продолжать если вы мне скажете, что я должен собрать совещание, отправить запрос, и т.д. Так, ничего сделано не будет. В лучшем случае плохо. Проверено. Я уже не говорю о том, что в рабочем порядке решается 99% вопросов. Но во что оно выродилось, мы тоже знаем. А учитывая что, мне на пути люди с подобным, вашему подходу, попадались, я знаю, что с ними работать не возможно. Их хочется только бить. Много демагогии. О договорах и прочем. Однако дело стоит.
Причем тут сила воли и отказ?APXEOLOG
05.10.2018 11:02Если у вас вся компания держится на "эх ребятушки, затянем пояса" и "ну что ты, ради проекта без выходных не поработаешь", то это проблема компании, нет?
Не понимаю каким боком это имеет отношение к качеству работы
anatolymik
05.10.2018 11:24Если у вас вся компания держится на «эх ребятушки, затянем пояса» и «ну что ты, ради проекта без выходных не поработаешь», то это проблема компании, нет?
Это вообще о чем и причем?
Не понимаю каким боком это имеет отношение к качеству работы
Прямое. Объяснять надо? Лично я, судя по утверждению, не вижу смысла.
Я только добавлю, что если бы я на все что не входит в мои обязанности давал отказ, технически как специалист я не вырос бы. Я напротив, придерживался иного подхода, если просят сделать задачу и сложную, я брался. Только ради того чтобы ее решить. Потому что она сложная. Хотя в обязанности она могла и не входить. В конце концов это и на перспективу мне работает.
Иной раз, когда начальник просил(а я не со всеми из них был в хороших отношениях), я не выпендривался и делал. И отношение ко мне тоже с их стороны было соответствующее.
А ваш подход мне знаком, сугубо буржуйский. Поэтому, что касается упомянутых вами ранее поисков работы, скорее меня попросят, чем вас.
Вам что так трудно понять, что лично мне хочется строить отношения не только на деньгах? И я не единственный в этом списке. Таких людей много.APXEOLOG
05.10.2018 11:41Возможно мы вообще друг друга не поняли?
Решать задачи входит в обязанности разработчика — любой сложности. Не важна сложность, не важно в каких отношениях вы с начальником — это и есть профессиональный подход, о котором я говорю. Это все часть рабочего процесса. И этот рабочий процесс описан в договоре (как правило 40-часовой рабочей неделей)
Вы упомянули работу сверх договора — в моем понимании это ситуации, когда вам приходится работать больше времени, чем указано в договоре (переработки) или заниматься непрофильной работой (таскать шкафы например). Вот против таких вещей я и выступаю. Одно дело, если вас по-человечески попросили помочь разок, другое дело, когда этот "разок" потом превратился в данность.
anatolymik
05.10.2018 12:56Вы знаете, я сейчас выполняю сложную работу. И выхожу в выходные. Потому что если её не сделать быстро. Другой возможности не будет. Выходные мне никто не оплатит. Мой интерес — сделать её.
Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной. Если занять такую позицию.
Вот и скажите мне, чем мне договора помогут? Разве что у них нет законных оснований меня уволить. И все. Но цель которую я преследую, достигнута не будет. Я не боюсь потерять работу. Я боюсь её не закончить. Это важнее чем начать.
APXEOLOG
05.10.2018 13:08Так что договорами можно причинное место вытирать. Они ничего не стоят. Потому что вас, все равно обманут.
Так ведь и получается, что это ваш выбор — терпеть неудобства. Непонятно тогда к чему ваше недовольство
Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной
Так может она и не нужна бизнесу-то? В таком случае опять же непонятно, каким боком к этому всему относится договор и компания, если это по сути — ваша личная инициатива. Для сложных и интересных задач я лично использую pet-проекты, но тут уж каждый волен поступать как угодно
anatolymik
05.10.2018 13:16Так ведь и получается, что это ваш выбор — терпеть неудобства. Непонятно тогда к чему ваше недовольство
То что они потом этим пользуются у вас это возмущения не вызывает?
Они все понимают. Чего оно стоило. Можно хотя бы не хамить?
Так может она и не нужна бизнесу-то? В таком случае опять же непонятно, каким боком к этому всему относится договор и компания, если это по сути — ваша личная инициатива. Для сложных и интересных задач я лично использую pet-проекты, но тут уж каждый волен поступать как угодно
А это не моя задача, решать что нужно бизнесу. Меня интересует сама задача. Изначально же людям говоришь, чего и сколько надо. Потом, тобой начинают манипулировать, постепенно. Как минимум, это называется обман. Ну и как с договорами теперь?APXEOLOG
05.10.2018 13:38То что они потом этим пользуются у вас это возмущения не вызывает?
Они все понимают. Чего оно стоило. Можно хотя бы не хамить?Я все пытаюсь у вас выяснить, кто (или что) вынуждает вас это терпеть? У меня складывается ощущение, что вы слишком привязались к своему проекту и поэтому согласны на любые запросы начальства.
Изначально же людям говоришь, чего и сколько надо. Потом, тобой начинают манипулировать, постепенно. Как минимум, это называется обман. Ну и как с договорами теперь?
Зачем поддавались?
anatolymik
05.10.2018 13:53Я все пытаюсь у вас выяснить, кто (или что) вынуждает вас это терпеть?
Я уже отвечал. Меня интересует сложная задача.
У меня складывается ощущение, что вы слишком привязались к своему проекту и поэтому согласны на любые запросы начальства.
Это 4й сложный проект(мелочи считать не будем), который я выполняю. Начат он сравнительно недавно.
Зачем поддавались?
Где я обозначил что я поддался? Мне казалось, я явно указал, что изначально я говорил как есть. На что все дружно покивали. А потом за свое взялись. По-моему я написал, что имел место обман. Как вы это откомментируете я догадываюсь.
Aingis
05.10.2018 13:09Это не «буржуйский» подход. Это здоровое понимание своих интересов и их отстаивание. Если вы не защищаете свои интересы, то никто не будет. Если договорились работать определённое время, то вы не обязаны превышать это время. И никто не может вас заставить. Вы можете согласиться, потому что вам платят сверхурочные или потому что вы так нарабатываете опыт работы, но опять же это надо чётко понимать. Если вы перерабатываете просто потому что неудобно отказать, то на вас ездят и недоплачивают.
Опять же если вы говорите говорите про перспективу, то надо понимать в чём эта перспектива. Какая-нибудь квартальная премия в 40% от зарплаты может просто не стоить времени всех переработок за этот квартал, если сверхурочные не оплачивались. Вполне может оказаться, что вам просто недоплачивают, и на рынке вы стоите чуть ли не в два раза больше. Причём без переработок.
Нередко бывает, что компании просто не замечают быстрый рост сотрудников и не повышают соответственно зарплату, особенно, если там не занимаются ростом сотрудников, или занимаются формально (а ля мы внедрили ревью, а насколько оно адекватно и есть ли реальный фидбек — не волнует). Тогда помогает смена места работы.anatolymik
05.10.2018 13:23Вы знаете, работодатель может уволить любого. Если он того захочет. Это к слову о договорах. Как я уже утверждал, договоры не стоят ничего. Потому что их нарушают все стороны. Это практика.
PsyHaSTe
05.10.2018 14:38У нас тут была история, как человеку 6 окладов выплатили, чтобы он согласился «по собственному» написать.
При нормальном трудоустройстве и соблюдении договора увольнение нифига не тривиально.anatolymik
05.10.2018 14:513х на законных достаточно. Не понятно.
PsyHaSTe
05.10.2018 15:05Насколько я помню, это при нарушении договора и прочих вещах. Я плохо разбираюсь, но насколько я понимаю, в таком случае можно трудоустроиться обратно через суд.
PsyHaSTe
05.10.2018 12:31Если у вас вся компания держится на «эх ребятушки, затянем пояса» и «ну что ты, ради проекта без выходных не поработаешь», то это проблема компании, нет?
Главное, чтобы это было взаимно.
Я за большее взаимодействие между работой и сотрудником. В моем случае это выражается в том, что я не против поработать в выходные иногда, а мои коллеги не возражают, если я пару недель или даже месяц поболею, работая из дома без больничного. В итоге все довольны, проект движется, денюжки заказчики платят.
Kroid
04.10.2018 18:41А когда это коммерческих компаний обязали заниматься благотворительностью? Они же не ваши папа с мамой. У них есть задачи и они ищут людей, которые эти задачи решат, в обмен за вознаграждение. Вы им по какой-то причине не подходили. Через некоторое время стали подходить.
Ваша история звучит примерно так:
Много лет назад я хотел устроиться дальнобойщиком на своей машине. У меня была легковушка, и меня нигде не принимали. Но через пару лет я наконец пересел за руль камаза и после этого меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним.
Зачем вообще кого-то ненавидеть? Или же они не просто отказывали на собеседовании, но еще и насмехались над вами?) Тогда да, есть причина.anatolymik
04.10.2018 18:57-4А когда это коммерческих компаний обязали заниматься благотворительностью? Они же не ваши папа с мамой. У них есть задачи и они ищут людей, которые эти задачи решат, в обмен за вознаграждение. Вы им по какой-то причине не подходили. Через некоторое время стали подходить.
Никогда и что? Не мои папа с мамой и что? Вознаграждение? Вознаграждение дают за чрезмерное старание. Иначе это называется зарплата.
Много лет назад я хотел устроиться дальнобойщиком на своей машине. У меня была легковушка, и меня нигде не принимали. Но через пару лет я наконец пересел за руль камаза и после этого меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним.
Во-первых работа дальнобойщиком, не творческая деятельность. Во-вторых, вам не знакомо чувство когда вы тратили много сил, чтобы что-то поменять? Нет? Если делать все строго по упомянутому ранее договору, то ничего сделано не будет. Это еще называется Итальянская забастовка.
Зачем вообще кого-то ненавидеть? Или же они не просто отказывали на собеседовании, но еще и насмехались над вами?) Тогда да, есть причина.
Допустим насмехались, дальше что?
P.S. Вы просто бред несете. Сразу видно человека, который не умеет делать ничего сам, и даже не пытался. Вы случаем не владелец компании Х?
PsyHaSTe
04.10.2018 19:44В чем циничность подхода «Нам нужен человек с навыками X,Y,Z». Если вы не ответили на вопросы на собеседовании, то вы тоже начинаете копанию ненавидеть? Особенно если вы через год-два подтянули эти пробелы и вам предлагают офер?
anatolymik
05.10.2018 08:19Как я уже где-то ниже утверждал, не важно сколько ты знаешь и сколько ты умеешь. Важно как быстро ты учишься. И в целом как голова работает.
Ну а HR это понять не способны.
Видимо объяснить это человеку — трудно. И суть цинизма вы не поняли.PsyHaSTe
05.10.2018 12:32Как я уже где-то ниже утверждал, не важно сколько ты знаешь и сколько ты умеешь. Важно как быстро ты учишься. И в целом как голова работает.
А если у компании нет времени ждать, пока вы всему научитесь? Можно выучить одно, другое, третье… Но если несовпадение идет сразу по куче пунктов, то давать месяцы на вход человека в коллектив многовато, не находите?anatolymik
05.10.2018 13:02А у них никогда времени нет. Вы скорее всего с этим сталкивались.
Я неоднократно видел, когда HR ноют что не могут найти человека 2 года, когда за это время человека можно не плохо натаскать.
Вы все еще ждете ответа на ваш вопрос?staticlab
05.10.2018 13:09Ему эти 2 года придётся зарплату платить. А потом он научится и уйдёт в другую компанию.
anatolymik
05.10.2018 13:19А вы как хотели? Для начала работодателю надо вести себя нормально. А не говорить джунам что из-за них убытки.
Лично я не был против когда джуны подрастали, и решили уйти. Беги дорогой, с этой помойки.
Вам надо видимо привести в пример всю ситуацию. Но здесь я этого делать не буду.
PsyHaSTe
05.10.2018 15:04Ситуации бывают разные.
Не говоря о том, что джуны могут уходить в другую компанию не потому, что ваша плохая, а потому что им просто хочется другой стек/ЯП попробовать.
MINYSMOAL
05.10.2018 20:36Как вы предлагаете оценивать на собеседованиях, способен ли кандидат быстро обучаться и какое у него настроение будет завтра? Результат ведь нужен здесь и сейчас, по нему и оценивают. Я не hr если что (:
Ateist602
05.10.2018 08:13Как я Вас понимаю. Я 4 года назад менял работу будучи джуном+, пытался устроиться в одну серьезную (как мне тогда казалось) контору. Неплохо пройдя 2 собеса, попал на третий — к директору. На котором меня забрили с формулировкой: «Не считаем Вас перспективным, не видим в Вас желания развиваться».
После этого меня наняла другая компания, в которой за пару лет я докачался до тим лида, через еще пару лет попал под сокращение (проект закрылся). Когда я начал искать новую компанию, в числе прочих сходил на собесы в вышеобозначенную. Пообщался и с местным тим лидами, и с местным архитектором. И знаете что? Я не увидел в них ничего особенного. Технический уровень ребят был явно ниже моего, о процессах разработки представления не имеют, нам даже особо обсуждать было нечего.
Хотя быть может, здесь стоит говорить не о том, готова ли компания нанимать джунов, а о том, насколько руководители в состоянии оценить «перспективность» нового сотродника.PsyHaSTe
05.10.2018 12:33У меня такая история была с касперским. Немного покоробило тогда, но особых hard feelings сейчас уже нет.
Femistoklov
06.10.2018 11:03Зачем ненавидеть-то? Пожалеть надо. Те, кто в вас поверил, выиграли, те, кто не поверил — проиграли.
White_Scorpion
04.10.2018 14:45С чисто капиталистической PoV* — точка зрения понятна и логична (простите за тавтологию) — всё на откуп прибыли, а далее по Даннингу.
Но вот с социальной действительно хочется "взять за грудки и потрясти". Никогда на самом деле не встречался с компаниями явно пропагандирующими идеалистические утопии вида: только сеньоры, только хардкор… Казалось бы — любая утопия априори нежизнеспособна, ан нет, оказывается — встречаются.
*Point of View
cade
04.10.2018 14:50А можете меня, как не программиста просвятить, как отличить джуна/миддла/сеньора?
На примере python/c++?
И еще, как понять что ты джун/миддл/сеньор?anatolymik
04.10.2018 15:04Легко, даем задачу, которую человек точно не решит. И смотрим на ход мысли. Далее даем подсказку для решения. Если подхватит, либо талант, либо опытный. Но для этого надо быть самому сеньором.
cade
04.10.2018 15:08исходя из этого, это способность решать более тяжелые задачи!?
anatolymik
04.10.2018 15:09Как минимум, человек быстро учиться. Не важно сколько он умеет, не важно сколько он знает. Важно как быстро человек обучается.
White_Scorpion
04.10.2018 15:12+4Скажу за крайние позиции, а мидл — что-то посередине:
Джун — в самый первый день работы во время знакомства с фичей предлагает переписать фичу… А лучше весь проект сразу… Под Ангулар… Ну или React… А сервер с легаси базой просто вырубить. Оценка задач у них хромает в принципе. Часто в коде отсутствуют казалось бы простейшие проверки, прозванные "защитой от дурака" — в ВУЗах главное сдать лабу/курсовик, а не освободить лишний раз память.
Сениор, при постановке задачи может уточнить — нужна скорость или качество? Не боится говнокода, но старается его не писать и честно предупреждает, что "вот тут могло бы бы и побыстрее работать, но сроки поджимали". Утечек памяти в его коде обычно не бывает. Обычно оценивает задачи более точно. Грамотно их разбивает. Легче входит продукт: зная общии принципы построяния коммерческого ПО и проработав в N компаниях — можно увидеть общие блоки, даже в ПО разных сфер и предназначений. Умеет ЧИТАТЬ код.
Понятное дело — список не полный.
anatolymik
04.10.2018 15:16+3Практически, я пришел к тому, что во-первых они не слушают. Если из-за этого увольнять всех подряд, один останешься. Надо дать человеку возможность облажаться. Ну и самому быть на высоте. Т.к. идут за личностью. Личным примером показывать. А не вынуждать. Это трудно. И затратно. Но, иначе мы в них породим только отторжение. Так мы ничего не добьемся.
PsyHaSTe
04.10.2018 19:46«Облажаться» слишком дорого, чтобы позволять это сознательно. Когда случайно друпнул базу в гитлабе — да, бывает, это ценный опыт. Но специально дать человеку дропнуть её, зная, к чему это приведет, слишком дорогостоящее обучение.
anatolymik
05.10.2018 08:23На мой взгляд вы утверждаете даже не крайности.
У джуна есть лид, и именно лид отвечает за действия джуна. Не надо давать джуну красную кнопку. Пусть начинает с простого. У них на простых задачах то проблемы.
А на практике я много раз видел, когда лид говорил что это джун напартачил. Вместо того, чтобы разгребать. А ведь именно ты его взял. Зачем ты на него стрелы переводишь? Именно ты отвечаешь за его действия, и последствия.White_Scorpion
05.10.2018 14:25Отвечает конечно лид, но зачастую случается, что платит на самом деле — именно джун.
aamonster
04.10.2018 15:19+2«как понять что ты джун/миддл/сеньор?» — да просто проверяйте по списку навыков, требуемых для конкретной вакансии. Можете по итогам походить на собеседования. Если проходите на сеньорскую позицию, значит, вы — он самый и есть. «Практика — критерий истины».
BingoBongo
04.10.2018 15:42+4Сеньор один может написать практически весь код проекта без особых трудностей (или, по крайней мере, ту часть, что в зоне его квалификации, если проект очень большой). Мидл требует консультаций, т.к. периодически испытывает трудности, но многие задачи решает сам, говнокод пишет от случая к случаю. Джун имеет очень узкие рамки для творчества, самостоятельно может решать только простые задачи, требует постоянный контроль за своим кодом.
Brenwen
04.10.2018 17:31+2На правах шутки:
Мид — тот, кто может сделать проект в одиночку. Джун — не может, сеньор — не хочет.
farwayer
05.10.2018 02:50Junior — уровень кода: базовые алгоритмы, "набивка руки" на написание кода, решение не очень сложных задач по примерам.
Middle — уровень технологий: хорошее знание своего языка и стека, умение выполнять поставленные задачи с минимальным числом багов. Это уровень хорошего технического специалиста.
Senior — уровень решений: широкий кругозор, знание не только своего основного языка/стека, но и смежных (и, возможно, совсем далеких), представление о работе системы в целом, умение выбирать технологии, ставить задачи, задавать направление разработки. Это уровень решения проблем в широком смыслы слова. Уже не только код, но и бизнес.
Кто скажет, что сеньором можно стать за 3 года — тот дурак.
Crafter2012
05.10.2018 16:17Ко всему выше сказанному, добавлю:
1) Общепринятой метрики в индустрии нет, каждый трактует так, как хочет.
Что собственно видно из комментариев выше)
2) Градация по факту шире: интерн/джун/миддл/сеньор/тимлид/«гуру»
Применительно к python: интерн напишет «привет мир», гуру напишет питон.
3) Работа программиста декомпозируется на разные навыки и знания, в соответствии с обязанностями по роли специалиста.
Например,
«Простой» программист имеет такие знания и навыки:
- Знания из Computer Science/Информатики (которая зачастую сводится к алгоритмам, ну и немного математики)
- Планирование своего времени применительно к решению задач
- Навык написания кода на языке X
- Использование тулсета (IDE, консоль)
- Использование VCS(git, TFS, mercurrial)
Архитектор, в дополнение к основному стеку программистских обязанностей, должен уметь проектировать:
- Знать и уметь в шаблоны(применительно к ООП)
- Выбирать стек под проект(на уровне фреймворков и библиотек)
- Читать и писать UML (опционально ли?)
Тимлид, же в дополнение к основному стеку программистских обязанностей и стеку архитектора, еще и с людьми работает, тут еще одна ветка «талантов».
4) Каждый навык оценивается отдельно по шкале от интерна до гуру.
5) Конечная оценка программиста — средняя оценка по его знаниям и навыкам.
6) В реальной жизни роль Архитектора редко выделяют, и включают в градацию сеньора.
То есть реальная разница между джуном/мидлом и сеньором — это умение проектировать код.
Поэтому,
- Интерн — кто еще ничего не может.
- Джун — кто может, что-то реализовать хорошо под руководством тимлида. Потому что в проектирование еще не умеет.
- Мидл — кто может, что-то реализовать хорошо под присмотром тимлида. Потому что в проектирование только учиться.
- Сеньор — кто может и спроектировать и реализовать хорошо без внешней помощи, но либо не хочет, либо не может руководить младшими.
- Тимлид — кто может и спроектировать и реализовать хорошо без внешней помощи, и при этом присмотреть за младшими, чтобы они тоже сделали хорошо.
- Гуру — Гвидо Ван Россум, Андерс Хейлсберг и т.д.
Пысы все вышесказанное IMHO.MikailBag
07.10.2018 14:10интерн/джун/миддл/сеньор/тимлид/«гуру»
Мне кажется, что тимлид и гуру это две разные ветки развития :)
DistortNeo
04.10.2018 15:34Проблема чрезмерной квалификации сеньоров также имеет место быть. Дело в том, что множество навыков соискателя и множество навыков, нужных работодателю, никогда не совпадают полностью. И чем выше позиция, тем больше список требуемых навыков, и тем сложнее найти кандидата на позицию. Приходится либо учить джуна, либо смириться с завышенными зарплатными ожиданиями сеньора (платить за невостребованные навыки).
anatolymik
04.10.2018 16:13Невостребованные навыки, это гарантия того что человек стоящий. А значит и платить есть за что. Он способен решить любую задачу.
А вообще, говоря о нашей деятельности, платить много они должны не потому что навыки, а за то чтобы он не работал в другом месте. У конкурента. Нынче капитализм.
andyN
04.10.2018 16:55+8Это всё конечно красиво, человеколюбиво, авангардно и либерально. И неверно для очень большого ряда случаев. Я перестал нанимать джунов и всем советую. Потому что
1) они входят в курс дел и в процесс разработки очень долго, в разы больше миддлов и тем более синьоров
2) очень быстро уходят из компании в поисках лучшей доли, и часто даже не из-за зарплаты или невозможности повышения (тут как раз все ок), а потому что хотят поиграться с другими технологиями
3) большинство джунов — молодые и у них ветер в голове и низкий уровень ответственности
Я высказываю непопулярную точку зрения, потому что она частная и потому что здесь просто больше разрабов чем собственников бизнеса или ИТ директоров. Но поверьте, вся эта розовая теория про милых джунов рассыпается о реальность, когда Джун, которого вы растили полгода и потратили на него кучу ресурсов других опытных разрабов, вдруг решает, что Го прикольнее чем Питон и надо переходить на работу в контору где юзают
Nalivai
04.10.2018 17:22-1Если твой джун решил что надо переходить из твоей конторы, значит ты не смог его удержать, и это твоя вина. И неважно почему он так решил, ты не барин чтобы Юрьев день вводить.
Если у тебя текучка такая, что работу работать невозможно, то у тебя явно что-то не так с конторой. А если ты жалуешься на обычную текучку, то ты неправильно воспринимаешь реальность.dom1n1k
04.10.2018 17:56+5Он-то не барин. Но он как бы отвечает автору статьи, который вещает нам за низкий уровень социальной ответственности.
Сотрудник может уйти по миллиону причин — это его право.
Но точно также право другой стороны сказать — а нафига мне эти заботы? Зачем вкладываться несколько месяцев в людей, которые могут свинитить (и скорее всего свинтят) в любой момент? Первое время польза от джуна околонулевая, а то и даже отрицательная.Nalivai
04.10.2018 18:14-2Ну я о том и говорю, что если в твоей конторе нормальная ситуация, когда ты берешь джуна, он вырастает и сваливает, значит для разрабов у тебя в конторе условия говно, иначе они хотели бы остаться именно у тебя. А если у тебя условия говно, то это только твоя вина.
А насчет социальной ответственности, даже если не обращать на нее внимание (что само по себе плохо), то в любом случае джун выращенный у тебя, на твоих практиках и продуктах, принесет тебе больше пользы чем джун выращенный кем-то другим, а стоить будет, статистически, меньше.dom1n1k
04.10.2018 18:30+4Человек 20-и с небольшим лет свалит независимо от условий, просто потому что он ищет себя. Он хочет новых мест, задач, языков, знакомств, городов, стран и тд и тп.
Даже при з/п выше средней по городу, бесплатных печеньках и ежедневном поцелуе в попу всегда найдется условный заокеанский гугл, который поманит яркими огнями и ничего с этим не поделать. Сейчас популярны даже поверья типа «засиделся на одном месте 3 года = прекратил развитие и оброс мхом».
Хорошие условия лишь немного оттянут момент расставания.Nalivai
04.10.2018 19:02А может и не свалит, если у вас реально хорошо. Вы всех мажете одной кистью, а люди-то разные, и если у вас единственная причина ухода джунов это заокеанский гугл, то у вас, в общем-то все хорошо, и потерю одного джуна из десяти вполне можно пережить. Или если у вас уходит половина, в общем-то, ничего страшного, не так уж и много вы на этом потеряли, а получили гораздо больше. А вот если у вас уходят все джуны, то это говорит только об одном — ваша контора говно, и работать у вас плохо.
andyN
05.10.2018 11:37Вы очень упорно давите на вами придуманный тезис, что "контора — говно". Поверьте, из говноконтор уходят не только джуны. Контора вполне хорошая. Но слишком многие джуны уходят действительно просто потому что им интересно поиграться в другие технологии. И здесь ничего невозможно сделать. Найдите мне способ понять, останется ли конкретный джун в компании в следующие три года, и я первый побегу их нанимать. А пока что — простите, нет.
Вообще вся эта история попахивает позитивной дискриминацией, когда под видом борьбы за права меньшинств, этих самых меньшинств пропихивают куда ни попадя, даже если они там неэффективны.White_Scorpion
05.10.2018 14:31+1По моему вы из позитивной дискриминации — прыгаете в негативную.
Джуны неэффективны — это факт. Но это не причина, чтобы их не нанимать. Это досадный недостаток, который проходит с опытом и только от вас зависит — как быстро этот опыт прийдёт.
BigFlask
06.10.2018 01:38Но слишком многие джуны уходят действительно просто потому что им интересно поиграться в другие технологии.
Значит, им недоплачивают. Если в конторе используется более-менее востребованный на рынке стек — джуны не станут уходить чтобы поиграться с новыми технологиями, им эти технологии нафиг не нужны, они не хотят их изучать, им нужна зарплата и перспективы ее роста. Джун уйдет поиграться в новые технологии только если его позовут поиграться в новые технологии за не меньшие деньги. Но если джуну за малознакомые ему технологии предлагают не меньше, чем в текущей конторе за знакомые — то текущая контора говно и не доплачивает.
nick_gabpe
04.10.2018 18:53Всё зависит от конкретного человека. Кому-то интересно пробовать новые технологии, кому-то интереснее развиваться в одной.
1 Да, но за пару лет талантливый Джун станет миддлом и будет так же быстро вникать в курс дел.
2 Зависит от человека. Я на первой своей работе работал 5 лет. И уйти пришлось из-за слабого роста зарплаты. Я был бы рад там работать и дальше, если бы там было нормальное повышение зарплаты.
3 опять же сильно зависит от человека. У кого-то всё серьёзно в 25 лет, а у кого-то пустая голова в 40andyN
05.10.2018 11:42В том-то и дело, что всё это — вопрос вероятностей. Зрелые разработчики более предсказуемые. Зачем нанимать что-то, что с более высокой долей вероятности создаст тебе проблемы? Любой руководитель, который так делает систематически, просто убивает свой бизнес и лишает всех сотрудников работы
Femistoklov
06.10.2018 11:35- Возможно, это дела так обстоят и процесс такой. Сеньоры просто имеют навык разбираться даже в лютом говнокоде и нелогичном процессе. Но виноваты джуны, да, что в реальности всё оказалось не так хорошо и понятно, как в книжках.
- Обычно никто даже не интересуется, чем человек хотел бы заниматься. Но тут проблема глубже, конечно. В вашем офисе могут сидеть люди, которые готовы не спать ночами, чтобы сделать крутой интерфейс на современном фрэймворке, что вывело бы проект на новый уровень, но у компании в приоритете интеграция с десятым по счёту API.
- А ещё энергия, жажда знаний, бескомпромиссность к плохим решениям и пока ещё не прагматичный подход к отношениям с работодателем.
basilbasilbasil
04.10.2018 17:11+1Если вы не нанимаете джунов, то не заслуживаете сеньоров
А можно я без дебильных подсказок сам решу, заслуживаю я сеньоров или нет?
Иногда, когда компании говорят, что не нанимают младших программистов, мне хочется схватить их за грудки и закричать: а откуда, по-вашему, берутся старшие программисты?!
Непонятно, почему это должно быть моей проблемой?
Откуда они берутся? Хм, «Ржевский, молчать!»
Если ваша компания обгоняет конкурентов по данному вопросу — то есть знает, как нанимать, обучать и удерживать младших программистов — то вы сами уже ощущаете все те преимущества, которые я лишь поверхностно описал в данной статье. У вас ниже текучка, выше разнообразие специалистов и меньше оверхеда, чем у конкурентов. В вашем софте меньше багов и больше радости. Есть, конечно, и другие факторы.
Ниже текучка? То есть джуны долго никуда не уходят??
Выше разнообразие специалистов? А если мне не нужно такое разнообразие?
Меньше оверхеда? То есть обучение джуна снижает оверхерд? В каком месте?
White_Scorpion
05.10.2018 14:41Непонятно, почему это должно быть моей проблемой?
Это станет вашей проблемой тогда, когда вам внезапно надо закрыть важное направление, а необходимого сениора — под рукой не окажется. И я сейчас не про идиотизмы вроде "и что вы предлагаете закрывать дыру джуном?" — ни в коем случае… Просто подумай вы в какой-то момент сильно заранее иначе, чем думаете сейчас — у вас были бы собственные подготовленные мидлы, для одного из которых затыкание вашей критической дыры позволило бы вырасти над собой, а вам — не метаться судорожно по рынку труда пытаясь найти того, кто впряжётся за уже ваши проблемы, негодуя, что "сениоры зажрались".
Жаль, что такое осмысление сценариев обычно приходит постфактум.
anatolymik
06.10.2018 12:47А можно я без дебильных подсказок сам решу, заслуживаю я сеньоров или нет?
Никто читать не заставлял.
А то как вы считаете, кого вы заслуживаете, практически может отличатся. Решать будет практика. А не вы.
unabl4
04.10.2018 18:09+4Очень похоже, что автор статьи из тех, у кого diversity головного мозга, пока ещё в начальной стадии.
Работодатель сам вправе решать, кого и какой квалификации ему нанимать. Все остальные доводы — это разговоры в пользу бедных, ненужное нытье и всякие левые домыслы.Nalivai
04.10.2018 18:17+1Конечно вправе, а остальные вправе ему показывать, когда его практики наёма полное говно.
Вот такие практики, например, говно, неважно насколько ты считаешь себя холодным капиталистом нанимающим лучших из лучших, не оглядываясь на собственный biasBingoBongo
04.10.2018 18:32Может расскажите нам о своей личной практике найма в одной из ИТ-шных организаций, которая принадлежит вам? Ааа… вы еще не владелец и сами работаете на дядю? А знаете почему? Потому что как бизнесмен вы что? Правильно… :)
Nalivai
04.10.2018 18:57Обязательно есть фекалии чтобы понять что они невкусные? А чтобы человеку поедающему фекалии сказать что он делает что-то неправильное сколько фекалий самому обязательно съесть?
И не надо нам тут вот этой вот уже-даже-не-очень-пассивной агрессии, вы вот как собеседник сами знаете что, я же вам на это не указываю.
balexa
05.10.2018 11:40Вот такие практики, например, говно
У вас какая-то зацикленность на фекальной теме. С чего это вы решили, что ваша точка зрения говном не является?anatolymik
06.10.2018 12:52У вас какая-то зацикленность на фекальной теме.
На говне обычно всем понятно. Не надо человеку на это указывать. Может наболело. Пусть высказывает негатив. Он никого не оскорблял.
P.S. А еще я шутки про говно очень люблю. И сам так «шутю». Подымает настроение.
dididididi
05.10.2018 10:17КАждый человек вправе решать, что ему делать, но судя по всему 80% россиян после сложных раздумий решили жить бедно. Автор просто сообщает работодателям, что часть решений неправильны и ведут не к тому результату, который они ожидают.
biseptol
04.10.2018 18:24+1А меня вот удивляют эти лычки, все с ними вдруг забегали в последние года два-три.
Как вы их отличаете? Например, в команде два человека: у одного два года на С++, у другого — 10, кто из них «сеньор»? Или команда из «сеньоров», которые 10 лет пишут интерфейсы в каком-нибудь embedded платформе, используя jquery и php 5, к ним приходит человек с 2 годами в современном фронтенде — он кто?
PsyHaSTe
04.10.2018 20:06У нас в компании нет джунов, да и миддлов не особо, в основном синиоры. И это лучшее место из всех, где я работал. Всегда есть с кем что обсудить. Сениор не значит, что он всё знает, я очень часто коллегам рассказываю какие-нибудь байки про особенности выравнивания памяти и последствия для производительности (для фронтов это очень неожиданная информация). В ответ я получаю интересные рассказы про докер, настройку CI, всякие фреймворки и т.п. То есть я и обучаю, и обучаюсь, хотя мы с людьми примерно на одном уровне, просто потому, что у нас разный уровень компетентности в разных сферах.
А теперь по пунктам:
Посыл состоит в том, что младшие программисты представляют собой риск, некий шаг, на который компания идёт либо из чувства общественного долга, либо из-за нехватки бюджета. Получается, что другие компании, должно быть, могут позволить себе корпоративную благотворительность и второсортные результаты, но уж точно не мы.
А какие могут быть причины нанимать низкоквалифицированных сотрудников? В отличие от «Работы руками», где человек гайку может тесать без высшего образования, весь код взаимодействует друг с другом, равно как и закон брукса никто не отменял.
То, как вы нанимаете и обращаетесь с младшими программистами — важный косвенный показатель здоровья вашей организации, вашей линейки продуктов и вашей внутренней культуры. Сеньоры обращают на это внимание. И если одно это не звучит достаточно убедительно, то найм взвешенного количества младших программистов также даёт финансовые преимущества.
То есть то, как вы обращаетесь с мидлами и синиорами совсем не является показателем, верно?
Если вы отказываете младшим программистам потому, что они «создают проблемы», то вы также машинально посылаете сотрудникам важное сообщение насчёт корпоративной культуры: ошибки недопустимы. Вы создаёте образ компании, которая увольняет кого-нибудь всякий раз, когда ложится сервер.
Нет, это значит, что мы хотим сделать упор на качество. Массовые расстрелы автор выдумал на ровном месте. Прием «Strawman».
А что насчёт ошибок, которые пробивают все установленные подстраховки? Думайте о них как о ценных возможностях укрепить вашу защиту.
Мир это война, свобода это рабство, ошибки это возможности. Нет, ошибки это ошибки. Напоминает старую цитату Programming Defeatism: No technique will remove all bugs, so let's go with what worked in the 70s.
Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $28 в час за написание этого кода — или вы можете заплатить $59 в час написание того же кода. Так или иначе, результат будет мало отличаться. Если вы нанимаете только сеньоров, то вы платите втридорога за существенный объём простой работы.
- Во-первых это не будет тот же код (скорее всего). А с этим кодом будут взаимодействовать куча других частей программы
- Во-вторых сколько времени уйдет на написание этого кода? Как не раз было сказано в блоге PVS studio, в коде часто не видно, сколько на самом времени потрачено было времени, чтобы написать этот кусок кода. И час работы сениора всё еще дешевле трех часов работы джуна, которые еще переписывать придется
Кроме того, кодовая база значительно разнится между приложениями, и знакомство с ней — ключевой фактор в продуктивности. В большинсте случаев младший программист, проработавший в команде полгода, будет эффективней справляться с задачами, чем только что нанятый старший программист — просто из-за степени знакомства с логикой проекта.
А что ж не сравнить джуна, который 5 лет на проекте работал, с только что пришедшим миддлом? Или наоборот, сениора который на проекте полгода отработал и только что пришедшего джуна?
Ввиду этого пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости. Если ваша цель — максимальная продуктивность с минимальными затратами, то такая пара джун+сеньор должна стать фундаментальной молекулой вашей организации.
Выше уже сказали, очередные цифры с потолка.
Стоит отметить ещё один, неизмеримый фактор: тенденцию старших программистов к постоянным спорам на темы, которые в конечном итоге ничтожны — про алгоритмы, микрооптимизации и стиль кода. Если компания нанимает только сеньоров и не имеет при этом жёсткого процесса принятия решений, то сотни рабочих часов могут уйти на подобные споры. Младшие разработчики обычно лишены такой проблемы.
Мы про сениоров говорим или про чуваков с излишним самомнением? Позиция «джуны боятся даже своей тени, чтобы не вылететь из компании, поэтому согласны на все, давайте это используем». Ну, такое себе. У нас на проектах всегда разумное общение по любым вопросам, потому что есть желание сделать проект, а не продавить табы или пробелы. Что тут сказать, на любом проекте проводится один раз жаркий спор, настраивается gitattributes/editorconfig, куда заносятся автоматические правила форматирования, и больше проблем с этим не возникает. Споров другого характера на практике я не припомню.
Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна».
Года 4 назад был на корпоративе Ланита, где люди получали медали за выслугу — 20, 25 лет… И тоже начинали интернами… У меня от этого скорее страх был, нежели трепет. Люди просто были полностью оторваны от того, как делаются процессы в других компаниях. Выдавать это за плюс по меньшей мере странно.
У младших программистов есть ряд уникальных черт, которые их более опытные коллеги обычно утратили. Одна из них — незамутнённый оптимизм. Другая — готовность идти за лидером.
Оптимизм — это когда «Давайте все нафиг перепишем… Да не боись, не взорвется!»? В команде не оптимизм должен быть, а реализм. Не надо путать со здоровым духом и хорошим настроением в компании, это ортогональные вещи. Команда веселых реалистов максимально продуктивна, и не косячит в сроках оценки фич.
Тут возникает логичный вопрос «откуда эти сениоры возникнут?». К сожалению, у меня нет ответа на этот вопрос. Я в своё время устроился будучи студентом, когда я пообещал, что я в течение ближайших лет никуда не уйду. Своё обещание я сдержал, и получился достаточно выгодный обмен, меня по цене сотрудника Макдональдса, а мне за это опыт. Лично я не вижу ничего плохого в том, чтобы начинать с самого низа. Учитывая, сколько сейчас крутых открытых проектов на гитхабе можно вкатиться сразу мидлом в разработку, и избежать упомянутых проблем.
FYR
04.10.2018 20:49Да спорная на самом деле статья. Все сильно зависит от того как построен бизнес, что за софт пишется, какова цена ошибки и вообще много всего. Например если вы не можете позволить себе CI (окружение изолированно) или у вас высокие требования по перфомансу — то джуны это только поддержка и багфикс. А если на фронте верстку крутить то там можно и джунами обойтись.
Опять таки бывают всякие галеры. где лучше взять самоуверенных джунов и «прокачивать их» и нескольких сеньеров.
Хотя конечно лучше вырастить сеньера из джуна. но это на самом деле признак очень хорошей компании когда. и стек технологий очень серьезный и обучение построенно хорошо и процесс ревью и тестирования (джуну не получится сильно накосячить)PsyHaSTe
04.10.2018 22:09Я не верю, что в одной компании (даже самой крутой) можно вырасти до джуна. Просто потому, что больше 3 лет на одном месте проработать тяжело. Я больше верю в джун->год-другой работы->недовольство текущими задачами/уровнем зп->офер на мидла->смешной контрофер->трудоустройство миддлом->год-другой работы->недовольство текущими задачами/уровнем зп->офер на синиора->смешной контрофер->трудоустройство синиором.
FYR
04.10.2018 22:56вы сейчас говорите про так себе джуна в компании с одним однотипным продуктом и использующей типовой стек.
Достаточно крупная компания с несколькими сотнями разработчиков, ссобственным продуктом полного цикла. и типовая карьера: команда састейн, поддержка старой версии на проде, прокачка скилов до толкового джуна, замечают в отделе постарше внутренний перевод на уровень недомидла. там жесткий энтерпрайз и куча задач которые сеньерам не интересны но отличают настоящий продукт: разные хвосты к мониторингу, ci. Всякие написать unit файл сервиса, обвернуть утилиты тестирования в rpm пакеты. вообщем те задачи когда знаю что писать и учусь как писать. ну и плюс рост компании и рост отделов. да при этом стек хоть и широк, но в одной сфере и специфичен.
Хотя да определенные личные характеристики тоже важны.
Собственно я в текушей компании 11 лет и как раз прошел путь от джуна до руководителя группы и системного архитектора. есть еще человек 40 таких дедушек. Конечно все на позициях сеньеров, лидов и архитекторов давно.PsyHaSTe
04.10.2018 23:21+1Я работал в компаниях до 7к человек, и везде наблюдал одну и ту же картину. Может я не там был, не спорю, но у меня сложилось такое мнение.
Например, на моей первой работе я работал джуном на полставки за 30 тысяч, совмещая с учебой, а вышел на полную ставку… 40 тысяч… После моего вопроса «Разве 30*2 это 40?» мне было сказано, что таковы у них вилки для джунов, а на мидла я не тяну.
Через неделю я принес офер сильно выше, чем «30*2», и тогда уже пошел разговор про нормальную ЗП, но я все же предпочел сменить рабочее место.
aamonster
05.10.2018 11:52Э… Я своими глазами видел джунов, выраставших до синьора. Не в каких-то там супер-крутых компаниях. Когда нанятый студент со временем вырастал до главы отдела.
boblenin
05.10.2018 06:26Ну в целом подход netflix понятен. Они считают, что их бренд достаточно привлекателен для того чтобы собирать сливки. Но сливки имеют тенденцию заканчиваться, а кроме того отсутствие градации скиллов — отсутствие возможности карьерно расти тем же самым сливкам. А значит те, кого привлекут в качестве сеньоров не будут оставаться в компании больше чем несколько лет и за повышением пойдут в другую компанию.
Это ни плохо и ни хорошо — это просто такая стратегия найма. Со своими плюсами и минусами.
Karpion
05.10.2018 07:03Почему-то никто не сказал, что есть «опыт работы вообще», а есть «опыт работы над данным проектом данной компании». И пока человек остаётся на одном проекте внутри одной компании — эти вещи взаимозаменяемы; но при смене работы — второй опыт обесценивается, и за него на новом месте платить не будут.
Так вот, набрав джуниоров — можно надеяться, что сложится команда людей, которые имеют опыт второго типа. Платить им можно по уровню опыта первого типа, ну или чуть больше; зато качество работы будет выше, чем у нанятых со стороны программистов на ту же зарплату.
(Надеюсь — я внятно выразился.)
SoEasy
05.10.2018 08:28На моем опыте джуны в команде бывают просто необходимы. Бывало много задач, которые для опытных программистов были неинтересными и рутинными. Для джуновже это был отличный опыт, и они с удовольствиям брались за работу. В общем всегда приятно иметь человека, на которого можно спихнуть левую задачу)
Silverado
05.10.2018 09:09Предлагаю развить тему вглубь, выпустив цикл статей «Растим сеньора из ничего» на темы от «Откуда берутся джуны» до «Откуда берутся дети», дорожка от этой статьи вполне непрерывная видится.
SergioPredatore
05.10.2018 15:21+1Один из недооценённых навыков программиста — способность писать код, который средний или посредственный программист сможет легко прочесть, изменить и расширить.
И такой код как раз таки пишу сеньёры. А вот джуны как раз умеют написать так, что без поллитры не разберёшься. Я имею ввиду не заумный код, заумный код обычно пишут мидлы, а код, логика которого живёт только в голове автора. Умение писать просто и понятно — тот ещё сеньёрский навык.
roscomtheend
05.10.2018 16:13Ох уж эти лозунги… Не во всех конторах 100500 программистов и не везде есть возможность безболезненно нанять десяток-дуругой джунов для тестов.
Krat0S
А я легко нанимаю джунов :)
В мобильной разработке сложилась такая ситуация, что сеньоры стоят очень дорого, а мидлов не существует.
Ну то есть они существуют только в своих глазах, а на практике, это люди, которые выучили пару паттернов (MVP\MVC), три библиотеки (rx, retrofit, moxy) и считающие себя могучими программерами, равными богам.
Забавно выглядит, когда человек, называющий себя Middle Android Developer, не может ответить на простой вопрос — «Когда лучше использовать Array List, а когда Linked List?».
Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?
dsapsan
Легко, можно писать на Unity и C#. У нас успешная команда, которая так делает уже более пяти лет.
Хотя, это скорее шутка, конечно эти знания нужны.
Krat0S
Да вообще без вопросов :)
Мы со своим уставом в чужой монастырь не ходим.
Как только появится методика успешной интеграции Android-приложений написанных не на Java\Kotlin с VMWare AirWatch, так мы сразу и начнём рассматривать такие варианты.
Neikist
Ы, у нас заказчик требовал встроить AirWatch в приложение для андроид на 1С. В итоге часть потребностей заказчика решили через написание второго приложения рядом на java и сделали обмен между этим приложением и приложением на 1с)
Krat0S
Не ТОиР случаем?)
Neikist
Эмм… Не хочу чтобы меня с этим проектом связывали, так что «нет»))
Arranticus
А что это меняет? Когда лучше использовать List, а когда LinkedList?
MikailBag
List лучше использовать примерно всегда.
PsyHaSTe
Плохой ответ, потому что не показывает, действительно ли вы знаете разницу, или просто никогда не задумывались.
MikailBag
Я представляю разницу довольно хорошо. Я загимаюсь спортивным программированием, где концетрация алгоритмов и структур данных вроде как сильно выше. Но кейсов для связного списка ни разу не видел. Следует помнить, что этими 2 выбор не ограничен. Как уже писали где-то выше, прежде чем поработать с серединой ее нужно найти. Исходя их этого я вангую, что на практике полезны более хитрые вещи типа корневой или декартова дерева.
PsyHaSTe
А вот это хороший ответ, хоть вы прямо ответ на вопрос и не озвучиваете :)
KvanTTT
Аналогично. Думал что может я что-то упускаю, но оказывается мое мнение не единственное. Хотя может просто задач подходящих не было.
Denis631
Если у тебя два листа/стека с использованием LinkedList, то ты можешь из замерджить в O(1), вместо того, чтобы создавать новый массив и копировать все данные туда O(n)
Ну и конечно, когда хочешь удалить элемент в O(1) имея handle/pointer. Например с помощью HashMap и LinkedList можно написать LRU Cache
zagayevskiy
А можно использовать LinkedHashMap и не писать велосипедов. Это О(1) для связного списка разбивается об реальные данные.
Denis631
Ну так LinkedHashMap уже использует LinkedList under the hood. Я не говорю писать костыли, я говорю где это может быть полезно. Хорошо что java имеет такие классы в стандартной библиотеке. Вопрос LinkedList или Array/Vector не ограничивается языком.
Например С++ не имеет LinkedHashMap.
Костыли есть костыли, а конценты есть концепты.
Ты на интервью также скажешь?
skyramp
а чем boost::multi_index не устраивает? конечно boost это не STL, но для плюсов уже практически стандартная библиотека если чистого STL вдруг начинает нехватать
Denis631
Я все склоняюсь к тому, что слепое удтверждение, что Vector >> LinkedList всегда, это не правильно. Use-Case'ы могут быть.
Для конкретного выбора нужен benchmark.
Опять же, для не High Performance Systems ArrayList сгодиться всегда.
mayorovp
Нет, LinkedHashMap не использует LinkedList. Там внутри особая реализация. Просто потому что LinkedList в том виде в котором представлен в стандартной библиотеке Java совершенно бесполезен.
MacIn
Почему? Не пишу на Java, просто интересно.
mayorovp
Потому что из LinkedList нельзя удалить произвольный элемент за O(1). А если так — зачем он такой нужен?
asm0dey
Парсинг и push/pop в дерево в целях быстрого анализа.
Antervis
в подавляющем большинстве случаев связные списки даже на «своих» задачах оказываются медленнее массивов из-за лишних аллокаций/деаллокаций и принципов работы кеша.
musicriffstudio
С точки зрения реального применения в реальных приложениях никакой разницы между Array List и Linked List нет.
vics001
Это отличное утверждение и действительно часто так и бывает, с этого момента интервью перестает томным… И вам предстоит показать и доказать, почему же разные имплементации имеют теоретически разное время выполнения, а на практике это оказывается не так заметно.
musicriffstudio
Нет, интервью ж это обоюдный процесс.
Мой опыт в жаве около 15 лет, я делал приложения ещё для J2ME, в котором на кучу выделяется 64кб памяти, если вы понимаете что это такое.
Конечно я сделаю выводы и буду общаться с другими. Хотя всякое бывает, по ситуации.
vics001
Я же и не спорю, обоюдный процесс. У нас вопросы — у вас ответы, будет интересно пообщаться :-)
musicriffstudio
вряд ли.
aikixd
Что, извините, за бред? Оба списка имеют конкретные сценарии применения и разница в скорости и нагрузке на память (особенно в присутсвии сборщика) могут различаться на порядок. Это не учитывая что у обоих разные интерфейсы.
s-kozlov
Если в ваших списках бывает только 3.5 записи, то да, никакой разницы нет )))
dididididi
Просто всегда употребляй ArrayList и не думай)))
Krat0S
Судя по всему, комментатор чуть выше так и делает :)
Deosis
Только ситхи возводят все в абсолют.
Если профилирование покажет, что замена ArrayList на LinkedList дает выигрыш в производительности, то можно и заменить.
Но ситуации, когда применение LinkedList оправдано, крайне редки.
Krat0S
О том и речь, чтобы сделать выбор в пользу какого-то из листов, да даже чтобы понимать необходимость этого выбора, нужно осознавать наличие и различия вариантов.
Neikist
А вот интересно, насколько много людей которые на java пишут не видят между ними разницы? Я хоть не джавист, но по идее даже по названию предположить можно что LinkedList это связный список, а ArrayList динамический массив, что за собой влечет разную асимптотику на одни и те же операции.
musicriffstudio
в реальности разница между ними это сотые доли процента влияния на конечный результат. В абсолютном большинстве случаев.
Neikist
Да. Но эти случаи есть это раз, а два — лично я, например когда пишу на 1с, предпочитаю выбирать то что больше подходит (что конечно не отменяет последующего профилирования), если сценарии использования объекта заранее известны и выбор структуры можно сделать за несколько секунд. В итоге самому же приятнее от написанного кода.
musicriffstudio
если вы занимаетесь преждевременной оптимизацией вы тратите (воруете, скорей, на своё личное хобби) деньги работодателя.
Neikist
Серьезно? Секунды выбора между двумя структурами это трата времени 90% которого уходит на разные согласования и выяснения бизнес-требований?
musicriffstudio
если выбор занимает секунды то это не выбор, это «наитие».
Neikist
Ну вообще да, я скорее про это и говорю. Во первых по наитию примерно выбирать структуру данных + во вторых не пугаться почему вдруг кусок кода стал тормозить и знать на что ее можно поменять.
А вообще я вопрос то изначальный больше задал по причине того что неясно: ответить на вопрос люди не могут из за того что внутрях лежит то что названию не соответствует, или же просто не могут в принципе ответить? Во втором варианте это выглядит странно, уж если 1сник без образования программиста разницу между этими структурами знает…
musicriffstudio
такие вопросы это признак низкой квалификации. Нет ориентированности на результат.
dimm_ddr
Krat0S
В описываемом случае, это как раз выбор.
Я полагаю, что разработчик знает, зачем создаёт список.
И, в большинстве случаев, за пару секунд может сказать, будет ли он постоянно вставлять элементы в произвольное место, или дописывать в конец. Будет ли использоваться обход списка, или нужен точечный доступ к произвольным элементам.
musicriffstudio
в большинстве случаев это несущественно для реальных приложений.
Krat0S
А вот это Вы зря.
Чуть ниже подходящий ответ.
musicriffstudio
описание единственного случая и является подтверждением вышесказанного.
ilitaexperta
Krat0S
Смысл именно в этом)
Объяснить в чем разница.
Nalivai
Пока у тебя не миллион этих листов, по миллиону операций с каждым в секунду.
musicriffstudio
это называется «преждевременная оптимизация». Явный признак недостатка опыта.
Nalivai
Это называется «отсутствие понимания задачи» и отличать это от преждевременной оптимизации довольно важно. Считать любую оптимизацию «преджевременной» — явный признак недостатка опыта.
musicriffstudio
это не «любая» оптимизация, это оптимизация вымышленных миллионов листов на вымышленных миллионах операций в секунду.
Nalivai
Так у нас тут все случаи вымышленные, мы же о чистой теории говорим.
А на практике я не раз и не два сталкивался с ситуацией когда система спроектирована не была, потому что «время потраченное на проектирование это время не потраченное на написание кода, а нам платят за код», и в итоге, внезапно, работала на тестовом наборе данных, и висла подумать на десяток секунд в реальном мире. И переписать это все стоило больше чем написать с нуля.
Neikist
Всего десяток секунд? Я видел случаи когда система на десятки минут зависала, а после переписывания буквально пары десятков строк работала за доли секунды над теми же задачами.
Nalivai
Вот хорошо когда можно переписать что-то одно и все хорошо. А когда ключевой момент системы построен по принципу «вроде не виснет при передаче hello world, а значит и многокилобайтные файлы схавает», это все только выкинуть, вместе с тем человеком который решил время на предварительную оптимизацию не тратить, а, условно, передавать каждую букву отдельным https пакетом (не, ну а чо, работает же).
JekaMas
Аж передернуло!
Но история как из жизни. Сколько раз видел «давай запросим из БД все товары продавца и после в коде отфильтруем клевыми map-filter-reduce».
ainoneko
Я сам когда-то один раз видел (приходилось дорабатывать) кусок кода на PHP, который сначала делал «SELECT * FROM table», потом в цикле всё читал — чтобы посчитать количество записей.
musicriffstudio
любой из присутствующих может легко убедиться на практике. Нужно просто открыть код над которым он работал сегодня и посмотреть есть ли там миллионы списков.
их нет.
а вот массивы на сотню элементов есть.
и ничего с этим не поделать.
Nalivai
А это у вас откуда такая статистика замечательная взялась?
Вот я открыл код, а там есть массивчик, который, в нормальное время, состоит из любого количества элементов от одного до пары миллионов. И поделать с этим что-то все-таки надо.
musicriffstudio
ну раз он у вас есть то вы можете проверить насколько замена одного стипа списка на другой повлияет общую производительность.
Или этот кусок написан давно и трогать его нельзя? Да и элементов там в реальности раз сто меньше? И сделан он второпях и его пора выкинуть заменив чем-то более подходящим?
Вот так всегда и бывает.
Nalivai
Если вы думаете что можно так прям спокойно менять одни контейнеры на другие везде где захочется, то вы серьезно недооцениваете связность среднего кода.
Я серьезно не понимаю, с чего вы решили что в мире не бывает больших контейнеров, или что весь код в мире похож на ваш.
musicriffstudio
ясно.
boblenin
Открыл проектик. Там сразу же рядом. Stack и Dictionary, на подходе Queue и все для того чтобы избежать решения в лоб, которое дает 2Gb съедаемой памяти на транзакцию, против 2Mb на решении, с использованием всех этих структур.
musicriffstudio
Насколько я понимаю, вы, как и предыдущий оратор, не можете изменить «свой» код и проверить как смена одного типа списка на другой влияет на конечный результат.
Реальная работа отличается от учебных материалов. Приоритеты разные, многие вещи оказываются несущественными, другие же наоборот.
Это приходит с опытом.
JekaMas
Как я понимаю, умение именовать коммиты и не фигачить в мастер тоже приходит, но попозже? https://github.com/surikov/riffshare/commits/master
Как я понимаю, вы работали всегда в небольших проектах. И тут у вас опыт, бесспорно есть. Однако не стоит говорить снисходительно о других людях, особенно, когда собственное резюме и код "не для гугла — у меня свой проект".
musicriffstudio
прям как история с Т.Линусом и феминистками. Я просил подтверждение значительно влияния выбора между разными типами списков в реальных проектах, а мне про снисходительность и невежливость.
Мне ближе когда невежливые и грубые работники выпускают качественные полезные продукты укладываясь в срок и смету.
Но тут я не настаиваю.
JekaMas
Ну давай рассмотрим ваши продукты и решим, есть ли у вас право быть экспертом про «качественные продукты».
Я посмотрел. Все продукты это «пишу сам для себя, но в github». Коммиты test-test-63-catalog-catalog. И так во всех проектах. Комиты не атомарны. Магические константы. Прикольная сложность функций:
```
if (slides) {
if (slides.length > 0) {
envelope.audioBufferSourceNode.playbackRate.setValueAtTime(playbackRate, when);
for (var i = 0; i < slides.length; i++) {
var newPlaybackRate = 1.0 * Math.pow(2, (100.0 * slides[i].pitch — baseDetune) / 1200.0);
var newWhen = when + slides[i].when;
envelope.audioBufferSourceNode.playbackRate.linearRampToValueAtTime(newPlaybackRate, newWhen);
}
}
}
```
На мой взгляд, у вас очень «местничковый» опыт. И мало, либо нет вовсе опыта работы в команде. Что для программиста критично. Можно, конечно, говорить о том, «зато у меня свой продукт и полный контроль!» Да, с чем вас и поздравляю.
Но это не мастерство программиста — это принятия себя в качестве «хочу тихо кодить и чтобы никто не мешал». То же путь.
Но тогда уж не судите других. Поверьте, тут, на Хабре, очень много людей, собеседование с которыми вы бы не выдержали, как программист или руководитель проекта.
musicriffstudio
Я просил подтверждение значительно влияния выбора между разными типами списков в реальных проектах.
Остальное оффтоп.
JekaMas
Мои реальные проекты имеют отношение к распределенным базам данных. Поверьте, у меня всякие структуры данных и выбор их критичен. Нам приходится выбирать, в частности, между тем, какой именно вид Bloom filter нам подойдет лучше по API, ассимпротике на разных объемах данных.
Но все же. Вы тут судите, как эксперт. Позвольте уж и другим спецам высказаться, но уже насчет вашего опыта, кода и, соответственно, права судить и весомости вашего суждения.
Что код приведен выше ваш вы не отрицаете. Значит народ сможет посмотреть и сложить мнение.
musicriffstudio
Зачем это всё? Фильтры, гитхаб, распределённые базы, вера? Вот изначальное утверждение
Здесь нет оскорблений, никому это утверждение не затыкает рот.
Если ни у кого не получается в реальном проекте поменять один тип на другой (по самым уважительным причинам) и увидеть значительный результат в конечном продукте, значит утверждение верно. Скорей всего.
Это ж просто.
JekaMas
Попробую медленно.
В проектах, в которых работаю я. Разница есть. Ее нет, если делать web странички — это да.
Например, от замены одного типа дерева на другое мы получили выигрыш в prune операции на порядок, что позволило начать меньше места жрать на диске пользователя, который бывает и мобильным в том числе. Реальный проект, реальный пример.
Поймите, вы судите только со своей колокольни и очень резко. Ваша резкость мало соотносится с реальным опытом программиста и качеством кода. Поэтому выглядит нелепо.
Разница очень существенна. С ней начинаешь понимать, что понятие «преждевременной оптимизации» относительное и для одного «преждевременная» — это давайте все делать в массивах, а после посмотрим, где окажется узко, и это сработает на многих проектах; а для других непреждевременной оптимизацией будет на минутку посидеть над новым методом и подумать, а как часто его будут дергать, сколько данных можно ожидать сразу, через год, через два и прикинуть подходящий тип данных, тоже без кропотливых исследований, но все же подумать и снизить вероятность критичной ошибки.
musicriffstudio
меньше слов, больше дела.
JekaMas
Неловко с вашим кодом получилось, неправда ли?
Вот уже и про «недостаток опыта» перестали болтать.
Удачи!
musicriffstudio
всего самого наилучшего
boblenin
А на что вы мне предлагаете поменять Stack или Dictionary?
> Это приходит с опытом.
Разумеется.
musicriffstudio
если вы непонятно на что менять то зачем лезть в обсуждение?
Напомню, здесь безуспешно пытаются опровергнуть тезис о незначительности влияния на конечный результат смены одного типа списка на другой. В реальных неучебных приложениях.
JekaMas
Или, вернее, безуспешно пытаются продать себя, как эксперта с весомым мнением.
boblenin
хорошо. освежим вашу память.
вы заявили
> Нужно просто открыть код над которым он работал сегодня и
> посмотреть есть ли там миллионы списков.
> их нет.
я вам ответил
> Stack и Dictionary, на подходе Queue и все для того чтобы
> избежать решения в лоб
вы начали слегка подхамливать, но кроме того предложили их заменить:
>Насколько я понимаю, вы, как и предыдущий оратор, не
>можете изменить «свой» код и проверить как смена одного
>типа списка на другой влияет на конечный результат.
Я попросил вас уточнить на что же я должен поменять Stack и Dictionary
Вы предлагаете мне читать ваши мысли?
Вот вы всем тут про ваш опыт рассказывали. Не расскажите сколько лет стажа и какого размера комманды были, в которых вам довелось работать?
musicriffstudio
На ваше усмотрение. Любой другой сходный по функционалу класс.
Изначальный тезис, напоминаю
Если вы не можете изменить «ваш» и проверить — значит это не ваш код.
JekaMas
Открыл. Вижу десятки деревьев разных видов, есть списки в каком-то кэше с ограничением длины в 100к, небольшой кэш, видимо.
Думаю, эти разные структуры данных тут неспроста. Оставлю, пожалуй.
musicriffstudio
т.е. поменять «свой» код и измерить влияние на конечный продукт по каким-то причинам не получается?
JekaMas
Откуда этот вопрос? Вы спросили про структуры данных, вам дал ответ. А теперь вы делаете какой-то необоснованный вывод.
Как и у вас, все open source, и "все ориентированы на продукт" и прочая. Поменять код не проблема, только вот эти типы данных живут тут неспроста, уже были добрые люди "давайте сделаем сразу проще" и после все умирало или жило криво до безбожности в конкурентном коде. И вот уже или люди поумнели, или поменялись и сначала читаем умные статьи про наши кейсы и ищем подходящие структуры данных. Ибо менять все по многу раз — это довольно больно.
DistortNeo
Вы ещё скажите, что программист, который ради одной простой одноразовой функции, например, преобразования числа в hex, не подключает многомегабайтные фреймворки, а просто пишет эту функцию за минуту, тоже неопытен, потому что не умеет пользоваться чужим кодом.
Кстати, отличие опытного программиста от неопытного заключается в том, что опытный программист заранее знает, какие места могут быть узкими и могут быть соптимизированы, но сознательно реализовывает их более быстрым, но менее оптимальным образом.
KvanTTT
А может это у вас «преждевременная пессимизация»?
GrigoryPerepechko
Напишите на каждую из структур тест в котором сперва создаете список на 100,000 элементов арифметической прогрессии. И напишите тест который складывает эти числа с первого до последнего.
И сравните результат. После этого надеюсь вы перестанете писать чушь про сотые доли процента.
WraithOW
В сообщении, на которое вы отвечаете, есть пометка «в реальности». В реальности для подсчета суммы арифметической прогрессии нужно воспользоваться формулой, а человеку, который додумается сделать по вашему сценарию, нужно настучать клавиатурой по рукам. Больно.
GrigoryPerepechko
Давайте не сумму а квадратичное отклонение. И не прогрессия а клиент присылает на сервер (дабы не было предположений о данных)
Но забавляет ваше желание сломать об ваше представление о реальном программировании мой сугубо академический пример придуманный чтобы показать что такое кеш мисы и как сильно может отличаться константа у алгоритмов (полный прямой обход) в структурах с одинаковой асимптотикой.
WraithOW
Придти с
мороженкой на бой подушкамиакадемическим примером в неакадемическую дискуссию по конкретному языку — это ваше решение. Хотели показать кеш-мисс? Оке, только джава не умеет в примитивные коллекции, так что какой бы список вы не выбрали — всё равно будете постоянно мазать, а решение всё равно будет тормозным.Так что в этом вся и суть — придумать можно очень много разных фантастических сценариев, но имхо на практике в большинстве случае вам либо побоку производительность списка, потому что её вклад в конечный результат исчезающе мал, либо вы не пользуетесь списками в принципе.
Krat0S
В том-то и дело)
Процентов 40 собеседуемых, могут перевести название, но объяснить в каком случае какой лист надо использовать не могут.
Neikist
Вы меня испугали) Я то думал среди уже работающих, а это про собеседование. Тут недавно цифра в каментах к другой статье проскакивала что 80% на собеседовании про стек рассказать не могут…
boblenin
Увы, значительное количество не знает ответа на этот вопрос, даже если его поставить более прямолинейно: «Где быстрее поиск N-го элемента в массиве или односвязном списке»? Хотя по насчет разбивки по языкам спекулировать не буду.
shiru8bit
Написал несколько проектов (эмуляторы игровых автоматов) под Android на Haxe. Java, впрочем, более-менее знаю (в основном J2ME и десктоп), но скорость не та, а Haxe компилируется в натив. На Middle Android Developer видимо не потяну, формального ответа не знаю.
Tsimur_S
Ответ «никогда не используйте LinkedList» принимается?
JediPhilosopher
Нет. Потому что я вот лично встречал ситуации когда приходилось менять с аррайлиста на линкедлист. Там требовалось в памяти держать ооочень длинные массивы, при попытке добавить новый элемент в аррайлист рано или поздно происходило перевыделение массива и оно падало, так как не могло выделить непрерывный кусок памяти достаточно большого размера из-за фрагментации (при том что суммарно свободной памяти хватало, и линкедлист нужного размера там отлично умещался).
Опять же вставка в середину или удаление с аррайлистами начинает ощутимо дольше работать на очень больших списках.
Tsimur_S
Разве что только вы использовали для этого итератор в случае LL что может быть эффективно только лишь если большая часть удалений происходит пакетами в примерно одном месте, а не в случайном порядке. Насколько я видел бенчмарки итерация через LL для того что бы удалить элемент будет все равно медленнее чем нативный arraycopy с рандомакссес.
Первый случай довольно редок и как по мне это попытка переложить проблему GC на логику приложения. Как костыль сойдет, как общая рекомендация ни в коем случае.
boblenin
А не эффективнее ли было аллокатор инициализировать правильным значением, чем расходовать по указателю на каждый элемент? Я, конечно, не знаю какого размера у вас в списке структуры лежали.
mayorovp
Если лично я встречу подобную ситуацию — я не буду переписывать на LinkedList, а сделаю особый контейнер под задачу. LinkedList не позволяет быстро искать элемент списка по его значению (для той самой вставки в середину), и неэффективно расходует память.
DistortNeo
У меня на практике был только один сценарий использования LinkedList — планировщик задач, а точнее, хранение очереди подписчиков на события, которых может быть довольно много, и которые подписывались-отписывались очень часто (практически при каждом событии).
boblenin
А разве ArrayList заалоцированый с запасом не даст лучший результат?
mayorovp
А как вы их отписывали? Если каждый раз искать нужный обработчик в LinkedList — то удаление будет немногим быстрее чем удаление из ArrayList. Если отписывать только крайние обработчики, то лучше использовать ArrayDeque.
Если же отписывался обработчик по время выполнения — то не быстрее ли создать новый ArrayList, и добавлять туда те обработчики, которые забыли отписаться?
DistortNeo
Эмм, а зачем его искать, когда можно просто хранить ссылку на элемент в LinkedList?
mayorovp
Какую именно ссылку вы предлагаете хранить? Если вы про LinkedListNode, то в Java этого класса не существует.
DistortNeo
Да, я про LinkedListNode.
AMURWOLF
А если я пишу прогу с графическим интерфейсом и хочу сделать список кнопок, то какой из этих двух выбрать?
Krat0S
Зависит от того, что Вы с этим списком будете дальше делать.
javarush.ru/quests/lectures/questsyntax.level08.lecture05
AMURWOLF
Дальше я напишу несколько слушателей (listener), которые будут при разных событиях читать список, добавлять в список кнопки и удалять их, возможно из середины.
AMURWOLF
Ок. В данном случае ни ArrayList, ни LinkedList не годятся, ибо они потоконебезопасные.
DistortNeo
В случае разработки интерфейса предполагается, что все манипуляции с GUI выполняются в специальном потоке.
ilitaexperta
Тут полезно знать мнение автора LinkedList в Java
Вообще это кстати очень хороший вопрос, условные джун, мидл и синьер дадут на него сильно разные ответы
Necessitudo
А как с вами связаться?:)
Krat0S
Написать в личку? :)
NBAH79
А сколько таких примеров возможно придумать в принципе, и не стоят ли они ломаного гроша, в плане что это можно объяснить любому достаточно быстро, главное иметь достаточную аргументацию, раз уж она накоплена опытом, нет? И это будет быстрее чем искать того самого ненаглядного сеньора, который теоретически вот вот должен прийти в эту замечательную компанию бросив все остальные, ведь в остальных ему так мало платят и он такой несчастный?.. )))
zagayevskiy
Есть мнение, что LinkedList надо использовать примерно никогда
s-kozlov
А как можно знать основы Java, не зная, что этот вопрос, в общем, не имеет отношения к Java?
First_Spectr
Блин, ты меня описал, знаю именно эти паттерны(еще MVVM) и эти библиотеки(+ другие по мелочи вроде дагера, батернайфа и подобного), правда до сих пор не уверен дошел ли я хотя бы до джуна…