10 grandes decepciones de los programadores


Para aquellos que no están relacionados con la creación de software, el trabajo del desarrollador puede parecer bastante sencillo: tiene una gran demanda en el mercado, pagan bien, las empresas intentan complacer los placeres agradables, etc. Todo esto es cierto, pero para ser sincero, el programador tiene muchos momentos desagradables. Hemos recopilado diez de las cosas más populares que con mayor frecuencia molestan a los fabricantes de software.


10. hierro



Por supuesto, los programas necesitan equipos para funcionar. Y no importa cómo algunos desarrolladores intenten ignorar la función del hardware, tarde o temprano al crear y depurar software, inevitablemente se encontrarán con problemas específicos del equipo. Por lo tanto, se recomienda a los principiantes que estudien siempre las características del hierro y los sistemas en los que se ejecutará su código, para que más adelante haya menos dificultades.


"Todo programador que haya depurado al menos una vez un extraño bloqueo en un servidor de base de datos o intente comprender por qué las unidades RAID no funcionan correctamente sabe lo dolorosos que son estos problemas de hardware". Steve borthwick


"¡Los programadores odian el hardware porque no siempre pueden echarle la culpa a todo!" Anónimo


9. Siéntate todo el día



Hasta que tenga una computadora de escritorio con una cinta de correr, el desarrollo de software nunca será como una especie de ejercicio aeróbico. La mayoría de los programadores pasan largas horas sentados sobre su trasero, tocando el teclado y mirando fijamente la (s) pantalla (s). Después de un tiempo, la sesión prolongada puede ser muy incómoda. Y si ni siquiera puede mudarse a otro lugar para cambiar los alrededores, esto a veces lo lleva rápidamente a la angustia.


“Me siento todo el día en una silla y miro la pantalla. Comenzó hace algún tiempo ... primero atrás, luego cuello, ojos cansados ​​y como si ardiera, dolor de cabeza ... no hay paz en las piernas ... Traté de compensar esto con ejercicio, taijiquan, yoga, qigong, fui a trabajar en bicicleta, y todavía no puedo seguir sentado. ocho o más horas. Para pasar todo el día en la oficina ... mira el sol atravesar el cielo, sin levantar la vista de esta maldita silla mientras la vida pasa ". Markus toman


8. Depuración



Incluso el mejor código cuidadosamente escrito no está exento de errores. Naturalmente, los desarrolladores se ven obligados a pasar regularmente tiempo buscando y reparando defectos, tanto en su código como en el de otra persona. Algunos errores se encuentran y se tratan fácilmente, mientras que otros pueden llegar al blanco con su evasión, obligándolos a pasar muchas horas y dudar de la estabilidad de su psique.


“¡Detección de un error difícil de reproducir o, lo que es peor, manifestado en un error de prueba de integración que pasa o falla accidentalmente en el mismo código! Entonces parece que nunca puedes encontrar estos malditos errores misteriosos escondidos en algún lugar del código. Fu! " Emmanuel ngwane


"Escribimos programas tan grandes (a veces también pequeños) que, al depurar, nos adentramos en tales comodines y nos olvidamos de cuál es el error" . Ayush Bhatnagar


“Depuración, especialmente cuando se trabaja en grandes proyectos de miles de líneas. Muchos geeks como yo prefieren mostrar la imagen a través del proyector al depurar, para que sea más fácil para los ojos ". Isaac perez


7. Mala documentación



Trabajar con el código de otras personas a veces es molesto, pero no tanto si está bien documentado. Desafortunadamente, este no es siempre el caso. Si no hay comentarios en el código o una explicación normalmente escrita de cómo funciona todo, debe pasar mucho más tiempo depurando, expandiendo o integrando la aplicación. Y esto no afecta el bienestar de los programadores de la mejor manera.


"Lo más molesto es cuando te contratan para lidiar con software mal documentado. Esto dificulta la vida de quienes aceptan el trabajo en el proyecto. Falta de comentarios y semántica deficiente, especialmente cuando quedaban muchos errores y errores después del programador anterior ". Angel Angeles III


"El juicio está en un código indocumentado y no comentado que algún idiota escribió". Abhishek chauhan


"Yo, como la mayoría de los programadores, paso más tiempo manteniendo códigos mal documentados que escribiendo nuevos". Walt karas


6. Fusión de código



Los sistemas de control de código fuente como Git o Subversion son excelentes herramientas que permiten a muchos programadores trabajar en la misma base de código al mismo tiempo, sin presionar los codos. Pero al final, los cambios deben comprometerse con el repositorio, y pueden surgir conflictos aquí si, por ejemplo, dos desarrolladores cambian un archivo o subrutina. A veces, tales conflictos se resuelven simplemente, a veces no.


" No me gusta fusionar, porque quiero cambiar el código para que mi colega quiera hacerlo de manera diferente, ¿y qué hacemos? "Siempre trato de encontrar formas de combinar ambas soluciones, pero si surge un conflicto real, la fusión se convierte en una tarea muy desagradable". Jessica su


"Conflicto de la fusión" mal absoluto " . Koustuv sinha


5. Expectativas poco realistas


Desarrolladores de software: la gente está lejos de ser estúpida. Pero precisamente por esta razón, todo tipo de jefes, gerentes de proyecto y vendedores a menudo muestran expectativas poco realistas y altas sobre lo que un programador o equipo de programadores pueden crear en una fecha determinada y, por lo tanto, planean demasiado. Como resultado, los desarrolladores eventualmente se agotan en el trabajo y generalmente no sienten placer por ello.


“Lo más desagradable es explicarle a la gente que no eres un mago, que tu conocimiento tiene límites, qué se puede lograr exactamente con la ayuda de las herramientas disponibles dentro del tiempo asignado, y tratar de transmitir todo esto a las personas que nunca han estado involucradas en la programación y no están ansiosas por hacerlo. " . Mark miller


"Su jefe espera mucho de usted y sus colegas, pero el tiempo y los recursos no son suficientes ni siquiera para acercarse a los resultados esperados". Kevin sekin


"Los gerentes de proyecto y los analistas de negocios prometen a los clientes sacar la luna del cielo, y los programadores deben hacerlo a toda costa" . Ratnakar sadasyula


"Me encanta cuando alguien pide hacer algo trivial, y luego presenta una demanda que la informática necesita desarrollar durante otros veinte años" . Vladislav Zorov


4. Otras personas rompen mi código



El código escrito por cualquier desarrollador, de una forma u otra, debe interactuar con el código de otros programadores. No importa si es parte de una aplicación, bibliotecas de terceros, herramientas u otra aplicación en general. Nuestro código no existe de forma aislada. Como resultado, alguien puede, por prisa, malentendido o descuido, romper el código de otra persona, lo que causa descontento, disputas, estrés y, a menudo, maldiciones.


“Lo peor que tuve fue cuando escribí un programa con una persona que, sin previo aviso, cambió la biblioteca a la que ambos nos referimos. Como resultado, mi subrutina invoca variables perdidas o las agrega. O, peor aún, el código de la biblioteca chocó contra el que no tenía acceso ". Sheri fresonke harper


“Cuando una parte de su código deja de funcionar porque alguien ha cambiado su parte del código. A menudo, sus funciones comienzan a requerir más argumentos que antes. A veces, las funciones generalmente desaparecen o se transfieren a otro archivo ". Jessica su


"La necesidad de volver constantemente y rehacer el código que escribió hace un par de días y que simplemente" se rompió "(no la primera vez) debido a los cambios realizados en el sistema general sin ninguna discusión por parte de alguien que ni siquiera ha probado o calificado que las pruebas fallan Y como resultado, le dicen que su código "no funciona" . Simon hayes


3. La gente no entiende lo que hago.


A pesar de la creciente popularidad de la profesión de programador y la ubicuidad del software, muchos profesionales no informáticos aún no entienden lo que los desarrolladores están haciendo realmente. Para ellos, solo somos "técnicos" y no ven mucha diferencia entre, por ejemplo, desarrolladores de software y hardware. El malentendido constante y las ideas inapropiadas, especialmente entre su familia y amigos, pueden volver loco a un programador.


“Entre las personas que no están relacionadas con TI, existe una idea errónea generalizada de que, dado que los programadores trabajan en computadoras, deberían poder repararlas. Esto es aproximadamente lo mismo que si condujera un automóvil, debería poder ordenar la caja de cambios ". Steve borthwick


“Sí, me gano la vida escribiendo código. No, no puedo ayudar a resolver el problema con la impresora, o al abrir el archivo adjunto a la carta, o por una computadora que no arranca. Al menos, hasta que me invites a almorzar o cerveza, entonces tal vez pueda ayudarte. Phil johnson


"Explique a las personas que no tengo en cada esquina una tienda que instale software pirateado en sus computadoras". Anbalagan jeyabalachandran


“La familia y los amigos piensan que puedo arreglar de forma remota todo lo relacionado con las computadoras. Tanto hardware como software. Ellos no entienden Como resultado, tienes que escuchar sus agudos comentarios como "qué tipo de programador eres, incluso si no puedes arreglar la unidad de DVD en mi computadora portátil". Jazib babar


"Solo el 1-2% de las personas saben lo que realmente hago". Yasin Pekşen


2. Falta de tiempo



Como con la mayoría de las otras áreas de negocios, crear un buen software lleva tiempo. Desafortunadamente, como en otros lugares, la gerencia y / o los clientes generalmente no quieren esperar lo suficiente para implementar correctamente la solución ideal. Como resultado, a menudo se insta a los desarrolladores a que sean más rápidos. Esto lleva al uso de hacks antiestéticos, a deudas técnicas, documentación deficiente. A su vez, las consecuencias descritas causan dolor de cabeza durante las mejoras y el mantenimiento posteriores, especialmente para los programadores que tienen que lidiar con el código listo para usar.


“Quiero hacer todo bien , pero debido a la presión tengo que hacerlo a toda prisa. A veces esto está justificado, pero la sensación de que la cultura de programación moderna ha ido demasiado lejos en esta dirección no se va ”. Tikhon jelvis


“Lo peor para mí es escribir apresuradamente código desordenado y saber que podría hacerlo mucho más elegante. Constantemente presionado por la falta de tiempo ... " Gene Sewell


"... Cuando gran parte de lo que haces ni siquiera se parece remotamente a buenas técnicas de programación, y solo porque la velocidad es más importante que la calidad, tienes que hacer lo que pides". Jose Palala


"... Siempre no hay suficiente tiempo y dinero para crear la solución correcta, pero siempre son suficientes para corregirla más adelante, una y otra vez" . Romi awasthy


1. Trabaja con el código de otra persona



Tarde o temprano, los desarrolladores de software tienen que lidiar con el código escrito por otra persona. Ya sea que se trate de un código heredado heredado de un predecesor en el trabajo, o de una API de terceros, o un código escrito por un consultor, no podrá evitar por completo la necesidad de arreglar, extender y / o integrar el programa de otra persona. Y esto a menudo hace que los desarrolladores se quiten el cabello de la cabeza.


“... Lo peor es escalar el código alienígena, comprenderlo, depurarlo, configurarlo. Y es completamente oscuro cuando la persona que lo escribió renunció y no lo ayudará de ninguna manera ". Ratnakar sadasyula


"Tratando de descifrar miles de líneas de código no documentado". Simon zhu


"Hubo momentos en que tuve que lidiar con el código IMPRESIONANTE escrito por consultores". Joe samson


“Otro problema que puede ser muy frustrante son las API de terceros. A veces confía en gran medida en ellos, y luego nota un problema, o se necesita algún tipo de funcionalidad, pero la API no permite resolverlo usted mismo, por lo que debe ponerse en contacto con el autor y esperar lo mejor ". Kevin sekin


“Errores de lenguaje y marco. Pasas días tratando de descubrir por qué tu código no funciona. Y solo para descubrir que todo es un error en el lenguaje o el marco ” . John paul alcala


"Para descubrir el código escrito por alguien que no tenía las calificaciones adecuadas para crearlo ..." Nani Tatiana Isobel




¿Quizás hay algo más en tu top 10? Bienvenido a los comentarios :)

Source: https://habr.com/ru/post/es410621/


All Articles