Разработчик — больше чем профессиональный кодер

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

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

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

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

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

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

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

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

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

В текущих реалиях мы считаем, что Apple/Google могут наложить запрет на всех разработчиков (юр и физ лиц) из этих трех стран. Реальный варинт что можно сделать — быстро открыть юридическое лицо и банк в другой стране, однако нужно понимать, что некоторые американские банки уже закрыли доступ из России и дальше могут реализоваться другие риски.
* https://vc.ru/legal/116932-kak-otkryt-amerikanskuyu-kompaniyu-i-ne-oblazhatsya тут моя статья про открытие юр лица и банка в США. Обычно я не даю никаких комментариев и советов по ней, но тут постараюсь помочь.
* Рассмотрите варианты с юрлицом в UK, Нидерландах и Португалии — я не знаю деталей, но говорят там не сложно.
* На Кипре в последнее время много юридических тонкостей, но думаю в вашем окружении много ребят, кто открыл там компанию.
* Открытие юр лица в Сингапуре (загуглите компания Osome — это сервис для открытия компания юр лица).
* Говорят про Сербию и другие страны рядом, но я ничего не знаю.

Peace

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

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