LAS 9 COSAS MÁS DIFÍCILES QUE TIENEN QUE HACER LOS DESARROLLADORES

Como cualquier estudiante de ingeniería tuve que cursar un asignatura de informática básica. En mi primera universidad en vez de dar Basic o C++, las clases giraban en aprender a programar con Pascal. Era Computación I y II y no os puedo negar que tuve que tomarme más de un café o pincharme con el lápiz para no dormirme. Pero esa no es la cuestión. Este artículo es sobre las tareas más difíciles que tienes que hacer cuando te sientas a programar.

Phil Johnson, columnista de  ITWorld   investigó un poco y descubrió a través de hilos de conversación en Quora y un foro de Ubuntu (tomó en cuenta los comentarios de aproximadamente 4500 desarrolladores) que lo que más cuesta es:

1. PONER NOMBRES

Sí, elegir los nombres de las variables, funciones, clases, objetos…es lo que consideran más difícil la mayoría de los programadores. Seguro pensabais que era documentar el código o el tener que usar el trabajo de otro, ya que suele ser el debate común cuando hablamos de programación.

Una buena elección de los nombres, que transmitan lo que hacen y que sean concisos son vitales cuando se desarrolla, incluso si es un programa pequeño o una aplicación.

Sólo hay dos cosas duras en Ciencias de la Computación: Invalidar una memoria caché y nombrar las cosas.

Es una de las cosas más importantes, si quieres que tu código sea legible por otros.

2. EXPLICAR LO QUE SE HACE (O NO SE HACE)

¿Quién entiende el arte de la programación? Solo los programadores. Para algunos es difícil hacer entender a sus familiares y amigos (no programadores) lo que conlleva su trabajo. Todos piensan que puedes solucionar cualquier problema relacionado con la informática.

El intento de explicar a (casi todo el mundo) que no sé cómo arreglar su ordenador.

3. LA ESTIMACIÓN DEL TIEMPO PARA COMPLETAR LAS TAREAS

Un programador puede pasar varias noches picando código para cumplir con los plazos de entrega de un proyecto. En el comienzo nunca se saben los imprevistos que pueden ocurrir.

Resulta extremadamente difícil estimar cuántas sorpresas a un problema de programación se presentarán cuando el trabajo sea llevado a la práctica.

4. TRATAR CON OTRAS PERSONAS

Explicar tecnicismos a personas sin conocimientos técnicos. Hay que proporcionar informes sobre el estado de la gestión, consultar con otros ingenieros sobre el proyecto, estar de acuerdo con otros desarrolladores…

Es mucho más fácil convencer a un procesador que haga lo que quiero que a algunas personas.

Lidiar con ingenieros tratando de decirme cómo escribir código…

5. TRABAJAR CON EL CÓDIGO DE OTRO.

Tener que entender, depurar o mejorar la aplicación o trozo código de otro, además de adivinar las intenciones del desarrollador original. Y si el código está mal escrito, comentando o documentado, el trabajo es mucho más tedioso.

Vivir con el código de alguien que en principio no estaba tan calificado para escribirlo.

Tratar de descifrar miles de líneas de código sin comentar.

6. LA IMPLEMENTACIÓN DE UNA FUNCIÓN CON LA QUE NO SE ESTÁ DE ACUERDO.

Tener que implementar una característica o función que, por cualquier razón, sientes que no debe ser incluida, pero que el cliente, o alguien por encima de tu nivel, insiste en incorporar.

7. LA DOCUMENTACIÓN

Crear la documentación que explique lo que hace el código o cómo funciona una aplicación. Puede ser una tarea que consuma mucho tiempo, que pueda sentirse como una pérdida de horas si nadie la va a leer.
No un secreto que muchos programadores suelen preferir escribir código que documentarlo.

Tener que escribir documentos inútiles que nadie va a leer o usar, sólo porque es parte del proceso.

¡Escribir una documentación que sea buena, explicativa y concisa, y todo al mismo tiempo!

En Geeky Theory hemos escrito sobre este tema, te recomendamos: Comentar o no comentar el código, esa es la cuestión y Un código autodocumentado.

8. PRUEBAS

Tener que escribir pruebas para pequeñas unidades de código y asegurarse de que funcionan correctamente. Estas pruebas ayudan a dar cuerpo a errores desde el principio del proceso y pueden facilitar el testeo cuando el código se modifica o se actualiza.

9. EL DISEÑO DE UNA SOLUCIÓN

Tienes un conjunto de requisitos y eres el arquitecto que debe diseñar una solución técnica e implementarla. Además de satisfacer las necesidades del cliente y cumplir con el plazo requerido.

Pensar en cómo ir del punto A y terminar en el Z es la parte más difícil.

Es difícil anticipar cómo serán las cosas en realidad antes de empezar a trabajar en ello.

Conclusión: Resulta que realmente escribir código no es una de las partes más difíciles de la programación.

Muchos diferirán del orden, en mi caso, el punto 9 y el 1 eran los que más me costaban —no tengo el ADN coder—.

Y a vosotros, ¿qué os cuesta más? ¿O que agregaríais?

Fuente: LifeDev