Cómo evaluar el síndrome del impostor con datos y luego diseñar una base de confianza

¿Alguna vez te has sentido como un fraude? ¿Como en cualquier momento su jefe y sus colegas se darán cuenta de que los ha estado estafando todo el tiempo? ¿Que no eres el ingeniero que creen que eres?

Resulta que los ingenieros en todos los niveles de éxito sufren del síndrome del impostor. De hecho, la mayoría de los profesionales (y probablemente los ingenieros ), desde los más jóvenes hasta los más eminentes, han tenido en algún momento la creencia paradójica de ser un fraude a pesar del éxito laboral y otras pruebas de lo contrario. ‍

Pero, ¿cómo saber si padece el ‘síndrome del impostor’ o en realidad es un impostor?

Frío. Difícil. Datos. ¡Interpretado correctamente, por supuesto!

Para ser claros, es muy poco probable que en realidad seas un impostor. Pero nadie espera que confíe en mi palabra. Solo los datos que han sido rigurosamente validados y procesados tienen el poder de liberar a alguien de las cadenas de la duda parabólica.

Aquí hay un proceso para que los ingenieros de software comprendan sus sospechas de impostores, las pongan a prueba y luego interpreten de manera significativa los resultados con un ojo crítico y saludable.


Análisis estático: compruebe el código que impulsa su impostura

El primer paso para resolver sus sospechas de impostor es identificar con precisión cuáles son para empezar.

Piense en la impostura como un programa que su cerebro ejecuta constantemente. Cuando descubre suficientes creencias para respaldar la identificación como impostor, establece al impostor como igual true. Cuando esas creencias se invalidan, se establece en false.

En otras palabras, sentirse un impostor no viene de la nada. Tienes una autoimagen técnica y profesional: un conjunto de creencias que te llevan a sentirte un impostor en algunas áreas y a tener confianza en otras. Y estas creencias, además, tienden a basarse en un conjunto muy específico de experiencias, ya sea en el trabajo, fuera del trabajo, ¡o incluso antes de comenzar a trabajar!

Necesitamos descubrir rigurosamente los matices de estas creencias (positivas y negativas) para luego alinearlas con la realidad y diseñar una base más estable en el futuro.

Y, por suerte para nosotros, existen varias técnicas para recopilar estos datos:

Auto-encuesta de alto nivel

Antes de emplear cualquier proceso formal, es mejor comenzar con una exploración de forma libre, similar a la lluvia de ideas o la ideación en el desarrollo de productos.

Es decir, hágase las siguientes preguntas y vea lo que sale a la superficie:

  • ¿Sobre qué me siento un impostor?
  • ¿De qué me siento inseguro?
  • ¿Qué debilidades temo que mi jefe o equipo (u otros) se enteren?
  • ¿De qué manera estoy por debajo del promedio?

Estas preguntas son intencionalmente de alto nivel para no anclar su pensamiento. El objetivo es permitir que todo lo que sea especialmente potente se revele antes de entrar en el meollo de la cuestión. Y eso también incluye sentimientos positivos. Así que también deberías preguntarte:

  • ¿De qué estoy orgulloso?
  • ¿En qué me siento fuerte?
  • ¿En qué me siento seguro?
  • ¿Qué habilidades tengo que otros ingenieros no tienen? o ¿De qué manera estoy por encima del promedio?

A medida que se le ocurran elementos, escríbalos en algún lugar y déjelos a un lado. Los próximos pasos nos permitirán llevar algo de organización a estos sentimientos de alto nivel.

Y recuerde, si no se le ocurre nada para una pregunta en particular, está bien. Es mejor dejar algo sin respuesta que forzar una respuesta que no suena verdadera.

Revisión sistemática de habilidades

La siguiente técnica está destinada a llenar los vacíos de cosas que pueden haberse perdido en la exploración de alto nivel, al tomarse un momento para considerar cada una de sus habilidades, una por una.

Entonces, en lugar de hacer una pregunta amplia y enumerar habilidades, está iterando a través del universo de habilidades posibles y clasificándolas en grupos significativos según cómo se sienta.

Sin embargo, antes de realizar cualquier clasificación, necesitamos una lista de habilidades que sean relevantes para su área particular de ingeniería. El siguiente es un gran lugar para comenzar, pero asegúrese de hacer una lluvia de ideas por su cuenta para llegar a una lista que sea un poco más exhaustiva para usted personalmente.

  • Escribir código de trabajo
  • Depuración
  • Escribir código legible
  • Habilidades de comunicación
  • Resolución de problemas en general
  • Trabajo centrado en la interfaz de usuario
  • Trabajo en equipo
  • Algoritmos y CS académica
  • Diseño y arquitectura del sistema
  • Conocimiento específico del dominio (por ejemplo, backend, frontend, iOS o sistemas de bajo nivel)
  • Comunicando tus fortalezas
  • No presenta errores graves
  • Hacer estimaciones
  • Proyectos secundarios

Con esta lista en la mano, simplemente repase cada habilidad y pregúntese cómo se siente al respecto. Más específicamente, clasifique la habilidad en una de tres categorías:

  1. Fuerza sospechada
  2. Sospecha de debilidad
  3. No estoy seguro

Las categorías anteriores se excluyen mutuamente. Debes elegir uno por habilidad. Y si eso es difícil de hacer, como con las «habilidades de comunicación», divida la habilidad en componentes como «establecer expectativas» y «comunicarse claramente con el equipo de producto» hasta que sea posible dicha categorización.

Y recuerde, se sospecha que se trata de fortalezas y debilidades. Las evaluaciones deben basarse simplemente en cómo se siente acerca de la habilidad, no en lo que la evidencia sugiere necesariamente de una forma u otra. El objetivo es descubrir tu imagen actual de ti mismo tal como es, no lo que debería ser (eso vendrá después).

/// Buckets
var suspectedWeaknesses = [Skill]()
var suspectedStrengths = [Skill]()
var notSure = [Skill]()
var impostorCandidates = [Skill]()

/// Bucket skills based purely on how you feel about them
func bucketBasedOnCurrentFeelings(_ skills: [Skill]) {
      for skill in allMySkills {

                /// If I currently feel like the skill is a weakness...
                if self.feelsWeak(about: skill) {
                        suspectedWeaknesses.append(skill)

                /// If I currently feel like the skill is a strength...
                } else if self.feelsStrong(about: skill) {
                        suspectedWeaknesses.append(skill)

                /// If I'm not sure or could go either way...
                } else {
                        notSure.append(skill)
                }

                /// If I have any impostor feelings about this skill, aside from whether I think it's a strength or weakness...
                if self.hasImpostorFeelings(about: skill) {
                        suspectedWeaknesses.append(skill)
                }
        }
}

Ahora hay una categoría más que está separada del resto: candidatos impostores.

Es decir, es posible que sientas que algo es una debilidad, pero no también un impostor al respecto. Esa debilidad podría ser conocida por otros y algo que no tienes miedo de revelar. Pero cuando sientes que los demás piensan que eres mejor en algo de lo que crees que eres, eso representa un riesgo de impostor.

Del mismo modo, incluso es posible que sienta que algo es una fortaleza, pero le preocupa que su interpretación no sea precisa y en cualquier momento lo descubrirán por ser realmente malo en eso.

Si ese es el caso de cualquiera de sus habilidades, agréguelo al grupo de «candidatos impostores» además de uno de los tres grupos anteriores.

Ahora tiene un sentido mucho más completo de su propia imagen sobre todas sus habilidades que complementará los descubrimientos más potentes que hizo con su autoevaluación de alto nivel.

Retroalimentación, éxitos y fracasos pasados

Finalmente, queremos hacer una lista de comentarios pasados (positivos y negativos), fracasos y éxitos.

Por ejemplo, es posible que su gerente le haya hecho un cumplido la semana pasada durante la revisión del código. Tal vez lo elogiaron por obtener algo con anticipación o lo criticaron por no estimar con precisión. Quizás a alguien realmente le encantó la forma en que ayudó a un desarrollador junior, o el correo electrónico que envió al equipo de producto, o cualquier otra cosa (técnica o no técnica) por la que se hizo un juicio de valor.

Enumere entre 10 y 20 elementos que se destaquen para usted, si puede.


Depuración: valide (y refine) el código con fuentes autorizadas

En este punto, debe tener una lista bastante sustanciosa de las creencias e ideas que alimentan su sentido personal de ser un impostor.

Hasta ahora, hemos tomado esas creencias al pie de la letra. Es decir, hicimos todo lo posible para revelar cuáles son, pero permitimos que existieran tal cual para que pudiéramos obtener una descripción precisa del código real que estamos ejecutando actualmente.

Esto es como depurar. Cuando descubra que una parte del código no funciona como se esperaba, primero debe comprender exactamente cómo funciona antes de saber qué parte cambiar para obtener los resultados que desea.

Este paso consiste en probar cada línea de código para determinar si debe permanecer, cambiarse o eliminarse por completo, comenzando con los elementos que son más importantes para usted.

Y la mejor manera de hacerlo es juzgar su legitimidad con autoridad en los temas sobre los que hace un reclamo. Estas autoridades vienen en una variedad de formas:

Mentores expertos

Si desea saber qué tan bueno es en el diseño de sistemas, probablemente sea beneficioso encontrar a alguien que sea considerado excelente en el diseño de sistemas y comenzar una relación de tutoría con ellos. No solo podrán ayudarlo a mejorar en la habilidad, sino que también le brindarán información valiosa sobre su viaje para llegar a ser tan bueno como ellos. Pueden decirle cuánto tiempo les llevó alcanzar la competencia, si la curva de aprendizaje es empinada o lineal, y cómo se compara con ellos en su etapa de desarrollo de esa habilidad. Lo mejor de todo es que su reconocida experiencia hace que sea más fácil para usted confiar realmente en lo que dicen, por lo que puede disipar las dudas que de otro modo podrían surgir al preguntarle a alguien cuyo éxito no es tan evidente.

Gerentes y líderes (que no sean los suyos)

Del mismo modo, hay muchos ingenieros en puestos de dirección y liderazgo que han trabajado con muchas otras personas en su puesto actual a lo largo de sus carreras. Revelarles sus inseguridades y obtener comentarios sobre cómo está a la altura puede proporcionar puntos de datos específicos e invaluables que puede usar para impulsar su sentido de dónde se encuentra en comparación con otros que tienen o administran actualmente. No es necesario que sean expertos en un área específica, pero tienden a ser mejores fuentes de comentarios sobre habilidades de nivel superior que abarcan toda la ingeniería de software. Y las personas en esta posición que no son su jefe a veces pueden estar en una mejor posición para ofrecer comentarios útiles porque no hay presión sobre la relación. Es decir,

Tu jefe real

Dicho esto, a veces nada calmará su sensación de impostor más que una clara sensación de cuál es su posición con respecto a su jefe real. Las personas de alto rendimiento tienden a establecer expectativas demasiado altas para sí mismas y, a veces, creen erróneamente que su jefe (y sus colegas) son tan duros con ellos como ellos mismos. Además de eso, un ingeniero junior a veces puede culparse a sí mismo por algo que aún no se ha dado cuenta de que es normal incluso para los ingenieros más experimentados.

Ponerse en contacto regularmente con su jefe sobre su desempeño es una excelente manera de mantenerse sincronizado y sentirse seguro acerca de si la persona a cargo de su salario cree que usted es un impostor, y eso a menudo tiene efectos positivos en su propia autoevaluación porque tiende a hacerlo. Ajústelo en tiempo real cuando descubra que no está en la misma página.

Simulacros de entrevistas, entrevistas reales y otros tipos de evaluaciones.

Si las entrevistas técnicas son una de las cosas que llevan a una sensación de impostura, entonces realizar tantas entrevistas y evaluaciones de estilo de entrevista como pueda es una excelente manera de recopilar datos sobre su posición en su habilidad de entrevista. El cuestionario de devnow es un estilo de evaluación que puede darle una idea de cómo se compara con otros para demostrar ciertos tipos de conocimiento del dominio. Interview Kickstart y Interviewing.io ofrecen entrevistas simuladas, mientras que Leet Code ofrece una gran cantidad de preguntas tipo entrevista. Y siempre existe la técnica de realizar entrevistas en empresas reales cuando se le ofrece (incluso cuando no está buscando activamente) exponerse a tantos estilos de entrevista como sea posible.

Artículos de opinión, estudios y otros materiales en línea (y fuera de línea)

Los ingenieros con todos los antecedentes posibles han escrito extensamente sobre lo que hace que alguien sea excelente en muchas de las habilidades que pueden preocuparle. Esto va desde artículos de opinión breves como los que se encuentran en el compilador de devnow , hasta tomos sobre cómo escribir código limpio, publicaciones en Reddit, estudios de académicos y nuevas empresas con acceso a conjuntos de datos únicos. Si desea obtener más información sobre su situación, a veces todo lo que necesita es ver las estadísticas que aparecen en Google sobre cuántos ingenieros escriben código limpio, cuántos piensan que es importante o si realmente debería conocer SQL como interfaz. ingeniero (o si la pila completa es el futuro). ¡Es posible que descubra que no hay una opinión canónica y que realmente no existe nada parecido a ser un impostor en este tema!

Interprete los datos con ojo crítico

El hecho de que haya recopilado datos externos de una fuente autorizada no significa que deba aceptarlos todos al pie de la letra. Todo el mundo tiene sus puntos ciegos y todo el mundo está influenciado por su conjunto específico de experiencias, que siempre introduce sesgos en sus opiniones.

Necesita recopilar datos, pero también debe evaluarlos con un alto grado de pensamiento crítico.

Opiniones fuertes! = Verdad

Los ingenieros tienden a tener opiniones muy sólidas, un hecho que a veces puede distorsionar realmente su sentido de la realidad. Tendemos a expresar las opiniones como un hecho, y argumentamos muy duramente en contra de las opiniones con las que no estamos de acuerdo.

El hecho de que alguien exprese claramente que el código limpio es una necesidad absoluta, o qué proceso usar para estimar sus tareas de ingeniería, o qué estilo de git commit es aceptable, no significa que estén «correctos». Para la mayoría de las opiniones sólidas, está prácticamente garantizado que encontrará decenas de otros ingenieros con la opinión exactamente opuesta que suenen igual de seguros. ¡Todavía hay una controversia brutal entre vim y emacs que ha estado ocurriendo desde los albores de los editores de texto! Y personalmente me han ensañado en numerosas ocasiones por puntos que hice en mis propios escritos porque la redacción no era del agrado de alguien o compartían un conjunto diferente de valores.

El punto es que puede recopilar todos los datos externos que desee, pero a menudo encontrará que no existe una autoridad única y definitiva que lo libere para unirse de manera segura a un campamento u otro. Tendrás que sopesar los matices de lo que a menudo es un campo de juego confuso y sacar tus propias conclusiones, y acostumbrarte a la incertidumbre de no estar 100% seguro. En caso de duda, pruebe un enfoque de encuesta (encontrar varias fuentes sobre algo) para tratar de descubrir cuál es una opinión útil sobre algo.

Considere la etapa de desarrollo al analizar sus datos

A veces, una fuerte crítica puede quedarse con alguien durante toda su carrera. Por ejemplo, alguien que fue muy malo depurando en el primer año de su carrera puede internalizar al “depurador malo” como una propiedad inamovible de su personalidad, cuando en realidad es una habilidad que se puede desarrollar.

Del mismo modo, puede recopilar comentarios de un jefe que tenía hace varios años, o proporcionar evidencia de algo que no ha sucedido en varios años a uno de sus mentores, e internalizarlo tan válido ahora como entonces.

El caso es que la gente cambia con el tiempo. A veces nos quedamos estancados en una cosa u otra, pero a veces crecemos de maneras que ni siquiera nos hemos dado cuenta. Mientras sopesas los comentarios y los datos de la experiencia, pregúntate siempre cómo el momento de esos datos puede ser relevante para la conclusión que estás tratando de sacar ahora.

Compárate con las personas adecuadas

Es genial buscar mentores y esforzarse por ser excelente. Pero no ser de clase mundial en una habilidad en particular tampoco implica que seas un impostor. Por eso, por lo general, no es una buena idea compararse con los expertos de los que está tratando de aprender, al menos cuando está emitiendo un juicio sobre su absoluta legitimidad.

En otras palabras, al responder la pregunta: «¿Estoy en un nivel de habilidad aceptable para x habilidad?» Siempre compare con otros en la misma etapa de desarrollo cuando sea posible. Pero al preguntarse: «¿He alcanzado la excelencia?» se puede comparar con sus modelos a seguir, siempre que lo haga con expectativas realistas de cuándo se puede alcanzar la excelencia.

La autoridad tiene sus limitaciones

Incluso los expertos más autorizados tienen sus puntos ciegos. Pueden ser excelentes para fragmentar una base de datos, pero no ser lo suficientemente conscientes de sí mismos como para comunicar lo que los llevó a ser excelentes (o si usted también está en el camino hacia la grandeza). Como tal, si algo no resuena completamente con usted, incluso de un experto, es posible que deba hacer el trabajo de lectura entre líneas de sus propios puntos ciegos para separar la verdad del sesgo. Si bien esto puede parecer aterrador, la otra cara es que te das cuenta de que incluso los más celebrados entre nosotros tienen debilidades, como tú, y estás en una mejor posición de lo que piensas para tener tus propias opiniones, sopesar los datos de manera razonable y confiar tus instintos.

 

Subscríbete y recibe nuevas noticias

devnow

Autor desde: August 12, 2020

Deje su comentario

EN ES