Debes DETENER estos MALOS hábitos de desarrollador AHORA

Todo buen trabajo de software comienza rascando el picor personal de un desarrollador

"Chupas a Ravi. Te estás poniendo difícil todos los días ". Dijo Jim, mi manager hace unos años .

Me sorprendió. Sorprendida sería la palabra más adecuada para describir mis emociones.

" Bueno Jim, no estoy seguro de por qué piensas así ", dije en voz, apenas disimulando mi sarcasmo.

" Soy un gran desarrollador y un activo muy valioso para mi equipo. El cliente está literalmente comiendo de mis manos y en conocimiento, estoy muy por delante de mis contemporáneos ".

Cada vez estaba más enojado.

" Este mismo" PENSAMIENTO "es tu problema Ravi y, a menos que hagas algo al respecto rápidamente, nunca llegarás al pináculo de GRANDEZA . "Jim dijo, mirándome directamente a los ojos.

Estaba estupefacto, enojado y confundido, todo al mismo tiempo viendo la audacia de su declaración

Resistí la tentación de TORMENTARSE FUERA de la habitación mientras le permitía dar sus razones:

"Mi código es el MEJOR"

Friedrich Nietzsche lo clavó cuando dijo.

"Cada vez que escalo me sigue un perro llamado 'Ego'".

El tipo de personas que todos los equipos necesitan son personas humildes, hambrientas e inteligentes: humildes y ego pequeño, centrándose más en sus compañeros que en sí mismos. Hambrientos, lo que significa que tienen una fuerte ética de trabajo, están decididos a hacer las cosas y contribuir de cualquier forma que puedan . Inteligente, lo que significa que no es inteligente intelectualmente, sino que es personalmente inteligente.

No critiques el código de los demás, podría ser tuyo el que esté en el punto de mira. Intenta hacer observaciones objetivas y profesionales en su lugar, pero no juzgues. Sé humilde e intenta aprender de todos los que te rodean.

Recuerda siempre, tu ego es un obstáculo para tu trabajo. Si comienzas a creer en tu grandeza, es la muerte de tu creatividad. Su aprendizaje se detiene el día que comienza a creer que no hay nada más que aprender.

"Puedo arreglar esto en un santiamén"

Angela Duckworth dijo una vez.

"No hay atajos para la verdadera excelencia".

Hazte un favor. Date permiso para sacar el máximo provecho de tu vida. Si pasas todo el tiempo fregando esquinas con un cepillo de dientes, estás perdiendo el sentido. Tomar atajos no significa atajar el resultado final.

Tomar atajos es muy tentador, todos lo han hecho. En realidad, hay situaciones en las que son necesarias, pero en general, son peligrosas, muy peligrosas y deben evitarse. Un atajo que sale mal puede ahorrarle unas horas pero puede causar meses de dolor y pérdida de reputación.

Toma mi consejo en serio. Aprendí por las malas que tomar atajos y vivir gratis no es realmente vivir libre.

"Lo recuerdo todo. No necesito documentar ".

Dick Brandon se golpeó con la uña cuando observó.

"La documentación es como el sexo; cuando es bueno, es muy, muy bueno, y cuando es malo, es mejor que nada ".

La documentación es el aceite de ricino de la programación. ¡Los administradores piensan que es bueno para los programadores y los programadores lo odian!

Pero todo dicho y hecho, los GRANDES desarrolladores lo convierten en una parte intrínseca de su rutina diaria.

Se dan cuenta de que, al igual que con cualquier función comercial, los equipos de desarrollo de software siempre están en constante cambio. Los programadores pueden cambiar de trabajo, pasar de un departamento a otro o retirarse. En el peor de los casos, las enfermedades, las lesiones o la muerte pueden marginar a los miembros del equipo cuando menos lo esperas. El código también envejece; los desarrolladores pueden olvidar fácilmente cómo funciona su propio código si no lo han tocado durante un año o más.

En cualquiera de estos escenarios, tener acceso a documentos de diseño, especificaciones de API, páginas de manual y comentarios de código puede significar la diferencia entre un producto de envío y una fecha de vencimiento.

Y esta actitud es lo que los hace un activo valioso para el equipo. No te vuelves " irremplazable " al no documentar intencionalmente nada. Todo lo que terminas se está convirtiendo en una responsabilidad " irreparable " para tu equipo.

"¡No fui yo!"

Bruce Lee ha dicho con razón.

"Los errores siempre son perdonables, si uno tiene el coraje de admitirlos"

Quizás esta declaración anterior no puede ser subestimada y es una de las características más importantes de un desarrollador realmente GRANDE.

Siempre tenemos una excusa … Es como si dijéramos que en condiciones normales nunca cometeríamos un error, lo que honestamente es bastante difícil de creer.

Los malos desarrolladores culpan a los clientes por no usar el producto " correctamente ". Un desarrollador malo no se responsabiliza de todo el producto y los errores. Se aseguran de que todos sepan exactamente quién fue el responsable cuando un error fue creado por otra persona.

¿Cuál es la necesidad de plantear todo este alboroto y perder el tiempo de todos en el proceso?

Tener una actitud saludable en la que podamos decir algo como: " sí, lo siento, ahora tenemos que hacer esto para solucionar este problema, mi culpa" lo ayudará a construir una reputación y a ser mejor considerado por sus colegas. Cuanto antes admitas tus errores, más tiempo tendrás para aprender y rectificar lo mismo. ¡¡¡Simple como eso!!!

Tu "HECHO" no está Hecho.

Rick Lemons observó correctamente cuando dijo.

"No haga que el usuario proporcione información que el sistema ya sabe".

Si la programación fuera sexo, habría muchas computadoras insatisfechas. Simplemente no puedes entrar, hacer las cosas a la mitad y luego quedarte dormido. Uno de los conceptos con los que te encuentro luchando es el concepto de " Hecho ".

Recuerde que hacerlo significa: probado y aprobado por el usuario según sus requisitos. No se HACE desde su final para ser considerado hecho .

Un buen desarrollador está ansioso por aprender cosas nuevas. Se esfuerzan por comprender cómo todas las piezas de la arquitectura trabajan juntas y en qué estado se encuentran. Cuestionan el diseño y las ideas detrás de las características para resolverlas. Ellos entienden lo que hace una buena experiencia de usuario.

Un mal desarrollador, por otro lado, está conectado a su tecnología favorita. Creen que un único método o proceso es el " ideal ", y que la experiencia y la situación del usuario nunca deberían conducir decisiones. Traen dependencias innecesarias en el proyecto para adaptarse a sus preferencias.

Un mal comportamiento del desarrollador como este es como un toro en una tienda en China. Solo la destrucción del tiempo, los esfuerzos y la reputación prevalecen al final.

Los proyectos exitosos son aquellos que son aceptados con los ojos vendados por los usuarios finales y se vuelven parte de su ADN que funciona.

Juntando todo

Entonces, ¿cuál es la única palabra que resume todo aquí?

La respuesta es Actitud.

Tener una gran actitud es mejor que cualquier cantidad de años de experiencia en cualquier momento.

Solo el trabajo no es suficiente, debes tener una actitud correcta en el trabajo y en lugar de tener una habilidad correcta, la actitud correcta es mucho más importante. Si tomas algo que te gusta hacer como profesión, generalmente se dice que te encantará hacerlo y el trabajo nunca será monótono. Al ser un empleado, es muy importante que disemine el mensaje correcto en el lugar de trabajo.

Como Zig Ziglar ha resumido correctamente.

"Tu actitud, no tu aptitud, determinará tu altitud".

Sobre el Autor-:

Ravi Rajan es un gerente de programa de TI global con sede en Mumbai, India. También es un ávido bloguero, escritor de poesía Haiku, entusiasta de la arqueología y maníaco de la historia. Conéctese con Ravi en LinkedIn , Medium y Twitter .