Para tu información, la mayoría de las universidades no enseñan cosas como JSON. Enseñan cosas como el primer árbol transversal de profundidad que podrías aplicar teóricamente para crear tu propia biblioteca de JSON, pero cualquier cosa más práctica que eso casi todo el mundo es autodidacta o aprendido en el trabajo.

Intenta no ponerte a la defensiva. Explicar las tecnologías prácticas como JSON es algo que esperamos tener que hacer ocasionalmente incluso para los graduados universitarios. Alguien con mejores habilidades sociales preguntaría si estás familiarizado con ello primero. Si no preguntan, siéntanse libres de simplemente interrumpir y decirles.

No hay razón para que no puedas indicar que tu colega está proporcionando información superflua durante las discusiones técnicas.

Hey Coworker, saltemos los detalles triviales y vayamos al quid de la cuestión. Esto no es un uso muy efectivo de nuestro tiempo.

Puede que sólo tenga una tendencia a sobreexplicar las cosas o a salirse del tema, pero una buena habilidad a desarrollar en cualquier momento en que esté interactuando con otros desarrolladores es mantener educada pero firmemente las interacciones sucintas y sobre el tema para que el tiempo de todos se gaste de manera eficiente.

Para ser justos, tengo muy buenas credenciales y un antiguo supervisor me hizo esto todo el tiempo. Tomé una clase de CS en profundidad sobre diseño de bases de datos, había construido todo tipo de aplicaciones basadas en bases de datos, y había estado trabajando profesionalmente durante años, y todavía tenía el descaro de explicarme (delante de todos los demás) los principios de diseño de bases de datos para principiantes.

Pero no estoy seguro de que lo hiciera a propósito. La verdad es que se necesita mucha energía mental para ponerse en el lugar de otra persona y hablar a su nivel. Lo ves todo el tiempo: los expertos a veces te lanzan jerga sin sentido, u otros te hablan con desprecio. Pero no lo dicen necesariamente en serio: no gastan suficiente energía para averiguar cómo comunicarse bien.

En mi experiencia, eso era lo más difícil de dar clases particulares de CS. No sólo tenía que entender el material en profundidad, sino que tenía que usar bastantes ciclos cerebrales tratando de entrar en la cabeza de mis estudiantes y averiguar lo que estaban pensando. Pero no todo el mundo practica eso en una conversación casual.

Así que no se apresure a atribuirlo a la malicia. Podría muy bien ser su propia incomodidad social. Te diría que no te lo tomes como algo personal, pero todavía estoy trabajando en ello. Personalmente tampoco lo soporto…

Esto es similar a otras respuestas, pero con algunos ejemplos concretos.

Si estás pidiendo ayuda / ustedes dos están discutiendo la tarea en cuestión

Cuando estoy en el otro extremo de esto. Es muy difícil saber qué conocimientos previos tiene alguien cuando explica algo.

Explicar de menos y de más es malo. La solución es comunicar lo que sabes o no sabes de forma efectiva y rápida.

En tu ejemplo antes de que se sumerja demasiado en explicar JSON, interrumpe (políticamente) para que pueda tachar eso de su “lista de cosas a explicar”.

Oh tengo lo que es JSON. Lo que no sé es cómo deserializarlo a un objeto en C#. ¿Cómo se hace eso?

O en la discusión. Por ejemplo, si alguien propone usar JSON como formato y usted tiene dudas. Usted todavía interrumpiría porque quiere llegar a la parte relevante de la conversación rápidamente.

Estoy familiarizado con JSON. Creo que XML podría ser una mejor opción ya que nuestros servicios de cabecera ya lo esperan en XML.

Si te están llevando a la tarea por no hacer algo. Entonces sigues el mismo patrón.

Ella: Podrías haber usado X. X es un -

Tú (interrumpiendo): Sí, estoy familiarizado con X. Usé Y porque X tiene esta desventaja. También consideré Z pero también decidí no hacerlo.

Ella: ¿Qué hay de A que es un -

Tú (interrumpiendo): Ah sí, yo también consideré A. Pero no funcionó por las RAZONES.

Ella: Si combinas la A con la Z puedes resolver las RAZONES.

Tú: Sí, eso podría funcionar. Lo investigaré.

Suelo ponerle el prefijo “Sí” como una forma corta más agradable de “Sí, soy consciente de eso” y eso me quita el borde.

Mientras mantengas un tono neutral, no te parecería que no escucharas las críticas.

Además, algún día te equivocarás. Sólo asegúrate de que cuando lo estés, seas igual de abierto y honesto.

Si estás chateando en general

Ahora estamos en el área de la etiqueta de la conversación educada. No es exactamente mi fuerte pero así es como lo manejaría.

En muchos casos sólo asiento y espero hasta que terminen. Después de lo cual digo algo como: “Ah, sí, estoy familiarizado con JSON”. Lo he usado en X.‘. Y simplemente continúo la conversación.

Si tengo que estar en algún lugar, no hay elección, tengo que interrumpir. Lo cual es más difícil en una conversación normal. Pero básicamente sólo digo “Sí” y asiento con la cabeza mientras están hablando. Y tan pronto como hacen una pequeña pausa digo la línea del párrafo anterior.

Aviso

Yo avisaría de todo lo anterior con: A veces es bueno escuchar de todos modos, ya que podrías recoger algo que no sabías. De hecho, a menudo pido a la gente que explique conceptos como si no supiera nada de ellos.

Descargo de responsabilidad: No soy un desarrollador de software

Le recomendaría que evitara hacer la suposición de que está siendo intencionadamente condescendiente. Podría muy bien ser que ella piense que tu falta de educación superior significa que no tienes conocimiento de los conceptos básicos de programación, pero no tienes pruebas de esto, así que es mejor que no lo pienses. A menudo explico los conceptos básicos en las reuniones de planificación porque me ayuda a entender ciertos problemas y asegura que todo el mundo siga mi proceso de pensamiento, no porque piense que las otras personas en la sala son idiotas.

Además de las excelentes respuestas de @Link0352 y @JeffO, cuando sea posible, recomendaría que se reduzca suavemente la conversación al nivel en el que debe estar para una discusión productiva.

Claro, podríamos manipular el JSON, pero esto podría llevar al problema X. En este caso, recomendaría manipular el objeto directamente (o lo que sea).

(Asumo que esta interacción ocurrió durante una reunión técnica y el compañero de trabajo no sólo se acercó a su cubo y comenzó a hablar de JSON. Si ese es el caso, mi respuesta no se aplica realmente).

Además de otras respuestas, mi solución genérica para que la gente te explique cosas obvias:

Cuando terminen, voltea la mesa. Empieza a explicar un conocimiento más profundo sobre el tema reciente o explica otro muy obvio, por ejemplo

otra persona : Json es un gran para … y puedes hacer … tú (sonriendo/amistoso): ¡Exactamente! Lo que también me gusta de Json es que puedes ….

o si quieres ser un poco malo

otra persona : Json es un gran para… y puedes hacer… tú (sonriendo/amistoso): ¡Exactamente! ¿Has oído hablar de XML? Es una [explicación de algo muy obvio]

De otra desarrolladora femenina

Soy un desarrollador con educación universitaria y he trabajado por un tiempo. Tengo que decir que no tengo nada más que admiración por los desarrolladores autodidactas. Honestamente, hay tantas cosas que he luchado por aprender que no puedo creer que ustedes hayan logrado enseñarse a sí mismos. Y me encanta discutir con los autodidactas porque normalmente tienen otro tipo de habilidades que la gente de la universidad. Es inspirador y bastante malo.

Y en cuanto a la señora que empezó a explicarte un JSON, no lo pienses mucho. Esto nos pasa mucho. Hombres que tienen buenas intenciones pero terminan explicando cosas mundanas porque somos chicas y somos tan poco comunes en este campo que sienten que tienen que ayudarnos un poco más, aunque a veces se vuelva un poco insultante. Tengo la suerte de haber sido recibida con nada más que respeto en mi lugar de trabajo, pero he escuchado algunas historias de horror.

Probablemente no quiso decir nada malo con ello, pero lo más probable es que sólo eran sus propias inseguridades que brillaban un poco y tal vez sintió que tenía que probarse a sí misma enseñándote algunas cosas.

Aconsejaría paciencia. He sido testigo de conversaciones entre personas con el mejor entrenamiento y décadas de experiencia discutiendo una situación de programación donde empezaron desde el cuadrado 1 absoluto. Que necesitamos representar una entidad del mundo real en el software, que se ha creado una estructura de datos para ser esa representación, que estos datos necesitan ser enviados a través de la red a otro sistema, etc.

Lo que deduje de su enfoque fue que al tomarse un par de minutos para hacer explícitas tantas suposiciones como fuera posible y establecer una cadena de razonamiento compartida, se estableció una base sólida para trabajar juntos.

Puede ser o no que estas explicaciones sean una señal de falta de respeto o resentimiento (o un intento de demostrarle su conocimiento), pero puede convertirse en una oportunidad para llegar a la misma página y compartir perspectivas para mejorar la relación de trabajo.

Si alguna vez se te escapa de las manos o sientes realmente la necesidad de decir algo, te sugiero que hagas una pregunta que muestre el límite de tu comprensión.

“JSON es un formato para representar estructuras de datos como texto”

“Oh, JSON, estaba leyendo sobre las diferentes implementaciones, ¿sabes si hay un ejemplo de referencia de un analizador construido con lex y yacc para JSON?”

Abre tu mente.

La Universidad enseña habilidades que no encontrarás en los libros (aparte de los libros de texto de la Universidad) y que probablemente te falten si eres autodidacta. ¿Cómo lo sé? Estudié, pero algunas partes del campo no eran parte de mi curiculo y soy autodidacta en esos campos. Así que conozco ambas partes.

Probablemente tenga algo que enseñarte, pero ambos no se dan cuenta de lo que es. Ella cree que necesita explicar los conceptos básicos. Esto podría ser porque es condescendiente, socialmente torpe, arrogante, tiene un complejo de inferioridad o cualquier otra cosa en la que quieras creer - o podría ser porque ella realmente quiere apoyarte.

En dubio pro reo, así que hasta que se demuestre lo contrario, asume lo mejor y da la bienvenida a sus discusiones con una mente abierta. Sin embargo, una vez que te des cuenta de que ya sabes lo que ella está tratando de explicar, agradécele y explícale que ya lo entiendes. Pregúntele qué más tiene para ofrecer, usted está ansioso por aprender y mejorar constantemente. Esta es la ventaja de ser autodidacta: Entiendes que el aprendizaje es un proceso constante que no termina con el examen o la tesis de maestría.

Utiliza esa ventaja. Aprende de ella, eso sólo puede ser una ventaja para ti.

Y un día, habrá algo que tú sepas y ella no. Enséñale de una manera amistosa y no condescendiente y ustedes dos podrían tener una brillante relación de trabajo de apoyo mutuo.

He visto esto muchas veces como consultor a lo largo de los años. La respuesta es simple. Este es un mecanismo de defensa.

Es uno de dos complejos y puede ser una combinación de ambos.

• Complejo de Inferioridad

• Complejo de Superioridad

Ambos son un mecanismo de defensa.

Si usted es el único objetivo de tal comportamiento, entonces es probable que el sujeto se vea amenazado por sus habilidades o destrezas.

Si usted es uno de los varios objetivos de tal comportamiento, entonces es un sentimiento general de inferioridad dentro del infractor.

Generalmente, usted verá la compensación mezclada con la grandiosidad de alguna forma. Podría ser tan simple como estar demasiado orgulloso de su grado. Nadie es inmune a ser un objetivo. Por ejemplo, he visto a gente con títulos menores atacar a los que tienen títulos superiores, como los ingenieros. Es un mecanismo de nivelación que intenta elevar la autoestima disminuyendo otra estatura. Vemos este comportamiento en la tierra p!ay de niños.

Aunque no quieras atacar a alguien por un insulto así, este comportamiento puede ser un peligro para ti y otros especialmente en la fuerza de trabajo.

Probablemente, hay poco que puedas hacer para combatir esto sin hacerte quedar mal. La razón es que la transacción está diseñada no sólo para indicar superioridad, sino también para solicitar una respuesta que refuerce la superioridad.

En este caso, parece que el infractor ha tomado el papel de padre. Sólo una respuesta adulta será suficiente. Una respuesta de Padre o Hijo significa que pierde. Esto se puede ver leyendo I’m OK, You’re OK y Games People Play . Ambos están basados en el Análisis Transaccional. Ayudaría leer el primer libro. Es relativamente simple de entender y te enseña a reconocer los tres estados y cómo responder.

En pocas palabras, esto es un juego.

Soy reacio a ofrecer sugerencias sobre cómo combatir esto específicamente de forma verbal ya que el consejo podría ser potencialmente dañino. Esto necesita ser combatido en el momento.

Para referencia, el Análisis Transaccional no es psicología pop. Es una herramienta real que debe ser entendida. Utilicé el AT en mi carrera de consultor y fue muy significativo en mi éxito como consultor de IT. Me permitió afirmarme como el adulto en la sala, hacer mis puntos, y con suerte hacer un caso efectivo para mis soluciones.

A menudo me llamaban para arreglar un problema o reemplazar un sistema del que alguien era responsable. A menudo, el poder se le quitaba al individuo que ahora estaba a la defensiva. Las batallas como estas son a menudo sobre el poder, ya sea la pérdida o la adquisición de poder. El objetivo es minimizar la amenaza minimizando la pérdida. Por ejemplo, en una compañía global, Microsoft Mail estaba envejeciendo y tuvo que ser reemplazado. El empleado responsable mantuvo las riendas con firmeza y administró todos los servidores que requerían estar en un solo lugar. Para una compañía global de telecomunicaciones, esto era un desastre. La gente en Japón tendría que conectarse a los servidores en Virginia para leer el correo electrónico. La carga era enorme y el correo electrónico no sería entregado en 24 horas. El empleado tenía miedo de la tecnología que no entendía o conocía y estaba preocupado por su trabajo con un sistema global distribuido. La solución fue guiar al empleado a través de la capacitación, las instalaciones de prueba, el soporte de sistemas remotos y hacer que se diera cuenta de que todavía jugaba un papel fundamental dentro de la organización. No estaba perdiendo poder sino ganando poder. Todo esto a través de TA.

Bien. Bien. La respuesta corta que tengo es entender los tres tipos de transacciones y aprender a presentar una postura adulta y a reconocer el verdadero objetivo de la transacción que se le presenta. Puedes cortocircuitar rápida y fácilmente el problema sin que nadie se dé cuenta y posicionarte como un líder de una manera silenciosa pero efectiva. El efecto general se verá.

La mayoría de las respuestas aquí discuten la confrontación o la conmiseración con su experiencia. No creo que la confrontación valga su tiempo o el de otros desarrolladores.

En su lugar recomiendo un poco de ingeniería social que fue practicada a menudo por Benjamin Franklin alias el Efecto Benjamin Franklin :

Pedir ayuda, consejo, sugerencias. Pedir un favor es un signo de intimidad y confianza.

Esto puede parecer una contra-iniciativa, pero si haces algunas preguntas puntuales sobre temas más complicados, subliminalmente hará que alguien reconozca que entiendes el tema fundamental y por lo tanto te dará más confianza. También hará que se sientan más confiados por ti porque acudiste a ellos para este tema “difícil”.

Esta es una solución rápida y no conflictiva que funcionará en la mayoría de los casos.

Es un campo muy amplio.

Asumir que alguien tiene que conocer a JSON sólo porque tiene un gran total de 4 años de experiencia (o 40) sería una cosa bastante tonta de hacer por su compañero de trabajo. Usted podría haber estado desarrollando aplicaciones que no usan JSON, o marcos de trabajo que ocultan los detalles de JSON.

Peor aún, usted podría haber aprendido parcialmente a usar JSON (por ejemplo, modificando el trabajo de alguien que no fue lo suficientemente cuidadoso); asignarle una tarea JSON sin asegurarse de que sabe cómo se usa JSON en su organización podría conducir a un producto de calidad inferior. Por ejemplo, tal vez su código debe funcionar no sólo para el éxito sino también para mostrar un mensaje apropiado en caso de error.

Dado que usted es nuevo en su puesto, uno de los medios de su compañero de trabajo para asegurarse de que el trabajo se hace correctamente es revisar sus conocimientos. El método descrito anteriormente es uno de los disponibles, ella podría optar por interrogarlo o esperar hasta que su tarea esté terminada y revisar el código. No sé si preferiría alguno de esos. Ciertamente, dejarte ser es arriesgado (para ti, para ella y para el negocio) hasta que esté segura de que estás a la altura del trabajo.

Ten en cuenta que nada de lo anterior está relacionado con tu falta de certificación académica.

Y el punto de “pasé la entrevista técnica” no te absuelve de ser examinado. Una entrevista técnica sólo da una valoración muy superficial de tu competencia; dice que puedes escribir un código que funciona pero no que puedes escribir un buen código.

Hay muchos aspectos que son importantes pero no pueden ser examinados fácilmente:

• Habilidad para entender problemas.

• Habilidad para leer el código de otras personas.

• Habilidad para usar una arquitectura apropiada.

• Escribir buen código estructurado.

• Programación defensiva.

• Buenas prácticas en el uso de herramientas (control de versiones, pruebas automatizadas).

Y para el tema de “grado vs auto-enseñanza”, acepta que la falta de un grado significa que tu interlocutor puede hacer menos suposiciones sobre lo que sabes o lo que no sabes1. Especialmente en relación con los puntos explicados anteriormente (muchas personas autodidactas ni siquiera saben de la existencia de esos factores y simplemente van al “Quiero hacer un programa que haga X "2)

Alguien con un título puede certificar una base mínima de conocimientos3, la falta de un título hace más fuerte que su interlocutor pueda estar inseguro de su nivel hasta que usted se pruebe a sí mismo. Por lo tanto, no se ponga a la defensiva si su interlocutor elige comprobar que su conocimiento es lo suficientemente completo para la tarea en cuestión.

TL/DR Déle tiempo a esa programadora para que compruebe por sí misma sus capacidades.

1Por supuesto, eso no significa que alguien con un título académico sea siempre capaz de escribir buen código porque alguien le haya explicado la "programación defensiva”. Pero el grado asegura que al menos debería saber lo que el concepto significa.

2Ahora mismo estoy modificando un programa hecho

3De hecho, esa es básicamente la utilidad de los grados.

Háblale de ello.

Tu interpretación de su comportamiento es que es porque ella piensa que eres inexperto. Muchas de las otras respuestas han dado sugerencias de interpretaciones alternativas a su comportamiento, y algunas dan sugerencias de cómo apagar el comportamiento, que, sin saber por qué lo hace podría poner innecesariamente un estrés adicional en la relación.

La única manera de saber por qué lo hace es hablar con ella sobre ello. Lo ideal sería preguntarle directamente, hacerle saber por qué lo hace y asegurarle que si no entiende algo le preguntará.

Usted la conoce mejor que cualquiera de nosotros, así que debería tener una mejor idea de cómo reaccionaría, pero considere comenzar con algo como esto:

Hey Sue, sé que no hemos trabajado juntos por mucho tiempo y todavía estamos aprendiendo qué esperar el uno del otro. He notado que cuando hablamos de trabajo a menudo caes en explicaciones bastante básicas de lo que considero temas estándar. ¿Por qué? Espero que sea porque X o Y (da una o dos de las interpretaciones más generosas de los otros), pero a menudo siento que te he dado la impresión de que necesito que me expliques estas cosas. Si ese es el caso, parece que estamos perdiendo un tiempo valioso que podría ser utilizado más productivamente discutiendo las características requeridas. Si no está seguro de mi experiencia con un tema, puede preguntar lo que sé sobre él, y si la discusión toca algo fuera de mi experiencia confíe en que lo preguntaré.

No la interrumpiría inicialmente mientras está en una de sus explicaciones para tener esta discusión porque parece más probable que se vea como reaccionaria o defensiva. Mejor acercarse a ella por separado.

A partir de ahí, dependiendo de lo que venga de la discusión inicial, cuando y si vuelve a suceder, podrías interponer que esta es una de esas explicaciones básicas, o empezar a aplicar algunas de las sugerencias de los otros sobre cómo responder en línea.

Como un aparte:

En un proyecto del año pasado tuve que explicar lo que era JSON a un par de miembros del equipo. Ambos tienen al menos una década (o dos) de experiencia en la industria sobre mí, y en varios puntos de sus carreras ambos habían trabajado en proyectos web. Simplemente nunca trabajaron con ningún marco de trabajo o técnicas necesarias donde fuera particularmente relevante.

En el mismo proyecto, algunos de los empresarios con los que trabajábamos usaban indistintamente los mismos dos o tres términos que se referían a dos temas estrechamente relacionados pero (resulta que) distintos. Qué tema significaba un determinado término dependía de cuál de ellos lo usaba y en qué contexto. De hecho, nos llevó unas cuantas iteraciones para ponernos al día. Hasta ese momento, nunca se había establecido claramente que había incluso temas distintos. Asumieron que lo sabíamos, y asumimos que todos se referían a lo mismo.

Más recientemente, en una discusión sobre una aplicación mal configurada, hice que un miembro del equipo se fuera por la tangente durante media hora proponiendo cambios equivocados en nuestro marco de configuración para evitar que se seleccionara el ambiente por defecto equivocado, cuando el problema era que la aplicación tenía el valor por defecto equivocado para un ajuste individual. (El marco de trabajo permite valores por defecto en caso de que no se anule para el entorno actual, la aplicación tenía lo que debería ser un valor de sólo producción establecido por defecto, así que cuando un entorno de prueba no lo anuló…)

¿Qué sentido tiene? Casi cualquier campo profesional es lo suficientemente amplio como para que para cualquier persona, independientemente de su nivel de experiencia, sea imposible saberlo todo. Cada uno tendrá diferentes agujeros en su conocimiento y experiencia, y bien puede haber subculturas y especializaciones con una jerga conflictiva. No se pueden hacer suposiciones sobre lo que otras personas saben, o significan, o por qué toman ciertas decisiones.

Ha sido mi experiencia, las suposiciones no declaradas pueden (y eventualmente lo harán) ser muy costosas. Dedicar unos minutos a asegurarse de que todo el mundo está en la misma página antes de empezar cualquier discusión ahorrará mucho a largo plazo.

En este caso, tu suposición de que ella está haciendo esto porque eres autodidacta, y/o (si tu suposición es correcta) su suposición de que necesitas la instrucción está causando daños a tu relación laboral.

El desarrollador con o sin título debe ser respetado por igual en el lugar de trabajo.

Leí todas las respuestas anteriores y la mayoría de ellas señalan que ella está siendo amable y tú lo estás pensando demasiado.

Pero por tu pregunta, no parece ser así. Parecía que te sentías insultado por su comportamiento.

En mi opinión, es el momento, necesitas mostrar tus habilidades. Puede ser su percepción de que el grado es lo que hace a un desarrollador de software, pero en mi experiencia trabajando en proyectos en tiempo real y resolviendo escenarios críticos es lo que hace a un “desarrollador de software”. No alardees, pero participa en las discusiones técnicas de forma proactiva.

Para exhibir sin alardear, empieza a ayudar a tus compañeros, juniors, etc. Tu trabajo, tus habilidades y todo lo demás hablará por ti mismo.

Esto es un poco más difícil de lo que algunas de las respuestas parecen ser. No deberías salir y decir que no necesitas ayuda (arrogancia), ni deberías seguir escuchando en silencio (¡es molesto!).

Mi consejo es… deslumbrarla con tu conocimiento. Si entiendes algo que se te está explicando en la industria del desarrollo de software, demuestra a la persona que te lo está explicando que lo entiendes, discutiéndolo, y luego introduce gradualmente tus conocimientos avanzados del tema para mostrarte que lo entiendes. Cuando alguien simplemente escucha, mucha gente, y especialmente los ingenieros, son propensos a pensar que el oyente es incapaz de participar en la discusión porque no lo entiende.

Caso y punto, cuando alguien está explicando algo obvio para ti en la industria, guarda silencio, es probable que lo explique de nuevo de una manera ligeramente diferente… varias veces con una frustración incremental. Responde, demuestra que lo sabes, y tienden a dejarte solo, o a encontrar algo mejor que discutir.

Para detener completamente el acoso técnico, demuestra que sabes MÁS que la persona que intenta enseñarte y rápidamente aprenderán a no sermonearte y si algo te viene con preguntas.

Si te explican JSON porque cometiste un error crítico, o acabas de demostrar un concepto arquitectónico erróneo, ahí es donde te callas y escuchas.

Apenas mis dos centavos en lo que me ha funcionado en el pasado, todo el mundo es un poco diferente sin embargo.

Advertencia: Esto sólo funciona con algunas personas en algunas situaciones; YMMV. Esta respuesta no tiene garantía. Lo que haría en este caso es interrumpirlos con un resumen del tema. Por ejemplo, con JSON:

Ellos: JSON es JavaScript Object Notation, que es una forma de representar - Me: Objetos similares a un diccionario y, erm, matrices y primitivas y, primitivas de JavaScript quiero decir, en un formato serializado.

Esto explica la siguiente situación:

Ellos: JSON es JavaScript Object Notation, que es una forma de representar - Me: Cualquier objeto en JavaScript como una cadena. Them: No, porque no puede almacenar funciones, u objetos que tienen propiedades ocultas; es una representación muy simple de…

Interrumpirlos con “sí, lo sé” en este caso llevaría a problemas más tarde, cuando resultó que no sabía realmente lo que era JSON, así que causó problemas en el código con mis suposiciones.

Su colega está probablemente tratando de asegurarse de que usted sabe todo lo que necesita. Si eres “autodidacta” entonces eso significa que podrías tener lagunas que la mayoría de la gente asumiría que has llenado ya que sabes las “cosas más difíciles” (¡aunque la mayoría de los establecimientos educativos enseñan esas cosas en un orden realmente raro también!) y ese tipo de suposiciones puede llevar a problemas sutiles y difíciles de encontrar debido a falsas suposiciones.

*: ver la parte superior de la respuesta.

No mencionaste la industria, lo cual hará una gran diferencia.

Trabajo en una gran compañía de alta tecnología y a menudo contrato a jóvenes desarrolladores (0-2 años de experiencia). La escuela a la que asistieron y su grado no hace la más mínima diferencia para mí.

Recientemente rechacé dos candidatos de la mejor escuela del país para contratar a uno de una escuela de la que ni siquiera recuerdo el nombre. La diferencia entre ellos era que los dos primeros eran buenos y el tercero era brillante, también porque era autodidacta. Era obvio después de 5 minutos que lo haría muy bien.

¿Qué significa esto en el contexto de tu pregunta? Probablemente que usted puede ser más adecuado en una industria que da una mayor importancia a los conocimientos frente a la escuela.

Dependiendo del país esto puede ser más o menos difícil ya que los diferentes países consideran en sus escuelas con diferentes niveles de deferencia (siendo Francia el extremo donde casi se usa ropa interior blasonada con su escuela, si es de la derecha - esto no es algo malo dependiendo del tipo de trabajo)

Supongo que se podría decir que ya sé un poco (énfasis en poco) sobre JSON. Entonces, ¿podemos dejar de lado a JSON por ahora? Pero, si hay algo que no sé sobre JSON, ¿puedo pedirte ayuda más tarde?

Digamos a su ejemplo que usted no manipula a JSON. Tomas a JSON, lo conviertes en un objeto modelo, manipulas el objeto modelo y lo vuelves a convertir en JSON. Apostaría que si su colega trata de manipular JSON directamente, habrá errores porque JSON es simple, pero no que simple.

Ahora, si es tan inteligente, imprima una copia de este documento https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf que trata sobre el cálculo de los códigos Huffman óptimos con longitudes de código limitadas (los códigos Huffman con longitudes de código ilimitadas son simples) y pídale que le explique ese algoritmo. Lo más probable es que no sea capaz de hacerlo, en el peor de los casos lo harás callar por un tiempo. (Los códigos Huffman de longitud limitada son importantes, porque permiten decodificadores mucho más eficientes). P.D. Si él o ella puede explicarte el algoritmo, entonces es bueno. Lo dudo.

Aparte de eso, si alguien trata de explicarte JSON, le preguntas qué es lo que está tratando de lograr allí? ¿Piensa que JSON es algo difícil que no puedes entender sin un grado de CS? ¿En serio? ¿No cree que está un poco lleno de sí mismo? Su comportamiento es insultante, así que le devuelves lo que se merece.

Los desarrolladores autodidactas suelen ser expertos en tecnologías en las que tienen experiencia práctica, pero a veces el problema es que no saben cuánto no saben. Por ejemplo, a menudo me he encontrado con desarrolladores autodidactas que inventan un nuevo algoritmo para resolver un problema cuando hay un algoritmo estándar bien conocido, que suele ser mucho mejor.

Intenta recordar que si fueras fontanero o electricista, por no hablar de un médico o un abogado, no te permitirían ejercer sin una titulación oficial. La programación, de hecho, es bastante única al permitir que aquellos cuyas habilidades son completamente autodidactas trabajen en la profesión. Y muchos de los que lo hacen, hacen un excelente trabajo. Pero trata de reconocer que aquellos que han hecho un título CS han aprendido cosas que tú no has aprendido, y estate abierto a aprender de ellos.

Por cierto, un título CS no te enseñará mucho sobre JSON. Sin embargo, te enseñará a qué clase de gramática pertenece JSON y, por lo tanto, qué clase de analizador necesitas para procesarlo: te enseñará a evitar el error de intentar analizar JSON usando expresiones regulares, porque la teoría dice que eso no se puede hacer. Sólo tienes que seguir StackOverflow durante unas semanas para ver cuántos programadores no son conscientes de tales fundamentos.