Aprendí programación en casa y me gradué de un bootcamp brillante (es decir, según los estándares de ese bootcamp, que ciertamente no es tan bueno como los mejores bootcamps de EE. UU.*), encontré un trabajo con bastante facilidad teniendo en cuenta lo difícil que creo que debería haber sido . La entrevista fue muy bien.
Ahora trabajo para una empresa de tecnología que básicamente tiene un software principal que escribe para otras empresas muy grandes, y plantea algunos desafíos: 1) es difícil para mí comprender lo que está haciendo todo (han estado escribiendo/actualizando este software durante años ahora), 2) Veo código escrito de formas a las que no estoy acostumbrado y, finalmente, 3) No entiendo todo el código a primera vista, a veces no lo entiendo en absoluto. Mi tarea principal durante los próximos 6 meses será escribir pruebas unitarias y luego pruebas de integración porque "necesitas acostumbrarte a nuestro software", lo cual creo que tiene mucho sentido, aunque mi entrevista no tuvo nada que ver con eso. La mayoría de la gente es realmente agradable y amistosa, y hay un buen ambiente en esta empresa.
Mi problema es que tengo que escribir pruebas para métodos que no entiendo la mayor parte del tiempo, no siempre entiendo qué parámetros tienen que tomar, qué devuelve, no sé en qué tengo que simular para hacer que mi método sea comprobable por unidad, y no siempre entiendo las instrucciones que me dan. Después de dos semanas, puedo decir con confianza que claramente no creé valor para esta empresa y que los otros desarrolladores que me ayudaron podrían haber hecho mi trabajo en lugar de pasar tiempo conmigo.
Estoy bastante frustrado porque tengo muchas ganas de aprender, sin embargo, no es viendo videos en Pluralsight/leyendo artículos que mejoraré en lo que me desafía (¿o me equivoco?), así que ni siquiera puedo practicar en casa. . Creo que me avergüenzo cada vez que hago una pregunta, así que tiendo a quedarme atascado mucho, mirando la pantalla y tratando de entender lo que estoy leyendo. Me siento como un impostor rodeado de personas que 'lo entienden' y, para ser honesto, mi confianza se ha visto muy afectada (pasé de ser posiblemente el mejor en su clase a definitivamente el peor en una empresa). Durante los malos momentos, a veces me pregunto si dedicarme al desarrollo de software fue una buena idea y si no soy víctima de una falacia de costo irrecuperable (como en "Pasé demasiado tiempo aprendiendo esto para dejarlo ahora").
Mis preguntas:
¿Es normal?
¿Qué puedo hacer mejor?
¿Cómo podría expresar esto (o parte de él) a la gerencia y a los colegas sin parecer un fraude?
Editar:
He trabajado allí solo 2 semanas, es mi tercer trabajo. Los trabajos anteriores duraron 7 meses y 1,5 años.
*No fui claro y no quería parecer arrogante; No creo que este campo de entrenamiento sea excepcional, por lo que ser brillante en él probablemente no signifique mucho en el mercado laboral, a diferencia del mejor campo de entrenamiento de EE. UU. Este bootcamp está basado en Europa, y yo diría que es promedio. Además, creo que una gran razón por la que tuve éxito fue que estuve aprendiendo programación durante 1 año y las personas a mi lado no tenían idea de qué era una 'variable', por lo que tuve una gran ventaja inicial y, en general, fue mucho menos abrumador que para mis compañeros de estudios.
Después de dos semanas, puedo decir con confianza que claramente no creé valor para esta empresa y que los otros desarrolladores que me ayudaron podrían haber hecho mi trabajo en lugar de pasar tiempo conmigo.
No creará un valor "positivo neto" para la empresa durante mucho más tiempo (incluso cuando contrato a desarrolladores sénior, asumo que no son positivos netos durante 6 meses).
Todo lo que mencionó en su pregunta son en realidad buenas señales: parece que están creando un software interesante y no trivial, lo que significa que hay muchas oportunidades para que aprenda, y significa que están interesados en usted, brindándole el tiempo y espacio para ponerse al día.
Las pruebas de unidad de escritura y de integración son una forma bastante común de incorporar nuevos empleados junior. Aprenderá el IDE, el sistema de control de fuente, el proceso de compilación y todos los diversos flujos de trabajo formales e informales de cómo desarrollan el software, mientras se enfoca en fragmentos de trabajo relativamente pequeños. También puede aprender mucho sobre la funcionalidad comercial que proporciona su software.
1 - ¿Es normal?
Sí. No eres un impostor, y no hay razón para pensar que entrar en este campo fue una mala idea. De hecho, por el hecho de que te contrataron y quieren invertir en ti, parece que fue una buena idea. Lo más importante es superar la ingenua creencia de que solo porque eras "posiblemente el mejor" en tu campo de entrenamiento, eso significaba que estabas preparado para entrar a un taller de desarrollo el primer día y comenzar a producir valor. El campo de entrenamiento le proporcionó la base básica de la programación: hay mucho, mucho, mucho más para ser un desarrollador profesional, que solo puede aprender en el trabajo.
2 - ¿Qué puedo hacer mejor?
Creo que hay dos "ámbitos" en esto. El primero son cosas que puedes hacer por tu cuenta. Invierta su propio tiempo en aprender el lenguaje en el que está programando: los detalles, las funciones avanzadas, etc. Incluso si su campo de entrenamiento estaba en el mismo lenguaje en el que está trabajando ahora, hay mucho que aprender (he estado programando en el mismo idioma principal durante más de 10 años y sigo aprendiendo cosas nuevas todos los días). Si alguna de las otras herramientas que usan está disponible públicamente o de forma gratuita (el IDE, la herramienta de control de código fuente), practique con ellas también. Además, dedique tiempo a aprender sobre los conceptos básicos de la informática (algoritmos, estructuras de datos). Incluso si no está utilizando ese conocimiento de inmediato, siempre será útil.
La segunda, aunque no está específicamente relacionada con las pruebas que está realizando, puede realizarse como parte de ese trabajo. Eso es desarrollar la capacidad de "analizar" una pieza de código. Realice la prueba más simple que pueda encontrar, pruebe la pieza de código más simple e intente resolver el flujo de control de esa pieza de código. Ejecútelo a través de un depurador, deteniéndose en cada línea, y vea lo que realmente está haciendo. Modifique la prueba ligeramente y vea cómo se comporta de manera diferente. Intente crear una prueba que probará una rama if diferente (etc.). Use su herramienta de control de fuente IDE y mire la confirmación más reciente que cambió ese código. Vea si puede entender qué hizo ese cambio (especialmente útil si puede vincular al ticket que documentó ese cambio). Pase a una prueba un poco más compleja y repita. Ahora, toma el fragmento de código que quieren que pruebes, y realizar ese análisis de antemano. Usa eso para escribir tu primera prueba.
Si necesita ayuda, pregunte al autor de la prueba o el código que está buscando para que le proporcione una descripción general.
3 - ¿Cómo podría expresar esto (o parte de ello) a la gerencia y colegas sin parecer un fraude?
Nadie nace sabiendo codificar. Por lo tanto, todos sus colegas y gerentes comenzaron en un lugar similar al suyo. Mientras no sean idiotas (y ya dijiste que no lo son), saben y esperan que les pidas ayuda.
Por supuesto, deberá encontrar el equilibrio adecuado entre hacer demasiadas preguntas y no pedir ayuda lo suficientemente pronto. A menudo les he dicho a mis jóvenes "no pierdan 3 horas tratando de descubrir algo en lo que pueda ayudarlos en 5 minutos". Por el contrario, no pierdas mis 5 minutos si no has pasado algún tiempo tratando de resolverlo por tu cuenta.
Si aún no tiene una programada, pídale a su gerente una reunión semanal de 30 minutos. Para citar otra respuesta que he escrito aquí:
el trabajo de su gerente [es] hacer todo lo posible para brindarle las oportunidades de tener éxito; esto solo puede suceder si ambos tienen conversaciones regulares y frecuentes, y si durante esas conversaciones son abiertos y honestos acerca de dónde están teniendo dificultades, dónde necesita apoyo, dónde se está estancando y dónde aprende lo que él / ella espera de usted.
Una de las cosas más importantes que debe preguntar es "¿por dónde debo empezar?" y "¿a quién debo molestar para pedir ayuda?"
¡Buena suerte!
One of the most important things to ask is "where should I start" and "who should I bother for help".Trabajé allí solo 2 semanas.
Tienes que darle mucho más que sólo 2 semanas.
Toma las cosas gradualmente. Es casi seguro que encontrará que cada semana es un poco más cómoda que la anterior.
Aproveche la cultura agradable y amistosa. Pide ayuda cuando la necesites.
Y no seas tan duro contigo mismo. Si aprendió a programar por su cuenta y luego fue brillante en el campo de entrenamiento, lo más probable es que esté bien con un poco más de paciencia y trabajo duro.
Bienvenido a la jungla. :)
Sí. Es normal. Eres un junior. Se espera que no tengas ni idea, y es por eso que te piden que hagas lo que estás haciendo.
Hacer preguntas. Obtenga el entendimiento. Pregunte qué puede leer en su propio tiempo para ayudarlo a desarrollar una comprensión. Esté dispuesto a trabajar duro incluso pasando algunas horas fuera del trabajo. Me preocuparía un desarrollador junior que NO hizo preguntas. Estaría dispuesto a apostar que cualquiera de sus compañeros de trabajo que son mayores comenzó como usted.
Haz preguntas y aprende. Con el tiempo no tendrás que hacer preguntas. Simplemente hará clic y lo obtendrás.
Como todo el mundo dice, dos semanas no es nada. Tardarás mucho más que eso en ponerte al día. Y su gerente y sus colegas esperan esto.
Me gustaría tomar una frase para comentar:
Mi problema es que tengo que escribir pruebas para métodos que no entiendo la mayoría de las veces, no siempre entiendo que parámetros tienen que tomar, que devuelve,...
Como lo veo, esto es una falla de documentación . Lo cual también es terriblemente común. En un mundo ideal, debería haber una descripción de todo lo que está disponible, pero muy a menudo no la hay.
Por lo tanto, su primera pregunta debería ser si se ha perdido alguna documentación. La respuesta más probable es "no", pero vale la pena preguntar.
Sugeriría escribir esa documentación antes de hacer pruebas unitarias. Esto hace posible preguntar "¿Entendí correctamente el propósito de esta función?" La documentación en sí será valiosa para la empresa, y es más probable que las pruebas unitarias prueben lo que deberían probar.
Puede ser difícil armarse de valor para interrumpir a un colega ocupado con una pregunta que probablemente sea trivial. Como debe ser, las interrupciones apestan.
En su lugar, debe programar una reunión. De esa manera es solo una interrupción en lugar de muchas. Si tiene una pregunta que bloquea su trabajo, déjela a un lado y busque otra tarea.
Ve preparado para la reunión. Tenga una lista de preguntas, referencias exactas a cualquier fuente relevante o documentos involucrados, etc.
Al principio necesitarás muchas de esas reuniones, pero las cosas mejorarán a medida que te familiarices con todo.
1 - ¿Es normal?
Sí. Sentado allí, mirando confundido el código alienígena y preguntándote qué estás haciendo es normal en todos los niveles, incluso después de décadas de experiencia. Lo que cambia es cómo lo manejas.
2 - ¿Qué puedo hacer mejor?
Síguelo. Dos semanas no es realmente nada de lo que preocuparse. Una vez fui líder de equipo/desarrollador líder de una aplicación como la suya, y las personas nuevas tardaban más de dos meses en volverse algo productivas, a veces tomaba años. Las personas pueden tardar una semana o más en inicializar solo su entorno de desarrollo, pudiendo compilar el código fuente, en aplicaciones heredadas, y más semanas para que se ejecuten en su computadora portátil. Etcétera.
3 - ¿Cómo podría expresar esto (o parte de ello) a la gerencia y colegas sin parecer un fraude?
No hablas de cómo te sientes un fraude; usted habla objetivamente sobre la tarea en cuestión. Trate de encontrar posibles soluciones y, si no puede decidir por sí mismo, pregúntele a su jefe o al desarrollador principal. Si eso significa que tiene que preguntarle a su colega todo el día, todos los días, que así sea. Si su colega le da la sensación de que es demasiado, pregúntele a su jefe a quién más preguntar, o si tiene otras fuentes de información, o si está de acuerdo con que se tome mucho tiempo para tropezar en el oscuro.
Sea transparente; asegúrese de que sus "partes interesadas" sepan lo que está haciendo. (Es un arte hacer esto de una manera que no ponga nerviosos a todos; tal vez sea un tema para otra pregunta; una forma sería mantener una página que se mantenga actualizada, y simplemente enviarla una vez a la semana o cada dos). semana, o algo así. También depende mucho de la cultura de su empresa).
Esta es una calle de doble sentido. Lanzar al chico nuevo al código fuente no documentado es un buen ejercicio para hacer que "fluyan los jugos", pero al final del día nadie esperaría que sucediera magia aquí.
Si tiene preguntas técnicas concretas, mejor pregunte en uno de los intercambios de pila más técnicos.
talk objectively about the task at handeste es el mejor consejo, repetirte a ti mismo que no entiendes es improductivo de la peor manera. La única forma de entender el código alienígena (me encanta esa frase) es hablarlo, y una vez que creas que lo entiendes, ve al autor, explica lo que crees que hace o cómo funciona y escucha sus comentarios. No tengas miedo de usar papel para dibujar diagramas que solo tú entiendas mientras tratas de resolver las cosas.He trabajado en algunos códigos base masivos y antiguos (3D CAD en C++, algunos de los cuales se generaron automáticamente desde FORTRAN) y he sido principalmente un desarrollador durante más de 35 años. ¡Cualquier cosa negativa que diga a continuación proviene de sentimientos y situaciones en las que he estado!
Como han dicho otros, no estás solo. Tengo un consejo similar a Stig pero con algunos matices importantes.
En primer lugar, es importante para su autoestima y posiblemente para su trabajo mostrar que no está simplemente sentado mirando el código, sintiéndose perdido.
Hay tres cosas que puedes escribir para mostrar lo que estás haciendo:
No critique sus prácticas de documentación existentes. Esta es un área que a menudo es muy controvertida. Las personas pueden tener sus propias opiniones fuertes y haberlas rechazado. Te sorprendería cuán profundos pueden ser los sentimientos en torno a las prácticas de documentación (y cómo escribir pruebas).
No le pidas consejo a alguien y parezca que lo ignoras. Si alguien te da un consejo y no entiendes cómo aplicarlo, piénsalo y por lo menos escribe algunas notas sobre cómo intentaste aplicarlo.
No trates de entenderlo todo. Simplemente no lo hagas . Esta es probablemente la mayor debilidad del código limitado al que las personas están expuestas en la educación (no solo en los bootcamps). Muy pocos lugares te enseñan a programar sin esperar que lo entiendas todo. Eso simplemente no es posible en grandes programas. Deja ir esa necesidad de entender.
Creo que me avergüenzo cada vez que hago una pregunta, así que tiendo a quedarme atascado mucho, mirando la pantalla y tratando de entender lo que estoy leyendo.
Creo que este es el único lugar en el que te estás equivocando. La gente nueva necesita hacer muchas preguntas, es la forma más fácil para que los experimentados juzguen lo que necesitas saber a continuación.
Cuando te encuentres mirando la pantalla, escribe un correo electrónico (o un mensaje de holgura, o lo que sea). Trátelo como una pregunta de desbordamiento de pila; describe el problema y lo que has hecho, y demuestra que te has esforzado. La mitad de las veces esto puede sugerir algo que no ha probado, o un tema que puede investigar, y no tendrá que enviar el correo electrónico. Si no, envíelo y pase a otro problema mientras espera una respuesta.
El correo electrónico permite que otras personas respondan cuando sea conveniente para ellos, pero pídales que lo llamen cuando sea conveniente para usted ir a su escritorio, luego vaya y hable con ellos. Obtendrá más información de esta manera y construirá relaciones importantes.
Distribuya sus preguntas en lugar de agotar el tiempo de una persona, y pídales que le muestren cómo resolverían el problema, en lugar de solo "la respuesta". También debe preguntar a las personas cuánto tiempo tardaron en aprender el sistema y cuánto saben. Eso debería convencerte de que lo estás haciendo bien.
Además, cuando encuentre una función mal documentada y pase un tiempo aprendiendo sobre ella, debe anotar lo que aprende. Esto podría ser comentarios en el código, documentación oficial, un wiki del equipo o una nota no oficial (en ese orden de preferencia). Entonces estás agregando valor y ayudando al siguiente. También puede tomar notas sobre las áreas que están atrasadas para la refactorización y cualquier error que encuentre.
2 - ¿Qué puedo hacer mejor?
Estoy totalmente de acuerdo con las otras respuestas, 2 semanas básicamente no es nada, así que deja de preocuparte por eso. Pero hay una cosa en la que puedes y debes hacerlo mejor:
Creo que me avergüenzo cada vez que hago una pregunta, así que tiendo a quedarme atascado mucho, mirando la pantalla y tratando de entender lo que estoy leyendo.
ESTO es en lo que tienes que trabajar. Hay algunas cosas que puedes resolver por tu cuenta y, por lo general, es mejor que lo hagas si es posible, por supuesto. Pero hay otras cosas, como las razones históricas de algunos giros del código, que posiblemente no puedas descifrar. Hay que preguntar por esas cosas sin pasar días pegado a mirarlas.
Ahora no estoy diciendo que revoloteas por la oficina como un mosquito zumbando a todos en tu camino. Cuando te encuentres con algún problema de este tipo, anótalo. Consiga a alguien (generalmente su gerente) que le diga quién es el experto en esto o aquello. Luego trate de encontrar un momento en el que no los interrumpa (¿como hacer una cita real?) y revise su lista de preguntas relevantes con ellos. No se molestarán por un flujo constante de preguntas, pero aún así tendrás la oportunidad de ponerte al día.
Neo
vaquero galáctico
MarkJL
Slothario
Azrantha
alejandro m