¿Es malo que odie tanto trabajar con el código de algunos de mis compañeros de trabajo que quiero renunciar?

Muy común. Algunos trabajos atrás tuve que trabajar con código escrito por un programador principiante. Uno cuyo entrenamiento fue en una escuela de programación de juegos de Florida. Puedes imaginar la calidad del código. Habían pasado meses poniendo bloques try / catch. En realidad, no descubrí cuáles eran los problemas, solo descubrí los errores.

El código horrible es muy común. O los programadores eran pésimos, o los gerentes los forzaron a escribir de esa manera, o el programa se ha expandido poco a poco a lo largo de los años en un horrible desastre.

Por lo tanto, no es inusual sentirse de esa manera. Sus opciones son bastante obvias: busque otro trabajo, con suerte uno en el que pueda escribir código nuevo de la manera que desee, que generalmente solo sucede en empresas y startups muy pequeñas y nuevas, o puede intentar convertirlo en un juego, ver si Puedes ver el lado divertido de todo el código torpe y con errores. Piense exactamente lo que sus gerentes quieren que haga, y vea si puede encontrar la manera de hacer la mayor parte de eso sin vomitar. A veces, todo lo que se necesita es un cambio de actitud, un paso atrás y darse cuenta de que en 5 años a nadie le importará de todos modos. Casi todo el gran drama que me enfureció hace 5 años ya no significa nada. En ese momento parecía realmente importante que los puntos y comas estuvieran alineados “a mi manera”, pero realmente no importaba mucho en ese momento, y no importa en absoluto ahora. En otras palabras, trate de relajarse.

Me reí en voz alta cuando leí esto. Si no supiera que mi amigo no era usuario de Quora (¡blasfemia, lo sé!), Juraría que eras él. Su situación es similar en lo que respecta al código, pero empeoró porque tiene que lidiar con el código de su jefe. Esto significa que su código siempre está bajo amenaza de veto y que el poder se usa a menudo.

No está mal que odies trabajar con el código de tu compañero de trabajo si, y solo si, dicho código de compañero de trabajo está mal escrito, es ineficiente y está producido por una personalidad que no está dispuesta a cambiar. Si este es el caso, entiendo totalmente tu dolor. Es difícil trabajar con estas personas. Se desperdicia tiempo y recursos al depurar, mantener y / o refactorizar su código. Combine todo esto con su negativa a aprender / cambiar y tendrá motivos para sacarlos por la puerta.

¿Duro? Tal vez. Si estamos juntos en un barco y tú eres el tipo que está destrozando el casco, haré todo lo que esté a mi alcance para que te detengas o te arrojes por la borda. Cada persona que lea esto haría lo mismo. Nadie quiere que el barco se hunda y los malos desarrolladores pueden tirar de ti. Esto es especialmente cierto en las startups donde la eficiencia es clave para el éxito.

Ahora, todo lo que he dicho hasta ahora trata de que el “otro tipo” es un mal desarrollador. Sin embargo, no sería justo para mí asumir que todo es culpa de este tipo, ¿verdad?

¡Tiempo de cuentos!

Empecé a escribir código hace 18 años. Durante este tiempo, he escrito código en muchos idiomas diferentes. El lenguaje más molesto que encontré fue Ruby. Espera, no abuses de tu teclado todavía. Amo absolutamente a Ruby. Me interesó escribir código nuevamente. Sin embargo, al principio, tenía muchos pensamientos violentos hacia Matz. Nada tenía realmente sentido porque estaba tan atascado en mis formas que no me permitiría ver que tenía sentido absoluto. Ahora, realmente no me gusta escribir código en ningún otro idioma con fecha.

Sin embargo, hay peculiaridades cada vez que entras en un nuevo idioma y muchas personas llevan sus viejas prácticas al idioma que acaban de aprender.

“Puede que no sea una práctica sugerida, pero funciona bien a mi manera, ¿por qué cambiar?”

Esta actitud me vuelve loco y lo he visto mucho. Trataré de ayudar y señalar los errores de las formas del individuo, pero a veces no funciona. Querrán argumentar que su camino está bien y que no deberían cambiar. Tenemos que pasar por todo el desorden de la evaluación comparativa, el diseño, etc. De alguna manera soy el malo porque tomé sus más de 20 métodos de línea, los separé correctamente y ahora tienen una cadena a seguir en lugar de 1 gran pila de basura rellena en un archivo singular. Sí, me odian. Si aprendieran algunos estándares, entonces nos llevaríamos de maravilla. Sin embargo, están atascados en sus caminos, se niegan a aprender y me culpan por su mal código. Todos se encontrarán con al menos una de estas personas en su carrera.

Los codificadores malos se niegan a aprender. Los codificadores malos, que fingen ser buenos, se niegan a guiar a aquellos con menor habilidad.

Los grandes programadores aprenden a adaptarse, guiar y seguir avanzando (mientras llevan a su equipo con ellos).

Son las 2 de la madrugada y no tengo idea si algo de esto tiene sentido. Espero que lo haya hecho.

El problema de trabajar con código incorrecto es que, con el tiempo, inconscientemente también adoptas malos hábitos y te configura como desarrollador. Otro aspecto es el código decente pero la arquitectura deficiente y la falta de mejores prácticas simples (1000 líneas de lógica de negocios en un controlador). Cuando los desarrolladores pasan años manteniendo el desorden de otros desarrolladores, nunca aprenden realmente a diseñar software, nunca saldrás de eso mientras sigas complaciente. Si el entorno actual le impide practicar un buen diseño y prácticas de software, entonces lo mejor que puede hacer para su carrera es moverse uno. Acabo de dejar un contrato muy lucrativo en una gran empresa aeroespacial porque no pude retroceder en el tiempo 10 años.

En tu lugar, renunciaría. De hecho, ahora estoy cambiando de trabajo a una compañía en otro país que dejó en claro que el código limpio y las pruebas son tan importantes para ellos como lo son para mí. Considero que el código limpio y el código comprobable son las marcas de la profesionalidad. No solo para desarrolladores, sino también para empresas.