El factor más importante en lo que me impide ser un desarrollador estelar es mi dependencia de los demás. Siento que hago demasiadas preguntas porque temo las consecuencias de romper todo y detener a todos. Así que soy demasiado cauteloso al hacer tantas preguntas que básicamente obtengo las respuestas después de suficientes preguntas. He reconocido que es malo, pero quiero detenerlo. Parte de esto se debe a que a veces simplemente no conozco el código (ya sea una sucursal con la que nunca he trabajado o es un producto nuevo), pero quiero confiar menos en otros. Para comenzar, este tipo de preguntas no son sobre patrones genéricos o lenguajes: por lo general, mis preguntas giran en torno a cómo codificamos en nuestra empresa y cómo hacemos que las cosas funcionen en nuestro ecosistema. Quiero poder tomar especificaciones y rodar con ellas sin tener que sentir que necesito ayuda en cada paso del camino. ¿Esto es normal? ¿Has pasado por esto, y si es así, cómo lo superaste?
fuente
Respuestas:
Veo que algunos nuevos desarrolladores entran en un trabajo e inmediatamente se sienten inadecuados. Hice lo mismo al principio de mi carrera. Creo que hay al menos dos problemas principales que la mayoría de los hombres inteligentes deben superar: la percepción del tiempo y su propia habilidad natural.
Percepción del tiempo
Los chicos inteligentes están acostumbrados a resolver problemas con relativa rapidez. Recuerdo estar horrorizado cuando tuve que pasar una hora en un solo problema de cálculo. Pasar 60 minutos en un problema ya no es nada. Esos días han terminado ... entiérralos y despídete. La complejidad y el tamaño de la mayoría del software actual es indignante. La gente no entiende todas las herramientas que tienen que usar para hacer las cosas por más tiempo. Douglas Crockford, uno de los hombres clave del lenguaje JavaScript, dijo:
"Misapplication of standard tools...is the new standard."Simplemente no hay suficiente tiempo en el mundo para aprender todas las herramientas de desarrollo.
Habilidad natural
Su inteligencia, capacidad de resolución de problemas y habilidades naturales lo llevaron a todo el concierto de desarrolladores en primer lugar. Simplemente no hay espacio para nada menos en este campo. Entonces, ¿qué haces con 100,000 líneas de código, lenguajes y marcos que apenas conoces, patrones de diseño y paradigmas que la gente te está presionando, tipos que saben la mayor parte como la palma de su mano, clientes que lo quieren ayer y un jefe ¿Quién espera el mundo de ti? Enloquece cuando tu habilidad natural falla.
Sí, eso es normal. Todavía me asusto con algunas de las cosas que me arrojan.
¿Qué se puede hacer?
Es hora de mejorar esas habilidades naturales con un buen trabajo duro a la antigua. Trabaja en dividir los problemas en partes más pequeñas. Y tenga en cuenta que, a diferencia de muchas cosas que pudo haber hecho en el pasado, estos problemas requieren mucho tiempo para resolverse. Así que no te rindas después de solo 15 minutos de examinar un problema complejo. En cambio, analice los problemas y deje de mirar el reloj. Después de un tiempo, 30 minutos de trabajo con un problema ya no es lo que solía ser.
La autoconfianza juega un papel importante en la capacidad de autogobernarse. También lo hace el equipo, especialmente los adultos mayores con más experiencia. Es bueno tener cuidado de no romper cosas, pero esto no significa que deba hacer un flujo constante de preguntas.
En su lugar, utilice el control de fuente. Mientras no registres un cambio, no puedes romper el producto principal y enojar a otros desarrolladores. Además, realice cambios que pueda comprender y probar y asegúrese de probarlos bien antes de registrarse.
Incluso tengo un pequeño proyecto de prueba que utilizo para escribir programas simples y únicos para no tener que preocuparme por todo lo que sucede en la aplicación principal.
Finalmente, recuerde que cada decisión viene con cierto nivel de toma y daca. No hay avance sin hacer algún tipo de sacrificio en algún nivel. No luches por la perfección, lucha por lo asombroso y ten en cuenta tus acciones. Porque siempre debes estar preparado para recibir críticas y explicar tus ideas y por qué las hiciste. Siéntete orgulloso de las decisiones que tomes. Incluso cuando están equivocados, hay mucho que aprender.
fuente
Lo primero es no tener miedo de hacer preguntas. Incluso he visto a arquitectos senior hacer preguntas sobre el código. No se espera que lo sepan todo; se espera que sepan lo suficiente para hacer el trabajo y puedan resolver el resto.
Probablemente las mejores tácticas serían:
fuente
No tenga miedo de hacer preguntas de "panorama general"
Solía tratar de encontrar la pregunta más pequeña que podía hacer y aún así poder continuar con mi trabajo, por temor a que me consideraran incompetente si hacía preguntas generales a las que todos los demás parecen saber la respuesta. No entendí la diferencia entre ignorancia e incompetencia. La ignorancia solo significa que aún no has aprendido algo, y es perfectamente aceptable siempre que no persista. Pretender no ser ignorante es mucho peor.
Si descubres que las respuestas de las personas solo te llevan tan lejos, debes pedirles que te enseñen a pescar en lugar de darte otro pez. Pregunte cómo encaja su parte con el todo. Si su pregunta parece tan básica como "qué es SQL de todos modos", pregúntelo lo antes posible. Puede parecer un poco tonto ahora, pero se verá mucho más tonto más tarde.
Date un período de espera
No haga preguntas tan pronto como las tenga. Dependiendo de la complejidad, date de media hora a un día para tratar de resolverlo por tu cuenta. Muchas veces lo resolverás tú mismo. Si no, podrá decirle a su colega lo que no funcionó, lo que puede ayudarlo a darle una mejor respuesta.
Además, si su colega no sabe una respuesta, preste atención a cómo llega a ella. Muchas veces no necesitas tanta ayuda como crees. Si no tengo tiempo para una pregunta, a menudo apunto a alguien en una dirección imprecisa y les digo que iré a hacer un seguimiento cuando tenga un minuto, y generalmente lo han resuelto para cuando llego allí.
Tire algunos borradores
No tenga miedo de escribir código que nunca se convierta en una versión. Cuanta más experiencia tenga, más pronto podrá darse cuenta de que está yendo por el camino equivocado, pero aún sigue por el camino equivocado. Muchas veces, el valor de una solución no es evidente hasta que la haya visto de manera incorrecta primero.
fuente
La autosuficiencia vendría con
Hacer preguntas con frecuencia correría el riesgo de demostrar que carece de ambas.
Si cambia su dominio, tecnología, plataforma, idioma, volverá al punto de partida (casi, sin contar su mayor capacidad para abordar problemas similares y conocimiento transferible)
No hacer preguntas cuando sea realmente necesario desperdiciaría mucho tiempo valioso de producción.
Podría funcionar a su favor al decir una palabra sobre su suposición sobre el alcance del posible daño si lo hace mal. o lo que crees que podría romperse para obtener una evaluación real de tus suposiciones. Muchas veces podría permitirte descubrir puntos y ángulos que te has perdido.
Ser cauteloso es bueno, pero lo mejor es comenzar a determinar la naturaleza de sus preguntas. Es mejor si lo escribe en papel y examina su dificultad / valor.
fuente
Diría que mire las cosas en las que está trabajando y comience a tomar decisiones usted mismo (manteniendo las especificaciones de la aplicación, por supuesto). A estas alturas, debe tener una buena idea de lo que es un cambio de largo alcance y lo que es un cambio simple. Comience con los simples. Si crees que lo que estás haciendo es correcto, hazlo.
Usted SE cometen errores y los que tienen un valor incalculable. Aprende todo lo que puedas de ellos cuando sucedan, ya que son lo que te hará hacer un mejor trabajo la próxima vez.
Una vez que se sienta cómodo con las decisiones más pequeñas, comience a tomar las más grandes. Deberá decidir hasta dónde llegar con esto en función de su proyecto / entorno / equipo.
Ese es el lado de la toma de decisiones. La otra cosa que debe hacer es seguir alimentando su cerebro para que pueda ayudarlo a guiar sus decisiones. Siga los sitios que cubren su tecnología. Hay tutoriales en línea de casi todo lo que cubre todo, desde lo simple hasta lo extrañamente complejo. No tenga miedo de preguntarle a la gente por qué toman ciertas decisiones, como buscadores de información, no para confrontar. La mayoría de las personas están más que felices de explicar las cosas y puedes aprender bastante de ellas.
Una vez que tenga el conocimiento técnico, el resto es sabiduría y confianza, y eso viene con experiencia.
fuente
Cuando era un novato haciendo preguntas, siempre intentaba obtener una respuesta parcial a la cosa yo mismo, usando las herramientas disponibles; y cuando llegué tan lejos como pude, descubrí exactamente cómo formular mi pregunta para ser lo más claro y conciso posible, bajo el supuesto de que la persona a la que iba a pedir ayuda estaba ocupada. Con este poco de preparación, no creo que a nadie le haya importado hacerles preguntas, y de hecho tuve la impresión de que lo disfrutaron. Más tarde, cuando me convertí en el experto en dominios, también disfruté ayudando a las personas que dejaron en claro que respetaban mi tiempo.
La otra cosa que hice fue, todos los días, seleccionar la arquitectura del sistema. Otros carteles han comentado qué es una empresa masiva de sistemas modernos, qué tan difícil de aceptar. Entonces, me gustaría hacer recorridos por el código: comenzar en algún punto de entrada sensible, luego seguirlo, anotarme notas sobre cómo funcionaba, hacer preguntas que a veces respondería por mí mismo, a veces preguntaría a otras personas. Este tipo de familiaridad general y competencia de dominio lleva tiempo, pero puede acelerarlo; y cuanto más hagas, antes serás autosuficiente de la forma que quieras.
fuente