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

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

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

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

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 - учим и работаем

Сжимаем информацию за 10 лет в неделю

— Посоветуй что-нибудь почитать по разработке. И вот ты открываешь гайд, а там — марафон на 10 лет🤯
— Тебе ссылку на книгу Python за 7 дней (255стр) или Изучаем Python Марк Лутц (2 тома на 1400стр)

Если снова не попал в цель с советом, возможно, дело в вопросе. Сформулируйте его чётко:

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

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

Из моего опыта: вот что дают рекрутёры/HR в Яндексе и Тинькофф перед собеседованием — и это золото по сравнению с другими компаниями. Правда это золото вам осваивать пару лет в спокойном темпе.

Тинькофф: https://www.tinkoff.ru/career/it/interview/backend
Яндекс: https://yandex.ru/jobs/pages/dev_interview

Присылайте в комментарии гайды, которые кажутся бесконечными лабиринтами. Давайте вместе оценим, можно ли их осилить за год. 🥲

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

Знать != владеть

— Я прошел курс, изучил все, что должен знать миддл, но меня не повышают.
— А теперь тебе нужно научиться владеть ими.

Важно разделять категории навыков: знаю, умею, владею.
> Знать — понимать в теории, уметь воспроизводить и объяснять материал.
> Уметь — решать типовые задачи за счет стандартных алгоритмов решения. Задачи могут быть взяты из курсов, учебников или интернета. Решая эти задачи, ты начинаешь понимать, как применять теоретические знания на практике.
> Владеть — решать усложненные задачи в нетипичных ситуациях и уметь передать этот опыт. Тут нужно ставить себя в новые, более сложные и нестандартные условия, например, работать над проектами с неопределенными требованиями, участвовать в хакатонах или брать задачи, выходящие за рамки твоих текущих знаний.

При построении индивидуального плана развития (ИПР/PDP) закладывайте не только "Изучить" тот или иной навык, но также время на практику и пет-проекты (чтобы не просто знать, но и уметь).

Хорошая вводная статья по этой теме: Все идет по плану: как составить PDP и прокачать карьеру (кому нужен, как составить, как оценить прогресс)

Уже строили себе план развития?
👍 - да
🤔 - жду от руководителя

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

От "не знаю, что не знаю" к эксперту: Путь через 4 стадии

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

Каждый разработчик проходит 4 стадии развития компетентности, начиная с неосознанной некомпетентности, когда даже не понимаешь объем неизвестного. Далее идет осознанная некомпетентность, осознаешь свои пробелы и начинаешь учиться. Осознанная компетентность требует сосредоточенности, но позволяет решать задачи эффективно. И, наконец, неосознанная компетентность делает выполнение задач автоматическим и эффективным.

Каждая стадия важна для достижения мастерства и помогает определить путь для роста.

Мой опыт показывает, что особенно сложным может оказаться этап осознанной некомпетентности, когда вы начинаете понимать огромное количество областей и инструментов, с которыми ещё не сталкивались. Здесь на помощь приходит Cloud Native Landscape.

Cloud Native Landscape — это каталог инструментов и ресурсов, организованный по категориям. Он включает, такие категории: как базы данных, CI/CD инструменты для разработки и многое другое. Для начинающих разработчиков, исследование этого каталога хорошая отправная точка для изучения новых инструментов и понимания текущих трендов.

Какой этап для вас самый вызывающий в вашем обучении? Поделитесь в комментариях.

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