Portada
mis comunidades
otras secciones
#1:
Si
la
calidad
de
los
comentarios
de
meneame
se
midiera
por
número
de
líneas
...
la
calidad
de
los
comentarios
de
meneame
se
midiera
por
número
de
líneas
...
#7:
Jefes dirigiendo un trabajo del que no tienen ni idea de qué va. Pasaba en 1982 y pasa en 2021.
Como dice el principio de Peter: En una jerarquía (organización o empresa) todo empleado tiende a ascender hasta su nivel de incompetencia
Como dice el principio de Peter: En una jerarquía (organización o empresa) todo empleado tiende a ascender hasta su nivel de incompetencia
#22:
Yo me he encontrado juniors de dos tipos: los que hacían líneas a mansalva para impresionar al revisor de código y parecer que sabían mucho y los que hacían todo en una línea ininteligible para impresionar al revisor de código y parecer que sabían mucho.
Con el tiempo llegan a un equilibrio.
Con el tiempo llegan a un equilibrio.
#57:
#7 No es exacto, el principio de Peter ocurría en 1982 pero esos eran los buenos tiempos donde tu jefe era un inútil pero sabias que antes de llegar ahí había sido bueno en algo, pero ahora eso ya no pasa. Lo que pasa ahora es el principio de Dilbert que dice que las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar.
#14:
Esas -2000 lineas son la diferencia entre un programador medio y un verdadero hacker.
#28:
Los commits con mas lineas borradas que insertadas son los que sientan mejor (refactors, optimizaciones, limpiezas de codigo, etc)
Comentarios
Si
la
calidad
de
los
comentarios
de
meneame
se
midiera
por
número
de
líneas
...
#1
for palabra in 'Pues que siempre habría alguien haciendo trampas'.split():
····print(palabra)
#2 mejor println
#4 Es python, ya salta de línea él solito
#5 Nunca te acostaras sin saber una cosa más
#6: De hecho yo lo veo como un problema para principiantes, es mejor que el lenguaje de programación haga pocas tareas simples, así la gente aprende a pensar por si misma y no a acostumbrarse a tener todo hecho.
#15 Da igual, ya se bajaran un framework de 50000 lineas de código para cualquier pijada...
#68: Sí, como las entradas de Instagram donde ponen:
1 "cómo reconocer perros y gatos por AI"
2 Código: una línea en plan "import perros y gatos from open_CV" y otras en plan "tomar una foto, aplicar una función y mostrar al usuario si había ahí un perro o un gato."
3 Pedir que des al like y les sigas.
#5 No.
#25 Sí.
#2 Con esos cuatro puntos te va a dar error de indentado
#30 Es que MNM no deja indentar, era para simular el sangrado
#2 print(*'Pues que siempre habría alguien haciendo trampas'.split(), sep='\n')
#1
T
I
E
N
E
S
T
O
D
A
L
A
R
A
Z
Ó
N
#1 Y si fuese por líneas negativas como en el artículo...
#13: Mejor, así cobras 65535 - 2000 = 63535 unidades monetarias.
#1 efectivamente .. seria algo como así..
/// hola mundo
array int a[10];
array char b[10];
a[0]=0;
a[1]=0;
a[2]=0;
a[3]=0;
a[4]=0;
a[5]=0;
a[6]=0;
a[7]=0;
a[8]=0;
a[10]=0;
a[0]=a[0]+150;
a[1]=a[1]+157;
a[2]=a[2]+154;
a[3]=a[3]+141;
a[4]=a[4]+40;
a[5]=a[5]+155;
a[6]=a[6]+165;
a[7]=a[7]+156;
a[8]=a[8]+144;
a[9]=a[9]+157;
char b[0] = a[0];
char b[1] = a[1];
char b[2] = a[2];
char b[3] = a[3];
char b[4] = a[4];
char b[5] = a[5];
char b[6] = a[6];
char b[7] = a[7];
char b[8] = a[8];
char b[9] = a[9];
print("%c", b[0]);
print("%c", b[1]);
print("%c", b[2]);
print("%c", b[3]);
print("%c", b[4]);
print("%c", b[5]);
print("%c", b[6]);
print("%c", b[7]);
print("%c", b[8]);
print("%c", b[9]);
resultado: -->
hola mundo
-----------
print("hola mundo");
resultado: -->
hola mundo
#41 ¿No te falta la línea
a[9]=0;?
Lo digo porque si necesitas inicialización...
Pasarme media carrera sin equipo, agudiza la lectura de código.
#62 si me equivoque en la linea 11 , mas código... mas errores .... gracias por la depuración
11 a[9]=0;;
Jefes dirigiendo un trabajo del que no tienen ni idea de qué va. Pasaba en 1982 y pasa en 2021.
Como dice el principio de Peter: En una jerarquía (organización o empresa) todo empleado tiende a ascender hasta su nivel de incompetencia
#7 La mayoría de los jefes miden la productividad en julios transferidos desde la raja del culo del trabajador a la esponja del asiento de la silla.
#9 Alguien debería inventar sillas de oficina hechas de cobre, imagina el aumento de productividad.
#17 #9 Esto puede abrir un debate que me parece interesante. ¿Cómo mides la productividad de un desarrollador?
De todo lo que se me ocurre, nada es aceptable. Lo más cercano, con sus pegas.
- Por tareas finalizadas ponderadas por el peso de las mismas en Scrum.
Claro, ¿y si hay errores? ¿y la calidad del código? ¿y si invierte tiempo en refactorizar?
#45 ¡ Qué modernos ! Mi scrum no tiene báscula, y cuando lo estimamos nosotros se va todo a la puta
Ahora en serio, no se puede medir de forma cuantitativa, la productividad de un programador es como el cariño, es algo que vas notando con el tiempo.
#7 En mi trabajo hace unos años alguien tuvo la idea de medir la productividad y una de las métricas propuestas fue precisamente el número de líneas.
Por suerte ya conocíamos esta anécdota de Bill Atkinson y después de reenviarla por correo ya nunca nadie más volvió a hablar de ella.
Al final decidieron que la mejor forma de medirla era usar un sistema muy español de decisión digital. El jefe decía quien era el más productivo señalándolo con el dedo y él era el beneficiario de la conocida paga de beneficios.
Por el camino se dieron cuenta que si solo tenían en cuenta el dinero que ganaba una persona, podía no ser muy justo porque a veces hay proyectos con monos que dan mucho dinero y otros con los mejores que dan perdidas. Pero compensa tenerlos porque permite volver a vender otros proyectos que dan dinero aunque los lleven monos.
#7 No es exacto, el principio de Peter ocurría en 1982 pero esos eran los buenos tiempos donde tu jefe era un inútil pero sabias que antes de llegar ahí había sido bueno en algo, pero ahora eso ya no pasa. Lo que pasa ahora es el principio de Dilbert que dice que las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar.
Yo me he encontrado juniors de dos tipos: los que hacían líneas a mansalva para impresionar al revisor de código y parecer que sabían mucho y los que hacían todo en una línea ininteligible para impresionar al revisor de código y parecer que sabían mucho.
Con el tiempo llegan a un equilibrio.
#22 yo me he encontrado juniors que les ha mandado trabajo de senior y casi analista y luego nadie ha revisado el código, ni programa ni persona.
Lo peor que tiene java es que puede conseguir que funcione cualquier mierda, y cuando ya no se puede ñapear mas...... a mi correo electrónico llega un puto correo que dice "mira a ver si ves porque no funciona esto"
Hay días que me siento como el colector de basura de la oficina.
#33 eres imprescindible, felicidades. Solo los buenos son capaces de lidiar con la basura de otros.
#50 nadie es imprescindible, al final la basura siempre le cae a un gilipollas, si me piro, se quien es el siguiente en la lista.
Y quizás no saque la basura tan rápido, pero la sacará. Y al final es lo único que cuenta, que la basura se solucione.
#52 era una forma de hablar. Obviamente todos somos prescindibles. Pero es verdad, para mi, que cuando te llueven los marrones es porque has llegado a un status. Quizas no el mejor. Porque lo normal en estw mundillo es el caos y la inmundicia. Alguien que es capaz de poner orden, tiene su valor.
#33 Hay una cosa peor. Te llega una mierda que falla a ratos y te piden que la arregles. Indicas lo que hay que hacer para arreglarlo pero nadie lo arregla y prefieren hacer un cutre-parche.
Y tiempo después vuelven a pedirte que lo vuelvas a arreglar... porque tu cutre-parche no funciona en un caso que ni sabías... pero como lo programaste tu... ahora es tu obligación arreglarlo.
#77 yap, esa mierda me suena demasiado.
Esas -2000 lineas son la diferencia entre un programador medio y un verdadero hacker.
#14 Douglas McIlroy lo llama codigo negativo: https://en.wikipedia.org/wiki/Douglas_McIlroy#Views_on_computing
#18 Y lo bien que te quedas cuando arreglas un error borrando líneas de código
#19 Lo malo es cuando no sabes qué líneas puedes borrar. Hay proyectos con una cantidad de código muerto acojonante.
Al final acabas escribiendo los tests para ver la cobertura de código y saber dónde entrar hacha en mano.
#31 Ahora que están tan de moda los microservicios, hace poco ví uno de un compañero que me extrañaba por qué el archivo de código java pesara tanto cuando el bytecode era mínimo. Me dió por abrirlo y voilá, mogollón de bloques de código muerto comentados (curiosamente ningún método ni ninguna clase tenía su comentario descriptivo de cabecera para llevar mínimamente una documentación estándar). Cabe decir que el que lo había hecho era un gran fan de la "pasta italiana".
La solución: estaba en un repo git, con lo que era simple, borrar todo el código muerto.
#37 Algo parecido me ha pasado a mi. Encontrarme puñados de código comentado. ¿Why ? Si lo tenemos en un control de versiones... En fin.
Pero lo peor es encontrarme clases enteres de funcionalidad muerta, que están así desde hace años (10 años o mas). Y lo peor, es que tienen dependencias con librerías del año de la tana que luego dan problemas en JVMs modernos o que chocan con otras librerías por sus dependencias.
#72 Y en cierto banco me he encontrado funcionalidades hechas en Javascript que ya estaban hechas en Primefaces, claro que los que mantenían esa aplicación pasaban de JSF (ni se habían molestado en aprender lo más mínimo). Lo más sangrante era que estaban llamando a métodos de Beans de JSF directamente desde javascript, y por eso tenían como un crack al que lo había hecho, sin saber que eso directamente abría las puertas a muchos fallos de seguridad. Menos mal que era una aplicación interna y que no se usaba en las oficinas. Eso por no decir que el acoplamiento entre capas debido a esas prácticas era más fuerte que una soldadura en acero reforzado.
Y el pan nuestro de cada día: código muerto o lava code en cantidades industriales.
#19 y lo que te cagas en los muertos de la persona que escribió ese código.
#32 sobretodo cuando es tu "yo" pasado
Es la única persona que seguro que no va a tomar represalias
#36 ¿? En mi caso es más bien al revés. Anda que no he dicho en voz demasiado alta "¡¡¡PERO SERÉ GILIPOLLAS!!! , ¡¡Es que mira que hay que ser gilipollas!!, idiota, idiota perdido; es que mira que hay que ser S-U-B-N-O-R-M-A-L (bufido bufido) ¡¡Immmmmmmmbécil!!".
(y similares)
Nadie me insulta ni me maltrata tanto como yo mismo. Es deprimente. Después de esa bronca llego a casa dolido y triste, pero con ganas de mejorar.
A mis compañeros no les digo nada, son humanos y todos cometemos errores.
#48 a los compañeros no hay que decirles nada, a no ser que sea un tipo de negligencia repetida y haya confianza, y siempre para mejorar, nunca para echar en cara.
Eso no quita que las tumbas de sus antepasados no hayan sido regaladas con defecaciones, pero es el calor del momento. Luego en el rato del café se pasa.
#48 #36 Alguien me dijo una vez que el infierno de los programadores consiste en tener que mantener tu propio código de hace 10 años.
#54 Por eso cambiamos de empresa cada 9
#56 Y cada dos...
#36 cuandonactuvas el git blame en el editor y ves que no puedes culpar a nadie del desastre...
#14 «La perfección no se alcanza cuando no hay nada más que añadir, sino cuando no hay nada más que quitar»
Antoine de Saint-Exupéry
Los commits con mas lineas borradas que insertadas son los que sientan mejor (refactors, optimizaciones, limpiezas de codigo, etc)
La moraleja de la historia es: haz las cosas del modo que más fastidie a tu jefe y dejará de pedirte que trabajes de más.
Gran jefe!
Estuve una vez en una cárnica en la que el supervisor revisaba los commits para ver cuánto se había modificado. Harto de eso, pues en ocasiones hacer 20 líneas podía llevar 10 veces más que hacer 200, en cada commit utilizaba un formateador de código diferente. Resultado, miles de archivos con cientos de líneas cuya diferencia era solo visual. Le era imposible buscar los cambios.
#23 estaba leyéndote el comentario y pensaba "para eso existen los autoformateadores de los ID"
Me gusta como piensa usted.
#23 Lastima que en lenguajes serios esto no funciona
go fmt.
Medir productividad en líneas de código, es un clásico de los gestores sin mucha idea. Otro muy habitual, es intentar doblar la productividad, doblando el número de miembros del equipo.
#38 O peor aun, intentar doblar la productividad usando el doble de miembros del equipo.... juniors (o becarios)
Donde dice descuarinjaría debería decir descuajaringaría.
#11 Descurdangarinjaría...
#11 Pues no, es descuajeringaría.
#40 Parece ser que ambas son válidas.
#85 Cierto, perdón. Yo siempre lo había oído con "e".
#11 El descuajaringador que lo descuajaringue, buen descuajaringador será.
Estando en asm del 68k es un mérito eliminar 2000 líneas ... y sus anotaciones.
_NEWHANDLE ;ask OS to do request
BNE.S MemFull ;if memory full, deep shit!
Ahora se miden por Puntos de
HistoriaHisteriauna magnifica politica de trabajo destinada conseguir una enorme productividad de lineas de codigo de mierda, ademas de una indentacion muy creativa basada en que se entiende por "linea de codigo"
Una idea muy loca: pagar más por menos líneas de código.
Me podéis enervar en vuestras absurdas reuniones eternas. Pero cuando programo soy libre.
#76 Así es: OS/2 Warp y 4 tiraban muy bien. Yo lo usé desde 1994 hasta 1999, cuando ya me cambié a Linux definitivamente, y pude probar una copia pirata de 2.0 y había muchísima diferencia. Es cierto que en Warp, al principio, había pocos controladores de video, pero cuando metieron la arquitectura GRADD, que simplificaba muchísimo la escritura de los drivers, de pronto "explotó" y había para casi todas, aparte de que podía usar las extensiones VESA en las tarjetas no soportadas.
Si en la universidad pueden determinar la dificultad de los ejercicios y los exámenes van medidos en tiempo, no veo porqué no se puede medir el coste de desarrollo.
Lo que ocurre es que la planificación es inexistente. Y por eso se alargan los plazos o se entrega a medias. Que si cambio de requisitos que si ahora hay que hacer esto o ahora no.
Yo a mi equipo la metrica que utilizo es sencilla : Esta funcion admite estos valores , y saca estos resultados. Vuestro objetivo es que tarde un % menos en devolver los resultados esperados con los parametros que os paso.
Luego paso tests automatizados con parametros diferentes y veo si la optimizacion es correcta para valores que no los he entrenado.
Poco a poco estoy conviertiendo a mi equipo en una CNN
Despues veo el codigo y si no tienen documentadas las funciones para el swagger , suspenso automatico.
#39 No trabajaría nunca para ti.
Esa técnica se usaba en IBM, y dicen las malas lenguas que fue el motivo de que las primeras versiones de OS2 2.0 fuese lentiiiiiisima.
#47 OS/2 2.0 no era lento. El problema siempre fue la compatibilidad de hardware (cada de vaca si no lo usabas en un PS/2) y la disponibilidad de software para OS/2
#70 El problema de OS/2 2.0 era que con las cantidades habituales de RAM de la época tiraba tanto de swap que iba lentísimo, lo que venía, supuestamente, por ese exceso de líneas y falta de optimización en espacio. Eso lo corrigieron en la versión 3.0, que precisamente por eso se llamaba "OS/2 Warp". Los mismos ingenieros de IBM le pusieron el apodo porque "iba a velocidad de curvatura".
#71 Windows NT 3 tenia un problema similar. Recuerdo que para la época requería una cantidad grande de RAM.
Y bueno, el problema de la SWAP haciendo lenta al sistema operativo, lo lleva arrastrando Windows desde su concepción...
#73 Sí, pero en el caso de NT, era más bien (bueno, ojo... que no es que yo sea un experto en el tema, sino que hablo de cosas que he leído por ahí) que era una arquitectura microkernel bastante pura, por un lado, y por otro que se obligó a que el código fuese lo más portable posible, con lo que no se utilizaron muchos trucos específicos de la arquitectura Intel que podrían haber hecho que fuese más rápido. A cambio, portarlo a MIPS, Sparc, etc, era una bicoca. De hecho, creo que fue en 4.0 que integraron en subsistema gráfico en el espacio de núcleo y ahí consiguieron un aumento bueno de rendimiento.
El caso de OS/2 era diferente porque era un sistema operativo con una arquitectura diseñada alrededor del procesador 286/386 (de hecho, creo que es el único que aprovecha "de verdad" el sistema de cuatro anillos de protección de los Intel, mientras que el resto, como Linux o NT, utilizan sólo el 0 y el 3 para una arquitectura "usuario-supervisor" clásica, además de aprovechar la segmentación y exponerla en su API). Ahí, que fuese lento y que tirase tanto de swap en 2.0 era por bloatware, y una vez más la prueba es que en la 3.0 se aceleró muchísimo sin mucho cambio en la arquitectura en sí.
De hecho, era tan específico que OS/2 para PowerPC era básicamente un sistema operativo nuevo con la misma API de usuario.
(por cierto: yo usé OS/2 durante muchos años y no tenía un PS/2, y funcionaba bien... si tenías memoria, claro. 8 megas mínimo para un rendimiento razonable. con 4 megas era mejor que quitases el WPS y usases un lanzador de aplicaciones más ligero).
#75 Yo tuve intentos de usar el OS/2 3.0 ... (fallaba la instalación por culpa de un virus, pero es otra historia).
Y ahora que estas mencionando, es verdad que la supuesta incompatibilidad de OS/2 con hardware, era mas un FUD de Microsoft, que algo cierto.
La verdad , es que cuando OS/2 (3 en adelante) funciona bien, funciona realmente bien. Recuerdo haber visto cajeros del Santander usando aun OS/2 hace como 4 o 5 años.
¿Soy el único que no lo entendía por no reparar en el signo "-"?
Telefónica usaba los Puntos Función para medir la complejidad del sw.
Al final, tardabas x jornadas, pues decías que tenía x/y puntos función, de acuerdo a la estimación de TEF para cada PF.
Y no, los gestores no eran tontos, sencillamente pasaban de ese parámetro, pero como se lo pedían de arriba, lo “calculaban” pasaban de chorradas, pero más o menos, gestionaban el proyecto razonablemente.
En tantos trabajos medir la productividad es muy difícil. Y en otros es más fácil y aún así no marca la diferencia. En mi última empresa, mi primer jefe me dió el mejor consejo, si quieres medrar aquí tienes que hacer Networking, hacerte amiguito de la gente con poder de decisión o influencia. Sin eso poco que hacer.
Dicen que uno de los roces que tuvo IBM y Microsoft (y que estos se marchasen y se llevasen su OS/2 NT que acabo siendo el Windows NT) fué que los de IBM se empeñaban en medir la productividad por lineas de código.
Historia entretenida, la versión en inglés, enlazada en la noticia, está mejor escrita.
#24, entretenida... A mi me ha decepcionado, simplemente que uno piso que hacía hecho - 2000 líneas de código porque el programa tenía esas líneas menos...
No fueron los jefes los que hicieron esa cuenta, sino él haciendo la gracia, y contando mal las líneas, porque habrá que contar las que escribes sin restar las eliminadas de antes. Que sí, que es absurdo medir así la productividad, pero esta anécdota, al menos así contada tienen poca chicha.
#65 En ingles tiene mas gracia (esta mejor escrito). Obviamente, la gracia viene tambien de que sucedio en los 70.
Como podrían medir la de los funcionarios?
Por el número de veces que van a comprar en horario laboral o por el tiempo que tardan en tomar el café?
Cuanto menos tardan y menos van a comprar más productivos
#43