Всем привет.

Начну свой блог с традиционного поста – расскажу о себе. Я действующий синьор android-девелопер и в профессии уже 9 лет. Сейчас, в свободное от работы время, я обучаю начинающих разработчиков, помогая им быстрее достигать джуниор-миддл уровней. В этом канале я буду делиться лайфхаками, как начать карьеру разработчика, возможностями профессии и советами по написанию кода. Надеюсь, это сделает жизнь начинающих разработчиков немного проще.

Моя история. Часть 1

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

Тогда вокруг меня было много знакомых ребят-программистов, я посмотрел, как они кайфуют от работы, и понял, что тоже так хочу!
С помощью одного из таких друзей я по-быстрому освоил ООП и базовый уровень C++ и пошёл работать по знакомству программистом на пол-ставки. Дальше – ловкость рук, документация, гугл и никакого мошенничества: я копипастил код, который вроде как должен был решить мою задачу, бил в бубен и заставлял код работать.

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

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

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

Ну а к чему это всё привело, я расскажу в следующий раз.

Моя история. Часть 2.

Итак, я вернулся к самостоятельному изучению android-разработки, параллельно с текущей работой.

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

Он оказался хорошим ментором, и многому меня научил: чем плохи “тяжёлые” public static переменные, и почему их не стоит держать в активити или синглтонах, что такое утечки памяти, как их находить и избегать, как построить стабильное REST-приложение с кэшированием и многому другому. Он показал мне, что действительно важно в профессиональной разработке, а что - дело вкуса, и как писать код так, чтобы другие смогли его понимать.

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

Но потом я осознал, что перестал развиваться и по уровню, и по зарплате, и я бросил все силы на прокачку своих скиллов, чтобы взять следующую ступень - миддла. Пришлось самостоятельно закрывать ряд важных пробелов: rx, корутины, даггер, паттерны проектирования, clean code. Ещё через полгода-год я уволился из компании и начал поиск работы, и спустя пару недель и несколько собеседований я устроился миддлом, а через 1.5 года стал синьором.

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

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

С чего начать андроид-разработку

Итак, вы приняли решение стать андроид-разработчиком. Как найти дорогу в этом океане неизвестного впереди?

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

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

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

#android #советы

Одна из главных ошибок, которую совершают джуны-разработчики

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

Одной из частых ошибок второго типа является подход "писать код месяцами (в особо запущенных случаях и годами), не показывая его никому". Хотя чем меньше у вас опыта – тем важнее вам регулярная и качественная обратная связь.

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

Например – я так когда-то сделал синглтон, в котором хранил большие коллекции с тяжёлыми элементами. А хранил его в нём, потому что больше не нашёл способа передавать данные из разных фрагментов в разные активити. Я не знал ничего ни о паттерне Repository, ни о Shared ViewModel, ни о Room, ни о Gson'е и Bundle. А синглтон, который кто-то предложил для решения похожей задачи на StackOverFlow, у меня сработал.

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

Хотите развиваться быстрее и эффективнее – найдите человека, который сможет вас вовремя откалибровать и поправить, если вы свернули не туда.

#android #советы

3 лучших книги для начинающего андроид-разработчика

1. Если хотите изучить Kotlin по книге – берём и штудируем книгу от основателей языка: "Kotlin in action". Если у вас есть опыт на Java или похожем языке – зайдёт на ура. Но нужно читать и одновременно пробовать писать код, иначе будет тяжко.

Если знания языков программирования у вас нет – говорят, лучше взять "Atomic Kotlin", но я не проверял. К тому же, один из двух соавторов там Брюс Эккель, Thinking in Java которого я не осилил (я не любитель фундаментальных книжек, люблю что-то полаконичнее и попрактичнее).

В целом, книги по Kotlin я бы рекомендовал использовать скорее как методички, или читать оттуда избранные главы. А так - изучение языка я бы начинал с kotlinlang.org, но это уже другая история.

2. Книга "Чистый код" Р. Мартина для меня не устареет никогда, кто бы что ни говорил. Я уверен, что прочитать её необходимо, потому что попытки следовать советам этой книги однозначно улучшают качество кода новичка. Читается она очень легко.

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

3. А вот книгу "Head First. Паттерны проектирования" вам нужно прочитать совершенно точно безо всяких "а стоит ли". Без знания этих основных паттернов писать код на профессиональном уровне вы просто не сможете, и дальше джуна не пробьётесь точно, да и на джуна только с большой удачей. Книга написана легко и понятно. Если уже знаете Java и/или Kotlin и не читали - читайте немедленно.

#android #советы #лайфхаки #книги

Сколько зарабатывает андроид-разработчик

1. Junior: от 50 000р до 80 000р в месяц.
Зависит от того, сколько задач в компании на вас нагрузят, и от того, будете ли вы единственным разработчиком. Эти два фактора обычно немного повышают оклад, но вы должны понимать, вывезете ли вы такие нагрузки, и сможете ли эффективно развиваться в одиночку. Хотя, если это первая работа, выбора обычно нет - идёшь, куда берут.

2. Middle: от 120 000р до 200 000р в месяц.
Тут вилка становится шире, потому что миддлам в разных компаниях поручают разные задачи и области ответственности. Где-то миддл - винтик в большой машине из джунов/миддлов/синьоров, а где-то - это самый опытный в команде или даже единственный её член, на котором полностью завязан процесс разработки.

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

3. Senior: от 250 000р до 450 000р в месяц.
Тут вилка ещё шире, потому что синьор, помимо крутого кода, может заниматься менторингом джунов/миддлов, собеседованиями, продвижением бренда компании: участвовать в конференциях, писать статьи, книги. Синьор часто является поддержкой тимлида/техлида и выполняет часть их обязанностей.

Чем больше таких областей ответственности вы сможете покрыть - тем больше вам будут готовы платить.

P.S.: Ну и не стоит забывать, что ваш оклад и грейд (джун/миддл/синьор) сильно зависят от того, как вы сможете подать себя на собеседовании. Об этом напишу подробнее в следующих постах.

#android #работа

Какими задачами обычно занимается джун?

Если вкратце - джуну дают небольшое задание и вкидывают его в процесс разработки.

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

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

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

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

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

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

#android #работа

Писать ли сразу чистый код с правильной архитектурой?

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

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

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

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

И так далее. Хорошая архитектура должна решать ваши проблемы, а не создавать их. Появление бессмысленного проксирования и бойлерплейта - знак того, что надо задуматься над упрощением архитектуры. А вот появление дублирования/копирования/неудобства - сигнал к пересмотру архитектуры в пользу более сложной/более подходящей к вашей задаче.

#android #архитектура #лайфхаки

Что учить: RX или корутины?

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

Если вы метите в миддла - важно также понимать, зачем вообще многие переходят на корутины, когда у них есть RX. И простого «ну они легковесные» недостаточно - вы должны показать, что реально на своей шкуре ощутили преимущества и недостатки того и другого.

И самое важное: корутины и RX - это разные реализации многопоточности. Прежде, чем приступать к ним - сначала научитесь отличать шедулер от диспатчера, а трэд от процесса. И про дэдлоки почитать не забудьте :)

#android #лайфхаки #советы

Продуктовая разработка vs галеры

Есть два фундаментельно отличающихся вида разработки: продуктовая и проектная.

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

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

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

Проектная разработка — компания разрабатывает приложение по заказу: заказчик формирует ТЗ и дедлайн, компания делает приложение по этому ТЗ, а потом отдаёт этот проект заказчику и забывает. Все права на приложение, на код, весь заработок с приложения — всё принадлежит заказчику.

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

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

Многие уничижительно называют любую проектную разработку галерами. Я же так называю только такую проектную разработку, в которой к разработчикам относятся, как к рабам, а все минусы выкручены на максимум: мало платят, но вынуждают много работать и овертаймить, «выжимают» человека и нанимают следующего: «у нас таких за дверью целая очередь».

Куда идти - решать вам. Поскольку в проектную разработку, а тем более на галеры, попасть куда проще, чем в продуктовую, то некоторые начинают с этого. Главное - понимать, зачем вы идёте в эту «мясорубку», и не разочароваться в профессии, подумав, что разработка везде такая, как там.

#android #работа #советы

Распространённая ошибка джунов

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

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

Анализируйте свои вопросы и причины их возникновения. Старайтесь объединять их, искать корневую причину и решать её, а не вопросы по отдельности. Как это сделать?

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

Например:
1) вы не понимаете, почему у вас контейнер фрагмента перекрывает тулбар активити
2) вы не понимаете, почему у кнопок обрезается тень
3) вы не понимаете, почему в некоторых приложениях всё выглядит объёмно, красиво, «друг под другом», а у вас всё на одной плоскости и некрасиво.

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

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

P.S.: а какие у вас трудности сейчас? Пишите в комментариях, разберёмся вместе.

#android #ошибки

Не играйте в героя. Или как осилить первое задание?

Итак, тимлид дал вам первое задание. Как к нему подступиться?

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

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

а) сделали что смогли и как смогли, упёрлись в проблему

б) попросили помощи

в) вас скорректировали, подсказали

г) вы пошли работать над задачей дальше

Например: “Мне надо выкачать репозиторий. А, нужны доступы: пошёл к лиду узнавать. Так, надо в фигме вёрстку глянуть. А, опять нужны доступы – пошёл узнавать. Так, теперь работаем. Хм, а как авторизоваться в приложении? Спрошу у команды. Так, работаем. Хм, а вот тут во вьюмодели какая-то странная логика, которую я не понимаю, а мне её надо дополнить – пойду-ка уточню у команды, чтоб ничего не запороть. Так, а как реквесты создавать? Командааа…”

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

Плохие варианты:

а) прийти с неконкретным вопросом: "Я не знаю как делать эту задачу" вместо "а как проверить 500-ю ошибку сервера?" или "гит не даёт скачать репозиторий"

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

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

#android #работа #советы

Как устроиться на работу, или "Где мои 300к/наносекунду?!"

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

Лайвкодинг – распространённый способ проверки того, а умеете ли вы, собственно, программировать? Сложно поверить, но на собеседования реально порой приходят люди, которые начитались книжек и решили, что этого достаточно, а сами за код практически не садились.
Кроме того, лайвкодинг – это программирование под присмотром, а значит – в довольно стрессовой ситуации. Под присмотром на работе вы кодить будете редко, а вот в стрессовой ситуации "Вася, фичу надо было отдать на ревью вчера, какой статус?!" вы будете оказываться регулярно :)

Лайвкодинги бывают разные: могут дать задачки на алгоритмы, могут дать порефакторить плохой/не работающий код, или дать простую задачу типа "Вот метод из API, напиши необходимые классы для отображения контента из этого метода".

Как подготовиться? Найдите того, кто согласится за вами смотреть в процессе программирования, а сами прорешайте десяток-другой несложных задач на leetcode, и добавьте новые фичи в свой проект-портфолио.

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

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

А были ли у вас на собеседованиях вопросы, которые вводили в ступор?

#android #работа #собеседование

Тварь ли я дрожащая или в разработку сумею?

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

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

Зависать на чём-то непонятном для вас – это нормально. Процесс познания не идёт бесшовно. Не бойтесь долго думать и изучать вещи, которые «казалось бы простые» – поверьте моему опыту: многие проходят мимо таких вещей, посчитав их «как бы понятными», но спроси их поглубже – найдёшь непонимание. Даже если у них 5-10 лет опыта. Так что не стесняйтесь искать ответы на простые и «глупые» вопросы, они углубляют ваше понимание и дают прочный фундамент для дальнейшего познания.

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

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

Не обесценивайте свой предыдущий опыт. Он обязательно сыграет вам на пользу, если вы ему это позволите.

#android #советы

Как осилить сложное задание?

Тимлид дал вам задание, а оно кажется вам сложным, и вы без понятия, как его сделать.
Как к нему подступиться?

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

«А как бы ты эту задачу делал? Опиши пожалуйста поподробнее, по шагам, а то я не очень понимаю, с чего начать».

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

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

Итак, вы смогли разбить задачу на несколько частей. Какие-то из этих частей вам под силу. А вот с теми, с которыми вы пока справиться не можете, есть два варианта действий:

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

2) Если задача срочная — тогда лид должен поручить другому члену команды эти непонятные вам части.

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

Запомните: если вы не впали в ступор перед сложной задачей, не постеснялись вовремя попросить помощи, и внесли свой вклад настолько, насколько могли — это точно сыграет вам в плюс.
А вот если вы зависнете на этой задаче, не сможете её сделать, никому об этом не скажете, и это выяснится через несколько дней — вот тогда у вас будут проблемы.

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

#android #работа #лайфхаки #советы