Menéame: comentarios [2194009]

#42 Si interrumpes a un desarrollador, estás haciendo el mundo peor

pradhesa — Tue, 10 Jun 2014 08:05:34 +0000

#26 Estoy un poco quemado con ese tema en particular, y en general con todo el tema de las interrupciones.
#28 Tomo nota de eso que dices.

» autor: pradhesa

#41 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Gargonslipfisk — Mon, 09 Jun 2014 19:40:21 +0000

#40 Eso es ser mala gente Estás forzando un razonamiento falaz al descontextualizar mi comentario.

» autor: Gargonslipfisk

#40 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--324579-- — Mon, 09 Jun 2014 19:32:07 +0000

#6 Venga, voy a preguntarlo de otra forma ¿ acaso los peces no duermen ?

» autor: --324579--

#39 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--231265-- — Mon, 09 Jun 2014 17:36:29 +0000

24.media.tumblr.com/0927f057a104f6bd5e6570e5a769c4c0/tumblr_n0kxeqeqBr

» autor: --231265--

#38 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Mister_Lala — Mon, 09 Jun 2014 16:12:06 +0000

Al leer esta entrada sólo he podido recordar esa escena de los Simpsons de "lisa necesita un aparato ¡Seguro dental!" donde Homer pierde la concentración cuando le meten un lápiz en la hucha.

» autor: Mister_Lala

#37 Si interrumpes a un desarrollador, estás haciendo el mundo peor

delawen — Mon, 09 Jun 2014 12:32:12 +0000

#36 EFfectivamente, TDD sirve cuando el proyecto ya está avanzado. Luego, volviendo al tema inicial del hilo, ni TDD ni hacer dibujitos ni nada similar te puede ayudar a la hora de simular ante los demás que estás trabajando más que cuando te sientas sencillamente en la silla (o vas andando, a mi me ayuda andar) mirando al infinito.

» autor: delawen

#36 Si interrumpes a un desarrollador, estás haciendo el mundo peor

alfredo_casado — Mon, 09 Jun 2014 12:25:34 +0000

#33 TDD sólo sirve cuando sabes lo que quieres hacer, como cualquier otra técnica de programación del mundo. De todos modos en ocasiones una aproximación con BDD y tratando de definir ejemplos de lo que quieres ayuda bastante, y si lo haces bien esos mismos ejemplos posteriormente se convierten en las pruebas de aceptación de tu sistema. Luego, la idea del "programador" como alguien que codifica en base a un diseño entregado por otro, vamos el waterfall de toda la vida, hace siglos que esta desterrada de cualquier equipo de programación medianamente competente, the design is the code decía jack reeves hace muchos, muchos años (dale al google y leete los artículos).

#32 En problemas puramente algoritmicos TDD no ayuda al diseño de algoritmos, para eso existen tecncias de algoritmia, en estos casos puede ser suficiente con tener algunos test iniciales y usarlos simplemente como método de comprobación para saber cuando hemos terminado, pero no como técnica de diseño del propio algoritmo, esto quedo bastante claro con el famoso asunto del sudoku y Ron Jeffries (uno de los integrantes del equipo original del proyecto C3 con Kent Beck donde se empezo a utilizar esto del TDD). Para el resto de problemas la aproximación en baby steps suele dar buenos resultados, tu código crece de manera mucho más sana, sobre todo si haces buen uso de la fase de refactor.

» autor: alfredo_casado

#35 Si interrumpes a un desarrollador, estás haciendo el mundo peor

alfredo_casado — Mon, 09 Jun 2014 10:46:37 +0000

En realidad en cualquier trabajo que exija concentración y tenga cierta complejidad las interrupciones son mortales, hay que contar el tiempo de la interrupción+el tiempo de volver al estado anterior a la interrupción que, depende muchisimo de la persona y la complejidad de la tarea, y en algunos casos pueden ser muy grandes. Por eso el telefono o las oficinas diafanas donde la gente tiene que aislarse para concentrarse son una muy mala idea.

Las típicas oficinas llenas de gente con cascos para aislarse y concentrarse, si lo piensas un poco es ridículo que en un espacio creado para el trabajo, la oficina, se tengan que usar mecanismos precisamente para aislarse del ruido que se genera en ese espacio, es el mundo al reves, una oficina sana debería ser un espacio ideal para el trabajo no lo contrario.

No es nada nuevo esto, en peopleware, uno de libros clásicos del desarrollo de software, ya se comentaba esto hace más de 20 años.

» autor: alfredo_casado

#34 Si interrumpes a un desarrollador, estás haciendo el mundo peor

triturator — Mon, 09 Jun 2014 10:33:00 +0000

#29 Hombre, si te pones a picar código a lo loco, sin pensar un poco antes lo que quieres hacer y cómo estructurarlo, pues claro que no funciona. Pero es que tampoco te va a funcionar de otra manera, el código va a ser una locura hasta que se estabilice.

Llevamos 50 años de ingeniería del software por algo. Lo de ponerse a picar sobre la marcha puede servir para un script de tres al cuarto, pero para poco más.

» autor: triturator

#33 Si interrumpes a un desarrollador, estás haciendo el mundo peor

delawen — Mon, 09 Jun 2014 10:32:19 +0000

#30 (y #32 y #34) Desde mi punto de vista, un desarrollador puro es alguien a quien le dan las interfaces/objetos/esquemas ya hechos y "sólo" tiene que modelarlo en la tecnología escogida.

No todo el mundo programa ni todo desarrollador hace sólo programación. De ahí lo de "puro". Alguien que sólo desarrolle, o sea, que sólo programe.

Te pongo un ejemplo que he tenido hace poco: estábamos tratando con crowdsourcing y necesitábamos un componente que pudiera verificar cómo de fiables eran los diferentes datos que se estaban subiendo. Todavía es una idea abstracta, no puedes definir ni tests ni interfaces ni nada. Ni siquiera tienes claro qué tipos de entradas y salidas vas a necesitar.

Durante las primeras horas (o días o incluso semanas), lo único que vas a hacer es leer fuentes, pensar, hacer algún esquema no muy concreto y hablar con gente que creas que puede aportarte ideas.

Ahí ni el TDD ni ninguna técnica de programación podrá ayudarte. Estás sólo tú con tus ideas felices.

TDD sólo sirve cuando la idea ya está avanzada, esquematizada y repensada. Que yo no sé vosotros, pero en mi trabajo eso suele ser menos de la mitad del tiempo.

» autor: delawen

#32 Si interrumpes a un desarrollador, estás haciendo el mundo peor

ktzar — Mon, 09 Jun 2014 10:29:22 +0000

#29 El TDD sirve todo el rato,... TDD no significa que los tests no se puedan cambiar más adelante, borrar, o combinar... La idea del TDD es que no es sólo útil para que tu aplicación esté probada, sino para ayudarte a establecer un ciclo de trabajo y a pensar, antes de picar código, qué demonios es lo que quieres hacer.

Lo que es una tontería es ser super estricto y estar haciendo tests para cada pequeña porción de lógica que añades, pero pensar "outside-in" en lugar de "inside-out" es muy útil a la hora de hacer código que sea cómodo de usar.

Cuántas veces, antes de empezar a programar una clase, hemos hecho un pequeño boceto en código de cómo usaríamos esa clase... Pues bien, una vez esta uno acostumbrado a escribir tests, ese código que uno luego tiraría a la basura, lo hace en formato test, y esto ayuda muchísimo a ir hilando ideas...

Y como dice #30 no todo el mundo sabe hacer tests, y para mucha gente esto es poco productivo. Pero a mi me funciona para el 50-60% de código que hago... El truco es tener 10-15 estrategias distintas a la hora de afrontar algo, de plantearse cómo testearlo. No todo tiene que tener 20 mocks y 200 tests. Y no hay que ser talibán ni de TDD ni de lo contrario (no tener ni un santo test). A veces, con escribir 4 o 5 tests inicialmente para un código en el que trabajarás 4 horas es una aproximación muy válida. No siempre hay que tener esos mini-ciclos de un test, al menos es mi opinión, que eso no funciona para todo tipo de códigos.

Por ejemplo, el otro día programando el código de pathfinding de un juego, pues hacer TDD me ayudó a establecer qué formato iba a dar a los nodos y segmentos, y qué cosas iba a esperar... Fue entonces cuando me fui dando cuenta de cuándo quería ids de nodos, y cuándo píxeles... Si no hubiera hecho los tests primero, me habría dado cuenta a medias y tendría que haberlo cambiado todo 3 ó 4 veces.

» autor: ktzar

#31 Si interrumpes a un desarrollador, estás haciendo el mundo peor

jaimedominguez — Mon, 09 Jun 2014 10:18:09 +0000

juas, menudas peloteras he tenido con mi pareja por culpa de esto:
Trabajo desde casa y muchas veces me preguntaba cosas que podrian esperar o podria solucionar ella misma... pero ya le dije que no lo hiciera, que me jode como una hora o dos horas de curro a veces y cuestra arrancar despues de esto...
Ahora cuando vamos a comer o ir a comprar o algo asi le digo espere que tengo que guardar la partida (pongo todo lo que puedo en papel) o termino lo que estaba haciendo.

mucho mejor ahora.

» autor: jaimedominguez

#30 Si interrumpes a un desarrollador, estás haciendo el mundo peor

drwatson — Mon, 09 Jun 2014 08:49:09 +0000

#29 que es un desarrollador puro??? creo que en cualquier proyecto en el que trabajes todo el mundo es desarrollador.
TDD funciona muy bien para fases iniciales, pero hay que saber escribir tests y saber lo que se quiere conseguir y eso no todo el mundo sabe hacerlo

» autor: drwatson

#29 Si interrumpes a un desarrollador, estás haciendo el mundo peor

delawen — Mon, 09 Jun 2014 08:39:50 +0000

#14 #15 #20 #25 #27 El TDD sólo sirve cuando la idea ya está avanzada. Si lo que estás haciendo es diseñar un componente desde cero, desde la idea abstracta, es absolutamente inútil.

TDD está bien para los desarrolladores puros, a los que se les dan las estructuras ya pensadas y lo "único" que tienen que hacer es programar (nótense las comillas en "único", no estoy despreciando esta tarea en absoluto). No han sido pocas las veces que he visto usar TDD para sistemas completamente nuevos y al final acabas programando dos veces: primero los tests, luego la implementación inicial, luego rehaces los tests porque te has dado cuenta de que necesitabas otras APIs diferentes y luego, finalmente, la implementación que encaje con los nuevos tests.

» autor: delawen

#28 Si interrumpes a un desarrollador, estás haciendo el mundo peor

delawen — Mon, 09 Jun 2014 08:34:15 +0000

#26 También hay formas de educar a ese tipo de gente que cree que sólo existe la comunicación síncrona.

Desde una contestación automática al correo que diga "lo he recibido, no me llames para comprobarlo porque lo he recibido copón", tardar varios tonos en contestar (y que de mientras se plantee si es tan importante saber si leiste o no el correo, haciéndole perder a él también el tiempo),... O, simplemente, diciéndoselo: "si esta llamada ha sido sólo para comprobar si me ha llegado el correo, me has hecho perder el tiempo".

A un jefe hay pocas cosas que le pongan más nervioso que que le digas que ha hecho algo que te ha hecho perder el tiempo. O que otra persona te está haciendo perder el tiempo.

También está la opción de no poner teléfono a según qué horas y que sólo haya mensajería instantánea. Al final se acaban acostumbrando y todos mejoran.

» autor: delawen

#27 Si interrumpes a un desarrollador, estás haciendo el mundo peor

ktzar — Mon, 09 Jun 2014 07:57:27 +0000

#25 Tienes razón que en el sentido estricto no funciona del todo bien a la hora de diseñar algo. Pero por ejemplo, siempre se dice que diseñar un API es la mejor forma de diseñar un sistema, ya que ayuda a la hora de buscar qué tipo de uso se le va a dar al sistema.

Pues bien, si en lugar de usar papel y boli, se hace una base de datos y se programa un cliente del api en forma de unit tests (o tests de comportamiento), ese cliente (que se podrá ir cambiando, claro) es una documentación, una hoja de ruta perfecta. Y es cierto que en ese caso, lo ideal es ir en grupos de tests, no de uno en uno.

» autor: ktzar

#26 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Ppgol — Mon, 09 Jun 2014 07:47:46 +0000

#24 El problema es esa gente que te envía un correo y si no le contestas en 5 minutos, te llama por teléfono para asegurarse que lo has leído

» autor: Ppgol

#25 Si interrumpes a un desarrollador, estás haciendo el mundo peor

ED209 — Mon, 09 Jun 2014 06:34:04 +0000

#14 cuando tienes que diseñar algo con cierta estructura el TDD (en el sentido estricto red->green->refactor) no ayuda. Lo que ayuda es el papel y boli.

» autor: ED209

#24 Si interrumpes a un desarrollador, estás haciendo el mundo peor

delawen — Mon, 09 Jun 2014 06:19:15 +0000

Y es por esto, amigos, que el enfoque cárnica de meter a unas pocas decenas (o centenas) de personas en una gran habitación para realizar desarrollos no tiene sentido. Queda muy bonito en la foto y puedes incluso poner una webcam para que tus clientes vean cómo un puñado de monos teclean por cacahuetes, pero es del todo anti-productivo.

Un buen desarrollador necesita su espacio de trabajo silencioso, sin interrupciones. Por eso es bueno el teletrabajo: tú mismo buscas cual es el espacio donde eres más productivo. Y si alguien te necesita, puede enviarte un correo o un mensaje directo que tú contestarás cuando bajes de tu concentración. Y si es algo muy urgente, para eso está el teléfono.

Nada más que añadir. Bueno, que #4 felicite al aprendiz de BOFH de la imagen

» autor: delawen

#23 Si interrumpes a un desarrollador, estás haciendo el mundo peor

timonoj — Mon, 09 Jun 2014 04:58:11 +0000

#8 La referencia es a esto. www.youtube.com/watch?v=qfResyFrqlM

» autor: timonoj

#22 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--122466-- — Mon, 09 Jun 2014 03:39:44 +0000

[Usuario deshabilitado]

» autor: --122466--

#21 Si interrumpes a un desarrollador, estás haciendo el mundo peor

f2105 — Mon, 09 Jun 2014 02:28:37 +0000

Interrumpir a un desarrollador mientras está profundamente concentrado en código, es cómo interrumpir una eyaculación.

» autor: f2105

#20 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--88899-- — Mon, 09 Jun 2014 01:25:03 +0000

El TDD es la mierda. Pasaba por aqui.

» autor: --88899--

#19 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Despero — Mon, 09 Jun 2014 01:23:06 +0000

Esto es en general para cualquier trabajo en el que se requiera un poco de elucubración y una cadena de pensamientos. Cuando te rompen el tren de pensamiento, tienes que empezar desde cero.

» autor: Despero

#18 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Relator — Mon, 09 Jun 2014 00:29:42 +0000

Yo soy el artista de la pista y suscribo la viñeta como algo que muchos jefes y no jefes deberían tener encima de sus mesas a primera hora de la mañana.

» autor: Relator

#17 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--179407-- — Mon, 09 Jun 2014 00:23:08 +0000

[Usuario deshabilitado]

» autor: --179407--

#16 Si interrumpes a un desarrollador, estás haciendo el mundo peor

nanobot — Mon, 09 Jun 2014 00:12:26 +0000

Oh sí, que todas las putas páginas te obliguen a estar haciendo scroll hacia abajo todo el rato que parece que estás buscando algo en una biblioteca que sólo tiene pergaminos, es hacer del mundo un lugar mejor, sí.

No te jode...

» autor: nanobot

#15 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--347930-- — Mon, 09 Jun 2014 00:07:06 +0000

[Usuario deshabilitado]

» autor: --347930--

#14 Si interrumpes a un desarrollador, estás haciendo el mundo peor

ktzar — Sun, 08 Jun 2014 22:53:15 +0000

#13 El papel es tan de los 2000... Ahora, antes de escribir código, deberías empezar por tus tests. Así no se te olvida lo que estás haciendo:

- Test, que falle
- Lo arreglas, commit
- Otro test, que falle
- Lo arreglas, commit

Así, te interrumpan cuando te interrumpan, puedes seguir donde estabas, ya que un test incluye bastante de lo que pensabas hacer en el código y a veces cómo pensabas abordarlo.

Típico test que está sin solucionar:

```js
var popup = popupModule.createPopup('#popup', '#trigger');
$('#trigger').trigger('click');
expect($('#popup').is(':visible').toBeTruthy()
```

Cuando me encuentro ese test que falla, sé perfectamente qué es lo que tengo que implementar.

» autor: ktzar

#13 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Joaqui — Sun, 08 Jun 2014 21:39:32 +0000

#11 Antes de sentarse a programar hay que escribir, eso es lo único que digo, ni flujo de ejecución ni nada, las ideas al papel.

» autor: Joaqui

#12 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--330392-- — Sun, 08 Jun 2014 21:24:38 +0000

#8 Veo que se han perdido los clásicos

www.youtube.com/watch?v=n3Gv2yhv2N8&feature=kp

» autor: --330392--

#11 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--151124-- — Sun, 08 Jun 2014 21:20:43 +0000

#10 Ayuda bastante, sí. Pero no puedes escribir el flujo de ejecución de cualquier cosa.

» autor: --151124--

#10 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Joaqui — Sun, 08 Jun 2014 20:55:24 +0000

Nada mas fácil que coger papel y boli para evitar esas cosas...

» autor: Joaqui

#9 Si interrumpes a un desarrollador, estás haciendo el mundo peor

ElPerroDeLosCinco — Sun, 08 Jun 2014 20:29:01 +0000

El problema es que le faltan los paréntesis en la condición.

» autor: ElPerroDeLosCinco

#8 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--10803-- — Sun, 08 Jun 2014 19:30:57 +0000

#2 "¿Silencio, yo matar tú?"

» autor: --10803--

#7 Si interrumpes a un desarrollador, estás haciendo el mundo peor

eltxoa — Sun, 08 Jun 2014 18:41:36 +0000

#1 Lo traducen, no?

» autor: eltxoa

#6 Si interrumpes a un desarrollador, estás haciendo el mundo peor

Gargonslipfisk — Sun, 08 Jun 2014 18:15:47 +0000

#5 Delfines, que los tiburones son peces

» autor: Gargonslipfisk

#5 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--324579-- — Sun, 08 Jun 2014 13:00:08 +0000

#4 ¿ Los tiburones duermen ?

» autor: --324579--

#4 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--151124-- — Sun, 08 Jun 2014 12:04:13 +0000

#2 i.imgur.com/vv12Psc.jpg

» autor: --151124--

#3 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--151124-- — Sun, 08 Jun 2014 12:02:18 +0000

#1 Ya citan la fuente, difundir algo no es copiar/plagiar. En cualquier caso igual me da cambiarlo

» autor: --151124--

#2 Si interrumpes a un desarrollador, estás haciendo el mundo peor

--330392-- — Sun, 08 Jun 2014 11:52:14 +0000

Mejor que el cartel de do not disturb es el que yo tengo.

Silence! I kill you!

» autor: --330392--

#1 Si interrumpes a un desarrollador, estás haciendo el mundo peor

ikipol — Sun, 08 Jun 2014 11:48:59 +0000

No aporta absolutamente nada a la fuente original heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer

» autor: ikipol