Очередной секрет успеха
Нам очень долго пихают инфу, что главный секрет богатства — уметь продавать свой час дороже. Мне кажется, эта установка пришла из аутсорсов и бодишопов. Я не переношу эту установку, которая продает мою жопу. Будто не имея за нее власть.
Галера продает гребцов другим работодателям и получает за тебя процент. Чем дороже твой час, тем больше денег у галеры, но не всегда у тебя.
Для меня такое мышление неправильное и разочаровывающее. Пока ты продаешь свои часы, то чаще упускаешь возможности и время.
Для себя я вывел другую формулу, по которой мне нужно двигаться — приносить ценность. Твоя ценность прямо пропорциональна количеству и качеству принесенной тебе ценности, а не накрученной и проданной.
В ней я вижу боевой клич, который сжимает в кулак множество идей. От экономических основ, до подходящей этической модели.
Основная идея моих действий — приносить пользу. Уверен, что это главный актив социума. Иначе ты паразит.
Как же найти эту ценность? Еще одна цель — это быть экспертом в своей области и стараться обрести уникальную экспертизу и навыки, которые ее дают. Пока мне работается —работать усердно. Докопать до золота.
Это очень простая мысль, но которую часто мне сложно донести.
Нам очень долго пихают инфу, что главный секрет богатства — уметь продавать свой час дороже. Мне кажется, эта установка пришла из аутсорсов и бодишопов. Я не переношу эту установку, которая продает мою жопу. Будто не имея за нее власть.
Галера продает гребцов другим работодателям и получает за тебя процент. Чем дороже твой час, тем больше денег у галеры, но не всегда у тебя.
Для меня такое мышление неправильное и разочаровывающее. Пока ты продаешь свои часы, то чаще упускаешь возможности и время.
Для себя я вывел другую формулу, по которой мне нужно двигаться — приносить ценность. Твоя ценность прямо пропорциональна количеству и качеству принесенной тебе ценности, а не накрученной и проданной.
В ней я вижу боевой клич, который сжимает в кулак множество идей. От экономических основ, до подходящей этической модели.
Основная идея моих действий — приносить пользу. Уверен, что это главный актив социума. Иначе ты паразит.
Как же найти эту ценность? Еще одна цель — это быть экспертом в своей области и стараться обрести уникальную экспертизу и навыки, которые ее дают. Пока мне работается —работать усердно. Докопать до золота.
Это очень простая мысль, но которую часто мне сложно донести.
Продолжаю делиться контентом и на очереди мок собес по алгосам.
В закрытом голосовании, среди платных подписчиков, выиграл систем дизайн, а алгосы заняли последнее место. Но я посчитал, что к алго-собесу сложней всего подготовиться и поэтому нужен пробник. Потому что он требует самых практичных навыков — уметь писать код
Вопреки всеобщему заблуждению, во всех алгособесах нет расчета на то, что вы знаете сложные и редкие алгоритмы.
Мы решили показать что оценивают на примере простейших задач:
Please open Telegram to view this post
VIEW IN TELEGRAM
Что выведется в консоли?
Anonymous Quiz
40%
Будет всегда одно число
38%
Числа будут разные
7%
Произойдет ошибка компиляции
10%
Ничего не вызовется
4%
Другое
Что вызовется в консоли №2?
Anonymous Quiz
59%
Будет всегда одно число
27%
Числа будут разные
7%
Будет ошибка компиляции
5%
Ничего не вызовется
2%
Другое
Масштабирование приложений на iOS
Как говорится, old, but gold. Хороший доклад на тему недели — как правильно масштабировать приложение.
Рано или поздно многие разработчики сталкиваются с необходимостью правильной организации апки и все не знают с чего начать.
В этом докладе разбирают:
🟣 модуляризацию
🟣 версионированность
🟣 правильное управление зависимостями
🟣 какие предстоят челенджи
Как говорится, old, but gold. Хороший доклад на тему недели — как правильно масштабировать приложение.
Рано или поздно многие разработчики сталкиваются с необходимостью правильной организации апки и все не знают с чего начать.
В этом докладе разбирают:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Scaling up an iOS Codebase • Tjeerd In't Veen • GOTO 2019
This presentation was recorded at GOTO Copenhagen 2019. #GOTOcon #GOTOcph
https://gotocph.com
Tjeerd In't Veen - Author of Swift in Depth
ABSTRACT
We’ll cover the challenges that arise when we start working with frameworks and versioning. We’ll cover…
https://gotocph.com
Tjeerd In't Veen - Author of Swift in Depth
ABSTRACT
We’ll cover the challenges that arise when we start working with frameworks and versioning. We’ll cover…
Практики кодревью в гугле
Для меня процесс кодревью очень важен. Я даже когда-то ливнул из одной компании, потому что его толком не было и на споры в комментах или экстрасенсорику требовалось больше сил, чем на всю работу вместе взятую.
Подсмотрел в черновиках одного бывшего руководителя Никиты Хромушкина пост про кодревью (потом репостну). В нем он расскажет про хорошие практики, где качество и скорость должны быть в балансе.
В нем он много ссылается на этот гайд. Вот пара интересных мыслей:
🟣 кодревью должно быть быстрым.
Я сам сторонники быстрых кодревью, если они буксуют и идут медленно, то значит проблемы в процессах онбординга и технической культуре команды.
До написания реквеста разраб должен минимизировать все возможные комментарии и подготовить код по общим правилам.
Множество комментариев же говорит о несогласованности и несформулированности критериев качества в команде.
🟣 делайте атомарные реквесты
База. Огромный реквест сложно ревьюить и нередко бывает, что многое упускается
Лучше делать множество маленьких, чем один большой. Стандартный закон «разделяй и властвуй»
🟣 код не должен быть идеален.
Это одно из главных правил, когда тебе попадается душнила, который пишет в один день одни комменты, а на следующий другие. Часто, противоречащие друг другу.
Главное правило «код должен немного улучшать текущую кодовую базу». Не нужно искать идеала
🟣 критикуешь — предлагай
Это еще один из самых бесячих процессов, когда тот же душнила пишет тебе абстрактно или без деталей «это не подходит». Такие комментарии не несут пользы и чаще тратят время. Ведь ты пытаешься угадать логику ревьюера (которая может быть ошибочна). вместо того, чтобы он сам предложил свое решение. Так легче проревьють обоих.
💎 Ну а я напоминаю про новый раздел кодревью, где уже есть и скоро будут новые крутые материалы
Для меня процесс кодревью очень важен. Я даже когда-то ливнул из одной компании, потому что его толком не было и на споры в комментах или экстрасенсорику требовалось больше сил, чем на всю работу вместе взятую.
Подсмотрел в черновиках одного бывшего руководителя Никиты Хромушкина пост про кодревью (потом репостну). В нем он расскажет про хорошие практики, где качество и скорость должны быть в балансе.
В нем он много ссылается на этот гайд. Вот пара интересных мыслей:
Я сам сторонники быстрых кодревью, если они буксуют и идут медленно, то значит проблемы в процессах онбординга и технической культуре команды.
До написания реквеста разраб должен минимизировать все возможные комментарии и подготовить код по общим правилам.
Множество комментариев же говорит о несогласованности и несформулированности критериев качества в команде.
База. Огромный реквест сложно ревьюить и нередко бывает, что многое упускается
Лучше делать множество маленьких, чем один большой. Стандартный закон «разделяй и властвуй»
Это одно из главных правил, когда тебе попадается душнила, который пишет в один день одни комменты, а на следующий другие. Часто, противоречащие друг другу.
Главное правило «код должен немного улучшать текущую кодовую базу». Не нужно искать идеала
Это еще один из самых бесячих процессов, когда тот же душнила пишет тебе абстрактно или без деталей «это не подходит». Такие комментарии не несут пользы и чаще тратят время. Ведь ты пытаешься угадать логику ревьюера (которая может быть ошибочна). вместо того, чтобы он сам предложил свое решение. Так легче проревьють обоих.
Please open Telegram to view this post
VIEW IN TELEGRAM
eng-practices
Introduction {#intro}
Google’s Engineering Practices documentation
Зачем тогда нужен кодревью?
У нас в чате подняли справедливый вопрос «вот я хочу понять что сделал автор в своем реквесте. Оценить риски, понять как интегрироваться с системой. Где мне это делать?»
Точно не на этапе, когда код был написан и сдан на проверку.
Знакомство с фичей должно быть раньше. Задолго до того, когда код начнут писать. Должно быть знакомство с будущей технологией, ее интеграцией и процессом раскатки.
В авито это решается через TDR (tech design review). Именно там происходят все жаркие беседы и спор куда и зачем что пихнуть.
В мобилке они не так сильно развиты, но мне кажется, потому что пока мы не сильно знакомы с этим.
Подробнее о них можно почитать тут и тут
У нас в чате подняли справедливый вопрос «вот я хочу понять что сделал автор в своем реквесте. Оценить риски, понять как интегрироваться с системой. Где мне это делать?»
Точно не на этапе, когда код был написан и сдан на проверку.
Знакомство с фичей должно быть раньше. Задолго до того, когда код начнут писать. Должно быть знакомство с будущей технологией, ее интеграцией и процессом раскатки.
В авито это решается через TDR (tech design review). Именно там происходят все жаркие беседы и спор куда и зачем что пихнуть.
В мобилке они не так сильно развиты, но мне кажется, потому что пока мы не сильно знакомы с этим.
Подробнее о них можно почитать тут и тут
Telegram
Product Developer
Technical Design Review (TDR)
Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.
Но у кодревью есть…
Зачем нужно кодревью — понятно. У каждой компании есть инструмент для кодревью. У многих команд есть договоренности и практики по кодревью. Например, «смотреть PR до стендапа», «критикуешь — предлагай» и тд.
Но у кодревью есть…
Forwarded from Product Developer (Nikita Khromushkin)
Культура код-ревью: приоритеты и скорость
Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект
Альтернативы есть: парное программирование или TDR. Но они подходят не всем.
Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.
Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.
👨💻 Удовлетворение на этапе открытия PR
Speed of Code Reviews
Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?
Так происходит, если написание нового кода поощряется больше, чем ревью.
Команда отличается от рабочей группы наличием общей цели. Для команды должно быть важнее дотолкать цель до прода, чем написать как можно больше кода.
А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»
🤌 Огромные PR
Why Write Small CLs
Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.
- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения
Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.
🏓 Ревью-пинг-понг
Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?
1️⃣ — Новые комменты к нетронутому коду
Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.
Так может происходить, если ревьювер цепляется то за одно, то за другое.
Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».
Могут помочь статьи What to look for in a code review и Navigating in ChangeList.
2️⃣ — Комменты к исправлениям
Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.
- Стоит объяснять, почему просишь изменений.
- Стоит разделять обязательные к исправлению пункты и опциональные.
- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».
How to write Review Comments
===
Итог
Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.
Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?
Можно ли обойтись без ревью ради ускорения Time-to-Market? Теоретически да, но:
1. Можно пропустить косяки
2. Код станет труднее поддерживать
3. Уход единственного разработчика может остановить проект
Альтернативы есть: парное программирование или TDR. Но они подходят не всем.
Поэтому большинство проводит код-ревью. И у большинства есть боль — «зависание» задачи на ревью.
Порефлексировал, почему кодревью затягивается, и что мы делали, чтобы это порешать.
Спойлер: мысли почерпнул в Google’s Code Review Guidelines. Далее буду ссылаться на конкретные части.
👨💻 Удовлетворение на этапе открытия PR
Speed of Code Reviews
Разработчик отправляет код на ревью и с чувством выполненной работы берётся за новую задачу.
Очень легко говорить «никто не ревьювит мой PR». Но кто будет ревьюить, если все кодят?
Так происходит, если написание нового кода поощряется больше, чем ревью.
Команда отличается от рабочей группы наличием общей цели. Для команды должно быть важнее дотолкать цель до прода, чем написать как можно больше кода.
А чтобы доводить цель до прода — код-ревью должно быть быстрым.
Задача тимлида и самих разработчиков — создать культуру, поощряющую быстрое ревью.
«Начал день — сделай ревью, прежде чем сесть кодить. На дейли обсудите спорные моменты.»
🤌 Огромные PR
Why Write Small CLs
Ревьюить атомарные PR на несколько файлов и сотню строк гораздо проще и быстрее, чем 10k строк.
- Маленькие PR ревьювят быстрее и тщательнее.
- Меньше переделывать, быстрее правки по комментам.
- Проще мержить и разрешать конфликты.
- Проще раскатывать в прод и откатывать изменения
Фича кажется «неделимой»? Попробуйте Trunk-based development: слияние в мастер не всегда рабочего кода, закрытого фича-флагами. Начало разработки с абстракций, слияние, затем написание имплементаций.
🏓 Ревью-пинг-понг
Допустим, ревью происходит быстро, но идёт уже десятая итерация.
Почему так?
1️⃣ — Новые комменты к нетронутому коду
Если ревьюер оставляет новые комментарии к неизмененному коду — это проблема. Важно за одну итерацию ревью написать все комменты, обязательные к исправлению.
Так может происходить, если ревьювер цепляется то за одно, то за другое.
Хорошее правило: «PR не должен быть идеальным — он должен улучшать код проекта на одну ступеньку».
Могут помочь статьи What to look for in a code review и Navigating in ChangeList.
2️⃣ — Комменты к исправлениям
Если комменты появляются к тому, как автор переписал код с учетом прошлых комментов — скорее всего стоит улучшить комментарии.
- Стоит объяснять, почему просишь изменений.
- Стоит разделять обязательные к исправлению пункты и опциональные.
- Стоит в явном виде писать, как предлагаешь изменить. Можно даже с частями кода.
«Критикуешь — предлагай».
How to write Review Comments
===
Итог
Мы добавили в чат бота, который каждое утро скидывает список PR для ревью. Бот приходит в личку, если ревью висит больше дня.
Но всё это не работает до тех пор, пока культура ревью не выстроена.
Как только ревью стало такой же целевой работой, как и написание кода — стало быстрее.
Это не все причины, почему задачи могут зависать на ревью.
Поделитесь опытом в комментах — какие проблемы с ревью были у вас и как решали?
Forwarded from Кодируем
Как написать чистый код?
⭐️ Угадываем, что хотел ввести юзер. Немного говорим про low coupling & high cohesion.
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть, чтобы получалось писать чистый и читаемый код даже там, где есть алгоритмы. Какие есть способы? Как начать разрабатывать и писать код? Как приступить? Декомпозируем задачу на каждом уровне абстракции, спускаемся ниже и ниже и решаем проблемы по мере поступления.
🚀 Сделаем программу, которая угадывает, какую команду хотел вызвать пользователь, но ошибся при написании. Мы подскажем ему, какие похожие варианты есть в нашей системе.
🚀 Мы сделаем максимально легковесно без фреймворков и баз данных и полнотекстовых поисковых систем. Просто возьмем и добавим маленькую и полезную фичу.
🚀 Также сделаем так, чтобы наш код был максимально понятный и читаемый. Чтобы мы могли понять все структуру программы, прочитав пару первых функций на самом высоком уровне.
🚀 Нарисуем все основные части нашей программы.
Ньюансы (чтобы экономить время):
❗️ Я не стал покрывать все типами, но это обязательно нужно делать
❗️ Я не стал покрывать тестами, но это очень сильно помогает для понимания кода, его надежности и поддержки
❓ Соберем вместе фреймворк по чистому коду? Как использовать паттерны, принципы. В чем плюсы и минусы. Сложно или нет это делать? Какие принципы знаете уже или хотите услышать? Чтобы "берешь и используешь" его. Чтобы не спорить "А вот смотри наглядно - это не вкусовщина, а у тебя переплетается логика или потекли абстракции - это плохо и тд". Если будут мысли - пишите. Это было бы очень круто. И это совсем иное, нежели бестолковые часто style guides и code reviews
Video:
https://www.youtube.com/watch?v=GsGyrrSC8Rw
Links:
https://en.wikipedia.org/wiki/Levenshtein_distance
#Algorithms #Clean_Code
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть, чтобы получалось писать чистый и читаемый код даже там, где есть алгоритмы. Какие есть способы? Как начать разрабатывать и писать код? Как приступить? Декомпозируем задачу на каждом уровне абстракции, спускаемся ниже и ниже и решаем проблемы по мере поступления.
Ньюансы (чтобы экономить время):
Video:
https://www.youtube.com/watch?v=GsGyrrSC8Rw
Links:
https://en.wikipedia.org/wiki/Levenshtein_distance
#Algorithms #Clean_Code
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как написать чистый код? Угадываем что ввел юзер и дизайним с нуля(общий подход) Clean Code Approach
Telegram post: https://t.iss.one/koduryem/38
Как написать чистый код? Угадываем, что хотел ввести юзер. Немного говорим про low coupling & high cohesion.
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть,…
Как написать чистый код? Угадываем, что хотел ввести юзер. Немного говорим про low coupling & high cohesion.
Лайкай не глядя! Сегодня разберем, какая все же последовательность действий и ход мышления должен быть,…
Я, хз. Но за Пашу болеешь как за своего кента которого участковый забрал по ошибке.
Французы те еще борцы за свободу. Абсурдность ситуации такая же, как если накрутчики опыта спорили с рекрутерами и обвиняли сторонние силы в своих проблемах.
Хотя, подождите…
Французы те еще борцы за свободу. Абсурдность ситуации такая же, как если накрутчики опыта спорили с рекрутерами и обвиняли сторонние силы в своих проблемах.
Хотя, подождите…
Советы по выгоранию для ит специалистов
Выгорание — серьезная вещь. Когда ты молодой и неопытный ты думаешь, что эта проблема касается только тех, кто ноет. Ее не существует и ее выдумали.
Иногда об этом любят говорить «эффективные менеджеры», которые бьют кнутом по спине. А потом все удивляются когда человек уходит из компании.
Мой отпуск заканчивается и я был рад, что почти не думал о работе. Уметь восстановить ресурсы очень важная вещь и наконец, мой отпуск принёс желание делать еще больше дел. Решать задачки 🙂
Я задумываюсь о ресурс менеджменте все чаще. Вот интересная статья для инженеров. Наша специфика работы и задачи могут не всегда дать понять, что нам нужен отпуск.
Мониторинг нашего здоровья и правильные привычки — залог успеха.
Выгорание — серьезная вещь. Когда ты молодой и неопытный ты думаешь, что эта проблема касается только тех, кто ноет. Ее не существует и ее выдумали.
Иногда об этом любят говорить «эффективные менеджеры», которые бьют кнутом по спине. А потом все удивляются когда человек уходит из компании.
Мой отпуск заканчивается и я был рад, что почти не думал о работе. Уметь восстановить ресурсы очень важная вещь и наконец, мой отпуск принёс желание делать еще больше дел. Решать задачки 🙂
Я задумываюсь о ресурс менеджменте все чаще. Вот интересная статья для инженеров. Наша специфика работы и задачи могут не всегда дать понять, что нам нужен отпуск.
Мониторинг нашего здоровья и правильные привычки — залог успеха.
Сталкивались ли вы с выгоранием на работе?
Anonymous Poll
30%
Да, часто
41%
Да, не часто
16%
Нет, но были симптомы
6%
Нет, никогда
6%
Не знаю
Forwarded from AppFiles - Mobile Development
This media is not supported in your browser
VIEW IN TELEGRAM
6 причин не использовать Server Driven UI
Мой главный посыл в этой статье - избегайте использования Server-Driven UI, насколько это возможно (если только команда разработчиков и руководство не разработают хороший конвейер для решения всех проблем). SDUI может сделать распределение кода и ответственности беспорядочным и трудноорганизуемым, даже если все находятся на одной волне. Это решение также может лишить вас гибкости в отношении новых решений в области дизайна и функциональности.
Статья: https://apptractor.ru/info/articles/server-driven-ui-6-prichin-ne-ispolzovat-ego.html
Платформа: архитектура
Мой главный посыл в этой статье - избегайте использования Server-Driven UI, насколько это возможно (если только команда разработчиков и руководство не разработают хороший конвейер для решения всех проблем). SDUI может сделать распределение кода и ответственности беспорядочным и трудноорганизуемым, даже если все находятся на одной волне. Это решение также может лишить вас гибкости в отношении новых решений в области дизайна и функциональности.
Статья: https://apptractor.ru/info/articles/server-driven-ui-6-prichin-ne-ispolzovat-ego.html
Платформа: архитектура
В одном канале я как-то видел очередной кликбейтный заголовок, что BDUI, или же SDUI, — будущее мобильной разработки.
Но чаще я встречаю больше минусов от него. Далеко не все разработчики в разных компаниях от него в восторге. Более того, его начинают недолюбливать не только разработчики, но и дизайнеры. Которым, впервую очередь, ломают творческую свободу
Да, он может хорошо ложиться на простые задачи, но в нем есть множество минусов.
Но чаще я встречаю больше минусов от него. Далеко не все разработчики в разных компаниях от него в восторге. Более того, его начинают недолюбливать не только разработчики, но и дизайнеры. Которым, впервую очередь, ломают творческую свободу
Да, он может хорошо ложиться на простые задачи, но в нем есть множество минусов.
Инфляция знаний, грейдов и навыков
Через год наши знания обесценятся.
Никакие гайды никому не помогут. Забавно, как мы это говорили пару лет, а сейчас это тоже самое повторяют цыгани. Их критиковали за продажу этих ложных обещаний, они сформировали стаи, а сейчас поджав хвост после удаления ютуба, резко переобулись в воздухе. Критиковали курсы и школы программирования, а сами стали тем же. Пользовались неопытностью и доверием желающих войти в ит.
После недавнего перфоманс ревью мы обсуждали с моим руководителем тему повышений. Как формируются требования, конкуренцию между бэком и фронтом, адаптацию рынка.
Никто не знает.
Главное правило, которое я сформировал — это никто не знает что будет завтра. Даже ваши руководители. 90% инженеров, кто получил повышение год назад, с таким бы результатом уже не получили бы в этом.
Система быстро меняется. Именно поэтому самые честные знания могут дать лишь практикующие специалисты. Тк они в авангарде.
Еще пол года назад я говорил один из первых о систем дизайне, а уже сейчас о нем пишет каждый и предлагает менторство, давно не работая или не имея практики. Инфобизнес.
Также и в нашем сообществе мы не стараемся давать гайды, мы даем наши наблюдения и делимся взглядами. Формировать окружение, кто изучает эту бесформенную науку.
Где каждый понимает, что может ошибаться. Где каждый не использует продающие подписку лозунги.
Мы не даем секретных знаний. Мы формируем культуру исследований и боремся с растущей неопределенностью. Ищем выходы и входы, которые с невероятной скоростью то закрываются, то открываются.
Через год наши знания обесценятся.
Никакие гайды никому не помогут. Забавно, как мы это говорили пару лет, а сейчас это тоже самое повторяют цыгани. Их критиковали за продажу этих ложных обещаний, они сформировали стаи, а сейчас поджав хвост после удаления ютуба, резко переобулись в воздухе. Критиковали курсы и школы программирования, а сами стали тем же. Пользовались неопытностью и доверием желающих войти в ит.
После недавнего перфоманс ревью мы обсуждали с моим руководителем тему повышений. Как формируются требования, конкуренцию между бэком и фронтом, адаптацию рынка.
Никто не знает.
Главное правило, которое я сформировал — это никто не знает что будет завтра. Даже ваши руководители. 90% инженеров, кто получил повышение год назад, с таким бы результатом уже не получили бы в этом.
Система быстро меняется. Именно поэтому самые честные знания могут дать лишь практикующие специалисты. Тк они в авангарде.
Еще пол года назад я говорил один из первых о систем дизайне, а уже сейчас о нем пишет каждый и предлагает менторство, давно не работая или не имея практики. Инфобизнес.
Также и в нашем сообществе мы не стараемся давать гайды, мы даем наши наблюдения и делимся взглядами. Формировать окружение, кто изучает эту бесформенную науку.
Где каждый понимает, что может ошибаться. Где каждый не использует продающие подписку лозунги.
Мы не даем секретных знаний. Мы формируем культуру исследований и боремся с растущей неопределенностью. Ищем выходы и входы, которые с невероятной скоростью то закрываются, то открываются.
Предлагаем альтернативы ноушену
Или есть возможность обойти отключение?
Или есть возможность обойти отключение?
This media is not supported in your browser
VIEW IN TELEGRAM
Ждем на наших рынках через 3, 2, 1
И курсы инфоцыган как подготовить правильно резюме 🙂
И курсы инфоцыган как подготовить правильно резюме 🙂
Советы из книги Mobile System Design: Сбор требований
Сейчас перечитываю книгу Mobile System Design и пропускаю сквозь свой накопленный опыт. Попытался адаптировать иногда очевидные советы в общую шпаргалку, но что-то лучше много раз проговорить.
В первой главе автор разбирает алгоритм проектирования и дает определения хорошего дизайна. Немного высмеивая тех, кто первым делом бежит обсуждать какой же паттерн стоит применить к этому проекту MVVM, VIPER и etc еще до того, как не написал даже строчку кода.
Мобильный разработчик является связующим звеном между бэком и дизайном. А значит его главная первостепенная задача — уточнить, верифицировать и завалидировать требования.
Ведь очень не очень, когда мобильный разработчик, не уточнив условия приступил к кодингу, а оказалось делать было нужно совсем не то, что нужно.
Собрал в список рекомендации автора, которые показались мне самые полезные:
Кстати, в базе знаний веду расширенные конспекты
Сейчас перечитываю книгу Mobile System Design и пропускаю сквозь свой накопленный опыт. Попытался адаптировать иногда очевидные советы в общую шпаргалку, но что-то лучше много раз проговорить.
В первой главе автор разбирает алгоритм проектирования и дает определения хорошего дизайна. Немного высмеивая тех, кто первым делом бежит обсуждать какой же паттерн стоит применить к этому проекту MVVM, VIPER и etc еще до того, как не написал даже строчку кода.
Мобильный разработчик является связующим звеном между бэком и дизайном. А значит его главная первостепенная задача — уточнить, верифицировать и завалидировать требования.
Ведь очень не очень, когда мобильный разработчик, не уточнив условия приступил к кодингу, а оказалось делать было нужно совсем не то, что нужно.
Собрал в список рекомендации автора, которые показались мне самые полезные:
🟣Первое правило разработки фичи — не торопись кодить, а попробуй сначала лучше понять проблему
🟣Это нормально, когда нет всех ответов в начале
🟣Обговори что обязательно, а что нет
🟣Если фича сделана на другой платформе, то поговори с разработчиками этой платформы и попроси показать их код
🟣Обговори ошибки, которые нужно обработать. Много условий могут не покрыть ни ответы бэка, ни макеты дизайнеров.
🟣Мобильные разработчики — это проводники между дизайном и бэком. Сохрани время всем находя ошибки, несогласованности и несоответствия
🟣Дизайн — это инструмент для обсуждений, а не финальное состояние продукта. Его можно менять и идти на компромиссы
🟣Пробуй найти скрытые условия и функции, которые упустили дизайнеры
🟣Определяй приоритеты с дизайнером и определи что необязательно делать
🟣Всегда будь вежлив критикуя дизайн
🟣Хорошо изучи согласованное АПИ. Бэкенд отдают верхнеуровневый мок, они могут не учитывать UX/UI
🟣Изучи ошибки, которые отдает бэкенд. Соответствуют ли они требованиям дизайна
🟣Изучи можно ли объединить множество запросов в одинКстати, в базе знаний веду расширенные конспекты