Комментарии 104
Ты гуглишь и вставляешь найденный код, иногда не разбираясь, как он работает. Так называемый «Google-программист» на парт-тайме. Ты не учишься.
Это всё потому что на работе на это нет времени, задачи требуется выполнять побыстрее. А учатся чему-то зачастую на своих pet проектах.
Если вы постоянно заняты, скорей всего, вы не используете главный инструмент — ваш мозг
Странное утверждение. То есть если разраб не гуглит, а постоянно занят разработкой велосипеда с нуля, значит он не занят?
Вы неправильно поняли контекст.
Речь идет о том, что если Вас постоянно загружают на работе (при 40 часовой рабочей неделе, условно) и Вы все 40 часов постоянно кодите и не изучаете новые для себя вещи вокруг вашего языка/фреймворка/того что стоит вокруг Вашей работы, то Вы не используете свой мозг.
Работа программиста - постоянное развитие. Если Вас грузят 40 из 40 часов в неделю и не дают продохнуть, а только закидывают задачами и не дают расти - нужно покидать такую компанию/команду как можно раньше.
А главный совет для джунов - идти туда, где есть опытные люди из Вашей сферы, чтобы было учиться у кого-то конкретного.
У меня есть опыт 3-ёх лет содержания пет-проектов, но ничего лучше, чем обучения у опытных людей, я не нашел.
Это как в спорте - у каждого спортсмена всегда есть тренер, который может взглянуть со стороны. Так и в программировании - должен быть наставник-ревьювер, который сможет как оценить качество кода, так и оценить качество решения со стороны бизнеса/постановки задачи.
Я меня лично процентов 90% знаний, полученных именно в процессе решения задач.
Никто и не исключает знания, полученные в процессе решения задач.
Только суть в том, что если Вы изначально учитесь у более опытного человека, который уже варится в том направление, которое Вам необходимо, это гораздо сильнее ускорит Ваш процесс обучения, нежели тыкание во всё подряд в принципе, если у Вас, конечно, изначально стоит цель стать таким же, как тот разработчик, у которого Вы учитесь.
Условно говоря, "если Вы работаете с шестью сеньорами, то, скорее всего, Вы станете седьмым".
А главный совет для джунов - идти туда, где есть опытные люди из Вашей сферы, чтобы было учиться у кого-то конкретного.
Ну, это справедливо не только для джунов, а IT это постоянное развитие. Но в любой компании, которая уже не стартап, накапливаются рутинные задачи, которые приходится кому-то делать и они уже порой составляют большую часть. Ну а джунам зачастую и дают по началу такие рутинные задачи, чтобы в проекте освоиться. Пилить что-то с нуля это уже следующий уровень.
А может вариант с ментором хорошо подходит экстравертам, но плохо - интровертам? Что заставило вас думать, что ваш опыт легко экстраполируется на всех других инженеров?
Понятия «джуниор», «миддл» или «сеньор» — это субъективные понятия грейда по оценке компании/руководства.
Не спорю, можно быть самозванцем, называя себя сеньором JS разработчиком, будучи 5 лет единственным фронтендером в компании и выполняя работу так, как компания требует.
Но даже здесь есть проблема, что человек работает в компании и его все равно кто-то оценивает.
Если у человека есть какой-то грейд — значит, его уже кто-то оценил. И неважно, экстраверт он или интроверт. Так же и на перспективу, чтобы человек вырос из джуна в миддла, согласитесь, его должен кто-то оценивать, логично?
Такая оценка должна производиться условно постоянно и по коду, и по архитектурным решениям, и по бизнес-решениям (кто-то, например, моя компания, еще считает, что сеньор должен быть не только разработчиком, но и управленцем).
Под постоянным надзором опытных людей гораздо проще выявлять ошибки, так как их видно со стороны через призму опыта.
Я не отрицаю, что, в теории, можно стать сеньором, будучи одним разработчиком, изучая все вокруг себя. Но, имхо, я все еще такого мнения, что конкретные опытные люди гораздо проще и быстрее смогут указать на ошибки и направить джуна в нужное русло, если изначально у компании стоит задача выращивать специалистов, чтобы решать сложные задачи, а не просто делать рутину вечность.
Не увидел ответа на вопрос - почему вы полагаете ваш собственный опыт подходящим для других людей? Любой рассудительный здравомыслящий человек с возрастом начинает понимать, что то, что сработало для него - не обязательно сработает для других. И не строит безапелляционных правил типа "опытным разрабом можно стать только с ментором" или "мы нанимаем только с ВО" и т.д. Вот и вы постарайтесь стать таким рассудительным, мой вам совет.
Есть масса способов перенимать опыт других людей (список конечно неполный): книги, статьи, конференции, код ревью, разбор чужого кода, да просто напросто - самоанализ. Если владеть достаточным уровнем рефлексии, то тоже можно многому научиться, так как самые лучшие умы двигают практики разработки вперед основываясь только на саморефлексии.
Я четко ответил на ваш вопрос.
Грейд — это оценка по требования компании. Каким бы ни был разработчик — открытым или закрытым к общению — оценка извне это важный критерий, по которому необходимо двигаться. Чем более глубокая эта оценка и чем чаще она происходит — тем быстрее происходит рост, если человек хочет двигаться в компании.
Джун — это грейд, в статье говорится о нем, и я комментирую и отвечаю все относительно вокруг этой статьи. Чтобы стать выше, чем джуном — нужно постоянно оцениваться.
Поэтому, повторю в третий раз. Чтобы вырваться из грейда «джун», нужно иметь четкий опыт, который будет складываться из код-ревью, а так же оценки технических и бизнес-решений в компании. Ментор или даже обычный ревьювер в разы ускоряет этот процесс.
И еще раз повторю, неважно, открытый этот человек или закрытый. Это неизбежный процесс роста в компании. Потому что грейды — это условные требования компаний, а не какой-то абсолютный показатель, и для этого в любом случае нужна оценка извне.
Требования у каждой компании разные.
Разные: стек, код-стайл, подход, архитектура, решения, инструменты, управление и еще множество факторов
Как Вы сможете узнать требования компании к росту, если Вы не будете постоянно оцениваться? С учетом того, что даже инструменты и подходы могут меняться каждые полгода на каком-нибудь JS?
В той компании, где я работаю на Go, есть требования по софт-скиллам для управления (буквально, начиная с миддл+), к пониманию построения архитектуры базовых веб-сервисов, паттернов проектирования, знания языка, его работы с памятью и т.д.
В то же время в какой-нибудь компании, которая занимается объявлениями, небезызвестной, есть очень большие требования по знаниям алгоритмов, микросервисных архитектур, но так же совпадают знания языка и мелких паттернов проектирования.
Согласитесь, что если у меня есть знакомый там, который четко мне скажет, какие явные требования есть у него в команде, то у меня будет больше шансов подтянуть конкретные навыки, чем если бы я шел туда без явной явной оценки, с чем мне предстоит работать?
Имхо, это очевидно
Поэтому я четко еще раз толкну мысль, что грейд — это оценка компании. Компания, в большинстве случаев, это одна или несколько команд, в которой должен быть опытный человек, чтобы здраво оценивать знания и силы своих сотрудников относительно решения задач.
Если такая компания маленькая, а оценки извне нет, то грейд будет волей случая, потому что Вы можете работать на одном стеке, со своим код-стайлом и не общаясь с людьми вовсе, а в компании с требованиям к миддлам, есть четкое требование софт-скиллов и взаимодействия с командой, а Вы по этим софт-скиллам можете даже под стажера не подходить.
Только не зная об этом, как Вы к этому придете? Разве не очевидно, что конкретный человек, работающий в той компании, в которой Вам нужно расти, если укажет Вам на ваши конкретные ошибки — это ускорит Ваш рост?
А почему интроверт – обязательно тот, кто изучает только всё вокруг себя? Есть же книги всякие, форумы... Можно всё это читать/слушать, и отвечать самому/спрашивать что-то по минимуму. Сохраняя при этом позицию интроверта, и учась у других. Самый банальный пример, Перельман очевидно интроверт, но это же не значит, что он постиг все свои знания исключительно методом проб и ошибок =)
Задача выполняется с той скоростью, с которой она выполняется, быстрее невозможно. Быть «недостаточно быстрым» однозначно лучше, чем быть «копирующим говнокод не вникая в детали».
Текущая задача тебя интересует только с точки зрения взаимодействия с ПМом и/или тимлидом, в отрыве от всего проекта - формально сделал, остальное меня не касается.
Копаешь от забора и до обеда.
Если нет текущих задач, то молча занимаешься своими делами.
Это, скорее, не джун, а совсем наоборот очень опытный и зрелый синьор :D
Тыканье во всей статье звучит весьма высокомерно.
"Тыканье" задано уже темой в заголовке: "15 причин, почему ты всё ещё джун". Единообразие текста - похвально)
У тебя с этим проблемы?
Вывод из прочитанного - все мы немного джуны вне зависимости от формально занимаемой позиции. А кто-то даже не немного.
А можно, пожалуйста, уточнить кто такой джун и мидл в контексте статьи?
Junior разработчик – это новичок с опытом от 6-12 месяцев, который знает базовые конструкции. Он может самостоятельно сделать простую программу, дописать или протестировать код, внести небольшие правки.
Мидл (middle) — средний специалист. Это основной разработчик, который выполняет поставленные задачи почти без ошибок. Знает языки программирования и использует дополнительные технологии — например, backend-разработчик погружается во фронтенд и учит Angular
backend-разработчик погружается во фронтенд и учит Angular
А Senior по вашему познает дзен и начинает писать на любых языках и технологиях? Если разработчик будет погружаться в соседние сферы он станет человеком с более большим кругозором, а не более квалифицированным в своей сфере.
Вот поэтому в статье каша из обработки ошибок и веры в себя. Но, похоже, ответ авторы мы не увидим.
один из признаков созревания Джуна - с ним переходят на "ты".
>Общий настрой - «моя хата с краю»
Должность у меня - джун, зарплата джунская, а переживать/гореть на работе я должен как со-инвестор? Спасибо, нет.
Можно подумать, если человеку пофигу на результат своей работы в период джуниорства, то в нём что-то поменяется, когда (или скорее если) он вырастет до более топовых позиций :) Эта черта характера от должности не зависит, меняются лишь отмазки. Сначала "зарплата джунская", потом "задачи криво поставлены", потом "зона ответственности не моя" и так далее.
Свою работу надо делать качественно. Это не значит, что надо гореть на работе, сидеть там ночами и бесплатно перерабатывать. Это значит, что надо не забивать болт на свои ошибки, писать тесты и пользоваться ими, читать ТЗ и делать по ТЗ, а не переделывать десять раз просто потому, что реализовал не так, как в задаче, и она в итоге футболится на QA и обратно, и т.д. Просто надо ответственно подходить к своей работе в оплаченное работодателем рабочее время, не больше и не меньше.
Именно. Свой работу. Писать или спорить о кривости тз, продвигать продукт, искать инвесторов - мне вообще не интересно. Я маленькая шестеренка и хорошо передаю момент. В ролексе я или в лифтовой шахте мне все-равно. Если надо крутиться в экзотической среде - пусть об этом напишет в ТЗ тот, кто за это деньги получает.
Я видел жизнь. "Мы одна команда" только когда надо жопу рвать или потерпеть. Как лавры делить - сразу нет.
Писать или спорить о кривости тз, продвигать продукт, искать инвесторов - мне вообще не интересно
Понимаете, продвигать продукт, искать инвесторов - это никоим боком не касается качества вашей работы, и вообще вашей работы как программиста. А писать или спорить о кривости ТЗ, это прямо и непосредственно часть вашей работы. Скажите, как далеко вы пошлёте мастера-отделочника, который вам не укажет, что купленный вашим прорабом клей не подходит для купленных обоев, и молча приклеит тем, что ему подсунули, и оно отвалится через пару дней?
Я видел жизнь.
Жизнь, она, знаете ли, разнообразна. И команды, и коллективы, и начальство, и подчинённые - их миллион разных сочетаний. А что касается делёжки "лавров" - вы на новоселье мастера-отделочника будете приглашать? Или зарплаты+премии за качественную работу ему хватит?
А за что в описанной схеме получает деньги прораб?
Вася ушел в запой и ему срочно нужна замена. Петя поспорил с Олегом и набил ему морду. Поставщик кинул с материалами и привез не то что заказано было. Водопроводчики забили и ничего не делают, а уже пора поверх труб плитку класть. Заказчик снова требует все сделать по другому, он с женой посоветовался.
Проекты это сложно. Если за рядового работника надо разруливать все мелочи, которые он сам мог бы разрулить, то на все остальное времени не хватит.
За то, чтобы надавать по шапке такому нерадивому отделочнику.
Что касается джунской зарплаты, то статья как раз про то, как сделать её не джунской
ТЗ это как раз часть вашей работы. Если вы джун, а вам дали нечеткое ТЗ, то это может быть проверкой на мидла. Сеньорам ТЗ могут вообще не давать, просто сказать - чтобы вот тут было все хорошо. И он сам пишет ТЗ, а потом еще и согласовывает его бывает. Если оно бизнес задевает.
Я видел жизнь. "Мы одна команда" только когда надо жопу рвать или потерпеть. Как лавры делить - сразу нет.
Большие премии вы же хотите получать? Настоящие, а не те которые как часть зарплаты. Вот это как раз про лавры и успех.
Повышение тоже где-то тут. Когда нет успеха кого-то повышать как-то странно. Только если люди разбегаться стали.
Так нет никаких вопросов - нравится быть шестерёнкой, передающей момент? Это же прекрасно! Каждому свое. Как я понял, статья адресована там, кто хочет выйти за пределы одной степени свободы и начать заниматься более интересными и высокооплачиваемыми задачами.
А зачем тогда идти в it? По деревне ходит слух что смена работодателя = повышение зп. А как менять работу = повышать зп, если скилл константа? Выход один - ждать когда средняя зп джуна по рынку подрастет и упрыгать в другое место джуном? Только потолок низковат, да и на собесах малый скилл и большой стаж не в плюс мне кажется. Таков план? Я просто не знаю мест где пробиваются не напрягая булки... Я не джун, а только учусь. 2 месяца. И я надеюсь и напрягаю булки))) И поверьте, я повидал не меньше Вас! Желаю успехов!
В этот заголовок можно вложить разный смысл, что подтверждает комент про зрелого сениора с 42 плюсами. Автор статьи вложил другой смысл. И я его испытываю прямо сейчас при работе с джунами - делает четко то, что написано в задаче. Шаг вправо/влево - все, не его забота. По итогу получается хрень. Видимая причина - это конечно качество постановки задач. Но я не могу расписать в задаче все, с чем джун/мидл столкнётся, пока будет ее делать. Я ожидаю что у него есть своя голова на плечах. С другой стороны - если я буду подробнейшем образом расписывать, что надо сделать (а для этого по факту, мне надо самому решить эту задачу), то мне проще и быстрее самому все сделать.
Отсюда я могу сделать вывод, что джуны к месту либо в крупных компаниях, либо там, где есть выделенный ментор.
Видимая причина - это конечно качество постановки задач. Но я не могу расписать в задаче все, с чем джун/мидл столкнётся, пока будет ее делать.
Где-то на этом сайте был комментарий, который мне запомнился. Там было сказано что-то вроде "мидл поставит задачу и распишет юнит-тесты для джуниора, а джуниор просто набьет код и закодит эти самые юнит-тесты".
Может, вам недостает именно что мидл-программистов в команде? Ведь с ними все в порядке, ибо вы упомянули, что (проблемные ситуации) испытываете только с джуниорами:
я его испытываю прямо сейчас при работе с джунами
Шаг вправо/влево - все, не его забота. По итогу получается хрень.
На самом деле, есть те кто не хочет делать лишнюю работу, даже если умеет, некоторые могут хотеть, но не знают как нормально сделать или на что нужно обратить внимание. Иногда на самом деле виноват конкретный сотрудник, а иногнда тот кто ставит задачи или контролирует их выполнение, от ситуации всё зависит.
Это ровно то, о чём я говорил не раз. Джун - это или стажёр (которого целенаправленно учат в рабочее время и у которого обучение, явно или неявно оформленное - прямая часть рабочих обязанностей), или подмастерье. Во втором случае он занимается тем, что помогает мастеру: выполняет несложные задачи, где невозможно накосячить, но тратить на них время и ум специалиста непродуктивно. Он "подаёт патроны": иногда программирует, иногда сисадминит, иногда за батарейками для мышки в магазин бегает. Попутно ему, если толковый, могут постепенно выделять всё более сложные задачи.
Ну а оценка джуна как мини-мидла или начинающего сеньора ошибочна. В этом случае он просто окажется не на своём месте и будет очень плохим работником.
Насчет стажера согласен. Насчет джуна - под вопросом, холиварная тема.
В любом случае - у человека опыт был 2 года, сейчас уже ближе 3. Т.е. это типа мидла. На собесе был норм. А по итогу...
На той неделе была задача - сделать обязательные поля на форме (в смысле поля уже есть, надо их сделать обязательными, с проверкой, подсветкой). Это же ведь не задача для сениора? Ведь правда? Вопрос от него "их помечать звездочкой", говорю "да, у нас по всему проекту такие поля в label помечаются звездочкой". Сделал.
Я делаю ревью кода, запускаю, захожу на форму, звездочки есть да, поля пустые, жму "Сохранить" - и все без вопросов сохраняется, без подсветки, без ошибок. Щта? Любой человек, даже не программист, сталкивается с обязательными полями, когда заполняет что-либо на сайтах в интернете.
Должность у меня - джун, зарплата джунская, а переживать/гореть на работе я должен как со-инвестор?
Почему? Речь только, чтобы быть вовлечённым хотя бы в рамках своей ответственности. В противном случае двигаться и в карьерном, и в профессиональном плане очень сложно.
Статью тоже джун писал?
Никто никогда ничего не понимают. Скажут что задача была нерешаемой или персонал плохой и закроют лавочку. Если хочется быть против всего плохого за все хорошее, то всегда лучше работать ради результата даже среди тех кто не понимает. Если никто не может это оценить, будет другая компания где оценят.
Ради результата работают во фрилансе, а на работе работают так. Когда то мечтал работать на результат, но это никому не нужно, да и проще работать на хорошую зарплату чем на результат
Думаю все верно подмечено. Нашел в статье несколько пунктов, которые описывают мое состояние при работе с джунами.
Но есть проблема.
Пассивное отношение к макету
На подобные замечания мне отвечают «ой а я не так не подумал», «ой а я не догадался», «ой а это не пришло мне в голову». Хотя каждый раз говорю, чтоб пользовался головой и здравым смыслом. И начинает складываться ощущение, что корень проблемы лежит в другой плоскости.
Причем, когда я пытаюсь вспомнить каким я был джуном — не помню такого. Было незнание технологии, или каких-то фишек/хаков, фигачил весь бизнес код в обработчике button1_Click. То есть технические вещи.
>пассивное отношение к макету
Ага, вот взял такой, включил активность, налепил отсебятины и понеслась. Потом с тебя же за нее и спросят, когда малейшие правки придут в отдел, спустивший кривой макет, а они встанут в позу "это не мы, мы все ок сделали по тз, это джун ваш накосячил!"
Нашёл косяки в макете - отправляешь макет на доработку с комментариями. А иначе ловим накапливающуюся ошибку, которая градиентом ложится на несколько отделов, и хрен пойми, кто там что должен править, откуда куда коммитить и кто с кем согласовывать.
Человек, писавший статью точно понимает, как это работает?
проблема "болезненности мыслительного процесса".... Т.к. по другому объяснить почему собственно иногда вполне умные и здраво рассуждающие люди не способны думать за рамками какой-то фиксированной задачи/парадигмы/процесса я немогу..... просто пока всё привычно истанадартно Люди справляются и всё ок чуть в право влево и вс
Типичный высер некомпетентного тимлида и/или начальства чуть приправленный прописными истинами для важности. Если заметили такое, бегите - будут ездить.
Джун должен постоянно учиться, но при этом бегать и выпрашивать задачи + ставить задачи другим... У джуна есть тимлид, дизайнер, дизайнер UI, ... не должен он вдруг вместо простого окошка делать светофор, потому что у него появилось чувство прекрасного.
Каждый дожен делать свою работу.
Вы точно эту статью читали?)
так Джун может и прод весь нагнуть исправляя в нем чей-то баг)))
Безусловно. Каждый делает свою работу - и остаётся в той роли, в которой был вчера. Когда расширяешь сферу своей ответственности (не забывая об этом напоминать при случае!) начинает меняться должность, доходы, компетенция. Если это не нужно - то всё правильно, делаем свою работу, не приносим фидбэк тимлиду, дизайнеру и т.д.
Только в мире розовых пони. В реальной жизни хозяинубизнеса/менеджерам/тимлиду/... нужен результат и снижение расходов. Если вы делаете 20 задач, а ваш сосед 10 за тоже время и деньги, то делать вы будете завтра и 30...
Фидбэк тимлиду/дизайнеру/... идет в задаче/трекере/... Никто не говорит, что не надо делать СВОИ задачи. Не передергивайте.
После того, как условный джун или мидл учится новым компетенциям, а работодатель это не вознаграждает соответственно, в наши дни всё ещё несложно сменить работодателя с повышением должности и финансового благополучия.
По крайней мере в том мире розовых пони, в котором живу как я сам, так и мое окружение, это прекрасно работает. Если ваш мир не таков, то может быть есть крохотный шанс, что дело всё-таки не в мире?
А откуда по вашему берутся сеньоры? Это как люди которые делали больше и лучше обычно.
Ну да, ну да... Растут и должности у нас получают только выдающиеся и лучшие.
"Ты молод душой"
Я бы ещё добавил:
долбаная удалёнка!
При всех её преимуществах, она таки тормозит джуна:
ты уже год в компании, но с трудом представляешь кто чем занимается за исключением 1.5-2 человек, с которыми ты общаешься +/- регулярно;
тебе неуютно задавать вопросы своим т.к. всё время (хрен знает чем) заняты, проще наяндексить или спросить на Хабр КуА;
ты понятия не имеешь как это принято делать у вас в команде и поэтому твои решения - скорее велосипеды со SOF;
ты мучительно думаешь как бы подкатить к шефу на тему апгрейда з/п, хотя вроде давно пора и есть что предъявить, но фиг его знает чем он сейчас занят и уместен ли этот разговор в данный конкретный момент.
Конечно, есть разные компании с по-разному настроенными процессами, но если джун трудится в маленькой компании, эти проблемы, скорее всего, актуальны.
Не соглашусь. Есть нормальные командные синки + общение со своими в ЛС и по видео.
У меня с 2020 три стажера до миддлов поднимались (Business intelligence) - что я делаю не так?
@F0iL , я же не говорю что невозможно. Просто одно дело когда ты видишь что коллега занят, аж дым из ушей, а когда он более-менее на расслабоне и можно к нему подсесть со своим блокнотиком. И другое дело когда вот эти вот коммуникации. Конечно, пользуемся тем что дают (ну, потому что другого ничего не дают), но мы тут обсуждаем статью о том что нас притормаживает - и таки удалёнка в ряде случаев притормаживает.
@Trabant_Vishnya,несомненно, всё делаешь так :) Но! Ты со своими джунами делаешь один проект, т.е. вы занимаетесь одним и тем же - просто на разном уровне сознания. А вот другая ситуация. Есть сильно_легаси проект и его уже не спасти. Но на него завязаны многие клиенты, более того, новые клиенты тоже его хотят. Принято решение грызть слоника по частям. Т.е. берутся некоторые функции и переносятся на современный стэк. Через некоторое время эти функции отключаются у "старого" приложения и ему становится лучше :) Так вот, под наработку новой базы набраны люди и им выдаются задания (пока основной коллектив занят поддержкой и новыми внедрежами). Только эти задания не вида "напиши класс" или "поправь метод", а вида "напиши сервис". С одной стороны это здорово: от тебя не ждут что ты поспеешь в спринт (у тебя и спринтов-то нет), плюс - тебя практически не ограничивают в технологиях, плюс - ты свой сервис можешь проверить в сравнении с уже существующим. С другой стороны - от тебя требуется совсем другой уровень самостоятельности, причём сразу на входе. Бессмысленно у коллеги спрашивать про классы и методы, максимум "а как оно должно работать?" или "это я глюк в старом приложении нашёл или оно так и задумано?". Так же бессмысленно задавать общие вопросы по стэку - ты быстрее найдёшь ответ на SOF. Или "а что это у меня на 300 тыс записей всё летает, а на 30 млн тормозит?". Какой тут ответ? "Смотри что там у тебя с запросами". Ну вот, сижу и смотрю :)
Да, конечно, и в этой ситуации можно наладить процессы и вот это всё. Только ведь джун работу не выбирает, это работа выбирает джуна :) Поэтому воду в бассейн нам сразу налили, учимся плавать в этих условиях :) А удалёнка нам тут скорее гирек добавляет чем жилет надувает.
А почему джун вообще задачи такого уровня в одиночку делает? Может тут дело не в удаленке все же, а в процессах и нагрузке как таковой?
Или в офисе второй мозг отрастает?
В офисе отрастает "перекинуться парой слов с коллегой, видя что он в данный момент не шибко занят". Я, правда, не работал программистом в офисе, мне досталась сразу удалёнка. Но раньше работал в офисе инженером и знаю что это хорошо помогает от тупняка :)
Правда, в офисе есть опасность: видя что ты на месте, на тебя набигают и ограбляют отвлекают. Но это только если есть смысл, т.е. ты много знаешь. Поэтому для опытного сотрудника удалёнка идеальна. А для джуна - нет :)
Легко свалить все на удаленку, но в чем проблема сказать начальнику что за год онбординг не провели и непонятно кто чем занимается? Это в офисе проблема когда начальник все время на совещаниях и у тебя нет его номера, а на удалёнке написал в ЛС в слаке "Пора мне поднять зарплату" и все, сидишь ждёшь когда поднимет
Частично соглашусь. Чтобы зарплата не жала, лучше сразу залететь на миддл, а вот дальше кстати не всём хочется, мне вот совершенно мне удобно миддлом. Ну есть немного только желание качать навыки, а так не особо. Как принято в команде узнаешь почти сразу даже если делаешь одну функцию несколько дней. таки корпоративные правила сразу узнаешь. Кто чем занимается, ну тоже спорно, но конечно, если имеется ввиду не вникаешь кем кто занимается да, возможно, но уже через неделю знаешь всю команду по должностям, так как ежедневный стендап же. Неуютно что то спросить то же может быть. А по поводу зарплаты тут лучше сразу заходить по рынку, есть варианты его узнать что бы потом не печалится.
В целом применимо и не к ИТ - если ты показываешь инициативу и сообразительность ты по возможности идёшь выше. Правда есть тонкая грань, есть уровень самостоятельности при котором ты уже раздражаешь руководство или, упаси хоспаде, создаёшь ощущение что ты конкурент...
джун=js разраб чтоли?
Да на хабре нынче половина статей молча предполагает разработчик=web-разработчик. Про других видимо не слышали.
Здесь ещё ситуация более-менее - всего 4 пункта касаются веба. Натыкался на статьи "10 антипаттернов в разработке", где речь шла про один какой-то фреймворк, а даже не js в целом.
Всё верно, уважающий себя человек с Javascript работать не станет. /s
Все еще джун человек может быть только из-за зарплаты. И останется джуном, пока не сможет продать себя дороже. Остаться слабым разработчиком и лидом при этом можно даже собрав все лычки и топ 1% зарплаты, что обычно подтверждают подобные статьи.
Если хочется развиваться как специалисту, то и развиваться надо как специалисту в любой области, - наращивать компетенции, собирать шишки, красть опыт и знания у всех, до кого только удастся дотянуться. Вступать в диалог, проигрывать, рисковать. Находить баланс жизни, знакомства и делать жизнь ярче и интереснее.
Работа программиста - делать то, что нужно для проекта. Иногда - копать, иногда - развиваться, иногда не спать ночью, потому что так лучше для клиента. Всякое бывает, сложная у нас профессия.
Зашёл почитать про джуна в разработке в целом, а тут описывается конкретный джун в вебе
Одного своего желания мало. Можно стать заложником ситуации. А плюнуть и послать всех "на..." чтоб развиваться не позволяет, например, ипотека.... Такое цифровое рабство :)))
Если не считать что автор сделал упор на фронт разработку (примеры не абстрактны), то очень неплохая статья! Можно с некоторыми правками включить в проект на вики дабы "молодняк" мог ознакомиться с указанными принципами ответственности:)
Прекрасный Хаброредактор.
1. Выделяем -копируем заголовок "15 причин, почему ты всё ещё джун"
2. Вставляем в поле комментария
3. Профит - не можем ни изменить, ни удалить, ни отправить Только перезагрузка страницы.
зы. Яндекс браузер, если важно.
В этой статье прекрасно все. :)
По всем пунктам не джун. Почему я ещё не синьор помидор?
Ну попадание не более 40%, мало того что пример только для фронтенда и в беке задачи несколько другие. Зато убер синьоры обращают внимание на всё что угодно, кроме логики. Не то форматирование, не так названы переменные, отсутcтвие префикса const или final, недостаточная ясность в тестах, отсутствие документирования, но сама логика практически никем не смотрится если это больше 10 строчек в методах. Кое какое попадание есть, Н кто не любит без инициативных, которые закапываются в себя, но опять же, мало смотрят на логику, по моему небольшому опыту 90 а то и 95% придирок к пул реквестам - это имена переменных, отсутствие не верные префиксы, модификаторы доступа и прочая шелуха. Нет обёртки исключений или наоборот, она там где не нужна, придирки к тестам, обязательно, саму же логику реально проверяют в лучшем случае в 5% случаев. Как то так из моего небольшого опыта это так. И да хотелось бы чтобы на логику и саму работу методов да и целиком проекта смотрели чаще. В разы чаще, а не на то, на что обычно смотрят, то что описал выше.
Если ты все еще джун и тяготишься этим, просто переходи в другую контору на милорда.
Статья выглядит как список оправданий тимлида: "почему я забиваю на своего джуна, а он при этом не должен возникать и как-то сам выкручиваться". Адекватно только предложение всё время учится и самосовершенствоваться.
15 причин, почему ты всё ещё джун