Android Raccoon - Миша Плеханов

Как оценить задачу, если делаешь это впервые в жизни? Одна из первых проблем, с которой ты можешь столкнуться после трудоустройства - оценка задач. Все эти магические стори поинты (или менее магические часы) - на сколько оценить задачу, чтобы коллеги не засмеяли, а у менеджера не началась тряска? Для начала разберемся со стори поинтами (story point). Что это вообще такое? Это оценка задачи исключительно по сложности, без привязки ко времени. Чтобы понять разницу, проще всего разобрать пример. Вот есть задача - сверстать экран и сделать на нем 1 запрос в сеть (80 процентов всех продуктовых задач на реальном проекте). В команде 2 разработчика - Senior и Junior. Первый сделает задачу за 2 дня, второй в лучшем случае за 4. Так сколько времени тогда ставить в оценку? Чьи часы будут "эталонные"? Стори поинты решают эту проблему - теперь мы любые задачи оцениваем по сложности, а не по времени, что позволяет не думать о том, "в чьих" часах оценена задача. Как правило, в стори поинтах задачи оценивают, используя числа Фибоначчи (1, 2, 3, 5, 8, 13). И сразу возникает справедливый вопрос - мне понятно, сколько я буду делать задачу, оцененную в часах, а сколько делать задачу в 5 стори поинтов? Здесь важно осознать, что оценка - условная, поэтому она может зависеть от конкретной команды/проекта. Какой вариант я наблюдаю чаще всего - выбирается одна или несколько абсолютно стандартных задач, которые уже реализованы целую кучу раз, и на их основе вырабатывается некий эталон. Самый частый пример такой задачи - 1 экран с несложным ui, 1-2 запроса в сеть (самая распространенная задача). И вы решили, что эта задача стоит 5 стори поинтов. И на основании этой оценки формируются все остальные. Например, если создавать новый экран не нужно, но требуется сильно изменить/добавить новые запросы, то это 3 sp. Если, наоборот, сильно меняется верстка, но логика остается неизменной - те же самые 3 sp. Если изменение на экране минорное (понятно, что и где нужно поправить) - справедливо поставить 1-2 sp. Аналогично работает в большую сторону - если нужно сделать все тот же 1 экран, но сложная логика запросов (аутентификация, otp) - это 8 sp. Если сложная верстка, но запросы стандартные - 8 sp. Если все вместе (сложный ui + сложная логика) - 13 sp. Если задачу хочется оценить на 21 sp, то ее нужно декомпозировать и делать по частям, потому что практика показывает, что 21 sp = хрен знает, когда будет сделано. Исходя из вышесказанного, когда вы оказываетесь на новом месте работы, уточните у своих коллег, какие задачи и во сколько у вас обычно оцениваются - это вполне валидный вопрос. А еще лучше посмотрите в Jira, как оценены уже существующие задачи (работает в том числе в командах, где принята оценка в часах). И помните, что умеренное завышение оценки - залог ментального здоровья, не раскручивайте колесо своей продуктивности бесплатно ☝️

Как не вылететь с испытательного срока? Просто работай лол На самом деле, как показывает практика, наиболее частой ошибкой на испытательном сроке является непонимание того, как тебя будет оценивать твой менеджер/тимлид и в чем вообще заключается твоя самая главная задача в первый месяц работы. Самое первое, что следует понять - твой непосредственный руководитель очень хочет, чтобы ты подходил на свою роль и очень не хочет, чтобы ты не подходил. Здесь все достаточно логично 😁 Важно помнить - он просто хочет успокоиться и перестать думать о том, что делать, если вдруг не срастется - ведь каждая ошибка найма невероятно дорого стоит и ведет к сопутствующим проблемам (возможные конфликты при увольнении, непонимание команды, разбор полетов для интервьюеров и тд). Поэтому с твоей стороны нужно сделать одну единственную вещь - успокоить менеджера. Что лучше всего успокаивает менеджера? Закрытые задачи. Тимлид успокоится, когда увидит, что вы: 1. Взяли задачу в работу; 2. Отчитывались по прогрессу на нескольких дейли митингах и своевременно задавали вопросы; 3. Открыли мердж реквест и успешно прошли код ревью (если задача очень большая - важно регулярно делать небольшие реквесты, чтобы руководитель видел результат твоей деятельности); 4. Прошли тестирование, адекватно коммуницировали с тестировщиками; 5. Закрыли задачу ✅ После прохождения такого нехитрого флоу тимлид вздохнет с облегчением и перестанет ежечасно мониторить, что у тебя там вообще происходит, и будет по-умолчанию считать, что ты занят делом и проблем с тобой не возникнет. Твоя задача на оставшийся испытательный срок - не испортить первое впечатление и создавать как можно меньше проблем. Чем меньше ты выделяешься на фоне всех остальных, тем лучше. Все сидят на созвонах с камерой? Ты тоже сидишь с камерой. Максимально подробно рассказывают на дейликах о своих успехах и возникших проблемах? Стараемся рассказывать более развернуто. Шутят на ретроспективах? Поддерживаем позитивный настрой. Если коротко резюмировать все вышесказанное - делаем таски и успокаиваем менеджера. В таком случае проблем не возникнет 👍 🦝 • Менторство

Часть 2 17. Идем в gitlab/github и открываем наш merge request. 18. Проходим код ревью. Процесс зависит от договоренностей внутри компании, но чаще всего вы просто перекрестно друг друга ревьюите в рамках своей кросс-функциональной команды (только андроидеры из вашей небольшой тимы), либо все андроидеры на приложении ревьюят всех. Чаще всего достаточно 2 аппрувов от разработчиков, чтобы реквест можно было замерджить в dev. 19. Если у вас настроен CI/CD и прогоняются какие-то специфические таски - они могут упасть (например, не проходят какие-то тесты или есть проблемы с код стайлом). Если упали - смотрим, что пошло не так и снова идем фиксить. 20. Когда все собралось - мерджим в develop. 21. Перетаскиваем наш тикет из In Progress в Ready To Test и идем в личку к тестировщику - сообщаем о том, что можно начать тестирование. 22. Тестировщик тестирует (как ни странно). Если находит какие-то баги - либо заводит сабтаски в задаче, либо просто комментами оставляет в текущей, либо заводит полностью новую, - все зависит от того, как у вас принято на проекте. 23. Есть баги? Создаем новую ветку от девелопа, фиксим. Затем снова создаем мердж реквест, снова проходим code review и мерджим. Снова отдаем тестировщику. Повторяем до победного. 24. Баги кончились или их не было? Отлично. Это повод перевести задачу в Done (или иной статус, если есть какой-то промежуточный). 25. Берем следующую задачу в работу и повторяем все флоу (c 6 по 24 пункт). Именно в этом заключается твоя работа. 26. Начинается вторая (и заключительная) неделя спринта. Снова понедельник. И сегодня у вас не дейлик - у вас Груминг (выяснение требований, оценка и декомпозиция). 27. Рекомендую посмотреть это видео, потому что иначе здесь будет слишком много текста для описания Груминг встречи. Лучше посмотреть все, но можете найти необходимый минимум по таймкодам. 28. Если после Груминга вы крайне заебались и не можете работать остаток дня - это нормально, вы такой не один. Зачильтесь и повтыкайте в ютуб. 29. В конце недели (а следовательно и спринта) вас будет ждать ретроспектива. Это встреча, на которой команда обсуждает, что прошло хорошо в спринте (обычно это мало всех интересует), а что прошло плохо (ради этого на самом деле эта встреча и существует). 30. В идеале вы обсуждаете самые волнующие проблемы, вырабатываете предложения для решения этих проблем, чтобы в дальнейшем процессы стали лучше, а объем ежедневной головной боли был меньше. 31. Все обсудили, выработали предложения, пожелали всем хороших выходных, отключились. 32. Эм.. ваш спринт закончен, в понедельник стартует новый - будут новые задачи (и старые, если вы что-то не успели довести до конца) и новые решения. И теперь когда вы будете рассказывать о любых процессах в вашей команде, о любых фичах, которые вы разрабатывали - вам нужно опираться исключительно на этот порядок действий и событий. Тогда это будет выглядеть максимально правдоподобно, и ваша легенда будет надежной и не развалится от “разрушителя легенд” на интервьюере. 🦝 • Менторство

Проработка легенды - как не проколоться? Часть 1 При проработке опыта многие вопросы возникают из-за плохого понимания стандартного рабочего процесса и ежедневных рутин, которые составляют 90 процентов всех событий на работе в принципе. Чтобы уверенней чувствовать себя при рассказе о своем опыте и перестать бояться разоблачения, предлагаю ознакомиться со стандартным флоу работы разработчика по Scrum процессу (инфа будет наиболее актуальна для Android). 1. Начало новой недели и нового спринта. Тебе повезло - ты работаешь удаленно, поэтому никуда ехать не нужно. Встаешь с кровати, приводишь себя в порядок, завтракаешь (лучше делать это до митинга, чтобы показать свое улыбчивое лицо менеджеру - так ты кажешься более вовлеченным в работу). 2. За 10 минут до планирования открываешь свой классный корпоративный макбук, заходишь в Slack/Telegram и проверяешь сообщения в чатах - нужен ли ты уже кому-то в начале недели (чаще всего нет, и это хорошо). Немного аутируешь в ожидании встречи, затем с чувством выполненного долга подключаешься в очередному планированию. 3. Ты подключился, поздоровался со всеми (кроме Васи - он опять опаздывает, наверняка выгорел и скоро уволится). Когда все собрались (а на встрече присутствует вся наша кросс-функциональная команда - менеджер, андроидеры, ios-еры, бэкендеры, тестировщики, дизайнер), твой менеджер шарит экран с вашей scrum доской и бэклогом с приоритезированными задачами. 4. Начинаем проходить по задачам бэклога (они уже оценены) и набираем таски, исходя из производительности команды. Обозначаем цель спринта (задачу, которая команда кровь из носу должна выполнить), желаем всем удачи и хорошей рабочей недели, отключаемся. 5. Списываешься с коллегами по Android - кто и какую задачу хочет взять (а кто какую вообще не хочет). Когда решили, кто и что возьмет - начинаем выполнять нашу таску. 6. Открываем тикет с задачей - обязательно прокликиваем все ссылки (figma, swagger), чтобы через пару дней внезапно не выяснилось, что к дизайну у тебя нет доступа, а ты уже успел зарепортить, как усердно верстаешь экраны. 7. Если вдруг чего-то нет - идешь к нужному человеку в личку. Нет ссылки на дизайн - стучишься к дизайнеру, на api - к бэкендеру, нет описания аналитики - к аналитику. 8. Все есть? Отлично. Создаем новую ветку от develop-a - в ней мы будем работать над нашей задачей. 9. Работаем. Да, уже можно. Возникают вопросы - спрашиваем в личке у тех, кто с большей вероятностью может знать ответ. Что-то непонятное происходит в коде? Смотрим по истории в git, кто там набезобразил и доебываемся до него. 10. Да, мы будем постоянно докапываться до людей - потому что ни одна задача не описана идеально, корнер кейсы не всегда обозначены, какой-то компонент в дизайн системе обязательно выглядит не так, как дизайнеру хочется и тд. 11. Каждый последующий день спринта для тебя будет начинаться с дэйли (daily) митинга - это встреча, которая чаще всего проходит утром и на которой каждый член команды рассказывает, чем он занимался вчера, чем планирует заниматься сегодня и есть ли у него какие-то блокеры (то, что блокирует работу - например, не готов дизайн). 12. Часто вы совершенно не в контексте того, чем занимаются другие люди - и это нормально. Просто умно киваете и ждете своей очереди. 13. Все рассказали, какие они молодцы, пожелали хорошего дня, отключились. 14. Опять работа. До конца недели это все наше флоу - работаем и ходим на дейлики. 15. Как только мы решили что закончили нашу задачу (нужно как минимум собрать проект и протестировать на базовых кейсах, что все работает), нам нужно запушить наши апдейты и открыть merge request (иногда называют pull request). 16. Как мы это делаем? Коммитим все изменения, пушим. Рекомендую сразу проверить на возможные конфликты и зафиксить их. Выполняем последовательность git команд - сначала fetch, затем - находясь на рабочей ветке, делаем rebase на develop. Если у вас есть конфликты - студия предложит их зафиксить в специальном интерфейсе. Затем коммитим изменения и пушим. 🦝 • Менторство

Как разобраться в новом проекте? Вы нашли свою первую работу и теперь огромный список модулей пугает вас так, что вы боитесь открыть директорию? Не знаете с чего начать постигать проект, пока тимлид ищет вам первую кнопку на покрас? Тогда вот вам простой и понятный список шагов, которые вам стоит пройти, прежде чем приступить к первым задачам: 1. Какие правила Git Flow приняты в проекте? От чего мы создаем рабочие ветки и есть ли у нас обязательные (или не очень) feature toggles? Имеет смысл уточнить у коллег, так как в разных компаниях могут быть приняты разные правила. 2. Многомодульность - есть ли вообще? Если есть - по какому принципу происходит разделение на модули (папочки с названиями feature, common, core помогут вам в этом). Не зазорно спросить об этом у коллег, если возникнут вопросы. 3. Есть ли Clean? Разбиение внутри модуля или под каждый слой - отдельный модуль? Открываем рандомные фичи и впитываем - где у нас лежат репозитории, где юзкейсы, а где viewModel. 4. Какая архитектура принята на Presentation слое? Открываем viewModel и смотрим - что используется для работы со стейтами (flow, liveData), как происходит работа с многопоточностью (корутины/rxjava). Смотрим и впитываем - во viewModel разного размера и сложности вы проведете большую часть своей андроид жизни. 5. Узнаем, как происходит навигация между экранами (в рамках одной фичи и между фичами), скорее всего во viewModel вы найдете что-то с названиями "router" и "navigation". Заходим в реализации и изучаем - точно понадобится. 6. Смотрим, где наша viewModel вызывается и легким движением руки переходим к UI части. У вас Compose? Поздравляю - вы модные и молодежные. Xml с тонной кастомных view? Искренне сочувствую. На всякий случай сделайте паузу в изучении проекта и забронируйте слот к психотерапевту. 7. Пункт со звездочкой - попробуйте (только осторожно) разобраться в том, как у вас работает DI. Но бояться вам нечего, ведь вы меня послушали и слот забронировали. Находим в вашем фиче модуле директорию с названием DI и пробегаем по таким файлам как Module и Component (скорее всего у вас даггер). Если вы сразу поняли, как это все работает и вяжется в единый проект - вы герой и вообще молодец. Наверняка в этих пунктах для вас не нашлось ничего нового. 8. Узнайте, есть ли у вас дебаг меню (и как его найти), есть ли разделение на стенды - dev, prod и тд. И узнайте, у кого брать тестовых юзеров для логина. Вы великолепны и готовы к покраске своей первой кнопки. Возможно даже к проектированию первого экрана 😁 Дальнейшее осознание проекта будет увеличиваться по мере того, как вы начнете создавать новые фичи и фиксить старые (и не очень) баги. Успехов 👍 🦝 • Менторство

На реальном проекте будет сложнее? У многих в процессе обучения возникает сомнение - вот я сейчас делаю какой-то учебный проект, и вроде все даже неплохо идет, подозрительно.. Наверное, реальные рабочие задачи намного сложнее, чем то, что я делаю прямо сейчас? Не может же все быть так просто? И да и нет. Настоящие проекты действительно могут сложными, но не в том смысле, в котором вы думаете - на базовом уровне они не отличаются ровным счетом ничем. В них используются те же самые технологии и архитектурные паттерны, аналогичным образом происходит работа на уровне сети и тд. Единственное, чем настоящие проекты реально сложнее - они просто больше. Больше кодовой базы (существенную часть из которой вы даже не увидите, даже проработав в компании несколько лет), больше фичей, больше информации в целом. То есть здесь исключительно количественное усложнение, но никак не качественное. И часто может не хватать именно каких-то качественных ориентиров - какого уровня код меня будет ждать на проекте? Чтобы ответить на этот вопрос и дать такого рода ориентир - я пошарю код своего проекта, который в том числе выложен в стор. Стэк: - Kotlin - MVI (Orbit) - Retrofit - Hilt - Coroutines (Под капотом у Orbit) - Compose - Cicerone Также при необходимости я готов пошарить код со своих предыдущих проектов, чтобы наглядно продемонстрировать - никакого rocket science там нет 😁 🦝 • Менторство

Что значит - я усвоил тему? Часто сталкиваюсь с ситуацией, когда ребята, только начинающие свой путь в индустрии, не понимают одну важную и в то же время довольно очевидную для человека изнутри вещь - практически невозможна ситуация в реальной жизни, когда вам нужно написать что-то с полного, абсолютного нуля. В подавляющем большинстве случаев у вас перед глазами будут десятки уже реализованных фичей и тонна кодовой базы, в которой уже существуют все основополагающие элементы - выбрана архитектура, стандартизирована работа с di, реализован общий паттерн работы с навигацией и тд. А значит у вас всегда будет возможность посмотреть существующие реализации, подходы, переиспользовать целые экраны и ui-компоненты. Плох тот программист, который перед работой не проведет ресерч проекта в поиске уже реализованного решения, которое можно использовать при некоторой адаптации. Страшно представить, сколько времени бы занимала разработка, если бы не такой замечательный хоткей, как ctrl + c/v 😁 К чему это я - каждый раз, когда при освоении новой темы у вас возникает ощущение, что без гугла/chat gpt/любой сторонней инфы у вас возникнут сложности с воспроизведением только что изученной информации - это абсолютная норма. На работе вы тоже не будете каждый раз с чистого листа писать ViewModel или UseCase (для упрощения заимствований даже придумали такие штуки как абстрактные классы и интерфейсы), так что не будьте слишком строгими к себе в процессе обучения. Если вы можете воспроизвести некоторый функционал, подглядывая в любой сторонний источник информации - значит вы знаете эту тему. 🦝 • Менторство

Всегда имейте в запасе коронные приемы Ни для кого не секрет, что время интервью ограничено - у компаний нет бесконечного времени, чтобы опросить кандидата максимально глубоко по всем возможным темам. Поэтому нужно соблюдать простое правило - на протяжении всего интервью мы должны как можно больший процент времени говорить о том, что мы очень хорошо знаем. Но часто могут быть кейсы, при которых разные кандидаты примерно на одном уровне отвечают на вопросы и тогда выбор того, кому достанется оффер будет очень рандомным. А ведь мы очень хотим оказаться именно таким счастливчиком, не правда ли? И в этом нам очень помогут наши killer фичи как кандидата - коронные темы, которые мы знаем на высочайшем сениорном уровне, которые должны повергнуть интервьюера в шок и оставить о нас впечатление как о жестком эксперте. И тогда даже в случае, когда на все остальные вопросы мы ответим немного хуже, чем прочие кандидаты - нас все равно выберут, потому что впечатление о нас останется сильнее.  И в какие же темы выгоднее всего инвестировать свое время, чтобы это было максимально эффективно? Очевидно, что в те, которые спрашивают чаще всего и в которых много неочевидных подводных камней - я всегда рекомендую базовую многопоточку, корутины и dagger. Чем глубже вы поймете и изучите эти темы, тем проще вам будет запасть в сердечко интевьюера и забрать свой оффер 😁 🦝 • Менторство

Как заработать 1000 долларов за 1 сообщение? Вам прилетел заветный оффер. Казалось бы - бери, пока дают. Но я настоятельно рекомендую не торопиться и просто отправить рекрутеру это сообщение: "Добрый день! Очень рад получить от вас оффер.) Подскажите пожалуйста, можем ли мы увеличить сумму компенсации? У меня сейчас на руках есть оффер на N, но процесс интервью в вашу компанию показался более комфортным и перспектива развивать ваш продукт мне интересны больше, поэтому я был бы очень рад, если бы получилось увеличить сумму оффера" Примеры того, как волшебно работает такая постановка вопроса прикреплены к посту 😁 Есть ли риски у такого подхода? Минимальные. Ни у меня, ни у моих менти не было случаев отзыва оффера в таких ситуациях. 🦝 • Менторство

Не душните на Code review Боль, с которой я сталкиваюсь буквально на каждом месте работы - люди тратят свое и чужое время на споры о том, как "читаемее/лаконичнее/красивее" с их точки зрения написать какой-то совершенно неважный блок кода. Особенно фрустрирует, когда чтобы удовлетворить чувство прекрасного очередного ревьюера, нужно перелопатить уже готовый и оттестированный на основных сценариях код - с неизвестными последствиями в дальнейшем 🫠 Можно возразить - но это же наша работа, код ревью позволяет избежать ошибок и прочее. Попробуйте сами себе честно ответить на вопрос - насколько чаще вы правите очередной неверный отступ (который вообще-то фиксится через настройку линтера и код ревью не требует вовсе) или спорите о нейминге переменной, чем вносите неочевидный и действительно важный фикс, который бы позволял избежать багов? Как правило - если в проекте есть уже устоявшаяся архитектура и разработчики пишут промышленный стандартизированный код, а не занимаются творчеством (что я особенно осуждаю, кстати), то такие фиксы - единичный кейс. А если нет, тогда у меня плохие новости - ваша архитектура отвратительна и требует рефакторинга, так как у вас слишком много неочевидных вариантов отстрелить себе конечности. Но таких очевидно проблемных проектов на рынке - меньшая часть. Давайте все дружно признаемся, что последние 3-5 проектов, на которых вам довелось работать, были написаны по Clean-у, имели разделение на Presentation, Data и Domain (в рамках отдельных фича-модулей или глобально), на Presentation слое была вариация MVVM/MVI с использованием коктейля из Flow/Corountines/RxJava/LiveData, а ваши Usecases по большей части проксировали получение данных из репозиториев. И что никакого rocket science в этом нет. И вы наверняка согласитесь, что большая часть багов возникает именно во взаимодействии всех элементов этой связки между собой - будь то неверные стейты на UI, ошибки с многопоточкой или сломанный маппинг моделей при передаче между слоями. И мой главный вопрос - как при код ревью разработчик вникнет в бизнес-логику твоей задачи так, что сможет указать на возможные ошибки? Насколько много времени на это может уйти? А занимается ли кто-то этим вообще или просто ищет, в какой переменной у тебя некрасивый нейминг? 😁 Мое предложение - не спорьте в пулл реквестах, а просто сделайте так, как вам указали - сэкономите кучу времени и нервов, они вам еще пригодятся. Естественно исключая вариант, когда чтобы удовлетворить чьи-то очень специфичные вкусы, вам придется фактически переделывать всю работу. Здесь включайте все свои софт скиллы и настаивайте на дополнительной задаче на рефакторинг с отдельной оценкой (перфекционист не оценит, но ваш менеджер будет доволен, что задача закрыта в срок). И последнее - не становитесь таким же перфекционистом. Бейте себя по рукам, когда в очередной раз хотите упрекнуть кого-то в вызове invoke() или неиспользовании деструктора. Берегите свое и чужое время ⏳ 🦝 • Менторство

Грань будущего - переводим количество в качество Заметил, что многие разработчики - причем как начинающие, так и вполне сеньорные ребята, - слишком щепетильно относятся к подготовке к интервью. Причем я не имею в виду ситуацию, когда ты смотришь записи чужих собесов для подготовки, освежаешь в памяти какую-то теоретичекую инфу, которую в работе применял пару лет назад (если вообще применял). Я о том, что ребята тратят много сил и времени на мок интервью, на прочтение свежего издания Kotlin in Action или (если случай совсем запущенный) на подготовку к алгоритмической секции. Подобный подход может дать свои плоды, если ты ставишь своей целью пробить зарплатный потолок или получить оффер на валютную удаленку - потому что в данных кейсах вакансий ограниченное количество, ты успеешь откликнуться на все релевантные предложения в течение месяца, а новые процессы сможешь запускать 1-2 раза в неделю максимум. Но когда речь идет о начинающих, либо о ребятах, пока еще не забравших у рынка свои 400-500к - такой подход просто не нужен, вы банально теряете деньги, если следуете ему. Намного эффективнее провести 1 настоящее интервью и начисто провалиться на нем, чем провести 3 моковых собеса. Сделав запись и разобрав одно свое интервью, вы станете существенно более подготовленным к следующему, разобрав два - еще более подготовленным и тд. Я даже не говорю о том, что ваше моральное состояние на интервью напрямую влияет на людей, которые его проводят - неуверенные ответы чаще трактуются как незнание и накрученный опыт, чем банальное человеческое "ну чувак просто волнуется, так-то он крутой". Немаловажный факт, о котором также иногда почему-то забывают - интервьюеры, которые проводят ваш собес сегодня, понятие не имеют о том, что вчера вы не знали, как правильно отменять корутину или забыли контракт equals/hashcode. Почему бы этим не пользоваться и не учиться на своих ошибках с каждой новой итерацией? 😁 🦝 • Менторство

Welcome пост 🦝 Всем привет! Меня зовут Миша, я действующий Android Developer, Ментор и автор этого блога 👋 Внезапно осознал, что возникла необходимость (почти физическая потребность) выкладывать разную общую информацию по поиску работы в открытый доступ - просто чтобы не отвечать на однотипные вопросы и сразу посылать всех по известному адресу + естественно привлечь новую аудиторию 😁 Почему мои мысли заслуживают внимания? Я разбираюсь в том, как получать офферы - мой текущий совокупный доход как Android разработчика - более 10к долларов. Пруфы Что будет публиковаться на канале: - советы по поиску работы; - как получать больше денег; - посты о мобильной разработке; - истории из личного опыта; - разбор психологических проблем разработчиков. Подписывайся 😄