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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вас взяли на работу за то, что вы чего-то не делаете. Тогда вы следуете тому же шаблону.

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

You (прерывающий): Да, я знаком с X. Я использовал Y, потому что у X есть обратная сторона. Я также рассматривал Z, но также решил против этого.

Her: А как насчет A, которая является -

You (прерывающий): Что насчет A, которая является -

You (прерывающий): Да, я использовал Y, потому что у X есть этот недостаток: А, да, я тоже подумал об А. Но это не сработало из-за REASONS.

Her: Если вы объедините A с Z, вы сможете решить REASONS.

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

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

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

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

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

Теперь мы в области вежливого этикета разговора. Не совсем моя сильная сторона, но вот как я с этим справлюсь.

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

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

Caveat

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

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

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

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

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

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

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

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

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

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

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

От другой женщины dev

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

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

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

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

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

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

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

“JSON - это формат для представления структур данных в виде текста”

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

Университет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом случае, кажется, что преступник взял на себя роль Родителя. Сделает это только взрослый ответ. Реакция Родителя или Ребенка означает, что Вы проиграли. Это можно увидеть, прочитав I’m OK, You’re OK . Оба основаны на транзакционном анализе. Это поможет прочитать первую книгу. Она относительно проста для понимания и учит распознавать три состояния и как на них реагировать.

Проще говоря, это игровое человечество.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отсутствует:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• *

То, что я would* делаю в этом случае, прерывает их с резюме темы. Например, с помощью JSON:

Them: JSON - это Нотация объектов JavaScript, которая представляет - Me: Словарные объекты и, эм, массивы и примитивы, и, я имею в виду, примитивы JavaScript, в сериализованном формате.

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

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

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

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

• *

*: смотрите верхнюю часть ответа.

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

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

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

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

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

Скажем так, на вашем примере, что вы don’t manipulate JSON. Вы берете JSON, конвертируете его в объект модели, манипулируете объектом модели и конвертируете его обратно в JSON. Готов поспорить, что если ваш коллега попытается манипулировать JSON напрямую, то будут ошибки, потому что JSON прост, а не that.

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

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

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

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

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