Para sua informação, a maioria das universidades não ensina sobre coisas como o JSON. Ensinam coisas como a travessia da árvore da primeira profundidade que teoricamente poderia ser aplicada na criação da sua própria biblioteca JSON, mas qualquer coisa mais prática do que isso mais todos é autodidacta ou aprendida no trabalho.

Tente não ficar na defensiva. Explicar tecnologias práticas como o JSON é algo que esperamos ter de fazer ocasionalmente, mesmo para os licenciados universitários. Alguém com melhores habilidades sociais perguntaria se você está familiarizado com isso primeiro. Se não perguntar, sinta-se à vontade para simplesmente interromper e dizer-lhes.

Não há razão para não poder indicar que o seu colega está a fornecer informações supérfluas durante as discussões técnicas.

Hey Coworker, vamos saltar os detalhes triviais e ir ao âmago da questão. Esta não é uma utilização muito eficaz do nosso tempo.

Ela pode ter apenas uma tendência para explicar demasiado as coisas ou sair do tópico, mas uma boa habilidade para desenvolver qualquer tempo que esteja a interagir com outros programadores é manter as interacções de forma educada mas firme, sucinta e no tópico para que o tempo de todos esteja a ser gasto eficientemente.

Para ser justo, tenho boas credenciais e um ex-supervisor esteve sempre a fazer-me isto. Tive uma aula de CS aprofundada sobre design de bases de dados, tinha construído todo o tipo de aplicações orientadas para bases de dados, e tinha trabalhado profissionalmente durante anos, e ele ainda tinha a ousadia de me explicar (à frente de todos os outros) os princípios de design de bases de dados para principiantes.

Mas não tenho a certeza se ele o estava a fazer de propósito. A verdade é que é preciso muita energia mental para se colocar no lugar de outra pessoa e falar ao seu nível. Você vê isso o tempo todo: os especialistas por vezes atiram-lhe calão sem sentido, ou outros falam-lhe mal. Mas não significam necessariamente isso - eles simplesmente não estão a gastar energia suficiente para descobrir como comunicar bem.

Na minha experiência, isso foi a coisa mais difícil de ensinar CS. Não só tive de compreender o material em profundidade, como tive de usar alguns ciclos cerebrais para tentar entrar na cabeça dos meus alunos e perceber o que eles estavam a pensar. Mas nem todos praticam isso numa conversa casual.

Por isso, não seja demasiado rápido a falar maliciosamente. Pode muito bem ser apenas a sua própria inépcia social. Eu diria como não levar isso a peito, mas eu próprio ainda estou a trabalhar nisso. Pessoalmente também não o suporto…

Isto é semelhante a outras respostas, mas com alguns exemplos concretos.

** Se está a pedir ajuda / vocês dois estão a discutir a tarefa em mãos**

Quando estou do outro lado disto. É realmente difícil saber que conhecimento de fundo alguém tem quando explica algo.

Explicar por baixo e explicar por cima são ambos maus. A solução é comunicar o que se faz/não se sabe de forma eficaz e rápida.

No seu exemplo antes de mergulhar demasiado fundo na explicação do JSON, interromper (politely) para que ela possa riscar isso da sua ‘lista de coisas a explicar’.

Oh eu tenho o que é o JSON. O que eu não sei é como deserializá-lo para um objeto em C#. Como fazer isso?

Ou na discussão. Como dizer se alguém se propôs a usar o JSON como formato e você tem preocupações. Você ainda interromperia porque quer chegar à parte relevante da conversa rapidamente.

Estou familiarizado com o JSON. Penso que o XML pode ser uma escolha melhor uma vez que os nossos serviços a montante já o esperam em XML.

Se está a ser levado à tarefa por não fazer nada. Então segue o mesmo padrão.

Ela: Você poderia ter usado X. X é um -

Você (interrompendo): Sim, estou familiarizado com X. Eu usei Y porque X tem este lado negativo. Também considerei Z mas decidi contra ele também.

Ela: E que tal A que é um -

Você (a interromper): Ah sim, eu também considerei A. Mas não funcionou por causa de REASONS.

Ela: Se combinar A com Z pode resolver REASONS.

Você: Sim, isso pode funcionar. Eu vou ver isso.

Eu normalmente prefiro com ‘Yea’ como uma forma curta mais agradável de ‘Yes I’m aware of that’ (Sim, eu estou ciente disso) e isso tira a vantagem.

Enquanto em geral, você mantiver um tom neutro, você não vai sair como não ouvir críticas.

Também, você vai estar errado algum dia. Certifique-se apenas de que quando estiver, é igualmente aberto e honesto.

** Se estiver a conversar em geral**

Agora estamos na área da etiqueta da conversa educada. Não é exactamente o meu forte, mas eis como lidaria com isso.

Em muitos casos, eu apenas aceno com a cabeça e espero até que acabem. Depois disso vou dizer algo como “Ah sim, estou familiarizado com o JSON”. Já usei no X.‘. E basta continuar a conversa.

Se eu tiver algum lugar para estar, não há escolha, tenho de interromper. O que é mais difícil numa conversa normal. Mas basicamente só digo “Sim” e aceno com a cabeça enquanto eles falam. E assim que eles fazem uma pequena pausa, digo a frase do parágrafo anterior.

Caveat

Com tudo o que acabei de dizer, eu cavei: Às vezes é bom ouvir de qualquer forma, pois pode pegar em algo que não sabia. Na verdade, muitas vezes procuro explicar conceitos a pessoas como se não soubesse nada sobre eles.

Aviso: Eu não sou desenvolvedor de software

Recomendo que evitem assumir que ela está a ser condescendente intencionalmente. Pode muito bem ser que ela pense que a sua falta de educação superior significa que não tem conhecimentos de conceitos básicos de programação, mas não tem provas disso, por isso é melhor não pensar nisso. Explico frequentemente conceitos básicos em reuniões de planeamento, porque me ajuda a envolver a cabeça em certos problemas e assegura que todos seguem o meu processo de pensamento, não porque pense que as outras pessoas na sala são idiotas.

Para além das excelentes respostas de @Link0352 e @JeffO, sempre que possível, recomendaria apenas que a conversa voltasse suavemente para o nível em que precisa de estar para uma discussão produtiva.

Claro, poderíamos manipular o JSON, mas isto poderia levar ao problema X. Neste caso, eu recomendaria manipular o objecto directamente (ou o que quer que seja).

(presumo que esta interacção ocorreu durante uma reunião técnica e o colega de trabalho não se limitou a vaguear até ao cubo e começar a falar do JSON. Se for esse o caso, a minha resposta não se aplica realmente).

Para além de outras respostas, a minha solução genérica para pessoas que lhe explicam coisas óbvias:

Quando estiverem prontas, vire a mesa*. Comece a explicar um conhecimento mais profundo sobre o tema recente ou explique outro muito óbvio, por exemplo,

outra pessoa* : Json é um óptimo para … e você pode fazer … you* (sorridente/amigável): Exactamente! O que eu também gosto na Json é que você pode ….

ou se você quiser ser um pouco mau

** outra pessoa*** : Json é um óptimo para … e você pode fazer … you* (sorridente/amigável): Exactamente! Já ouviu falar em XML? É uma [explicação de algo muito óbvio].

De outra mulher dev

Sou uma desenvolvedora com formação universitária e já trabalho há algum tempo. Devo dizer que só tenho admiração por programadores autodidactas. Honestamente, há tanta coisa que me esforcei por aprender que não consigo acreditar que vocês conseguiram realmente ensinar-se a si próprios. E eu adoro discutir com aqueles que são autodidactas porque normalmente têm um conjunto de competências completamente diferente do que a multidão unida. É inspirador e muito mauzão tbh.

E quanto à senhora que começou a explicar-vos um JSON, não pensem muito nisso. Isto acontece-nos muito. Homens bem-intencionados mas que acabam por explicar coisas mundanas porque somos raparigas e somos tão pouco comuns neste campo que sentem que têm de nos ajudar um pouco mais, mesmo que por vezes isso se torne um pouco insultuoso. Tenho sorte de ter sido recebida com respeito no meu local de trabalho, mas já ouvi algumas histórias de terror.

Ela provavelmente não quis dizer nada de mal com isso, mas o mais provável é que foram apenas as suas próprias inseguranças a brilhar um pouco e talvez ela sentisse que tinha de provar a si própria, ensinando-lhe algumas coisas.

Aconselho paciência. Testemunhei conversas entre pessoas com a melhor formação e experiência de décadas a discutir uma situação de programação em que começaram do quadrado absoluto 1. Que precisamos de representar uma entidade do mundo real no software, que foi criada uma estrutura de dados para ser essa representação, que esses dados precisam de ser enviados através da rede para outro sistema, etc.

O que inferi da sua abordagem foi que, tirando alguns minutos para tornar o maior número possível de pressupostos explícitos e estabelecer uma cadeia de raciocínios comuns, foi criada uma base sólida para trabalharmos juntos.

Pode ou não ser que estas explicações sejam um sinal de desrespeito ou ressentimento (ou uma tentativa de lhe provar os seus conhecimentos), mas pode transformar-se numa oportunidade de entrar na mesma página e partilhar perspectivas para tornar a relação de trabalho melhor.

“JSON é um formato para representar estruturas de dados como texto”

“Oh, JSON, estava a ler sobre as diferentes implementações, sabe se existe um exemplo de referência de um parser construído com lex e yacc para o JSON?

Abra a sua mente.

A Universidade ensina competências que não encontrará em livros (para além dos livros escolares da Universidade) e que provavelmente lhe faltam se for autodidacta. Como é que eu sei? Eu estudei, mas algumas partes do campo não faziam parte do meu curriculum e eu sou autodidata nesses campos. Por isso conheço ambos os lados.

Ela provavelmente tem algo para te ensinar, mas ambos não percebem o que isso é. Ela acha que precisa de explicar conceitos básicos. Isto pode ser porque ela é condescendente, socialmente desajeitada, arrogante, tem um complexo de inferioridade ou o que quer que vocês queiram acreditar - ou pode ser porque ela quer genuinamente apoiá-los.

In dubio pro reo, portanto, até prova em contrário, assumam o melhor e recebam as suas discussões com uma mente aberta. No entanto, assim que perceber que já sabe o que ela está a tentar explicar, agradeça-lhe e explique que já compreende isto. Pergunte-lhe o que mais ela tem para oferecer, você está ansioso para aprender e melhorar constantemente. Esta é a vantagem de ser autodidacta: Compreende que a aprendizagem é um processo constante que não termina com o exame nem com a tese de mestrado.

Use essa vantagem. Aprenda com ela, isso só pode ser vantajoso para si.

E um dia, haverá algo que você sabe e ela não sabe. Ensine-a de uma forma amigável e não condescendente e vocês os dois poderão ter uma relação de trabalho brilhante e de apoio mútuo.

Tenho visto isto muitas vezes como consultor ao longo dos anos. A resposta é simples. Este é um mecanismo de defesa.

É um de dois complexos e pode ser uma combinação de ambos.

• Complexo de Inferioridade

• Complexo de Superioridade

Ambos são um mecanismo de defesa.

Se você é o único alvo de tal comportamento, então o sujeito é provavelmente ameaçado pelas suas habilidades ou habilidade.

Se você é um dos vários alvos de tal comportamento, então é um sentimento geral de inferioridade dentro do infrator.

Geralmente, você verá a compensação misturada com grandiosidade de alguma forma. Pode ser tão simples como estar demasiado orgulhoso do seu grau. Ninguém é imune a ser um alvo. Por exemplo, já vi pessoas com graus académicos inferiores atacarem pessoas com graus superiores, como os engenheiros. É um mecanismo de nivelamento que tenta elevar a auto-estima, diminuindo outra estatura. Nós vemos este comportamento no terreno p!ay quando crianças.

Embora você possa não querer atacar alguém por tal insulto, este comportamento pode ser um perigo para você e para outros, especialmente na força de trabalho.

Provavelmente, há pouco que você possa fazer para combater isto sem se fazer parecer mal. A razão é que a transacção foi concebida não só para indicar superioridade, mas também para solicitar uma resposta que imponha a superioridade.

Neste caso, parece que o infractor assumiu o papel de pai. Apenas uma resposta adulta o fará. Uma resposta de Pai ou Filho significa que perde. Isto pode ser visto através da leitura I’m OK, You’re OK e Games People Play . Ambos são baseados na Análise Transaccional. Ajudaria a ler o primeiro livro. É relativamente simples de entender e ensina a reconhecer os três estados e como responder.

Simplificando, isto é gamemenship.

Eu estou relutante em oferecer sugestões sobre como especificamente combater isto verbalmente, uma vez que os conselhos podem ser potencialmente prejudiciais. Isto precisa de ser combatido no momento.

Para referência, a Análise Transaccional não é psicologia pop. É uma ferramenta real que deve ser compreendida. Utilizei a AT na minha carreira de consultor e fui muito significativo no meu sucesso como consultor de TI. Permitiu-me afirmar-se como o adulto na sala, fazer valer os meus pontos de vista e, esperemos, defender eficazmente as minhas soluções.

Fui muitas vezes chamado para resolver um problema ou substituir um sistema pelo qual alguém era responsável. Muitas vezes, o poder estava a ser retirado ao indivíduo que estava agora na defensiva. Batalhas como estas são frequentemente sobre poder, quer a perda de ou a aquisição de poder. O objectivo é minimizar a ameaça, minimizando a perda. Por exemplo, numa empresa global, o Microsoft Mail estava a envelhecer e tinha de ser substituído. O funcionário responsável manteve as rédeas apertadas e geriu todos os servidores que exigiam que estivessem num único local. Para uma Telecom global, isto foi um desastre. As pessoas no Japão teriam de se ligar aos servidores na Virgínia para ler o correio electrónico. O fardo era enorme e o e-mail não seria entregue em 24 horas. O funcionário tinha medo de tecnologia que não compreendia ou conhecia e estava preocupado com o seu trabalho com um sistema global distribuído. A solução era acompanhar o funcionário através de formação, instalações de teste, suporte a sistemas remotos, e fazer com que ele percebesse que ainda desempenhava um papel fundamental dentro da organização. Ele não estava a perder poder, mas sim a ganhar poder. Tudo isto através do TA.

Ok. Bem e bem. A resposta curta que tenho é compreender os três tipos de transacções e aprender como apresentar uma postura de adulto e como reconhecer o verdadeiro objectivo da transacção que lhe é apresentada. Você pode rápida e facilmente curto-circuitar o problema sem que ninguém se aperceba e posicionar-se como um líder de uma forma silenciosa mas eficaz. O efeito global será visto.

A maioria das respostas aqui discutem confrontação ou comiseração com a sua experiência. Eu não acredito que o confronto valha o seu tempo ou o tempo dos outros desenvolvedores.

Em vez disso eu recomendo um pouco de engenharia social que foi frequentemente praticada por Benjamin Franklin aka o Efeito Benjamin Franklin :

Peça ajuda, conselhos, sugestões. Pedir um favor é um sinal de intimidade e confiança.

Isto pode parecer uma iniciativa contrária, mas se você fizer algumas perguntas pontuais sobre assuntos mais complicados, subliminarmente alguém reconhecerá que você entende o assunto fundamental e, assim, lhe dará mais confiança. Também os fará sentir mais confiantes por si porque veio ter com eles para este tópico “difícil”.

Esta é uma solução rápida e não conflituosa que irá funcionar na maioria dos casos.

TI é um campo muito amplo.

Assumindo que alguém _ tem de conhecer_ JSON só porque tem um total de 4 anos de experiência (ou 40) seria uma coisa bastante estúpida para fazer pelo seu colega de trabalho. Você poderia estar desenvolvendo aplicações que não usam JSON, ou frameworks que escondem os detalhes do JSON.

Pior ainda, você poderia ter aprendido parcialmente a usar o JSON (por exemplo, modificando o trabalho de alguém que não foi suficientemente cuidadoso); atribuindo-lhe um JSON sem garantir que você sabe como o JSON é usado na sua organização poderia levar a um produto abaixo do padrão. Por exemplo, talvez o seu código deva funcionar não só para ter sucesso mas também para mostrar uma mensagem apropriada em caso de erro.

Dado que é novo no seu cargo, um dos meios do seu colega de trabalho para garantir que o trabalho é feito correctamente é rever os seus conhecimentos. O método descrito acima é um dos disponíveis, ela poderia, alternativamente, optar por questioná-lo ou esperar até a sua tarefa estar concluída e rever o código. Não sei se prefere algum deles. Certamente, deixá-lo estar é arriscado (para si, para ela e para o negócio) até ela ter a certeza de que está à altura do seu trabalho.

Note que nenhum dos pontos acima está relacionado com a sua falta de certificação académica.

E o ponto “passei na entrevista técnica” não o absolve de ser examinado. Uma entrevista técnica dá apenas uma avaliação muito superficial da sua competência; diz-lhe que pode escrever código que funciona mas não que pode escrever bom código.

Há muitos aspectos que são importantes mas não podem ser examinados facilmente:

• Capacidade de compreender problemas.

• Capacidade de ler o código de outras pessoas.

• Capacidade de utilizar uma arquitectura adequada.

• Capacidade de escrever código bem estruturado.

• Programação defensiva.

• Boas práticas na utilização de ferramentas (controlo de versões, testes automáticos).

E para a questão “grau vs autodidacta”, aceite que a falta de um grau significa que o seu interlocutor pode fazer menos suposições sobre o que sabe ou o que não sabe1. Especialmente em relação aos pontos acima explicados (muitas pessoas autodidatas simplesmente não sabem da existência desses factores e apenas vão ao “Quero fazer um programa que faça X "2)

Alguém com um diploma pode certificar uma base mínima de conhecimentos3, a falta de um diploma torna mais forte que o seu interlocutor pode estar inseguro do seu nível até que você prove a si próprio. Portanto, não fique defensivo se o seu interlocutor optar por verificar duas vezes se os seus conhecimentos são suficientemente completos para a tarefa em questão.

TL/DR Dê algum tempo a esse programador para que ele possa verificar sozinho as suas capacidades.

1Of curso, isso não significa que alguém com um grau académico seja sempre capaz de escrever bom código porque alguém lhe explicou "programação defensiva”. Mas o grau garante que pelo menos ele deve saber o que o conceito significa.

2Pois estou a modificar um programa feito

3Na verdade, isso é basicamente a utilidade dos graus.

Fale com ela sobre isso.

A sua interpretação do comportamento dela é que é porque ela pensa em si como inexperiente. Muitas das outras respostas têm dado sugestões de interpretações alternativas ao seu comportamento, e algumas dão sugestões de como desligar o comportamento, o que, sem saber porque o faz, poderia simplesmente colocar desnecessariamente mais stress na relação.

A única maneira de saber porque o faz é falar com ela sobre isso. O ideal seria perguntar-lhe directamente, dizer-lhe porque o faz, e assegurar-lhe que se não entende algo que vai perguntar.

Conhece-a melhor do que qualquer um de nós, por isso deveria ter uma ideia melhor de como ela reagiria, mas considere começar por algo como isto:

Hey Sue, sei que não trabalhamos juntos há muito tempo e ainda estamos a aprender o que esperar um do outro. Reparei que quando falamos de compras, muitas vezes caem em explicações bastante básicas sobre o que considero serem tópicos padrão. Porquê? Espero que seja porque X ou Y (dar uma ou duas das interpretações mais generosas das outras), mas muitas vezes parece que já te dei a impressão de que preciso que me expliquem estas coisas. Se for esse o caso, parece que estamos a desperdiçar tempo valioso que poderia ser utilizado de forma mais produtiva na discussão das características necessárias. Se não tem a certeza da minha experiência com um tema, pode perguntar o que sei sobre ele e se a discussão toca em algo fora da minha confiança de experiência que eu vou perguntar.

Eu não a interromperia inicialmente enquanto ela está numa das suas explicações para ter esta discussão, porque parece mais provável que ela se veja como reaccionária ou defensiva. É melhor abordá-la em separado.

Avançar a partir daí, dependendo do que vier da discussão inicial, quando e se voltar a acontecer, poderia interjectar que esta é uma dessas explicações básicas, ou começar a aplicar algumas das sugestões dos outros sobre como responder em linha.

Como um aparte:

Num projecto do ano passado tive de explicar o que era o JSON a dois membros da equipa. Ambos têm pelo menos uma década (ou duas) de experiência no sector e, em vários momentos das suas carreiras, ambos tinham trabalhado em projectos web. Eles simplesmente nunca trabalharam com qualquer framework ou precisaram de técnicas onde era particularmente relevante.

No mesmo projecto, tínhamos alguns dos empresários com quem estávamos a trabalhar, utilizávamos alternadamente os mesmos dois ou três termos que se referiam a dois tópicos intimamente relacionados mas (ao que parece) distintos. Qual o tópico que um determinado termo significava dependia de qual deles o utilizava e em que contexto. Na verdade, foram necessárias algumas iterações para que pudéssemos compreender. Até esse ponto, nunca foi claramente definido que existiam sequer tópicos distintos. Mais recentemente, numa discussão sobre uma aplicação mal configurada, tive um membro da equipa a sair numa tangente durante meia hora propondo alterações mal orientadas ao nosso quadro de configuração para evitar que o ambiente defaultado errado fosse seleccionado, quando o problema era que a aplicação tinha o valor defaultado errado para uma configuração individual. (O framework permite valores por defeito no caso de não ser anulado para o ambiente actual, a aplicação tinha o que deveria ser um valor de produção apenas definido por defeito, por isso quando um ambiente de teste não o anulou…)

Qual é o objectivo? Praticamente qualquer campo profissional é suficientemente amplo para que qualquer pessoa, independentemente do nível de experiência, seja impossível saber tudo. Cada um terá diferentes buracos no seu conhecimento e experiência, e pode muito bem haver subculturas e especializações com linguagem de choque. Não se pode simplesmente fazer suposições sobre o que as outras pessoas sabem, ou significam, ou porque tomam certas decisões.

Tem sido a minha experiência, suposições não declaradas podem ser (e eventualmente serão) muito caras. Alguns minutos gastos para garantir que todos estão na mesma página antes de iniciar qualquer discussão pouparão muito a longo prazo.

Neste caso a sua suposição de que ela está a fazer isto porque você é autodidacta, e/ou (se a sua suposição estiver correcta) a sua suposição de que precisa da instrução está a causar danos à sua relação de trabalho.

Eu li todas as respostas acima e a maioria delas aponta que ela está sendo gentil e você está pensando demais.

Mas pela sua pergunta, não parece ser assim. Parecia sentir-se insultado pelo comportamento dela.

Na minha opinião, é o momento, precisa de mostrar as suas capacidades. Pode ser a percepção dela que o grau é o que faz um “Programador de Software”, mas na minha experiência a trabalhar em projectos em tempo real e a resolver cenários críticos é o que faz um “Programador de Software”. *Não se vanglorie, mas participe nas discussões técnicas proactivamente.**

Para mostrar sem se gabar, comece a ajudar os seus colegas, juniores, etc. O seu trabalho, conjunto de competências e tudo o resto falará por si.

Isto é um pouco mais complicado do que algumas das respostas fazem crer. Não deve simplesmente dizer que não precisa de ajuda (arrogância), nem deve continuar a ouvir silenciosamente (é irritante!).

O meu conselho é… deslumbrá-la com os seus conhecimentos. Se compreende algo que lhe está a ser explicado na indústria de desenvolvimento de software, mostre à pessoa que lhe está a explicar que o compreende, discutindo-o, e depois introduza gradualmente os seus conhecimentos avançados sobre o assunto para lhe mostrar que o compreende. Quando alguém apenas ouve, muitas pessoas, e especialmente engenheiros, são propensos a pensar que o ouvinte é incapaz de se envolver na discussão porque não compreende.

Case and point, when someone is explaining something obvious to you in the industry, stay silenci silenci silencioso, as chances são de que eles vão explicar novamente de uma forma ligeiramente diferente… várias vezes com frustração incremental. Responda, mostre que sabe, e eles tendem a deixá-lo em paz, ou a encontrar algo melhor para discutir.

Para parar completamente com a má formação técnica, mostre que sabe MAIS do que a pessoa que o está a tentar ensinar e eles aprenderão rapidamente a não lhe dar lições e se alguma coisa lhe surgir com perguntas.

Agora se lhe estão a explicar o JSON porque cometeu um erro crítico, ou apenas demonstrou um conceito arquitectónico falhado, é aí que se cala e ouve.

Apenas os meus dois cêntimos sobre o que funcionou para mim no passado, todos são um pouco diferentes no entanto.

Advertência: Isto só funciona com algumas pessoas em algumas situações; YMMV. Esta resposta não tem garantia.

O que eu faria neste caso era interrompê-los com um resumo do tópico. Por exemplo, com JSON:

Them: JSON é JavaScript Object Notation, que é uma forma de representar - Me: Dictionary-like objects and, erm, arrays and primitives and, JavaScript primitives I mean, in a serialised format.

Isto explica a seguinte situação:

Them: JSON é JavaScript Object Notation, que é uma forma de representar - Me: Qualquer objecto em JavaScript como uma string. Them: Não, porque não pode armazenar funções, ou objectos que têm propriedades escondidas; é uma representação muito simples de…

Interrompê-los com “sim, eu sei” neste caso levaria a problemas mais tarde quando eu acabasse por não saber realmente o que era o JSON, por isso causou problemas no código com os meus pressupostos.

O seu colega está provavelmente apenas a tentar ter a certeza de que sabe tudo o que precisa de saber. Se é “autodidacta” então isso significa que pode ter lacunas que a maioria das pessoas presumiria ter preenchido uma vez que sabe as “coisas mais difíceis” (embora a maioria dos estabelecimentos de ensino ensine essas coisas numa ordem muito estranha também!) e esse tipo de suposição pode levar a problemas subtis, difíceis de encontrar devido a falsas suposições.

*: ver o topo da resposta.

Não mencionou a indústria, o que fará muita diferença.

Trabalho numa grande empresa de alta tecnologia e contrato frequentemente jovens promotores (0-2 anos de experiência). A escola que frequentaram e a sua licenciatura não me faz a mínima diferença.

Recentemente rejeitei dois candidatos da melhor escola do país para contratar um de uma escola de que nem sequer me lembro do nome. A diferença entre eles era que os dois primeiros eram bons e o terceiro era brilhante, também porque era autodidacta. Era óbvio, após 5 minutos, que ele se sairia bem.

** O que é que isto significa no contexto da sua pergunta? Provavelmente, poderá estar melhor adaptado a uma indústria que dá maior importância ao conhecimento do que à escola.**

Dependendo do país, isto pode ser mais ou menos difícil, como os diferentes países consideram nas suas escolas com diferentes níveis de deferência (sendo a França o extremo onde quase se veste roupa interior brasonada com a escola, se for da escola certa - isto não é uma coisa má, dependendo do tipo de trabalho)

Acho que se pode dizer - eu já sei um pouco (ênfase no pouco) sobre o JSON. Então, podemos saltar o JSON por agora? Mas, se há algo que eu não sei sobre o JSON, posso pedir-lhe ajuda mais tarde?

Vamos apenas dizer ao seu exemplo que você não manipula o JSON. Você pega no JSON, converte-o para um objecto modelo, manipula o objecto modelo e converte-o de volta para o JSON. Aposto que se o seu colega tentar manipular o JSON directamente, haverá bugs porque o JSON é simples, mas não isso simples.

Agora se ele é tão inteligente, imprima uma cópia deste papel https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf que se trata de calcular códigos Huffman ideais com comprimentos de código limitados (códigos Huffman com comprimentos de código ilimitados são simples) e peça-lhe para lhe explicar esse algoritmo. Muito provavelmente ele não será capaz de o fazer, na pior das hipóteses você cala-o durante algum tempo. (Códigos Huffman de comprimento limitado são importantes, porque permitem descodificadores muito mais eficientes). PS. Se ele ou ela can lhe explicar o algoritmo, então ele ou ela é bom. Duvido.

Além disso, se alguém tentar explicar-lhe o JSON, pergunte-lhe o que é que eles estão a tentar alcançar lá? Será que ele acha que o JSON é algo difícil que não se consegue compreender sem um grau de CS? A sério? Será que ele não acha que está um pouco convencido de si mesmo? O seu comportamento é insultuoso, por isso devolve o melhor que ele merece.

Os autodidactas são muitas vezes peritos em tecnologias em que têm experiência prática, mas por vezes o problema é que não sabem o quanto não sabem. Por exemplo, já encontrei muitas vezes programadores autodidactas a inventar um novo algoritmo para resolver um problema quando existe um algoritmo padrão bem conhecido, que muitas vezes é muito melhor.

Tente lembrar-se que se fosse canalizador ou electricista, quanto mais médico ou advogado, não seria autorizado a praticar sem qualificações formais. De facto, a programação é bastante única, permitindo que aqueles cujas competências são inteiramente autodidacta trabalhem na profissão. E muitos dos que o fazem, fazem um excelente trabalho. Mas tente reconhecer que aqueles que fizeram um curso de CS aprenderam coisas que você não aprendeu, e esteja aberto a aprender com eles.

A propósito, um curso de CS não lhe ensinará muito sobre o JSON. No entanto, ensinar-te-á a que classe de gramática pertence o JSON e, portanto, a que classe de parser precisas para o processar: ensinar-te-á a evitar o erro de tentar analisar o JSON usando expressões regulares, porque a teoria diz-te que isso não pode ser feito. Basta seguir o StackOverflow durante algumas semanas para ver quantos programadores não têm conhecimento de tais fundamentos.