Los malos programadores no son estúpidos en absoluto. Simplemente tienen malos hábitos.

Algunos programadores son mejores que otros. Hay una especie de estadística: un pequeño grupo de programadores está en el nivel "excelente", un grupo un poco más pequeño es simplemente bueno, la mayoría de los programadores son al menos competentes, algunos apenas llegan al nivel anterior y alguien es absolutamente terrible.

El punto es que la diferencia entre un buen y un mal programador no es necesariamente la capacidad de escribir código. Todo es mucho más sencillo: los malos hábitos . Es difícil lidiar con ellos tanto en la vida como en el trabajo.

Es fácil quedar atrapado en este tipo de hábitos mientras juegas con el código, lo que a su vez te impide desbloquear todo tu potencial. Si algunos hábitos ayudan a agilizar el trabajo, otros pueden perjudicar tu negocio y tu vida personal.

A menudo no los notamos, por lo que necesitamos ayuda externa. Como en la vida, no hay reglas estrictas e inequívocas en la programación. Para lograr algo, es necesario improvisar.

Analicemos algunos malos hábitos de programación de los que debe deshacerse lo antes posible.

Mi código es el MEJOR

Federico Nietzsche dijo:

No importa qué montaña escale, siempre me sigue un perro llamado "Ego".

Todo equipo necesita gente así: humilde, hambrienta e ingeniosa. Los humildes tienen menos ego, su enfoque está hacia afuera, en el equipo, y no en ellos mismos. Los hambrientos se distinguen por una actitud seria hacia el trabajo, están obsesionados con el resultado, listos para cualquier cosa. La inteligencia se refiere a la inteligencia, no a la inteligencia.

No critique el código de otra persona sin medida, porque el suyo también puede estar bajo ataque. Repito, no juzgues, pero trata de analizar objetivamente, desde un punto de vista profesional. Sé humilde, trata de aprender en todas partes y en todas partes.

Recuerde que su ego puede interponerse en el camino de un buen trabajo. La creencia excesiva en la propia superioridad es la muerte de la creatividad. Debido a la creencia de que ya dominaste todo, pierdes la oportunidad de aprender algo nuevo. 

Lo arreglaré en un segundo.

La psicóloga y autora Angela Duckworth dijo una vez:

"El camino fácil no conducirá al verdadero éxito".

Hazte un favor y permítete sacarle el máximo partido a la vida. Si pasa todo su tiempo libre fregando las mismas esquinas con un cepillo de dientes, corre el riesgo de perder el punto. Un camino corto no siempre conduce a un resultado rápido y mejor.

La búsqueda de soluciones fáciles es muy tentadora, de una forma u otra, todo el mundo recurre a esto. De hecho, a veces ese enfoque es necesario, pero en general es peligroso. Debe evitarse deliberadamente. Un camino potencialmente fácil ahorrará un par de horas, pero los problemas ignorados pueden surgir más tarde, lo que de una forma u otra resultará en meses de angustia y pérdida de reputación.

Toma mi consejo en serio. Fue difícil para mí darme cuenta de que los atajos y la vida libre no es libertad en absoluto.

Recuerdo todo. no necesito documentacion

Dick Brandon fue muy acertado en este tema:

"La documentación es como el sexo: cuando es buena, es muy, muy buena, pero cuando es mala, es mejor que nada".

La documentación es una especie de aceite de ricino de programación. Los gerentes están seguros de que la documentación es una panacea para los programadores, y estos últimos la odian abiertamente.

De una forma u otra, la documentación es una parte integral de la vida de los grandes desarrolladores.

Entienden que, como cualquier otro proceso comercial, la interacción dentro del equipo de desarrollo ocurre en un flujo. Un programador puede cambiar de trabajo, mudarse a otro departamento, renunciar. En el peor de los escenarios: enfermedad, lesión o muerte pueden privar al equipo de un participante en el momento más inesperado.

O el código puede estar desactualizado. Es fácil para un desarrollador olvidar exactamente cómo funciona el código de hace un año si no lo ha tocado en ese tiempo.

En cualquier caso, el acceso a la documentación, las especificaciones de la API, los manuales o los comentarios en el código pueden ser determinantes para determinar el resultado: o se implantará con éxito el producto o se incumplirán los plazos.

La responsabilidad es lo que se valora en un equipo. No te vuelves " indispensable " solo porque no escribes documentación. Todo terminará con una irreparable pérdida de reputación en el equipo y más problemas.

¡No soy yo!

Como bien dijo Bruce Lee:

"Los errores siempre se perdonan si tienes el coraje de admitirlos".

Esta idea puede no ser fácil de aceptar, pero expresa una de las características clave de un desarrollador realmente bueno.

Siempre tenemos derecho a equivocarnos. Es difícil creer que bajo todas las demás condiciones normales, no tenemos la más mínima posibilidad de estar equivocados.

Los malos desarrolladores culpan a los usuarios por el uso " incorrecto " del producto. Los malos desarrolladores no están dispuestos a asumir la responsabilidad por el resultado de su trabajo y errores. Harán todo lo posible para convencer al público de que otra persona es la causa del error.

¿Y qué sucede como resultado de este cambio de culpa? Nada.

Es importante hacer frente a lo que está sucediendo. Una simple confesión, como: “ Oh, lo siento, esto es realmente un error, lo arreglaremos ahora. » - salvará la cara y obtendrá la ubicación de la audiencia.

Cuanto antes admita un error, más tiempo tendrá para corregirlo. ¡¡¡Todo es sencillo!!!

Tu "Terminado" está lejos de la realidad

"No fuerce al usuario a ingresar información que el sistema ya conoce".

Si hacemos un paralelo entre la programación y el sexo, hoy en día hay muchas computadoras insatisfechas. Como si te detuvieras a mitad de camino y cayeras en un sueño. Uno de los conceptos más importantes que estoy tratando de transmitirles es el factor Listo .

Recuerde, esto significa un programa que ha sido probado, satisface las necesidades de los usuarios y ha sido probado en acción. “ Creo que ya está hecho ” y “ Ya está hecho ” son conceptos fundamentalmente diferentes.

Un buen desarrollador se esfuerza por aprender constantemente algo nuevo. Anhela entender cómo interactúan las piezas del rompecabezas arquitectónico. Revisa y reelabora diseños, ideas, conceptos de características para encontrar la mejor solución. Él entiende lo que crea una experiencia de usuario positiva.

Por otro lado, un mal desarrollador se apega a una tecnología, su favorita. Está seguro de que solo así es " perfecto " y que la decisión no debe venir de las circunstancias de una situación particular, ni de la experiencia del usuario. Introduce dependencias innecesarias en el proyecto, siempre que coincida con sus preferencias.

Un mal revelador es como un elefante en una tienda de porcelana. Es destructivo, gasta su fuerza y ​​arruina su reputación.

Conclusión

Entonces, ¿qué palabra puede combinar todo lo anterior?

La respuesta simple es "aproximación".

Un enfoque responsable del trabajo puede incluso compensar la falta de muchos años de experiencia.

Simplemente trabajar no es suficiente, debe adherirse al enfoque más responsable. Y a veces la actitud correcta es muchas veces más valiosa que las habilidades bombeadas.

Tener la actitud correcta, junto con una mentalidad optimista, se reflejará en su estilo de trabajo y aumentará en gran medida su productividad. Esto determinará qué resultados logrará y cómo lo tratarán otras personas. Una buena actitud es contagiosa. Te cambia primero a ti y luego a tu entorno.

Me gustaría terminar con una cita de Zig Ziglar:

"Tu enfoque, no tu habilidad, determina tu nivel".

Compartir:

0 comentarios

Deja una respuesta

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.