Мы среднее нашего окружения

— Ты уже полгода учишься. Общаешься c кем-то из python-разработчиков? В коммьюнити, на Хабре обсуждаешь темы? Может, ходишь на митапы и конференции?
— Хм🤔 да надо бы. Но постоянно откладываю.

Хочешь выделиться среди таких же начинающих разработчиков? Сделай то, чего большинство не делает — стань активным членом нетворкинга.

Если ты не в IT тусовке — будет крайне сложно найти себя в профессии. Помощь в сообществах другим разработчикам:
▪️ ответы на вопросы
▪️ обсуждение интересныхтем
▪️ знакомство на конференциях

— не просто общение, а развитие твоего кругозора и насмотрености. Так ты повысишь профессиональную ценность.

Вечером закину файл с предстоящими конференциями и митапами в комментариях к посту (включи уведомления и подпишись на чат канала https://news.1rj.ru/str/ForkwayPythonChat, чтобы не пропустить).

А пока поставь
👍 - пост понравился
🤔 - не зашел

Python - учим и работами

Позиция «клиента», а не «студента»

— Я купил курс, а меня отправляют смотреть ютуб и читать статьи, да ещё и на английском!
— Что если твой работодатель скажет: «Я плачу деньги за решение задач, а он 50% из отведенного времени гуглит, как это делать».

Курсы дают минимум, а этот минимум есть уже у тысяч таких же студентов и самоучек.

Чтобы сейчас войти в ИТ, нужно постоянно учиться и решать задачи.

Выкладывайте в комментария полезные статьи и видео, которые зашли вам, а также где вы набиваете руку на решение задач:)

А пока поставь
👍 - пост понравился
🤔 - не зашел

Python - учим и работами

Быть активным - нет, не слышал

— Что читаешь по программированию? – спросил у знакомого студента.
— Материалы курса 😐

По активности предыдущего поста у меня складывается ощущение, что не читает/не изучает ничего дополнительного не только студент из диалога 👆🏻

Чтобы вы не скучали, пока домашка на проверке, предлагаю познакомиться с полезными бесплатными инструментами для начинающего разработчика:

1. Codewars — это сборник интерактивных тренировок по разным языкам программирования. Есть задачки по базовому Python для тех, кто только учится.
Как с ним работать можно посмотреть тут https://www.youtube.com/watch?v=QdR84ruO0po (ru)

2. hackerrank – сборник задачек с онлайн редактором как для python, так и для sql. Видео, где автор рассказывает, как работать с платформаой https://www.youtube.com/watch?v=tnH6twfFas4

3. Шпаргалка по python

4. Основные модули в Python 3 – описание модулей и перевод документации к ним.

Пока не побежал изучать новые ресурсы, поставь
👍 - пост понравился
🤔 - не зашел

Python - учим и работами

Почему мы ищем джунов

— Сколько вам потребуется времени на решение задачи? – спросил я у двух разных разработчиков.
— Здесь нужно декомпозировать и спланировать. Думаю, за две недели управлюсь, – ответил senior.
— Сегодня–завтра сделаю, – ответил junior.

Что в итоге?

Senior потратил 3 недели и отправил хорошо сделанное задание. Junior «из говна и палок» собрал за неделю. Оба не успели выполнить в обещанный срок и сделали с разным качеством.

Как правильно поступать, когда ищешь исполнителя?

Я обычно задаю следующие вопросы:
🔸 я уверен, что это нужно конечному клиенту? Проверка гипотезы.
🔸 какие разработчики есть в команде?
В команде Forkway сейчас 3 сильных разработчика и 6 джунов, которые помогают быстро тестировать гипотезы.

Но задачек с каждым днём все больше😬 Поэтому открываем новую итерацию поиска junior back-разработчиков на python.
Пишите Даше (@cutepinkribbon), она пришлет описание вакансии и тестовое задание.

Чуть позже в комментариях к посту выложу вакансию и тестовое.

Буду благодарен за репост.

Пока не побежал(а) писать Даше, поставь:
👍 - пост понравился
🤔 - не зашел

Python - учим и работами

Как прочитать Лутца

— Что сейчас читаешь по Python? – спросил я знакомого.
— Лутца начал.
— Так ты его год назад начинал уже
— Было, но всё забыл и сейчас вспоминаю.

Разговор повторяется раз в полгода на протяжении лет трёх. Как думаете, в чём тут дело?

Изучение любого «открытого» контента требует колоссальной самодисциплины:
– материал можно освоить в любое время, это превращается в бесконечное «позже пройду»
– простую задачку прикину в уме и пойду дальше, упарываться не буду. Итог — через 5-6 модулей/глав не помните базовые вещи, и дальше двигаться не получается.

А сколько у вас начатых книг, которые ждут своего часа?

Python - учим и работами

Чуйка наше всё

— Что отработает быстрее
numbers = [i for i in range(1000_000_000)]
или
numbers = {i for i in range(1000_000_000)} ? – спросил я на собеседовании.
— Наверное, первое.
— Почему?
— Что-то мне подсказывает, не знаю почему.

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

Но опытный спец смог бы ответить на этот вопрос.

А вот когда так отвечает кандидат без опыта, то начинаешь задумываться, а не пролистал ли он вопросы/ответы к собеседованиям?

Предлагайте свои варианты в комментариях. Как думаете, почему что-то работает быстрее, а что-то медленнее:)

Кто не любит писать, ставьте:
👍 - отработает быстрее первый вариант.
🔥 - отработает быстрее второй вариант.
🤔 - я тот самый кандидат.

Python - учим и работами

Не ошибается тот, кто ничего не делает

— Почему у тебя проект в портфолио оформлен как один коммит в main ветке в GitHub? — спросил кандидата в стажеры.
— Как сделал проект — так и закоммител.

Когда я (и нетолько 😊) вижу один комит в main ветку, то сразу появляются предположения:
– человек не умеет работать с git, и просто сохраняет итоговый проект, чтобы расшарить этот код для портфолио. Ни о каких git/GitHub/gitlab flow кандидат не знает.
– а не скопировал ли кандидат откуда-то этот код? 🧐 Я же не могу проверить ход его мыслей в дереве коммитов. Будто он с первого раза сделал идеально —даже у миддла такое редкость, а тут джун, и целый интернет магазин.

В своих я проектах придерживаюсь модифицированного gitlab flow:
1. Главная ветка не main (как в документации gitlab flow), а develop (у команд уже было много настроено на эту ветку).

2. Feature ветки создаются только от develop и вливаются только в develop.

3. Realese ветки создаются только от develop. При создании:
a. название ветки выставляем MAJOR и MINOR версию (название начинается с release-)
b. создаём tag MAJOR.MINOR.0.

4. Hotfixes ветки создаются только от develop и вливаются только в develop, далее с помощью cherry-pick переноситься в нужную release ветку. После переноса для нового commit в release ветке выставляем tag такой же, как и в прядущем commit данной ветки, только PATCH инкрементируем.

Есть более полный документ, где описано всё: от того, как правильно называть ветки и комиты, до того, как подготавливать merge request / pull request.

Пишите в комментариях, если нужен такой док. Подготовлю чуть позже и пришлю :)

По сложившейся традиции жду ваших реакций:
👍 - пост понравился
🤔 - не зашел

Python - учим и работами

Гайды, гайды, гайды

— Документы подписал, что дальше? – спросил как-то новый сотрудник.
— Вот тебе список ссылок в confluence с нашими инструкциями/гайдами и прочими материалами. В них описано, как мы работаем.

Когда в команде больше двух человек, а все пишут, как умеют, код превращается в дом, в котором каждый подъезд строит свой архитектор. Но в отличие от стройки, разработчики не могут разделить куски кода по "подъездам". В итоге получаем большой комок грязи.

На помощь приходят архитектура приложения, гайды по работе с кодом, с гитом, с работой над merge requests, по ревью и многое другое 🤯

Вы просили — я услышал. Делюсь своим гайдом по работе с гитом. Используем его в стартапе Forkway.

Гайд: https://docs.google.com/document/d/1JUSxEoiRDmeOCcUHeRLrTd2p1M3QRaf9bJFWSQehMjM/edit?usp=sharing
* Attention в документе много IT жаргона😅

Посмотрите и пойдем в комментарии обсуждать...

Поставь:
👍 - пост понравился
🤔 - не зашел

Оно же работало..

— Я сделал тестовое задание, – написал кандидат.
— Ага, часть API работает, часть выдает ошибку. И тестов нет..

Частенько присылают решение задания без тестов или с бестолковыми тестами, которые проверяют 1-2 функции.

Почему я прошу писать unit тесты при проверке кандидата на собеседовании?

Представим ситуацию: мы сделали первую API'шку, проверили вручную, что она выдаёт правильный ответ.

Сделали вторую API'шку. Поправили частично код уже имеющихся функций. Протестировали новую API, выгрузили в гит и отправили на ревью.

Есть ли гарантии, что первая API не сломалась, а вы проверили все граничные условия, а не только стандартные? А если API ручки не две, а 10?

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

Когда последний раз писали unit тесты?

Интересна тема тестирования:
👍 - да
🤔 - не заходит

Python - учим и работами

Работа в стол или опыт?

— Сколько нужно создать pet-проектов, чтобы прокачать опыт в разработке? – спросил знакомый студент.
— Тут как в обучение — это непрерывная деятельность.

Чем больше будет проектов, и чем разнообразнее они будут по своей сути и технологиям, тем лучше. Так закрепите свои знания и научитесь ставить, декомпозировать и оценивать задачи.

Главное, чтобы последующая идея по качеству превосходила предыдущую.

Я в разработке уже больше 10 лет. Но до сих пор создаю pet-проекты. Из одного такого родился стартап Forkway🙂

За все время у меня появились порядка 60-70 pet-проектов. Например:
– Вкрипте (2018 год)
– Инвестирование (2020)
– Крипто (2018)
– Личный кабинет сетевого маркетинга (2017)
– Плагин Jobs (2017)
– Проект ZN (2016)
– SEO компания (2016)
– Автопоиск уязвимостей (2018)
– Facenter (2014)
– kinocar (2017)

Многие не принесли мне ничего, кроме опыта. Именно его считаю лучшим приобретением.

А какие проекты хотелось бы создать вам? :) Возможно, уже думаете над воплощением пары-тройки идей?

Интересна тема pet-проектов:
👍 - да
🤔 - не заходит

Python - учим и работами

Красные глаза, каша в голове, или как завалить собеседование

— Расскажи на пальцах, как работает асинхронность в Python, – попросил я на собеседовании.
— Хм, ну… Перед определением функции ставим async, а при вызове – await.

На интервью встречал несколько типов людей:
– Первые считают, что готовиться к собеседованию не нужно: важно быть честным перед работодателем, чтобы он знал, кого берет на работу.
– Вторые в ночь перед экзаменом включают режим студента: повторяют ВСЁ (даже то, что хорошо знали).

С первыми всё понятно — просто лень что-то учить/повторять. Опытные ребята в принципе могут вспомнить на собеседовании всё. А вот новички навряд ли пройдут.

Со вторыми сложнее: вроде что-то знают, но каша в голове страшная. Еще и приходят невыспавшиеся.

Советую не следовать этим вредным примерам😉

А вот как я готовлюсь к собеседованию:
1. Когда вас приглашают в какую-либо компанию, там наверняка есть список требований и ожиданий: например, знание Python, FastAPI, Postgres и т.д. Забираем его.

2. Разбиваем каждую тему на подтемы: можно взять документацию/книги по ним и взглянуть на оглавление.

3. Гуглим/@gpt_ihelper_bot Просим накидать вопросы по подтемам. Сохраняем их. Это пригодится для самопроверки.

4. Ищем материал: видео + пару статей по подтеме, и сохраняем ссылки на то, что лучше всего зашло. Это будет основой для изучения.

5. После прочтения/просмотра материала делаем небольшое резюме (2-3 предложения). Поможет вспомнить материал перед самим собеседованием.

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

Для более эффективной подготовки можете добавить в каждой подтеме два пункта: "теория" и "практика", где будет диапазон от 0 до 100. Так вы сразу увидите свои слабые и сильные стороны. А также поймете, что подтянуть. На скрине показываю часть шпаргалки. Готовил ее очень давно, но подход помогает мне до сих пор.

А как вы готовитесь к собеседованию?

Мой метод был полезен для вас?
👍 - да
🤔 - у меня свой подход (напишите в комментариях)
🔥 - давай в закреп (если соберу 20 🔥)

Python - учим и работами

Почему мой код долго проверяют?

— Можешь посмотреть мои правки? Вот MR (merge request, аналог pull request в GitHub), неделю над ним работал, – попросил знакомый.
— Он большой?
— 1473 строки изменений.
Первая моя мысль): проверю как-нибудь потом. Тут часа три нужно, не меньше.

Смотришь на MR больше 300-500 строчек изменений — первые минут 15 честно пытаешься вникнуть, оптимально ли решает данный код поставленную задачу.

Спустя 15 минут понимаешь, что держать в голове чужой код размером в сотни строк просто НЕРЕАЛЬНО.

В итоге всё ревью скатывается к простой проверке стиля кода.

Результат:
1. В проект попадает неоптимальное решение.
2. Проверяющий не сможет поделиться через обратную связь знаниями. Вы просто узнаете, что функцию лучше назвать по другому, а вот тут добавить аннотацию.
3. Такой MR будет очень долго откладываться «на завтра». Разработчик перед каждой проверкой будет отвлекаться на старый MR, чтобы обновить его в соответствии с главной веткой.

Гугл уже достаточно давно столкнулась с проблемой код-ревью. Они выработали набор правил.

Пункт который нас интересует:
MR должен быть как можно меньше
* Маленький MR можно быстро проверить
* Проверка будет более осмысленной
* Меньше вероятность упустить баг
* Не так обидно, если весь MR будет отклонен. Ведь обидно, когда проделана большая работа, а потом выясняется, что все было зря
* Проще вливать изменения, меньше конфликтов
* Легче добиться хорошего качества кода
* Чем больше изменений за раз, тем сложнее откатывать код при необходимости

Интересно посмотреть остальные пункты из гайда? Тут перевод https://habr.com/ru/articles/474334/

А вы создаете MR?
👍 - да
🤔 - это для слабаков. Я сразу в главную ветку отправляю:)

Python - учим и работаем

Повышаем скорость и качество своего развития

— Как запомнить пройденный материал? — спросил знакомый студент.
— Выпиши 3 пункта, чем тебе было полезно сегодняшнее обучение.

А теперь пошагово:
1. Быстро вспомните, что сегодня прошли и сделайте краткую выжимку.

2. Отметьте и выпишите, чем материал был полезен (поможет осознанно подойти к его освоению и повысить мотивацию).

3. Через 3/7/15 дней перечитайте пункты. Теперь вам понадобится всего несколько минут, чтобы «пробежаться» по тексту и повторить информацию.

Чтобы сделать этот прием еще эффективнее, советую отправить пункты наставнику / преподавателю / ментору. Так вы удержите темп обучения — если пропустите упражнение, будет стыдно перед другим человеком.

Давайте проведём эксперимент? 2 недели попробуем применять этот инструмент на практике. Пишите в комментариях, что сегодня изучали, и какую пользу для себя вынесли:
1️⃣2️⃣3️⃣

Не забудьте поставить:
👍 - я «за» (если наберется 5 участников, то закрепляю пост, и поехали)
🤔 - я всё уже знаю

Python - учим и работаем

Когда важен кругозор

— Бек сделаем на питон, а фронт на джава, – поделился своими планами знакомый, который хотел открыть стартап.
— Чем отличается Java от JavaScript?
— 🤔

Разбавлять контент юмором из ИТ?
👍 - да
🤔 - такое себе…

Python - учим и работаем

Достаем двойные листочки!

— Какого уровня задачки нужно уметь решать, чтобы пройти собеседование у тебя? – спросил мой мети.
— Моя любимая задача «однонаправленный список».

Задача: Написать класс для однонаправленного списка в Python без использования стандартных структур данных (например, list, dict и т.д.).

Требуемые методы:
• get(index): возвращает элемент на заданном индексе
• add(value): добавляет в конец списка элемент с заданным значением
• remove(index): удаляет элемент на заданном индексе

Попробуйте решить тут https://replit.com/@AlexeyNekrasov/PiterPy#main.py
По ссылке доступна заготовка нужного класса и тесты к решению.

Переходим, форкаем и решаем! Ссылку на реплит с решением выкладывайте в комментариях.

А для тех, кто сегодня участвует в конференции PiterPy, мы с @mtsai начисляем +5 баллов за правильное решение. Баллы можно обменять на крутой мерч. Торопись!

Решишь задачку?
👍 - да
🤔 - у меня есть 1000 причин не решать

Python - учим и работаем

Как съесть слона и почему это поможет закончить онлайн-курс

— Ого, ты купил курс, хочешь войти в IT?
— Да, менеджер сказал, что уже в январе смогу поменять профессию и стать востребованным айтишником.
— Но до января остались 3 недели!
— Ничего, я успею…

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

Проходит неделя, другая, месяц. А вы так и не становитесь айтишником за 3 дня. Трек пройден всего на 5%, а конечная цель уже не мотивирует, как раньше. Что делать?

Когда внешняя мотивация истощается, приходится искать внутреннюю. На помощь приходит метод слона, а точнее его поедания:

1️⃣ Разбейте весь курс на небольшие временные отрезки. Так будет проще усваивать материал, а трек не будет казаться чем-то огромным.

2️⃣ Получайте кайф от обучения. Если что-то не нравится – меняем. Это важно для поддержания интереса.

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

4️⃣ Находим наставника или сообщество единомышленников. Они будут мотивировать и напоминать о необходимости двигаться вперед.

А что помогло вам не бросить онлайн-курсы на полпути? Поделитесь в комментариях.

Соскучились по постам?
👍 - да
🤔 - «что я тут забыл?»

Python - учим и работаем

Курица и яйцо в программировании: сначала писать, а потом читать, или наоборот?

— Сначала надо научиться писать или стоит побольше анализировать чужой код?
— Советую делать это параллельно.
— Разве так Python выучишь? Понятно все с вашими курсами.

Что первичнее: научиться писать код или анализировать чужие? В школе на уроках литературы мы учим русский, читая большие произведения классиков. Не заучиваем их бездумно, а вникаем и стараемся понять, что хотел передать автор. В онлайн-школах нередко дают только простые команды, которые необходимо просто повторить.

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

Почему мы в школе изучаем литературу и письмо, а в программирование только письмо?
Литература учит нас анализу, критическому мышлению и пониманию чужой позиции. Программирование, уделяя внимание только активному созданию кода, часто упускает важный аспект — умение воспринимать и оценивать чужой код. А ведь оно помогает усовершенствовать навыки.

Я всем студентам говорю, откройте GitHub, найдите проект Open Source на Python. Посмотрите, какие там issue, и предложите свои правки. Но никто не делает. То ли тяжело разобраться в этом процессе, то ли лень изучить кодовую базу и предложить что-то, то ли страх показаться глупым.

А как вы начинали обучение?  Поделитесь, что нужно освоить в первую очередь.

Согласны с моим мнением?
👍 - да
🤔 - «я учился по чужому коду»

Python - учим и работаем