Привет! Меня зовут Давид Шекунц, я – Tech Lead Go & TS Tech Lead, а вы находитесь на сайте с постами из моей 🦾 IT-Качалки 💪
Подписаться на ТГ-канал
Подписаться на ТГ-канал
2021-03-28 14:28
🔥 Воркшоп через полтора часа 🔥
Напоминалочка
Кто сможет, всем буду рад 🥰
Напоминалочка
Кто сможет, всем буду рад 🥰
2021-03-27 12:30
😩 Устал быть мидлом? Не знаешь куда, а главное как развиваться? А может вообще надоел кодинг? 😩
Я вас отлично понимаю, я тоже был в ситуации этого распутья, НО мне сильно повезло и за последние 7 лет я сумел поработать в куче разных ролей и хочу рассказать вам: как и куда может расти middle разработчик (даже если не хочется больше кодить)
Завтра воскресенье 28.03 в 19:00 я проведу воркшоп, в котором расскажу про пути "🦍 Эволюции разработчика 👨💻" (по мотивам постов #evolution)
Сорян, что так резко, понимаю, что многие не смогут прийти, но не отчаивайтесь, я проведу этот еще воркшоп пару раз и буду предупреждать за неделю, так что вы точно успеете
Воркшоп пройдет в zoom (ссылку кину завтра в канал), потому что мне важно иметь возможность дискутировать с вами и вживую отвечать на все вопросы
Добавляйте событие в календарь и ждите ссылочки, всем качалки 🦾
Я вас отлично понимаю, я тоже был в ситуации этого распутья, НО мне сильно повезло и за последние 7 лет я сумел поработать в куче разных ролей и хочу рассказать вам: как и куда может расти middle разработчик (даже если не хочется больше кодить)
Завтра воскресенье 28.03 в 19:00 я проведу воркшоп, в котором расскажу про пути "🦍 Эволюции разработчика 👨💻" (по мотивам постов #evolution)
Сорян, что так резко, понимаю, что многие не смогут прийти, но не отчаивайтесь, я проведу этот еще воркшоп пару раз и буду предупреждать за неделю, так что вы точно успеете
Воркшоп пройдет в zoom (ссылку кину завтра в канал), потому что мне важно иметь возможность дискутировать с вами и вживую отвечать на все вопросы
Добавляйте событие в календарь и ждите ссылочки, всем качалки 🦾
2021-03-21 22:06
Привет!
Да, без проблем, опиши деталивсе на rxjs
реализуем канбан доску, с обновлением по сокетам
Есть менеджер состояний.
В упрощенном варианте все базируется на трех сущностях
funnel - воронка
stage - этап
deal - сделка
Рассмотрим 2 структуры (псевдо разметка). И в качестве примера задача: меняется значение color у сущности stage, информация об этом пришла по сокетам
1 вариант структуры
funnel$: Observable<T> = {
name: T,
...,
stages: T[] [{
name: T,
color: T,
...,
deals: T[] [{
name: T,
...
}]
}
}
в случае изменения цвета, находим stage по id, изменяем значение color, затем $funnel.next($funnel.value)
данные на клиенте обновились.
2 вариант
funnel$: Observable<T> = {
name$: Observable<T>,
...,
stages$: Observable<T[]> [{
name$: Observable<T>,
color$: Observable<T>,
...,
deals$: Observable<T[]> [{
name$: Observable<>,
...
}]
}
}
в случае изменения цвета, находим stage по id, изменяем значение color, затем $funnel.value.stages$.value[index].value.$color.next(color);
данные на клиенте тоже обновились
Вопросы
1) как вообще обычно делают такие штуки, может какой-то из способов вообще не приемлем?
2) на мой взгляд у каждого способа есть свои плюсы и минусы. Глобально в первой проще намного работать с данными внутри компонент, во втором намного меньше рендерятся компоненты, завязанные на данных.
3) подозреваю, что выбор зависит от бизнес-задач, как часто будут приходить сообщения об изменении данных.Попробую ответить, если правильно понял
Для начала определим возможные проблемы:
1. Сложность написания кода
2. Зависания из-за ререндеринга
3. Зависания из-за обновления громадных сущностей
3 – только в том случае, если сущность очень объемная (сотни полей). Эту проблему можно обойти тем, что часть обхемных атрибутов (например связи) выносить в отдельное место и связывать по id (как нормализация в БД) или превращать тоже в Observable (то есть не все поля, а только это)
2 – в первом случае, у вас будет одна большая подписка, в которую будет падать полный объект и если не разрулить на уровне компонентова понимание \"(не)изменилось\" будет перерисовывать вееесь элемент и все его дочерние компоненты. Тут соответственно или проверка на изменение или, если компонент небольшой, забить хрен и не париться
1 – первый вариант намного проще
Поэтому, наверное, я бы сделал так: используете первый вариант, не делаете никаких оптимизаций, смотрите на то виснет или не виснет интерфейс при частых обновлениях (например, окажется, что частота обновления настолько большая, что ререндеринг слишком чато происходит)
Далее начинаете писать сравнение на изменение в элементах
Потом превращаете какие-то отдельные атрибуты сущности в Observable (большими кусками) и делаете на них отдельную подписку💬 Вопросы от подписчиков 💬
Прекрасная задачка на тему структуры менеджера состояний на фронте
Не стесняйтесь писть и вы свои вопросы мне в ЛС (@davidshekunts) с удовольствием отвечуПривет! Сможешь помочь консультацией по менеджеру состояний на фронте?
Да, без проблем, опиши деталивсе на rxjs
реализуем канбан доску, с обновлением по сокетам
Есть менеджер состояний.
В упрощенном варианте все базируется на трех сущностях
funnel - воронка
stage - этап
deal - сделка
Рассмотрим 2 структуры (псевдо разметка). И в качестве примера задача: меняется значение color у сущности stage, информация об этом пришла по сокетам
1 вариант структуры
funnel$: Observable<T> = {
name: T,
...,
stages: T[] [{
name: T,
color: T,
...,
deals: T[] [{
name: T,
...
}]
}
}
в случае изменения цвета, находим stage по id, изменяем значение color, затем $funnel.next($funnel.value)
данные на клиенте обновились.
2 вариант
funnel$: Observable<T> = {
name$: Observable<T>,
...,
stages$: Observable<T[]> [{
name$: Observable<T>,
color$: Observable<T>,
...,
deals$: Observable<T[]> [{
name$: Observable<>,
...
}]
}
}
в случае изменения цвета, находим stage по id, изменяем значение color, затем $funnel.value.stages$.value[index].value.$color.next(color);
данные на клиенте тоже обновились
Вопросы
1) как вообще обычно делают такие штуки, может какой-то из способов вообще не приемлем?
2) на мой взгляд у каждого способа есть свои плюсы и минусы. Глобально в первой проще намного работать с данными внутри компонент, во втором намного меньше рендерятся компоненты, завязанные на данных.
3) подозреваю, что выбор зависит от бизнес-задач, как часто будут приходить сообщения об изменении данных.Попробую ответить, если правильно понял
Для начала определим возможные проблемы:
1. Сложность написания кода
2. Зависания из-за ререндеринга
3. Зависания из-за обновления громадных сущностей
3 – только в том случае, если сущность очень объемная (сотни полей). Эту проблему можно обойти тем, что часть обхемных атрибутов (например связи) выносить в отдельное место и связывать по id (как нормализация в БД) или превращать тоже в Observable (то есть не все поля, а только это)
2 – в первом случае, у вас будет одна большая подписка, в которую будет падать полный объект и если не разрулить на уровне компонентова понимание \"(не)изменилось\" будет перерисовывать вееесь элемент и все его дочерние компоненты. Тут соответственно или проверка на изменение или, если компонент небольшой, забить хрен и не париться
1 – первый вариант намного проще
Поэтому, наверное, я бы сделал так: используете первый вариант, не делаете никаких оптимизаций, смотрите на то виснет или не виснет интерфейс при частых обновлениях (например, окажется, что частота обновления настолько большая, что ререндеринг слишком чато происходит)
Далее начинаете писать сравнение на изменение в элементах
Потом превращаете какие-то отдельные атрибуты сущности в Observable (большими кусками) и делаете на них отдельную подписку💬 Вопросы от подписчиков 💬
Прекрасная задачка на тему структуры менеджера состояний на фронте
Не стесняйтесь писть и вы свои вопросы мне в ЛС (@davidshekunts) с удовольствием отвечуПривет! Сможешь помочь консультацией по менеджеру состояний на фронте?
2021-03-18 17:31
🌉 Оффлайн встреча в Питере 🌉
Ребятки, кто сейчас в Питере, пишите мне в ЛС (@davidshekunts) давайте встретимся, предположительно, в воскресенье вечером в центре Питера
Более подробное место и время согласуем в ЛС
Всем доброй прокачки 💪
Ребятки, кто сейчас в Питере, пишите мне в ЛС (@davidshekunts) давайте встретимся, предположительно, в воскресенье вечером в центре Питера
Более подробное место и время согласуем в ЛС
Всем доброй прокачки 💪
2021-03-15 16:47
💸 Просить повышение – ваша ответственность 💸
Я решил прокачать инстаграмм, потому что реклама в ТГ и приток пользователей пока неочень активный, а хочется больше людей, чтобы нести больше пользы
Поэтому приглашаю вас всех присоедениться и вместе прокачивать свои скиллы 💪
В ближайшее время я буду много говорить о росте и развитии в IT, о стрессе и выгорании и что с ними делать, о способах и подходах к проектированию IT-систем и менеджменту проектов
https://www.instagram.com/p/CMaWEhpKkRq/
Я буду по-прежнему писать в ТГ, но всякое более хардкорное
Заходите, подписывайтесь и осталяйте свои мысли 💋
Я решил прокачать инстаграмм, потому что реклама в ТГ и приток пользователей пока неочень активный, а хочется больше людей, чтобы нести больше пользы
Поэтому приглашаю вас всех присоедениться и вместе прокачивать свои скиллы 💪
В ближайшее время я буду много говорить о росте и развитии в IT, о стрессе и выгорании и что с ними делать, о способах и подходах к проектированию IT-систем и менеджменту проектов
https://www.instagram.com/p/CMaWEhpKkRq/
Я буду по-прежнему писать в ТГ, но всякое более хардкорное
Заходите, подписывайтесь и осталяйте свои мысли 💋
2021-03-02 16:00
🧠 Знания пораждают скорбь 💧
Я ненавижу проходить собеседования у менее квалифицированных специалистов, чем я.
Вот задают тебе вопрос:
"Занимались ли вы масштабированием High Load баз данных?"
И поскольку у меня был достаточно большой опыт я вспоминаю как мы проектировали распределенную систему, с георепликацией, кучей master-slave реплик, шардированием, подключением OLAP системам, локальными БД с проекциями из основной и кучей другой очень сложной шелупони.
Но сам, я не раскрывал эти БД и не настраивал их коммуникацию, потому что это настолько сложно, что даже несколько Senior Архитекторов БД месяцами бились над этой задачей.
Поэтому я честно отвечаю:
"Я проектировал, но сам не занимался"
Интервьюирующий пишет у себя:
"Не имеет опыта масштабирования баз данных"
И так проходит куча тонких вопросов, я честно отвечаю на каждый из них, а в самом конце, начинаю сам задавать вопросы, и тут выясняется...
Во-первых, текущая БД просто не подходит под задачи архитектуры и ее масштабирование в 10 раз дороже, чем использование стороннего доступного решения, которое полностью закроет всю потребность. И нет никаких причин его не использовать.
А во-вторых, у интервьюера всего 1-2 года за плечами...
Вот он в свои 1-2 года уверен, что "надо масштабировать БД".
А я, поскольку уже много лет сталкивался с этими проблемами, понимаю, что не БД надо масштабировать, а немного архитектуру поменять, так чтобы сэкономить х10 времени и сил.
Только по итогу я со своими знаниями и сомнениям – полупокер лоховской, а вот этот мидл – маестро ле монефик.
Потому что меня обуревает тяжесть своих знаний и понимание бесконечности своего незнания, а его пока нет.
Короче, господа Суньеры и другие опытные спецы, чаще бы нам с вами уверенности юнцов, ведь на деле вообще никто ничего не знает и нет в этом ничего плохого.
Я ненавижу проходить собеседования у менее квалифицированных специалистов, чем я.
Вот задают тебе вопрос:
"Занимались ли вы масштабированием High Load баз данных?"
И поскольку у меня был достаточно большой опыт я вспоминаю как мы проектировали распределенную систему, с георепликацией, кучей master-slave реплик, шардированием, подключением OLAP системам, локальными БД с проекциями из основной и кучей другой очень сложной шелупони.
Но сам, я не раскрывал эти БД и не настраивал их коммуникацию, потому что это настолько сложно, что даже несколько Senior Архитекторов БД месяцами бились над этой задачей.
Поэтому я честно отвечаю:
"Я проектировал, но сам не занимался"
Интервьюирующий пишет у себя:
"Не имеет опыта масштабирования баз данных"
И так проходит куча тонких вопросов, я честно отвечаю на каждый из них, а в самом конце, начинаю сам задавать вопросы, и тут выясняется...
Во-первых, текущая БД просто не подходит под задачи архитектуры и ее масштабирование в 10 раз дороже, чем использование стороннего доступного решения, которое полностью закроет всю потребность. И нет никаких причин его не использовать.
А во-вторых, у интервьюера всего 1-2 года за плечами...
Вот он в свои 1-2 года уверен, что "надо масштабировать БД".
А я, поскольку уже много лет сталкивался с этими проблемами, понимаю, что не БД надо масштабировать, а немного архитектуру поменять, так чтобы сэкономить х10 времени и сил.
Только по итогу я со своими знаниями и сомнениям – полупокер лоховской, а вот этот мидл – маестро ле монефик.
Потому что меня обуревает тяжесть своих знаний и понимание бесконечности своего незнания, а его пока нет.
Короче, господа Суньеры и другие опытные спецы, чаще бы нам с вами уверенности юнцов, ведь на деле вообще никто ничего не знает и нет в этом ничего плохого.
2021-03-01 16:00
🤐 Главный секрет проектирования и архитектуры 🤐
Абсолютно все, что мы делаем в IT сводиться к 3-м функциям: (1) передача, (2) обработка и (3) хранением данных.
Мы делаем запрос на сервер и передаем с него данные на фронт.
Мы визуализируем эти данные в формах и таблицах, передавая их во внешний мир через дисплеи компьютеров, мобилок и других устройств.
А потом внешний пользователь через интерфейсы доступа (клавиатура, touch панель, переключатели) в обратную сторону передает данные в устройство.
Мы трансформируем эти данные заполняя формочки на фронте, а потом трансформируем их же на бэке.
В конце мы сохраняем эти данные в базах данных и цикл повторяется заново.
И все это работает не только в вебе:
Нажав на кнопку умной кофеварки, мы передаем команду устройству, мы трансформируем и сохраняем изменившийся бит в микроконтроллере, это дает положительный заряд на пластинку кремния, который в свою очередь активирует транзисторы, пропускающие 5-12 вольт на реле, где заряжается магнитная подушечка, происходит соединение металических контактов и по ним начинает течь 220 вольт. Наш умный кофе поступает в тупой стакан.
В итоге, абсолютно все задачи по проектированию архитектуры IT-систем сводятся к 3-м вопросам:
1. Как мы будем передавать данные?
2. Как мы будем их трансформировать?
3. И как мы будем их хранить?
Вы просто снова и снова задаете себе эти вопросы и ищите ответы. В разрезе всех участвующих систем: интерфейсов, серверов, сетей, устройств, etc.
Хороший проектировщик / архитектор не только знает как построить все эти цепочки, но знает как это сделать максимально оптимизировано и чтобы при этом на разработку не ушли годы.
P.S.
Я – бездарь и неучь и уверен, что эти мысли были сформулированы задолго до меня, поэтому предлагаю вам поправить меня, если вы не согласны с какой-либо из формулировок. Поскольку только вместе мы – сила 💪
Абсолютно все, что мы делаем в IT сводиться к 3-м функциям: (1) передача, (2) обработка и (3) хранением данных.
Мы делаем запрос на сервер и передаем с него данные на фронт.
Мы визуализируем эти данные в формах и таблицах, передавая их во внешний мир через дисплеи компьютеров, мобилок и других устройств.
А потом внешний пользователь через интерфейсы доступа (клавиатура, touch панель, переключатели) в обратную сторону передает данные в устройство.
Мы трансформируем эти данные заполняя формочки на фронте, а потом трансформируем их же на бэке.
В конце мы сохраняем эти данные в базах данных и цикл повторяется заново.
И все это работает не только в вебе:
Нажав на кнопку умной кофеварки, мы передаем команду устройству, мы трансформируем и сохраняем изменившийся бит в микроконтроллере, это дает положительный заряд на пластинку кремния, который в свою очередь активирует транзисторы, пропускающие 5-12 вольт на реле, где заряжается магнитная подушечка, происходит соединение металических контактов и по ним начинает течь 220 вольт. Наш умный кофе поступает в тупой стакан.
В итоге, абсолютно все задачи по проектированию архитектуры IT-систем сводятся к 3-м вопросам:
1. Как мы будем передавать данные?
2. Как мы будем их трансформировать?
3. И как мы будем их хранить?
Вы просто снова и снова задаете себе эти вопросы и ищите ответы. В разрезе всех участвующих систем: интерфейсов, серверов, сетей, устройств, etc.
Хороший проектировщик / архитектор не только знает как построить все эти цепочки, но знает как это сделать максимально оптимизировано и чтобы при этом на разработку не ушли годы.
P.S.
Я – бездарь и неучь и уверен, что эти мысли были сформулированы задолго до меня, поэтому предлагаю вам поправить меня, если вы не согласны с какой-либо из формулировок. Поскольку только вместе мы – сила 💪
2021-02-22 12:36
🦍 Эволюция разработчика v1.3 "Вкусные ветки развития" 👨💻
В прошлых постах мы поговорили про рост в качестве и про сторонние ветки развития.
А сейчас я добью последние 3 ветки развития разработчика.
Вот эти ветки очень крутые и вполне доступные любому разработчику от Middle+ за 2-3 месяца.
! Дисклеймер ! В ближайшие 2 недели я устрою серию вебинаров, в которых буду разбирать все плюсы и минусы каждой позиции, как до них расти, какие перспективы заработка и что нужно для трудоустройства. Следите за новостями в канале.
1. Бизнес Системный Аналитик (БСА) – об этой роли не так много говорят, но она невероятно интересная.
Условно это локальный бизнес Архитектор. Его задача – полностью изучить бизнес-процесс и потребность пользователей, а после спроектировать систему и передать ее разработке (Team Lead, например), которая сформулирует уже конкретные спринты.
Вы уже не будете заниматься кодом, ваша основная задача будет анализировать огромные объемы информации и придумывать самые оптимальные способы решения, создавая документацию и схемы. Но по-прежнему потребуется много технологических скиллов в архитектуре и проектировании, поскольку все ваши решения должны будут лечь в основы кода множества сервисов.
Вакансий достаточно много и они высокооплачиваемые.
2. Data Engineer – мало кто знает про эту роль, но ее основная задача: спроектировать и реализовать потоки данных и их трансформации до целевых систем.
Чаще всего, это работа с созданием хранилища источника данных, валидации и чистки, подготовке к решению бизнес задач (через BI визуализацию и Data аналитику).
Вы будете писать код выгрузки из источников, трансформации и визуализации данных (ETL). Эти задачи требуют хорошего знания бизнеса, работы со структурами данных и базами, но при этом не особо много от дата саенс или аналитики.
Рынок среднего размера и платят хорошо.
3. Продуктовый инженер (Product Engineer) – а вот это самое интересное и новое. Тренд, который я подметил на начало 2021-го года, который скоро станет "де-факто".
Это не совсем "специализация", это скорее роль / подход к мышлению, когда вы ставите перед разработкой задачу не "разработать менюшку", а "сделать более эффективный способ пользователю работать с системой".
Продуктовый инженер знает чего хотят пользователи и ставит себе задачи по удовлетворению этих потребностей через разработку фич.
Это нечто среднее между PO, БСА и Team Lead.
Рассказывать об этой роли я могу долго, поэтому готовьтесь к серии статей, в которых я буду раскрывать особенности его работы.
---
Если вам понравилось, то ставьте 🔥 секси-эмоджи 🚀 в комментарии, пишите о чем вам больше хотелось бы услышать и ждите вебинаров 😘
В прошлых постах мы поговорили про рост в качестве и про сторонние ветки развития.
А сейчас я добью последние 3 ветки развития разработчика.
Вот эти ветки очень крутые и вполне доступные любому разработчику от Middle+ за 2-3 месяца.
! Дисклеймер ! В ближайшие 2 недели я устрою серию вебинаров, в которых буду разбирать все плюсы и минусы каждой позиции, как до них расти, какие перспективы заработка и что нужно для трудоустройства. Следите за новостями в канале.
1. Бизнес Системный Аналитик (БСА) – об этой роли не так много говорят, но она невероятно интересная.
Условно это локальный бизнес Архитектор. Его задача – полностью изучить бизнес-процесс и потребность пользователей, а после спроектировать систему и передать ее разработке (Team Lead, например), которая сформулирует уже конкретные спринты.
Вы уже не будете заниматься кодом, ваша основная задача будет анализировать огромные объемы информации и придумывать самые оптимальные способы решения, создавая документацию и схемы. Но по-прежнему потребуется много технологических скиллов в архитектуре и проектировании, поскольку все ваши решения должны будут лечь в основы кода множества сервисов.
Вакансий достаточно много и они высокооплачиваемые.
2. Data Engineer – мало кто знает про эту роль, но ее основная задача: спроектировать и реализовать потоки данных и их трансформации до целевых систем.
Чаще всего, это работа с созданием хранилища источника данных, валидации и чистки, подготовке к решению бизнес задач (через BI визуализацию и Data аналитику).
Вы будете писать код выгрузки из источников, трансформации и визуализации данных (ETL). Эти задачи требуют хорошего знания бизнеса, работы со структурами данных и базами, но при этом не особо много от дата саенс или аналитики.
Рынок среднего размера и платят хорошо.
3. Продуктовый инженер (Product Engineer) – а вот это самое интересное и новое. Тренд, который я подметил на начало 2021-го года, который скоро станет "де-факто".
Это не совсем "специализация", это скорее роль / подход к мышлению, когда вы ставите перед разработкой задачу не "разработать менюшку", а "сделать более эффективный способ пользователю работать с системой".
Продуктовый инженер знает чего хотят пользователи и ставит себе задачи по удовлетворению этих потребностей через разработку фич.
Это нечто среднее между PO, БСА и Team Lead.
Рассказывать об этой роли я могу долго, поэтому готовьтесь к серии статей, в которых я буду раскрывать особенности его работы.
---
Если вам понравилось, то ставьте 🔥 секси-эмоджи 🚀 в комментарии, пишите о чем вам больше хотелось бы услышать и ждите вебинаров 😘
2021-02-19 16:02
2021-02-17 12:01
🇵🇳Никто не знает английский и что с этим делать 🇲🇸
Чем больше я работаю с иностранными коллегами, тем больше убеждаюсь в том, о чем ни в школе, ни в институте, ни на курсах практически не говорят:
Основная проблема – это не "знание как правильно что-то написать/сказать", а "как понять, когда собеседник ошибается"
Так вот: абсолютно все люди, всегда ошибаются
Ошибаются не только грамматически, но и лексически, и ОСОБЕННО СЛОЖНО УЛОВИМЫЙ БАГ это когда они ошибаются логически
Ну вы же сами знаете, когда у вас путаются мысли и вы пишите не: "мы письмо заказчику отправили на рассмотрение" – а: "я – толостожопый говноклюв" – ну и всех же бывало, правда? правда?... сранный Т9... но не важно, я к тому, что мы часто даже на своем языке ошибаемся из-за усталости, перенапряжения, а иногда просто потому что решаем написать "хоть как-то" в надежде, что нас поймут
Вот тоже самое происходит и с людьми, которые общаются с вами на английском
Особенно часто это происходит с нэйтив спикерами, потому что они привыкли писать на отъебись, ведь их же сограждане понимают, значит и вы поймете
И вот ты сидишь, читаешь ересь, которую тебе прислал твой зарубежный коллега и думаешь: "Я что, реально настолько не понимаю английский? Какой 'говноклюв'? Ну, он же знает английский, значит, это я не понимаю что здесь написано..." – и вот с этой уверенностью, что на той стороне все сделали правильно, вы начинаете копаться в том, что никогда правильным и не было
Это проблема лечиться очень просто:
Если вы не можете понять, что написал вам собеседник или у вас закралась толика сомнения о правильности написанного, ВСЕГДА переспрашиваете, что человек имел ввиду
Любой специалист, который работает с зарубежными коллегами более 1 года уже привык разъяснять свои мысли и искать альтернативные способы донести информацию – это норма международной переписки
Короче, иногда нужно понимать, что не вы дебил (даже, если вы дебил), а ваш собеседник, потому что все бывают дебилами
Чем больше я работаю с иностранными коллегами, тем больше убеждаюсь в том, о чем ни в школе, ни в институте, ни на курсах практически не говорят:
Основная проблема – это не "знание как правильно что-то написать/сказать", а "как понять, когда собеседник ошибается"
Так вот: абсолютно все люди, всегда ошибаются
Ошибаются не только грамматически, но и лексически, и ОСОБЕННО СЛОЖНО УЛОВИМЫЙ БАГ это когда они ошибаются логически
Ну вы же сами знаете, когда у вас путаются мысли и вы пишите не: "мы письмо заказчику отправили на рассмотрение" – а: "я – толостожопый говноклюв" – ну и всех же бывало, правда? правда?... сранный Т9... но не важно, я к тому, что мы часто даже на своем языке ошибаемся из-за усталости, перенапряжения, а иногда просто потому что решаем написать "хоть как-то" в надежде, что нас поймут
Вот тоже самое происходит и с людьми, которые общаются с вами на английском
Особенно часто это происходит с нэйтив спикерами, потому что они привыкли писать на отъебись, ведь их же сограждане понимают, значит и вы поймете
И вот ты сидишь, читаешь ересь, которую тебе прислал твой зарубежный коллега и думаешь: "Я что, реально настолько не понимаю английский? Какой 'говноклюв'? Ну, он же знает английский, значит, это я не понимаю что здесь написано..." – и вот с этой уверенностью, что на той стороне все сделали правильно, вы начинаете копаться в том, что никогда правильным и не было
Это проблема лечиться очень просто:
Если вы не можете понять, что написал вам собеседник или у вас закралась толика сомнения о правильности написанного, ВСЕГДА переспрашиваете, что человек имел ввиду
Любой специалист, который работает с зарубежными коллегами более 1 года уже привык разъяснять свои мысли и искать альтернативные способы донести информацию – это норма международной переписки
Короче, иногда нужно понимать, что не вы дебил (даже, если вы дебил), а ваш собеседник, потому что все бывают дебилами