К кому обращаться за помощью? Я же новичок!

На проектах нет тимлида от Девмана. Это приводит к нескольким вопросам, которые нам часто задают. Здесь мы постараемся на них ответить.

На наш взгляд, отсутствие техподдержки наоборот работает отлично. Это стало лакмусовой бумажкой ваших знаний. Не тянете проект —> что-то не так, менторам пора вмешаться.

Если бы вам просто помогали — мы бы протащили вас за уши еще пару месяцев, но никаких самостоятельных разработчиков мы бы не получили.

Если у вас есть проблемы — мы о них узнаем и поможем решить. Иногда оказывается, что дело в слабом английском. Поможем с ним. Иногда дело в чтении чужого кода. Тогда дадим больше заданий на эту тему.

Если что-то не получается – обратитесь к ментору или ПМу

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

С частью вопросов вам может помочь ПМ. Нужно только хорошо сформулировать вопрос, чтобы он вас понял.

Но мы же только учимся! Нам нужен тимлид, как мы сделаем сами?

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

На настоящих проектах никто ссылки для вас не готовит и на шаги проекты не делит. Проекты закрывают недостающие навыки, которым не учат уроки. Да, это сложнее, но и вас трое + вам выдан менеджер, который может помочь с этими вопросами.

Вы справитесь. Главное, не уходите в себя, общайтесь друг с другом и менеджером, не стесняйтесь – задавайте вопросы, высказывайте свои опасения. Не бойтесь показать, что вы чего-то не знаете: командная работа, помимо прочего, это обмен опытом и умениями.

Если все команды поголовно будут не справляться с проектом — мы заметим и вмешаемся.

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

Если нет тимлида, то как мне выбрать библиотеку для проекта?

Мы учим вас быть программистами. Это часто путают с “обучением программированию”, но уметь писать код — это лишь малая часть из всего, что ожидают от программиста.

Мы хотим, чтобы вы стали профи. Часть этого — уметь самому выбирать технологии. Этого нет в курсах: обычно все ссылки на библиотеки приложены прямо в шагах, ничего выбирать не нужно. Но как только вы выйдете на работу, вы обнаружите, что в ТЗ от заказчика нет ссылок на необходимые библиотеки. Тимлид/сениор на работе не будет ежедневно участвовать, он будет всегда занят и максимум что сделает — накинет вариантов. А выбирать из этих вариантов будете вы. И что делать?

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

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

Ошибаться – это часть обучения

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

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

Чем больше от вас просьб починить ваш код, тем менее понятно, а в чем ваша ценность? А чем меньше ценность работника, тем легче с ним расстаются.

Написать неработающий код может любой. Платят за работающий код.

Тимлидов часто возмущает сама идея того, что в случае проблем к вам должен приходить спаситель с надувным кругом и делать самые сложные вещи за вас. Тогда за что вам платит заказчик? Если сотрудник не может выполнять свою прямую работу — его вроде обычно увольняют, а не нанимают другого с ЗП x5-x7, который будет ему помогать. В такой ситуации нужно не тащить вас за уши, а срочно разбираться в ситуации и форсить вас исправить положение.

Статистика показывает, что обычно проблема “нам нужен тимлид” — не организационная, а психологическая. Иногда это страх неизвестности, иногда — нежелание брать на себя ответственность. Иногда что-то ещё. В такой ситуации нужно выдохнуть, прогуляться на свежем воздухе вокруг дома, а затем начать выписывать варианты решения вашей проблемы.

Программистам платят не за код, а за решение сложных проблем

Несколько примеров

Не знаю как делать чат-ботов!

Примеры деструктивных реакций:

• Такого в курсе ещё не было
• В курсе не было такой фичи
• Я использовал другую библиотеку, в этой мне не разобраться
• Пусть с этим разбирается мой сокомандник, мне это не по силам
• Пусть мне подскажет тимлид

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

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

В курсе по Python вы тоже регулярно сталкиваетесь со штуками, которые не делали. Ситуация отличается лишь тем, что в курсе за вас подобраны ссылки на материалы, а здесь их нужно подобрать самостоятельно.

Лайфхак: Если не знаете как подступиться к изучению технологии – загляните в шаги любого урока. Там можно подсмотреть, как обычно для вас строилось изучение новой технологии. Вы найдёте шаги по типу “Запусти туториал из документации” или “Получи токен, который нужен для запуска библиотеки”. Или “Попробуй поменять код из документации под свою ситуацию”.

Вы изучали незнакомые библиотеки уже не раз. В этом нет ничего страшного

---

Не понимаю, почему мой код не работает!

Примеры деструктивных реакций:

• Я работаю с незнакомой библиотекой, я не знаю как тут чинить код
• Это слишком сложно, я ещё не дорос, чтобы чинить такие ошибки в коде
• В этом невозможно разобраться!
• Я тупой, мне не суждено стать программистом
• Тут не справится новичок, нужна помощь наставника!

Конструктивная реакция: Хорошо, нужно разобраться, на какой строчке ошибка. Сформулировать 2-3 гипотезы, откуда она взялась. Ведь я начал писать этот код, мне и разбираться почему я написал его неправильно. Если не получается дольше 2 часов — нужно предупредить менеджера, что фича задерживается. Можно попробовать придумать способ обойтись без этой фичи, либо сменить подход. Подробнее см. статью Откуда берутся нерешаемые проблемы.

Мотивация/Пример из жизни: На работе вы тоже будете писать код. И в нём тоже будут ошибки. Если вы позовёте тимлида, чтобы он починил ваш код — он минимум тяжело вздохнёт и подумает о вас что-то плохое, если не повезёт — открыто пошлёт куда подальше. Ведь если он пришёл переписывать ваш код — получится, что это ему пришлось реализовывать вашу фичу.

В конце концов, в уроках на Девмане вы тоже регулярно сталкиваетесь с ошибками в коде. Просто там на вас не давят сроки. Если вы справляетесь в уроках, то и тут справитесь.

“Незнакомая библиотека” – тоже не аргумент. Вы и так работаете с незнакомыми библиотеками в каждом уроке на Девмане. Перед вами просто ещё одна.

---

Не знаю какую библиотеку использовать, какую правильно?

Примеры деструктивных реакций:

• Я не знаю какие библиотеки хорошие, а какие плохие!
• И что, мне просто взять любую из гугла? А если она не рабочая?
• Как мне понять, в чём отличие между библиотеками? Для этого нужно быть экспертом!

Конструктивная реакция: Окей, попробую минимально разобраться в чём отличие. Не получится за полчаса-час — возьму первую попавшуюся, что поделать.

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

Задумайтесь: а как “ребята из Девмана” выбирают библиотеки? Ответ: мы находим их в гугле или в поиске на pypi, как и вы сейчас. Нет никаких “тайных троп” или списков библиотек, названия которых передаются от учителя к ученику.

Гуглить библиотеки – это нормально

Разве бывают команды без тимлидов?

Отдел без начальника/заказчика (т.е. “ответственного”) – так и правда не бывает.

Но тут мы не видим никаких противоречий. Нанято 3 программиста, им выдан заказчик. Почему им обязательно нужен впридачу старший помощник?

Даже на работе у вас может и не быть тимлида

Мои сокомандники сильнее/слабее меня, нужна сбалансированная команда

На работе не будет никаких “сбалансированных команд”.

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

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

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

Больше на тему

• Откуда берутся нерешаемые проблемы
• Отладка принтами
• Метод утёнка