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

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

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

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

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

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

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

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

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

#android #ошибки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#android #советы

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

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

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

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

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

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

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

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

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

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

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

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

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

7 принципов подготовки тестового задания. Часть 1.

1. Выдержать баланс между простотой и демонстрацией навыков.

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

2. Делать задание самому.

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

3. Сделайте задание за разумный срок или быстрее.

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

4. Сразу продумайте структуру приложения.

Делайте так, как написано в ТЗ. Если не написано – уточните у работодателя, есть ли у вас карт-бланш на любое решение.

По структуре обычно предлагают делать всё по Clean, в отдельных слоях. Со своими учениками я дополнительно отделяю presentation, domain и data в отдельные модули, если вам хватает навыков и времени – сделайте так же.

Для презентейшн-слоя я рекомендую MVVM, как самую распространённую и несложную.

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

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

7 принципов подготовки тестового задания. Часть 2.

5. В каком порядке что писать?

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

Потом реализуем всю необходимую вёрстку.

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

6. Проверка работоспособности.

Желательно успеть проверить работу приложения на реальном устройстве, не только на эмуляторе. Можете написать в Readme, на каком устройстве проверяли.

7. Readme

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

P.S.: если вам нужна помощь с тестовым заданием - пишите мне в личку или в комментарии.

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

Если гора не идёт к Магомету, Магомет идёт прочь

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

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

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

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

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

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

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

8 удобных хоткеев в Android Studio

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

1. Ctrl + B (⌘ + B). B можно заменить кликом мышкой.

Перейти к месту объявления класса/метода/переменной.
Также работает как переход к месту пакета в дереве проекта, если кликнуть на название пакета, который есть на 1 строке любого файла.

Если этот хоткей использовать на названии интерфейса, вы перейдёте к списку использований интерфейса: куда его инжектят, где его байндят, где его реализуют. Если же вы хотите не этого, а перейти к конкретной имплементации интерфейса - на это есть хоткей
Ctrl + Alt + B (⌘ + ⌥ + B)
На методах интерфейса это тоже работает.

2. Ctrl + Alt + O (⌃ + ⌥ + O)

Убрать неиспользуемые импорты в классе.
Чтобы не удалять вручную все эти серые импорты.

3. Ctrl + Alt + L (⌘ + ⌥ + L)

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

4. Shift + F6 (⇧ + Fn + F6)

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

5. Ctrl + Shift + F (⌘ + ⇧ + F)

Поиск строки в указанной папке (предварительно на неё надо кликнуть в дереве проекта).
Если помните на экране какую-то строку, но не помните, как называется сам экран - таким образом сможете его найти.
Если строку нужно не просто найти, а заменить во всём приложении на другую - на это есть хоткей
Ctrl + Shift + R (⌘ + ⇧ + R).

6. Alt + F7 (Fn + F7 + ⌥)

Найти все места использования.
Работает на переменных, классах, айдишниках в xml. Особенно удобно на строках: находите строку в strings.xml, используете на ней хоткей - и видите, где она используется.

7. Shift + O (⌘ + O)

Искать класс по его названию.

8. Ctrl + Z (⌘+ Z)
и Ctrl + Shift + Z (⌘+ ⇧ + Z)

Отменить последнее действие (шаг назад)
и
Вернуть отменённое действие (шаг вперёд)

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

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

#android #лайфхаки

Бесплатный поэтапный Roadmap Android-разработчика с нуля до Junior

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

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

Этот гайд - концентрация моего 9-летнего опыта работы, собеседований и менторинга андроид-разработчиков.

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

#android #работа #роадмап

Paging3 - дар или проклятие?

Рано или поздно начинающий разработчик сталкивается с понятием «пагинация» – постраничная загрузка контента. Разумеется, он идёт искать существующие для этого решения, и неизбежно находит библиотеку Paging3.

Он думает:
«Ура! Эта штука решит проблему пагинации под ключ! На обучающих видео всё делается быстро, удобно и красиво! Документация понятная и с примерами! И это даже не внешняя библиотека, а из гугловского джетпака!».

Давайте обсудим, чем же закончится это приключение.

Поначалу вам понравится и всё покажется удобным. Потом столкнётесь с визуальным багом, и найдёте костыльное решение. Потом с ещё одним. Потом поймёте, что вы можете на 80% решить все свои задачи красиво, но для оставшихся 20% вам нужно вставить 20 отвратительных костылей. Потом, если вы уже умеете в Clean, обнаружите, что Paging3 расползся у вас по всем слоям, заставил вас отсылать ряд избыточных ивентов во вьюху, вынудил ввести костыльные флаги и заводить стейты там, где они быть не должны.
И в этот момент вы поймёте, что Paging3 вас победил, и условия давно диктует он. И придётся решать, стоит ли оно того.

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

Кроме того, для начинающих я категорически советую сделать сначала пагинацию вручную через ScrollListener. С кэшированием и взаимодействием с сетью, с вьюмоделью, и желательно с чистой архитектурой. Увидеть, как оно всё работает, и какие есть проблемы. И только потом попробовать Paging3, чтобы сделать осознанный выбор: от него больше пользы или проблем.
Но ознакомиться с Paging3 я всё же советую, в некоторых компаниях его используют.

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

#android #лайфхаки

❇️ видео про парсинг API ❇️

https://youtu.be/-qCv3jEoFzA?si=5vy_5YGdHBDdy0lZ

#android #видео #лайфхаки

Как джуниору стать миддлом?

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

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

1️⃣ работал ли он в команде с продактами, проджектами, айосерами, бэкендерами, дизайнерами, тестировщиками? Принимает ли он процессы разработки, не будет ли саботировать их?

2️⃣ участвовал ли в перекрёстных код-ревью, умеет ли доносить свои мысли до коллег и принимать критику?

3️⃣ были ли у него конфликты и факапы, как выходил из этих ситуаций?

4️⃣ достаточно ли глубоки его знания об архитектуре? Понимает ли он, для чего это всё, когда это избыточно, а когда нет, и как применять в конкретных бизнес-ситуациях? Может ли он рассказать об этом на своём опыте, а не из книжек?

5️⃣ может ли рассказать об именно своих значимых вкладах в разработку в команде? Не абстрактно: "участвовал в разработке фич", а конкретно: "самостоятельно провёл рефакторинг главного экрана с MVP на MVVM".

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

P.S.: если вам интересно, какие навыки нужны, чтобы стать джуном - ответ тут.

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

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

🚀 Скидка 15% на менторство на https://androidmentor.ru/ 🚀

Привет, друзья!

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

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

✨ Что вас ждёт:

1️⃣ Начальное собеседование-скрининг и индивидуальная программа обучения

2️⃣ Быстрая и тщательная обратная связь, жизненно необходимая для эффективного развития

✅ Результат:
Заточенное именно под вас обучение и менторская поддержка, обеспечивающие максимально эффективный рост и быстрое достижение целей

Подробнее о менторстве на моём сайте.

Но и это ещё не всё.

💥Для тех, кто не уверен, что готов к полноценному менторству, но хочет попробовать, каково это – до конца года я даю скидку в 50% на разовую консультацию со мной.

Записаться на менторство / консультацию со скидкой можно сейчас, а начать в следующем году.

Если вы готовы начать Новый Год продуктивно вместе со мной – приходите в личку.

#android #менторство

Отзыв на менторство

Привет, друзья!

Это отзыв одного из моих менти, с которым мы занимались в этом году.

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

Что мы сделали:

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

🎉 Вскоре Александр устроился на новую работу андроид-разработчиком.

Если хотите ускорить свой путь до устройства на работу – приходите ко мне на менторство. До нового года действует скидка 15%.

Подробнее о менторстве и запись: https://androidmentor.ru/

#android #менторство

@andrdevnotes

Как бы я развивался в андроид-разработке с нуля в 2024 ?

Если представить, что у меня остались все мои знания о мире, но все софты/харды в IT пропали, а мне снова 18 – как бы я строил свой профессиональный путь в 2024 ?

1️⃣ Освобождаю себе максимум времени.
Поступаю в институт попроще, чем МФТИ. Лишь бы дали общежитие.

2️⃣ Учу kotlin.
В институте учился бы спустя рукава, и всё время бы тратил на изучение kotlin.

3️⃣ Устраиваюсь на kotlin-стажировку: коплю деньги на ментора и набираюсь знаний о том, как работает IT-компания внутри.
Подойдёт стажировка в любой IT-компании на вакансию с kotlin. В идеале – андроид, но необязательно, можно и бэкенд.

4️⃣ Выбираю ментора, развиваюсь до джуна.
Через несколько месяцев, когда накопил денег, ушёл бы со стажировки, выбрал бы себе хорошего платного ментора, пришёл к нему с запросом "kotlin знаю, доведи меня до андроид-джуна".
Ещё несколько месяцев плотной работы с ментором – и можно идти на собеседования.

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

Итак: работаю джуном, а параллельно, для ускорения процесса, продолжаю развивать навыки с ментором, пока не стану твёрдым миддлом.

6️⃣ Синьор-ментор.
Дальше – дело техники. Коплю опыт, развиваю софты, становлюсь синьором. А дальше – ментором.

🏁 По моим прикидкам, такой путь занял бы у меня 5 лет вместо 10 к той точке, где я сейчас, и начал бы я его в 18, а не в 21. И я бы был тем самым мемным 23-летним синьором-ментором :)

Мой самый большой страх перед первой серьёзной работой

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

Я знал, как работает гит на уровне commit/push в мастер и всё.
Я не знал о подходах с отдельными ветками, пулл-реквестами, лишь что-то слышал краем уха о код-ревью. Но я так и не смог найти ответ на вопрос, а где и как этот загадочный код-ревью проходит.

Тогда я впервые услышал про какой-то гит-флоу. Советую почитать и оригинальную статью и её критику.

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

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

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