Comments 240
Один вопрос автору — сеньор будет в восторге от того что 80% своего времени будет круды писать? И стоит ли за эти круды платить по 40-50 баксов в час?
А если в компании нет таких задач?
Таких компаний крайне мало. Я думаю даже в Америке таких не большинство. В том же Гугле тысячи работников, думаешь они все решают сложные задачи? Большинство те же круды пишет. Читал как то статью чувака, который поработал там
В том же Гугле тысячи работников, думаешь они все решают сложные задачи?
Гуглевские джуны != обычным джунам.
Есть же статьи на Хабре от тех, кто там работал. Даже младшие программисты Гугля — это далеко не каждая компания таких сеньоров может себе позволить/не каждая компания нуждается в таких слишком over-квалифицированных сеньорах.
Это неправда. Полно джунов только после универа. Не глупые, конечно, но и не мега-кодеры и уж тем более не сеньоры.
Джуны гугла знают, как умножать матрицы? Могут написать обход графа в ширину и в глубину? Имеют представление о системах управления версиями? Имеют базовые знания о протоколе HTTP, чтобы записать простой запрос и простой ответ?
Если всё это — да, то
Если всё это — да, то
Гуглевские джуны != обычным джунам
Я все это знал устраиваясь джуном в местную контору на 3-м курсе. Вроде как это базовые вещи, которым учат в универе.
Одно дело, учат, а другое дело — научили.
Не глупые, конечно, но и не мега-кодеры и уж тем более не сеньоры.
В иных фирмах сеньорами называют 23-летних, как раз с двумя годами опыта (что, в самом лучшем случае, имхо, крепкий джун или начинающий миддл) после ВУЗа, не мега-кодеров, в Гугль бы собеседование не прошли.
Но они вполне себе «сеньоры».
по моему опыту — в любой компании всегда есть пакет задач, в которых нужно поправить запятую, поменять цвет кнопки, исправить опечатки
как минимум один джун мог бы на этом сидеть, пока старшие решают хорошие проблемы
Ну и можно давать джуну время от времени настоящие задачи — чтобы рос
как минимум один джун мог бы на этом сидеть, пока старшие решают хорошие проблемы
Ну и можно давать джуну время от времени настоящие задачи — чтобы рос
По моему опыту, как раз в таких задачах, сеньоры и лиды показывают очень высокий перфоманс (когда не ленятся). Потому, что исправить сам цвет — 2 секунды. Найти это место в коде — до 30 секунд для сеньора и до часа для джуна.
Для джуна это какое-никакое изучение проекта/инструментов, а для сеньора может оказаться еще одной унылой задачей, непосредственно сделать которую быстрее чем уйдет времени на около-задачную бюрократию.
Для джуна это какое-никакое изучение проекта/инструментов
Несомненно, для джуна в +. Проблема в том, что если в проекте подразумеваются джуны, то и уровень абстракций закладывается низкий (надо же, чтобы джуны потом сами разобрались без ежеминутных отвлеканий ментора), и сложность инфраструктуры необходимо изолировать. То есть, и синиоры в пол силы работают. А когда их нет априори, то все эти ограничени снимаются.
чем уйдет времени на около-задачную бюрократию
Так может проблема в ней?
Хм, знаете, я замечаю такую интересную вещь — чем сильнее программист, тем более понятный его код.
Так как в реальности действительно сложные в реализации штуки встречаются все таки не так часто, то весь остальной код, если он нормально написан, понимается даже непрограммистами в виде специалистов из смежных областей. Джунов в эти сложные штуки пускать не будут, а с остальным, при условии нормальных синьоров, не должно быть для них проблемой.
И причем тут уровень абстракции?
Так как в реальности действительно сложные в реализации штуки встречаются все таки не так часто, то весь остальной код, если он нормально написан, понимается даже непрограммистами в виде специалистов из смежных областей. Джунов в эти сложные штуки пускать не будут, а с остальным, при условии нормальных синьоров, не должно быть для них проблемой.
И причем тут уровень абстракции?
Хм, знаете, я замечаю такую интересную вещь — чем сильнее программист, тем более понятный его код.
К сожалению, это правило работает не всегда. Например, далеко не всякий код на C# с активным использованием Reflection (и особенно Reflection.Emit) будет понятен с ходу, даже если его написал крутой специалист.
Уровень абстракций как раз для джунов нужен высокий. Грубо, сеньоры пишут в машкодах, а джуны юзают fopen(). Сеньоры пишут ORM, а джуны объектики создают и только в теории знают, что в проекте есть и база данных.
По моему опыту — это зависит от времени, потраченного на изучении проекта. Сам пришел джуном, сначала искал долго, через 2 недели познакомился с очень удобными штуками в IDE и понял структуру проекта, после чего у меня весь поиск свелся к минимуму.
В 21 веке у вас есть кодогенерация и рефлексия, что бы круды писали сами себя, а вы только создавали модели и регистрировали ее.
Если у вас 80% времени нужно писать круды — вряд ли ваша компания может назвать себя высокотехнологичной.
Если у вас 80% времени нужно писать круды — вряд ли ваша компания может назвать себя высокотехнологичной.
Истинный Сеньор!)) Там где можно за неделю написать круд, он за месяц напишет рефлексивный кодогенератор круда, или вы просто спринг дату имели ввиду?
Зависит от того, что вы используете. У большинства популярных фреймворков уже есть библиотеки для быстрой имплементации crud.
Если же нет, то таки да, взял бы и написал. И вместо четырех месяцов был бы один. Вы же не пишете crud один раз и навсегда, обычно сущности потом добавляются.
Ну и месяц это как то дофига, правда.
Если же нет, то таки да, взял бы и написал. И вместо четырех месяцов был бы один. Вы же не пишете crud один раз и навсегда, обычно сущности потом добавляются.
Ну и месяц это как то дофига, правда.
Ой, извините я про JAVA пишу, не думая, что есть другие ЯП, которые не обязаны знать наши библиотечки.
я не очень понимаю, что такое писать круд вообще, для меня это написать один родительский дженерик класс, который реализует 4 метода. Что имеет ввиду автор не до конца понятно, но он наверно имеет ввиду написание любого бойлерплейт кода))
я не очень понимаю, что такое писать круд вообще, для меня это написать один родительский дженерик класс, который реализует 4 метода. Что имеет ввиду автор не до конца понятно, но он наверно имеет ввиду написание любого бойлерплейт кода))
Хороший сеньор, написав 5 крудов, сделает генератор крудов, и после этого их будет писать БА. Либо этот же сеньор, но со скоростью 5 крудов в минуту. И чтобы достичь такой же производительности, надо ну очень много джунов + представьте себе каскадные изменения в таком копипастном коде.
Согласен с тезисами статьи. Не согласен с подачей.
Автор про истинно технологичную фирму, где каждая задача — это челлендж для сеньора, а формочки и круды сами пояляются.
Вообще, удел джуниоров — кодить сложно, сеньор должен кодить просто, чтоб любой джун понял. Поэтому, если джун не может разобраться в Вашем коде, подумайте, а сеньор ли Вы, а не гуано ли ваша архитектура, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.
Вообще, удел джуниоров — кодить сложно, сеньор должен кодить просто, чтоб любой джун понял. Поэтому, если джун не может разобраться в Вашем коде, подумайте, а сеньор ли Вы, а не гуано ли ваша архитектура, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.
getUserById, проходит через 100 классов, прежде, чем добраться до базы.
О, выглядит как кишки андроида. Там считается нормой вложенность в 100 классов.
Вы не правы. Если джун не знает про, к примеру, Observer, то ему любая реализация этого великолепного паттерна покажется гуаном в плане архитектуры, ведь можно и проще сделать — раз. Чтобы написать большой и сложный продукт, нужно использовать стратегические и сложные решения — два. Особенно, если компания высокотехнологична и, что называется, living on the edge, работая с тем, для чего еще не существует best practices.
Это да. По факту, именно джуны создают решения, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.
Про это — вывернутую логику — и автор этой статьи писал. Если джун не может разобраться в моем коде, то это далеко не означает, что моя архитектура плоха. Но это уже значит, что джун не понял. Что ж, ок, я подумал, и пришел к выводу, что я-таки сеньор, а джун по-прежнему не понимает мой код, мои действия?
удел джуниоров — кодить сложно
Это да. По факту, именно джуны создают решения, где какой-нить чертов getUserById, проходит через 100 классов, прежде, чем добраться до базы.
Поэтому, если джун не может разобраться в Вашем коде, подумайте, а сеньор ли Вы
Про это — вывернутую логику — и автор этой статьи писал. Если джун не может разобраться в моем коде, то это далеко не означает, что моя архитектура плоха. Но это уже значит, что джун не понял. Что ж, ок, я подумал, и пришел к выводу, что я-таки сеньор, а джун по-прежнему не понимает мой код, мои действия?
Джуны по определению не так хороши, они в начале становления себя как специалиста, но это не повод не нанимать их…
Мне вот интересно, это такой шаблон мышления только в странах СНГ что ли…
А вы статью-то прочитали? Там конкретные примеры даже есть.
Статья статьей, но ведь и тот кто писал статью, да все были в свое время джунами в своей области и ведь их наняли где-то и кто-то, почему теперь такое отношение? Это мне напоминает покорителей дефолт-сити, которые через год себя считают себя коренными жителями и имеют высокомерное отношение к жителям провинции.
Статья статьей, но ведь и тот кто писал статью, да все были в свое время джунами в своей области и ведь их наняли где-то и кто-то, почему теперь такое отношение?
Когда то их наняли не из благотворительности, чтобы они могли научиться и стать потом специалистами.
А чтобы компания могла денег заработать.
Если же совсем другая компания работает по другой экономической модели и в ее модели не нужно экономить на программистах, нанимая джунов — то почему нет…
> да все были в свое время джунами в своей области
Ну как… Я, например, первой работой программистом пошел на мидла. Почему люди в институте балду гоняют, что бы потом пойтиждуном(но какая описка) джуном и 2 года круды писать — не знаю. Какой опыт им эти круды принесут — тоже не знаю.
Ну как… Я, например, первой работой программистом пошел на мидла. Почему люди в институте балду гоняют, что бы потом пойти
При чем тут СНГ вообще?
Если, например, частная клиника будет нанимать только лучших врачей, вам жe нe покажется это странным? Скорее всего именно в эту клинику вы захотите обратиться если надо будет, а не в ту где врачи интерны учатся на вас и пробуют новые подходы к лечению.
Если, например, частная клиника будет нанимать только лучших врачей, вам жe нe покажется это странным? Скорее всего именно в эту клинику вы захотите обратиться если надо будет, а не в ту где врачи интерны учатся на вас и пробуют новые подходы к лечению.
А откуда эти лучшие врачи возьмутся, если их в интернатуру брать не будут?
Ну, где-нибудь, сами, на pet-project'ах научатся.
если их в интернатуру брать не будут
Я говорил про одну конкретную частную клинику. Пускай учатся там где берут интернов.
Моя мысль не в том что джунов не надо нанимать, а о том что не стоит судить компании со своей колокольни.
Сейчас я работаю в компании которая нанимает джунов и интернов — и все ОК, до этого работал в компании в которой были только синиоры и выше — и тоже все было ОК. Никаких негативных вещей из статьи вроде токсичной кутьтуры, невозможности ошибаться и т.п. Просто не было задач для младших разработчиков и не было времени их выращивать.
А откуда эти лучшие врачи возьмутся, если их в интернатуру брать не будут?
А че, где-то кто-то написал, что теперь «принципиально во всех до единой больницах не будут брать интернов без опыта»
Одна-единственная фирма, которая может себе позволить не иметь дела с неспециалистами — не берет не специалистов. Специалистов для нее готовят другие компании.
Больниц и фирм ИТ-шных много.
Где подготовиться джунам/интернам — проблемы нет никакой.
Да, я понимаю, всем нам бы хотелось начинать карьеру с Google/Netflix/Microsoft. Но это не обязательно. Гораздо проще — и реалистичнее — поступить сначала на работу в фирму попроще, набраться опыта. После чего вас возьмут в «бодишоп» уже с желанием, после него — уже можно попытать счастия в высокотехнологичной компании, ну а уж потом — Netflix, Google…
Начните уже с районной поликлиники (ну или что там у врачей считается аналогом мелкой фирмочки по клепанию веб-сайтиков)
Одна-единственная фирма, которая может себе позволить не иметь дела с неспециалистами — не берет не специалистов. Специалистов для нее готовят другие компании.
Больниц и фирм ИТ-шных много.
Где подготовиться джунам/интернам — проблемы нет никакой.
Проблема в том, что в пределе всем выгодно не готовить специалистов, а получать их падающими с неба.
Не знаю почему минусанули коммент MacIn, по сути он прав. Не многие компании согласны тратиться на обучение сотрудников, а с программистами такое не прокатит. Наблюдал в других отраслях проблему передачи знаний, в машиностроении и строительстве. Когда старые специалисты ушли на пенсию, а на их место никто не пришел. И свои знания они унесли с собой, так никому не передав их. Конечно, программирование остаётся молодой, востребованной отраслью и такое пока не грозит. Но раз взялись за пример из медицины, то сейчас там происходит подобное, что было в инженерных науках 25 лет назад. Из-за оптимизаций медицинский персонал, который занимается лечением сокращается, а административный увеличивается в разы. Талантливые врачи вместо лечения больных занимаются пластической хирургией в косметологических клиниках. Ну и для диагностирования и лечения ОРЗ вам не нужен светила мировой медицины, достаточен толковый терапевт. Надеюсь я правильно донёс свою мысль для читателей (если что, сильно не бейте).
Но не у всех есть на это деньги) джунов чаще нанимают не кто кто растят специалистов, а те у кого денег только на них и хватает.
Вот только в этом пределе падать они не будут. И компании, которые начнут испытывать проблемы с кадрами и правильно поймут причины, изменят политику.
Проблема в том, что в пределе всем выгодно не готовить специалистов, а получать их падающими с неба.
Никакие это не проблемы.
Реальная жизнь расставляет все по своим местам. И мечты работодателей испаряются тоже. Но Netflix может себе позволить.
Это не благотворительность, это отложенная прибыль, специалист вырастает и начинает работать лучше, принося бОльшую прибыль, но хочетсяя прям здесь и сейчас, а это как раз менеджерская фича, определенному менеджеру хочется скорее доложить руководству, что работа сделана, чтобы получить свои плюшки, хотя если взять разработку в Нидерландах, то насколько я слышал там нет такой гонки, делается упор на качество, а не на скорость.
Или специалист вырастет и уйдёт к конкурентам, которые смогут предложить немного больше за счёт того, что не платят джунам и не тратят время сеньоров на них.
Ну так надо заботиться о своих специалистах и тогда мысль уйти у них не будет возникать
У компании, которая не растит специалистов, больше материальных возможностей заботиться о специалистах при прочих равных. Грубо, при ФОТ на разработку в 100 000, одна компания может предложить 20 сеньорам по 5 000, а другая только по 4000, потому что ещё 20 джунов по 1000. Можно рассчитывать, что джуны варостут, будут получать по 4000 и отказываться получать 5000 из чувства благодарности, но несколько наивно это, по-моему.
Ну собственно говоря, при подборе людей, стоит обращать внимание не только на «джун/сеньор», есть ещё другие критерии.
Спасибо за разбор переведённой мною статьи! Статья была переведена из-за интереса к теме, и в комментариях и вашем разборе нашлось много пищи для ума.
Каеф наверное писать статьи, выдирая куски из чужого материала и оставляя никому не интересные, свои собственные комментарии.
Автор, если твой подход к написанию — это паразитированние на чужих работах, а все твое мысленное усилие было приложено лишь к плевкам вида «комментарий: », то пожалуйста, не пиши ничего больше.
Автор, если твой подход к написанию — это паразитированние на чужих работах, а все твое мысленное усилие было приложено лишь к плевкам вида «комментарий: », то пожалуйста, не пиши ничего больше.
Каждый автор старается где-нибудь кого-нибудь зацепить, что бы было большое обсуждение.
Напоминает редакцию AdMe в лучшие его годы — так и вижу кучу авторов бегающих за рейтинговыми постами и только и думающие «чего бы теперь написать»
Вместо авторов, которые хотят донести своё другим — авторы, которые сидят на зарплате и просто пытаются заработать себе на жизнь.
Что же получается, если автор хочет высказаться на больную для сообщества тему (а т.к. он является участником сообщества, то скорее всего для него это тоже больная тема), то он «сидит на зарплате» и «гонится за рейтинговыми постами»? То есть никакой рефлексивности у сообщества нет, все гоняются за рейтингами, так что ли?
У качества статей есть отпечаток на карме. Посмотрите на эти два профиля:
Ализару поставили больше трех тысяч оценок, но почти половину из них — в минус. Он выезжает на желтизне.
А у Нулевого Пациента всего семьсот оценок, зато все в плюс. Он переводит технические статьи.
Это мой юзерскрипт — https://greasyfork.org/ru/scripts/368828-habr-features
А откуда вообще дробная карма берется? В правилах об этом вроде ничего нет.
Вычитал где-то в комментариях, могу ошибаться:
- Если повысил карму или сделал приглашение юзеру, которого потом его забанили, то снимают 0.1 или 0.5 кармы.
- Если два юзера повышают друг другу карму, то с них снимают по 0.1 кармы.
- Раньше была некая "сила голоса", когда в зависимости от достижений твои голоса считались больше единицы.
- Был баг в api хабра, когда можно было было поставить любое дробное число как свой голос, а не только +1 или -1.
Когда ты тупо эксплуатируешь устаревающую технологию — нужны сеньоры, знающие её от и до.
Когда ты хочешь содрать бабло, обманув инвестора демонстрацией умных, у которых на любой вопрос ответ отлетает от зубов — нужны сеньоры.
Но, если ты заботишься о будущем компании — джунов набирать необходимо, и сразу группами! Пусть сеньоры продолжают «писать фортрановские программы на любом языке », это обеспечит текущую работу. А новые технологии джуны освоят гораздо быстрее и лучше, потому что примут их как данное, без ломки себя.
Когда ты хочешь содрать бабло, обманув инвестора демонстрацией умных, у которых на любой вопрос ответ отлетает от зубов — нужны сеньоры.
Но, если ты заботишься о будущем компании — джунов набирать необходимо, и сразу группами! Пусть сеньоры продолжают «писать фортрановские программы на любом языке », это обеспечит текущую работу. А новые технологии джуны освоят гораздо быстрее и лучше, потому что примут их как данное, без ломки себя.
Как вы думаете, кто придумывает новые технологии? Джуны или сеньоры? Кто делает компиляторы на новые языки, джуны или сеньоры?
Молодые сеньоры, вчерашние джуны — по большинству, подавляющему большинству.
И я думаю, Вам очень сильно повезло, если Вам встречались по преимуществу конторы, создающие новые компиляторы, а не использующие их.
Хм, посмотрел Ваш же коммент чуть ниже — Вы там подтверждаете мои слова, по сути.
Мне вот, кстати, повезло. Моя контора и конкретно мой отдел как раз создаёт новые технологии. И у их потребителей (приобретателей наших продуктов) очень характерная картина: там, где сеньора ставят на освоение, мы обречены месяцами выслушивать, как всё неправильно сделано и почему всё не заработает никогда. А там, где джуны — через короткое время уже идёт использование и профит. После чего джуна срочно повышают, и не дай бог, если его место займёт вытесненный вчерашним джуном сеньор :-)
И я думаю, Вам очень сильно повезло, если Вам встречались по преимуществу конторы, создающие новые компиляторы, а не использующие их.
Хм, посмотрел Ваш же коммент чуть ниже — Вы там подтверждаете мои слова, по сути.
Мне вот, кстати, повезло. Моя контора и конкретно мой отдел как раз создаёт новые технологии. И у их потребителей (приобретателей наших продуктов) очень характерная картина: там, где сеньора ставят на освоение, мы обречены месяцами выслушивать, как всё неправильно сделано и почему всё не заработает никогда. А там, где джуны — через короткое время уже идёт использование и профит. После чего джуна срочно повышают, и не дай бог, если его место займёт вытесненный вчерашним джуном сеньор :-)
И это херовая схема. Это не джун быстро станет сеньером. Это он станет тимлидом в лучшем случае. Задача лида — натягивать тех специалистов на бизнес задачи. Задача сеньера — сделать хорошо и с умом и на перспективу. В споре этих двух противоположностей рождаются годные продукты.
А джуны, нашлепавшие говнокод в продакшен лишь бы поскорее заработало, это просто сюр. Это вы глупость путаете с тонким расчетом.
Вы несколько смешиваете пары джун/сеньор aka новичок/опытный и тупой/умный. «Тупой» (очень условно!) вполне может быть сеньором, если его хватает на то, чтобы сосредоточиться в узкой области. Тогда он может быть вполне успешен, успешнее многих умных с проблемой концентрации. Но ничего вне уже освоенноей технологии он не тянет. Таких сеньоров, на самом деле — подавляющее большинство. Я уже 40 лет программляю, насмотрелся.
А джуны принимают новую технологию, как просто часть окружающего мира, они ничего другого не пробовали, и не знают, как трудно эту новую технологию постичь. Потому и справляются, практически все, что умные, что тупые.
Научить их делать приличный код — совершенно параллельная, не пересекающаяся, задача. И говнокод, и изюминка — могут быть и в старой, и в новой технологиях. Но фокус в том, что старая технология, даже изумительно реализованная — не нужна. И потому-то не нужными становится большинство сеньоров. Другое дело, что сеньоры умеют очень хорошо защищать свои позиции, затаптывая джунов.
Обычные проблемы, приведшие, кстати, в природе к появлению механизма старения, насильственно устраняющего сеньоров из эволюционного процесса.
А джуны принимают новую технологию, как просто часть окружающего мира, они ничего другого не пробовали, и не знают, как трудно эту новую технологию постичь. Потому и справляются, практически все, что умные, что тупые.
Научить их делать приличный код — совершенно параллельная, не пересекающаяся, задача. И говнокод, и изюминка — могут быть и в старой, и в новой технологиях. Но фокус в том, что старая технология, даже изумительно реализованная — не нужна. И потому-то не нужными становится большинство сеньоров. Другое дело, что сеньоры умеют очень хорошо защищать свои позиции, затаптывая джунов.
Обычные проблемы, приведшие, кстати, в природе к появлению механизма старения, насильственно устраняющего сеньоров из эволюционного процесса.
старая технология, даже изумительно реализованная — не нужна.Почему? Мешает вам пилить бюджет?
На самом деле, не нужна большая часть новых технологий — они придуманы лишь для распила денег. Значительных преимуществ они не дают, зато недостатков — куча.
Ну как хрестоматийный пример — BGA. Достоинства — компактность, большое число выводов. Недостатки -совсем иное оборудование для изготовления и ремонта плат, обязательная многослойность платы, то есть невозможность ручного исправления ошибок разводки… Дикая компактность нам не нужна — на тракторах и ледоколах места хватает, даже для беспилотников без BGA уложились в полпачки сигарет. Большое число выводов — ну так себе преимущество, нам пока и без BGA хватает. Зато без BGA быстрый цикл выпуска и модернизации платы. И даже первые экземпляры, с наляпанными проводочками и разрезанными дорожками — вполне пашут.
Да-да, именно потому специалисты по изготовлению каменных рубил до сих пор настолько в цене.
Серьёзно: области, где нет нужды скакать по технологиям — есть, и они вполне многочисленны. Ну так да, там сплошь сеньоры и сидят.
Я — о другом, когда новая технология требуется. В этом случае коллектив, группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры. Ну да, к концу процесса они джунами быть перестают :-), но начинать нужно именно с таких.
Серьёзно: области, где нет нужды скакать по технологиям — есть, и они вполне многочисленны. Ну так да, там сплошь сеньоры и сидят.
Я — о другом, когда новая технология требуется. В этом случае коллектив, группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры. Ну да, к концу процесса они джунами быть перестают :-), но начинать нужно именно с таких.
Я — о другом, когда новая технология требуется.Это огромная редкость. Обычно новые технологии — это попытка возложить свои затраты на тестирование и апробацию на другие фирмы. То есть придумывается технология, разводится хайп и куча глупых джуниоров начинают на своем опыте ощупывать границы её применимости.
группа джунов, брошенная на её освоение и применение, срабатывает в конце-концов гораздо эффективнее, чем сеньоры.А выгоду получит тот сеньор, который новую технологию придумал. Потому что шишки будут набивать джуны из чужой компании.
Рубила принципиально не меняются уже хреновы тыщи лет. Переход на качественно новые материалы пару раз был — можно считать мажорными релизами, и рубилами версии 3.0 мы пользуемся лет шестьсот. И таких областей — подавляющее большинство, и считать стартапы духа «а давайте встроим в топор блокчейн и сделаем рукоятку из перфорированного углеволокна» чем-то кроме попила бюджета что-то не выходит.
просуммировав, делаю два выводы:
1. Писатели комментов сплошь считают себя сеньорами и хором защищают позицию. Ожидаемо :-)
2. Деление джун/сеньор [в том числе по причине пункта 1] проводят по «тупой автор говнокода» и «высоколобый крылатый ангел». Что показывает очевидно узкий взгляд (не сеньоровский) и приверженность простеньким приложениям массового веба.
Как «лид» по принятой тут терминологии, и достаточно успешный (в нашей области наши продукты безусловно лидируют в России, применяются в нескольких странах, включая США, причём в США шире всего после России), скажу: говнокод вообще не проблема программиста — это проблема команды. Говнокода не бывает вообще — при правильно организованной работе с ревизией кода и выстроенным взаимодействием. Разница между разработчиками пролегает во времени поиска решений в тех местах, где нужно решения принимать. Сеньор находит их легко, джун — бьётся долго и решения хуже. Но и это соотношение действует в рамках уже принятого направления. Когда же начинается совершенно новое направление — я формирую под него именно группу джунов. Группа довольно быстро сортируется, в ней выделяются сеньоры… и пошла работа по направлению. Для последующего развития уже ставшей на ноги работы действительно нужны сеньоры — но они и появились преимущественно из той самой группы.
Соглашусь, что такой подход работает, когда компания развивается. Если она [вполне успешно] жуёт какое-то одно направление работ, то уже существующих сеньоров нужно куда-то девать, это, кстати, проблема.
Ну и напоследок — терминология просто недостаточна. Настоящий сеньор сам вырабатывает новое направление и предлагает его либо своей, либо другой компании. Вот таких — безусловно нужно брать в первую очередь, если, конечно, компания способна потянуть предложенное. Но таких людей всё же единицы, в довольно-таки массовое понятие «сеньоров» они не вмещаются.
1. Писатели комментов сплошь считают себя сеньорами и хором защищают позицию. Ожидаемо :-)
2. Деление джун/сеньор [в том числе по причине пункта 1] проводят по «тупой автор говнокода» и «высоколобый крылатый ангел». Что показывает очевидно узкий взгляд (не сеньоровский) и приверженность простеньким приложениям массового веба.
Как «лид» по принятой тут терминологии, и достаточно успешный (в нашей области наши продукты безусловно лидируют в России, применяются в нескольких странах, включая США, причём в США шире всего после России), скажу: говнокод вообще не проблема программиста — это проблема команды. Говнокода не бывает вообще — при правильно организованной работе с ревизией кода и выстроенным взаимодействием. Разница между разработчиками пролегает во времени поиска решений в тех местах, где нужно решения принимать. Сеньор находит их легко, джун — бьётся долго и решения хуже. Но и это соотношение действует в рамках уже принятого направления. Когда же начинается совершенно новое направление — я формирую под него именно группу джунов. Группа довольно быстро сортируется, в ней выделяются сеньоры… и пошла работа по направлению. Для последующего развития уже ставшей на ноги работы действительно нужны сеньоры — но они и появились преимущественно из той самой группы.
Соглашусь, что такой подход работает, когда компания развивается. Если она [вполне успешно] жуёт какое-то одно направление работ, то уже существующих сеньоров нужно куда-то девать, это, кстати, проблема.
Ну и напоследок — терминология просто недостаточна. Настоящий сеньор сам вырабатывает новое направление и предлагает его либо своей, либо другой компании. Вот таких — безусловно нужно брать в первую очередь, если, конечно, компания способна потянуть предложенное. Но таких людей всё же единицы, в довольно-таки массовое понятие «сеньоров» они не вмещаются.
> Настоящий сеньор сам вырабатывает новое направление и предлагает его либо своей, либо другой компании.
Если речь о новых бизнес-направлениях, типа «а давайте из нашего сайта выделим движок и будем его продавать», то это уже точно не сеньор, а менеджер или даже предприниматель, случайно умеющий код писать. Сеньор решает бизнес-задачи техническими (обычно) методами, а вот постановки и продвижение новых бизнес-задач — это уже совсем другой вид деятельности.
Если речь о новых бизнес-направлениях, типа «а давайте из нашего сайта выделим движок и будем его продавать», то это уже точно не сеньор, а менеджер или даже предприниматель, случайно умеющий код писать. Сеньор решает бизнес-задачи техническими (обычно) методами, а вот постановки и продвижение новых бизнес-задач — это уже совсем другой вид деятельности.
> Писатели комментов сплошь считают себя сеньорами и хором защищают позицию. Ожидаемо :-)
Действительно, считаю, тут спорить не буду, но и позицию автора статьи защищать не буду, она порочна.
> Деление джун/сеньор [в том числе по причине пункта 1] проводят по «тупой автор говнокода» и «высоколобый крылатый ангел»
А вот этого я не говорил, не надо. Хватает и сеньорского говнокода (сам пишу иногда, каюсь), и высоколобых джунов. Разница в первую очередь в осознанности того, что ты делаешь, и, в меньшей степени, в глобальности задач, которые ты можешь успешно решить.
Если ты пятнадцать лет в отрасли, знаешь много умных слов и твой код работает, но дизайнишь ты его определённым образом не потому, что таковы условия, а потому, что умеешь только так — ты не сеньор; и, напротив, если ты можешь решить задачу с обоснованием, почему ты это делаешь так, а не иначе, и видишь альтернативные пути с их достоинствами и недостатками — ты не джун, даже если писать ты умеешь только псевдокодом и вчера пятый класс закончил.
И вот эти ваши джуны которые поднимают новое направление — совсем не джуны, если способны проявлять инициативу в решениях и вот это вот всё, равно как закостеневшие в древних технологиях сеньоры перестали ими быть в момент, когда перестали учиться.
Но общепринятая терминология всех этих нюансов не учитывает, тут абсолютно согласен.
Действительно, считаю, тут спорить не буду, но и позицию автора статьи защищать не буду, она порочна.
> Деление джун/сеньор [в том числе по причине пункта 1] проводят по «тупой автор говнокода» и «высоколобый крылатый ангел»
А вот этого я не говорил, не надо. Хватает и сеньорского говнокода (сам пишу иногда, каюсь), и высоколобых джунов. Разница в первую очередь в осознанности того, что ты делаешь, и, в меньшей степени, в глобальности задач, которые ты можешь успешно решить.
Если ты пятнадцать лет в отрасли, знаешь много умных слов и твой код работает, но дизайнишь ты его определённым образом не потому, что таковы условия, а потому, что умеешь только так — ты не сеньор; и, напротив, если ты можешь решить задачу с обоснованием, почему ты это делаешь так, а не иначе, и видишь альтернативные пути с их достоинствами и недостатками — ты не джун, даже если писать ты умеешь только псевдокодом и вчера пятый класс закончил.
И вот эти ваши джуны которые поднимают новое направление — совсем не джуны, если способны проявлять инициативу в решениях и вот это вот всё, равно как закостеневшие в древних технологиях сеньоры перестали ими быть в момент, когда перестали учиться.
Но общепринятая терминология всех этих нюансов не учитывает, тут абсолютно согласен.
C удовольствием отмечаю схождение позиций. Кроме одного пунктика: говнокод всё же — проблема руководителя группы и его косяк. Это страной можно руководить, перед этим поработав актёром или банщиком, а группой руководить — квалификация нужна. Сам, кстати, уже 15 лет не пишу ничего принципиально (для себя не в счёт, ессно), не верю в «играющих тренеров». Бывают, конечно, гении, но я не из тех. Когда пишешь сам — очень сильно желание спрятаться «вот, сейчас допишу и займусь группе работу выстраивать».
Вы так говорите, как будто компилятор — это что-то сложное. У меня у самого три написано (довольно простых, кстати). Компилятор — это лишь способ ускорить выполнение кода. Просто у джунов мысли не возникает, что можно самому написать компилятор.
К сожалению, джуны не отличают важное от неважного, а нужное от ненужного.
мы обречены месяцами выслушивать, как всё неправильно сделано и почему всё не заработает никогдаУгу, именно поэтому мы любим сеньоров. Помните туполевское "сломается здесь"? Так где джуниор через пару лет будет удивляться возникшим проблемам и ещё пару лет их расхлебывать — сеньор видит их с самого начала.
Моя контора и конкретно мой отдел как раз создаёт новые технологии.Так и мы тоже не старьем занимаемся (высокоточная спутниковая навигация). И джуны из числа заказчиков — достали. Куча лишней писанины, требования, выставленные лишь потому, что «так в институте учили» и не имеющие отношения к реальности… Дурацкие просчеты в написанном джунами ТЗ…
К сожалению, джуны не отличают важное от неважного, а нужное от ненужного.
Вы так говорите, как будто компилятор — это что-то сложное. У меня у самого три написано (довольно простых, кстати). Компилятор — это лишь способ ускорить выполнение кода. Просто у джунов мысли не возникает, что можно самому написать компилятор.При решении сколько-нибудь серьёзных задач инициатива по созданию компиляторов внутри неё почти всегда означает отвратительную потерю времени и отвратительно же сложную поддержку продукта. Области, где подобное приветствуется — есть, но это весьма узкие области, и приводить их в пример неправильно.
Угу, именно поэтому мы любим сеньоров. Помните туполевское «сломается здесь»? Так где джуниор через пару лет будет удивляться возникшим проблемам и ещё пару лет их расхлебывать — сеньор видит их с самого начала.Там где сеньор пилит знакомую технологию — верно. Там, где нужно строить или осваивать новое — наоборот.
Так и мы тоже не старьем занимаемся (высокоточная спутниковая навигация). И джуны из числа заказчиков — достали. Куча лишней писанины, требования, выставленные лишь потому, что «так в институте учили» и не имеющие отношения к реальности… Дурацкие просчеты в написанном джунами ТЗ…Удивительное пишете! Если эта область, где у заказчиков нет опыта вообще, то создаётся классическая IT-ситуация, когда заказчик вообще не способен составить ТЗ и вообще представить, что ему, на самом деле, нужно. Только в самых-самых общих словах. Всегда и везде в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.
Если же область сколько-нибудь заказчиком освоена — то никаких джуниоров в составлении ТЗ и не будет. Сеньоры не настолько дураки, чтобы самое вкусное отдавать желторотым.
В описанном же Вами я могу только согласиться — кошмар. Заказчик настолько оторван от реальности, что сеньоров у него нет вообще, и даже более того — он не способен воспринять и предложения разработчиков, так что фонтанирует дистиллированной глупостью. Но… денег у него немерено, приходится за это страдать. Ну, могу только посочувствовать, в таких условиях тяжело работать.
Надеюсь, становится видно и Вам, что у нас не противоречия, а плавный переход на поболтать. Потому, если просто приятно пообщаться, вспомнить былое и помечтать о новом — я готов. А продолжать обсуждение или тем более спор — смысла уже нет, согласны? Если да, просто давайте остановимся.
При решении сколько-нибудь серьёзных задач инициатива по созданию компиляторов внутри неё почти всегда означает отвратительную потерю времени и отвратительно же сложную поддержку продукта.Чушь какая-то. Компиляторы пишутся там, где они упрощают разработку. Ну как пример — электронные таблицы. На написание простейшего компилятора и простейшего интерпретатора байт-кода — два дня. А без компиляции сколько вы провозитесь, пока у вас начнет "(1+2)*3" считать?
Там где сеньор пилит знакомую технологию — верно. Там, где нужно строить или осваивать новое — наоборот.Вспоминаем количество новых технологий, запиленных теми же Туполевым и Королевым.
никаких джуниоров в составлении ТЗ и не будет. Сеньоры не настолько дураки, чтобы самое вкусное отдавать желторотым.Вы просто не сталкивались с конторами, созданными ради распила. Там одни джуны.
Всегда и везде в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.Вам очень сильно повезло, что вы с такими конторами не сталкивались. «Мы тут выиграли тендер, а теперь объясните нам, что мы нужно сделать. Ну и сделайте работу за нас, но за полцены». Это, практически, дословно.
А писать наукоообразные документы — это единственное, что эти джуны умеют. Так что ТЗ они пишут сами, вплетаю много-много красивых слов.
Ну, могу только посочувствовать, в таких условиях тяжело работать.С момента падения цены на нефть это обычная ситуация по госзаказу. Выигрывают конторы-однодневки, сидящик под кем-нибудь из олигархов.
в таких ситуациях исполнитель пишет ТЗ сам для себя и отдаёт заказчику, чтобы тот поставил большую круглую печать и вернул.Это если у заказчиков есть сеньор. А девиз джунов — «слабоумие и отвага». :-)
Вы считаете это не будет компиляцией? А чем тогда оно будет, интерпретацией? :-)
P.S. Я согласен, что компиляторные технологии очень просты и удобны. Просто джунам они кажутся чем-то космическим.
P.S. Я согласен, что компиляторные технологии очень просты и удобны. Просто джунам они кажутся чем-то космическим.
нет, как только появляется AST — это компиляция. А уж если вы храните AST — так это уже совсем классическая компиляция. Интерпретация — это как в калькуляторе.
Java — она как по вашему? Компилируется или интерпретируется?
Любой перевод в байт-код — трансляция.
То есть по сути так. В компилируемых языках мы можем откомпилировать модуль, а в интерпретируемых — только оператор.
Как минимум, не компилируемый FORTH — из-за динамического порождения ключевых слов.
Трансля́ция програ́ммы — преобразование программы, представленной на одном из языков программирования, в программу на другом языке. Любой перевод в байт-код — трансляция.
Получается, все языки, кроме, возможно, брейнфака — компилируемые?Не-а. Если у нас выполнения оператора может породить или не породить ключевое слово или идентификатор и мы не можем это узнать заранее — это будет чисто интерпретируемый язык.
То есть по сути так. В компилируемых языках мы можем откомпилировать модуль, а в интерпретируемых — только оператор.
Как минимум, не компилируемый FORTH — из-за динамического порождения ключевых слов.
Я склоняюсь к определениям, в которых компиляция — это произвольный перевод[1] из external language в некий internal language, самодостаточный и со строго определённой семантикой.
И тут вступает в силу странный критерий. А можно ли сохранить внутренний язык? А можно ли загрузить код на внутреннем языке и использовать его? Если можно — это компиляция, какая бы примитивная она не была.
Или, например, те же арифметические выражения после парсинга в AST я могу интерпретировать (бегая по дереву), либо скомпилировать в байткод для самописной стековой машины,Это менее значимый критерий. Если вы можете загрузить AST из файла — значит это компиляция.
А! вы неверно поняли слово «можно». Речь не о теоретической возможности. А о наличии функции в программе. А функция сохранения-вычитки делается в зависимости от того, имеет ли ценность результат компиляции. Или компиляция из исходного кода настолько быстрая, что нет смысла сохранять результат на внутреннем языке.
Угу. По аналогии «Если на транспортном средстве нет противоугонки, значит это ржавое корыто нечто дешевое, которое и так не угонят». Видели противоугонку на садовой тачке? А на детском трехколесном велосипеде? Но вы правы, порш со снятой противоугонкой по данному определению превращается в тыкву.
Это формальный признак. Если есть файл с откомпилированным представлением — значит, есть компиляция. Если откомпилированное представление не сохраняется, значит оно лишь этап интерпретации.
Я тут не вижу противоречий. Если у нас для каждого запуска нужен исходный текст — это интерпретатор, что бы ни было наворочено внутри. Если для запуска можно использовать откомпилированное представление — значит есть компиляция. Пусть очень простая, но есть.
P.S. А что любой формальный критерий может быть извращен до полного бреда — IMHO нормально. Чтобы было не извратить — нужно несколько формальных критериев. И то, специалисты по извращению найдут лазейку.
Это формальный признак. Если есть файл с откомпилированным представлением — значит, есть компиляция. Если откомпилированное представление не сохраняется, значит оно лишь этап интерпретации.
Я тут не вижу противоречий. Если у нас для каждого запуска нужен исходный текст — это интерпретатор, что бы ни было наворочено внутри. Если для запуска можно использовать откомпилированное представление — значит есть компиляция. Пусть очень простая, но есть.
P.S. А что любой формальный критерий может быть извращен до полного бреда — IMHO нормально. Чтобы было не извратить — нужно несколько формальных критериев. И то, специалисты по извращению найдут лазейку.
Я предлагаю следующий критерий.
Если в процессе выполнения программы изменить исходный код и программа станет работать с учётом изменений, то это интерпретатор. То есть, любые промежуточные представления для интерпретатора запрещены.
Если в процессе выполнения программы изменить исходный код и программа станет работать с учётом изменений, то это интерпретатор. То есть, любые промежуточные представления для интерпретатора запрещены.
Точнее, в таком критерии промежуточное представление разрешено, но объёмом не более, чтобы выполнить 1 шаг программы на исходном языке (1 оператор языка). Для следующего оператора нужно готовить промежуточные данные непосредственно перед его выполнением.
Исходный код кто меняет? Человек или программа? Без этого уточнения сложно оценить критерий.
Есть ещё один критерий. В интерпретаторе легко делается выполнение произвольного выражения, введенного оператором с клавиатуры.
Кстати, по всем трем критериям, SQL получается интерпретатором. Хотя у него довольно большая стадия компиляции и оптимизации скомпилированного кода.
Есть ещё один критерий. В интерпретаторе легко делается выполнение произвольного выражения, введенного оператором с клавиатуры.
Кстати, по всем трем критериям, SQL получается интерпретатором. Хотя у него довольно большая стадия компиляции и оптимизации скомпилированного кода.
Исходный код кто меняет? Человек или программа?Человек не сам действует, а всегда посредством программы. Я имел в виду, что исходный код лежит где-то в памяти интерпретатора или в файле на диске (менять его может другой процесс или тот же самый), в сам язык не обязательно встраивать возможность само-модификации.
Есть ещё один критерий. В интерпретаторе легко делается выполнение произвольного выраженияЭто скорее следствие, но обратное не всегда верно (интерпретатор может быть зашит в железку без портов, через которые можно ввести выражение).
Кстати, по всем трем критериям, SQL получается интерпретатором.Да пожалуйста. Хотя насколько я знаю по популярным СУБД, хранимые процедуры лежат в виде байт-кода. Получается, что у СУБД есть компилятор в байт-код и интерпретатор байт-кода. То есть, одиночный запрос выполняется в режиме интерпретации (по этому критерию), а блок запросов — компилируется.
Если изменить исходный код до точки чтения — точка чтения улетит. Да и буферизация чтения помешает увидеть изменения.
Увы, плотно работал с SQL лет 20 назад, так что уже не помню точно. Но вроде бы у первого запроса время компиляции было ненулевое, а у последующих — 0.
То есть, одиночный запрос выполняется в режиме интерпретации (по этому критерию), а блок запросов — компилируется.На MS SQL и одиночный запрос компилируется, а потом оптимизируется. Им для оптимизации (составления плана выполнения) нужна промежуточная форма. Похоже там и кэширование промежуточной формы есть. То есть подав 100 однотипных запросов, время на компиляцию будет получено только на первом.
Увы, плотно работал с SQL лет 20 назад, так что уже не помню точно. Но вроде бы у первого запроса время компиляции было ненулевое, а у последующих — 0.
На MS SQL и одиночный запрос компилируется, а потом оптимизируетсяВнутри может быть что угодно, я говорю о том, что по предложенному критерию одиночные SQL выполняет интерпретатор, и это с наблюдаемым поведением не расходится (возможна интерактивная работа)
По моим понятиям MS SQL компилируется. И по вашему критерию — тоже. Ибо запрос считывается целиком и его изменение не повлияет.
Нет, потому что минимальный шаг выполнения в языке SQL это один запрос.
Вы не правы. Теоретически минимальный шаг — это один оператор. А в запросе можно уместить сотню DELETE, UPDATE или INSERT.
За давностью лет уже и синтаксис помню нечетко, но мне кажется, что в транзацкии запросы типа
Отрабатывали как
То есть вроде как в MS SQL была межоператорная оптимизация. Не поручусь (20 лет прошло), но по рассмотрению плана запросов мне казалось, что так.
За давностью лет уже и синтаксис помню нечетко, но мне кажется, что в транзацкии запросы типа
BEGIN TRANSACTION
DELETE FROM TABLE WHERE N=11
DELETE FROM TABLE WHERE N=12
END TRANSACTION
Отрабатывали как
BEGIN TRANSACTION
DELETE FROM TABLE WHERE N IN (11,12)
END TRANSACTION
То есть вроде как в MS SQL была межоператорная оптимизация. Не поручусь (20 лет прошло), но по рассмотрению плана запросов мне казалось, что так.
Если изменить исходный код до точки чтения — точка чтения улетит. Да и буферизация чтения помешает увидеть изменения.Да, такое я наблюдаю на Windows 10 с cmd-файлами. Можно из критерия убрать про диск, оставить только оперативную память, куда загружена интерпретируемая программа.
В интерпретаторе легко делается выполнение произвольного выражения, введенного оператором с клавиатуры.Антипример — классические BASIC-и времён 8-битных процессоров. Имея произвольное выражение (в виде строки, например), вычислить его сложно, т.к. интерпретатор не предоставляет таких ф-ций.
Исходный BASIC — это компилируемый язык, отсюда ограничение на 26 FOR (страница 55). В нем не было строк, даже в PRINT использовались метки (страница 31). Типов в нем тоже не было — все было FLOAT.
Имелся ли ввод строк в BASIC на 8080 — не знаю, скорее всего нет. А без ввода строк и строчных операций eval не нужен.
Имелся ли ввод строк в BASIC на 8080 — не знаю, скорее всего нет. А без ввода строк и строчных операций eval не нужен.
Я про бейсики на всяких ZX-Spectrum, Commodore 64 и прочих БК-0010. Строки там есть, eval нет.
Вики утверждает, что на БК-0010 бейсик компилировался:
Про спектрум и коммондор — копайте сами.
была возможность отказаться от исходного текста и использовать только «скомпилированную» версию программы.Про спектрум и коммондор — копайте сами.
У меня спектрум был, и я очень неплохо разбирался в его внутренностях. Там ничего не компилировалось. Да, БК не было. Значит, классический BASIC таки компилируемый, но для меня он навсегда интерпретатор )))
Самый простой способ реализациия для любого языка — это компиляиция в код виртуальной машины, очень похожей на этот самый язык. А уже вирт-машина
интерпретирует операторы. Ну то есть примерно как в FORTH.
Можно по скорости цикла посмотреть, была ли там компиляция. Скорость при чистой компиляции (без оптимизации, то есть фортран) — в 1.5-2 раза меньше скорости ассемблера. Скорость форт-систем — в 10-20 раз ниже скорости ассемблера. А скорость чистой интерпретации — намного хуже.
Чистая интерпретация была в FOCAL, по ощущениям — ну раз в 10-20 медленней FORTH. По ощущениям, фокал при каждом обращении искал значаение переменной по её имени.
интерпретирует операторы. Ну то есть примерно как в FORTH.
Можно по скорости цикла посмотреть, была ли там компиляция. Скорость при чистой компиляции (без оптимизации, то есть фортран) — в 1.5-2 раза меньше скорости ассемблера. Скорость форт-систем — в 10-20 раз ниже скорости ассемблера. А скорость чистой интерпретации — намного хуже.
Чистая интерпретация была в FOCAL, по ощущениям — ну раз в 10-20 медленней FORTH. По ощущениям, фокал при каждом обращении искал значаение переменной по её имени.
Это будет парсер выражений в данном случае.
Чтобы вы понимали — технология без компиляции — это как в калькуляторе. Интерпретация каждого вводимого символа. Так (на конечном автомате) можно писать можно, но будет сложнее, чем с компиляцией.
Поток байтиков в данном случае — не алгоритм, а данные. Поэтому он и «парсится», а не компилируется.
А вообще это лет 50 уже известно, что в интерпретируемых языках для скорости и отлаживаемости лучше вначале компилировать в AST или байт-код, а потом его исполнять.
Но есть и чисто интерпретируемые реализации, классические калькуляторы — это типовой пример.
А вообще это лет 50 уже известно, что в интерпретируемых языках для скорости и отлаживаемости лучше вначале компилировать в AST или байт-код, а потом его исполнять.
Но есть и чисто интерпретируемые реализации, классические калькуляторы — это типовой пример.
Текст программы — это алгоритм. Это не мешает ему одновременно быть набором байтов или данными файла.
А вот трудовой договор — это не алгоритм. В нем нет последовательности действий. Так что приходим к странному результату — текст программы на декларативном языке алгоритмом не является.
А вот трудовой договор — это не алгоритм. В нем нет последовательности действий. Так что приходим к странному результату — текст программы на декларативном языке алгоритмом не является.
На самом деле отличие в том, что для меня нормальный джун — это школьник или студент. А после окончания института — должен тянуть на миддла. Ну или человек неверно профессию выбрал и весь институт — учился вместо того, чтобы работать.
Джун после 25 лет — это нонсенс. Ну разве что человек пришел в программирование из физиков или строителей.
Джун после 25 лет — это нонсенс. Ну разве что человек пришел в программирование из физиков или строителей.
Не зависит. :-) Следите за руками.
Если написанием компилятора мы упрощаем код и сокращаем время на разработку — значит компилятор менее сложен, чем остальной код. Ели компилятор сложнее, чем его замена — зачем его писать?
Если написанием компилятора мы упрощаем код и сокращаем время на разработку — значит компилятор менее сложен, чем остальной код. Ели компилятор сложнее, чем его замена — зачем его писать?
Разве можно сэкономить время, написав сложный код вместо простого? Время, если очень грубо, примерно равно квадрату сложности кода.
Ну если очень много… :-))) Но пример как-то в голову не приходит.
Пример уже вроде был — crud
важнее, что проще понять и отладить. Учить библиотеку ради разового применения обычно не выгодно.
взаимоисключающие параграфы. Или самописную и понятную автору — или автосгенеренную и понятную лишь тому, кто писал код yacc.
Нет, самописная стейтмашина — это именно самописная. Написанная ручками, без кодогенераторов. Сделать из описания протокола БНФ — займет времени побольше, чем написать стейт-машину. Пример протокола.
Молодые сеньоры, вчерашние джуны
А мидлов не существуют?
Не впадайте в крайности. Срединного подхода нет и никогда не будет. Новички необходимы в силу эволюционного развития каждой компании. Кто-то из старших разработчиков эволюционировал до руководящей или менторской работы, кто-то наоборот деградировал, кто-то остался на том же уровне. Да и по хорошему перетекание сотрудников с примерно одинаковым уровнем знания влечет к деградации к отрасли в целом. Пример не связанным с программированием это перетекание закостеневших ciso из одной компании в другую. Да у человека имеется огромный багаж знаний, но есть минус потребности в безопасности у компании эволюционируют, так же и с написанием кода. Предугадать какие библиотеки и какие языки будут востребованы и актуальны в проектах в следующем месяце или квартале не возможно.
Однако тут есть маленькая проблемка: как их найти?Это как просто. Любой программист младше 12 лет :-) — это будущий крутой сеньор.
Вопрос не в том, как их найти — места обитания таких людей известны. Вопрос в том, как их удержать. Слишком уж меняются интересы по мере взросления.
P.S. У меня был 17летний сотрудник, которого, по-хорошему нужно было ставить руководителем группы вместо меня. В 17 он был на третьем курсе и четвертый год программировал за деньги. Собственно многие его знают как человека, придумавшего идею языка Котлин и написавшего первую книжку по нему. Вот только даже в 14 — он уже был мидлом.
У меня есть вот вопрос — ну, ОК, все перестали нанимать джунов. Где через 5-10 лет вы планируете нанимать новых сеньоров, на замену умершим/вышедшим на пенсию? Ведь сеньоры получаются из джунов, но раз джунов никто не нанимает, то и новых сеньоров не появляется…
Почему же. Если оглядеться на реальный мир — можно увидеть, что джунов нанимают аутсорс-конторы, чтобы продавать их как миддлов, а заодно тренируют их проходить собеседования на миддлов. Заодно они же занимаются раздуванием кода программных продуктов, чтобы нанимать и продавать больше разработчиков, и их как раз устраивает низкое качество кода — можно заодно QA продавать.
А в момент, когда человек понимает, что не способен в своей доменной области в компании отрабатывать с желаемым уровнем качества — он начинает искать компании из второй категории.
И да, скорее всего любая компания, которая говорит, что не нанимает джунов, наймет человека, который будет сидеть по 24 часа в сутки, переделывая собственные ошибки и подходя с вопросами ко всем. Просто джуны обычно сейчас ждут, что их будут носить на руках, потому что они прошли двухмесячные курсы. Увы, говорю как человек, который занимается интервью последние пару лет довольно часто — как себе, так и другим проектам.
Нанимайте джунов только в двух случаях: вы корпорация и коллекционируете программистов, либо вам очень тяжело заманить высокоуровневых программистов. Джунов которые пишут не говно — считанные проценты. Джунов, которые считают иначе — более 90%. И вот где-то среди тех долей процентов, где джун пишет не совсем говно и трезво оценивает свои возможности, пытаясь избавиться от недостатков, лежит ваш не ограненный алмаз. Так что тут нужно быть либо ну очень терпеливым, либо ну очень уверенным в своих оценках и методиках отбора.
Есть еще третий случай: вам очень важен конкретный человек. Например, если вы хотите научить брата-джуна программировать, можно вместе сделать проект.
Проектов без простых задач — мало.
При нормально поставленном процессе — следить за джунами занимает меньше времени, чем реализовывать простые задачи силами сильных разработчиков.
При этом самим сильным разработчикам интересней работать, некоторым еще и само менторство тоже помогает отвлечься — а это тоже корпоративные деньги на тимбилдинги и тд и тп.
При том всем джуны имеют свойство расти и не сразу об этом понимать. Так что опять таки, при нормально поставленном процессе у конторы есть энное количество мидлов которые получают как джуны.
Вы можете сказать что это денежный вопрос и могут существовать компании где денег хватает и на сениора который половину рабочего времени формошлепит, и денег на то чтобы создать для него комфортную среду несмотря на формошлепство.
Вот только это сразу же ошибка с точки зрения бизнеса, ведь эти деньги можно пустить на дело и приумножить.
При нормально поставленном процессе — следить за джунами занимает меньше времени, чем реализовывать простые задачи силами сильных разработчиков.
При этом самим сильным разработчикам интересней работать, некоторым еще и само менторство тоже помогает отвлечься — а это тоже корпоративные деньги на тимбилдинги и тд и тп.
При том всем джуны имеют свойство расти и не сразу об этом понимать. Так что опять таки, при нормально поставленном процессе у конторы есть энное количество мидлов которые получают как джуны.
Вы можете сказать что это денежный вопрос и могут существовать компании где денег хватает и на сениора который половину рабочего времени формошлепит, и денег на то чтобы создать для него комфортную среду несмотря на формошлепство.
Вот только это сразу же ошибка с точки зрения бизнеса, ведь эти деньги можно пустить на дело и приумножить.
Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.
Правильно ли я понял, что имеется в виду, что старшие разработчики будут экономить время за счет делегирования задач джунам?
если да
а-ха-ха-ха-ха
Я дико извиняюсь, но разве комментарии к статьям не принято писать, собственно, в комментариях? А это именно комментарии, никакого анализа даже близко нет.
Обычно компании, которые нанимают только сеньоров, на самом деле нанимаю джунов, которые маскируюся под сеньоров, так как если нету сотрудников разного уровня, то и сравнить их проблематично.
Всегда было интересно, из какого пальца высасывается то, чего не было в оригинальной фразе. Где было про долг и про бюджет? Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.
Мне вот больше интересно, автор, а где Вы выловили такую мысль в приведенной статье? Автор статьи, которого Вы местами нещадно критикуете, всего лишь делает вывод на основании представленных пунктов. В принципе, тоже самое делаете и Вы, вот только у него вывод намного ближе к истине, чем Ваш…
И таких недочетов, на самом деле, у Вас еще очень много.
Мне вот больше интересно, автор, а где Вы выловили такую мысль в приведенной статье? Автор статьи, которого Вы местами нещадно критикуете, всего лишь делает вывод на основании представленных пунктов. В принципе, тоже самое делаете и Вы, вот только у него вывод намного ближе к истине, чем Ваш…
И таких недочетов, на самом деле, у Вас еще очень много.
Немного лирики: если в армии оставить одних генералов, то кто будет носить патроны и мыть полы?
По делу:
— Есть, как уже тут отмечали, более сложные задачи, есть более тривиальные (ну там CRUD'ы и иже с ними). Использовать на тривиальных задачах сеньоров (в случае, когда, нет автоматизации производства такого рода кода) — почти что как забивать микроскопом гвозди.
— Джун, действительно, может взглянуть более свежим и упрощённым взглядом на вопрос, и иногда это бывает полезно.
— Джун — это инвестиция компании в будущее. И если в компании хорошие условия, то джун станет расти и приносить ей пользу (за исключением экстремальных личных обстоятельств, когда джун вынужден куда-то переехать или по иным особым причинам покинуть работу).
По делу:
— Есть, как уже тут отмечали, более сложные задачи, есть более тривиальные (ну там CRUD'ы и иже с ними). Использовать на тривиальных задачах сеньоров (в случае, когда, нет автоматизации производства такого рода кода) — почти что как забивать микроскопом гвозди.
— Джун, действительно, может взглянуть более свежим и упрощённым взглядом на вопрос, и иногда это бывает полезно.
— Джун — это инвестиция компании в будущее. И если в компании хорошие условия, то джун станет расти и приносить ей пользу (за исключением экстремальных личных обстоятельств, когда джун вынужден куда-то переехать или по иным особым причинам покинуть работу).
Так ли это — про сеньора за считанные недели? Мне, к сожалению, случалось наблюдать лишь обратное. Возможно, это как раз та разница в привлекательности компании и перспективности проекта.
По сравнению с ним в РФ на рынке труда программистов «как грязи» и расслоение по зарплатам не так значительно.
Шта? «Хорошо только там, где нас нет». Полюбопытствуете медианам зарплат в США — многое для себя откроете.
habr.com/post/423695
110 000 в год сеньор с 15 летним опытом.
www.indeed.com/salaries/Junior-Developer-Salaries
62 000 джун
Разница в 2 раза.
Это в США разбег незначительный. Если не считать несколько самых крутых фирм, куда мало кому светит попасть.
В РФ типовой джун и 30 000 рублей в месяц может не получать.
Типовой сеньор — это далеко за 100 000 рублей в месяц, скорее ближе к за 150 000.
Разница в 5 раз.
И это если не считать, что можно из РФ работать «на западного дядю», где и 200-300 тыс. рублей в месяц не предел мечтаний, а можно и больше.
У нас более «дикий рынок». По зарплатам в том числе.
В РФ позиция сеньора закрывается за недели, в США многими месяцами с кучей собеседований.
То, что ради ЧСВ вакансию называют «сеньорской» вовсе не означает, что она таковой считается.
Неделю?
Мы по 2 месяца ищем. И дело даже не в зарплатах (они более чем достойные, существенно выше чем по региону).
Просто приходят в основном «23-х летние сеньоры». А то и вовсе «Я умею ставить Windows и являюсь администратором Linux, потому что сам поставил Ubuntu; что? командная строка? нет, не работал. зачем, GUI же есть».
Сеньор это от 7 лет опыта.
Где в РФ выгодно нанимать сеньоров у «них» имеет смысл обучить джуна.
Ничуть.
Зависит не от страны, а от особенностей конкретной компании.
«Сеньор это от 7 лет опыта», — разрешите узнать, почему?
В IT разве есть строго формализованное понятие «выслуги лет» аки в армии? Мне думается, что развитие и приобретение большего опыта не всегда коррелирует с временем. Как тут и в других местах уже писали, можно и семь лет сидеть на тривиальных задачах, не став, разумеется, сеньором. А можно и за год-два плотной работы как в команде, так и над своими навыками, получить колоссальное развитие. Ибо всё это условно, и нельзя ставить рамки. Но даже если как-то попытаться усреднить, то семь лет — многовато для сеньора. Я вижу (сугубо личное мнение) эту планку где-то в 4-5 лет. Быстрее, если разработчик крайне талантлив и трудолюбив, плюс для него есть толковые задачи.
В IT разве есть строго формализованное понятие «выслуги лет» аки в армии? Мне думается, что развитие и приобретение большего опыта не всегда коррелирует с временем. Как тут и в других местах уже писали, можно и семь лет сидеть на тривиальных задачах, не став, разумеется, сеньором. А можно и за год-два плотной работы как в команде, так и над своими навыками, получить колоссальное развитие. Ибо всё это условно, и нельзя ставить рамки. Но даже если как-то попытаться усреднить, то семь лет — многовато для сеньора. Я вижу (сугубо личное мнение) эту планку где-то в 4-5 лет. Быстрее, если разработчик крайне талантлив и трудолюбив, плюс для него есть толковые задачи.
«Сеньор это от 7 лет опыта», — разрешите узнать, почему?
В IT разве есть строго формализованное понятие «выслуги лет» аки в армии? Мне думается, что развитие и приобретение большего опыта не всегда коррелирует с временем.
Разумеется, не коррелирует на 100% людей. Это всего лишь грубая прикидка для среднего разработчика.
Если брать основную массу:
2 года от трейни до джуна (у кого-то может и год занять, у кого-то и 3).
потом еще лет 5 через-миддла-к сеньору, и то не все придут.
7 лет — это еще по оптимистичному, для целеустремленного человека, который и сам учился по профессии и которому повезло работать с грамотными коллегами, что его поднатаскали.
Разумеется, в конкретной ситуации могут быть и другие цифры
Но «23-летний сеньор»? Извините, не верю. Оно конечно бывает, но исчезающе редко очень…
Я начал программировать в 14. В университете сам уже учил преподавателей новым методам разработки. К 23 годам точно был максимум что миддлом, если еще не джуном.
Опыт получаемый не в реальных проектах — он так себе опыт.
«От 7 лет опыта» — значит, «не менее».
Дольше — да, можно.
Немного быстрее, скажем за 5 лет — дано не многим.
Существенно быстрее — не дано никому.
«23-летние сеньоры» в реальной жизни если и существуют, то никому из нас они не встретятся.
Спасибо за ответ! Я понял Вашу позицию. :)
«2 года от трейни до джуна (у кого-то может и год занять, у кого-то и 3)», — все кого я знаю, этот путь закрывали ещё в вузе.
До мидла от джуна почти все вырастали быстро (год-полтора), но ценой труда и усидчивости.
Ну, 23-летний сеньор — согласен полностью, едва ли реально.
Но 25-летний лично мне известен, мой хороший друг. Он начал программировать в реальных проектах со второго курса, ну а так для себя что-то — ещё в школе, разумеется. Упахивался на работах, по 2-2,5 года отпуск не видел, но зато к 25 годам он уверенный сеньор был. Ценой огромного труда, ну и сам он талантлив и не глуп в довесок к тому.
«2 года от трейни до джуна (у кого-то может и год занять, у кого-то и 3)», — все кого я знаю, этот путь закрывали ещё в вузе.
До мидла от джуна почти все вырастали быстро (год-полтора), но ценой труда и усидчивости.
Ну, 23-летний сеньор — согласен полностью, едва ли реально.
Но 25-летний лично мне известен, мой хороший друг. Он начал программировать в реальных проектах со второго курса, ну а так для себя что-то — ещё в школе, разумеется. Упахивался на работах, по 2-2,5 года отпуск не видел, но зато к 25 годам он уверенный сеньор был. Ценой огромного труда, ну и сам он талантлив и не глуп в довесок к тому.
До этого работал в Томске — город студентов, программистов много, с поиском сеньоров проблем не было, на каждое место был конкурс, за 2 недели закрывали.
Вы работали в большой фирме Томске, которая регулярно нанимала сеньоров? Иначе откуда у вас статистика.
Меня больше интересует — откуда в Томске столько большая фирма, регулярно нанимающая сеньоров.
Последние 3 года за трендами зарплат в РФ не слежу, но в нашем регионе больше 100 очень мало кто получал
У нас с вами просто разное понятие слова «сеньор».
Полагаю, вы этим словом называете того, кто по моему «миддл».
HH.RU говорит про Томск следующее:
Имеется 283 вакансии «программист».
Из них 63 с зарплатой более 120 000 в месяц
Ну и 34 — более 150 000
И даже 10 — более 185 000
22% от вакансий — это от 120 000 рублей в месяц
На самом деле гораздо больше, так как нижний сегмент по зарплате это эникеи, а не разработчики, просто их традиционно называют программистами.
Скриншот с hh.ru, Томск, программист
Никто не говорит, что джуниоры — враги. Их просто не нанимают. А еще не нанимают, например, слесарей и художников.
Ну, передергивание же. «Джун» — это уровень квалификации, «слесарь» — представитель другой профессии вообще.
Некоторые мысли настолько точны, что статью добавил в закладки, а тезисы выписал.
Только где компания возьмет столько сеньоров и мидлов? Я видел как некоторые тривиальные вакансии(JS/React) по 6-12 месяцев висят и пересоздаются раз в неделю чтобы быть в топе. Это наверное те компании которые называют себя «высокотехнологичными с уникальным программным продуктом».
Я боюсь представить сколько времени висят вакансии на С++ сеньора.
Искать сеньоров оправдано в таких областях как разработка нейросетей, игр, игровых движков, научный софт.
Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.
Я боюсь представить сколько времени висят вакансии на С++ сеньора.
Искать сеньоров оправдано в таких областях как разработка нейросетей, игр, игровых движков, научный софт.
Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.
Только где компания возьмет столько сеньоров и мидлов? Я видел как некоторые тривиальные вакансии(JS/React) по 6-12 месяцев висят и пересоздаются раз в неделю чтобы быть в топе. Это наверное те компании которые называют себя «высокотехнологичными с уникальным программным продуктом».
Я боюсь представить сколько времени висят вакансии на С++ сеньора.
Если в компании много, ну скажем, 100 разработчиков (а это еще не особо и большая фирма всего-то «малый бизнес»), то нескольких из них постоянно приходится донанимать.
Чисто статистически: кто-то заболевает или впадает в депрессию, кто-то умирает, кто-то вырастает из джуна, кто-то уходит в другую фирму, кто-то разочаровывается в профессии и становится таксистом, кто-то уезжает в другой город по семейным обстоятельствам, и это не считая того, что сама фирма может рости.
Чем больше сотрудников, тем больше в абсолютных цифрах (не в процентах, конечно) доля подобный флуктуаций численности.
Это не одна и та же вакансия, хотя и называется одинаково.
Ну вот скажите, зачем фирме проплачивать отдельно публикацию вакансии на каждого нанимаемого сотрудника, если должность одна и та же. Что там каждый раз изменяется? Новые контактные данные HR, что ли? Кадровичка на нового сотрудника новый сотовый себе покупает что ли?
Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.
Ну это если он до этого уже был сеньором в другой сфере разработки. И то, 2 недели тебе нужно просто чтобы войти в рабочий ритм фирмы, только чтобы понять «где какие файлы принято складывать» и т.п.
джун за 2-4 недели набирает нужный уровень.
Не всех заказчиков устраивают дико тормозящие сайты.
Не все заказчики довольствуются сайтами визитками или интернет-магазинами, где при изменении цены у поставщика приходится по всем 1000 товарам проходиться вручную меня цену.
Искать сеньоров не оправдано в таких областях как веб-разработка, бекенд, энтерпрайз разработка, в этих областях джун за 2-4 недели набирает нужный уровень.
Видимо вы не сталкивались с мало-мальски серьезными проектами и демонстрируете Даннинга-Крюгера.
Про библиотекарей совсем не в тему пример, джун — это в какой-то мере степень профессионального развития программиста, я не думаю, что библиотекарь или слесарь может считаться таковой.
Когда занимался физ-хим. экспериментом в одном из ведущих НИИ АН СССР (РАН), часто заказывал нестандартные устройства/детали на опытном производстве при этом НИИ. Неоднократно слесари шестого разряда предлагали решение гораздо более технологичное для них и гораздо более удобное и надежное для меня. Там были «ювелирные работы». Но, к сожалению, не у всех слесарей 6-ой разряд. В том же НИИ пара опытных библиотекарей, часто не смотря в каталог, подсказывали наиболее востребованную книгу по узко-специальной теме. И физика и химия — очень большие, и в полном объеме их знать не в человеческих силах, и часто бывает нужной справка из области, с которой не имел до этого дела. Библиотекарши, проработав несколько десятков лет, запоминают десятки тысяч заголовков и могут сильно сэкономить время поиска нужного источника. Гуглу пока остается только мечтать о таком поиске. Чуть сложнее запрос — выбросит сотни тысяч ссылок, и только доли процента окажутся нужными (см., нпр., картинку — но это не самый тяжелый случай).
Я же не говорю, что библиотекари, или слесари — плохие и ненужные люди.
Моя мысль в том, что они ну никак не вписываются в квалификацию джун/миддл/сеньор, в их прямые обязанности не входит написание кода, и сравнивать найм джунов в IT-компании с наймом библиотекарей/слесарей в IT-компании, как минимум, неверно.
Моя мысль в том, что они ну никак не вписываются в квалификацию джун/миддл/сеньор, в их прямые обязанности не входит написание кода, и сравнивать найм джунов в IT-компании с наймом библиотекарей/слесарей в IT-компании, как минимум, неверно.
ИМХО в сравнении «джун vs сеньор» несколько факторов. Один из важных — это опыт. Программист-сеньор, как и опытный слесарь, как и опытная библиотекарша зачастую вспоминают похожую задачу, которую уже решали. Но иногда это решение может оказаться устаревшим и прилежный джун может найти (нпр., в инете) новое более эффективное решение, еще не успевшее стать общеизвестным. С этой точки зрения любой нетривиальный труд вписывается — такой своеобразный изоморфизм.
Имхо, джуны имеют смысл в четырех случаях:
- У руководства имеется мнение (почти всегда ошибочное) что хороший сеньор с командой джунов выдаст продукт сеньорного качества со скоростью команды джунов
- Нанимаем джуна, по-быстрому подтягиваем до миддла, продолжаем платить как джуну — чистый профит.
- Недорого, быстро и при этом работает — осознанная политика руководства.
- Нужны узкопрофильные или лучшие специалисты и при этом есть деньги на их выращивание.
Нанимаем джуна, по-быстрому подтягиваем до миддла, продолжаем платить как джуну — чистый профит
Это не лишено смысла.
Миддлом он конечно не станет быстро.
Но уровень «начинающего джуна» и уровень «джуна с опытом», действительно, разительно отличается.
Недорого, быстро и при этом работает — осознанная политика руководства.
Не всем нужны высокие технологии.
Разработка уже давно не является элитной профессией. Раскатать CMS и щелкнуть в ней пару галочек уже и головастые «менеджеры по продажам» способны.
У руководства имеется мнение (почти всегда ошибочное) что хороший сеньор с командой джунов выдаст продукт сеньорного качества со скоростью команды джунов
Как правило просто нет бюджета на сеньора + 3 миддлов.
Далеко не всегда имеется уверенность что проект взлетит, потому невозможно привлечь инвестиции. Дорогая ИТ-шная разработка — это риски.
Если не нанимать на работу джунов, то откуда тогда возьмутся сеньоры?
Исходная статья говорит о том, что плохо не то, что принимаются только высокоуровненые специалисты, а плохо то, что Netflix выпячивает это как корпоративную ценность.
Посмотрите на Google — там есть и стажёрские позиции, и средние. Но, чтобы туда попасть, нужно на собеседовании показать такой же уровень, как у сеньора в Netflix. Зато сразу декларируется возможность роста. В Netflix, если тебя взяли синьором, то это уже потолок.
Посмотрите на Google — там есть и стажёрские позиции, и средние. Но, чтобы туда попасть, нужно на собеседовании показать такой же уровень, как у сеньора в Netflix. Зато сразу декларируется возможность роста. В Netflix, если тебя взяли синьором, то это уже потолок.
Компания никому ничего не должна. Даже если она разорится — это ее право.Вот это, среди прочих вполне здравых аргументов, крайне странная… эммм… сентенция. Компания должна — по определению. Начиная с налогов и отчётности и заканчивая зарплатой. А если она разоряется, то и говорить уже не о чем. Да, есть такое право — расформировать компанию. Но давайте не будем путать просто ликвидацию юрлица со стратегическими ошибками, которые приводят к упадку, либо невозможности исполнять то, что компания должна.
Лучший способ забюрократизировать отрасль, когда новые сеньоры будут появляться только из университетов для подготовки «сеньоров», где их будут уметь отвечать на вопросы резюме, что такое virtual и как решать графы.
Суть любой компании — это зарабатывание денег.
Это может относится только к коммерческим организациям, но не к любой.
Заметили ошибку?
Заметил, что «Воистину!» написано через пробел.
В отраслях, где от кода зависят жизни и здоровье людей, любой сеньор будет чувствовать себя полным джуном.
Ваш пример — очередное подтверждение, как мне видится, тому, что границы степеней развития разработчика являются весьма плавающими. Впрочем, вероятнее всего, сыграли роль также Ваши талант и трудолюбие, ибо без них сразу на позицию мидла попасть сложновато, как по мне.
Да что уж там, всё плавающее: и сроки роста из одной категории в другую, и критерии оценки. Как я уже выше отмечал, мир IT — не армия, тут не работает в обе стороны принцип «Ну посижу тут лет N да стану полковником». То есть не каждый, кто много лет работает в каком-то стеке технологий, является в нём сеньором, но и не каждый сеньор много лет работал в одном стеке технологий, чтобы стать тем, кто он есть.
Стоит развиваться, читать профильную литературу, просить более нетривиальные задачи. Я, например, обожаю, когда (звучит забавно, да) на работе много работы. Не через край, чтобы на выходных ещё сидеть, а вот самое оно — весь рабочий день заполнен. Это не скучно, интересно, занятно, чувствуешь своё развитие. И грущу, когда задач нет. Потому что в нашей сфере мы работаем не только на фирму. Мы, прежде всего, работаем на своё будущее. И наработанные для этого самого будущего навыки есть много более ценный капитал, чем материальное вознаграждение за проделанный труд.
Да что уж там, всё плавающее: и сроки роста из одной категории в другую, и критерии оценки. Как я уже выше отмечал, мир IT — не армия, тут не работает в обе стороны принцип «Ну посижу тут лет N да стану полковником». То есть не каждый, кто много лет работает в каком-то стеке технологий, является в нём сеньором, но и не каждый сеньор много лет работал в одном стеке технологий, чтобы стать тем, кто он есть.
Стоит развиваться, читать профильную литературу, просить более нетривиальные задачи. Я, например, обожаю, когда (звучит забавно, да) на работе много работы. Не через край, чтобы на выходных ещё сидеть, а вот самое оно — весь рабочий день заполнен. Это не скучно, интересно, занятно, чувствуешь своё развитие. И грущу, когда задач нет. Потому что в нашей сфере мы работаем не только на фирму. Мы, прежде всего, работаем на своё будущее. И наработанные для этого самого будущего навыки есть много более ценный капитал, чем материальное вознаграждение за проделанный труд.
Прежде всего весьма плавающие сами термины «джун», «мидл», «сеньор», «лид» и т. п. Это обычно должности, а не степени развития.
Ну, позволю себе согласиться с Вами лишь отчасти.
Действительно, большинство компаний указывают в вакансии, например, «Senior developer». Но дело в том, что (как минимум у конкретной компании в рамках определённой вакансии) определяются навыки, требуемые для должности этой, ну и на собеседовании становится ясно, какой уровень и по каким моментам хотят от соискателя. В разных фирмах для должностей той или иной степени эти навыки и их глубина могут отличаться, но если собрать и экстраполировать эти данные, то мы получим более-менее усреднённый список навыков (возможно, в виде списка вопросов к собеседованиям) для данной позиции. Например, в моей сфере (ASP.NET, C#) такой список есть по стеку дотнета и шарпа. Понятно, что его расширяют списки основных вопросов по алгоритмам, БД и ООП. И если более-менее знать (а, главное, понимать, а не просто выучить ответы) по сути всех этих вопросов из этих списков, то вероятность успеха при приёме на работу (да и при дальнейшей работе) будет высока.
И джун знает из этих списков далеко не всё, а если и знает, то уж точно не всё применять умеет. Мид, соответственно, знает и умеет применять уже больше, а сеньор, по идее, должен знать и уметь это всё (или почти всё, или мочь быстро понять и применить, даже если не знал). В этом плане/контексте «джун», «мидл», «сеньор» могут рассматриваться в том числе и как уровни развития.
Действительно, большинство компаний указывают в вакансии, например, «Senior developer». Но дело в том, что (как минимум у конкретной компании в рамках определённой вакансии) определяются навыки, требуемые для должности этой, ну и на собеседовании становится ясно, какой уровень и по каким моментам хотят от соискателя. В разных фирмах для должностей той или иной степени эти навыки и их глубина могут отличаться, но если собрать и экстраполировать эти данные, то мы получим более-менее усреднённый список навыков (возможно, в виде списка вопросов к собеседованиям) для данной позиции. Например, в моей сфере (ASP.NET, C#) такой список есть по стеку дотнета и шарпа. Понятно, что его расширяют списки основных вопросов по алгоритмам, БД и ООП. И если более-менее знать (а, главное, понимать, а не просто выучить ответы) по сути всех этих вопросов из этих списков, то вероятность успеха при приёме на работу (да и при дальнейшей работе) будет высока.
И джун знает из этих списков далеко не всё, а если и знает, то уж точно не всё применять умеет. Мид, соответственно, знает и умеет применять уже больше, а сеньор, по идее, должен знать и уметь это всё (или почти всё, или мочь быстро понять и применить, даже если не знал). В этом плане/контексте «джун», «мидл», «сеньор» могут рассматриваться в том числе и как уровни развития.
Немало компаний, где список знаний технологий и т. п. практически не отличается по позициям, но отличаются опыт и навыки работы в команде. Грубо, джун может быть без опыта почти и должен умерь работать под единолричным руководством, миддл — должен иметь опыта 2-5 лет и должен уметь работать самостоятельно в команде, а сеньор — опыта 5+ лет и навыки руководства джунами.
. Впрочем, вероятнее всего, сыграли роль также Ваши талант и трудолюбие, ибо без них сразу на позицию мидла попасть сложновато, как по мне.
Ихмо, все куда как проще.
Сейчас огромная куча «войти-в-айтишников» после 2 месячных курсов.
На их фоне человек с 4-мя годами обучения (если не балду пинал) выглядит вполне себе квалифицированым.
Тех, кто после 2-х месяцев — берут на простые работы. Ну и называют джунами.
А тех, кто после 4-х лет — как после этого называть? Вот и дают сразу миддла.
С сеньорами та же история. Многие, ой как многие, этим словом только называются.
Нет жестких критериев для формально-точного определения квалификации.
В пределах одной фирмы — да, можно оценить и прикинуть более-менее точно — «ты джун, а ты миддл».
Но универсального, пригодного для разных фирм метода оценки, чтобы оценка корректно распространялась и на другие фирмы — не существует.
Мм… Вопрос кого считать мидлом а кого джуном — довольно открытый. Как по мне мидл должен иметь опыт работы в команде, знать свой стек на довольно глубоком уровне, иметь хорошие навыки декомпозиции и решения задач, иметь представление о смежных вещах (уметь понять когда кривые требования прилетели), какие то навыки проектирования если не всей архитектуры системы, то хотя бы крупных модулей, писать чистый код (относительно), ну и стандартные вещи вроде представления как работает его код на всех уровнях (пусть поверхностное, но все же), среда где код работает, сложность алгоритмов, и т.д. и т.п. Если вы до всего этого дошли сами — рад за вас, я 4 года уже работаю с половиной и до сих пор не совсем в мидла перешел.
Официально должность правда старший программист, но это у нас какая то странная градация: стажер-программист(пол года)->программист->старший->ведущий (правда он уже код практически не пишет).
Умудрился еще забыть: знание подходов и архитектур принятых на стеке технологий на котором этот человек пишет, несколько реализованных крупных проектов, знание широко используемых библиотек и подобного, желательно знание еще нескольких языков и разных парадигм программирования, умение управлять своим временем, оценка сроков задач.
Официально должность правда старший программист, но это у нас какая то странная градация: стажер-программист(пол года)->программист->старший->ведущий (правда он уже код практически не пишет).
Умудрился еще забыть: знание подходов и архитектур принятых на стеке технологий на котором этот человек пишет, несколько реализованных крупных проектов, знание широко используемых библиотек и подобного, желательно знание еще нескольких языков и разных парадигм программирования, умение управлять своим временем, оценка сроков задач.
У Вас весьма «Хардовый» мидл получается. :) Не подумайте, это ни разу не плохо, а, наоборот, хорошо, что Вы ставите высокую планку (прежде всего, себе, как я понимаю). Это круто, наверняка, с таким подходом Вы — специалист довольно хороший.
Знание нескольких языков (синтаксисов) — тут очень по-ситуации. Например, мало кому из дотнетчиков нужно что-то кроме Шарпа, XML, HTML, SQL, JSON ну и если он — фулстек, то ещё базы по JS (как правило, в виде JQuery). Но вот C++, Python и т.д. едва ли там пригождаются.
Знание нескольких языков (синтаксисов) — тут очень по-ситуации. Например, мало кому из дотнетчиков нужно что-то кроме Шарпа, XML, HTML, SQL, JSON ну и если он — фулстек, то ещё базы по JS (как правило, в виде JQuery). Но вот C++, Python и т.д. едва ли там пригождаются.
Ну, что то можно заскриптовать — тут полезными окажутся баш и питон, поправить на фронте — js, я вот работаю с 1с, но по необходимости и внешнюю компоненту на плюсах напишу, и простое андроид приложение (правда не на котлин, его еще не смотрел, на dart+flutter или java). Конечно я это сделаю с меньшим качеством чем тот кто на этом специализируется, но иногда не все удается сделать средствами имеющейся на руках платформы/стека, и тогда можно что то запилить на другой технологии.
Или взять C# — может быть полезным кроме SQL решений иметь представления о паре NoSQL решений (ключ-значение, колоночная). Хотя бы иметь представление что такое есть, в каких задачах может помочь и куда гуглить.
Или взять C# — может быть полезным кроме SQL решений иметь представления о паре NoSQL решений (ключ-значение, колоночная). Хотя бы иметь представление что такое есть, в каких задачах может помочь и куда гуглить.
А что же в вашем представлении сеньор? )
Все то же самое но уже далеко не поверхностно (знание технологий, платформ, языков на уровне эксперта), большой опыт работы с крупными проектов, глубокое знание предметной области (будь то ОС и железо или продажи и реклама), более глубокие знания CS, немного навыков менторства и руководства, что то такое.
P.S. Возможно стоит еще добавить что лично себя я стал считать похожим на джуна где то спустя года 2 с копейками работы)) Хотя как по мне еще и не полноценным на тот момент)
P.S. Возможно стоит еще добавить что лично себя я стал считать похожим на джуна где то спустя года 2 с копейками работы)) Хотя как по мне еще и не полноценным на тот момент)
Вы, видимо, весьма строги к себе. :)
Не, просто стараюсь здраво оценивать. Я вообще удивлен что меня взяли работать, а по окончанию стажировки не уволили. Дуб дубом же был. И сейчас не сильно лучше, но хоть научился маскироваться да какие то навыки набрал.
Не, вряд ли, я прикидывал. Какие то его элементы есть скорее всего, но я наоборот боюсь что у меня по эффекту Данинга-Крюгера даже те области о которых я, по своему мнению, имею представление — хуже чем я представляю. Трудно оценить знания и навыки если не сменил еще несколько мест работы и круг общения профессиональный довольно узок (только коллеги в своем и соседнем отделе, которые тоже не сказать что много где работали).
Это уже синерский уровень.
Как по мне это любой средненачинающий мидл в своей копилке иметь должен.
Вот это зачем? Типа пишешь ты такой на питоне или жс и должен знать, как оно в байт код компилится?
Не обязательно в деталях, но иногда и знания о промахах кеша могут на практике пригодиться например. Или например что в случае если мы обходим несколько миллионов элементов и у нас нет умной компиляции которая заинлайнит вызов метода внутри цикла мы сильно просядем. Или о соотношении времени доступа (кэш, память, диск). Или о функционировании ОС.
Тоже ни разу не пригодилось, хотя для приличия пыталась зубрить сортировочки.
Ну оценить на глаз сложность и без изучения действительно обычно просто. А вот «зубрить сортировочки» смысла нет как по мне. Полезней изучать подходы к созданию разных алгоритмов. «Разделяй и влавствуй» там, динамическое программирование и подобное. (К сожалению в части алгоритмов я очень плох)
Как по мне это любой средненачинающий мидл в своей копилке иметь должен.По-моему, ваше понятие «средненачинающий миддл» отличается от среднерыночного.
Полностью согласен! Возможно, уважаемая julia4545 не обратила внимания на то, что использует понятие сложности алгоритма при принятии решения «использовать std::map или std::unordered_map».Тоже ни разу не пригодилось, хотя для приличия пыталась зубрить сортировочки.Ну оценить на глаз сложность и без изучения действительно обычно просто. А вот «зубрить сортировочки» смысла нет как по мне. Полезней изучать подходы к созданию разных алгоритмов
Человек не может в одиночкуА кто сказал про «в одиночку»? Естественно в команде, отвечая за какие подсистемы (проектирование, согласование и собственно реализация).
Но вы же про глубокий уровень и под «парадигмами», наверное, подразумеваете функциональное программирование.
Не сказал бы что про глубокий. Скорее про то что парадигмы стоит знать и применять по месту подходы из них если есть возможность. И не только функциональное, еще процедурное, нормальное ООП, аспектно-ориентированное, может где то логическое.
Вот, как выглядит «чистый» код для меня до сих пор загадка, наверное, каждый проецирует на это свой стиль.
Главное чтобы он был читаемым, соответствовал принятым на проекте стандартам, следовал общепринятым паттернам и подобное.
> Это вообще только на конкретной работе с конкретным постановщиком задач приходит, т.к. надо просчитывать время тестирования, учитывать их любовь менять требования и присылать на переработку.
Это уровень ПМ-а, может тимлида, но никак не обычного разработчика, оценивать организационные и прочие риски, не связанные с кодом. Или риски возврата кода с QA или CR.
Это уровень ПМ-а, может тимлида, но никак не обычного разработчика, оценивать организационные и прочие риски, не связанные с кодом. Или риски возврата кода с QA или CR.
Sign up to leave a comment.
Так ли хороши джуны?