Análisis de errores comunes cometidos por programadores novatos, pt. 2

¡Hola de nuevo a todos! Continuaremos considerando los problemas que un programador joven e inmaduro puede enfrentar en su primer trabajo. La primera parte se puede encontrar aquí . Continuemos.

13. Incumplimiento de las pautas de estilo de codificación.

Los equipos de desarrollo suelen ceñirse a un único estilo de codificación. Es decir, los desarrolladores individuales siguen ciertas reglas escritas o no escritas para garantizar que su estilo de codificación no difiera de los demás. No intentes diferenciarte con un estilo de codificación distintivo: esto no te hará quedar bien. Si es nuevo en el proyecto, debe averiguar inmediatamente si existe alguna documentación que defina pautas generales de estilo de codificación. Es posible que haya algunos archivos de estilo para su proyecto específico que deba solicitar e importar a su IDE (por ejemplo, IntelliJ IDEA), para que el IDE pueda proporcionar las sugerencias de estilo de codificación correctas. Por ejemplo, el estilo podría requerir el uso del modificador final siempre que sea posible. El archivo de estilo permite a IntelliJ IDEA resaltar en amarillo cualquier variable que no se respete.

14. Desanimarse por los errores

Los errores son algo a lo que tienes que acostumbrarte. Lo han sido, son y serán. No importa si eres principiante o un arquitecto serio, siempre cometerás errores. El número y la gravedad de tus errores pueden cambiar, pero te acompañarán a lo largo de tu carrera. A veces te cuesta conseguir que algo funcione toda la semana, cometes un error, y luego es viernes por la noche y te escabulles a casa como un perro apaleado, sin poder corregir ese maldito error. Es un sentimiento indescriptible, pero no algo que deba desanimarte. Después de todo, otra diferencia importante entre un desarrollador experimentado y un novato es cómo maneja los errores. Los desarrolladores experimentados no se los toman en serio, sino que los consideran experiencia. Nadie te regañará por cometer un error. Esto es normal: todo el mundo se mete en un lío a veces. Nuevamente, puede pedir ayuda a sus colegas. Y no se olvide de personas como los directores de proyectos (PM). Si está atascado en algo, debe comunicarse inmediatamente con el primer ministro. Él o ella puede ayudarle a encontrar a alguien que sea experto en el área problemática. En cualquier caso, el PM debe mantenerse informado sobre cualquier problema que encuentre en el proyecto. El trabajo del PM es ayudar a resolver todo tipo de problemas, incluida la comunicación y las interacciones entre los miembros del equipo. En resumen: los errores ocurren , no dejes que te maten. En lugar de ello, acéptelos como un desafío para usted y sus habilidades. Al final, es sólo una parte del trabajo.

15. No implementar la seguridad de subprocesos.

Nada bueno se crea fácilmente. Todo desarrollador debe comprender que escribir una funcionalidad específica, ya sea un módulo o simplemente un método, requiere un plan sobre qué se hará y cómo. Como regla general, al desarrollar funciones de cualquier complejidad, debe seguir el siguiente procedimiento: Muchos errores que surgen en el código escrito por programadores novatos se relacionan con los pasos de este procedimiento. Por supuesto, no puedes descartar que haya momentos en los que necesites escribir código rápidamente sin dudarlo tan pronto como veas la tarea. Pero esto generalmente sólo funciona para ciertas tareas y métodos menores cuya implementación es obvia y no requiere mucha reflexión. El procedimiento de desarrollo mencionado anteriormente es más adecuado para tareas grandes y complejas que se pueden dividir en subtareas. No es una buena idea empezar a escribir código sin tener claro lo que se quiere escribir. Primero, debe pensar y planificar todo detenidamente. También puede resultar útil coger una hoja de papel y un lápiz e intentar esbozar sus ideas de implementación. Siempre hago esto cuando planifico funciones complejas. Un programador pasa la mayor parte de su tiempo no escribiendo código, sino pensando en cómo estructurar la funcionalidad requerida . De hecho, una vez que haya planeado y pensado en todo, escribir código se convierte en un proceso puramente mecánico y sin complicaciones.

16. Trabajar demasiado

de la película "El club de la lucha" (1999) Quizás todo principiante piense que, al trabajar hasta altas horas de la noche, comenzará a completar más tareas y se le confiarán más responsabilidades. Yo también pensaba lo mismo, pero ya no. Me di cuenta de que llega un momento en el que llegas a tu límite, en el que dejas de poder pensar adecuadamente. Empiezas a volverte bastante aburrido y experimentas confusión mental. Se necesita una hora para hacer cosas que podrías hacer en 10 minutos si tuvieras la mente fresca. Casi sin excepción, después de cruzar esta línea de fatiga, te encuentras con algún problema que parece insuperable. Pero cuando llegas a trabajar a la mañana siguiente, lo solucionas en un abrir y cerrar de ojos. Así que cuando sientas que has llegado a este punto, no te quedes despierto hasta tarde. Simplemente vete a casa y descansa bien. Después de todo, si permanece en su escritorio hasta altas horas de la noche, no sólo no logrará resultados particularmente sobresalientes durante estas horas de tormento, sino que al mismo tiempo corre el riesgo de descansar mal (insuficiente) antes del siguiente día de trabajo, cuando Lo arruinarás una vez más. Piensa en tu salud: ¿vale la pena minarla así al inicio de tu carrera? Yo creo que no. Es un momento costoso para estar enfermo. Y piense en su empleador. Al trabajar demasiado, empeora las cosas no sólo para usted, sino también para su empleador. ¿Quién necesita un empleado que siempre tiene sueño y que, debido al cansancio, no puede implementar el algoritmo de clasificación más simple? Sí, sin duda hay momentos en los que tienes una fecha límite urgente, momentos en los que todo salió mal y momentos en los que (y este es mi favorito personal) "lo necesitamos para ayer". Pero estas situaciones son generalmente raras y una vez que las superas, debes sentarte y considerar cuidadosamente cómo pudieron haber sucedido y cómo evitarlas en el futuro.

17. Descuidar las habilidades en inglés

Muchos aspirantes a desarrolladores dan prioridad al aprendizaje de la tecnología y posponen el aprendizaje del inglés. Esto es un error grave, ya que muy a menudo un programador es perfecto para un puesto junior (o pasantía), pero no consigue el trabajo debido a sus débiles conocimientos de inglés. Sí, por supuesto, hay casos en los que puedes arreglártelas sin inglés. Por regla general, estas personas son contratadas localmente para proyectos en países de habla no inglesa. Pero las empresas locales no pagan los mismos salarios que las extranjeras. Y será muy, muy difícil conseguir un salario digno, incluso con el tiempo. Por eso no debes ignorar el inglés. En lugar de dejar el inglés en un segundo plano, debes aprenderlo para poder concentrarte inmediatamente en proyectos en inglés. De hecho, piénselo por un minuto: el inglés es actualmente el idioma de los negocios internacionales. Cualquiera que sea el país al que vayas, podrás encontrar un idioma común con otros si sabes inglés. Lo mismo ocurre con los proyectos de desarrollo. No importa dónde se base el proyecto: Alemania, Australia, Francia o cualquier otro lugar: toda la comunicación, todas las tareas, documentación, etc. estarán en inglés. Y si lo piensas un segundo, estarás de acuerdo en que esto es muy conveniente, ¿verdad?

18. Búsqueda de tecnología de moda

A medida que los desarrolladores comienzan su camino, a menudo intentan mantenerse al día con las últimas tecnologías. ¿Es eso lo correcto? Por un lado, sí: las últimas tecnologías, proyectos... ¿Pero merece la pena convertir esto en una máxima prioridad? ¿Quizás sea mejor recurrir al "conjunto de herramientas clásico" de un especialista en su campo? Lo nuevo es ciertamente bueno, pero no debes olvidarte de las tecnologías fundamentales de tu campo. Y sólo entonces, después de haber adquirido un poco de experiencia y un conocimiento profundo de los conceptos básicos, podrá probar algo nuevo. Consideremos también que las nuevas tecnologías pueden ser superiores en algunos aspectos sutiles, pero pueden perder ventajas en otros. Hasta que un desarrollador novato comprenda estas ventajas y desventajas, es mejor seguir con las soluciones probadas en el tiempo. Por ejemplo, si un programador está desarrollando una aplicación que interactúa con algunos datos, no se apresure a utilizar la última solución NoSQL simplemente porque está de moda. Una base de datos SQL común y corriente (MySQL, PostrgreSQL, etc.) probablemente tenga documentación detallada y soluciones en StackOverFlow para cualquier problema potencial :)

19. Aprender varias tecnologías y/o idiomas diferentes a la vez

Hablamos anteriormente sobre principiantes que intentan aprender tecnologías de moda. Bueno, ¿qué tal estudiar simultáneamente muchas tecnologías o idiomas? Obviamente, habrá oído hablar de programadores que conocen más de un lenguaje de programación y dominan muchas tecnologías. Pero señalaré rápidamente que estas personas están lejos de ser nuevas en la programación. Son personas con muchos años de experiencia a sus espaldas. Han dominado su tecnología original y luego han ido más y más lejos. Los principiantes que intentan dominar todo a la vez deben recordar el excelente proverbio: "persigue dos liebres y no atraparás a ninguna". La consecuencia puede ser que no domines bien ningún tema, sino que solo aprendas los temas de forma superficial. Habrá más demanda de un especialista que conozca profundamente un solo idioma que de uno que sepa un poco de todo. Entonces, si quieres conocer muchos idiomas y tecnologías, debes abordarlos sabiamente. Para comenzar, debes elegir un lenguaje básico y central que debes aprender en profundidad. Y sólo entonces deberías empezar a estudiar otras áreas. Por ejemplo, conviértete en un gurú de Java y luego aprende Python como segundo idioma. Después de eso, es posible que aprenda algo sobre reaccionar/angular para la interfaz. En este caso hablamos de tecnologías que no son intercambiables, como C# y Java, sino complementarias, ampliando tus oportunidades profesionales. Pero repito de nuevo: no debes intentar aprender todo de una vez. Necesitas ir secuencialmente. Atrapa una liebre a la vez, por así decirlo.

20. Metas formuladas incorrectamente

¿Cómo te fijas metas? ¿Convertirse en un desarrollador genial? Recuerde esto de una vez por todas: debe fijarse objetivos concretos o, en otras palabras, objetivos alcanzables. ¿De qué estoy hablando? Por ejemplo, te fijas el objetivo: "Quiero hacerme rico". Pero, ¿cómo sabrías si has logrado este objetivo? ¿O cómo mides qué tan cerca estás de lograrlo? Bueno, si te pones el objetivo "quiero ganar un millón de dólares", eso queda un poco más claro, ¿no? Una vez que haya ganado $10,000, estará $10,000 más cerca de su meta; solo le quedan $990,000. Aún queda mucho por lograr, pero podrás sentir tu progreso y entender dónde está la meta, por lo que estarás motivado para seguir adelante. En términos de tu carrera, ¿qué tal si te fijas una meta más tangible? Por ejemplo: quiero convertirme en líder de equipo. O un desarrollador senior. O, en definitiva, arquitecto. Bueno, toda gran tarea debe dividirse en pequeñas subtareas. No te conviertes en líder de equipo al comienzo de tu carrera. Establezca plazos si es posible y apropiado, y concéntrese en la etapa actual.

1. Si hablamos de convertirnos en desarrollador senior , entonces el primer pequeño objetivo sería encontrar una pasantía o un trabajo como desarrollador junior en una empresa.
2. A continuación, puede establecer objetivos para profundizar su conocimiento de determinadas tecnologías. En lo que respecta a Java, podría prepararse para la certificación de Nivel 1 de Oracle. Establecemos un marco temporal para nuestra preparación y afrontamos el objetivo.
3. Luego, por ejemplo, podrías fijarte el objetivo de mejorar tu inglés en un nivel (por ejemplo, de B1 a B2). Elaboramos un plan de aprendizaje, programamos el tiempo y avanzamos hacia la meta.

Así es como podemos lograr nuestro objetivo final paso a paso (mientras adquirimos experiencia en desarrollo de software).

21. Teoría sin práctica

Es un hecho indiscutible que nos volvemos mejores profesionales estudiando nuevas tecnologías y profundizando en temas que ya conocemos. Pero al comienzo del viaje, los desarrolladores rara vez se dan cuenta de que devorar libros técnicos uno tras otro no aporta grandes beneficios si los nuevos conocimientos no se ponen a prueba en la práctica. Personalmente me he encontrado con esto más de una vez. Si dedicas mucho tiempo a un libro pero no practicas nada de él, casi todos los conocimientos recién adquiridos se olvidan: sólo te queda un vago recuerdo general de cómo funciona todo. El resultado es una gran pérdida de tiempo sin resultados tangibles. ¿Por qué deberíamos perder el tiempo? La vida no dura para siempre. La conclusión es que cuando estás aprendiendo una nueva tecnología, no debes obsesionarte con la teoría: escribe los ejemplos dados en paralelo con tu lectura, experimenta con la nueva tecnología. Esta es la única manera de lograr que su cerebro retenga la información. Sí, consumirás nuevos materiales mucho más lentamente, pero asimilarás mucho más de lo que lees. Es más, si dominas bien una tecnología, la siguiente será aún más fácil de dominar (como ocurre con el aprendizaje de idiomas).

22. Perfeccionismo excesivo

La mayoría de los desarrolladores son perfeccionistas: personas que luchan por alcanzar la perfección. Esto significa que su código también debe ser perfecto. Entonces su código ha sido escrito, probado, ajustado y parece que es hora de enviarlo a la rama principal. Pero todavía no estás satisfecho con el código, así que empiezas a torcerlo de un lado a otro, dedicando mucho tiempo a este esfuerzo. Y en este caso, el tiempo es dinero de su cliente. Los programadores novatos son más susceptibles a esta búsqueda de la perfección. Los desarrolladores experimentados están acostumbrados a la sensación de que el código nunca será perfecto y que deberían intentar escribirlo mejor. Pero al mismo tiempo no llegan a los extremos en un esfuerzo por acercarse a "lo ideal". Entonces, recuerde aprender cómo lograr un punto medio: no de manera descuidada y sin intentar recrear la Mona Lisa en código.

23. No pensar en la arquitectura

Déjame decirlo de nuevo: no debes escribir código desordenado. Además de la legibilidad y el rendimiento, también debes pensar en cómo tu código podría afectar al resto de tu aplicación en su conjunto. Por ejemplo, qué tan difícil será ampliar su código, etc. El problema es que los desarrolladores novatos, debido a su falta de experiencia, pueden no darse cuenta de inmediato de cómo afectará su nueva funcionalidad a la aplicación en el futuro. Sin duda, desarrollar esta previsión requiere mucha práctica. Pero ¿qué deben hacer entonces los novicios? ¿No escribir código? En estas situaciones, varios paradigmas de programación vienen en nuestra ayuda. Por ejemplo, principios SOLID o varios patrones de diseño que pueden transmitirle prácticas útiles. Estos paradigmas también deben tratarse con cautela y no llevarse demasiado lejos. Pero, ¿cómo se determina el punto en el que se está exagerando? Aquí es donde le ayudará una revisión del código por parte de un colega con más experiencia. Al aportar una mirada fresca y objetiva, su colega podrá indicarle la dirección correcta.

24. Síndrome del impostor

El síndrome del impostor es un fenómeno psicológico en el que una persona es incapaz de atribuir sus logros a cualidades, habilidades y esfuerzos personales. A pesar de la evidencia externa de su desempeño consistente, las personas susceptibles a este síndrome continúan creyendo que son fraudes y no merecen el éxito que han logrado. Muchos desarrolladores tienen este síndrome. Quizás nos brinde la persistencia que nos impulse hacia nuevos conocimientos y tecnologías. Miras a colegas con más experiencia y logros y te sientes incómodo, como si no valieras tu salario. Créame, esto no es cierto. Hay y siempre habrá desarrolladores mejores o peores que tú. Alguien más te mira y se siente incómodo, pensando que nunca llegará a ser como tú. Y esto es normal. Los comentarios de su equipo, las revisiones de código y las discusiones ayudan a combatir un poco este sentimiento. Créame, la opinión de un extraño le sorprenderá gratamente, pero sólo si realmente no descuida su trabajo y su desarrollo profesional. Si descuidas esas cosas, entonces has elegido la profesión equivocada. En esta profesión, siempre es necesario aprender algo nuevo y esforzarse por lograr lo mejor. Pero creo que la gente que se reúne aquí está lejos de ser vaga. En cambio, la gente aquí avanza firmemente hacia su preciado objetivo. Si eso te describe, entonces no tienes nada que temer.

25. Rara vez se compromete

¡Recuerde realizar confirmaciones con frecuencia! No cada media hora, eso sí. Si pasa una semana implementando alguna funcionalidad, entonces no debe realizar una confirmación el viernes por la noche, sino, digamos, cinco confirmaciones. Casi cualquier tarea grande se puede dividir en tareas más pequeñas para mayor comodidad. Entonces completa estas tareas más pequeñas y te comprometes. Y no olvide enviar estas confirmaciones al servidor remoto de inmediato. De lo contrario, podrías realizar compromisos durante toda la semana y luego tu computadora sufrirá una falla de hardware el viernes a la hora del almuerzo, ¡y entonces habrás perdido toda una semana por nada! Pero si cargó sus confirmaciones en un servidor remoto, simplemente trasladará la rama con su última confirmación a otra computadora y continuará trabajando. Una cosa más: no envíe nuevas funciones a un servidor de producción en vivo el viernes por la noche. Solo confía en mi. No necesitas eso. Es muy probable que salgan a la luz errores inesperados y pases el fin de semana solucionándolos. Y eso no es divertido. Necesitas descansar el fin de semana. Supongo que eso es todo por hoy. PD: Un último consejo: escribe mucho código. PPS Escriba una cantidad INCREÍBLEMENTE grande de código, porque esa es la única manera de obtener la experiencia que tanto necesita.