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

Старайтесь не защищаться. Объяснение практических технологий, таких как JSON, — это то, что мы ожидаем, что иногда придется делать даже выпускникам университетов. Кто-то с лучшими социальными навыками сначала спросит, знакомы ли вы с этим. Если они не спрашивают, не стесняйтесь просто прервать и сказать им.

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

Эй, коллега, давайте опустим тривиальные детали и перейдем к сути проблемы. Это не очень эффективное использование нашего времени.

У него может быть просто склонность слишком много объяснять или отходить от темы, но хороший навык, который нужно развивать каждый раз, когда вы взаимодействуете с другими разработчиками, — это вежливо, но твердо поддерживать краткость и тему общения, чтобы время каждого было потрачено эффективно.

Когда вы работаете в области компьютерных технологий, вы можете встретить много людей, не обладающих хорошими социальными навыками. Не делайте поспешных выводов. Кроме того, люди из разных уголков мира или внутри одной страны могут по-разному воспринимать определенные виды поведения. В США люди из маленьких городов часто считают жителей больших городов шумными и агрессивными. Они могут говорить громче по привычке, а не потому, что пытаются быть агрессивными.

Вы можете быть удивлены, обнаружив, что этот человек не видит того, что он делает, так же, как вы. Она может просто болтать и не думать, что вы вообще ничего не понимаете. Если бы она начала эти объяснения с чего-то вроде: «Ну, если бы вы когда-нибудь посещали урок по вводному программированию X, вы бы знали…»

Не похоже, чтобы вы разговаривали с этим человеком. Нет ничего плохого в том, что вы упомянули, что вы тоже этому научились. Возможно, вы захотите сказать: «Я научился этому, а где вы это узнали?» Ваш тон голоса покажет, обороняетесь ли вы или не можете принять критику. Остерегайтесь, некоторые люди не всегда улавливают эти тонкости.

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

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

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

По моему опыту, это было самым сложным в обучении CS. Мне нужно было не только глубоко понять материал, но и использовать несколько мозговых циклов, пытаясь проникнуть в головы моих студентов и понять, о чем они думают. Но не все практикуют это в непринужденной беседе.

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

Это похоже на другие ответы, но с несколькими конкретными примерами.

Если вы просите о помощи / вы двое обсуждаете поставленную задачу

Когда я на другом конце этого. Действительно трудно понять, какими фоновыми знаниями обладает человек, когда что-то объясняет.

Недостаточное объяснение и чрезмерное объяснение — это плохо. Решение состоит в том, чтобы сообщать о том, что вы знаете/не знаете, эффективно и быстро.

В вашем примере, прежде чем она слишком углубится в объяснение JSON, прервите ( вежливо ), чтобы она могла отметить это в своем «списке вещей, которые нужно объяснить».

О, я понял, что такое JSON. Чего я не знаю, так это как десериализовать его в объект на С#. Как ты это делаешь?

Или в обсуждении. Например, если кто-то предложил использовать JSON в качестве формата, и у вас есть проблемы. Вы все равно будете перебивать, потому что хотите быстро перейти к нужной части разговора.

Я знаком с JSON. Я думаю, что XML может быть лучшим выбором, поскольку наши вышестоящие службы уже ожидают его в XML.

Если вас ругают за то, что вы чего-то не делаете. Затем вы следуете той же схеме.

Она: Ты мог бы использовать Х. Х - это...

Вы (перебивая): Да, я знаком с X. Я использовал Y, потому что у X есть недостаток. Я тоже рассматривал вариант Z, но тоже отказался.

Она: А как насчет А, который...

Вы (перебивая): Ах, да, я тоже думал об А. Но это не сработало по ПРИЧИНАМ.

Она: Если вы соедините А с Я, вы сможете решить ПРИЧИНЫ.

Вы: Да, это может сработать. Я посмотрю на это.

Я обычно добавляю префикс «Да» как более приятную короткую форму «Да, я знаю об этом», и это снимает остроту.

Пока в целом вы сохраняете нейтральный тон, вы не окажетесь не прислушиваясь к критике.

Кроме того, однажды вы ошибетесь. Просто убедитесь, что вы так же открыты и честны.

Если вы общаетесь в целом

Теперь мы подошли к этикету вежливой беседы. Не совсем моя сильная сторона, но вот как бы я с этим справился.

Во многих случаях я просто киваю и жду, пока они закончат. После чего я скажу что-то вроде «А, да, я знаком с JSON». Я использовал в X.'. И просто продолжайте разговор.

Если у меня есть какое-то место, чтобы быть, нет выбора, я должен прервать. Что сложнее в обычном разговоре. Но в основном я просто говорю «Да» и киваю, пока они говорят. И как только они делают хоть маленькую паузу, я говорю строчку из предыдущего абзаца.

Предостережение

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

Отказ от ответственности: я не разработчик программного обеспечения

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

В дополнение к превосходным ответам @Link0352 и @JeffO, где это возможно, я бы порекомендовал просто осторожно перевести разговор обратно на тот уровень, на котором он должен быть для продуктивного обсуждения.

Конечно, мы можем манипулировать JSON, но это может привести к проблеме X. В этом случае я бы рекомендовал манипулировать объектом напрямую (или как-то так).

(Я предполагаю, что это взаимодействие произошло во время технического совещания, и коллега не просто подошел к вашему кубу и начал болтать о JSON. Если это так, мой ответ на самом деле не применим.)

В дополнение к другим ответам, мое общее решение для людей, объясняющих вам очевидные вещи:

Когда они закончатся, поверните стол . Начните объяснять более глубокие знания по недавней теме или объясните другую очень очевидную, например

другой человек : Json отлично подходит для... и вы можете сделать...
вы (улыбается/дружелюбно): Точно! Что мне также нравится в Json, так это то, что вы можете ....

или если вы хотите быть немного злым

другой человек : Json отлично подходит для... и вы можете сделать...
вы (улыбается/дружелюбно): Точно! Вы когда-нибудь слышали о XML? Это [объяснение чего-то очень очевидного]

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

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

Эти объяснения могут быть, а могут и не быть, что эти объяснения являются признаком неуважения или обиды (или попыткой доказать вам свои знания), но их можно превратить в возможность найти общий язык и поделиться взглядами, чтобы наладить рабочие отношения. лучше.

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

«JSON — это формат для представления структур данных в виде текста».

«О, JSON, я только что читал о различных реализациях, вы не знаете, есть ли эталонный пример синтаксического анализатора, созданного с помощью JSON lexи yaccдля него?»

От другого женского разработчика

Я разработчик с университетским образованием и уже некоторое время работаю. Должен сказать, что у меня нет ничего, кроме восхищения разработчиками-самоучками. Честно говоря, есть так много вещей, которые я изо всех сил пытался выучить, что я просто не могу поверить, что вы, ребята, действительно смогли научиться сами. И я люблю дискутировать с теми, кто самоучка, потому что у них обычно совсем другой набор навыков, чем у студенческой аудитории. Это вдохновляет и довольно круто.

А что касается дамы, которая начала объяснять вам JSON, не придавайте этому большого значения. У нас это часто случается. Мужчины, которые действуют из лучших побуждений, но в конечном итоге объясняют обыденные вещи, потому что мы девушки, и мы настолько необычны в этой области, что они чувствуют, что должны помогать нам немного больше, даже если иногда это становится немного оскорбительным. Мне повезло, что меня на работе встречали только с уважением, но я слышал несколько страшных историй.

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

Открой свой разум.

Университет действительно учит навыкам, которых вы не найдете в книгах (за исключением университетских учебников) и которых вам, вероятно, не хватает, если вы самоучка. Откуда я знаю? Я учился, но некоторые области не входили в мою учебную программу, и я самоучка в этих областях. Так что я знаю обе стороны.

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

In dubio pro reo, так что, пока не доказано обратное, предполагайте лучшее и непредвзято приветствуйте ее обсуждения. Однако, как только вы поймете, что уже знаете, что она пытается объяснить, поблагодарите ее и объясните, что вы уже это понимаете. Спросите ее, что еще она может предложить, вы стремитесь постоянно учиться и совершенствоваться. В этом преимущество самоучки: вы понимаете, что обучение — это постоянный процесс, который не заканчивается сдачей экзамена или магистерской диссертацией.

Используйте это преимущество. Учитесь у нее, это может быть только вам на пользу.

И однажды будет что-то, что ты знаешь, а она нет. Научите ее дружелюбно, не снисходительно, и у вас двоих могут быть блестящие, взаимовыгодные рабочие отношения.

Я видел это много раз в качестве консультанта на протяжении многих лет. Ответ прост. Это механизм преодоления.

Это один из двух комплексов и может быть комбинацией обоих.

• Комплекс неполноценности

  Комплекс неполноценности — это недостаток самооценки, сомнения и неуверенность в себе, а также чувство несоответствия стандартам. Часто это происходит подсознательно и, как считается, побуждает страдающих людей к сверхкомпенсации, что приводит либо к впечатляющим достижениям, либо к крайне асоциальному поведению.

• Комплекс превосходства

  Комплекс превосходства – это психологический защитный механизм, компенсирующий комплекс неполноценности.

Оба являются защитным механизмом.

Если вы являетесь единственной мишенью такого поведения, то субъекту, скорее всего, угрожают ваши навыки или способности.

Если вы являетесь одной из нескольких целей такого поведения, то это общее чувство неполноценности внутри обидчика.

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

Хотя вы можете не захотеть нападать на кого-то за такое оскорбление, такое поведение может представлять опасность для вас и других людей, особенно на работе.

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

В этом случае создается впечатление, что преступник взял на себя роль Родителя. Подойдет только ответ Взрослого. Ответ родителя или ребенка означает, что вы проиграли. В этом можно убедиться, прочитав « Я в порядке», «Ты в порядке» и «Игры, в которые играют люди» . Оба основаны на трансактном анализе. Не помешало бы прочитать первую книгу. Его относительно просто понять, и он учит вас распознавать три состояния и реагировать на них.

Проще говоря, это игровое мастерство.

Я не хочу предлагать предложения о том, как конкретно бороться с этим устно, поскольку совет потенциально может быть вредным. С этим нужно бороться в данный момент.

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

Меня часто вызывали для решения проблемы или замены системы, за которую кто-то отвечал. Часто сила отнималась у человека, который теперь защищался. Сражения, подобные этим, часто связаны с властью, либо с ее потерей, либо с приобретением власти. Цель состоит в том, чтобы свести к минимуму угрозу, минимизировав потери. Например, в глобальной компании Microsoft Mail устарела, и ее нужно было заменить. Ответственный сотрудник крепко держал бразды правления и управлял всеми серверами, требуя, чтобы они находились в одном месте. Для глобальной телекоммуникационной компании это было катастрофой. Людям в Японии придется подключаться к серверам в Вирджинии, чтобы читать электронную почту. Бремя было огромным, и электронная почта не доставлялась в течение 24 часов. Сотрудник боялся технологии, которую он не понимал или не знал, и беспокоился о своей работе с распределенной глобальной системой. Решение заключалось в том, чтобы провести с сотрудником обучение, тестовую установку, поддержку удаленных систем и дать ему понять, что он по-прежнему играет ключевую роль в организации. Он не терял власть, а набирал силу. Все это через ТА.

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

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

Вместо этого я рекомендую немного социальной инженерии, которую часто практиковал Бенджамин Франклин, также известный как Эффект Бенджамина Франклина :

Просите помощи, совета, предложений. Просьба об одолжении является признаком близости и доверия.

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

Это быстрое неконфронтационное решение, которое сработает в большинстве случаев.

Поговорите с ней об этом.

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

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

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

Эй, Сью, я знаю, что мы не очень долго работаем вместе и все еще учимся тому, чего ожидать друг от друга. Я заметил, что когда мы говорим о работе, вы часто впадаете в довольно простые объяснения того, что я считаю стандартными темами.
Почему это?
Я надеюсь, что это из-за X или Y (дайте одну или две более щедрые интерпретации из других), но часто кажется, что я произвел на вас впечатление, что мне нужно объяснить эти вещи. Если это так, то кажется, что мы теряем драгоценное время, которое можно было бы использовать более продуктивно, обсуждая необходимые функции. Если вы не уверены в моем опыте работы с темой, вы можете спросить, что я знаю об этом, и если обсуждение затрагивает что-то, выходящее за рамки моего опыта, поверьте, я спрошу.

Сначала я бы не стал прерывать ее, пока она давала одно из своих объяснений, чтобы обсудить это, потому что это, скорее всего, будет воспринято как реакция или оборона. Лучше подойти к ней отдельно.

Двигаясь дальше, в зависимости от того, что выйдет из первоначального обсуждения, когда и если это произойдет снова, вы можете вставить, что это одно из этих основных объяснений, или начать применять некоторые из предложений других о том, как реагировать в режиме реального времени.

Как в сторону:

В прошлогоднем проекте мне пришлось объяснять паре членов команды, что такое JSON. Они оба имеют как минимум десять (или два) опыта работы в отрасли, и в разные периоды своей карьеры оба работали над веб-проектами. Они просто никогда не работали с какими-либо фреймворками или нужными техниками там, где это было особенно актуально.

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

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

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

По моему опыту, невысказанные предположения могут (и в конечном итоге станут) очень дорогими. Несколько минут, потраченных на то, чтобы убедиться, что все находятся на одной странице, прежде чем начинать какое-либо обсуждение, сэкономят много денег в долгосрочной перспективе.

В этом случае ваше предположение, что она делает это, потому что вы самоучка, и/или (если ваше предположение верно) ее предположение, что вам нужны инструкции, наносит ущерб вашим рабочим отношениям.

IT — это очень широкая сфера.

Предполагать, что кто -то должен знать JSON только потому, что у него в общей сложности 4 года опыта (или 40), было бы довольно глупо со стороны вашего коллеги. Вы могли разрабатывать приложения, не использующие JSON, или фреймворки, скрывающие детали JSON.

Что еще хуже, вы могли просто частично научиться использовать JSON (например, модифицировав работу кого-то, кто был недостаточно внимателен); назначение вам задач JSON без уверенности в том, что вы знаете, как JSON используется в вашей организации, может привести к некачественному продукту. Например, может быть, ваш код должен работать не только на успех, но и показывать соответствующее сообщение в случае ошибки.

Учитывая, что вы новичок в своей должности, одним из способов вашего коллеги убедиться в том, что работа выполнена должным образом, является проверка ваших знаний. Описанный выше метод является одним из доступных. В качестве альтернативы она может задать вам вопрос или подождать, пока ваша задача не будет завершена, и просмотреть код. Я не знаю, предпочтете ли вы какой-либо из них. Конечно, просто позволять вам быть рискованным (для вас, для нее и для бизнеса), пока она не будет уверена, что вы готовы к работе.

Обратите внимание, что ничто из вышеперечисленного не связано с отсутствием у вас академического сертификата.

И пункт «прошел техническое собеседование» не освобождает от прохождения экзамена. Техническое собеседование дает лишь очень поверхностную оценку вашей компетентности; он говорит о том, что вы можете писать работающий код, но не о том, что вы можете написать хороший код.

Есть много аспектов, которые важны, но не могут быть легко изучены:

• Способность понимать проблемы.

• Умение читать чужой код.

• Умение использовать правильную архитектуру.

• Пишите хороший структурированный код.

• Защитное программирование.

• Передовая практика использования инструментов (контроль версий, автоматизированное тестирование).

А что касается вопроса «степень против самоучки», примите, что отсутствие степени означает, что ваш собеседник может делать меньше предположений о том, что вы знаете или чего не знаете ¹ . Особенно в отношении объясненных выше моментов (многие самоучки просто даже не знают о существовании этих факторов и просто идут к «я хочу сделать программу, которая делает Х» ² )

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

TL/DR Дайте этому программисту немного времени, чтобы он мог самостоятельно проверить ваши возможности.

² Прямо сейчас я модифицирую программу, сделанную

³ На самом деле в этом и заключается полезность степеней.

Разработчик с дипломом и без должен одинаково уважаться на рабочем месте.

Я прочитал все ответы выше, и большинство из них указывают на то, что она добра, а вы слишком об этом думаете.

Но судя по вашему вопросу, это не так. Казалось, ты чувствуешь себя оскорбленным ее поведением.

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

Для демонстрации без хвастовства начните помогать своим товарищам, младшим и т. д. Ваша работа, набор навыков и все остальное будут говорить сами за себя.

Это немного сложнее, чем кажется в некоторых ответах. Вы не должны просто выйти и сказать, что вам не нужна помощь (высокомерие), и не должны молча продолжать слушать (это раздражает!).

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

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

Чтобы полностью прекратить техническое приставание, покажите, что вы знаете БОЛЬШЕ, чем человек, пытающийся вас научить, и он быстро научится не читать вам нотации и, если что, приходить к вам с вопросами.

Теперь, если они объясняют вам JSON, потому что вы допустили критическую ошибку или только что продемонстрировали упущенную архитектурную концепцию, тогда вы должны заткнуться и слушать.

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

Предупреждение: это работает только с некоторыми людьми в определенных ситуациях; YMMV. Этот ответ не имеет гарантии.

Что бы я* сделал в этом случае, так это прервал бы их кратким изложением темы. Например, с JSON:

Они: JSON — это нотация объектов JavaScript, которая представляет собой способ представления —
Я: Подобные словарю объекты и, хм, массивы и примитивы, я имею в виду примитивы JavaScript, в сериализованном формате.

Это объясняет следующую ситуацию:

Они: JSON — это нотация объектов JavaScript, способ представления —
Я: Любой объект в JavaScript в виде строки.
Они: Нет, потому что он не может хранить функции или объекты со скрытыми свойствами; это очень простое представление...

Прерывание их с помощью «да, я знаю» в этом случае привело бы к проблемам позже, когда выяснилось, что я на самом деле не знаю, что такое JSON, что вызвало проблемы в коде с моими предположениями.

Ваш коллега, вероятно, просто пытается убедиться, что вы знаете все, что вам нужно. Если вы «самоучка», то это означает, что у вас могут быть пробелы, которые, по мнению большинства людей, вы заполнили, поскольку вы знаете «более сложные вещи» (хотя большинство учебных заведений преподают такие вещи в действительно странном порядке!) и тому подобное . предположения могут привести к тонким, трудно обнаруживаемым проблемам из-за ложных предположений.

*: см. начало ответа.

Я думаю, вы могли бы сказать - я уже немного знаю (акцент на немного) немного о JSON. Итак, можем ли мы пока пропустить JSON? Но если я чего-то не знаю о JSON, могу ли я попросить вас о помощи позже?

Вы не упомянули отрасль, которая будет иметь большое значение.

Я работаю в крупной высокотехнологичной компании и часто нанимаю молодых разработчиков (0-2 года опыта). Школа, которую они посещали, и их степень не имеют для меня ни малейшего значения.

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

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

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

Разработчики-самоучки часто являются экспертами в технологиях, в которых у них есть практический опыт, но иногда проблема заключается в том, что они не знают, как много они не знают. Например, я часто сталкивался с разработчиками-самоучками, изобретающими новый алгоритм для решения проблемы, когда есть хорошо известный стандартный алгоритм, который часто намного лучше.

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

Между прочим, степень CS не многому вас научит о JSON. Тем не менее, он научит вас тому, к какому классу грамматики относится JSON и, следовательно, к какому классу синтаксического анализатора вам нужно его обработать: он научит вас избегать ошибки, пытаясь анализировать JSON с помощью регулярных выражений, потому что теория говорит вам это невозможно сделать. Вам нужно всего несколько недель следить за StackOverflow, чтобы увидеть, сколько программистов не знают таких основ.

Давайте просто скажем вашему примеру, что вы не манипулируете JSON. Вы берете JSON, конвертируете его в объект модели, манипулируете объектом модели и конвертируете его обратно в JSON. Могу поспорить, что если ваш коллега попытается манипулировать JSON напрямую, будут ошибки, потому что JSON прост, но не настолько .

Теперь, если он такой умный, распечатайте копию этой статьи https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf , в которой рассказывается о вычислении оптимальных кодов Хаффмана с ограниченной длиной кода (коды Хаффмана с неограниченной длиной кода). длина кода проста) и попросите его объяснить вам этот алгоритм. Скорее всего, он не сможет этого сделать, в худшем случае вы заткнете его надолго. (Ограниченные по длине коды Хаффмана важны, потому что они позволяют использовать гораздо более эффективные декодеры). PS. Если он или она может объяснить вам алгоритм, то он или она хороши . Я сомневаюсь в этом.

Кроме того, если кто-то пытается объяснить вам JSON, вы спрашиваете его, чего он там добивается? Он думает, что JSON — это что-то сложное, что вы не можете понять без степени CS? Серьезно? Не кажется ли ему, что он немного самодовольен? Его поведение оскорбительно, поэтому вы отплатите ему тем, что он заслуживает.