Yo trabajo en TI Creo que solo escribir códigos es un trabajo genial, sin embargo, aún no podía hacerlo. Sigo cambiando de trabajo y tengo miedo de cambiar o no perder. ¿Cuáles son algunos consejos para concentrarse más en las cosas? Estilo de Vida y Elegante

Yo trabajo en TI Creo que solo escribir códigos es un trabajo genial, sin embargo, aún no podía hacerlo. Sigo cambiando de trabajo y tengo miedo de cambiar o no perder. ¿Cuáles son algunos consejos para concentrarse más en las cosas?

Como se mencionó anteriormente, TI se trata de resolver problemas y conlleva cometer MUCHOS errores.

Para darle mi visión personal, trate de evitar estas fallas:

No le digas sí a tu jefe sobre todo: ¡sé honesto! hágales saber de su conjunto de habilidades, velocidad, ETA y demás. Pueden lidiar con juniors lentos, pero no con el establecimiento de expectativas altas en el tablero y luego con retrasos.
¡TU CÓDIGO Apesta! Acéptelo más temprano que tarde. Siempre pensé que estaba reescribiendo la historia con mi código de vanguardia. Ahora que miro hacia atrás … ¡apesta! ¿¡QUÉ ESTABA PENSANDO!?
Revisiones hechas por colegas. Abrazo ha sido masacrado por sus compañeros por cada falta de su código. ¡Crecerás MUCHO más rápido que cualquier cantidad de cursos certificados!
Evite las soluciones internas hechas a mano: parte de los desafíos de una TI es comprender una amplia variedad de marcos y bibliotecas a nuestra disposición. No entender esto conduce al miedo y terminamos nuestras propias soluciones a medias. Antes de escribir un solo botón de interfaz de usuario, siempre pregúntese “Me pregunto si ya hay algo por ahí con entornos prod probados y pruebas sólidas”.
BDD, no TDD. El desarrollo impulsado por el comportamiento es más de lo que + describe + espera. Da forma a tu código. Hay una razón para escribir las pruebas primero. Reordenará sus pensamientos y pensará en el código CORRECTO para escribir.

Por último, el zen de python. INCLUSO si no haces python:
Bienvenido a Python.org

Hermoso es mejor que feo.
Explícito es mejor que implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Escaso es mejor que denso.
La legibilidad cuenta.
Los casos especiales no son lo suficientemente especiales como para romper las reglas.
Aunque la practicidad supera la pureza.
Los errores nunca deben pasar en silencio.
A menos que sea silenciado explícitamente.
Ante la ambigüedad, rechaza la tentación de adivinar.
Debe haber una, y preferiblemente solo una, forma obvia de hacerlo.
Aunque esa manera puede no ser obvia al principio a menos que seas holandés.
Ahora es mejor que nunca.
Aunque nunca es mejor que * ahora * ahora.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es fácil de explicar, puede ser una buena idea.
Los espacios de nombres son una gran idea, ¡hagamos más de eso!