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

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

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

Зависать на чём-то непонятном для вас – это нормально. Процесс познания не идёт бесшовно. Не бойтесь долго думать и изучать вещи, которые «казалось бы простые» – поверьте моему опыту: многие проходят мимо таких вещей, посчитав их «как бы понятными», но спроси их поглубже – найдёшь непонимание. Даже если у них 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 #работа #советы

Как выглядит работа андроид-разработчика в продуктовой команде?

1️⃣ Тот код, что в продакшне (то есть у пользователей), всегда лежит в мастер-ветке. Код, который вы пишете, окажется в мастере только в самом конце вашей работы над задачей, после код-ревью, тестов и релиза в стор. До этого он будет существовать в отдельной ветке, которая будет ревьюиться и тестироваться.

2️⃣ Вам приходит таска в таск-трекере (Jira, Miro, etc.), например «Интегрировать новый дизайн на экране авторизации».

3️⃣ Вы от мастера ответвляете свою ветку под эту таску.

4️⃣ Пишете в этой ветке свой код для таски.

5️⃣ Коммитите/пушите изменения в своей ветке и создаёте из ветки пулл-реквест в гитхаб.

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

7️⃣ После того, как коллеги решили, что ваш код в порядке - они ставят "Approve" пулл-реквесту, и после этого вашу ветку можно отдавать в тестирование. В зависимости от договорённостей в команде и её размера, вам может потребоваться один или несколько аппрувов.

8️⃣ Если тесты прошли успешно - ваша ветка мёрджится в релизную ветку, если нет - идёте вносить исправления и снова отдавать на код-ревью.

9️⃣ Релизная ветка — та, которая пойдёт в стор, и сразу после этого смёрджится в мастер. В релизную ветку сливаются все ветки, которые проревьюены, протестированы и готовы к публикации в стор.
Важно: перед тем, как мерджить свою ветку в релизную, вам может понадобиться исправить мердж-конфликты. Они возникают, если в одном и том же месте в двух ветках были внесены разные изменения, и вам нужно определиться, что с этим делать: заменить одно изменение другим, или добавить и то и другое, или каким-то ещё образом выйти из этой ситуации, не сломав логику обоих изменений. Это можно делать или внутри Android Studio, подлив релизную ветку в свою, а потом исправить конфликты и запушить итоговые изменения в свою ветку, или в самом гитхабе в пулл-реквесте.

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

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

@andrdevnotes | androidmentor.ru

Бесконечные муки или источник кайфа?

На пути разработчика вам придётся привыкнуть к одной простой мысли: ваши усилия != количество написанных строк кода. Иначе оценка труда разработчика и его оплата была бы куда проще и прозрачнее.

Когда-то я считал иначе. И на полном серьёзе думал, что увеличение скорости печати сделает меня лучшим профессионалом :)

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

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

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

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

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

А сколько вы кода при этом напишете – не так важно. По сути, чем меньше кода – тем лучше. Не тот крут, кто пишет 1000 строк кода в день, а тот, кто 100 строками кода решает ту же задачу, что менее опытный за 1000 строк :)

#android #советы

@andrdevnotes | androidmentor.ru

Надо ль вам идти с понятного пути в непонятное IT?

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

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

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

Почему я ушёл из науки?
Потому что потолок белой зарплаты там был
100 000р через несколько лет упорного труда, что меня не устраивало.

Почему я ушёл из науки?
Потому что я месяц почти не появлялся на рабочем месте, а после возвращения я услышал лишь «о, а ты не в отпуске был? Ну ладно». И я понял, что моя работа здесь никому не нужна.

Совсем по-другому в IT. Здесь у тебя постоянно горит земля под ногами от того, что тебе со всех сторон твердят: то, что ты знаешь, уже никому не нужно. Это вам не НИИ, тут знания протухают очень быстро. И ты вместе со всеми бежишь вперёд и развиваешься.

Идти ли вам в IT? Нет, если вы не готовы пахать. Первые полгода – год в обучении, хотя бы по 4 часа в день, а потом ещё год-другой в команде, пока не станете крепким миддлом. А там вас уже затянет, если до тех пор не сольётесь.

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

#android #советы

@andrdevnotes | androidmentor.ru