¿Qué hacer cuando te enfrentas a una tarea de programación que nunca has hecho?

Comencé mi carrera como desarrollador .NET hace 3 meses y después de un largo plan de capacitación sobre diversas tecnologías, patrones y conceptos, los desarrolladores que me supervisaban decidieron que estaba listo para unirme a uno de los muchos proyectos que maneja la compañía.

Estoy muy emocionado de finalmente poder comenzar a codificar. El equipo al que me he unido es bastante pequeño por ahora porque comenzamos con un nuevo proyecto, lo cual es genial porque me involucro en todo el ciclo de vida del proyecto. Es un proyecto SPA basado en la web con una copia de seguridad que utiliza ASP.NET MVC / ASP.NET Web API y en el front-end el marco de trabajo de Durandal y las bibliotecas relacionadas.

Mi problema es que después de reunirme con mis colegas y establecer las tareas y estimaciones para el próximo mes, me encuentro en una posición que no sé si soy capaz de asumir alguna de las tareas.

Nunca he realizado ninguna de las tareas creadas y no sé cómo debo proceder.

Por ejemplo, una de las tareas creadas es crear un mecanismo genérico de manejo de errores para toda la aplicación.

¿Cómo suele proceder uno cuando se enfrenta a tareas que nunca ha realizado?

Hay varias cosas que puede y debe hacer para prepararse para la tarea:

• Piensa en el problema y dibuja algunos diagramas. Asegúrese de saber cuál es el problema que está tratando de resolver.
• Investigue sobre lo que está tratando de hacer. Internet es una valiosa fuente de información. No estoy diciendo que pregunte a Stack Overflow: estoy diciendo que investigue cómo otras personas ya han resuelto un problema como el suyo o lo han abordado. Esto es lo que se le ocurrió a Google: "Manejo de excepciones como una preocupación de todo el sistema" . Personalmente, siempre trato de aprender de los demás.
• Por último, y esto podría ser lo más importante, hable con las otras personas de su equipo para obtener más aclaraciones y orientación sobre qué hacer. Siempre quiero ver a nuevos ingenieros venir a pedir orientación sobre proyectos.

No saber cómo hacer algo nunca terminará realmente. Todos los días me encuentro con problemas que nunca antes había abordado. Tener la capacidad de descubrir cómo resolver nuevos problemas es extremadamente importante. Incluso los problemas antiguos nunca son totalmente antiguos: en la programación, casi siempre hay un nuevo giro o una solicitud para que su solución funcione de una manera nueva o diferente.

Por eso soy ingeniero; Me encanta descubrir cosas nuevas.

Nunca dejes de aprender cosas nuevas. Aprender es lo que te hace mejor.

No existe una solución perfecta, pero hay algunas cosas que pueden ayudar:

• Divida las tareas en las unidades más pequeñas posibles: divídalas hasta que tenga cosas que pueda hacer.

• Repita la tarea o el problema inmediato para asegurarse de que realmente lo comprende. Luego haz un análisis y repite.

• Elija la tarea más simple primero, incluso si parece demasiado simple para impulsar el impulso . Algunas personas prefieren la tarea más difícil, por lo que el 'trabajo duro' está fuera del camino. He descubierto que la 'tarea más simple' generalmente funciona mejor, ya que solo está buscando un impulso y he visto que 'lo más difícil primero' lleva a que los proyectos se detengan antes de que tengan un impulso real.

• Solicite ayuda para seleccionar la tarea y el enfoque correctos para comenzar.

• Busque un mentor que pueda brindarle comentarios constantes (idealmente diarios) durante una o dos semanas.

• Haga muchas preguntas pero concéntrese en ser cortés con sus compañeros de equipo. Siempre pregunte si tienen tiempo y preste atención a los signos verbales y no verbales habituales de que no tienen tiempo en ese momento.

• Mantenga una lista actualizada de los problemas que está encontrando y luego, ya sea en el scrum diario o en un momento regular de su elección, revíselos con otros.

• No tengas miedo de hacer las preguntas más básicas. Las suposiciones de otros pueden ser difíciles de desafiar, pero si no puede proceder con lo que le dan, debe cuestionar nuevamente.

• Si conoce el objetivo, haga todo lo que pueda hasta que se quede atascado y luego publique el progreso y la pregunta en Stack Overflow.

Por supuesto, no tiene idea de cómo escribir un "mecanismo de error genérico". Nadie sabe cómo escribir un "mecanismo de error genérico" hasta que se definan algunos requisitos. Parece que todo lo que tiene es la noción de alguien de que de alguna manera se requiere un "mecanismo de error genérico" para comenzar este proyecto.

Personalmente, rechazaría esta noción. Escribir algo "genérico" antes de implementar los requisitos reales del usuario es casi siempre una pérdida de tiempo. Y dado que es genérico , por definición no es específico de su empresa o aplicación, por lo que probablemente ya haya algo disponible que satisfaga aproximadamente el 95% de sus necesidades.

Pero dado que usted es el miembro junior, retroceder puede no ser una gran idea. Por lo tanto, debe hablar con las personas que piensan que necesitan un "mecanismo de error genérico" y averiguar qué servicios esperan que brinde este mecanismo. Luego busque en la red para ver si algo ya escrito será suficiente. Si encuentra algo, proponga simplemente usarlo. Probablemente no estarán de acuerdo, porque cualquiera que solicite un "mecanismo de error genérico" probablemente esté sufriendo un mal caso de no inventado aquí.

Si eso falla, el siguiente paso es definir una interfaz para el mecanismo de error y lograr que los interesados ​​lo aprueben. Después de eso, la implementación probablemente será trivial.

=================

PD Hay algunos programadores que piensan que la forma de comenzar cualquier proyecto es escribiendo una "plataforma" para proporcionar todos los servicios comunes que necesitarán los módulos de aplicación. Esto generalmente se convierte en meses de trabajo trivial reinventando cosas que ya están disponibles de forma gratuita. Hasta que alcance los límites de rendimiento de las soluciones disponibles, no hay razón para escribir servicios de "plataforma". Tampoco hay ninguna razón para escribir contenedores alrededor de las API existentes. Si refactoriza continuamente, el envoltorio exacto requerido por su aplicación aparecerá mágicamente.

Creo que sufres más de ansiedad que de déficit de habilidades. En algún momento, ¿no era todo nuevo? ¿Alguna vez te han asignado una tarea y no has podido resolverla en alguna medida? Te pagan para resolver las cosas.

Utilice su equipo : si está en un buen equipo, debería poder pedir ayuda. Hay cosas que sabrás que incluso los más mayores no sabrán. Pedir ayuda no es un signo de debilidad (no es más que correr a algún sitio de preguntas).

Búsqueda : ¿una búsqueda web sobre el manejo de errores genéricos no obtuvo nada? Es posible que no encuentre una solución completa. Tendrás que trabajar en ello y adaptarlo a tu aplicación de todos modos.

Prototipo : cambie su perspectiva de la tarea de producción a prototipo. Solo consigue algo para trabajar y construye desde allí. Cuando llegue al punto en que puede usarlo, comience a pensar en ello como producción. Ahora no verá la tarea como algo que ni siquiera sabe por dónde comenzar.

Supéralo : solo hacer cosas que sabes hacer será aburrido. También lo lleva a una trampa de fuerza bruta forzando algunas soluciones repitiendo las mismas cosas una y otra vez (si le gusta repetir cosas, vaya a trabajar en una línea de montaje). Prepárate para cometer errores. Aquellos que te dicen que lo saben todo, nunca piden ayuda o realizan búsquedas, solo mienten.

Es la vieja broma sobre los médicos que todavía "practican" la medicina; tampoco tienen todas las respuestas.

Alégrate porque no estás haciendo algo que hayas hecho cientos de veces antes. Has encontrado la alegría del desarrollo de software (para mí, de todos modos, YMMV): aprender a conducir mientras conduces por la autopista a velocidades extraordinarias. Este es el tipo de cosas por las que un gran desarrollador vive y destaca.

Mi proceso personal es algo como esto:

• Investigación. Averigüe si y cómo este problema, o un problema similar, se ha resuelto antes. Incluso si solo puede encontrar información sobre soluciones para diferentes idiomas o plataformas, aún puede ser extremadamente informativo.
• Prototipo. La mejor manera absoluta de hacer algo bien es hacerlo primero mal. Cree una solución, inventando todo a medida que avanza, según su investigación. Intente hacer que se ajuste a los requisitos principales, teniendo en cuenta los requisitos auxiliares. No se moleste en hacerlo bonito o perfecto o extensible o flexible o performante, solo haga que funcione. Tome notas de las lecciones aprendidas: qué funcionó, qué no funcionó, posibles obstáculos, etc. Luego deseche el código. Si le preocupa parecer un tonto por tomar demasiado tiempo, hágalo en su propio tiempo. Te beneficia personalmente, en términos de conocimiento.
• Diseño. Combine su conocimiento externo (investigación) con conocimiento personal (lecciones aprendidas prototipo) y formule un diseño de lo que cree que sería la forma correcta de hacerlo.
• Cooperar. Encuentre un miembro sénior del equipo, muéstrele su diseño propuesto, obtenga comentarios. Muéstralo a otra persona, recibe sus comentarios. Refina tu diseño.
• Iterar. Si aún no está seguro de su solución, asegúrese de que las revisiones por pares sean parte de su ciclo de iteración. Lleve su implementación a un miembro sénior del equipo regularmente para recibir comentarios.
• Sé feliz: has avanzado tu conocimiento y tu carrera, y tienes que hacer algo nuevo e interesante en lugar de algo viejo y aburrido que hayas hecho miles de veces antes. Intenta hacer de tu próximo proyecto un desafío aún mayor.

Y por último, no te preocupes demasiado por las apariencias. Como gerente del equipo de desarrollo, prefiero tener a alguien que pueda demostrar que puede aprender lo que sea necesario para aprender cuando lo necesite, que alguien que pueda demostrar que ya sabe lo que estamos tratando de hacer en este momento. Lo primero será más útil para lo que sea que terminemos haciendo mañana, o el próximo mes, o el próximo año.