Джун и cеньор-программисты Python

r/#ProgrammerHumor

Git - это опасно

У меня когда-то давно уже выходил пост с заголовком IT - это опасно.

Хочу вернуться к этой теме, так как буквально неделю назад снова наступили на те же грабли. Ещё в августе я фиксила некоторые баги в нашем проекте на работе. В ноябре обнаружила, что всё, что я чинила - снова сломано, и баги каким-то чудом "вернулись" в проект. Стала разбираться. Выяснилось, что один коллега, когда заливал свои изменения в проект, каким-то образом в гите перезатёр все мои изменения, и вернул в код старую версию, которая была ещё до августа. Причем, коллега не джун и не новичок. Но гит - инструмент мощный и умеет многое, поэтому, используя его, нужно всегда хорошо понимать, что ты делаешь. Действуя наобум, наверняка что-то сломаешь.

Для тех, кому слово "гит" и всё, что написано ниже ни о чем не говорит - почитайте мои вводные посты к гиту - раз и два.

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

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

А чтобы всё было хорошо, стоило всего-то - взять самую последнюю новую версию кода из мастера и в отдельной ветке прогнать код через свои линтеры. Поскольку никаких других изменений в логике кода не планировалось, то и смысла разбирать руками каждый конфликт при мерже (а это муторно, долго и сложно) - не было никакого.

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

Как войти в айти

В этом году я с разгона забежал в IT. Это позволило переехать в Мадрид и вести достойную жизнь в европейской столице.

Сегодня раздаю советы тем, кто хочет сменить профессию.

Выбор профессии

Профессионалы зарабатывают хорошо в любой отрасли и IT не панацея. Но допустим, вы всё-таки выбрали информационные технологии.

В IT работают не только разработчики/программисты. Там куча занятий, которые могут подойти, если код не возбуждает. Пройдите профориентацию, может быть ваше призвание стать scrum-мастером.

Preproduction

Вы определились. Пока рано менять жизнь и покупать курсы.

Заходите в YouTube и пару месяцев поглощайте информацию оттуда.

На этом этапе не нужно пытаться «освоить профессию». Сейчас важно выработать привычку учиться и прислушаться к себе. Через 2 месяца задайтесь вопросом: «Готов(a) ли я этим заниматься следующие 20 лет жизни?». Если ответ: «Да!», поехали дальше.

Курсы или самообучение

Я знаю успешных самоучек, но это исключение. Получить формальное образования – хорошая идея.

Курсы нужны не для информации. Информации в интернете куча. У курсов есть две важные функции:

1. Обратная связь

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

На курсах есть человек, который посмотрит на вашу работу и скажет: «Здесь нужно так, а здесь вот так»

2. Дедлайн

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

Я купил самые дорогие курсы и не жалею, но сейчас бы поступил иначе.

Все эти конторы существуют по схеме:

Идут на Udemy -> Покупают там за 100 евро популярный материал по нужной теме -> Красиво упаковывают -> Продают за 1500 евро.

Я советую идти напрямую на Udemy и подобные сайты и брать материал оттуда. Периодически дополняйте курсы уроками с наставником по 20-30 евро. В итоге в 300-500 евро можно уложиться.

Pet project

С начала обучения пилите свой проект. Это очень важно.

Проект должен быть больше, чем просто что-то, работающее на вашем компьютере. Он должен пройти все этапы разработки: это небольшое приложение, развернутое на сервере и доступное извне.

Даю слово, что 99% знаний вы получите именно тогда, когда будете делать и разворачивать свой проект.

Поиск работы

Теперь самое интересное – как найти работу без опыта?

Вы можете пойти на стажировку, хотя часто и там требуется опыт.

Я считаю, что нужно упаковывать своё обучение, pet project и что-то из прошлой жизни в опыт работы. Задача у этого одна – попасть на собеседование. Если попали на собеседование и у вас нет знаний, то HR быстро это раскусит.

Как пройти техническое собеседование

Чтобы подготовиться я вместо музыки слушал постановочные собеседования. Таких на YouTube полно по каждой теме. Это помогло вызубрить как работает нужная технология изнутри. В итоге собеседования я щёлкал как орешки.

Рынок труда

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

Джуны нужны.

Говорить, что они не нужны – все равно что сказать: «Зачем миру дети, если взрослые всё делают лучше?»

Вот, прочитала в авторском блоге, на который подписана

Интровертам посвящается

Бытует мнение, что айтишники - это такие сплошные асоциальные интроверты. Это отчасти верно, но вообще асоциальность или трудности с коммуникациями - это совсем не "фича", а, скорее, "баг". С этим сложнее жить, сложнее работать, сложнее искать работу и проходить собеседования. Работа в IT - это тоже, прежде всего, работа с людьми - с людьми надо уметь договариваться, обсуждать задачи, совместно продумывать решения и просто ладить.

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

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

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

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

Помните, софт-скиллы бывают важнее чем хард.

Больше половины россиян (55%) сменили профессию за последние два года. Более трети ушли в IT, оценив сферу как наиболее перспективную и мобильную. Чаще всего профессии меняли руководители среднего звена, а также специалисты из сферы гостинично-ресторанного бизнеса и туризма. Причинами смены сферы деятельности участники исследования Kokoc Staff назвали более высокий заработок и интерес к новым занятиям. @retailrus

Роадмап по изучению Python:

https://roadmap.sh/python

Как собеседуют senior-разработчиков

В конце прошлого года была на конференции Highload++, и там зашла послушать доклад о том, как собеседуют Senior-разработчиков.

Подход докладчика к этому вопросу мне не понравился, я в корне не согласна по многим пунктам, кажется, даже дослушивать до конца не стала.

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

Собеседование - это знакомство. Кандидат приходит понять, есть ли у работодателя интересные вакансии для него. Работодатель смотрит, подойдёт ли кандидат для того, чтобы закрыть собой нужный функционал. А экзамен - это взгляд "сверху вниз" - при том, что сильный кандидат может быть по уровню выше того, кто его собеседует.

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

Получается, ребята расписались в том, что они с радостью нанимают к себе на работу людей, которые умело притворяются сениор-разработчиками - и еще всем советуют так же делать. В итоге у них там работает кто? Миддлы, хорошо выучившие вопросы к собеседованию? Люди с хорошей памятью и навыками самопрезентации? В чём прикол?

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

Но вот работодателю спрашивать по списку вопросы из топа выдачи гугла - это же смешно. Задача же - понять уровень специалиста объективно, таким, какой он есть на самом деле, без подготовки. Чтобы понять, что сениор на самом деле сениор - прежде всего, важно спросить, в каких проектах он участвовал, понять размер, сложность этих проектов, подробнее расспросить, что именно он (и его команда) там делали и как делали. Подделать ответы на такие вопросы гораздо сложнее - это придётся придумывать/описывать целую архитектуру.

Так же важно проверить софт-скиллы - из общего разговора с человеком выяснить, как он умеет общаться с коллегами, есть ли у него навыки лидера и организаторские качества, как он ведёт себя в ситуации неопределенности и недостатка информации, пассует ли перед сложностями. Докладчик на конференции рассказывал, как они собеседовали кандидата, и кандидат стал вести себя агрессивно и орать на собеседующих - мол "у него такая реакция на стресс". И, удивительное дело, кандидату даже предложили продолжить общение в другой день, раз сегодня не получилось. Хотя, на мой взгляд, человек очевидно завалил тест на софт-скиллы - если даже на первом собеседовании не способен держать себя в руках и ведёт себя агрессивно в адрес почти незнакомых людей.

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

Ну а для тех, кто сейчас в поиске работы, особенно для новичков, вывод такой, что характер собеседования зависит только от того, кто собеседует. И вот, как видите, для кого-то действительно важно ваше знание топ-10 вопросов для собеседований. Так что гуглите, готовьтесь и будет вам счастье. Другое дело, что более толковый интервьюер будет копать вглубь, а не проходиться по списку "экзаменационных билетов". И, может быть, уделит больше внимания неформальной беседе с кандидатом, чем чисто техническим тонкостям.

Есть расхожее представление, что для того, чтобы стать хорошим специалистом, джуну нужно прийти и поработать года 3 - и готово, дальше уже карьера как по маслу пойдёт.

На самом деле всё немного по-другому. Хороший специалист - он сразу хороший специалист, это видно со старта. Ещё будучи джуном, он уже себя проявляет классно и очень быстро начинает приносить пользу компании.

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

А бывает и обратная история - когда человек уже работает 2-3 года, а толку от него примерно столько же, как и на старте - не растёт, не учится (либо ооооооочень меееееедленно).

Причем, тут, кажется, важнее личностные качества и качества характера, чем знания.

#вашивопросы

Хотелось бы узнать Ваше мнение, по поводу входа в IT с позиции системного аналитика, встречались ли такие люди Вам? Просто бытует мнение, что это не стартовая позиция, а с другой стороны, системному аналитику не обязательно писать код на каком то языке программирования. Как Вы думаете, можно ли начать карьеру с данной позиции? Или лучше желателен опыт в IT и только потом можно переходить на позицию системного аналитика? Хватит ли знаний полученных в результате самообучения, чтобы справляться с задачами в процессе работы? Может можно еще серьезнее подготовиться, например, найти ментора и решать с ним учебные задачи, собрать портфолио свое.

Вообще мне не очень понятна точка зрения, согласна которой, есть какие-то "стартовые позиции", с которых "надо" входить. Ну какая позиция считается стартовой? Сотрудник колл-центра/техподдержки? Ручной тестировщик?

Наверно, когда говорят о том, что нужен абстрактный "опыт в IT", имеют в виду, что человеку нужно иметь какое-то представление о том, как устроены процессы в IT-компаниях, какие там есть роли и какие функции выполняет каждая роль, каков жизненный цикл разработки продукта и прочие внутряки. Но тут же получается Уроборос - чтобы был опыт, надо поработать, а чтобы взяли на работу - нужен опыт.

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

Я знаю человека, который стал системным аналитиком после работы в техподдержке. Но так же я знаю человека, который без опыта в IT захотел стать скрам мастером, и стал им, а сейчас планирует переквалифицироваться в project manager.

На счет менторов - не уверена, что они существуют для таких профессий (хотя сейчас наверно можно найти всё, что угодно). Повторюсь - лучше ищите стажировки. В работе важнее всего опыт работы а не наличие "репетиторов".

Задать вопрос автору блога можно здесь: @hum_it_bot

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

В чём идея:
- Объективно оценивать своё рабочее время. Иногда кажется, что день прошёл крайне не продуктивно, и толком поработать не удалось. В такой ситуации лучше иметь реальную оценку отработанного времени - удалёнщикам свойственно недооценивать то время, которое они потратили на работу и вечно чувствовать что ты "недорабатываешь". Это не обязательно правда

- Избегать переработок. Допустим, 8 часов в день - это предел. Если нет экстренной необходимости, не стоит пересиживать за работой. От этого страдают все прочие сферы жизни, в том числе здоровье. Да и на продуктивность в долгосрочной перспективе переработки влияют плохо. В целом, "недоработки" лучше, чем переработки - они могут вредить дедлайнам, но в остальном в них есть и польза. Почему я пишу "недоработки" в кавычках - потому что в работе важнее продуктивность и результат, а не количество часов, потраченное на этот результат. Не обязательно 10 часов работы в день принесут лучший результат, чем 5-6 часов, если эти 5-6 часов удалось работать в хорошем продуктивном режиме. В целом у интеллектуального труда есть предел по времени эффективности - через какое-то количество часов уже не получится хорошо концентрироваться и эффективность труда падает.

- Лучше управлять своим временем. Опять-таки, беда удалёнщиков и фрилансеров - плохой тайм-менеджмент и планирование своего времени. В сутках 24 часа, за вычетом сна, допустим, остаётся 16. Если 8 часов потратить на работу, остаётся ещё 8 под все прочие дела. У многих эти часы изчезают буквально вникуда.

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

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

В книге Remote читала мнение, что по-хорошему, стоит завести для работы и прочих дел 2 разных компьютера - чтобы чётче разделять время рабочее и личное, чтобы в личное время не читать рабочую почту, например. Сегодня я подумала, что идея разумная - когда ты не работаешь - к рабочему ноутбуку даже не притрагиваться. Покупать второй ноут я, конечно, не буду. Но мысль здравая. Если бы кто-то мне его подарил - так бы и делала. :)

https://hottg.com/sale_caviar/6419

И что, кто-то верит, что можно найти сеньора, который согласится работать за 150к, да ещё и нелегально?
Вместо того, чтобы устроиться на аналогичную вакансию за фулпрайс, ага

Мне иногда предлагают делать свои курсы, но мне эта идея кажется непривлекательной.

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

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

Часто к преподавателям обращаются не из-за желания учиться, а, наоборот - из нежелания, надеясь, что уж преподаватель сможет нацедить недостающей мотивации для своего ученика. Но мне такой подход не нравится. Если человек хочет идти в индустрию и тут работать, значит, необходим его собственный интерес и энтузиазм, рвение к учёбе, если угодно. А если он ничего не хочет и ничего не готов делать самостоятельно и надеется, что его преподаватель вытянет к знаниям - кажется, это обреченный случай. А потом удивляемся, откуда на работу приходят джуны, не готовые учиться и проявлять хоть какую-то самостоятельность и всё время ждущие, что их кто-то будет за ручку водить и всё объяснять.

От подписчиков:

Здравствуйте. У вас действительно получается какой-то около-психологический канал😅 вот сейчас, у меня проблема и я сразу подумала об этом канале и его авторе))

Благодаря, в том числе, и вашим постам в результате самообразования и удачного стечения обстоятельств, сумела найти работу, которая мне очень удобна: удаленно, не полный день(потому что ребенок хоть и в саду, но то и дело болеет), оплата устраивает пока, есть перспектива. Есть конечно и трудности: не распространенная среда разработки, отсутствие комьюнити, маленький коллектив, а значит широкий круг обязанностей и еще постоянно нестандартные задачи. Читая вас, я в общем-то всё это понимала и осознавала, относилась терпеливо.
Да, я джун в любом случае.
Но ещё все осложняется тем, что начальник не удается в подробности, задание выдает очень кратко и нередко бывает так, что я начинаю делать его неправильно, что выясняется только через какое-то время.

В результате, конечно, немало разочарования, пропущенные сроки, чувство вины.

И вот сейчас. Задача была поставлена месяц назад, заложено определенное количество часов. В это количество часов я уложилась, даже остался запас. Однако, вот сегодня выяснилось, что задача выполнена не совсем корректно. Со слов посредника между мной и руководителем, руководитель написал: "я сам сейчас это делаю"
Я попросила разъяснений, что не так, что я напортачила, ответа пока нет

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

Что же касается вашей трудности с правильным пониманием поставленных задач, предлагаю посмотреть на это так: любой проект, задача, подзадача начинается с этапа выработки требований. Только когда на 100% понятно, каковы требования - уже приступают к выполнению задачи. У вас получается этап выработки требований "зажевался" и вы начинаете выполнять задачу без верного понимания, что именно нужно делать. Это достаточно частая проблема не только у новичков, но и в опытных командах. Поэтому как только получаете новую задачу - сосредоточьтесь на первом этапе. Сформулруйте список уточняющих вопросов. Опишите примерный план того, что собираетесь сделать. И потом с этим материалом идите к начальнику и уточните - правильно ли вы поняли задачу, а так же закройте все неясности. Ещё хорошая практика - даже если вам кажется, что вы поняли, что сказал начальник, пересказать это за него своими словами и спросить "Правильно ли я понимаю задачу? Мне нужно сделать то и то, вот так". Если вы поняли задачу не так, как её хотел передать вам начальник, он это услышит из ваших слов и внесёт правки. И уточнять, формулировать и задавать вопросы нужно до тех пор, пока всё не будет кристально ясно на 100%. А чтобы не отвлекать начальника кучей мелких вопросов, лучше заранее подготовить список и договориться с ним, что он выделит полчаса на обсуждение.

[... к предыдущему посту]

И ещё один момент - не все руководители дают ответ "зачем" вы что-то делаете, и какой цели этим добиваетесь. Без этой информации высок риск начать двигаться в неправильном направлении. Поэтому спрашивайте, зачем. И любимое у разработчиков "какую проблему мы решаем"? Например, "хочу скрипт, который будет возвращать список клиентов за последний день" - это задача с непонятной целью. А "нам надо проанализировать, какой процент клиентов использует android. Если 90% клиентов использует веб-версию, и им не нужен андроид, тогда в этом году мы не будем вкладываться в разработку андроид-приложения". Вот так вы понимаете реальную цель работы, и можете предложить другой вариант решения - может быть, первоначальная идея со скриптом не самая лучшая.