В каждой приличной IT-компании уделяется достаточно много внимания развитию сотрудников. Проводятся разного рода митапы, тренинги и хакатоны для прокачки хард-скиллов, встречи на тему развития софт-скиллов (на которых сотрудникам объясняют почему панибратство и общение строго матерными выражениями - очень плохая идея), и прочие увеселительные мероприятия. Но мое внимание обратила на себя тема, которая находится на стыке этих двух навыков - хард и софт. С некоторой регулярностью мне приходится видеть перспективных ребят, которые явно засиделись в джунах. Это удручает и разочаровывает - ведь я знаком со многими из них, и отлично знаю, что у них есть все необходимое для быстрого роста. И часто причина не в чем-то одном, а в сочетании некоторых, возможно неочевидных, недостатков. Я постарался собрать здесь весь список подобных минусов, которые приходится наблюдать довольно регулярно.
Итак, что обычно мешает условному джуну подтянуться до условного мидла:
-
Нет обработки ошибок
Классика - не изучаешь тему обработки ошибок в целом и способ это делать в данном конкретном проекте. Автоматически записан в джуны.
Касаемо конкретно языка
Dart- абьюзbang-оператора. Этот оператор доступен к использованию только когдаnullне прилетит гарантированно. Другой случай непроверки наnull- выдавать сообщение об ошибке вtoString(). Прилетитnull- покажешь пользователю сообщение “null”. За такое желательно сразу расстреливать, но, так как в большинстве стран мира смертная казнь не применяется, приходится ограничиваться подобной статьей.Вообще, во внимании джуна код всегда имеет более высокий приоритет, чем то, что видит пользователь. У мидла наоборот - приоритет у UI. Потому что заказчик видит только UI и оценивает приложение в первую очередь по пользовательскому опыту.
-
Пассивное отношение к взаимодействию с бэком
Прилетает ошибка с кодом 200 - не просишь поправить. Как маленький, ей-Богу. Поле с сообщением об ошибке возвращается в рандомных объектах с рандомным названием этого поля - пилишь у себя поиск таких сообщений во всех возможных случаях, вместо того чтобы призвать бэк к порядку. В следующий раз сообщение прилетает в очередном неожиданном месте - снова ломается. Я утрирую, но мысль понятна. Прилетают одни и те же данные разрозненном виде - не просишь бэк привести их одному и тому же виду. Например, принимать и возвращать один тот же объект. В будущем это приводит к проблемам, которые нарастают, как снежный ком.
-
Отсутствие тестирования собственного кода
Вместо проверки работоспособности кода в разных условиях, ты приносишь жертвы темным силам в надежде, что всё работает как надо. Или того хуже - не думаешь о том, что нужно тестировать что ты там понаписал. Не перекладывай свою работу на тестировщика - его задача искать крайние кейсы и замечать то, что пропустил ты. Он работает вместе с тобой, а не вместо тебя.
-
Злоупотребление Google
Гуглишь и вставляешь найденный код, иногда не разбираясь, как он работает. Так называемый «Google-программист» на парт-тайме. Ты не учишься.
-
Недостаточная вера в себя
Когда сталкиваешься с более или менее сложной задачей, сразу сдаешься с формулировкой «есть люди поопытнее, надо спросить». По моим наблюдениям, больше половины вопросов джунов связаны с простой логикой, и не требуют никакого опыта. То есть он бы и сам справился, если бы верил в себя. Подход должен быть - «если не я, то кто?». Разбираешься с задачей самостоятельно, пока не заходишь в полный тупик. Тогда идешь спрашивать у опытных коллег, да и то только чтобы время сэкономить. "Разобрался бы и сам, да только времезатраты не адекватны задаче".
-
Пассивное отношение к макету
В макете указано поле ввода, хотя очевидно, что должен быть выпадающий список - ты не обращаешь на это внимание дизайнера и/или ПМа. «Там уже все решили». Этот пункт перекликается с предыдущим.У программиста всего два инструмента для решения задачи - логика и опыт
и Google. Отсутствие опыта — это не повод выбрасывать в окно еще и здравый смысл. В макете не указана кнопка повтора последнего действия при ошибке (там, где это уместно) - ты молча выводишь только сообщение об ошибке. Если не забудешь. В дизайне не указан способ обновления данных на экране - ты так и делаешь, хотя очевидно что тут нужно обновление свайпом, к примеру. И такая задача неизбежно прилетает из QA, либо от заказчика. Ты мог сделать сразу логично - но дождался пока укажут пальцем. В дизайне не указана индикация загрузки при пагинации - ты так и делаешь. А ведь достаточно посмотреть взглядом пользователя — прокрутил список до конца, ничего не происходит. Потом внезапно в конце появляются новые элементы. Отсюда вытекает следующий пункт. -
Удивляешь пользователя
Удивлять нужно девушку на 8 марта. А приложение должно обладать предсказуемым поведением, настолько, насколько это возможно. Это касается всего приложения в целом и отдельных элементов в частности. Никто не будет вести тебя за ручку и указывать на каждую мелочь. Это будет делать заказчик. После чего тебя отшлепают. Из чего станет очевидно, что на тебя нельзя положиться.
-
Общий настрой - «моя хата с краю»
Текущая задача тебя интересует только с точки зрения взаимодействия с ПМом и/или тимлидом, в отрыве от всего проекта - формально сделал, остальное меня не касается. Отсюда вытекают такие странности, как например отображение информации для пользователя с помощью всплывающего сообщения снизу на одном экране, и сверху - на другом. Ты не смотрел как там у других. “Зачем, мне и так хорошо, а то того и гляди придется поучиться чему то новому”. Ты должен смотреть на задачу как часть проекта в целом. Насколько твоя работа соответствует логике всего приложения?
-
Отношение к любой текущей задаче, как к копанию огорода
Просто объем земли, который нужно перелопатить. Копаешь от забора и до обеда. Любая задача это мини-проект, у которого есть начало и конец. К реализации нужно подходить творчески - сначала обдумать, как это сделать эффективнее, чем делалось раньше. Как сократить себе время на похожую задачу в будущем. Как это уже сделано твоим коллегой и почему именно так. Не бояться экспериментировать. Каждая задача - это материал для прокачки своих скиллов.
-
Отсутствие стремления писать читаемый код
Читаемый всеми, а не только тобой. Привык вариться в своем соку - у тебя свои приколы и привычки в коде, понятные только себе. Также ты не смотришь как написаны другие модули приложения, а пилишь очередную вариацию.
-
Пассивная позиция в компании
Ты не активный член коллектива, стремишься не высовываться, чтобы не дали каких нибудь задач. Никогда не вызываешься добровольцем. Если нет текущих задач, то молча занимаешься своими делами. Ведь молоток всегда бьет по тому гвоздю, что торчит выше других.
-
Гиперактивная позиция в компании
Противоположная крайность - ты неугомонный член коллектива, берешься за тучу задач в куче проектов. Отсюда вечная спешка. Нет времени вникать, разбираться, исправлять. Гонишься за объемом в ущерб качеству.
-
Не придаешь значения «мелочам»
У тебя вечно куча опечаток. Куча подсказок от анализатора, которые ты игнорируешь. Ну не ошибки же. А предупреждения - это для слабых духом. Твоя консоль замусорена бесполезными сообщениями на всякий случай.
-
Не делишься опытом с другими
Избегаешь роли лидера - например, работы со стажерами, где нужно подсказывать менее опытным коллегам. Мидл часто является тимлидом, навык лидерства жизненно необходим. Это не значит, что ты, будучи интровертом, должен выступать перед стадионом и рвать рубаху на груди. Достаточно базовых навыков распределения задач и работы с людьми.
-
Ты не понимаешь, что твоя работа - не только писать код
Твоя работа - учиться. Учиться каждый день и при любой возможности. Это твой стандартный подход к решению задач. Отныне и до самой пенсии.
Надеюсь, эта информация поможет вам быстрее продвигаться на пути разработчика. Happy coding.
Комментарии (88)
nronnie
17.12.2022 18:26+95Текущая задача тебя интересует только с точки зрения взаимодействия с ПМом и/или тимлидом, в отрыве от всего проекта - формально сделал, остальное меня не касается.
Копаешь от забора и до обеда.
Если нет текущих задач, то молча занимаешься своими делами.
Это, скорее, не джун, а совсем наоборот очень опытный и зрелый синьор :D
Pampam83
17.12.2022 20:18+14Тыканье во всей статье звучит весьма высокомерно.
Areek
17.12.2022 20:37+16"Тыканье" задано уже темой в заголовке: "15 причин, почему ты всё ещё джун". Единообразие текста - похвально)
geher
17.12.2022 21:27+4Вывод из прочитанного - все мы немного джуны вне зависимости от формально занимаемой позиции. А кто-то даже не немного.
olku
17.12.2022 21:48+4А можно, пожалуйста, уточнить кто такой джун и мидл в контексте статьи?
ArtemDragonsky
19.12.2022 10:15-3Junior разработчик – это новичок с опытом от 6-12 месяцев, который знает базовые конструкции. Он может самостоятельно сделать простую программу, дописать или протестировать код, внести небольшие правки.
Мидл (middle) — средний специалист. Это основной разработчик, который выполняет поставленные задачи почти без ошибок. Знает языки программирования и использует дополнительные технологии — например, backend-разработчик погружается во фронтенд и учит Angular
Layan
19.12.2022 15:29+3backend-разработчик погружается во фронтенд и учит Angular
А Senior по вашему познает дзен и начинает писать на любых языках и технологиях? Если разработчик будет погружаться в соседние сферы он станет человеком с более большим кругозором, а не более квалифицированным в своей сфере.
olku
19.12.2022 19:47+2Вот поэтому в статье каша из обработки ошибок и веры в себя. Но, похоже, ответ авторы мы не увидим.
shornikov
17.12.2022 22:41+56>Общий настрой - «моя хата с краю»
Должность у меня - джун, зарплата джунская, а переживать/гореть на работе я должен как со-инвестор? Спасибо, нет.
PuerteMuerte
17.12.2022 23:09+16Можно подумать, если человеку пофигу на результат своей работы в период джуниорства, то в нём что-то поменяется, когда (или скорее если) он вырастет до более топовых позиций :) Эта черта характера от должности не зависит, меняются лишь отмазки. Сначала "зарплата джунская", потом "задачи криво поставлены", потом "зона ответственности не моя" и так далее.
Свою работу надо делать качественно. Это не значит, что надо гореть на работе, сидеть там ночами и бесплатно перерабатывать. Это значит, что надо не забивать болт на свои ошибки, писать тесты и пользоваться ими, читать ТЗ и делать по ТЗ, а не переделывать десять раз просто потому, что реализовал не так, как в задаче, и она в итоге футболится на QA и обратно, и т.д. Просто надо ответственно подходить к своей работе в оплаченное работодателем рабочее время, не больше и не меньше.
shornikov
17.12.2022 23:50+36Именно. Свой работу. Писать или спорить о кривости тз, продвигать продукт, искать инвесторов - мне вообще не интересно. Я маленькая шестеренка и хорошо передаю момент. В ролексе я или в лифтовой шахте мне все-равно. Если надо крутиться в экзотической среде - пусть об этом напишет в ТЗ тот, кто за это деньги получает.
Я видел жизнь. "Мы одна команда" только когда надо жопу рвать или потерпеть. Как лавры делить - сразу нет.
PuerteMuerte
18.12.2022 00:01+15Писать или спорить о кривости тз, продвигать продукт, искать инвесторов - мне вообще не интересно
Понимаете, продвигать продукт, искать инвесторов - это никоим боком не касается качества вашей работы, и вообще вашей работы как программиста. А писать или спорить о кривости ТЗ, это прямо и непосредственно часть вашей работы. Скажите, как далеко вы пошлёте мастера-отделочника, который вам не укажет, что купленный вашим прорабом клей не подходит для купленных обоев, и молча приклеит тем, что ему подсунули, и оно отвалится через пару дней?
Я видел жизнь.
Жизнь, она, знаете ли, разнообразна. И команды, и коллективы, и начальство, и подчинённые - их миллион разных сочетаний. А что касается делёжки "лавров" - вы на новоселье мастера-отделочника будете приглашать? Или зарплаты+премии за качественную работу ему хватит?
plFlok
18.12.2022 16:29+2А за что в описанной схеме получает деньги прораб?
BugM
18.12.2022 16:57-1Вася ушел в запой и ему срочно нужна замена. Петя поспорил с Олегом и набил ему морду. Поставщик кинул с материалами и привез не то что заказано было. Водопроводчики забили и ничего не делают, а уже пора поверх труб плитку класть. Заказчик снова требует все сделать по другому, он с женой посоветовался.
Проекты это сложно. Если за рядового работника надо разруливать все мелочи, которые он сам мог бы разрулить, то на все остальное времени не хватит.
romash
19.12.2022 10:17+1За то, чтобы надавать по шапке такому нерадивому отделочнику.
Что касается джунской зарплаты, то статья как раз про то, как сделать её не джунской
BugM
18.12.2022 01:33+7ТЗ это как раз часть вашей работы. Если вы джун, а вам дали нечеткое ТЗ, то это может быть проверкой на мидла. Сеньорам ТЗ могут вообще не давать, просто сказать - чтобы вот тут было все хорошо. И он сам пишет ТЗ, а потом еще и согласовывает его бывает. Если оно бизнес задевает.
Я видел жизнь. "Мы одна команда" только когда надо жопу рвать или потерпеть. Как лавры делить - сразу нет.
Большие премии вы же хотите получать? Настоящие, а не те которые как часть зарплаты. Вот это как раз про лавры и успех.
Повышение тоже где-то тут. Когда нет успеха кого-то повышать как-то странно. Только если люди разбегаться стали.
Artyomcool
20.12.2022 03:04+1Так нет никаких вопросов - нравится быть шестерёнкой, передающей момент? Это же прекрасно! Каждому свое. Как я понял, статья адресована там, кто хочет выйти за пределы одной степени свободы и начать заниматься более интересными и высокооплачиваемыми задачами.
onets
18.12.2022 06:59+3В этот заголовок можно вложить разный смысл, что подтверждает комент про зрелого сениора с 42 плюсами. Автор статьи вложил другой смысл. И я его испытываю прямо сейчас при работе с джунами - делает четко то, что написано в задаче. Шаг вправо/влево - все, не его забота. По итогу получается хрень. Видимая причина - это конечно качество постановки задач. Но я не могу расписать в задаче все, с чем джун/мидл столкнётся, пока будет ее делать. Я ожидаю что у него есть своя голова на плечах. С другой стороны - если я буду подробнейшем образом расписывать, что надо сделать (а для этого по факту, мне надо самому решить эту задачу), то мне проще и быстрее самому все сделать.
Отсюда я могу сделать вывод, что джуны к месту либо в крупных компаниях, либо там, где есть выделенный ментор.
izogfif
18.12.2022 14:32Видимая причина - это конечно качество постановки задач. Но я не могу расписать в задаче все, с чем джун/мидл столкнётся, пока будет ее делать.
Где-то на этом сайте был комментарий, который мне запомнился. Там было сказано что-то вроде "мидл поставит задачу и распишет юнит-тесты для джуниора, а джуниор просто набьет код и закодит эти самые юнит-тесты".
Может, вам недостает именно что мидл-программистов в команде? Ведь с ними все в порядке, ибо вы упомянули, что (проблемные ситуации) испытываете только с джуниорами:
я его испытываю прямо сейчас при работе с джунами
onets
18.12.2022 22:07Таки мы и пытались их найти. Стоят почти как сениоры. Но не сениоры. Взяли одного 2+ опыта, типа на мидла. Вот с ним у меня как то не получается. И еще одного, возраст 60+, опыт 15+, но по итогу тоже как-то до мидла не дотягивает.
12rbah
19.12.2022 08:26Шаг вправо/влево - все, не его забота. По итогу получается хрень.
На самом деле, есть те кто не хочет делать лишнюю работу, даже если умеет, некоторые могут хотеть, но не знают как нормально сделать или на что нужно обратить внимание. Иногда на самом деле виноват конкретный сотрудник, а иногнда тот кто ставит задачи или контролирует их выполнение, от ситуации всё зависит.
StjarnornasFred
19.12.2022 10:19Это ровно то, о чём я говорил не раз. Джун - это или стажёр (которого целенаправленно учат в рабочее время и у которого обучение, явно или неявно оформленное - прямая часть рабочих обязанностей), или подмастерье. Во втором случае он занимается тем, что помогает мастеру: выполняет несложные задачи, где невозможно накосячить, но тратить на них время и ум специалиста непродуктивно. Он "подаёт патроны": иногда программирует, иногда сисадминит, иногда за батарейками для мышки в магазин бегает. Попутно ему, если толковый, могут постепенно выделять всё более сложные задачи.
Ну а оценка джуна как мини-мидла или начинающего сеньора ошибочна. В этом случае он просто окажется не на своём месте и будет очень плохим работником.
onets
19.12.2022 13:56+2Насчет стажера согласен. Насчет джуна - под вопросом, холиварная тема.
В любом случае - у человека опыт был 2 года, сейчас уже ближе 3. Т.е. это типа мидла. На собесе был норм. А по итогу...
На той неделе была задача - сделать обязательные поля на форме (в смысле поля уже есть, надо их сделать обязательными, с проверкой, подсветкой). Это же ведь не задача для сениора? Ведь правда? Вопрос от него "их помечать звездочкой", говорю "да, у нас по всему проекту такие поля в label помечаются звездочкой". Сделал.
Я делаю ревью кода, запускаю, захожу на форму, звездочки есть да, поля пустые, жму "Сохранить" - и все без вопросов сохраняется, без подсветки, без ошибок. Щта? Любой человек, даже не программист, сталкивается с обязательными полями, когда заполняет что-либо на сайтах в интернете.
RH215
19.12.2022 02:17Должность у меня - джун, зарплата джунская, а переживать/гореть на работе я должен как со-инвестор?
Почему? Речь только, чтобы быть вовлечённым хотя бы в рамках своей ответственности. В противном случае двигаться и в карьерном, и в профессиональном плане очень сложно.
aktuba
18.12.2022 01:59+7Пассивная позиция в компании
Сорян, но это не критерий джуна. На паре прежних мест работ я не только занимал "пассивоную" позицию, я искренне хотел, чтобы текущий проект провалился. Нет, я не хотел зла компании, я хотел, чтобы на основе провала мелкого, внутреннего, проекта люди поняли - надо работать не ради "работы", а ради результата.
amazed
18.12.2022 04:46+2Никто никогда ничего не понимают. Скажут что задача была нерешаемой или персонал плохой и закроют лавочку. Если хочется быть против всего плохого за все хорошее, то всегда лучше работать ради результата даже среди тех кто не понимает. Если никто не может это оценить, будет другая компания где оценят.
wolfy_str
20.12.2022 02:20Ради результата работают во фрилансе, а на работе работают так. Когда то мечтал работать на результат, но это никому не нужно, да и проще работать на хорошую зарплату чем на результат
onets
18.12.2022 06:43Думаю все верно подмечено. Нашел в статье несколько пунктов, которые описывают мое состояние при работе с джунами.
Но есть проблема.
Пассивное отношение к макету
На подобные замечания мне отвечают «ой а я не так не подумал», «ой а я не догадался», «ой а это не пришло мне в голову». Хотя каждый раз говорю, чтоб пользовался головой и здравым смыслом. И начинает складываться ощущение, что корень проблемы лежит в другой плоскости.
Причем, когда я пытаюсь вспомнить каким я был джуном — не помню такого. Было незнание технологии, или каких-то фишек/хаков, фигачил весь бизнес код в обработчике button1_Click. То есть технические вещи.
Fell-x27
19.12.2022 10:09>пассивное отношение к макету
Ага, вот взял такой, включил активность, налепил отсебятины и понеслась. Потом с тебя же за нее и спросят, когда малейшие правки придут в отдел, спустивший кривой макет, а они встанут в позу "это не мы, мы все ок сделали по тз, это джун ваш накосячил!"
Нашёл косяки в макете - отправляешь макет на доработку с комментариями. А иначе ловим накапливающуюся ошибку, которая градиентом ложится на несколько отделов, и хрен пойми, кто там что должен править, откуда куда коммитить и кто с кем согласовывать.
Человек, писавший статью точно понимает, как это работает?
not-allowed-here
20.12.2022 03:46проблема "болезненности мыслительного процесса".... Т.к. по другому объяснить почему собственно иногда вполне умные и здраво рассуждающие люди не способны думать за рамками какой-то фиксированной задачи/парадигмы/процесса я немогу..... просто пока всё привычно истанадартно Люди справляются и всё ок чуть в право влево и вс
Kyoki
18.12.2022 08:30+17Типичный высер некомпетентного тимлида и/или начальства чуть приправленный прописными истинами для важности. Если заметили такое, бегите - будут ездить.
Джун должен постоянно учиться, но при этом бегать и выпрашивать задачи + ставить задачи другим... У джуна есть тимлид, дизайнер, дизайнер UI, ... не должен он вдруг вместо простого окошка делать светофор, потому что у него появилось чувство прекрасного.
Каждый дожен делать свою работу.
Artyomcool
20.12.2022 03:11+1Безусловно. Каждый делает свою работу - и остаётся в той роли, в которой был вчера. Когда расширяешь сферу своей ответственности (не забывая об этом напоминать при случае!) начинает меняться должность, доходы, компетенция. Если это не нужно - то всё правильно, делаем свою работу, не приносим фидбэк тимлиду, дизайнеру и т.д.
Wan-Derer
18.12.2022 10:35+7Я бы ещё добавил:
долбаная удалёнка!
При всех её преимуществах, она таки тормозит джуна:
ты уже год в компании, но с трудом представляешь кто чем занимается за исключением 1.5-2 человек, с которыми ты общаешься +/- регулярно;
тебе неуютно задавать вопросы своим т.к. всё время (хрен знает чем) заняты, проще наяндексить или спросить на Хабр КуА;
ты понятия не имеешь как это принято делать у вас в команде и поэтому твои решения - скорее велосипеды со SOF;
ты мучительно думаешь как бы подкатить к шефу на тему апгрейда з/п, хотя вроде давно пора и есть что предъявить, но фиг его знает чем он сейчас занят и уместен ли этот разговор в данный конкретный момент.
Конечно, есть разные компании с по-разному настроенными процессами, но если джун трудится в маленькой компании, эти проблемы, скорее всего, актуальны.
Trabant_Vishnya
18.12.2022 21:11+3Не соглашусь. Есть нормальные командные синки + общение со своими в ЛС и по видео.
У меня с 2020 три стажера до миддлов поднимались (Business intelligence) - что я делаю не так?
F0iL
18.12.2022 23:01+2ты уже год в компании, но с трудом представляешь кто чем занимается
Это потому что в удаленном режиме (пусть даже сидя в офисах) должна работать вся команда, а не так, чтобы один человек онлайн, а остальные онсайт. Когда все планнинги, обсуждения технических решений, переговоры с другими командами и менеджерами проходят онлайн (текстом либо голосом), а не в виде обсуждений в очереди к кофе-машине, тогда вовлечённость в дела команды будет полноценная у всех ее членов.
тебе неуютно задавать вопросы своим т.к. всё время (хрен знает чем) заняты
Наоборот, удаленка в этом плане гораздо лучше, потому что там асинхронная коммуникация. Человека не вырывают из рабочего потока ударом по столу с требованием ответить на вопрос прямо сейчас, а все гораздо приятнее и удобнее - пишешь вопрос, и когда твой коллега освобождается, он тебе на него отвечает.
ты понятия не имеешь как это принято делать у вас в команде
Для этого есть, опять же, совместные планнинги, обсуждения архитектурных решений и code review.
мучительно думаешь как бы подкатить к шефу на тему апгрейда з/п, хотя вроде давно пора и есть что предъявить, но фиг его знает чем он сейчас занят и уместен ли этот разговор в данный конкретный момент.
См. пункт #2. Если по каким-то причинам не выходит, ничего не мешает заслать в календарь предложение о созвоне 1-на-1 и обсудить этот вопрос там.
Wan-Derer
19.12.2022 11:33@F0iL , я же не говорю что невозможно. Просто одно дело когда ты видишь что коллега занят, аж дым из ушей, а когда он более-менее на расслабоне и можно к нему подсесть со своим блокнотиком. И другое дело когда вот эти вот коммуникации. Конечно, пользуемся тем что дают (ну, потому что другого ничего не дают), но мы тут обсуждаем статью о том что нас притормаживает - и таки удалёнка в ряде случаев притормаживает.
@Trabant_Vishnya,несомненно, всё делаешь так :) Но! Ты со своими джунами делаешь один проект, т.е. вы занимаетесь одним и тем же - просто на разном уровне сознания. А вот другая ситуация. Есть сильно_легаси проект и его уже не спасти. Но на него завязаны многие клиенты, более того, новые клиенты тоже его хотят. Принято решение грызть слоника по частям. Т.е. берутся некоторые функции и переносятся на современный стэк. Через некоторое время эти функции отключаются у "старого" приложения и ему становится лучше :) Так вот, под наработку новой базы набраны люди и им выдаются задания (пока основной коллектив занят поддержкой и новыми внедрежами). Только эти задания не вида "напиши класс" или "поправь метод", а вида "напиши сервис". С одной стороны это здорово: от тебя не ждут что ты поспеешь в спринт (у тебя и спринтов-то нет), плюс - тебя практически не ограничивают в технологиях, плюс - ты свой сервис можешь проверить в сравнении с уже существующим. С другой стороны - от тебя требуется совсем другой уровень самостоятельности, причём сразу на входе. Бессмысленно у коллеги спрашивать про классы и методы, максимум "а как оно должно работать?" или "это я глюк в старом приложении нашёл или оно так и задумано?". Так же бессмысленно задавать общие вопросы по стэку - ты быстрее найдёшь ответ на SOF. Или "а что это у меня на 300 тыс записей всё летает, а на 30 млн тормозит?". Какой тут ответ? "Смотри что там у тебя с запросами". Ну вот, сижу и смотрю :)
Да, конечно, и в этой ситуации можно наладить процессы и вот это всё. Только ведь джун работу не выбирает, это работа выбирает джуна :) Поэтому воду в бассейн нам сразу налили, учимся плавать в этих условиях :) А удалёнка нам тут скорее гирек добавляет чем жилет надувает.
Trabant_Vishnya
19.12.2022 14:24+2А почему джун вообще задачи такого уровня в одиночку делает? Может тут дело не в удаленке все же, а в процессах и нагрузке как таковой?
Или в офисе второй мозг отрастает?Wan-Derer
20.12.2022 15:41В офисе отрастает "перекинуться парой слов с коллегой, видя что он в данный момент не шибко занят". Я, правда, не работал программистом в офисе, мне досталась сразу удалёнка. Но раньше работал в офисе инженером и знаю что это хорошо помогает от тупняка :)
Правда, в офисе есть опасность: видя что ты на месте, на тебя набигают и
ограбляютотвлекают. Но это только если есть смысл, т.е. ты много знаешь. Поэтому для опытного сотрудника удалёнка идеальна. А для джуна - нет :)
rusik2293
19.12.2022 11:39+1Легко свалить все на удаленку, но в чем проблема сказать начальнику что за год онбординг не провели и непонятно кто чем занимается? Это в офисе проблема когда начальник все время на совещаниях и у тебя нет его номера, а на удалёнке написал в ЛС в слаке "Пора мне поднять зарплату" и все, сидишь ждёшь когда поднимет
wolfy_str
20.12.2022 02:16+1Частично соглашусь. Чтобы зарплата не жала, лучше сразу залететь на миддл, а вот дальше кстати не всём хочется, мне вот совершенно мне удобно миддлом. Ну есть немного только желание качать навыки, а так не особо. Как принято в команде узнаешь почти сразу даже если делаешь одну функцию несколько дней. таки корпоративные правила сразу узнаешь. Кто чем занимается, ну тоже спорно, но конечно, если имеется ввиду не вникаешь кем кто занимается да, возможно, но уже через неделю знаешь всю команду по должностям, так как ежедневный стендап же. Неуютно что то спросить то же может быть. А по поводу зарплаты тут лучше сразу заходить по рынку, есть варианты его узнать что бы потом не печалится.
Arhammon
18.12.2022 16:21+1В целом применимо и не к ИТ - если ты показываешь инициативу и сообразительность ты по возможности идёшь выше. Правда есть тонкая грань, есть уровень самостоятельности при котором ты уже раздражаешь руководство или, упаси хоспаде, создаёшь ощущение что ты конкурент...
Trabant_Vishnya
18.12.2022 21:13В финансах автоматизация труда и уход от велосипедов в Excel чаще раздражала и руководство, и коллег. Учиться пользоваться достижениями того же MS стека редко кто хочет
F0iL
18.12.2022 23:04+2если ты показываешь инициативу и сообразительность
...то на твоём горбу просто начинают ездить больше. И с повышением в должности и зарплате это совпадает далеко не всегда.
Arhammon
19.12.2022 09:34Ну это и есть модные софтскиллы, можно проявлять сообразительность в своей области, в интересной руководству области, уметь слить ненужную работу. А по Русски просто карьеризм.
Hebe
18.12.2022 17:25+6джун=js разраб чтоли?
Ritan
18.12.2022 22:01+9Да на хабре нынче половина статей молча предполагает разработчик=web-разработчик. Про других видимо не слышали.
Здесь ещё ситуация более-менее - всего 4 пункта касаются веба. Натыкался на статьи "10 антипаттернов в разработке", где речь шла про один какой-то фреймворк, а даже не js в целом.
Lexicon
19.12.2022 01:08+3Все еще джун человек может быть только из-за зарплаты. И останется джуном, пока не сможет продать себя дороже. Остаться слабым разработчиком и лидом при этом можно даже собрав все лычки и топ 1% зарплаты, что обычно подтверждают подобные статьи.
Если хочется развиваться как специалисту, то и развиваться надо как специалисту в любой области, - наращивать компетенции, собирать шишки, красть опыт и знания у всех, до кого только удастся дотянуться. Вступать в диалог, проигрывать, рисковать. Находить баланс жизни, знакомства и делать жизнь ярче и интереснее.
Jeoplett
19.12.2022 11:32Работа программиста - делать то, что нужно для проекта. Иногда - копать, иногда - развиваться, иногда не спать ночью, потому что так лучше для клиента. Всякое бывает, сложная у нас профессия.
rBo3Db
19.12.2022 11:32Зашёл почитать про джуна в разработке в целом, а тут описывается конкретный джун в вебе
iikoreva
19.12.2022 11:57Одного своего желания мало. Можно стать заложником ситуации. А плюнуть и послать всех "на..." чтоб развиваться не позволяет, например, ипотека.... Такое цифровое рабство :)))
johan134
19.12.2022 12:20Если не считать что автор сделал упор на фронт разработку (примеры не абстрактны), то очень неплохая статья! Можно с некоторыми правками включить в проект на вики дабы "молодняк" мог ознакомиться с указанными принципами ответственности:)
diakin
19.12.2022 13:13+2Прекрасный Хаброредактор.
1. Выделяем -копируем заголовок "15 причин, почему ты всё ещё джун"
2. Вставляем в поле комментария
3. Профит - не можем ни изменить, ни удалить, ни отправить Только перезагрузка страницы.зы. Яндекс браузер, если важно.
wolfy_str
20.12.2022 02:07Ну попадание не более 40%, мало того что пример только для фронтенда и в беке задачи несколько другие. Зато убер синьоры обращают внимание на всё что угодно, кроме логики. Не то форматирование, не так названы переменные, отсутcтвие префикса const или final, недостаточная ясность в тестах, отсутствие документирования, но сама логика практически никем не смотрится если это больше 10 строчек в методах. Кое какое попадание есть, Н кто не любит без инициативных, которые закапываются в себя, но опять же, мало смотрят на логику, по моему небольшому опыту 90 а то и 95% придирок к пул реквестам - это имена переменных, отсутствие не верные префиксы, модификаторы доступа и прочая шелуха. Нет обёртки исключений или наоборот, она там где не нужна, придирки к тестам, обязательно, саму же логику реально проверяют в лучшем случае в 5% случаев. Как то так из моего небольшого опыта это так. И да хотелось бы чтобы на логику и саму работу методов да и целиком проекта смотрели чаще. В разы чаще, а не на то, на что обычно смотрят, то что описал выше.
Nasreddin_Hodja
Это всё потому что на работе на это нет времени, задачи требуется выполнять побыстрее. А учатся чему-то зачастую на своих pet проектах.
Malizia
ChatGPT будет всем всё пояснять ????
Maccimo
Возможно даже объяснит, что не стоит употреблять ****-эмодзи при написании комментариев.
Malizia
Специально для Вас и прошу прощения если мои эмодзи Вас оскорбили.
kalombo
anayks
Nasreddin_Hodja
Странное утверждение. То есть если разраб не гуглит, а постоянно занят разработкой велосипеда с нуля, значит он не занят?
anayks
Вы неправильно поняли контекст.
Речь идет о том, что если Вас постоянно загружают на работе (при 40 часовой рабочей неделе, условно) и Вы все 40 часов постоянно кодите и не изучаете новые для себя вещи вокруг вашего языка/фреймворка/того что стоит вокруг Вашей работы, то Вы не используете свой мозг.
Работа программиста - постоянное развитие. Если Вас грузят 40 из 40 часов в неделю и не дают продохнуть, а только закидывают задачами и не дают расти - нужно покидать такую компанию/команду как можно раньше.
А главный совет для джунов - идти туда, где есть опытные люди из Вашей сферы, чтобы было учиться у кого-то конкретного.
У меня есть опыт 3-ёх лет содержания пет-проектов, но ничего лучше, чем обучения у опытных людей, я не нашел.
Это как в спорте - у каждого спортсмена всегда есть тренер, который может взглянуть со стороны. Так и в программировании - должен быть наставник-ревьювер, который сможет как оценить качество кода, так и оценить качество решения со стороны бизнеса/постановки задачи.
serginho
Я меня лично процентов 90% знаний, полученных именно в процессе решения задач.
anayks
Никто и не исключает знания, полученные в процессе решения задач.
Только суть в том, что если Вы изначально учитесь у более опытного человека, который уже варится в том направление, которое Вам необходимо, это гораздо сильнее ускорит Ваш процесс обучения, нежели тыкание во всё подряд в принципе, если у Вас, конечно, изначально стоит цель стать таким же, как тот разработчик, у которого Вы учитесь.
anayks
Условно говоря, "если Вы работаете с шестью сеньорами, то, скорее всего, Вы станете седьмым".
Nasreddin_Hodja
Ну, это справедливо не только для джунов, а IT это постоянное развитие. Но в любой компании, которая уже не стартап, накапливаются рутинные задачи, которые приходится кому-то делать и они уже порой составляют большую часть. Ну а джунам зачастую и дают по началу такие рутинные задачи, чтобы в проекте освоиться. Пилить что-то с нуля это уже следующий уровень.
just-a-dev
А может вариант с ментором хорошо подходит экстравертам, но плохо - интровертам? Что заставило вас думать, что ваш опыт легко экстраполируется на всех других инженеров?
anayks
Понятия «джуниор», «миддл» или «сеньор» — это субъективные понятия грейда по оценке компании/руководства.
Не спорю, можно быть самозванцем, называя себя сеньором JS разработчиком, будучи 5 лет единственным фронтендером в компании и выполняя работу так, как компания требует.
Но даже здесь есть проблема, что человек работает в компании и его все равно кто-то оценивает.
Если у человека есть какой-то грейд — значит, его уже кто-то оценил. И неважно, экстраверт он или интроверт. Так же и на перспективу, чтобы человек вырос из джуна в миддла, согласитесь, его должен кто-то оценивать, логично?
Такая оценка должна производиться условно постоянно и по коду, и по архитектурным решениям, и по бизнес-решениям (кто-то, например, моя компания, еще считает, что сеньор должен быть не только разработчиком, но и управленцем).
Под постоянным надзором опытных людей гораздо проще выявлять ошибки, так как их видно со стороны через призму опыта.
Я не отрицаю, что, в теории, можно стать сеньором, будучи одним разработчиком, изучая все вокруг себя. Но, имхо, я все еще такого мнения, что конкретные опытные люди гораздо проще и быстрее смогут указать на ошибки и направить джуна в нужное русло, если изначально у компании стоит задача выращивать специалистов, чтобы решать сложные задачи, а не просто делать рутину вечность.
just-a-dev
Не увидел ответа на вопрос - почему вы полагаете ваш собственный опыт подходящим для других людей? Любой рассудительный здравомыслящий человек с возрастом начинает понимать, что то, что сработало для него - не обязательно сработает для других. И не строит безапелляционных правил типа "опытным разрабом можно стать только с ментором" или "мы нанимаем только с ВО" и т.д. Вот и вы постарайтесь стать таким рассудительным, мой вам совет.
Есть масса способов перенимать опыт других людей (список конечно неполный): книги, статьи, конференции, код ревью, разбор чужого кода, да просто напросто - самоанализ. Если владеть достаточным уровнем рефлексии, то тоже можно многому научиться, так как самые лучшие умы двигают практики разработки вперед основываясь только на саморефлексии.
anayks
Я четко ответил на ваш вопрос.
Грейд — это оценка по требования компании. Каким бы ни был разработчик — открытым или закрытым к общению — оценка извне это важный критерий, по которому необходимо двигаться. Чем более глубокая эта оценка и чем чаще она происходит — тем быстрее происходит рост, если человек хочет двигаться в компании.
Джун — это грейд, в статье говорится о нем, и я комментирую и отвечаю все относительно вокруг этой статьи. Чтобы стать выше, чем джуном — нужно постоянно оцениваться.
Поэтому, повторю в третий раз. Чтобы вырваться из грейда «джун», нужно иметь четкий опыт, который будет складываться из код-ревью, а так же оценки технических и бизнес-решений в компании. Ментор или даже обычный ревьювер в разы ускоряет этот процесс.
И еще раз повторю, неважно, открытый этот человек или закрытый. Это неизбежный процесс роста в компании. Потому что грейды — это условные требования компаний, а не какой-то абсолютный показатель, и для этого в любом случае нужна оценка извне.
anayks
Требования у каждой компании разные.
Разные: стек, код-стайл, подход, архитектура, решения, инструменты, управление и еще множество факторов
Как Вы сможете узнать требования компании к росту, если Вы не будете постоянно оцениваться? С учетом того, что даже инструменты и подходы могут меняться каждые полгода на каком-нибудь JS?
anayks
В той компании, где я работаю на Go, есть требования по софт-скиллам для управления (буквально, начиная с миддл+), к пониманию построения архитектуры базовых веб-сервисов, паттернов проектирования, знания языка, его работы с памятью и т.д.
В то же время в какой-нибудь компании, которая занимается объявлениями, небезызвестной, есть очень большие требования по знаниям алгоритмов, микросервисных архитектур, но так же совпадают знания языка и мелких паттернов проектирования.
Согласитесь, что если у меня есть знакомый там, который четко мне скажет, какие явные требования есть у него в команде, то у меня будет больше шансов подтянуть конкретные навыки, чем если бы я шел туда без явной явной оценки, с чем мне предстоит работать?
Имхо, это очевидно
anayks
Поэтому я четко еще раз толкну мысль, что грейд — это оценка компании. Компания, в большинстве случаев, это одна или несколько команд, в которой должен быть опытный человек, чтобы здраво оценивать знания и силы своих сотрудников относительно решения задач.
Если такая компания маленькая, а оценки извне нет, то грейд будет волей случая, потому что Вы можете работать на одном стеке, со своим код-стайлом и не общаясь с людьми вовсе, а в компании с требованиям к миддлам, есть четкое требование софт-скиллов и взаимодействия с командой, а Вы по этим софт-скиллам можете даже под стажера не подходить.
Только не зная об этом, как Вы к этому придете? Разве не очевидно, что конкретный человек, работающий в той компании, в которой Вам нужно расти, если укажет Вам на ваши конкретные ошибки — это ускорит Ваш рост?
MegaMANGO
А почему интроверт – обязательно тот, кто изучает только всё вокруг себя? Есть же книги всякие, форумы... Можно всё это читать/слушать, и отвечать самому/спрашивать что-то по минимуму. Сохраняя при этом позицию интроверта, и учась у других. Самый банальный пример, Перельман очевидно интроверт, но это же не значит, что он постиг все свои знания исключительно методом проб и ошибок =)
Maccimo
Какие-то детские оправдания.
Задача выполняется с той скоростью, с которой она выполняется, быстрее невозможно. Быть «недостаточно быстрым» однозначно лучше, чем быть «копирующим говнокод не вникая в детали».
SteamEngine
"Врёшь, морда американская, не может солдат в день два мешка брюквы съесть!"