Pues comenzamos:

Para mi programar es:
Un reto diario (me gustan los retos).
Ejercicio para mi cerebro.
Apasionante.
Mucho estres.
Estar sentado mucho tiempo.

Para mi programar no es:
Un empleo sociabilizador (me gusta sociabilizar).

Para ti ¿programar es?

Para mi programar es desarrollar tu logica, tener una manera diferente de resolver problemas, creando aplicaciones que te permitan hacer un mejor uso de las tecnologías

Para ti ¿programar no es?

Para mi no es quedarse siempre programando en el mismo lenguaje y no tratar de conocer nuevas opciones

¿Que es?
Escribir instrucciones que una máquina pueda ejecutar y un humano pueda entender.

¿Que no es?
Todo lo demás.

Sobre ¿Que es?
Ahora, hay un nivel de subjetividad en el primer punto. Escribir instrucciones que una máquina pueda entender es la parte fácil: funciona o no funciona, pero escribir instrucciones que un humano puede entender varia mucho dependiendo del humano que lo lea, así que digamos que se trata de un humano que también sea programador y que además otros consideran como buen programador. No hay mucho caso si alguién que es un mal programador o un programador en formación no le entiende a tu código. Puntos extra si logras hacer que hasta el más principiante entienda tú código.

Citando a Martin Fowler:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Entre más grande es aquello que hay que programar, más difícil se vuelve cumplir con la segunda parte. Programar un hola mundo generalmente es sencillo. Programar un sistema operativo definitivamente no lo es.

Sobre ¿Que no es?

Sobre todo lo demás es, pues... ¡todo lo demás!. Cuando estas recopilando requerimientos, analizando, diseñando, dando soporte, etc. etc no estás programando, estas ejecutando varias de las otras disciplinas de la "ingeniería" del software.

No es un arte ( el arte no tiene más fin que la recreación del ser humano ) , no es una ciencia, no es una ingenería, no son matemáticas, no se necesita ser un genio. Se parece o forma parte de alguna de estas disciplinas, pero no es una de esas disciplinas.

Se parece mucho a la artesanía ( por lo que "Artesanos del software" suena razonable ) y se parece muchísimo a un sin fin de actividades diversas más, arquitectura, literatura, música, ¡leyes! , ajedrez, pffff.... y la lista sigue pero, ninguna de ellas es programar.

A mi en lo particular me parece mucho a la literatura, aunque nunca he escrito más de 4 páginas de nada ( aunque los posts que acá pongo a veces parecen más que eso ) puedo encontrar la similitud entre saber primero que es lo que quieres decir y luego encontrar la mejor forma de decirlo y le haga sentido a alguien más.

En fin, las similitudes son muchísimas.

Sobre todo lo demás es, pues... ¡todo lo demás!. Cuando estas recopilando requerimientos, analizando, diseñando, dando soporte, etc. etc no estás programando, estas ejecutando varias de las otras disciplinas de la "ingeniería" del software.

OscarRyz ahi tenemos un punto en que no concordamos, para mi el analisis y diseño son parte de la programacion.

Y leyendo tu contestacion creo que deje muy limitada mi pregunta.

Son más bien parte del "desarrollo del software".

Puedes tener un analista que no sepa ni ";" de programación y aún así ser muy buen analista y también hay muchos programadores que no pueden sacarle la más mínima información a un usuario porque solo piensan técnicamente y nomás no se logran comunicar.

Usuario: quiero que cualquiera pueda escribir en el blog, pero que no haya publicidad barata

Programador ( que no sabe más que programar y no tiene idea de como obtener requerimientos ) : Te refieres a que cuando se haga el submit valide que no venga spam? Porque no mejor ponemos un captcha? Y se forzaría a que se haga el registro de la cuenta? ¿Un submit anónimo sin cookies que vaya directo al servlet? ¿O como?
Usuario: ehmmm ... creo que mejor le paso esto a tu jefe
Programador: ( q_n_s_m_q_p_y_n_t_i_d_c_o_r ): El usuario es un tarado

Afortunadamente con la experiencia y la práctica la mayoría de los buenos programadores aprenden otras disciplinas del desarrollo del software y se vuelven "desarrolladores de software" ( Software Developer ) y ya saben: modelar el negocio, obtener requerimientos, hacer análisis y diseño, pruebas, soporte a producción etc.etc.
Deployment

Hace un par de meses tuve un usuario que solicitaba tantas cosas que luego ya no sabía que quería o a veces pedía tantas modificaciones a un modulo que finalmente se arrepentía de los cambios, entonces muchas veces no depende solo del programador sino también del usuario que sepa que es lo que quiere. Bueno pero en si a mí lo que me llamo la atención de lo que mencionas es aprender las disciplinas del desarrollo, eso como se adquiere? en base a la práctica? la experiencia?

Pues como en todo, hay cursos, libros y demás y como en casi todo te lo da la experiencia.

...no depende solo del programador sino también del usuario que sepa que es lo que quiere...

Es correcto, pero ahí viene muchas veces la experiencia del analista en entender "Ah lo que esta persona quiere es esto otro"

Es decir, el usuario SI sabe lo que necesita y lo que quiere, solo que no siempre lo puede expresar.

Por ejemplo a veces sucede que el supervisor te dice:

"Quiero un reporte que me diga quién no ha terminado su trabajo y me ponga en rojo los que ya se tardaron más de X días y blah, blah, blah"

y después descubres que lo que se necesita es que el sistema ayude a que a los usuarios no se les olvide completar su tarea. Quizá con recordatorios ( muy malos por cierto, casi siempre terminan haciendo un filtro en el correo para mandar todo ahí ) o con escalamientos ( más efectivos ) o simplemente con un inbox en el sistema de tareas pendientes.

Cuando un programador experimentado hace este trabajo y además tiene la experiencia necesaria para entender al cliente ( trabajó en el área, o fue cliente el mismo ) , tienes un muy buen levantamiento de requerimientos.

Por desgracia así como hay malos programadores, hay malos analistas de negocio que nomás confunden más las cosas. Por fortuna son pocos.

p.d. Offtopic. Por cierto Alex, en la última opentalks que nos saludamos, solo ví tu cara como 2 segundos ( el tiempo anterior te ví de espalda y ni sabía que eras tú - no traías tu camisa de "Yo soy AlexSnake" - ) y cuando me saludaste pues te fuiste luego luego. Así que ... si la siguiente vez que te vea pongo cara de... "Y este quién es?" no me lo tomes a mal ( o de plano ve con la cara pintada de camuflaje :P )

Bueno Para mi programar es el desarrollo de sofware que cualquier persona no es capaz de tener una solucion para el desarrollo del futuro de sofware
en un determinado lenguaje de programacion.

Para mi programar no es :
Estar presionando las teclas , es el acto en el cual un programador se "estresa cuando algo del sofware requerido no le sale"
pero se desestresa o satisface cuando le sale dicho requerimiento.

De lo que hablan Oscar y AlexSnake acerca de los usuarios: como desarrollador también hay que saber interpretar lo que el usuario pide. El usuario te dice lo que quiere, y tú le tienes que decir lo que necesita. Y entre los dos definen super bien esos requerimientos y les ponen prioridades y que se sientan a leer todos los requerimientos hasta que estén de acuerdo y entonces el cliente te firma de que ya está de acuerdo en que eso es lo que tienes que desarrollar. Y en el futuro para cualquier cambio haces lo mismo.

No siempre es posible, pero pues cuando menos que quede en un mail; cuando de plano nada más son requerimientos orales (que te lo dicen en persona o por teléfono) después no tienes manera de comprobarles que ellos pidieron eso, cuando resulta que ya no lo quieren así.

Así es como regularmente levantamos los requerimientos, pero esa ocasión tuve una muy mala experiencia, ya que se había definido en su totalidad el proyecto y se comenzó el desarrollo pero después que se termino y conforme iba haciendo pruebas el usuario, fue cuando comenzó la catástrofe ya que el mismo usuario había omitido cosas del sistema y a veces impactaban desde la bd. Entonces yo estoy de acuerdo en que nosotros como desarrolladores/programadores debemos a indicarle al usuario la mejor manera de hacer un sistema, porque obviamente a veces el usuario no tiene ni idea, pero nosotros tampoco somos adivinos porque realmente quien conoce el negocio es el usuario. Por eso decía que no siempre depende del programador.

>que se termino y conforme iba haciendo pruebas el usuario, fue cuando comenzó la catástrofe ya que el mismo usuario había omitido cosas del sistema...

Mmhh vaya, sí suele suceder. Lo peor de todo es cuando se tomaron meses levantando los requerimientos y dejan el 30% para el desarrollo y 5% del tiempo para pruebas.

Es por eso que se recomienda seguir un proceso iterativo donde en vez de esperarse a terminar todo el análisis y luego todo el desarrollo y luego probar, se comienza con los requerimientos más importantes seguido por la construcción de los mismos; para cuando se están levantando los requerimientos secundarios, alguna parte de los más importantes ya esta construída y se puede mostrar al cliente y si hay cambios, estos se meten en la siguiente ronda.

Incluso siguiendo un modelo de cascada ( como el que se nota que siguieron en el ejemplo que dices ) estos nuevos requerimientos se pueden hacer en "proyecto" ( o la siguiente versión ). Le puedes decir "Si, es correcto que ahora quieras meter esta otra cosa, lo que podemos hacer es entregarte lo que pediste inicialmente y cerrar, e inmediatamente comenzar con las modificaciones". Obvio esto implica un costo extra que muchos clientes no quieren ( o pueden ) pagar y dicen "Es que así no me sirve, o no fue lo que acordamos o xyz" y ahí mucho depende de la habilidad del gerente del proyecto para hacer esta negociación. Aunque por desgracia, si no se pudo detectar ese hueco antes lo más probable es que el responsable ( el gerente del proyecto ) tampoco logré convencer al cliente del cambio de alcance y como suele pasar en varios lados el que tiene que hacer el esfuerzo para construir lo que no estaba planeado es el programador.

Una desventaja del modelo iterativo es que no es posible predecir cuando va a terminarse la construcción del software, porque como se deja la puerta abierta a más y más cambios, entonces se puede pasar el tiempo y jamás terminar. De nuevo es aquí donde el analista de negocio y el gerente del proyecto ( y/o el arquitecto de sistemas ) deben de tener la experiencia necesaria para identificar y delimitar bien el alcance del proyecto junto con el área usuaria, quizá lo que se necesita es hacer módulos y/o proyectos diferentes en vez de querer hacer todo de un jalón.

Totalmente de acuerdo Oscar tal parece que todo se basa en la experiencia, saber como enfrentar las situaciones. Lo bueno que ya paso.. fiuu

Programar es dejar que los bits fluyan e inunden la mente, y como comentaban muchas veces los clientes al pedir una aplicación , lo primero que hacen es dar una solución que consideran la más apropiada y solicitan un diseño que creen que necesitan , es decir botones, listas desplegables, cosas así. Es ahí en donde nosotros tenemos que plantearnos Que es lo que quiere resolver? y determinar si el diseño que solicita es el adecuado o existe alguna opción más factible.

Eso es lo que yo creo, por ahora, pues soy nuevo en esto, inicio mi aventura en este universo.

Claro que programar también es arte, porque hay muchos seres humanos que se recrean al leer un código bello. Vale la pena leer el libro Beautiful Code para deleitarse.
Programar también es ciencia porque la buena programación se tiene que basar en los fundamentos matemáticos de la ciencia de la computación.
Programar también es ingeniería porque estamos creando un producto siguiendo las prácticas que las ingenierías han establecido.
Programar para mí es poder resolver un problema real en un espacio diferente (el espacio de la solución) al espacio donde el problema se manifiesta.
Diseñar es programar con un lenguaje diferente al lenguaje que utilizo para codificar.
Programar es una chingonería que todos lo que lo hacen lo deben disfrutar, porque están haciendo una de las cosas más sublimes que Dios ( o en lo que creas) nos otorgó: la capacidad de crear.

¡¡Oooraless!!

Arte es entendido generalmente como cualquier actividad o producto realizado por el ser humano con una finalidad estética o comunicativa, a través del cual se expresan ideas, emociones o, en general, una visión del mundo, mediante diversos recursos...

Pues en estricta teoria... o no tan estricta no sé si... tambíen programar podria ser Arte

Como yo lo veo Programar depende mucho de las aptitudes mas que de la actitud

Hay muchas personas(compañeros, amigos, extraños,etc) que admiro porque solo leyendo la documentacion técnica ya le entendieron a cualquier cosa, por ejemplo yo no supe que pex con Spring leyendo el manual de referencia pero vi unos codigos y pensé ahh mira de aqui sales, ahh por ésto esto otro

@Hugo

Hay dos acepciones sobre lo que es el arte. En una sobre simplificación totalmente mía son:

1.- Lo que cuesta mucho trabajo hacer y que pocos logran dominar.

Ejemplo "Criar a este niño es todo un arte" o "El arte de hacer enchiladas, etc."

y

2.- Aquello que no sirve para nada más que para recrear* al ser humano.

Ejemplo: - Esos garabatos que? - Es una representación de un hombre consumido por sus preocupaciones. - Oooh ...

Yo prefiero la segunda y aquí entiendo la palabra "recrear" como "volver a crear" al ser humano ( de hecho por ahí va la asociación entre diversión y recreo ), a través de símbolos y aquí comparto con el Dr. BFerro, el código puede llegar a tener un valor puramente estético.

Estos símbolos pueden ser visuales ( pintura, escultura, plástica ) , sonoros ( palabra, música ) o de cualquier otro sentido ( hay pocos ejemplos de arte olfativo pero debería de haber )

Pero en esta segunda acepción ese es el único fin. Si la actividad sirve para comer, ya no es arte. Si sirve para sentarse, ya no es arte o si sirve para generar una factura digital, en mi opinión ya no es arte.

Es por eso que las pinturas rupestres donde se ven a los cazarores al rededor de un mamut es considerado arte, porque el / los que lo pintaron estaban re-creando su condición humana en una pared con colores. Aquello podría haber servido para indicar donde había mamuts ( como en un mapa ) pero hasta ahora parece que solo fue con el fin de decir: "Así yo lo viví". La monalisa es otro ejemplo similar, no tiene más objetivo que representar a una mujer desde el punto de vista del que lo hizo.

Claro está la otra acepción que también es válida y muchas personas la toman como referencia y es totalmente respetable, aunque a mi entender aquello entra más en el terreno de la "artesanía".

Cuando una obra de arte tiene una utilidad y se puede reproducir (hacer varias copias, o hacer el acto repetidas veces), es una artesanía. Y por eso todo el rollo de los artesanos de software.

Sobre esto de lo "irrepetible" fue la causa de que en los 70's surgieran los famosos "performances", pasan una sola vez y el que lo vio: +1 y el que no lo vio pues ya se la .. perdió. Y la idea fundamental es que ese "performance" no se podía vender ni "vulgarizar" como las pinturas, Je, je .. cada quién su rollo. Ya saben lo que dicen: "De mi arte a tu arte, prefiero..."

AlexSnake la experiencia es una parte muy importante, pero tener ciertas aptitudes que los programadores casi no tenemos, como la empatia, el "adivinar" que quiere decir el cliente, la paciencia hacia las personas, etc. ayuda mucho.

Divertido!

Estresante pero divertido

Busqué en google Programmig + Fun, y encontré éste libro:

Que tla bebida y la programación van de la mano je je je

Si, pero no siempre: