Cómo guiar a un desarrollador junior

Este título es un poco amplio, pero es posible que tenga que dar un poco de historia antes de poder hacer mi pregunta correctamente.

Sé que preguntas similares se han preguntado aquí ya. Pero en mi caso no estoy preguntando si debería ser mentor de alguien o si la persona es una buena opción para ser un desarrollador de software. Ese no es mi lugar para juzgar. No me han preguntado directamente, pero es evidente que yo y otros colegas desarrolladores senior deben ser mentores de los nuevos desarrolladores que comienzan aquí. No tengo ningún problema con esto y, en muchos casos, me da una nueva perspectiva sobre las cosas y termino aprendiendo en el proceso. Además, recuerdo cuán beneficioso fue al comienzo de mi carrera cuando alguien se tomaba un tiempo para enseñarme algo.

Cuando digo "nuevo desarrollador", podrían estar en cualquier lugar, desde recién salidos de la universidad hasta tener uno o dos años de experiencia.

Recientemente hemos tenido personas que comienzan aquí que parecen tener una actitud hacia el desarrollo / programación que es diferente a la mía y que me es difícil de conciliar; extraen suficiente información para realizar la tarea pero realmente no aprenden de ella. Me encuentro repitiendo los mismos problemas con ellos. Entiendo que parte de esto podría ser una cuestión de personalidad, pero siento que es mi trabajo hacer mi mejor esfuerzo y sacarlos del nido mientras están bajo mi ala, por así decirlo.

¿Cómo puedo impartir suficiente información para que aprendan pero no den tanto como para resolver el problema?

O quizás:

¿Cuál es la respuesta adecuada a las preguntas que están diseñadas para tomar el camino de menor resistencia y, en esencia, obligarlas a aprender en lugar de tomar el camino fácil?

Estas preguntas son probablemente preguntas de enseñanza más generales y no tienen mucho que ver específicamente con el desarrollo de software.

Nota: No puedo opinar sobre en qué tareas están trabajando. La administración reparte la tarea y podría ser cualquier cosa, desde una solución de error muy simple hasta iniciar una aplicación completa por sí mismos. Si bien esto no es ideal de ninguna manera y obviamente presenta su propio conjunto de desafíos, creo que es un tema que es mejor dejar para otra pregunta. Entonces, lo mejor que puedo hacer es ayudarlos con el problema en cuestión e intentar ayudarlos a dividirlo en problemas más simples y también verificar sus registros de confirmación y señalar los errores que cometieron.

Mis objetivos principales son:

• Ayúdelos y bríndeles las herramientas que necesitan para comenzar a ser más autosuficientes.
• Guíelos en la dirección correcta y rompa los malos hábitos de desarrollo desde el principio.
• Disminuye la cantidad de tiempo que paso con ellos (el tipo de personalidad descrito anteriormente tiende a necesitar mucho más tiempo individual y no funciona bien por mensajería instantánea o correo electrónico. Si bien eso generalmente está bien, no siempre puedo detener lo que ' Estoy trabajando, rompo el paso y les ayudo a depurar un error en cualquier momento; tengo mis propios proyectos que necesito hacer).

Hubo una vez una pregunta por aquí que contenía este tipo de información, y la pieza que más me llamó la atención fue no tocar su teclado

En resumen, dígale a su hijo cómo lograr lo que está tratando de hacer, pero no lo haga por ellos.

Pero además de eso, aquí hay algunos otros consejos:

• Fomentar Google (o cualquier otra herramienta de búsqueda). Si sabe que la respuesta se puede encontrar en línea fácilmente, dígales que la busquen en lugar de decirles la respuesta. En última instancia, desea enseñarles cómo enseñarse a sí mismos , y no hacer que dependan de usted.
• Esté disponible para responder preguntas. Si alguna vez no está disponible o no desea ser interrumpido, déjelos en claro que deben mantener sus preguntas hasta un tiempo específico.
• Haga revisiones de código regularmente para decirles lo que están haciendo bien / mal. Use esto como una oportunidad para señalar las mejores prácticas
• Comience temprano con las mejores prácticas. Es mejor tomarse un tiempo extra para enseñarles la forma correcta, que intentar cambiar sus métodos más adelante.
• Comience temprano con la planificación / documentación de lo que van a hacer en lugar de dejar que comiencen escribiendo código.
• Esté abierto a aprender de ellos. Probablemente pasen más tiempo del que usted aprende, y es posible que aprendan algo que usted no sabía.

• Ayúdelos a aprender de sus errores. Habrá errores, así que asegúrese de mostrarles que los errores son parte del aprendizaje y que deben usarlos como una oportunidad para aprender.

• (De RuneFS a continuación) En lugar de decirles cómo hacer algo, trate de ayudarlos a resolverlo por sí mismos. Esto ayudará a mejorar su capacidad de resolver lógicamente un problema y aumenta su capacidad de aprendizaje.

• (De RuneFS a continuación) En lugar de decirles lo que hicieron mal, dígales cómo pueden mejorarlo. Asegúrese de incluir por qué su camino es mejor que el de ellos. Esto aumentará su confianza en lugar de debilitarla. Por supuesto, si no te están escuchando, entonces no tengas miedo de decirles que lo hagan de la manera correcta :)

Tengo alrededor de 4 años de experiencia, y puedo decirle desde mi experiencia como desarrollador junior lo que desearía tener en términos de tutoría. Parece que en realidad estás describiendo el tipo de desarrollador que era cuando comencé :)

Esencialmente quieres animarlos a aprender. Algunas personas piensan que después de terminar la universidad, ya no tienen que leer libros ni aprender más. Este tipo de actitud puede llevar a buscar atajos y simplemente "hacerlo".
Consígalos "El programador pragmático" y pídales que lo lean. Este libro les ayudará a darse cuenta de que la programación es un oficio / carrera y no solo un trabajo. Recomiende libros para que lean cada trimestre más o menos. Ayúdelos a construir su "cartera de conocimientos" (como se menciona en Pragmatic Programmer). Recomiendo Safari Books Online, que tiene muchos libros de CS / Programming.

Con su cartera de conocimientos, sabrán dónde buscar si tienen problemas. Enséñeles dónde mirar. Yo mismo descubrí la utilidad de StackOverflow recientemente (y como saben, es mejor mirar aquí que solo Google).

Parece que no puedes pasar mucho tiempo con ellos, pero la programación de pares es muy útil. Si no puede hacer eso, entonces al menos revise el código usando CodeCollaborator u otra herramienta similar. No toman tanto tiempo como crees que lo hacen.

Las pruebas unitarias también son muy importantes. Pueden revelar rápidamente malas prácticas de desarrollo, especialmente si combina eso con una integración continua.

Haga preguntas iniciales para dirigirlo a las respuestas en lugar de simplemente decirle (bueno, puede decirle algunas cosas básicas como cuál es el nombre del servidor y qué base de datos almacena la información). Muéstrele cómo encontrar sus respuestas.

Y nunca reescriba su código cuando esté mal, dígale qué está mal y espere que lo arregle. Obtienes lo que esperas. No ayudas a nadie haciéndole depender de ti.

Las revisiones de código también son críticas. Y si empareja el programa, deje que tenga el teclado con frecuencia. Incluso si le está diciendo qué escribir, aprenderá de escribir más que aprenderá sentado a su lado mientras programa.

Tome algunos ejemplos del software que son típicos de cómo está estructurada la aplicación y repáselos con él línea por línea, asegurándose de que comprenda por qué se necesita cada línea y qué hace. Es su trabajo asegurarse de que conoce los estándares de codificación y cómo está organizado el código y por qué usted (como empresa) hace las cosas de la manera que lo hace.

Si tiene una forma diferente de sugerir, escuche con atención. En primer lugar, puede tener razón. En segundo lugar, escuchar le dirá dónde está su debilidad en la comprensión si lo que sugiere no es práctico. Además, las personas tienden a respetarte más si las escuchas. Cuando se equivoca, vuelve a las preguntas principales para que vea por sí mismo por qué la idea está equivocada. SI incluso está cerca de estar en lo cierto, vaya con sus ideas a veces, nada es más desalentador que siempre que le digan que sus ideas no valen nada.

Haga preguntas sobre sus antecedentes. Él puede saber algunas cosas con las que no ha tenido la oportunidad de trabajar. Si es así y surge la oportunidad de usarlos, hágale preguntas sobre su conocimiento.

Si su aplicación es antigua, probablemente tenga algunas "trampas" engañosas que alguien nuevo no tendrá forma de conocer. Entonces, cuando está comenzando a trabajar en áreas donde tienes una o más de estas trampas, puedes contarle sobre ellas ya que se está acelerando antes de codificar, luego mira para ver si cayó en la trampa cuando codificó.

Finalmente, obtienes respeto en parte dando respeto. Trate a todas las personas a las que asesora con respeto. No los hagas sentir menospreciados o estúpidos. Te escucharán mucho mejor si los tratas con respeto.

• Siempre me aseguro de que el desarrollador quiera mi ayuda, y tengo mucho cuidado de no profundizar en las explicaciones de lo que su paciencia puede tolerar. ¡Como todos, amo el sonido de mi propia voz!
• Los trato como iguales, y me aseguro de pedirles su opinión tan a menudo como sueno.
• Atrápalos haciendo algo bien y hazles saber.
• Siempre aprendo algo cuando hago esto bien: sobre mi oficio, sobre mi profesión, sobre el desarrollador y sobre la enseñanza.
• La primera lección siempre es: cuándo saber que lo has intentado por tu cuenta durante demasiado tiempo. Muchas personas se enorgullecen de encontrar sus propias respuestas y gastan un tiempo valioso en círculos.

Soy un desarrollador junior y creo que mi mentor trata muy bien estas cosas. En general, me dirá un par de formas de hacer algo, pero no cómo hacerlo. Luego solía sentarme allí y probar en ambos sentidos, y decidir cuál era la solución más limpia para el problema.

Además, si alguna vez estaba haciendo algo que podría ser útil para mí, me llamaría solo para dar una idea de lo que estaba haciendo y por qué.

Esto resultó en una pequeña cantidad de tiempo que pasaba conmigo y esencialmente significaba que tenía que aprender las respuestas correctas y cómo implementar las cosas. Por supuesto, si alguna vez me atasco, él estaría allí para ayudar, pero esto fue un puñado de veces. Después de solo 5 meses trabajando con él, probablemente obtuve más conocimiento de las cosas que la totalidad de mi curso universitario.

Lo importante para recordar es que solo soy un individuo y esto funcionó bien para mí debido a cómo soy y cómo es él. Se trata de encontrar una estructura adecuada que los ayude a ambos.

Dependiendo de la tarea asignada, estaría tentado a adoptar algunos enfoques diferentes:

• Pregúnteles qué intentarían después para completar la tarea. Esto puede dar una idea de dónde, desde la categoría "No sé qué hacer" hasta "Bueno, lo intentaría, pero ..." son en términos de tener su propia idea que puede ser útil como punto de partida .

• Eche un vistazo rápido a lo que quieren hacer y ofrezca sugerencias para que puedan resolver el problema. Esto es en lugar de dar la respuesta de "Solo saca esta línea de código", sugiere que miren lo que hay allí y todo es necesario.

• Si la primera pareja no va a funcionar, entonces intentaré que sigan mis instrucciones sobre qué hacer para resolver el problema. Este es el siguiente paso en la progresión donde, si no tienen idea de por dónde empezar y las sugerencias no funcionan, este es el siguiente punto.

• Por último, si nada más funciona, yo haría el trabajo por ellos, pero trataría de evitar esto tanto como sea posible, ya que así es como se crean problemas como que una persona conozca íntimamente un sistema, ya que alguien puede considerar descargar el trabajo sobre mí para este sistema que parece que conozco muy bien.

Una cosa que hice aquí en mi trabajo que encontré realmente útil fue configurar un foro (es decir, PHPbb) para preguntas y respuestas internas, y seguir la regla de que si la pregunta y / o la respuesta lleva más de 5 minutos, debería ser preguntó y respondió a través del foro. Los beneficios:

• Obliga al desarrollador junior a plantear claramente la pregunta, lo que hace que sea más fácil responderla, sin mencionar los momentos en que encuentra la respuesta por sí mismo, simplemente pensando un poco más en ello.
• Evita preguntas duplicadas, ya que el desarrollador junior debe comenzar buscando preguntas similares ya hechas
• Ayuda a construir una base de conocimiento que será útil para futuras contrataciones y para documentar muchas cosas pequeñas que podrían perderse en el tiempo.

Voy a romper la tendencia aquí y sugerirle que no intente alentar a los desarrolladores junior a aprender cómo encontrar las respuestas por sí mismos. Esto parece un juego de "Lo tengo pero no te lo voy a dar".

En cambio, únete a ellos para encontrar la respuesta. De todos modos, lo buscarás en Google, así que hazlo mientras estás sentado con ellos. Ellos entenderán que esta es la forma de encontrar respuestas.

Si trabajas en estrecha colaboración con ellos, aprenderán cómo usar el IDE correctamente; Cómo normalizar una base de datos; cómo SECAR tu código ... todo lo que sabes que vale la pena saber.

Las claves son: una: estar disponible para que puedan ver cómo trabaja. Y dos: decir en voz alta por qué estás haciendo lo que estás haciendo. "Este código se repite, así que voy a refactorizarlo", no "usar el método de extracción en esas tres líneas".

Solo he tenido que entrenar a un programador junior una vez. Fue para ayudar a mantener un sistema que había construido. El objetivo era finalmente entregarle todo el sistema.

Después de un corto período en el que me hizo sombra, lo tiré al fuego. Le asignaría casos y esperaría que se completaran. Si tuviera problemas, le pediría que explicara cuál era el problema y dónde había mirado. Luego le aconsejaría en los términos más generales, dónde buscar a continuación. (Qué aplicación, tal vez qué módulo mirar, etc.). Nunca lo dejaría tambaleándose, pero tampoco haría nada del trabajo. Solo proporcione dirección. Si todavía tuviera problemas, simplemente me encogería de hombros y diría "Comienza a rastrear el código". Y cada vez que decía eso, se encogía de hombros, sabiendo que estaba haciendo un ejercicio tedioso. Lo volvía loco, porque ambos sabíamos que probablemente podría encontrar el problema en 10 minutos si simplemente me despegaba y ayudaba.

Años más tarde, se ha movido a cosas más grandes y ahora está entrenando a sus propios juniors. Y su historia favorita es cómo siempre le diría que "rastreara el código", y cómo esos ejercicios de rastreo de código fueron cruciales para convertirlo en el programador que es hoy.

Cada vez que se me haga una pregunta que sé que se puede resolver mediante una búsqueda rápida en Google, encontraré documentación o un artículo relativo y se la transmitiré a la persona que hace la pregunta.

Saber dónde buscar las cosas es una habilidad importante, y a veces es más difícil de lo que pensarías para un nuevo desarrollador. Es posible que ni siquiera sepan lo que están buscando, y aquí es donde debe ayudarlos.

Una vez en su mano, los artículos y la documentación los obligarán a leer sobre la solución en lugar de buscar a otros desarrolladores para obtener una respuesta rápida.

Esto logrará lo siguiente:

• Aliviando un poco la carga de los desarrolladores experimentados.
• Obligar al nuevo desarrollador a aprender.
• Felicidad para todos.

A veces solo tienes que darles un poco de amor duro, especialmente si no parecen querer aprender. No les des la respuesta, pero asegúrate de apuntarlos en la dirección correcta.

Recomendaría comenzar a dar partes de las tareas reales que tiene y hacer todo lo posible para poder usar su código. En otras palabras, entrénelo como reemplazo de usted mismo.

De esta manera, se comprometerá a asignar tiempo para trabajar con junior y él podrá ver la "vida real". Al trabajar en tareas reales y escuchar comentarios enérgicos, podrá acelerar rápidamente.

He enseñado a la gente varias materias en el pasado, y lo que más me ha llamado la atención es cómo la mayoría de las personas no tienen habilidades para resolver problemas . Es decir, si les muestra una solución exacta, pueden reutilizarla más tarde si reconocen o se les dice que la necesitan.

Pero, muy pocas situaciones en la vida son así. A menos que su trabajo sea una "fábrica mental" que implique pegar el widget A al widget B con la herramienta C, entonces necesitará tener un par de elementos:

• Una caja de herramientas de habilidades y herramientas.
• Un método para resolver problemas.

Por ejemplo, eche un vistazo a esta respuesta que publiqué . Eso cubre el método de resolución de problemas que muchas personas no tienen . La universidad no le enseñó esto a nadie en el programa CompSci, ya lo sabías o lo descubriste tú mismo.

Una vez que el desarrollador junior comprende cómo resolver problemas, necesita un conjunto de herramientas para hacerlo.

• Depurador (la universidad nunca mencionó esto)
• Perfiladores
• Editor de texto
• Shell (y utilidades asociadas)
• Recursos (libros, google, SO, páginas de manual)

Determine qué le falta al desarrollador junior y puede ayudarlo a mejorar. Solo tenga en cuenta que algunas personas realmente no están interesadas en aprender cómo resolver sus propios problemas y solo quieren que se les entregue una solución "obvia paso a paso". Estos no son buenos desarrolladores.

Con suerte, no tendrás ninguno de esos. Si lo hace, tenga en cuenta que no importa cuánto tiempo pase, no todos se ayudarán a sí mismos. Requeriría esfuerzo, y es más fácil pedirte que lo hagas por ellos. Es similar al problema de bienestar y se explica por la teoría económica.

El interés propio ilustrado dice que las personas tomarán lo que ven como la opción más ventajosa en cualquier situación. Tenga en cuenta que es lo que ven. Veo lo más importante como ser autosuficiente y aprender. Entonces, hago las cosas yo mismo. Pero otros pueden ver que solo necesitan proporcionar un código de trabajo antes de la fecha límite. Entonces buscan el método menos costoso para hacerlo. Al proporcionarles "obsequios" necesitan gastar el menor esfuerzo para completar su objetivo. Hasta que retire esa muleta, no crecerán.

Su organización como la describe es muy diferente a la mía. Estoy en control de mi trabajo junior y lo veo como mi papel de juzgar. Entonces mucho es diferente.

Una cosa que me gustaría aconsejarle que haga de todos modos, es visitar su escritorio con frecuencia en las primeras dos semanas, especialmente. Algo así como tres veces al día la primera semana, disminuyendo gradualmente.

El mensaje que intento enviar de esta manera es que me importa su productividad. Me aseguro de que no se atasquen. Me aseguro de que siguen las reglas y no reinventan la rueda. Les enseño a comprometerse con la mayor frecuencia posible. Aprenda a desarrollar de forma incremental y piense en el diseño de forma incremental.

Mi peor pesadilla son los desarrolladores que cada día te dicen que solo necesitan un día más para realizar su función. Después de semanas de retraso, obtienes un diseño demasiado complicado, que hackeado desde el principio por su autor. Se agregan características de errores adicionales no solicitadas en la mezcla para compensar el retraso y porque fueron un efecto secundario libre del diseño.

Creo que muchos desarrolladores están inclinados a este enfoque. Si se queda solo con una tarea complicada, es una reacción natural tratar de demostrar que puede hacerlo por su cuenta. Pero es la respuesta incorrecta. La calidad es trabajo en equipo, y cuanto antes aprendan, mejor.

Las otras respuestas son muy buenas, pero quería comentar esta oración.

Recientemente y en el pasado hemos tenido personas que comienzan aquí que parecen tener una actitud hacia el desarrollo / programación que es diferente a la mía y difícil para mí reconciliarme; parecen extraer la información suficiente para realizar la tarea pero realmente no aprenden de ella.

La mayoría de la gente quiere saber cómo hacer algo. Esta actitud está bien al principio cuando estás abrumado por aprender cosas nuevas y aprender a hacer tu trabajo.

Raras son las personas que quieren saber por qué se hace algo. Estas son las personas que los gerentes inteligentes quieren, incluso si a veces son difíciles de manejar.

Algunas personas codifican para que se les pague bien. Otros aceptan felizmente dinero para codificar. Es mucho mejor trabajar con personas apasionadas por el diseño y la codificación. Desafortunadamente para mí, también fue bastante raro. Al menos hasta que encontré Stack Overflow.

Una cosa a tener en cuenta, para aquellos que se entusiasman ante la perspectiva de hacer todo este asesoramiento para desarrolladores junior: asegúrese de que su gerencia entienda lo que está sucediendo.

Enseñar a otras personas es un trabajo duro, en general. Requiere enfoque y concentración, planificación y esfuerzo, y sobre todo toma tiempo. Cualquiera sea el enfoque que adopte, si está enseñando y asesorando de manera seria, va a comerse su tiempo.

• Si su gerencia contrata a desarrolladores menos experimentados con la expectativa de que los desarrolladores senior asuman tareas de capacitación, asegúrese de que sea explícito. Descubra cuál será el marco de tiempo y asegúrese de que sus cronogramas de desarrollo reflejen el tiempo y el esfuerzo dedicado a la capacitación. Asegúrese de que la gerencia tenga algunos planes para evaluar el éxito de los esfuerzos de mentoría en algún momento acordado. (Por supuesto, si están contratando desarrolladores que necesitan enseñanza y tutoría, pero la administración no lo está planeando, entonces obviamente es un problema grave).

• No todos son buenos maestros o mentores, y no todos quieren serlo. No quiero sonar crujiente o amargo; Me gusta mucho enseñar. Pero es una tontería esperar que todos sean buenos en eso (a pesar de sus propios talentos), ni podemos esperar que todos disfruten del proceso (recuerden, no es fácil). Además, si usted es un desarrollador senior que no disfruta de la tutoría, o si realmente siente que es una mala elección para un maestro o mentor, asegúrese de que su gerencia comprenda que un plan que lo involucra a usted haciendo esas tareas es un plan con defecto grave Por otro lado, si quieres ser bueno enseñando o guiando, eso también es algo para comunicarte.

• Si la enseñanza y la tutoría son cargas compartidas de manera desigual entre la población de desarrolladores senior, asegúrese de que esas tareas sean reconocidas como valiosas para la compañía de la misma manera que se reconocen los logros de desarrollo de productos.

Te voy a echar un vistazo.

Básicamente, aprendo bien cuando:

1. Me dan una introducción formal al tema. Nunca puedo aprender algo nuevo sin alguien (sí, una persona) respondiendo todas las preguntas que tengo sobre los nuevos conceptos. Una vez que tengo eso hecho yo ...
2. Consigue un libro. Como mi mentor, deberías tener exactamente el mismo libro, así que siempre podría decir algo como "Oye, qué significa eso en el capítulo cuatro, página 72, párrafo 6 ..." y sabrás exactamente de lo que estoy hablando acerca de. Una vez que tengo un libro, soy más independiente y realmente solo hago preguntas. Entonces yo...
3. Comience un proyecto juntos. Esta es la parte más importante del proceso. Aquí es donde puedes comenzar a enseñarme sobre las mejores prácticas, algoritmos, características del lenguaje difíciles (pero útiles), etc.

Ahora dijiste que tienes tus propios proyectos que cuidar y que no siempre tienes el tiempo. Es por eso que fuimos bendecidos con StackOverflow . Estoy seguro de que estarían encantados de ayudarlo a depurar su código. En cuanto a las preguntas que no están sobre el tema allí, puede preguntar aquí.

Dicho esto, todavía tienes que trabajar con él de forma regular. Una "línea de tiempo" general debería ser:

• 1 mes. Debe saber la sintaxis básica. Todavía no es independiente cuando se codifica.
• 3 meses. En este punto, él debería conocer la sintaxis como el dorso de su mano, y debería ser capaz de resolver problemas simples con facilidad. Él es mucho más independiente, pero aún no está allí.
• 6 meses. Deben saber, además de todo lo demás: mejores prácticas, algoritmos comunes, etc. Debería poder hacer un proyecto él mismo, tal vez con un poco de ayuda de SO.

Además de lo anterior, la forma más fácil de hacer que alguien sea independiente es darles un tema difícil de aprender y no darles nada para ayudarlos, excepto Internet. Se verá obligado a aprender solo y sabrá lo que hace.

Después de que sepa lo que quieres que sepa, libéralo. Permita que se vaya y aprenda lo que quiere aprender (siempre puede decir que quiere que siga trabajando en ese idioma).

¡Espero que esto ayude! Por cierto, que lea esto: enséñese a programar en diez años .

Haga una distinción entre los niveles de aprendizaje inferior y superior. Si se trata de conocimiento, comprensión o aplicación, no tengo problemas simplemente dándoles la respuesta, con una breve explicación de cómo pueden buscarla la próxima vez. Esto no es escuela, no es trampa, y no confiarán en ti de esa manera para siempre. Simplemente no planee hacer nada más durante la primera semana o dos, para que no lo moleste cuando no lo haga.

Después de las primeras dos semanas, si se interrumpe con demasiada frecuencia con este tipo de preguntas, use un temporizador de pomodoro y no responda ninguna pregunta hasta el final de un pomodoro. Google es fácil para usted ahora porque sabe qué buscar. A menudo no lo hacen, por lo que si debe decirles que busquen algo en Google, dígales qué términos de búsqueda usar para obtener los mejores resultados.

Si un problema está relacionado con el análisis, la síntesis o la evaluación, dedico más tiempo al tema. Aquí es donde proporciona su razonamiento detrás de sus decisiones y les ayuda a llegar a las mismas conclusiones. Esto se presenta con mayor frecuencia en cuestiones de diseño y estilo. No solo les digas que usen un cierto diseño, muéstrales por qué es superior a su primera opción. Permítales cometer errores y déjelos corregir sus propios errores.

No he visto a nadie aquí mencionando a mi héroe personal, Randy Pausch .

Creo que puede ser beneficioso para cualquiera que realmente esté haciendo, enseñando o guiando programas (o incluso para cualquiera que quiera vivir una vida significativa). Usted y / o sus colegas pueden encontrar que mirar estas conferencias vale la pena el tiempo que yo tengo, en

• alcanzar sus sueños (él era un profesor y esto está muy relacionado con la motivación de los demás), y
• la gestión del tiempo .

Yo, como desarrollador junior, siento que si me encuentro con un problema, sería mejor obtener la respuesta de inmediato y pasar tiempo entendiendo cómo se resolvió.

Estoy pagado mi empleador no espera pagarme por aprender. Se espera que haga un trabajo al final del día. No tiene sentido perder el tiempo en un entorno laboral, intente descubrir una solución. Eso es algo que recogeré a tiempo, con suerte rápidamente si soy bueno en lo que hago.