Если вы не нанимаете джунов, то не заслуживаете сеньоров

http://isaaclyman.com/blog/posts/junior-developers/
  • Перевод
Позвольте рассказать вам историю об одной очень успешной компании, совершившей большую, глупую ошибку:
Мы не нанимаем младших программистов и интернов… Если не заводить щенка, не придётся убирать лужи.
--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.

The trick is, I recruit some of them earlier in their career.

— Reginald Braithwaite (@raganwald) 17 сентября 2018 г.

Я нанимаю только старших программистов.

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

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

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

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

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


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

Companies so eager to only hire senior people often forget that unlearning what doesn't apply can take longer than learning what does.

— DHH (dhh) 31 июля 2017 г.

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

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

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

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

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 принцип «только сеньоры» недооценивает младших программистов. Это плохо сказывается на всех, особенно когда организация считает, что без начинающих специалистов всё будет даваться легче. Хотя некоторые подобные компании финансово успешны, можно представить себе колоссальные растраченные суммы которые приходится сносить их бюджету из-за такого подхода.

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

Комментарии 279

    +2
    А я легко нанимаю джунов :)
    В мобильной разработке сложилась такая ситуация, что сеньоры стоят очень дорого, а мидлов не существует.
    Ну то есть они существуют только в своих глазах, а на практике, это люди, которые выучили пару паттернов (MVP\MVC), три библиотеки (rx, retrofit, moxy) и считающие себя могучими программерами, равными богам.

    Забавно выглядит, когда человек, называющий себя Middle Android Developer, не может ответить на простой вопрос — «Когда лучше использовать Array List, а когда Linked List?».
    Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?
      +2
      Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?

      Легко, можно писать на Unity и C#. У нас успешная команда, которая так делает уже более пяти лет.

      Хотя, это скорее шутка, конечно эти знания нужны.
        0
        Да вообще без вопросов :)
        Мы со своим уставом в чужой монастырь не ходим.
        Как только появится методика успешной интеграции Android-приложений написанных не на Java\Kotlin с VMWare AirWatch, так мы сразу и начнём рассматривать такие варианты.
          0
          Ы, у нас заказчик требовал встроить AirWatch в приложение для андроид на 1С. В итоге часть потребностей заказчика решили через написание второго приложения рядом на java и сделали обмен между этим приложением и приложением на 1с)
            0
            Не ТОиР случаем?)
              +1
              Эмм… Не хочу чтобы меня с этим проектом связывали, так что «нет»))
          +1
          А что это меняет? Когда лучше использовать List, а когда LinkedList?
            +1

            List лучше использовать примерно всегда.

              +1
              Плохой ответ, потому что не показывает, действительно ли вы знаете разницу, или просто никогда не задумывались.
                +5

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

                  +1
                  А вот это хороший ответ, хоть вы прямо ответ на вопрос и не озвучиваете :)
                    0
                    Аналогично. Думал что может я что-то упускаю, но оказывается мое мнение не единственное. Хотя может просто задач подходящих не было.
                      0
                      Если у тебя два листа/стека с использованием LinkedList, то ты можешь из замерджить в O(1), вместо того, чтобы создавать новый массив и копировать все данные туда O(n)

                      Ну и конечно, когда хочешь удалить элемент в O(1) имея handle/pointer. Например с помощью HashMap и LinkedList можно написать LRU Cache
                        +1

                        А можно использовать LinkedHashMap и не писать велосипедов. Это О(1) для связного списка разбивается об реальные данные.

                          0
                          Ну так LinkedHashMap уже использует LinkedList under the hood. Я не говорю писать костыли, я говорю где это может быть полезно. Хорошо что java имеет такие классы в стандартной библиотеке. Вопрос LinkedList или Array/Vector не ограничивается языком.

                          Например С++ не имеет LinkedHashMap.
                          Костыли есть костыли, а конценты есть концепты.

                          Ты на интервью также скажешь?
                          Ну так есть уже LRU класс в джаве, зачем думать
                            0
                            Например С++ не имеет LinkedHashMap.

                            а чем boost::multi_index не устраивает? конечно boost это не STL, но для плюсов уже практически стандартная библиотека если чистого STL вдруг начинает нехватать
                              0
                              Я все склоняюсь к тому, что слепое удтверждение, что Vector >> LinkedList всегда, это не правильно. Use-Case'ы могут быть.

                              Для конкретного выбора нужен benchmark.

                              Опять же, для не High Performance Systems ArrayList сгодиться всегда.
                              +1
                              Нет, LinkedHashMap не использует LinkedList. Там внутри особая реализация. Просто потому что LinkedList в том виде в котором представлен в стандартной библиотеке Java совершенно бесполезен.
                                0
                                Почему? Не пишу на Java, просто интересно.
                                  +1
                                  Потому что из LinkedList нельзя удалить произвольный элемент за O(1). А если так — зачем он такой нужен?
                                    0
                                    А из-за чего так получается? В Джаве нет ссылки на конкретный элемент (инкапуслировано for ya)?
                                      0
                                      Да, именно поэтому. Ради соответствия общему с ArrayList интерфейсу они заинкапсулировали саму важную функциональность…
                          0
                          Парсинг и push/pop в дерево в целях быстрого анализа.
                          +3
                          в подавляющем большинстве случаев связные списки даже на «своих» задачах оказываются медленнее массивов из-за лишних аллокаций/деаллокаций и принципов работы кеша.
                    –7
                    С точки зрения реального применения в реальных приложениях никакой разницы между Array List и Linked List нет.
                      0
                      Это отличное утверждение и действительно часто так и бывает, с этого момента интервью перестает томным… И вам предстоит показать и доказать, почему же разные имплементации имеют теоретически разное время выполнения, а на практике это оказывается не так заметно.
                        0
                        Нет, интервью ж это обоюдный процесс.

                        Мой опыт в жаве около 15 лет, я делал приложения ещё для J2ME, в котором на кучу выделяется 64кб памяти, если вы понимаете что это такое.

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

                          0
                          Я же и не спорю, обоюдный процесс. У нас вопросы — у вас ответы, будет интересно пообщаться :-)
                      +3

                      Что, извините, за бред? Оба списка имеют конкретные сценарии применения и разница в скорости и нагрузке на память (особенно в присутсвии сборщика) могут различаться на порядок. Это не учитывая что у обоих разные интерфейсы.

                        0
                        Если в ваших списках бывает только 3.5 записи, то да, никакой разницы нет )))
                          0
                          А потом еще кто-то начинает писать статьи про то, что программисты совсем распустились и их программы тормозят на топовых машинах :)
                        +5
                        Просто всегда употребляй ArrayList и не думай)))
                          +3
                          Судя по всему, комментатор чуть выше так и делает :)
                            0
                            Конечно. А если будет тормозить, то это однозначно компилятор виноват, потому что не оптимизирует. JAVA уже не та, переходим на SQL.
                            +4

                            Только ситхи возводят все в абсолют.


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

                              +1
                              О том и речь, чтобы сделать выбор в пользу какого-то из листов, да даже чтобы понимать необходимость этого выбора, нужно осознавать наличие и различия вариантов.
                                +2
                                А вот интересно, насколько много людей которые на java пишут не видят между ними разницы? Я хоть не джавист, но по идее даже по названию предположить можно что LinkedList это связный список, а ArrayList динамический массив, что за собой влечет разную асимптотику на одни и те же операции.
                                  –1
                                  в реальности разница между ними это сотые доли процента влияния на конечный результат. В абсолютном большинстве случаев.

                                    0
                                    Да. Но эти случаи есть это раз, а два — лично я, например когда пишу на 1с, предпочитаю выбирать то что больше подходит (что конечно не отменяет последующего профилирования), если сценарии использования объекта заранее известны и выбор структуры можно сделать за несколько секунд. В итоге самому же приятнее от написанного кода.
                                      –7
                                      если вы занимаетесь преждевременной оптимизацией вы тратите (воруете, скорей, на своё личное хобби) деньги работодателя.
                                        +1
                                        Серьезно? Секунды выбора между двумя структурами это трата времени 90% которого уходит на разные согласования и выяснения бизнес-требований?
                                          –4
                                          если выбор занимает секунды то это не выбор, это «наитие».
                                            +1
                                            Ну вообще да, я скорее про это и говорю. Во первых по наитию примерно выбирать структуру данных + во вторых не пугаться почему вдруг кусок кода стал тормозить и знать на что ее можно поменять.
                                            А вообще я вопрос то изначальный больше задал по причине того что неясно: ответить на вопрос люди не могут из за того что внутрях лежит то что названию не соответствует, или же просто не могут в принципе ответить? Во втором варианте это выглядит странно, уж если 1сник без образования программиста разницу между этими структурами знает…
                                              –9
                                              такие вопросы это признак низкой квалификации. Нет ориентированности на результат.
                                                +2
                                                Нет ориентированности на результат.
                                                Извините, но вы сейчас звучите как плохой HR из анекдотов.
                                              +1
                                              В описываемом случае, это как раз выбор.
                                              Я полагаю, что разработчик знает, зачем создаёт список.
                                              И, в большинстве случаев, за пару секунд может сказать, будет ли он постоянно вставлять элементы в произвольное место, или дописывать в конец. Будет ли использоваться обход списка, или нужен точечный доступ к произвольным элементам.
                                                –5
                                                в большинстве случаев это несущественно для реальных приложений.
                                                  0
                                                  А вот это Вы зря.

                                                  Чуть ниже подходящий ответ.
                                                    –4
                                                    описание единственного случая и является подтверждением вышесказанного.
                                                  0
                                                  И, в большинстве случаев, за пару секунд может сказать, будет ли он постоянно вставлять элементы в произвольное место, или дописывать в конец. Будет ли использоваться обход списка, или нужен точечный доступ к произвольным элементам.
                                                  А смысл? Пока у нас список не стал очень длинным, ArrayList во всех этих кейсах будет эффективнее и по скорости, и по памяти
                                                    0

                                                    Смысл именно в этом)
                                                    Объяснить в чем разница.

                                          0
                                          Пока у тебя не миллион этих листов, по миллиону операций с каждым в секунду.
                                            –4
                                            это называется «преждевременная оптимизация». Явный признак недостатка опыта.
                                              +6
                                              Это называется «отсутствие понимания задачи» и отличать это от преждевременной оптимизации довольно важно. Считать любую оптимизацию «преджевременной» — явный признак недостатка опыта.
                                                –3
                                                это не «любая» оптимизация, это оптимизация вымышленных миллионов листов на вымышленных миллионах операций в секунду.
                                                  +3
                                                  Так у нас тут все случаи вымышленные, мы же о чистой теории говорим.
                                                  А на практике я не раз и не два сталкивался с ситуацией когда система спроектирована не была, потому что «время потраченное на проектирование это время не потраченное на написание кода, а нам платят за код», и в итоге, внезапно, работала на тестовом наборе данных, и висла подумать на десяток секунд в реальном мире. И переписать это все стоило больше чем написать с нуля.
                                                    0
                                                    Всего десяток секунд? Я видел случаи когда система на десятки минут зависала, а после переписывания буквально пары десятков строк работала за доли секунды над теми же задачами.
                                                      +2
                                                      Вот хорошо когда можно переписать что-то одно и все хорошо. А когда ключевой момент системы построен по принципу «вроде не виснет при передаче hello world, а значит и многокилобайтные файлы схавает», это все только выкинуть, вместе с тем человеком который решил время на предварительную оптимизацию не тратить, а, условно, передавать каждую букву отдельным https пакетом (не, ну а чо, работает же).
                                                        0
                                                        передавать каждую букву отдельным https пакетом

                                                        Аж передернуло!
                                                        Но история как из жизни. Сколько раз видел «давай запросим из БД все товары продавца и после в коде отфильтруем клевыми map-filter-reduce».
                                                          0
                                                          Я сам когда-то один раз видел (приходилось дорабатывать) кусок кода на PHP, который сначала делал «SELECT * FROM table», потом в цикле всё читал — чтобы посчитать количество записей.
                                                      –5

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


                                                      их нет.


                                                      а вот массивы на сотню элементов есть.


                                                      и ничего с этим не поделать.

                                                        +1
                                                        А это у вас откуда такая статистика замечательная взялась?
                                                        Вот я открыл код, а там есть массивчик, который, в нормальное время, состоит из любого количества элементов от одного до пары миллионов. И поделать с этим что-то все-таки надо.
                                                          0

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


                                                          Или этот кусок написан давно и трогать его нельзя? Да и элементов там в реальности раз сто меньше? И сделан он второпях и его пора выкинуть заменив чем-то более подходящим?


                                                          Вот так всегда и бывает.

                                                            0
                                                            Если вы думаете что можно так прям спокойно менять одни контейнеры на другие везде где захочется, то вы серьезно недооцениваете связность среднего кода.
                                                            Я серьезно не понимаю, с чего вы решили что в мире не бывает больших контейнеров, или что весь код в мире похож на ваш.
                                                        0
                                                        Открыл проектик. Там сразу же рядом. Stack и Dictionary, на подходе Queue и все для того чтобы избежать решения в лоб, которое дает 2Gb съедаемой памяти на транзакцию, против 2Mb на решении, с использованием всех этих структур.
                                                          –1
                                                          Насколько я понимаю, вы, как и предыдущий оратор, не можете изменить «свой» код и проверить как смена одного типа списка на другой влияет на конечный результат.

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

                                                          Это приходит с опытом.
                                                            +2

                                                            Как я понимаю, умение именовать коммиты и не фигачить в мастер тоже приходит, но попозже? https://github.com/surikov/riffshare/commits/master
                                                            Как я понимаю, вы работали всегда в небольших проектах. И тут у вас опыт, бесспорно есть. Однако не стоит говорить снисходительно о других людях, особенно, когда собственное резюме и код "не для гугла — у меня свой проект".

                                                              0
                                                              прям как история с Т.Линусом и феминистками. Я просил подтверждение значительно влияния выбора между разными типами списков в реальных проектах, а мне про снисходительность и невежливость.

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

                                                              Но тут я не настаиваю.
                                                                0
                                                                Ну давай рассмотрим ваши продукты и решим, есть ли у вас право быть экспертом про «качественные продукты».
                                                                Я посмотрел. Все продукты это «пишу сам для себя, но в 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);
                                                                        }
                                                                    }
                                                                }
                                                                


                                                                Это ведь полностью ваш код. Без поддержки legacy и прочего. Но, как известно, некоторый код становится legacy сразу, как его написали.

                                                                На мой взгляд, у вас очень «местничковый» опыт. И мало, либо нет вовсе опыта работы в команде. Что для программиста критично. Можно, конечно, говорить о том, «зато у меня свой продукт и полный контроль!» Да, с чем вас и поздравляю.
                                                                Но это не мастерство программиста — это принятия себя в качестве «хочу тихо кодить и чтобы никто не мешал». То же путь.
                                                                Но тогда уж не судите других. Поверьте, тут, на Хабре, очень много людей, собеседование с которыми вы бы не выдержали, как программист или руководитель проекта.
                                                                  0
                                                                  Я просил подтверждение значительно влияния выбора между разными типами списков в реальных проектах.

                                                                  Остальное оффтоп.
                                                                    +1
                                                                    Мои реальные проекты имеют отношение к распределенным базам данных. Поверьте, у меня всякие структуры данных и выбор их критичен. Нам приходится выбирать, в частности, между тем, какой именно вид Bloom filter нам подойдет лучше по API, ассимпротике на разных объемах данных.

                                                                    Но все же. Вы тут судите, как эксперт. Позвольте уж и другим спецам высказаться, но уже насчет вашего опыта, кода и, соответственно, права судить и весомости вашего суждения.
                                                                    Что код приведен выше ваш вы не отрицаете. Значит народ сможет посмотреть и сложить мнение.
                                                                      –3
                                                                      Зачем это всё? Фильтры, гитхаб, распределённые базы, вера? Вот изначальное утверждение

                                                                      С точки зрения реального применения в реальных приложениях никакой разницы между Array List и Linked List нет.


                                                                      Здесь нет оскорблений, никому это утверждение не затыкает рот.

                                                                      Если ни у кого не получается в реальном проекте поменять один тип на другой (по самым уважительным причинам) и увидеть значительный результат в конечном продукте, значит утверждение верно. Скорей всего.

                                                                      Это ж просто.
                                                                        0
                                                                        Попробую медленно.
                                                                        В проектах, в которых работаю я. Разница есть. Ее нет, если делать web странички — это да.
                                                                        Например, от замены одного типа дерева на другое мы получили выигрыш в prune операции на порядок, что позволило начать меньше места жрать на диске пользователя, который бывает и мобильным в том числе. Реальный проект, реальный пример.
                                                                        Поймите, вы судите только со своей колокольни и очень резко. Ваша резкость мало соотносится с реальным опытом программиста и качеством кода. Поэтому выглядит нелепо.

                                                                        Разница очень существенна. С ней начинаешь понимать, что понятие «преждевременной оптимизации» относительное и для одного «преждевременная» — это давайте все делать в массивах, а после посмотрим, где окажется узко, и это сработает на многих проектах; а для других непреждевременной оптимизацией будет на минутку посидеть над новым методом и подумать, а как часто его будут дергать, сколько данных можно ожидать сразу, через год, через два и прикинуть подходящий тип данных, тоже без кропотливых исследований, но все же подумать и снизить вероятность критичной ошибки.
                                                                          –2
                                                                          меньше слов, больше дела.
                                                                            0
                                                                            Неловко с вашим кодом получилось, неправда ли?
                                                                            Вот уже и про «недостаток опыта» перестали болтать.

                                                                            Удачи!
                                                                              –2
                                                                              всего самого наилучшего
                                                              0
                                                              А на что вы мне предлагаете поменять Stack или Dictionary?

                                                              > Это приходит с опытом.

                                                              Разумеется.
                                                                0

                                                                если вы непонятно на что менять то зачем лезть в обсуждение?


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

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

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

                                                                    я вам ответил
                                                                    > Stack и Dictionary, на подходе Queue и все для того чтобы
                                                                    > избежать решения в лоб

                                                                    вы начали слегка подхамливать, но кроме того предложили их заменить:
                                                                    >Насколько я понимаю, вы, как и предыдущий оратор, не
                                                                    >можете изменить «свой» код и проверить как смена одного
                                                                    >типа списка на другой влияет на конечный результат.

                                                                    Я попросил вас уточнить на что же я должен поменять Stack и Dictionary

                                                                    Вы предлагаете мне читать ваши мысли?

                                                                    Вот вы всем тут про ваш опыт рассказывали. Не расскажите сколько лет стажа и какого размера комманды были, в которых вам довелось работать?
                                                                      –1
                                                                      На ваше усмотрение. Любой другой сходный по функционалу класс.

                                                                      Изначальный тезис, напоминаю
                                                                      С точки зрения реального применения в реальных приложениях никакой разницы между Array List и Linked List нет.


                                                                      Если вы не можете изменить «ваш» и проверить — значит это не ваш код.
                                                                        0
                                                                        Если вы можете легко и быстро менять контейнеры в вашем коде чтобы доказать что-то случайному чуваку с хабры, у вас очень простой код, в котором действительно неважно что где хранить.
                                                                        Рефакторинг подавляющего большинства рабочих проектов задача нетривиальная.
                                                                          0
                                                                          Т.е. не только не получилось измерить производительность конечного продукта, но даже заменить один класс на другой сходного функционала в реальном приложении не выходит.

                                                                          Отрицательный результат это тоже результат.

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

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

                                                                0
                                                                т.е. поменять «свой» код и измерить влияние на конечный продукт по каким-то причинам не получается?
                                                                  +1

                                                                  Откуда этот вопрос? Вы спросили про структуры данных, вам дал ответ. А теперь вы делаете какой-то необоснованный вывод.


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

                                                        +3
                                                        это называется «преждевременная оптимизация». Явный признак недостатка опыта.

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


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

                                                          +3
                                                          А может это у вас «преждевременная пессимизация»?
                                                        +1

                                                        Напишите на каждую из структур тест в котором сперва создаете список на 100,000 элементов арифметической прогрессии. И напишите тест который складывает эти числа с первого до последнего.


                                                        И сравните результат. После этого надеюсь вы перестанете писать чушь про сотые доли процента.

                                                          0
                                                          В сообщении, на которое вы отвечаете, есть пометка «в реальности». В реальности для подсчета суммы арифметической прогрессии нужно воспользоваться формулой, а человеку, который додумается сделать по вашему сценарию, нужно настучать клавиатурой по рукам. Больно.
                                                            0
                                                            Давайте не сумму а квадратичное отклонение. И не прогрессия а клиент присылает на сервер (дабы не было предположений о данных)

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

                                                              Придти с мороженкой на бой подушками академическим примером в неакадемическую дискуссию по конкретному языку — это ваше решение. Хотели показать кеш-мисс? Оке, только джава не умеет в примитивные коллекции, так что какой бы список вы не выбрали — всё равно будете постоянно мазать, а решение всё равно будет тормозным.

                                                              Так что в этом вся и суть — придумать можно очень много разных фантастических сценариев, но имхо на практике в большинстве случае вам либо побоку производительность списка, потому что её вклад в конечный результат исчезающе мал, либо вы не пользуетесь списками в принципе.
                                                              0
                                                              Япредлагаю отсортировать стандартным библиотечным способом LinkedList из 1000000 элементов и ArrayList с точно таким же контентом и почувствовать разницу по скорости.
                                                          0
                                                          В том-то и дело)
                                                          Процентов 40 собеседуемых, могут перевести название, но объяснить в каком случае какой лист надо использовать не могут.
                                                            +2
                                                            Вы меня испугали) Я то думал среди уже работающих, а это про собеседование. Тут недавно цифра в каментах к другой статье проскакивала что 80% на собеседовании про стек рассказать не могут…
                                                            0
                                                            Увы, значительное количество не знает ответа на этот вопрос, даже если его поставить более прямолинейно: «Где быстрее поиск N-го элемента в массиве или односвязном списке»? Хотя по насчет разбивки по языкам спекулировать не буду.
                                                      +1
                                                      Написал несколько проектов (эмуляторы игровых автоматов) под Android на Haxe. Java, впрочем, более-менее знаю (в основном J2ME и десктоп), но скорость не та, а Haxe компилируется в натив. На Middle Android Developer видимо не потяну, формального ответа не знаю.
                                                        +2
                                                        Когда лучше использовать Array List, а когда Linked List?

                                                        Ответ «никогда не используйте LinkedList» принимается?
                                                          +2
                                                          Нет. Потому что я вот лично встречал ситуации когда приходилось менять с аррайлиста на линкедлист. Там требовалось в памяти держать ооочень длинные массивы, при попытке добавить новый элемент в аррайлист рано или поздно происходило перевыделение массива и оно падало, так как не могло выделить непрерывный кусок памяти достаточно большого размера из-за фрагментации (при том что суммарно свободной памяти хватало, и линкедлист нужного размера там отлично умещался).
                                                          Опять же вставка в середину или удаление с аррайлистами начинает ощутимо дольше работать на очень больших списках.
                                                            +2
                                                            Опять же вставка в середину или удаление с аррайлистами начинает ощутимо дольше работать на очень больших списках.

                                                            Разве что только вы использовали для этого итератор в случае LL что может быть эффективно только лишь если большая часть удалений происходит пакетами в примерно одном месте, а не в случайном порядке. Насколько я видел бенчмарки итерация через LL для того что бы удалить элемент будет все равно медленнее чем нативный arraycopy с рандомакссес.
                                                            Первый случай довольно редок и как по мне это попытка переложить проблему GC на логику приложения. Как костыль сойдет, как общая рекомендация ни в коем случае.
                                                              +1
                                                              А не эффективнее ли было аллокатор инициализировать правильным значением, чем расходовать по указателю на каждый элемент? Я, конечно, не знаю какого размера у вас в списке структуры лежали.
                                                                0
                                                                Если лично я встречу подобную ситуацию — я не буду переписывать на LinkedList, а сделаю особый контейнер под задачу. LinkedList не позволяет быстро искать элемент списка по его значению (для той самой вставки в середину), и неэффективно расходует память.
                                                                +1

                                                                У меня на практике был только один сценарий использования LinkedList — планировщик задач, а точнее, хранение очереди подписчиков на события, которых может быть довольно много, и которые подписывались-отписывались очень часто (практически при каждом событии).

                                                                  0
                                                                  А разве ArrayList заалоцированый с запасом не даст лучший результат?
                                                                    0
                                                                    А как вы их отписывали? Если каждый раз искать нужный обработчик в LinkedList — то удаление будет немногим быстрее чем удаление из ArrayList. Если отписывать только крайние обработчики, то лучше использовать ArrayDeque.

                                                                    Если же отписывался обработчик по время выполнения — то не быстрее ли создать новый ArrayList, и добавлять туда те обработчики, которые забыли отписаться?
                                                                      0
                                                                      Эмм, а зачем его искать, когда можно просто хранить ссылку на элемент в LinkedList?
                                                                        0
                                                                        Какую именно ссылку вы предлагаете хранить? Если вы про LinkedListNode, то в Java этого класса не существует.
                                                                          0
                                                                          Да, я про LinkedListNode.
                                                                  +1

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

                                                                    0
                                                                    Зависит от того, что Вы с этим списком будете дальше делать.
                                                                    javarush.ru/quests/lectures/questsyntax.level08.lecture05
                                                                      +1

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

                                                                        0

                                                                        Ок. В данном случае ни ArrayList, ни LinkedList не годятся, ибо они потоконебезопасные.

                                                                          +1

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

                                                                      0
                                                                      Ну то есть они существуют только в своих глазах, а на практике, это люди, которые выучили пару паттернов (MVP\MVC), три библиотеки (rx, retrofit, moxy) и считающие себя могучими программерами, равными богам.
                                                                      Как же приятно встретить адекватного человека на хабре, ваши слова просто бальзам на душу

                                                                      Когда лучше использовать Array List, а когда Linked List?
                                                                      Тут полезно знать мнение автора LinkedList в Java

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

                                                                        А как с вами связаться?:)

                                                                          0
                                                                          Написать в личку? :)
                                                                          0
                                                                          А сколько таких примеров возможно придумать в принципе, и не стоят ли они ломаного гроша, в плане что это можно объяснить любому достаточно быстро, главное иметь достаточную аргументацию, раз уж она накоплена опытом, нет? И это будет быстрее чем искать того самого ненаглядного сеньора, который теоретически вот вот должен прийти в эту замечательную компанию бросив все остальные, ведь в остальных ему так мало платят и он такой несчастный?.. )))
                                                                            +1

                                                                            Есть мнение, что LinkedList надо использовать примерно никогда

                                                                              0
                                                                              Забавно выглядит, когда человек, называющий себя Middle Android Developer, не может ответить на простой вопрос — «Когда лучше использовать Array List, а когда Linked List?».
                                                                              Да, это больше вопрос по Java, но как можно писать под Android, не зная даже основ Java?

                                                                              А как можно знать основы Java, не зная, что этот вопрос, в общем, не имеет отношения к Java?
                                                                                0
                                                                                Блин, ты меня описал, знаю именно эти паттерны(еще MVVM) и эти библиотеки(+ другие по мелочи вроде дагера, батернайфа и подобного), правда до сих пор не уверен дошел ли я хотя бы до джуна…
                                                                                +2
                                                                                Особенно смешит когда ищут сеньоров с минимум 5 годами опыта работы с языком, который появился 5 лет назад) По Go видел вакансии только на сеньоров, при том что еще 3-4 года назад на том же хабре его обсуждали как некий экзотичный язык, игрушку, которая вряд ли будет когда то использоваться в продакшене)
                                                                                  +6

                                                                                  Не беда — синьоры-за-три-года уже спешат на помощь.

                                                                                    +3
                                                                                    Так может ищут сеньеров-независимо-от-языка знающих при этом go?
                                                                                      0
                                                                                      Вот именно что нет
                                                                                        0
                                                                                        Спрос рождает предложение. Если сильно будут искать — найдут таких. Сомнений нет :). Рано или поздно.
                                                                                    +5
                                                                                    Стоит отметить ещё один, неизмеримый фактор: тенденцию старших программистов к постоянным спорам на темы, которые в конечном итоге ничтожны — про алгоритмы, микрооптимизации и стиль кода.

                                                                                    ничтожны

                                                                                    алгоритмы, микрооптимизации


                                                                                    То-то я смотрю бурления комментариев до степени зависания страницы в соседнем топике не было. Пусть все, кто жалуются там купят себе еще три плашки RAM.
                                                                                      0
                                                                                      Но это рано или поздно закончится: уже сейчас куча сложностей с процессорами и скорость ядер остается поднимать разве что частотами.
                                                                                        0
                                                                                        Будут массово ставить два процессора на борду, подумаешь.
                                                                                          0
                                                                                          Да и уже сейчас некоторые ставят, бгг)
                                                                                          Но проблема в скорости одного ядра никуда не уходит, а распараллелить все не удастся.
                                                                                        0
                                                                                        > стиль кода
                                                                                        туда же
                                                                                        +13
                                                                                        пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости


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

                                                                                        В рамках статьи программисты воспринимаются, как некоторые черные ящики, которые на входе принимают кофе с тасками, а на выходе — код. Как бы вам не хотелось, это не так. Еще Брукс доказал, что введение даже равного специалиста в команду, сильно ее охлаждает. В статье же утверждается, что полтора программиста дадут выхлоп 150%, что противоречит Бруксу. В реальности эта цифра ближе к 110%, если вообще не ниже 100%, если джун совсем деревянный попался, или приходится менторить нескольких джунов.

                                                                                        Несмотря на некоторые спорные аргументы, в целом, с выводом статьи, согласен — в компаниях, которые не тратятся на развитие человеческого капитала, делать нечего — ни сеньорам, ни джунам.
                                                                                          0
                                                                                          Вывод вне контекста правильный, но вот делать его только из того что компания не хочет нанимать именно джунов — уже нет. Компания вполне может заморачиваться развитием разработчиков, но при этом нанимать разработчиков уже с опытом. Даже сеньорам есть куда развиваться обычно.
                                                                                            0
                                                                                            > Не учтены такие вещи, как:
                                                                                            да эти 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.
                                                                                            автор похоже все исследования провел в голове, сделал свои выводы и написал статью
                                                                                              0
                                                                                              and a Mormon

                                                                                              Понятно, сумасшедший. Расходимся.
                                                                                            +8
                                                                                            Не вижу проблемы. Не нанимают джунов одни — наймут другие: сеньоров на всех не хватит, и кому-то придётся учить своих. Так что в целом по индустрии найм джунов никуда не денется, а требовать его от конкретной конторы и делать о ней какие-то выводы на основании отказа — глупо.

                                                                                            P.S. Imho, в первую очередь найм джунов — это «хочешь стать женой генерала — выйди замуж за лейтенанта». Только тут всё быстрее — видел, как люди всего за пару лет раскрываются, не сильно косяча в процессе. Но из скольких надо выбирать для этого?
                                                                                              +5
                                                                                              Так и не увидел какую ошибку совершил Нетфликс и как это им помешало.
                                                                                                +3

                                                                                                Сложилось такое ощущение, что автора (или его протеже) в Нетфликс не взяли :)

                                                                                                  0
                                                                                                  Может он просто уволился, видя и картину происходящего
                                                                                                    0
                                                                                                      +1
                                                                                                      Судя по профилю на линкедине — автор сам еще порядочный «джуняра» (психологически), программировать начал менее 3-х лет назад, а до этого сидел в QA. Видимо, пока не пристроился в свою HealthCatalyst (а это не софтверная компания), пережил немало отказов из-за отсутствия практического опыта.
                                                                                                0
                                                                                                Возможно у Вас собеседовался разработчик не уровня «Middle»?

                                                                                                И столько компаний ищут разработчиков уровня «Middle», а оказывается, они не существуют в природе.
                                                                                                  +12
                                                                                                  Все аргументы — философское бла-бла и натягивание совы на глобус.
                                                                                                  Описанный подход очень логичен и имеет право на существование.
                                                                                                  Что, конечно же, абсолютно не значит, что не может быть других подходов.
                                                                                                    +3
                                                                                                    Бывает и обратная история: «сеньоров у нас уже вагон, давайте наймём табун джунов и научим их, заодно на ФОТе сэкономим». При этом все сеньоры либо не очень сеньоры, либо загружены работой по крышечку, либо не имеют интереса/способностей к обучению других. При этом как класс отсутствует тактика и стратегия обучения.

                                                                                                    Netflix может передумать в любой момент и начать джунов набирать и учить. Описанные же товарищи, если решат поменять ситуацию, потратят на разворот хорошо если год, по дороге растеряв половину набранных и худо-бедно разбирающихся в происходящем людей.
                                                                                                      +1
                                                                                                      Бывает и обратная история: «сеньоров у нас уже вагон, давайте наймём табун джунов и научим их, заодно на ФОТе сэкономим». При этом все сеньоры либо не очень сеньоры, либо загружены работой по крышечку, либо не имеют интереса/способностей к обучению других. При этом как класс отсутствует тактика и стратегия обучения.

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

                                                                                                      +2
                                                                                                      Существует всего две причины нанимать джунов: хорошая и плохая.

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

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

                                                                                                      Я лично работал в синиор онли компании. Никаких проблем связанных с этим не заметил.
                                                                                                        +12
                                                                                                        Если джунам не дать в помощь никого, могут и вообще не справиться.
                                                                                                          +2
                                                                                                          Джуны справятся, но стоить это будет дороже.

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

                                                                                                              И повторюсь — такой подход подойдет не всем и не на каждом проекте.
                                                                                                                0
                                                                                                                Т.е. все равно пока джуны не дорастут хотя-бы до мидлов на них будут тратить время сеньоры?
                                                                                                                  0
                                                                                                                  Конечно будут. И мидлы будут, и другие сеньоры (код-ревью и всё такое). Вопрос в пропорциях.

                                                                                                                  Чтобы говорить предметно: мы занимаемся мобильной разработкой. На приложение есть дизайн, спецификации на поведение и сеть. В самом приложении — куча типовых компонентов. Нужно сделать новый экран? Вот типовой класс, наследуйся, добавляй разметку и поведение. Персистентность? Вот типовой компонент, пропиши тип кеша, тип данных и используй. Запросы? Вот типовой… ну вы поняли. Это механическая работа, перемежаемая периодическими контактами с дизайнерами/аналитиками на предмет уточнить или добавить или поправить что-либо; для неё не нужно уметь проектировать высоконагруженные системы.

                                                                                                                  Можно ли вместо найма джуна написать суперфреймворк, который сам будет генерировать большую часть приложения по файлам с дизайном и документам со спецификациями? Мб можно, но джун дешевле. Можно ли посадить сеньора вписывать отступы и перебрасывать модели из одного компонента в другой? Можно, но джун дешевле, а сеньор может и сбежать от такой рутины.
                                                                                                              0
                                                                                                              Вот тут и нужен опытный разработчик.
                                                                                                              Чтобы написать скрипт/фреймворк и перестать шмалять однотипные формочки.
                                                                                                              +2
                                                                                                              и джуны справятся не состоятельный. Джуны справятся, но стоить это будет дороже

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

                                                                                                              Тут впрочем опять непонимание что такое «джун», так как формальных критериев никаких нет и каждый трактует как хочет. Если считать что это человек с нулевым опытом и посредственным знанием синтаксиса языка — то да, там лиду придется больше объяснять ему, чем если бы он взял и сделал сам. Но если это человек хотя бы с годом опыта работы, то мелкие задачи он может делать сам, и даже более-менее качественно (особенно если в компании реально используют всякие автоматизированные метрики качества — статический анализ, тесты и т.п., которые позволяют отсекать совсем уж криворукий новичковый говнокод без участия сеньоров)
                                                                                                                0
                                                                                                                Дороже это может начать стоить, когда написанное понадобится расширить. По метрикам качества есть сомнения. Если сеньоров нет, то реализация этих метрик с большой долей вероятности будет такой же, что и код. Тем более, я лично не очень представляю автоматическую оценку расширяемости.
                                                                                                                  0
                                                                                                                  Написать вагон бойлерплейта

                                                                                                                  Не нужно писать вагоны бойлерплейта.

                                                                                                                  пофиксить какие-нибудь мелкие баги

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

                                                                                                                    Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.
                                                                                                                      0
                                                                                                                      >> Не бывает джуновских тасков.

                                                                                                                      У вас разработана структура БД и есть ORM. Задача перевести эту структуру в то, что получит на вход ORM — чем не джуновская? Или с теми же формами, написать валидатор для очередной формы или добавить поле — чем не джуновская задача?

                                                                                                                      >> Если у вас много монотонной работы у вас либо плохой менеджмент, либо плохие сеньоры.

                                                                                                                      Либо «поточное производство»
                                                                                                                        0
                                                                                                                        Первую задачу я не понял.

                                                                                                                        Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.

                                                                                                                        Поточное производство напрашивается на автоматизацию.
                                                                                                                          +1
                                                                                                                          >> Если вам нужно постоянно добавлять поля и писать валидаторы, то надо вынести это в конфиг и пусть BA играются сколько хотят.

                                                                                                                          Во-первых, BA может и не быть. Во-вторых, в конфиг легко выносятся простые случаи, если же поля зависимы, то этот конфиг может превратиться в тьюринг-полный редактор макросов, который надо поддерживать, который непонятно когда окупится и в которым не факт, что пользователи захотят разбираться (и в итоге будет такая же джуновская задача по вбиванию условий в этот редактор). Ну и, банально, стоимость времени BA на «поиграться» может легко превысить стоимость правки кода.

                                                                                                                          >> Поточное производство напрашивается на автоматизацию.

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

                                                                                                                            Во-вторых, в конфиг легко выносятся простые случаи

                                                                                                                            Так мы и говорили про простые случаи. Если случаи не простые, то это задача для сениора. Он выполнит ее быстрее и надежнее.

                                                                                                                            упрется в окупаемость
                                                                                                                            т.е. ваш аргумент в том что джун это не только ценный мех, но еще и бесплатная машинистка?
                                                                                                                            Спорить не буду, но что-то мне подсказывает что профессиональная машинистка будет быстрее и дешевле.
                                                                                                                  –7
                                                                                                                  Граница между сеньорами и джунами весьма расплывчат — внезапно.

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

                                                                                                                  Проблема оферквалифаед никуда не девалась. Сеньор, выполняющий джуновские задачи — печальное зрелище.

                                                                                                                  Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?
                                                                                                                    +5
                                                                                                                    Сеньор не всегда кодит лучше, чем джун. Особенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка. Я конечно рад, что он до черта умный, но как потом это все читать?

                                                                                                                    По-моему, таким страдают именно джуны.

                                                                                                                      0
                                                                                                                      >> собенно фанат оптимизированных побитовых операций, колбэков и редко используемых особенностей языка.

                                                                                                                      Это не сеньор, ИМХО. В моем понимании, сеньору можно дать задачу и быть уверенным, что он ее сделает так как нужно компании. Отсутствие перерасхода времени на оверинжениринг в это «как нужно» тоже входит.

                                                                                                                      >> Сеньор, выполняющий джуновские задачи — печальное зрелище.
                                                                                                                      Согласен. Но не в плане «лучше кодит». Тут, скорее, два момента. Первое, на задачах, где производительность упирается в скорость печати, он невыгоден. Второе, он может затосковать и потратить даже больше времени, чем джун.
                                                                                                                        +1
                                                                                                                        Сеньору неинтересно в какой то момент становится, он начинает извращаться. И не докопаешься: например у нас он нормализовал базу по последнему уровню, так что она становится абсолютно нечеловекочитаема и непонятно никому кроме него. Да любой сеньор замучится собирать юзера по 8 таблицам, а там отмазка надо лучше учиться, база нормализована по правилам.
                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                          0
                                                                                                                          Первое, на задачах, где производительность упирается в скорость печати, он невыгоден.

                                                                                                                          Простите, а что это за задачи такие? Я всегда считал рабочим правило про «80% времени разработчик читает». И прочитать и понять, где нужны изменения сениор сможет сильно быстрее, нет? Хотя в с этим и не спорили, вы говорили на задачах, где скорость печати важна. Так что собственно повторюсь: это где такие задачи бывают?
                                                                                                                            0
                                                                                                                            Тупые «обезьяньи» задачи типа «сделать тут так же, как там, но только поменять это и это». Или даже просто «поменять это на то». В веб-разработке этого навалом. В таких задачах нечего читать и не о чем думать.
                                                                                                                              +1
                                                                                                                              Ну почему же, можно вынести компонент/пакет/… Копипаста ведь это не единственный способ решения задач.
                                                                                                                                0
                                                                                                                                Можно, но только если понятно, что работать над проектом еще долго, а именно таких задач будет еще много. И, я чуть ниже приводил пример, если это какой-нибудь класс, представляющий конкретную форму, то это и так практически будет конфиг, только записанный на исполняемом языке. Список полей, их типы, функция валидации. Оттуда уже нечего выносить. Понятно, что когда есть десятки почти одинаковых форм, и притом в одном и том же проекте, можно что-то придумать, но когда их две и первый раз за год понадобилось добавить третью, при том что половина полей в них отличается… оно того не стоит.

                                                                                                                                Если проектов много, в режиме сделали-сдали-забыли, то версии компонента в них будут разные. Допустим в старом проекте нужно внести маленькую правку и снова на год про него забыть. Можно обновить версию компонента, тогда правка применится автоматически, но сломается что-то другое (ну например, понадобилась функция валидации ИНН, в новой библиотеке она есть, а в старой — нет, зато в новой несколько функций переименовано, несколько добавлено, и у нескольких поменялся интерфейс). В итоге вынос ничего не дал, а сделать «правильно» выходит сильно дороже.
                                                                                                                                  +1
                                                                                                                                  Можно, но только если понятно, что работать над проектом еще долго, а именно таких задач будет еще много. И, я чуть ниже приводил пример, если это какой-нибудь класс, представляющий конкретную форму, то это и так практически будет конфиг, только записанный на исполняемом языке. Список полей, их типы, функция валидации. Оттуда уже нечего выносить. Понятно, что когда есть десятки почти одинаковых форм, и притом в одном и том же проекте, можно что-то придумать, но когда их две и первый раз за год понадобилось добавить третью, при том что половина полей в них отличается… оно того не стоит.

                                                                                                                                  У меня одна из первых задач на первой работе состяла в том, чтобы написать две сотни однотипных конфигов (ну, не совсем однотипных). На задачу дали месяц. Месяц я потратил на написание генератора этих конфигов (парсинг powershell-скрипта, определение структуры конфига, и собственно генерация). После чего за 2 часа сделал все эти конфиги. В последующем, этот генератор мне не раз пригождался, и задача на день-два решалась за 15 минут.

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

                                                                                                                                  Если проектов много, в режиме сделали-сдали-забыли

                                                                                                                                  Звучит очень печально.

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

                                                                                                                                  Ага, и потом регрессия, потому что баги чинят в одних компонентах, а скопипащенные куски продолжают жить со своими багами, где их уже никто не починит, «дорого, да и сдали проект уже».
                                                                                                                        +4

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

                                                                                                                          0
                                                                                                                          Самые большие, умные и дальновидные берут не то что джунов, но и вообще интернов со студенческой скамьи
                                                                                                                            +1
                                                                                                                            Ключевое слово здесь: «большие». На это нужны деньги, которые могут и не вернуться, а польза сильно неочевидна. Даже средние компании не всегда могут себе позволить и почти всегда могут найти области где эти деньги дадут больший выхлоп.
                                                                                                                              0
                                                                                                                              Около 100 человек из которых программистов хорошо если треть. Процентов 60 сотрудников были взяты стажерами (даже джунами назвать трудно многих было). Просто в провинции выбора особого нет.
                                                                                                                                0
                                                                                                                                Если нет выбора, то это не дальновидность и ум, а безысходность все же. Оно конечно не отрицает одно другого, но если убрать положительные качества то ситуация останется той же, а вот если убрать безысходность и предположить ситуацию когда выбор есть — я думаю такая компания взяла бы гораздо меньше студентов. Которые из этой провинции еще и сбегут большей частью когда опыта наберутся.
                                                                                                                          +9
                                                                                                                          Во многом согласен. Де факто мы сталкиваемся с тем, что экономия денег сейчас, вырождается в последующие траты потом. Т.к. текучка не исключена, например. На мой взгляд, думать и делать на перспективу разучились почти все.

                                                                                                                          От себя могу добавить, что когда я был «джуном», меня никто также не хотел брать. Хотя я очень быстро обучался любой под-отрасли IT. Поэтому приходилось «шляться» по «помойкам». И через пару тройку лет, меня звали те компании, которые не так давно отказывали. Это порождает ненависть к ним. Ну и соответственно, работая на них, отношение к ним такое же. Я не буду думать о благе компании, я буду думать о своем благе поплевывая на их благо. И даже злонамеренно. Ну хотя бы потому, что я их ненавижу.

                                                                                                                          Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан. Это тоже правда. Возмущает сам факт циничности. Что только когда им надо. И дело не в том что мне должны. Дело в том, что им все должны.

                                                                                                                          Я и сейчас с этим сталкиваюсь, почему то я постоянно что-то должен. Я уже не говорю о том что отпуск в 2 недели, это не отпуск. 2 недели — это отходняк. И только потом ты начинаешь отдыхать. А объясняется это тем, что компании не выгодно…
                                                                                                                            +1
                                                                                                                            Некоторые могут сказать мне, что никто мне ничем не обязан. Это правда. Но и я им не обязан.

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

                                                                                                                              Назовите мне хотя бы одного добросовестного работника, который делал строго в соответствии с договором.

                                                                                                                              И не надо путать договор с текучкой. На практике, все не по договору.

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

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


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

                                                                                                                                  +1
                                                                                                                                  Вы описываете подход работника, который делает работу на «отвяжись». Если конечно деятельность у вас не творческая. Мешки таскать, нормальный подход.

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

                                                                                                                                  Причем тут сила воли и отказ?
                                                                                                                                    0

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


                                                                                                                                    Не понимаю каким боком это имеет отношение к качеству работы

                                                                                                                                      0
                                                                                                                                      Если у вас вся компания держится на «эх ребятушки, затянем пояса» и «ну что ты, ради проекта без выходных не поработаешь», то это проблема компании, нет?

                                                                                                                                      Это вообще о чем и причем?

                                                                                                                                      Не понимаю каким боком это имеет отношение к качеству работы

                                                                                                                                      Прямое. Объяснять надо? Лично я, судя по утверждению, не вижу смысла.

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

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

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

                                                                                                                                      Вам что так трудно понять, что лично мне хочется строить отношения не только на деньгах? И я не единственный в этом списке. Таких людей много.
                                                                                                                                        0

                                                                                                                                        Возможно мы вообще друг друга не поняли?


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


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

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

                                                                                                                                          Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной. Если занять такую позицию.

                                                                                                                                          Вот и скажите мне, чем мне договора помогут? Разве что у них нет законных оснований меня уволить. И все. Но цель которую я преследую, достигнута не будет. Я не боюсь потерять работу. Я боюсь её не закончить. Это важнее чем начать.

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

                                                                                                                                            Так ведь и получается, что это ваш выбор — терпеть неудобства. Непонятно тогда к чему ваше недовольство


                                                                                                                                            Получилось так, что компанию интересует быстро выпустить, сложность никто в расчет принимать не хочет. Говорить об этом без толку. Все равно будет постоянное давление. Это надо воспринимать как условие решения задачи. Если я встану в позу, то это просто отменят. Я с подобным сталкивался уже. И комично то, что она в принципе не будет сделана. Не только мной

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

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

                                                                                                                                              То что они потом этим пользуются у вас это возмущения не вызывает?
                                                                                                                                              Они все понимают. Чего оно стоило. Можно хотя бы не хамить?

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

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

                                                                                                                                                Я все пытаюсь у вас выяснить, кто (или что) вынуждает вас это терпеть? У меня складывается ощущение, что вы слишком привязались к своему проекту и поэтому согласны на любые запросы начальства.


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

                                                                                                                                                Зачем поддавались?

                                                                                                                                                  0
                                                                                                                                                  Я все пытаюсь у вас выяснить, кто (или что) вынуждает вас это терпеть?

                                                                                                                                                  Я уже отвечал. Меня интересует сложная задача.

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

                                                                                                                                                  Это 4й сложный проект(мелочи считать не будем), который я выполняю. Начат он сравнительно недавно.

                                                                                                                                                  Зачем поддавались?

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

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

                                                                                                                                          Нередко бывает, что компании просто не замечают быстрый рост сотрудников и не повышают соответственно зарплату, особенно, если там не занимаются ростом сотрудников, или занимаются формально (а ля мы внедрили ревью, а насколько оно адекватно и есть ли реальный фидбек — не волнует). Тогда помогает смена места работы.
                                                                                                                                            0
                                                                                                                                            Вы знаете, работодатель может уволить любого. Если он того захочет. Это к слову о договорах. Как я уже утверждал, договоры не стоят ничего. Потому что их нарушают все стороны. Это практика.
                                                                                                                                              0
                                                                                                                                              У нас тут была история, как человеку 6 окладов выплатили, чтобы он согласился «по собственному» написать.

                                                                                                                                              При нормальном трудоустройстве и соблюдении договора увольнение нифига не тривиально.