Comments 10
В ваш первый день на новой работе объедините все коммиты в один с комментарием «legacy-код» и сделайте force push в мастер. Пусть сразу поймут, кто тут главный...
Если Ваше творчество вызывает эмоции у людей, значит оно им интересно. Даже если Вы пишите плохою статью, она всегда может быть эталоном плохой статьи.
Самое главное правило не пытайтесь всем понравиться, Вы это Вы.
40+ стажа в разработке. Советы здравые, но как обычно, мало полезные. По сути азы.
Часто, придя в команду новичок не имеет никакого представления о местных процессах. С чего начать?
Поиск и чтение доков, если они есть.
Как правило, дают несложный тикет, который мало информативен и не интересен, но является хорошим поводом изучить весь код, подходы и стили, принятые в команде, осматривая в округе тикета всё подряд.
Но, бывают и исключения. "Классный сеньор! Закрыл 8багов за первый день работы".. Правда потом ещё три месяца и всем, пришлось править последствия, ибо не разобравшись, что понятно..
как грустно год от года читать такие статьи на хабре...
воистину, "если нужно объяснять, то не нужно объяснять". Если человек пришел на позицию (какими-то ухищрениями трудоустроился) и не понимает таких очевидных очевидностей, то может и не надо, чтоб такие люди приходили в профессию? А то мы и так страдаем от низкой квалификации "свежей крови", а такие вот советчики только поощряют её размножение...
В уважающей себя фирме, завсегда к новичкам приставляется наставник, как миниум на месяц, не зависимо от квалификации пришедшего и по сути "сидит с ним рядом" весь месяц, редко получается меньше.
Такие статьи джунам нужны, поскольку опыта у них нет, и то что нам с вами кажется банальностью, для них - откровение.
ЗЫ. Ещё лучше (но мало где есть) когда весь стек вхождения прописан в вики компании, вместе с феншуем от Убера (много где тупо скопировано, даже не вникая в суть), как-то: штатное расписание и ответственность сотрудников - к кому бежать; общее описание продуктов в целом и развернутое вики по каждому по отдельности - что написао, почему именно так а не иначе (всякое легаси имеет свою историю); феншуй написания кода - в т.ч. ПОЧЕМУ надо писать так, особенно в свете разных "чистых архитектур", раскладки на слои и пр. инвертированные поведения зависимостей .. нахрена так? Ответ должен быть развернутым и с примером кода в имеющемся легаси, типа: "вот, тут был постгрес, стал редис .. поэтому, все не ключевые поля записей храним отдельным полем в джсоне, а не строим таблички из 100500полей".. ок, бывает и так.
Спасибо за коммент!
Кажется, что тезис очень радикально звучит) Если честно, не встречал джунов, которых не нужно онбордить и доучивать уже внутри компании. Они косячат, задают глупые вопросы и учатся с разной скоростью.
Надеюсь, этот пост может помочь какому-нибудь из них чуть реже отвлекать опытных коллег от работы. Размножать никого не хотел) Все вопросы к коллегам из Скиллбоксов и Гикбрэйнсов))
Мне кажется, гайд написан человеком, который видел ИТ максимум из космоса
Ну давайте представим
первая айтишная работа таки нашлась
Дальше мега полезные советы, но не все
Сформулируйте и запишите, какого результата было бы классно добиться в компании через 6 месяцев или год, например
Вот мне интересно, чего может написать полный джун, который только пришел на работу. Он же еще не знает ничего. О чем он может писать? Чтобы что-то планировать надо знать хоть минимальные знания о предмете. А спроси его как выглядит SDLC - он сядет в лужу, или будет выдавать заученный "бред" с курсов.
А не зная процессов, как себя видеть в них?
Ну и где вы видели "новенького", который вообще делает что ему вздумается? Ему уже и так накрутили планы, задачи и у него башка кругом от всего, что происходит вокруг
Шаг третий. Познакомьтесь с командой
Это нормальный совет, тут не подкопаешься
Шаг пятый. Разберитесь с бизнесом
Хорошо наверное некоторым новеньким, есть время на такие вопросы. Но многим так не "везет" и их грузят по специальности
Шаг шестой. Будьте проактивным
Правильно, с самого первого дня. Ничего не знаю, но всех задолбу своим незнанием и получу ачивку "самый активный идиот года". Ну блин, понятно что не надо ото всех прятаться и тому подобное. Но не стоит, будучи джунов заниматься
Например, вы видите, что какой-то процесс завис и работа не движется. Организуйте короткую встречу и помогите команде разрушить блок.
Ну как вы себе это представляете. Два дева условно обсуждают проблему, о которой вы ничего не знаете. И вообще понимаете два из трех слов. Но влезете и предложите помощь? Серьезно?
Тут вот реально классика "лучше промолчать, чтобы не казаться идиотом, чем открыть рот и развеять все сомнения"
Пункт 0 - получить доступы. Без них сложно сделать все остальное. По скорости получения доступов можно сделать выводы о вашей проактивности. Иногда на получение доступов может уйти месяц.
На тему "разобраться с бизнесом". В реальности на этот вопрос нет ответа даже у CPO. Если приземленно - то ожидания от вашей работы обычно формирует нанимающий менеджер - это называется "План задач на испытательный период".
Главное когда в офис заходишь - полотенце с пола не поднимать, а то в айосеры запишут. И только потом записать имена и специальности коллег за соседними столами, чтобы клянчить подсказки, пока лиду не до тебя.
Статья с сомнительной полезностью. Если у человека это первая работа в ИТ, но в принципе не первое место работы, то как лучше адаптироваться в новых условиях скорее всего понятно из предыдущего опыта. Если совсем первая работа, то на мой взгляд самое полезное как можно быстрее установить нужные программы, получить всё доступы. Далее внимательно изучать документацию и продукт, плюс налаживать коммуникацию с командой.
Что надо сделать на новой работе в первый месяц: гайд для тех, кто недавно в IT