Never just present a problem

Eché un vistazo rápido a tu perfil y me di cuenta de que has estado en la comunidad de StackExchange durante un tiempo. Sin duda habrás notado aquí que las preguntas que reciben las mejores respuestas por aquí son las que presentan el problema y el razonamiento que ya han tomado en un intento de responder a la pregunta.

La vida laboral es así. Si estás haciendo una pregunta, entonces quieres estar seguro de que también les haces saber lo que ya has hecho para intentar contestarla tú mismo. Esto te beneficia de varias maneras:

• Demuestra que no estás preguntando innecesariamente. Si expones tu razonamiento entonces le haces saber a la persona que estás haciendo un intento antes de hacer una pregunta y no sólo siendo perezoso.
• *Es probable que recibas retroalimentación que beneficie tus procesos de pensamiento. * Si un compañero viene a mí con un problema y expone cómo ha intentado responder a una pregunta no sólo le ayudará a guiarse por el camino correcto sino que también le ayudaré a entender cómo podría haber pensado en la pregunta para llegar allí por sí mismo. Cuanto más exponga su proceso de pensamiento y razonamiento, más podrán ayudarle otras personas a construir sobre ellos para futuros problemas.

Hay un par de puntos aquí para desempacar.

Asumí que a todos los demás en una compañía tecnológica les gustaba hablar de tecnología…

No necesariamente. Mucha gente técnica hablará de tecnología que es relevante para la tarea que están haciendo ahora, pero puede que no tengan ningún interés en nada más.

Creo que te puedes estar confundiendo entre esto y:

También me regañaron por “ir por el camino equivocado” al intentar resolver un problema con el que no estaba familiarizado en lugar de preguntar a alguien que sí lo estaba

Considera el chico que gritó lobo :) Si pasas el tiempo de otra persona hablando de cosas que no son relevantes para lo que está haciendo, entonces cuando le haces una pregunta relevante, puedes encontrar que siente que ya ha perdido suficiente productividad contigo.

Casi siempre trato de resolver los problemas por mi cuenta durante al menos una hora. ¿Esto es demasiado corto?

En muchos casos, sí es demasiado corto. A menos que el problema que intente resolver sea simple, entonces debería invertir más tiempo en buscar e intentar diferentes permutaciones. Si el problema es simple, entonces una búsqueda apropiada en la web debería dar los resultados correctos.

Ponga todo esto junto, y lo que veo es un joven programador que tiene algunos problemas de juicio, que es lo que su persona de RRHH le dijo. No es insuperable, pero hay algunas cosas en las que debes pensar.

• Guárdate las preguntas técnicas hipotéticas para el comedor. No es apropiado, a menos que conozcas bien a la gente, desperdiciar tu tiempo y el de los demás en preguntas irrelevantes.
• Aprenda a aplicar mejores términos de búsqueda en la web. Si le dicen que está haciendo demasiadas preguntas y se toma demasiado tiempo para hacerlas, entonces claramente está haciendo las preguntas equivocadas.
• Cuando haga una pregunta, muestre lo que ha intentado. Mentalidad clásica de desbordamiento de pila. Si no tienes nada que mostrar como un esfuerzo concertado para resolver un problema, entonces no te has esforzado lo suficiente. De hecho, no tengas miedo de utilizar los recursos como Stack Overflow si hay algo tangible que preguntar que puede ser de dominio público. Y por último;
• Guardar preguntas para preguntas específicas del negocio. No preguntes sobre cómo manejar tu herramienta de programación, pero do pregunta sobre temas específicos del dominio o del medio ambiente que no serán de dominio público.

Hay muchas cosas aquí que puedes hacer para mejorar. Usted puede encontrar que el PIP puede ser una herramienta muy valiosa para ayudarle a convertirse en un mejor desarrollador :)

El problema es que, cuando interrumpes el trabajo de alguien, no sólo pierden los 5-15 minutos que tardan en responder. Pierden mucho más tiempo, ya que necesitan recuperar la concentración. Y eso puede ser bastante frustrante.

Estuve en una situación similar a la tuya. Solía ir a la gente y hacerles preguntas de inmediato. Incluso cuando hacían algo que me bloqueaba. Eso puede incluso haber interrumpido a otras personas cercanas.

Mi gerente me dio una solución: usar el correo electrónico y la mensajería instantánea, incluso cuando la persona está sentada a tu lado. De esta manera, pensarás más en cómo formular la pregunta, y durante ese proceso podrás responderte a ti mismo. Además, la otra parte puede responderte cuando tenga algo de tiempo libre.

Otra opción es fijar una reunión, donde se aclaren todas las cosas.

Voy a tratar de responder desde la perspectiva de la empresa. No soy esa compañía, así que puede haber cosas que no veo, pero he visto esto antes en mi propia compañía.

Too Many Questions

La mayor parte de su confusión parece provenir del hecho de que no entendió que hacer preguntas es un juego peligroso. **Cuando haces una pregunta, admites que no sabes nada, y que no puedes entenderlo. Como desarrollador de software, una de tus tareas es descubrirlo. Estás insultando al equipo de desarrollo “actual” preguntando básicamente, “Así que escribiste tal código de mierda aquí que no puedo averiguar cómo leerlo o qué está haciendo, así que voy a necesitar que me lo expliques.”

La parte difícil aquí, es que algunas veces ese es exactamente el caso y deberías estar haciendo preguntas. Es importante recordar que, pase lo que pase, esas preguntas tienen un lado negativo.

Otra cosa que creo que percibo en tu OP es que estás haciendo preguntas demasiado pronto. Está muy bien que un nuevo desarrollador se siente a leer, e investigar durante todo un día, para escribir 2 líneas de código. De hecho, con 14 años de experiencia, todavía termino haciendo eso. Escribir código profesional no se trata de “cuánto” se hace, se trata de “qué tan bien” se hace, y ser capaz de repetir ese éxito. Dudo que alguien se queje de que te lleve 100 veces más tiempo hacer una décima parte del trabajo como desarrollador entrenado y establecido. De hecho, cuando contrato a alguien, anoto el primer mes como que no espero ningún trabajo real, y los primeros seis meses como que no espero mucho.

No pasar suficiente tiempo por tu cuenta

¡¡Esto es algo grande!!! Cuando le pides ayuda a un miembro del equipo, estás bajando la productividad de esa persona también. Estás impactando en su proceso e insultándolo (ver arriba) al mismo tiempo. No hay manera de que ganes, si tienes que pedir ayuda. Piensa en cada petición, como una batalla perdida. Aún puedes ganar la guerra, pero perdiste esta batalla.

Hay algunas cosas que puedes hacer para mitigar el problema:

1. Preguntar por correo electrónico, nunca en persona o por chat. El chat puede ser la forma preferida de hacerlo “oficialmente”, pero el correo electrónico es más agradable porque el receptor puede manejarlo en su propio tiempo.
2. 2. Acercarse a él desde una posición “más baja”. Tú eres el suplicante aquí. Haz algo de arrastre. Está bien. Un poco no te hará daño y le demostrará al receptor que sí te importa su tiempo, es decir, “Sé que estás muy ocupado, pero parece que no puedo averiguar cómo integrarme con tu API”. Cuando tengas unos momentos, ¿puedes mostrarme lo que me estoy perdiendo?“ Muestra que estás equivocado, no ellos. Es importante.
3. Enumera los pasos que has dado por tu cuenta. "El documento de la API dice que se pase una cadena que represente el id del usuario. Intenté pasar la propiedad user.id y el nombre de usuario, pero no funcionó.” Esto demuestra que al menos has intentado algo, y que en general, estás empezando a “conseguir” el producto.

Mejor juicio al hacer preguntas

Esto, para mí, suena como si hubieras “lloriqueado” a alguien, y no tenían una forma agradable de decir, “Estás molestando a todo el mundo con tus patéticas preguntas”. ¡Basta!“ En otras palabras, creo que esto no es un problema. Una vez que corrijas tus otros problemas esto desaparecerá.

Mala documentación

¡Ejem! Ese es otro insulto personal. Nunca jamás digas eso. ¡¡¡JAMÁS!!! Una vez más estás diciendo que la calidad de su código es tan pobre que no puedes entenderlo. Su respuesta siempre será "Funciona para todos los demás, así que tú debes ser el idiota, no yo”

Además, esto es un poco de “bienvenido al mundo real”. En el mundo real, los clientes pagan por aplicaciones que funcionan, no por el código o la documentación (la mayoría de las veces), así que es muy común que la documentación se degrade con el tiempo.

Si crees que la documentación es pobre y necesita ser abordada, entonces saca el tema, en silencio, con tu jefe de equipo. Deje que ellos decidan.

Sin embargo, diré esto. No importa cuán mala sea la documentación, con el código fuente delante de ti no deberías necesitarlo. Es muy agradable tenerlo, no me malinterprete, pero usted puede trabajar sin él. Eso es una tontería. De hecho, en tu situación actual, ¡llegas 30 minutos antes! Sin excusas. Estás arruinando cualquier esperanza de encontrar tu próximo trabajo con este. Si llamara al departamento de RRHH y preguntara por tu asistencia, y me dijeran “Llegaba tarde frecuentemente” o “Le escribieron por llegar tarde” eso es una bandera roja instantánea. Menciono esto, porque si mantienes este trabajo o consigues uno nuevo, esto más que cualquier otra cosa te impedirá conseguir el siguiente trabajo.

Código de baja calidad

Esto es probablemente cierto. Dado el problema de la pregunta, probablemente no estés escribiendo un buen código. Sin embargo, eres nuevo, y eso es de esperar. Encuentro que las universidades no enseñan una maldita cosa sobre codificación del mundo real. Nunca he contratado a alguien recién salido de la universidad y conseguido un “buen desarrollador”. Eso no significa que no hayan sido buenos desarrolladores. Simplemente no empiezan de esa manera. Escribir un buen código significa estar al tanto de las últimas tendencias y técnicas. Estás aprendiendo constantemente. El momento en que te detienes es el momento en que empiezas a apestar.

En conclusión

Este post ha sido duro, pero quería mostrar, claramente, cuál puede ser la postura de una compañía. A menudo, las empresas envuelven sus comentarios con tanto “lenguaje de directivos” que puede ser difícil de entender. Traté de reducir el discurso del gerente en este post tanto como pude, pero eso significa que es un poco duro.

Sus pasos más importantes para arreglar su fallida carrera:

1. ¡¡APARECE A TRABAJAR TEMPRANO!! (No puedo enfatizar eso lo suficiente)
2. Haz preguntas con la mente puesta en que ya estás insultando a la persona que estás preguntando.
3. Muestra tu trabajo. Cuando haga una pregunta, diga claramente lo que ya ha hecho. 4. Pasa más tiempo aprendiendo por tu cuenta. Es importante pasar más tiempo investigando que preguntando. Honestamente, 3 o 4 días buscando algo por tu cuenta serán más respetados que una pregunta de 30 segundos.

Quería intentarlo desde el punto de vista de la gestión.

Un PIP es algo integral

Es muy probable que la mejora del rendimiento sea una colección de las cosas que su gestión ha resaltado, todas juntas. Sospecho que si usted fuera la persona que hizo muchas, muchas preguntas, pero llegó temprano, se quedó hasta tarde e hizo un gran trabajo al escribir el código, el equipo trataría la pregunta como una rareza personal, o que usted es excepcionalmente minucioso.

Pero cuando el equipo tiene que ayudar a encontrar y arreglar más errores en tu código, después de responder más de la cantidad habitual de preguntas, y te ven trabajando menos horas o apareciendo tarde sin avisar, el equipo y el gerente van a sentir que no estás contribuyendo al nivel que necesitas, y no estás poniendo tiempo extra para ponerte al día. Es probable que la pregunta se haya planteado a la luz de los otros problemas, porque si intentas arreglar la calidad del código haciendo MÁS preguntas, será insostenible para el equipo.

Cada hora cuenta

Un nuevo graduado universitario ES una inversión en tiempo de equipo. Cualquier gerente que te diga lo contrario, o nunca ha contratado a un nuevo graduado universitario, o está mintiendo, o tiene líderes de equipo realmente excepcionales trabajando para él/ella. Cualquier nueva contratación es una inversión, pero los graduados universitarios tienen MÁS tiempo. Normalmente el intercambio vale la pena, pero ten en cuenta que los graduados universitarios hacen más preguntas que los desarrolladores más experimentados. Un equipo de desarrolladores hará más en una semana cuando todos estén al día, conozcan el código y no hagan muchas preguntas. Además, un equipo en este estado gelificado será capaz de hacer y responder preguntas muy rápidamente - lo que también acelera la productividad.

Responder a las preguntas _lleva tiempo. Y hay un cambio de contexto cada vez que un desarrollador deja de escribir código y comienza a responder preguntas. Así que responder a preguntas altamente interrumpidas es mucho más asesino de la productividad que sentarse durante una hora y responder a una colección de preguntas.

Estaría seguro de argumentar que CUALQUIER cambio de contexto cuesta 1 hora, así que incluso si tienes una pregunta de 5 minutos, le has costado al equipo una hora cuando alguien se detiene a responder tu pregunta. Eso significa que tomar 1 hora y no obtenerla, y luego pedir ayuda, en realidad cuesta más tiempo que tomar 2-4 horas.

No existe tal cosa como “al otro tipo sólo le tomará 5 minutos ahorrarme una hora”. Dada la métrica de al menos una hora por interrupción, es mejor que el otro tipo te ahorre 2-4 horas.

Consejos para hacer preguntas Bien:

• Entender y hacer preguntas de acuerdo con la urgencia - si absolutamente DEBES tener un problema resuelto en una hora, entonces interrumpir a casi cualquier persona que pueda ayudarte es una buena idea. Si se te dio un plazo de 3 semanas, entonces interrumpir menos y resolver más tus propios problemas es una mejor idea. Esto significa que en una emergencia, la gente a menudo hace muchas preguntas que de otra manera investigarían por su cuenta. Porque es absolutamente esencial tener la respuesta lo más rápido posible.
• Usar los foros de preguntas para su propósito definido, o intuir el propósito a partir de las preguntas/respuestas existentes. Los Intercambios en pila, por ejemplo, tienen un conjunto bastante extenso de reglas básicas que están bastante bien documentadas, y una expectativa particular de que los usuarios busquen respuestas previas antes de preguntar. Un foro diferente puede esperar preguntas repetidas pero sólo sobre un área muy estrecha.
• Investigue su pregunta. Espere que escribir una buena pregunta puede tomar tanto tiempo como dar la respuesta - en muchos casos, usted está describiendo (¡poco a poco!) los pasos que lo llevaron al punto de ser incapaz de responder al problema. También es probable que estés documentando todos los síntomas del problema.
• Dirige tus preguntas - averigua quién puede realmente responder a las preguntas cuando sea posible en lugar de preguntar a todo el mundo. No todas las preguntas valen la pena ser discutidas.
• Agregue una gran pila de preguntas - especialmente cuando es nuevo, tómese un día para revisar el problema y el código. Agregue sus preguntas en una lista de viñetas con temas agregados. Luego pregúntale a un mentor o a un amigo adónde ir para obtener ayuda con estos temas. Es muy probable que la mayoría de las preguntas de la hora 1 sean respondidas en la hora 6. Las preguntas que llegaron en la hora 1 y 2 y que no pudieron ser respondidas en la hora 8 están probablemente en el tope de su lista ya que saben que en 8 horas no pudieron descifrarlas.
• El código no se “auto documenta” pero se puede aprender mucha información leyéndolo. Aprendí muchos sistemas no documentados sentándome con un cuaderno y dibujando mi versión del diseño sobre la marcha. Si no has leído varios niveles por encima y varios niveles por debajo del área en la que trabajas y no has leído los documentos de las APIs externas que estás usando, no has investigado lo suficiente.
• Cuando intentas averiguar una respuesta, se llega muy lejos si puedes sugerir posibilidades, en lugar de preguntar por la respuesta. “¿Sería esta la forma correcta de hacerlo?” es mejor que “¿Cómo lo hago?” - incluso si la respuesta es “lo estás haciendo completamente mal”, puedes preguntar “¿por qué mi manera está mal?” y la más meta “¿cómo aprendería a hacerlo bien repetidamente? Este es el enfoque de "enseñar a un hombre a pescar” - aprender a pescar, no hacer preguntas que sólo te consiguen un pez.
• Evitar las preguntas que son simplemente una forma educada de no estar de acuerdo. Hay una línea entre “¿es mi forma de hacer esto factible?” vs. “No entiendo (es decir, estoy de acuerdo) por qué lo hiciste a tu manera”. Esas son buenas conversaciones, pero es mejor mantenerlas informalmente después de conocer a la gente.
• Modera tus preguntas generales - estas suelen ser las preguntas de “por qué”. La gente nueva está en su derecho de hacer muchas preguntas de “dónde” y “quién” (dónde están los documentos, dónde está el proceso para esto, dónde está el lugar en el código que quiero mirar? quién puede responder a esto? a quién invito a la revisión?) y un cierto número de preguntas de “cómo” - es así como debería enfocarlo? cómo puedo conseguir su acuerdo? Pero “por qué” como en “¿por qué lo construimos así?”, “¿por qué no documentamos más el código?”, “¿por qué no es esto una prioridad?” - son legítimos, pero hasta que no tengas más experiencia con el trabajo y el negocio, no son las preguntas más necesarias. Pueden ser GRANDES para un 1 a 1 con tu jefe donde no tienes otros asuntos urgentes, pero si el “por qué” desplaza el “dónde”, el “quién” y el “cómo” entonces no te estás centrando en tu trabajo.

He estado exactamente en la misma situación.

Problema

Lo que describes es el problema que enfrentan la mayoría de los recién graduados. La mayoría de las universidades sólo te enseñan lo básico o conceptos mientras que en un trabajo práctico necesitas mucho más.

La mayoría de las empresas cuando contratan a recién licenciados tienen planes de formación, que si los sigues deberías tener confianza en hacer tu trabajo dentro de un año más o menos. Pero algunas personas se vuelven curiosas, si les das una tarea simple para arreglar un pequeño componente de un sistema, no lo consiguen hasta que dominan todo el sistema y creo que tú eres uno de esos…

Creo que haces preguntas porque,

• Sientes que te estás tomando más tiempo del razonable para completar una tarea, ya que no entiendes alguna parte del sistema.

• Tienes curiosidad por entender el sistema completamente

• Tu compañía no te proporcionó el entrenamiento apropiado

Solución

Si mis suposiciones son correctas, entonces deja de hacer preguntas a menos que tengas que hacerlo (punto final - ahora mismo)

• Empieza a pasar más tiempo entendiendo el sistema (no sólo 8 horas)

• Usa el SO u otros sitios relacionados en su lugar (después de hacer tu parte de investigación)

• Pide a tu compañía que te entrene adecuadamente @áreas con las que necesitas ayuda.

Seguí lo anterior y ahora trabajo en la misma compañía después de 5 años y puedo decir que sé más que nadie aquí.

Ya hay muchas respuestas aquí, pero quiero abordar algunas partes específicas de tu pregunta.

Aunque también me regañaron porque no paso suficiente tiempo tratando de resolver las cosas por mi cuenta antes de pedir ayuda a los demás. Esto no es cierto, y mi jefe no tiene forma de saber cuánto tiempo pasa desde que encuentro un problema hasta que pido ayuda a alguien. Casi siempre trato de resolver los problemas por mi cuenta durante al menos una hora.

¿Esto es demasiado corto? ¿Cuál es una cantidad razonable de tiempo para dedicar a un problema antes de preguntarle a un compañero de trabajo que sabe la respuesta?

El énfasis añadido es mío.

Para empezar, sí, una hora es probablemente demasiado poco tiempo. Digo probablemente aunque… realmente depende del problema. Y tener un límite de tiempo es bueno, pero debes confiar más en los indicadores de que estás en una pared que en un límite de tiempo. Pero lo importante es que cuando estés listo para hacer preguntas, el receptor de las mismas debería poder ver la investigación que has hecho sobre tu problema sólo por el tipo de pregunta que estás haciendo.

Y ahí es cuando llegamos a la parte en negrita de la cita. Es técnicamente correcto. Nadie más que tú puede saber exactamente cuánto tiempo dedicas a un problema antes de pedir ayuda.

Pero basándome en la pregunta que haces, en la información que proporcionas con la pregunta, en el contexto de la pregunta y en la facilidad con la que puedo encontrar la respuesta con una simple búsqueda en Google, puedo hacer una estimación bastante buena de cuánto esfuerzo pones para resolver el problema por tu cuenta.

Si haces una pregunta, y la primera búsqueda en Google que intento da como resultado tu solución como la número uno, eso son dos golpes para ti, básicamente. No importa si pasaste 10 minutos o 10 meses en el problema. Deberías haber estudiado ya esa página y o bien arregló tu problema, o me estás hablando de esta página y por qué no resolvió tu problema.

Pero además, ¿qué tipo de preguntas estás haciendo? ¿Estás pidiendo soluciones directas? ¿O está pidiendo un pequeño empujón en la dirección correcta? A veces, la pared a la que te enfrentas es que desconoces por completo alguna biblioteca o alguna parte existente de la base de código que hará que la solución de tu problema sea sencilla.

Diría que has aprendido sobre lo que esta compañía espera a través de la escuela de los golpes duros. Las preguntas en este lugar son un no-no.

Creo que tu principal problema es la visibilidad. Hacer preguntas sobre la holgura es algo que mucha gente puede ver; incluso si no se sienten obligados a responder, eso podría afectar su juicio sobre ti. Mientras tanto, si pasas un día averiguando una sola característica en tu escritorio, nadie ve esa rueda girando. Pareces estar haciendo algo mal, en lugar de estar golpeando las teclas de tu escritorio, que parece funcionar. Seguro, tal vez en las revisiones semanales, mensuales o anuales, tu productividad se reflejará pobremente. Pero tus preguntas flojas se ven varias veces al día, mientras que tu productividad real se mide con mucha menos frecuencia.

Yo estaba en una posición como la tuya. Me contrataron para arreglar errores en un CMS de propiedad, mientras que el desarrollador principal (read:only) se peleaba como loco para añadir características para los clientes. Estábamos muy atrasados. La base de código no estaba en el control de versiones, y cada lado tenía su propia versión a medida. Fue un completo desastre.

Ingeniosamente, pensé que era mejor tomar 10, 20 o 30 minutos de mi tiempo y el del líder para que me explicara las cosas, en lugar de pasar medio día, un día entero, o incluso varios días para hacer ingeniería inversa de una característica para averiguar 1. qué se supone que debe hacer, 2. cómo se supone que funciona, y 3. cómo arreglar el error.

Resulta que cuando mi jefe (uno de los dos socios) se enteró de esto, pensó que no se mostraba bien en mí que no podía solucionar el código por mi cuenta, y que me estaba tomando el tiempo de nuestro precioso desarrollador principal. (El desarrollador principal parecía disfrutar hablando de cómo funcionaba su código base… en cualquier caso, no se quejó a mi jefe por ello, como me dijo). Así que dejé de hacer preguntas, y mi productividad bajó probablemente al 10% de lo que era. Me despidieron un mes después.

De todas formas, esta compañía te está diciendo, de una manera pobre, que no valoran este efecto secundario de eficiencia de tiempo y documentación. Así que no lo hagas.

Pasa un día tratando de resolver algo. Pasa un par de días… ¡pasa una semana! ¿A quién le importa? No a esta compañía. Hagas lo que hagas, no hagas preguntas, porque es algo que a ellos les importa. Ya sea que se trate de la administración, o de tus compañeros quejándose, no importa. La compañía te ha dicho qué tipo de cultura está cultivando.

Así que si piensas en tu situación, con retrasos y código de mala calidad, la caída de la productividad podría ser demasiado. En lugar de esperar a que el hacha caiga, tal vez quieras buscar un lugar que se adapte mejor a ti y a tu estilo. Algún lugar que tal vez tenga algunos comentarios y documentación de código, para empezar.

Entonces, ¿cómo terminó mi historia? Después de un período de desempleo, conseguí un nuevo trabajo. Aparte de que la base de código es mucho mejor (estamos usando un CMS estándar de la industria, estamos en control de versiones, tenemos entornos de desarrollo, puesta en escena y producción, etc.), mis compañeros son excepcionales y mi empresa fomenta el aprendizaje. Tenemos un wiki, donde compartimos nuestra información y evitamos reinventar las ruedas. Charlamos todo el día, hablando del trabajo, haciendo preguntas, haciendo lluvia de ideas, compartiendo noticias, información y descubrimientos. Empezamos proyectos para mejorar nuestros procesos, como ágiles, vagabundos, e implementando la integración continua. Nos enseñamos unos a otros y aprendemos unos de otros. Actuamos como colegas y colaboradores; no como competidores. Tenemos una orientación para las nuevas contrataciones y contratistas, que no podríamos tener sin esta cultura. Eso es algo bueno, porque en el tiempo que llevo aquí, hemos pasado de dos (yo incluido) a ocho, y también a los contratistas durante las épocas de más trabajo.

Nuestra empresa nos envía a entrenamientos, conferencias, y nos anima a tomar tiempo para clases y castings en la web. He aprendido más en este tiempo aquí que en cualquier otro período de mi carrera, especialmente en materias en las que no trabajo específicamente. Es maravilloso; he estado aquí 4 años y medio, y no veo mucha razón para irme, aparte de aprender una nueva tecnología. La cultura en mi nuevo lugar está realmente orientada hacia el aprendizaje, la comprensión y la aplicación de las mejores prácticas, lo que conduce a la productividad. Es un ganar-ganar.

En serio, hay mejores lugares para trabajar. Este no es el lugar para ti, y tú no eres la persona para ellos.

Si estás haciendo preguntas no relacionadas con el trabajo, entonces podría considerarse una charla ociosa, lo cual es malo a los ojos de tus jefes, así que deja de hacerlo.

Sin embargo, hacer preguntas relacionadas con el trabajo es algo bueno, ya que demuestra que estás interesado en tu trabajo y quieres mejorarte a ti mismo.

Si te han acusado de hacer perder el tiempo a otras personas, yo sugeriría que necesitan administrar mejor su tiempo y decirte que están ocupados en lugar de responder preguntas cuando deberían estar haciendo otras cosas. Sin embargo, una respuesta más útil sería preguntar si tienen tiempo de responder a una pregunta antes de hacerla.

Me parece que tu jefe es un poco tonto, o que sólo quiere deshacerse de ti por cualquier razón. Van a fracasar porque no documentan las cosas, lo cual es una receta para el desastre cuando su(s) desarrollador(es) principal(es) se va(n), ha(n) estado allí, lo ha(n) hecho.

Tipos de preguntas de trabajo:

1. ¿Cómo hago algo que necesito aprender para hacer el trabajo?

2. ¿Cómo hago algo que necesito aprender para hacer el trabajo, pero ya me lo han dicho?

3. ¿Cómo hago algo que está fuera del objetivo del trabajo, y sé que está fuera del objetivo?

4. ¿Cómo hago algo que está fuera del objetivo del trabajo, y no sé que está fuera del objetivo?

5. ¿Cómo hago algo que está fuera del objetivo del trabajo, y no sé que está fuera del objetivo? Preguntas divertidas y charlas.

Así que…

Puedes preguntar todas las preguntas que quieras. Puede que piensen que eres molesto, pero es un molesto bueno/inteligente. No te escribirían por esto.

Si preguntas a los números 2, entonces piensan que tienes un problema de comprensión. O simplemente te gusta hacer preguntas pero no escuchar. Esto se aguanta hasta cierto punto y envejece rápidamente.

Dependiendo de tu posición y de las cosas raras que traigas al equipo, los números 3 pueden estar bien - conoces bien un área específica, eres barato, lo que sea. Sin embargo, es mejor no preguntar a los Nº 2 después de preguntar a los Nº 3.

No hay duda de que los Nº 4 no son buenos. Puedes salirte con la tuya preguntando algunas de ellas, pero no como un nuevo empleado. Los compañeros de trabajo esperan que preguntes las #1 (y algunas #2) mucho antes de pensar en las #4. Si preguntas mucho a las 4, creen que estás en todas partes.

Esto es lo peor. Sólo preguntarle a un par de #5 puede hacer que te pongan en contra de cualquier miembro del equipo. Significa que no lo entiendes y probablemente no tienes la aptitud para entenderlo.

Hmmm… #Los números 6 dependen de la persona. Mucha gente puede preguntarle a un montón de #6s si son entretenidos o divertidos. Por otro lado, si no eres el número 6, puede ser muy malo, especialmente si preguntas a los números 2-5.

Si piensas en ti mismo, ¿por qué no pueden ser amables conmigo y ayudarme si tengo problemas y pregunto a los números 2-5 todo el tiempo? Porque pueden contratar a alguien que sepa más y no haga preguntas estúpidas. Si yo fuera tú empezaría a prestar más atención, tal vez incluso llevando un bloc de notas contigo todo el tiempo, y cuando alguien responde a algo te aseguras de estar 100% seguro de que lo entiendes o pides una aclaración en el acto.

Esta respuesta es sobre cómo tomar la retroalimentación (las otras respuestas ya cubren muy bien cómo hacer las preguntas).

Aunque también me regañaron por “ir por el camino equivocado” al tratar de resolver un problema con el que no estaba familiarizado en lugar de preguntarle a alguien que sí lo estaba. Cuando pregunté sobre la contradicción, mi gerente y RRHH dijeron que sólo necesitaba usar un mejor juicio sobre cuándo hacer preguntas. Nunca me di cuenta de que hacer preguntas podía ser tan peligroso.

Esa fue una mala reacción de su parte. Imagínese en su lugar por un momento. Sabes que algún empleado tiene un mal desempeño, y les dices lo que necesitan mejorar. Sin molestarse en pensar en lo que les estás diciendo, sin mostrar ningún interés en tu feedback, y mucho menos disculparse por no cumplir las expectativas, ese empleado afirma incorrectamente que te estás contradiciendo.

Cuando recibas feedback, en particular si es negativo, primero debes escuchar, luego buscar la comprensión (haciendo preguntas aclaratorias si es necesario), y sólo entonces responder.

Eso es porque, a menos que lo hayas estropeado intencionadamente, tú y tu jefe no están de acuerdo en si lo has estropeado. O su jefe está equivocado, o usted lo está (o ambos). Debe considerar la posibilidad de que sea usted, porque es muy improbable que su jefe esté completamente equivocado, y usted tiene toda la razón - e incluso si la tiene, sólo puede convencer a su jefe de que está equivocado mostrándole donde está equivocado, y eso requiere escucharlo también.

También podrías pedir consejo sobre cómo podrías hacerlo mejor.

Por ejemplo, después de escuchar que estás haciendo demasiadas y muy pocas preguntas, podrías haber preguntado:

Así que he hecho ambas preguntas innecesarias y no he hecho las preguntas necesarias. ¿Cómo debo determinar qué preguntas son necesarias? Es decir, ¿qué tipo de preguntas debería hacer más y qué tipo de preguntas debería hacer menos?

La siguiente discusión de hechos probablemente habría revelado lo que necesitas hacer para mejorar.

¿Es esto habitual? ¿No se supone que la nueva persona en una empresa no debe ser curiosa o hacer preguntas que no estén inmediatamente relacionadas con su trabajo?

Hasta qué punto el hacer preguntas es esperado o deseado difiere entre los lugares de trabajo. Es posible que desee adaptarse a la cultura de su lugar de trabajo, lo que puede descubrir observando a sus compañeros, tomando nota de cómo reaccionan las personas a sus acciones (¿están molestos por sus preguntas, o encantados con ellas?), o pedirles su opinión (“¿Estuvo bien que yo preguntara eso?”).

Creo que si eres joven como yo, tu mentalidad es ahorrar tiempo y encontrar la respuesta y luego pasar al siguiente problema. Sin embargo, encuentro que con las generaciones mayores eso no es una preocupación ni una prioridad para ellos. Así que sí, tomar una hora para resolver un problema es demasiado corto para alguien mayor, sin embargo puede parecerte demasiado largo. Sugiero observar la brecha generacional y seguir el ejemplo aunque no estés de acuerdo. Con el tiempo serás más rápido en la resolución de problemas con más experiencia.

En cuanto a meterse en problemas por hacer preguntas, trato de usar la explicación de Quiero ver cómo se debe hacer, o seguir los estándares de la compañía. Una vez más he notado que en las generaciones más antiguas esto es irritante por alguna razón. Creo que las personas mayores tienden a pensar que resolví esto por mí mismo y que no recibí ninguna ayuda, así que están menos dispuestos a ayudar. También se sienten interrumpidos. Como alguien mencionado anteriormente trata de encontrar el momento adecuado para pedir ayuda, mientras acaricia el ego, IE “Escuché que eras el tipo al que había que acudir para esto…” “Alguien dijo que usted es el experto en….” Con suerte, eso hará que pasen por alto una interrupción y estarán más dispuestos a ayudar ya que usted les dio algo que probar. Tenga cuidado con ese último consejo, ya que estoy seguro de que en algunos casos podría resultar contraproducente.

Me resulta difícil definirlo exactamente, pero he trabajado con varios jóvenes desarrolladores, y algunos de ellos hicieron preguntas que fueron muy satisfactorias de responder, y otros no. Responder a tus preguntas distrae a tus compañeros de trabajo, y eso está bien, si algo bueno sale de ello y la compañía se beneficia a largo plazo. Eso significa que necesitas preguntar a la persona correcta, hacer la pregunta correcta, y llegar a un lugar donde hayas ganado comprensión que te permita hacer un progreso significativo. Si tienes un don para eso, la gente sentirá que el tiempo que pasa ayudándote es tiempo bien empleado, y que eres un valioso colaborador. Si no, es probable que te encuentren molesto en su lugar.

Obviamente si hay muchas cosas que no sabes, eso te pone en una situación delicada, pero la actitud y la aptitud hacen una gran diferencia. Nadie espera que lo sepas todo, pero sí se preocupan por cómo lo manejas. Otros aquí ya han cubierto las cosas que puedes hacer para sacar el máximo provecho de tu dinero cuando tienes a un dev dev dev devenido mayor encasillado, así que no repetiré sus consejos; sólo intento arrojar algo de luz sobre los sentimientos de tus compañeros de trabajo que te llevaron a esta situación, para que puedas entenderla y evitarla en el futuro.

Esto es casi más una sugerencia para su empleador, pero tal vez usted podría hacer que funcione para usted.

¿Le asignaron un mentor cuando empezó? Darle a un nuevo empleado un mentor asignado, alguien a quien puedan acudir con sus preguntas es una buena idea. Esto les da alguien con experiencia en la compañía y evita que el nuevo empleado moleste constantemente a los demás. :-)

El mentor también conocerá a las personas adecuadas para preguntar y los lugares adecuados para buscar cosas como la documentación. Por ejemplo, algunos proyectos pueden tener documentos de Google Doc, otro los tiene en un servidor de archivos interno y un tercero los tiene comprometidos dentro del repositorio de fuentes. Mientras que otros proyectos no tienen ningún tipo de documentos.

Otro consejo es que cuando empieces a trabajar en un nuevo proyecto pide una visita. Un bloque sólido de cuatro horas de tiempo con usted y una persona experimentada puede ponerle al día sin requerir esas cuatro horas de tiempo como interrupciones repartidas en varios meses.

Una cosa a recordar: el código es como la gramática. La gente puede saber que el suyo apesta pero no le gusta que se lo digan. Por ejemplo, si señalo que repetidamente escribes mal “juicio”, puede que te molestes porque no estoy añadiendo nada constructivo. Bueno, lo acabo de hacer de todas formas :)

Pero empareje eso con el hecho de que muchos programadores experimentados tienden a adoptar una actitud de diva. Lo que pretendes como preguntas sinceras enraizadas en la lógica puede ser muy amenazante para ellos. He trabajado con innumerables ejemplos (y yo mismo puedo ser uno) que han mantenido el mismo código de mierda que no ha sido relevante durante 15 años. Saben que hay una mejor manera de hacerlo hoy en día, pero no tienen interés o motivación para aprender cosas nuevas, por lo que su mera presencia como la próxima generación es una amenaza para ellos. Cuando hagan el acto de la prima donna, ríete de ello para ti mismo y recuerda que tú eres el que tiene el verdadero poder… tienes muchos años por delante para trabajar con la tecnología del futuro y la dirección definitiva que tome tu carrera está todavía en tus manos. Ese no suele ser el caso de los esnobs experimentados.

Coincido con otros que mencionaron que esto no suena como una buena incubadora para los aspirantes a desarrolladores. Sin embargo, esto es común. Toma tiempo y experiencia identificar tu nicho, encontrar un empleador que sea bueno para ti, y determinar qué es lo más importante para ti. Así que paga tus cuotas allí, toma tus bultos, planifica tu carrera y sal de ahí después de haber trabajado unos cuantos años de forma sólida. Por ahora, siga el consejo por lo que vale la pena, no se preocupe por el PIP y siga recordándose a sí mismo que su situación actual es sólo un medio para un fin. Tus supervisores esperan que llegues y salgas a tiempo como si trabajaras en Wendy’s. No es así como tiene que ser, incluso para los nuevos desarrolladores sin experiencia, para que pueda haber un futuro mucho más brillante por delante en otros lugares.

Intenté decirles exactamente lo que les he dicho a ustedes aquí. Se enojaron conmigo por discutir con ellos “con uñas y dientes” y no tomar bien su consejo. Dije que sólo intentaba decir mi punto de vista… se molestaron más.

Creo que puedo explicar por qué se molestaron: simplemente no quieren retroalimentación. Tu gerente no te ha invitado a dar tu opinión, simplemente dijo, con este plan de “necesita mejorar”, que tienes un mal comportamiento y necesitas arreglarlo, “por tu propio bien”.

¿Quién decide qué es un mal comportamiento? La gente que te paga y que puede despedirte, solamente. Cuando criticas sus decisiones, se molestan, ya que te pagan por seguir sus órdenes, no por cuestionarlas. No son “jueces imparciales”, son los que te pagan. Y si los criticas en el momento en que te dan una alerta seria y formal “cambia o vete” (lo que ellos llamaron “consejos para mejorar”), esto puede llevarlos a pensar que no tienes redención.