Feeling more productive

In recent months, I've been reflecting about those things that can make an IT worker feel more comfortable at work, or, at least, make the job easier. I mainly refer to the tools and infrastucture that support our daily tasks and make our work environment more productive.
I think it's a good idea to list these things I consider interesting to have within arm's reach, for all those who can be interested in them:

Tools

• Knowledge Base. In my opinion, it's really interesting to have some tool that let you compile information related with specific topics. For example, it can be useful to have a wiki, to share that information that you wouldn't find in other place. Some of the topics could be, comments about books you read, common technical problems and solutions, opinion about new technologies, methodologies and procedures, and especially topics related with information that you usually get from another people you work with (and that can, from any moment to another. not be working with you anymore).
• Mailgroups. I think that they are important for those moments when you have a question or problem that you can't resolve by yourself, and you need help from some especialized people. Sending a mail to a mailgroup can make you get some solutions or, at least, new ideas or ways to restart your search for the solution you need. I think that forums can really be useful in the same way, but I think they only can be as powerful and comfortable as mailgroups if some technology like RSS, or something like that, is applied to them.
• Instant messaging. Hey! not just to chat with your friends! It can be surprising the amount of help you can get from your colleagues using this kind of technology. Especially to get answers about things you shared in the past with them and perhaps now you can't remember (i.e. 'do you remember the name of the library you used for your project in 2004 blablabla? '). It can make you save a lot of time, get important information and be in touch with colleagues. But, be careful! Don't overuse this resource!
• Documentation templates. It can really organize your documents by itself. Knowing which templates you have available is, in my opinion, as important as having them. Having lots of documentation templates is not necessarily important; having the right and useful ones is the goal. This approach saves time when documenting and standardizes your documents.
• File server. A common place for storing your files will let you share them with your workmates. You can store documents there, applications you download from the web and you want to have available, libraries versions, e-books, and so on.
• Outlook, post-it or similar. It's mandatory for me to have some tool with an alarm or reminder where I can write down things I shouldn't forget to do. I've became a kind of reminder-dependent person lately.
  

Working place

• Library. In my opinion, e-books are a really good for having as reference and for searching topics or key-words. But, they're not comparable to real books that you can read anywhere (i.e. bus, train, subway), even in your box at work. It's important for me to have a library near, and to have it orgaized and accesible.
• Meeting room. It can be the place where you share your thoughts with your boss or workmates without bothering another people that have nothing to do with the topic you're going to talk about. It's good for communication to share your thougths and to know the status of the environment you're workin in.
• Comfortable boxes. Every person needs a comfortable place to be/feel more productive at work. Some special considerations I find interesting to have are: having a blackboard near to discuss solutions with visual aids; having comfortable boxes to be able to discuss problems easily with your workmates and not to be isolated from the others.
  

Activities

• Technical meetings. I think that having this kind of meetings where you can share your experiences with your mates can help you balance the knowledge in your workgroup and the interest in different topics. Besides this you'll probably get different points of views that enrich the meetings.
• Status meetings. Knowing the status of your project or your workmates projects' can help you to know where you are, and where you are going, what tasks to focus in, and so on.
  

Teoría vs. Práctica. Round 1

En el trabajo del día a día uno a veces cae en la cuenta de que las cosas no son siempre como se leen en los libros; si, esto está claro desde hace rato. Teoría vs. práctica. Pero sinceramente creo que es parte de nuestro trabajo también tratar de que estos dos extremos no se aparten tanto uno del otro.
El caso en el que estoy pensando ahora es, desde mi punto de vista, bastante común. Hablo de un análisis real en el que se consideren los factores necesarios para la selección de un lenguaje de programación para resolver un problema (obviamente, una vez que este está definido y está claro que se quiere solucionar desarrollando una aplicación, script o lo que sea...).

Hasta el momento, nunca tuve la suerte de tener la suficiente libertad ni la posibilidad de realizar un análisis exhaustivo acerca de este tema en un contexto laboral. Por lo general noto que algunos de los siguientes factores afectan con alta influencia a la selección del lenguaje, no permitiendo tener estas libertades de las que hablo:

• Lenguaje con el que trabaja la empresa u organización en la que trabajamos. Por una cuestión de convenios o relación laboral inter-empresas o por disponer de licencias para determinados productos asociados directamente a un lenguaje determinado, nos vemos acotados en el análisis. Este tipo de restricciones parece inevitable.
• Conocimientos por parte de los recursos. ¿Por que pasa a ser esta una restricción? Pienso que muchas veces por especulación. Si se tiene desarrolladores con dominio de un lenguaje de programación determinado y la posibilidad de capacitar o bien obtener nuevos desarrolladores con dominio del lenguaje que realmente se requiere, ¿por que no hacerlo? Tal vez sea porque no se sabe qué lenguaje realmente se requiere (aquí estaría afectado el 'conocimiento por parte de los recursos' de más alto nivel: líderes técnicos, arquitectos, etc.). O tal vez sea por propósitos económicos (léase, ahorrarse unos mangos). Yo veo a este tipo de restricciones como algo posiblemente evitable, siempre que se cuente con los recursos y voluntad necesarios.
• Modas. Muchas veces se nota que, debido a falta de claridad en ciertos conceptos, se selecciona un lenguaje en función a 'lo que se usa actualmente'. Sería algo asi como un '...y si lo usa todo el mundo debe ser bueno...'. No creo que haga falta aclarar mucho mas.
  

A modo de mini-resumen observo que a menudo trabajamos matando lo que se nos cruce por delante con un cañón. Sea un ejercito entero o un mosquito. Ni hablar de cuando se eligen frameworks o toolkits para trabajar, pero de eso podemos 'hablar' en otro momento (aunque está muy relacionado).

Por otro lado, algunos de los factores que tendría en cuenta si existiera esa libertad para el análisis (que actualmente veo restringida):

• Análisis del problema y visión. Creo que en parte el análisis del problema a resolver se basaría en un análisis de la posible solución y su factibilidad. Esto requeriría experiencia y visión del profesional encargado del análisis.
  
• Eficiencia del lenguaje. ¿Necesito responder en tiempo real? ¿Como me pueden perjudicar/beneficiar factores propios del lenguaje o de la plataforma que lo soporta (se me ocurre por ejemplo, el uso de Garbage Collectors, manejo de la memoria disponible, etc)?
  
• Comunidad de apoyo/referencia. Si tengo problemas, tengo a quien recurrir? Empezando por los recursos que tenga en la empresa (líderes técnicos, arquitectos, etc.) y siguiendo por la comunidad de desarrolladores que podemos consultar por ejemplo en foros o que nos puedan comunicar su experiencia.
• Documentación existente. ¿Existe documentación formal sobre el lenguaje (mas allá de los foros... ¿algún libro, tutorials?), problemas existentes, problemas solucionados, y todos aquellos factores que nos reflejen la madurez del lenguaje?.
  
• Proyección, crecimiento. ¿Es un lenguaje con tendencia a evolucionar, madurar, integrarse?¿Cuán viable parece una migración?
• Paradigma. ¿Pertenece a algún paradigma de programación?¿En que medida se ajusta al paradigma al que pertenece?
• Herramientas asociadas. ¿Existen frameworks/toolkits/bibliotecas de funciones maduras para el lenguaje que me puedan ayudar en el desarrollo de mi solución? ¿Existe una IDE que brinde beneficios considerables en el trabajo diario?
  

La conclusión desde mi punto de vista es que la realización de este tipo de análisis no resulta excesivamente costosa; Si bien, muchas veces nos encontramos afectados por las restricciones mencionadas inicialmente y no poseemos control sobre ellas, observo que con frecuencia, la selección del lenguaje no es resultado de un análisis real, sino es tomada como premisa incuestionable de trabajo. ¿Por qué entonces no realizar un análisis real y exhaustivo y comunicarlo a los niveles superiores en un modo profesional y a la vez comprensible de manera de lograr mayor eficiencia? Si no logramos eficiencia, tal vez logremos mostrar profesionalismo. Cuando las cosas se hacen bien, la recompensa llega en algún momento.

Con ojos de End-User

Este post no pretende ser innovador ni dar grandes soluciones al desarrollo de software.
Simplemente es una simple observación. Hoy estuve navegando la aplicación con la cual trabajo actualmente implementando ciertas funcionalidades y me topé con un problema que observo recurrentemente en aplicaciones web.
Describo lo sucedido:

• Accedo a uno de los modulos de la aplicación que muestra ciertos datos en un pop-up.
• Me levanto para ir a hablar por teléfono (si, hasta ahora no tiene sentido, no?)
• Regreso a la PC luego de hablar, y cuando realizo alguna acción en el pop-up encuentro que la session ha expirado; inmediatamente la aplicación me redirige a la pantalla de login, pero en el pop-up!.
• Me logueo y continúo navegando la aplicación pero adentro de un pop-up. Desagradable!

Este problemita lo vengo observando desde hace rato, en varias aplicaciones. Entiendo que la complejidad de solucionarlo no es tan alta como para no hacerlo y, desde mi punto de vista, tener en consideración este tipo de detalles en un desarrollo hace notar el esfuerzo en la calidad. Tal vez con un manejo de excepciones especial para los popups en la aplicación sea suficiente. Tal vez haya que pensarlo un poco más, dependiendo de la situación.
En fin, a veces hace falta pensar un poco como end-user para ver estas cosillas...