Es probable que en su día a día los programadores enfrenten una gran variedad de momentos y situaciones que genere estrés, con cuestiones tan sencillas como que falte un punto y coma, que el código no compile o el alguna situación con sus compañeros de trabajo o algún supervisor.

Para reflexionar un poco en torno a estas cuestiones, Phil Johnson, editor en ITworld, que cuenta con más 17 años en la industria corporativa como desarrollador de software / web, director técnico y gerente de proyectos comparte algunas experiencias y momentos que más causaron frustración en su desarrollo profesional.

La gente asume que puedes solucionar cualquier problema relacionado con la computadora. Sí, escribo código para vivir; no, no puedo ayudarte con tu problema de impresión o con el archivo adjunto que no puedes abrir o con el portátil que no se inicia. A menos que quieras comprarme un almuerzo o una cerveza, entonces quizás pueda ayudarte.

Los usuarios finales no brindan suficiente información sobre los errores. Gracias por el informe de errores, pero escribir simplemente «No funciona» no es tan útil. ¿Qué le parece decirme cosas como en qué pantalla estaba, qué medidas tomó, qué esperaba que sucediera y qué sucedió realmente, y qué mensaje de error (si lo hubo) que recibió? Nunca está de más incluir el navegador y el sistema operativo o la plataforma. Básicamente, al proporcionar más información por adelantado, nos ahorrará tiempo para tener que volver con «¿Y ahora qué estaba haciendo exactamente?» Y le ayudará a resolver su problema más rápido.

Almacenamiento de código en la base de datos: obtuve mi inicio como programador de PL / SQL, escribiendo procedimientos almacenados y desencadenantes y demás, y me gustó bastante. También entiendo la necesidad a veces pero cuanto más avanzaba, menos quería poner el código en la base de datos; hizo que la depuración y el mantenimiento del código fueran un dolor real. Es difícil superar la ejecución del antiguo comando de búsqueda cuando intenta rastrear el origen de un mensaje de error, por no mencionar la posibilidad de revisar los historiales de revisión de archivos y demás.

Personas que ignoran la documentación: parte de mi trabajo como desarrollador consistía en escribir documentación, a veces documentos técnicos para otros desarrolladores y, a veces, documentación para el usuario final. Fue escrito y puesto a su disposición por una razón; por favor, al menos darle un vistazo antes de venir a mí y pedirme que explique desde cero cómo funciona algo.

Los gerentes de proyecto ignoran o subestiman las estimaciones de tiempo para completar una tarea o proyecto. Si no te gusta el tiempo estimado que te he dado para saber cuánto tiempo tomará construir o codificar algo, hablemos de ello. No lo ignore o corte a la mitad y continúe con la planificación de su línea de tiempo. No saqué el presupuesto de la nada; se basa en mi experiencia y en algunos pensamientos cuidadosos.