¿Por qué los programadores trabajan mejor de noche?

programmer-night

Si coges a un programador al azar y le preguntas por sus hábitos de trabajo, es muy probable que responda que echa una gran cantidad de horas por la noche, y que estas suelen ser las que más cunden. Puede que algunos prefieran trabajar hasta altas horas de la madrugada, mientras que otros directamente opten por levantarse a las 4 y aprovechar para trabajar unas cuantas horas antes de que comience el ajetreo del día.

¿A qué se deben estos hábitos? ¿Fotofobia? ¿Genes de murciélago? ¿Anti sociales? ¡No! Como explica Business Insider, la principal razón que convierte a los programadores en seres nocturnos es la mayor facilidad para concentrarse a esas horas, y aislarse de cualquier tipo de distracción. Ni ruidos, ni whatsapps, ni actividad en las redes sociales, ni correos electrónicos… Visto de este modo, una habitación o una oficina de noche se convierte en un entorno idóneo para trabajar.

Una de las reglas de oro para aquellos que trabajen con programadores o tengan alguno en su entorno cercano es no distraerles jamás, y en el caso de hacerlo, prepararse para que se muestren molestos y enfadados (se han visto casos en que llegan a la agresión física). Su trabajo requiere una enorme inversión mental, y para lograr la concentración necesaria para empezar a rendir al máximo de su capacidad son necesarias en torno a un par de horas sin ser distraído.

Lógicamente, los programadores no son ninguna especie de súper humanos, y el cansancio también afecta a sus cerebros. Sin embargo, el artículo de BI sostiene que el cansancio mental ayuda a concentrarse, simplemente porque un cerebro agotado no tiene fuerzas para fijarse en otras cosas. Por eso mismo, no es aconsejable tomar bebidas energéticas o altas dosis de cafeína. Trabajar con el cerebro cansado permite concentrarse en el código durante horas, sin ni siquiera acordarse de la existencia de Twitter o Facebook.

Además, mirar la pantalla brillante del ordenador durante horas en una habitación con poca luz altera los ciclos de sueño. Por la misma razón que los especialistas en sueño recomiendan leer un libro antes de ir a la cama para dormir bien (en lugar de ver la tele, o mirar la pantalla del tablet o el smartphone), trabajar por la noche cambia los hábitos vitales, de modo que el cerebro se mantiene -un tanto artificialmente- alerta hasta las 3 o 4 de la madrugada, y termina acostumbrándose a ese ritmo.

Y por último, el poder trabajar por la noche es un punto a favor de los programadores, que enfocan su trabajo de una manera más relajada. A no ser que estén pendientes de la entrega de turno, su trabajo no exige ser acabado a una hora concreta ni seguir un esquema horario fijo. Y en realidad, no hay ningún problema en acostase a las 3 y despertarse a las 11 de la mañana.

97 cosas que todo programador debería saber

Traducción al Español del libro “97 Things Every Programmer Should Know”, contiene todo tipo de consejos y recomendaciones para los profesionales de la programación informática: refactorización, código limpio, pruebas, aprendizaje contínuo, etc. Índice

  1. Actúa con prudencia, por Seb Rose
  2. Adueñate (y Refactoriza) la compilación, por Steve Berczuk
  3. Antes de Refactorizar, por Rajith Attapattu
  4. Aplica los principios de la programación funcional, por Edward Garson
  5. Aprende a decir “Hola, Mundo”, por Thomas Guest
  6. Aprende a hacer estimaciones, por Giovanni Asproni
  7. Aprende un lenguaje extranjero, por Klaus Marquardt
  8. Aprende a usar las herramientas de línea de comandos, por Carroll Robinson
  9. Aprendiendo continuamente, por Clint Shank
  10. Automatiza el estándar de codificación, por Filip van Laenen
  11. Averigua qué haría el usuario (tú no eres el usuario), por Giles Colborne
  12. La belleza está en la simplicidad, por Jørn Ølmheim
  13. El camino al mejor rendimiento está lleno de sucias bombas de código, por Kirk Pepperdine
  14. Codificando con la razón, por Yechiel Kimchi
  15. Codifica en el lenguaje del dominio, por Dan North
  16. Codificación Ubuntu para tus amigos, por Aslam Khan
  17. El código es diseño, por Ryan Brush
  18. Comenta sólo lo que el código no dice, por Kevlin Henney
  19. Un comentario acerca de los comentarios, por Cal Evans
  20. ¿Cómo usar un Gestor de Errores?, por Matt Doar
  21. Conoce bien más de dos lenguajes de programación, por Russel Winder
  22. Conoce tu próximo Commit, por Dan Bergh Johnsson
  23. Conoce tu IDE, por Heinz Kabutz
  24. Conoce tus límites, por Greg Colvin
  25. La conveniencia no es una -bilidad, por Gregor Hohpe
  26. Cuando Programadores y Testers colaboran, por Janet Gregory
  27. Ten cuidado al compartir, por Udi Dahan
  28. Cumple tus ambiciones con Software Libre, por Richard Monson-Haefel
  29. Los grandes datos interconectados pertenecen a una base de datos, por Diomidis Spinellis
  30. Deja que tu proyecto hable por sí mismo, por Daniel Lindner
  31. El diseño del código sí importa, por Steve Freeman
  32. Distingue excepciones de Negocio de las excepciones Técnicas, por Dan Bergh Johnsson
  33. Dos cabezas son a menudo mejores que una, por Adrian Wible
  34. Dos fallos pueden hacer un acierto (y es difícil de arreglar), por Allan Kelly
  35. Lenguajes Específicos del Dominio (DSL), por Michael Hunger
  36. El mito del Gurú, por Ryan Brush
  37. El Programador Profesional, por Uncle Bob
  38. El trabajo duro no paga, por Olve Maudal
  39. Encapsula Comportamiento, no sólo Estado, por Einar Landre
  40. Escoge tus herramientas con cuidado, por Giovanni Asproni
  41. Escribe código como si tuvieras que mantenerlo por el resto de tu vida, por Yuriy Zubarev
  42. Escribe pequeñas funciones usando ejemplos, por Keith Braithwaite
  43. Escribe las pruebas para las personas, por Gerard Meszaros
  44. Evita errores, por Giles Colborne
  45. Haz lo invisible más visible, por Jon Jagger
  46. Haz mucha práctica deliberada, por Jon Jagger
  47. Las herramientas Unix son tus amigas, por Diomidis Spinellis
  48. Implementa rápido y con frecuencia, por Steve Berczuk
  49. Inicia con un Sí, por Alex Miller
  50. Instalame, por Marcus Baker
  51. Haz las Interfaces fáciles de usar correctamente y difíciles de usar incorrectamente, por Scott Meyers
  52. La comunicación entre procesos afecta el tiempo de respuesta de la aplicación, por Randy Stafford
  53. Lee el código, por Karianne Berg
  54. Lee las humanidades, por Keith Braithwaite
  55. El linker no es un programa mágico, por Walter Bright
  56. La longevidad de las soluciones provisionales, por Klaus Marquardt
  57. Mantén limpia la compilación, por Johannes Brodwall
  58. Mejora el código quitándolo, por Pete Goodliffe
  59. Mensaje al futuro, por Linda Rising
  60. No sólo aprendas el lenguaje, entiende su cultura, por Anders Norås
  61. No claves tu programa en la posición vertical, por Verity Stob
  62. No confíes en el “Aquí sucede la magia”, por AlanGriffiths
  63. ¡No ignores ese error!, por Pete Goodliffe
  64. No seas lindo con tus datos de prueba, por Rod Begbie
  65. No te repitas, por Steve Smith
  66. No tengas miedo de romper cosas, por Mike Lewis
  67. ¡No toques ese código!, por Cal Evans
  68. Los números de punto flotante no son reales, por Chuck Allison
  69. Oportunidades perdidas del Polimorfismo, por Kirk Pepperdine
  70. El paso de mensajes lleva a una mejor escalabilidad en sistemas paralelos, por Russel Winder
  71. Pensando en estados, por Niclas Nilsson
  72. Pon todo bajo Control de Versiones, por Diomidis Spinellis
  73. Da preferencia a tipos de Dominio Específico que los tipos primitivos, por Einar Landre
  74. Preocúpate por el código, por Pete Goodliffe
  75. El Principio de Responsabilidad Única, por Uncle Bob
  76. Programa en pareja y siente el flujo, por Gudny Hauknes, Ann Katrin Gagnat, y Kari Røssland
  77. Prueba el comportamiento requerido, no el comportamiento incidental, por Kevlin Henney
  78. Prueba precisa y concretamente, por Kevlin Henney
  79. Haz pruebas mientras duermes (y los fines de semana), por Rajith Attapattu
  80. Las pruebas son el rigor ingenieril del desarrollo de software, por Neal Ford
  81. Los registros detallados perturbarán tu sueño, por Johannes Brodwall
  82. La Regla Boy Scout, por Uncle Bob
  83. La regla de oro del diseño de API, por Michael Feathers
  84. Reinventa la rueda frecuentemente, por Jason P Sage
  85. Resiste la tentación del patrón Singleton, por Sam Saariste
  86. Retrocede y Automatiza, Automatiza, Automatiza, por Cay Horstmann
  87. Primero revisa tu código antes de buscar culpar a otros, por Allan Kelly
  88. Revisiones de código, por Mattias Karlsson
  89. La Simplicidad viene de la Reducción, por Paul W. Homer
  90. Sólo el código dice la verdad, por Peter Sommerlad
  91. Suelta el ratón y aléjate del teclado, por Cay Horstmann
  92. Noticias raras – Los testers son tus amigos, por Burk Hufnagel
  93. Toma ventaja de las herramientas de análisis de código, por Sarah Mount
  94. Tus clientes no quieren decir lo que dicen, por Nate Jackson
  95. Un binario, por Steve Freeman
  96. Usa el algoritmo y estructura de datos correcto, por JC van Winkel
  97. El WET dispersa los cuellos de botella en el rendimiento, por Kirk Pepperdine

Actúa con prudencia

Actúa con prudencia
Autor: Seb Rose

“En todo lo que emprendas, actúa con prudencia y considera las consecuencias”Anónimo

No importa qué tan cómoda se vea una agenda de trabajo al comienzo de una iteración, no podrás evitar sentirte bajo presión en algún momento. Si te encuentras en una situación en la que tienes que elegir entre “hacerlo bien” o “hacerlo rápido”, suele ser tentador “hacerlo rápido” y pensar que regresarás a corregirlo más adelante. Cuando te haces esta promesa a ti mismo, a tu equipo, al cliente, lo haces en serio. Pero a menudo la siguiente iteración trae nuevos problemas y te debes enfocar en ellos. Este tipo de trabajo aplazado se conoce como deuda técnica y no es un buen amigo. Martin Fowler, en su taxonomía de la deuda técnica, la llama específicamente deuda técnica deliberada, la cual no debería confundirse con la deuda técnica inadvertida.

La deuda técnica es como un préstamo: te trae beneficios en el corto plazo, pero deberás pagar intereses hasta terminar de saldarla. Tomar atajos a la hora de programar hace que sea más difícil agregar funcionalidad o refactorizar tu código; las soluciones rápidas son un caldo de cultivo para defectos y casos de prueba muy frágiles. Mientras más tiempo las abandones, peor se ponen. Para cuando te decidas a corregir el problema puede que haya toda una pila de malas decisiones de diseño acumulada encima del problema original, haciendo que el código sea mucho más difícil de refactorizar y corregir. De hecho, es sólo cuando las cosas están tan mal como para tener que arreglarlas, que realmente vuelves y corriges el problema. Pero para entonces suele ser tan difícil corregirlo que no te puedes permitir el tiempo ni correr el riesgo.

Hay ocasiones en las que debes incurrir en la deuda técnica para cumplir con una fecha límite o para implementar una pequeña parte de una función. Intenta esquivar esos casos; sólo hazlo si la situación lo exige. Pero (y éste es un gran pero) debes mantener un ojo sobre la deuda técnica y pagarla tan pronto como puedas o las cosas se irán rápidamente cuesta abajo. Apenas te hayas endeudado, escribe una tarjeta o registra el problema en tu sistema de seguimiento para asegurarte de no olvidarlo.

Si planeas pagar la deuda en la próxima iteración, el costo será mínimo. Pero si la abandonas, se incrementarán los intereses y esto también deberá registrarse para que el costo permanezca a la vista. Hacer esto resaltará el impacto que tiene la deuda técnica del proyecto sobre el valor de la empresa y permitirá una priorización de pago. Cómo calcular y realizar el seguimiento de los intereses dependerá de cada proyecto, pero deberás hacerlo.

Paga la deuda técnica tan pronto como puedas; sería imprudente no hacerlo.

Leer contribución original

Adueñate (y Refactoriza) la compilación

Adueñate (y Refactoriza) la compilación
Autor: Steve Berczuk

No es poco común para los equipos que, aunque son altamente disciplinados sobre las prácticas de codificación, descuiden los scripts de compilación, quizás por la creencia de que son meramente un detalle de poca importancia o por el miedo de que son complejos y necesitan ser atendidos por el culto de la ingeniería de la liberación. Los scripts que no son posibles de mantener, con duplicaciones y errores, causan problemas de la misma magnitud que aquellos con código pobremente factorizado.

Una de las razones por las que los desarrolladores hábiles y disciplinados tratan la compilación como algo secundario es que los scripts de compilación son frecuentemente escritos en un lenguaje diferente al código fuente. Otra es que la compilación no es realmente “código”. Estas justificaciones van en contra de la realidad de que la mayoría de los desarrolladores de software disfrutan aprendiendo nuevos lenguajes y que la compilación es lo que crea artefactos ejecutables para desarrolladores y usuarios finales para probar y ejecutar. El código es inútil si no ha sido compilado, y la compilación es lo que define el componente de arquitectura de la aplicación. La compilación es una parte esencial del desarrollo, y las decisiones sobre el proceso compilado pueden hacer más simples tanto el código como la codificación.

Los scripts para la compilación que son escritos usando modismos erróneos son difíciles de mantener y, más importante, de mejorar. Vale la pena tomarse tiempo para entender la forma correcta de realizar un cambio. Los errores pueden aparecen cuando una aplicación se compila con la versión incorrecta de una dependencia o cuando la configuración del tiempo de compilador está mal.

Tradicionalmente las pruebas han sido algo que siempre fue dejado al equipo de “Quality Assurance”. Ahora nos damos cuenta de que hacer pruebas mientras codificamos es necesario para permitirnos liberar el valor predeciblemente. Del mismo modo, el proceso de compilación tiene que ser propiedad del equipo de desarrollo.

Entender la compilación puede simplificar el ciclo de vida completo y reducir costos. Una compilación simple de ejecutar permite al nuevo desarrollador empezar rápida y fácilmente. La automatización de la configuración de compilación puede permitirte obtener resultados consistentes cuando muchas personas están trabajando en un proyecto, evitando el “a mí me funciona”. Muchas herramientas para compilación te permiten ejecutar reportes de calidad de código, lo que hace posible detectar problemas potenciales tempranamente. Al entender cómo hacer tuya la compilación, puedes ayudarte a ti mismo y a los integrantes de tu equipo. Enfócate en codificar características, en beneficio de las partes interesadas y para hacer tu trabajo más agradable.

Aprende lo suficiente de tu proceso de compilación para saber cuándo y cómo realizar los cambios. Los scripts de compilación son código. También son muy importantes para dejárselos a alguien más, la aplicación no está completa hasta que se compila. El trabajo de programación no está completo hasta que hayamos liberado software funcionando.

Leer contribución original

Antes de Refactorizar

Antes de Refactorizar
Autor: Rajith Attapattu

En algún punto todo programador necesitará refactorizar código existente. Pero antes de hacerlo por favor piensa en lo siguiente, ya que tú y otras personas podrían ahorrar una gran cantidad de tiempo (y dolor):

  • El mejor enfoque para la reestructuración comienza por hacer un balance del código base existente y las pruebas escritas contra ese código. Esto ayudará a entender las fortalezas y debilidades del código en su estado actual, por lo que puedes asegurar que retienes los puntos fuertes, mientras evitas los errores. Todos pensamos que podemos hacerlo mejor que el sistema actual… hasta que terminamos con algo que no es mejor –o incluso peor– que la anterior encarnación, debido a que fallamos en aprender de los errores existentes en el sistema.
  • Evita la tentación de volver a escribir todo. Es mejor reusar tanto código como sea posible. No importa que tan feo sea el código, ya ha sido probado, revisado, etcétera. Desechar el código viejo –especialmente si está en producción– significa que estás desechando meses (o años) de pruebas sobre el aguerrido código que podría haber tenido ciertos atajos y correcciones críticas de errores de los cuales no estás enterado. Si no tomas esto en cuenta, el nuevo código que se escriba podría terminar mostrando el mismo error misterioso que fue reparado en el código antiguo. Esto desperdiciará un montón de tiempo, esfuerzo y conocimiento adquiridos a través de los años.
  • Muchos cambios incrementales son mejores que un cambio masivo. Los cambios incrementales permiten medir el impacto en el sistema más fácilmente a través de la retroalimentación, como las pruebas. No es divertido ver cientos de pruebas fallidas después de realizar un cambio. Esto puede conducir a la frustración y presión que puede, a su vez, dar lugar a malas decisiones. Un par de pruebas fallidas es fácil de manejar y provee un enfoque más manejable.
  • Después de cada iteración es importante asegurar que las pruebas existentes pasan. Agrega nuevas pruebas si las pruebas existentes no son suficientes para cubrir los cambios realizados. No deseches las pruebas del código antiguo sin la debida consideración. En la superficie algunas de estas pruebas podrían no parecer aplicables a tu nuevo diseño, pero será de utilidad el esfuerzo de investigación a fondo de las razones por las cuales estas pruebas en particular fueron añadidas.
  • Las preferencias personales y el ego no deben ponerse en el camino. Si algo no está roto, ¿para qué arreglarlo? Que el estilo o la estructura del código no se ajuste a tus preferencias personales no es una razón válida para reestructurarlo. Pesar que podrías hacer un mejor trabajo que el programador previo no es una razón válida tampoco.
  • La nueva tecnología es razón insuficiente para refactorizar. Una de las peores razones para refactorizar se debe a que el código actual está muy por detrás de las buenas tecnologías que tenemos hoy en día, y creemos que un nuevo lenguaje o framework puede hacer las cosas mucho más elegantemente. A menos que un análisis de costo-beneficio muestre que el nuevo lenguaje o framework beneficiará la funcionalidad, mantenimiento o productividad, es mejor dejar las cosas como están.
  • Recuerda que los humanos cometen errores. Reestructurar no siempre garantiza que el nuevo código será mejor o tan bueno como el intento anterior. He visto y sido parte de muchos intentos de reestructuración fallidos. No fue bonito, pero fue humano.

Leer contribución original

Aplica los principios de la programación funcional

Aplica los principios de la programación funcional
Autor: Edward Garson

Recientemente, la comunidad programadora ha demostrado un renovado interés por la programación funcional. Parte del motivo es que las propiedades emergentes de este paradigma las hacen una buena opción para abordar la transición de la industria hacia el desarrollo sobre arquitecturas multi-core. Sin embargo, aunque es, sin duda, una aplicación importante, no es la razón por la que este texto te exhorta a que aprendas sobre programación funcional.

Dominar el paradigma funcional puede mejorar enormemente la calidad del código que escribes en otros contextos. Si lo comprendes y lo aplicas a tus diseños, lograrás un nivel mucho más alto de transparencia referencial.

La transparencia referencial es una cualidad deseable: implica que las funciones devuelvan siempre los mismos resultados cuando se les pase el mismo valor, independientemente de dónde y cuándo se las invoque. Es decir, la evaluación de una función no depende tanto de los efectos colaterales del estado mutable –idealmente, no depende en absoluto–.

Una de las principales causas de defectos cuando se programa en lenguajes imperativos no es otra que las variables mutables. Cualquier persona que se encuentre leyendo esto habrá tenido que investigar alguna vez por qué un valor no es el esperado en una situación particular. La semántica de visibilidad puede ayudar a mitigar estos errores insidiosos o, al menos, reducir drásticamente su ubicación; pero es probable que el verdadero culpable de su existencia sea un desarrollo que hace uso de mutabilidad excesiva.

Y la industria no nos ayuda mucho con este problema. La mayoría de la documentación introductoria sobre orientación a objetos tácitamente promueve este tipo de prácticas, porque a menudo utilizan como ejemplo una serie de objetos con un tiempo de vida relativamente largo, invocando métodos mutadores unos sobre otros, lo cual puede ser peligroso. Sin embargo, con un buen desarrollo guiado por pruebas, particularmente asegurándose de “simular roles, no objetos“, se puede evitar la mutabilidad excesiva.

El resultado neto será un diseño que generalmente posee una mejor distribución de responsabilidades con una mayor cantidad de funciones –más pequeñas– que trabajan sobre los argumentos que se les pasa, en lugar de hacer referencia a miembros mutables. Habrá menos defectos y también será menos complejo detectarlos, porque es más fácil localizar dónde se introdujo un valor no deseado que deducir el contexto específico que resulta en una asignación errónea. Un diseño de este tipo establecerá un nivel mucho más alto de transparencia referencial; y, de seguro, nada fijará mejor estas ideas en tu cabeza que estudiar un lenguaje de programación funcional, en el cual este modelo de computación es la norma.

Por supuesto, este enfoque no es la mejor opción para todas las situaciones. Por ejemplo, en sistemas orientados a objetos de este estilo suele lograr mejores resultados con el desarrollo del modelo de dominio (es decir, en el cual la interacción de las funciones sirve para descomponer la complejidad de las reglas de negocio) y no tanto con el desarrollo de la interfaz de usuario.

Domina el paradigma de la programación funcional y podrás –con criterio– aplicar en otros contextos las lecciones que aprendas. Tus sistemas orientados a objetos (para empezar) se llevarán mejor con las bondades de la transparencia referencial y, contrario a lo que muchos te dirán, estarán más cerca de su contraparte funcional. De hecho, algunos incluso afirman que, en el fondo, los paradigmas de programación funcional y orientada a objetos no son más que un mero reflejo el uno del otro, una especie de yin y yang computacional.

Leer contribución original

Aprende a decir “Hola, Mundo”

Aprende a decir “Hola, Mundo”
Autor: Thomas Guest

Paul Lee, nombre de usuario “leep”, comúnmente conocido como Hoppy, tenía la reputación de experto local en temas de programación. Necesitaba ayuda. Caminé hacia el escritorio de Hoppy y le pregunté:

— ¿Podrías echar un vistazo al código por mí?

— Seguro —dijo Hoppy—, toma una silla.

Tuve el cuidado de no derribar las latas vacías de soda apiladas en una pirámide detrás de él.

—¿Qué código?

—En una función en un archivo —le dije.

—Echemos un vistazo a esta función.

Hoppy alejó una copia de K&R y deslizó su teclado frente a mí. ¿Dónde está el IDE? Aparentemente Hoppy no tenía un IDE ejecutándose, sólo algún editor que yo no podía operar. Tomó de nuevo el teclado. Unos cuantos teclazos después y teníamos el archivo abierto –era un archivo algo grande– y estamos observando la función –era una función algo grande–. Él avanzó unas páginas hacia el bloque condicional que quería cuestionarle.

— ¿Qué haría realmente esta cláusula si x es negativo? —le pregunté—. ¿Sin duda, es un error.

Había estado probando toda la mañana tratando de encontrar una manera de forzar que x fuera negativo, pero la gran función en un gran archivo era parte de un gran proyecto, y el ciclo de recompilar y volver a ejecutar mis experimentos me estaba venciendo. ¿No podría un experto como Hoppy simplemente decirme la respuesta?

Hoppy admitió que estaba seguro. Para mi sorpresa, no buscó en K&R. En vez de ello, copió el bloque de código en un nuevo buffer del editor, lo reindentó y lo envolvió en una función. Un poco más tarde codificó una función main y lo cicló, pidiendo al usuario valores de entrada, pasándolos a la función e imprimiendo el resultado. Guardó el buffer como un nuevo archivo, tryit.c. Todo esto lo podría haber hecho yo mismo, creo que quizá no tan rápido. Sin embargo, su siguiente paso fue maravillosamente simple y, para ese tiempo, un poco extraño para mi manera de trabajar

$ cc tryit.c && ./a.out

¡Mira! Su programa, concebido unos pocos minutos antes, ahora estaba en marcha y funcionando. Probamos unos cuantos valores y confirmó mis sospechas (¡había tenido razón sobre algo!) y entonces cotejó la sección correspondiente de K&R. Le agradecí a Hoppy y me fui, una vez más, teniendo cuidado de no molestar su pirámide de latas de soda.

De regreso a mi escritorio, cerré mi IDE. Me había hecho tan familiar al trabajo con un gran proyecto con un gran producto que había empezado a pensar qué debía hacer. Una computadora de propósito general puede realizar pequeñas tareas también. Abrí un editor de texto y empecé a escribir.

#include <stdio.h>

int main() {
    printf("Hello, World\n");
    return 0;
}

Leer contribución original

Aprende a hacer estimaciones

Aprende a hacer estimaciones
Autor: Giovanni Asproni

Como programador debes ser capaz de proporcionar estimaciones a tus directivos, colegas y usuarios de las tareas que necesitas realizar, así ellos tendrán una idea razonablemente precisa del tiempo, costo, tecnología y otros recursos necesarios para lograr sus objetivos.

Para poder estimar bien es obvia la importancia aprender algunas técnicas de estimación. En primer lugar, sin embargo, es fundamental aprender qué son las estimaciones y para qué deberían ser usadas –por extraño que parezca, muchos desarrolladores y administradores no conocen esto–.

El siguiente diálogo entre un administrador de proyectos y un programador es nada atípico:

  • Administrador de Proyecto: ¿Puedes darme un estimado del tiempo necesario para desarrollar la característica xyz?
  • Programador: Un mes.
  • Administrador de Proyecto: ¡Eso es mucho tiempo! Sólo tenemos una semana.
  • Programador: Necesito al menos tres.
  • Administrador de Proyecto: Puedo darte dos cuando mucho.
  • Programador: ¡Es un trato!

Al programador, al final, se le ocurre un “estimado” que concuerda con lo que es aceptable para el administrador. Pero, ya que es una estimación del programador, el gerente lo hará responsable de ello. Para entender qué está mal en esta conversación necesitamos tres definiciones: estimado, fin y compromiso.

  • Un estimado es un cálculo aproximado o un juicio de valor, número, cantidad o extensión de algo. Esta definición implica que un estimado es una medición factual basada en datos concretos y experiencia previa; la esperanza y los deseos deben ser ignorados cuando se calcula. La definición también implica que, al ser aproximada, una estimación no pueden ser precisa, por ejemplo: una tarea de desarrollo no puede ser estimada para durar 234.14 días.
  • Un fin es una declaración de un objetivo deseable del negocio, por ejemplo, “el sistema debe soportar al menos 400 usuarios concurrentes”.
  • Un compromiso es una promesa de ofrecer una funcionalidad especificada a una determinado nivel de calidad en una cierta fecha o evento. Un ejemplo podría ser: “la funcionalidad de búsqueda estará disponible en la próxima versión del producto”.

Los estimados, fines y compromisos son independientes uno del otro, pero los blancos y cometidos deberían estar basados en estimados. Como Steve McConnell señala: “El propósito principal de la estimación de software no es predecir el futuro del proyecto, sino determinar si los fines son lo suficientemente realistas para que pueda ser controlado hasta lograrlo”. Por lo tanto, el propósito de una estimación es hacer una administración de proyecto adecuada y una planificación posible, permitiendo que los interesados hagan compromisos basados en fines realistas.

Lo que estaba pidiendo el administrador en la conversación anterior al programador era hacer un compromiso basado en un fin no declarado que el administrador tenía en mente, no dar un estimado. La próxima vez que te pidan proporcionar un estimado asegúrate que todos los involucrados sepan de lo que están hablando, y tus proyectos tendrán una mejor oportunidad de éxito. Ahora es el momento de aprender algunas técnicas…

Leer contribución original

Aprende un lenguaje extranjero

Aprende un lenguaje extranjero
Autor: Klaus Marquardt

Los programadores necesitamos comunicarnos. Mucho.

Hay periodos en la vida de un programador cuando mucha de su comunicación parece ser con la computadora. Más precisamente, con los programas ejecutándose en esa computadora. Esta comunicación es con respecto a expresar ideas en una forma leíble por la máquina. Sigue siendo un prospecto emocionante: los programas son ideas convertidas en realidad, con virtualmente ninguna sustancia física involucrada.

Los programadores deben tener fluidez en el lenguaje de la máquina, ya sea real o virtual, y en las abstracciones que pueden estar relacionadas con el lenguaje vía herramientas de desarrollo. Es importante aprender muchas abstracciones diferentes, de otro modo algunas ideas se vuelven increíblemente difíciles de expresar. Los buenos programadores necesitan ser capaces de pararse fuera de su rutina diaria, de estar al tanto de otros lenguajes que son expresivos para otros propósitos. La hora siempre llega cuando éste vale la pena.

Más allá de la comunicación con las máquinas, los programadores necesitan comunicarse con sus pares. Los grandes proyectos de hoy en día son más emprendimientos sociales que simplemente una aplicación en el arte de la programación. Es importante entender y expresar más de lo que pueden las abstracciones de máquina. La mayoría de los mejores programadores que conozco es muy fluida en su lengua madre y, por lo general, en otros idiomas también. Esto no es sólo sobre la comunicación con otros: hablar bien un lenguaje nos lleva a una claridad de pensamiento que es indispensable cuando se abstrae un problema. Y también de eso se trata la programación.

Más allá de la comunicación con las máquinas, con uno mismo y con los compañeros, un proyecto tiene muchos stakeholders, la mayoría con una formación diferente o no técnica. Ellos viven en las áreas de pruebas, calidad y despliegue, en mercadeo y ventas, son usuarios finales en alguna oficina (o tienda o casa). Necesitas entenderlos y a sus preocupaciones. Esto es casi imposible si no puedes hablar su lenguaje en su mundo, su dominio. Mientras puedes pensar que una conversación con ellos salió bien, ellos probablemente no.

Si puedes hablar con contadores, necesitas un conocimiento básico de contabilidad, de centros, de costos o capital invertido, capital empleado, et al. Si vas a hablar con mercadólogos o abogados, algo de su jerga y lenguaje (y, por lo tanto, su mente) debería serte familiar. Todos estos lenguajes específicos del dominio necesitan ser dominados por alguien en el proyecto; de preferencia los programadores, ya que son los responsables de llevar las ideas a la vida a través de una computadora.

Y, por supuesto, la vida es más que proyectos de software. Como lo nota Charlemagne, el conocer otro lenguaje es tener otra alma. Para tus contactos más allá de la industria del software serás más apreciado al conocer lenguajes extranjeros. Para saber cuándo escucharlos en vez de hablar. Para saber que la mayor parte del lenguaje es sin palabras.

“De lo que no se puede hablar, hay que callar”. Ludwig Wittgenstein.

Leer contribución original

Aprende a usar las herramientas de línea de comandos

Aprende a usar las herramientas de línea de comandos
Autor: Carroll Robinson

Hoy en día, muchas herramientas de desarrollo de software se empaquetan como Entornos Integrados de Desarrollo (IDE, Integrated Development Environments). Microsoft Visual Studio y el proyecto de software libre Eclipse son dos ejemplos populares, aunque hay muchos otros. Hay muchas razones por las cuales nos gustan los IDE. No sólo porque son fáciles de usar, sino que también alivian al programador de pensar en un montón de pequeños detalles que involucran el proceso de construcción.

La facilidad de uso, sin embargo, tiene su lado negativo. Por lo general, cuando una herramienta es fácil de usar, es debido a que está tomando decisiones por ti y haciendo un montón de cosas automáticamente detrás de la escena. Por lo tanto, si un IDE es el único entorno de programación que siempre has usado, quizás nunca entiendas completamente lo que tus herramientas están haciendo. Haces clic en un botón, algo de magia ocurre, y un archivo ejecutable aparece en la carpeta del proyecto.

Al trabajar con las herramientas de línea de comandos vas a aprender mucho más sobre lo que están haciendo cuando se está construyendo el proyecto. Escribir tus propios archivos make te ayudará al entendimiento de todos los pasos (compilar, ensamblar, enlazar, etcétera) que están en la construcción de un archivo ejecutable. Experimentar con las muchas opciones de la línea de comandos de esas herramientas también es una experiencia educacional valiosa. Para empezar con el uso de las herramientas de construcción en línea de comandos, puedes usar las de software libre, como GCC, o las proporcionadas por tu IDE propietario. Después de todo, un IDE bien diseñado es sólo una interface gráfica para un conjunto de herramientas de línea de comandos.

Además de mejorar tu entendimiento del proceso de construcción, hay algunas tareas que pueden ser realizadas de forma más fácil o eficiente con las herramientas de línea de comandos que con un IDE. Por ejemplo, las capacidades de buscar y reemplazar provistas por las utilerías grep y sed son más poderosas que aquellas que encuentras en IDEs. Las herramientas de línea de comandos inherentemente soportan secuencias de comandos (scripting), lo cuál permite la automatización de tareas, como calendarizarbuilds diarios, crear múltiples versiones de un proyecto y la ejecución de conjuntos de pruebas. En un IDE este tipo de automatización puede ser más difícil (si no imposible) de realizar debido a que las opciones de construcción son usualmente especificadas usando cajas de diálogo del GUI (Interface Gráfica de Usuario) y el proceso de construcción es invocado con el clic del ratón. Si nunca has dado un paso fuera de un IDE, quizá nunca te diste cuenta de que estos tipos de tareas automatizadas son posibles.

Pero, espera. ¿Acaso el IDE no existe para hacer el desarrollo más fácil y para mejorar la productividad del programador? Bueno, sí. La propuesta presentada aquí no es que debes dejar de usar un IDE. La propuesta es que deberías “mirar debajo de la cortina” y entender lo que el IDE está haciendo por ti. La mejor manera de hacerlo es aprender a usar las herramienta de línea de comandos. Luego, cuando vuelvas a usar tu IDE, tendrás un mucho mejor entendimiento de qué es lo que está haciendo por ti y cómo puedes controlar el proceso de construcción. Por otra parte, una vez que domines el uso de las herramientas de línea de comandos y experimentes el poder y flexibilidad que ofrecen, quizás podrías encontrar que prefieres la línea de comando sobre el IDE.

Leer contribución original