Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




desu

#45300

6 1 respuesta
JuAn4k4

#45301 Con moneda trucada.

Zoko

#45298

Ah vale que de aqui sacas tu estilo

1 respuesta
Farmijo
#45298desu:

Este me ha encantado.

1 respuesta
desu

#45303 Taylor es un trozo de pan a mi lado.

Estas comparando a tu amigo que sabe dibujar (Taylor) con Pablo Picasso (Yo).

Cuando yo posteo tambalea la industria.

Los pelicolores y streamers de Twitch se ponen nerviosos....

Los tweets para defenderse y la ingenieria de camaras de eco empieza a rodar.

Tienen miedo, saben que viven en un chiringuito de mentira y falisadad.

Tic, tac, tic, tac.

#45304 A mi me gusta este:

https://taylor.town/busy-body

Por ejemplo:

estoy en un meeting y juego a vampire survivors
estoy en un meeting y foreo
estoy en un meeting sin audio y veo videos en youtube
estoy en un meeting y hablo con bebitas por ig
estoy en un meeting y preparo el entreno de crossfit
estoy en un meeting y estoy en crossfit
estoy en un meeting y trabajo

Fijate que si me libero del meeting, gano 1 slot.

3
Dr_Manhattan

2023 y excel no puede abrir dos libros con el mismo nombre

1 respuesta
Wei-Yu

#45306 me pasó hace poco, me quedé flipando

buena deuda técnica usar el filename en vez del abspath xddd

1 respuesta
Dr_Manhattan

#45307 tal cual tiene pinta a que es eso jajjaja, y tiene que ser jodido de arreglar con el tiempo que lleva así

desu

Vale la pena todo, pero si ya conoceis el tema, saltad al minuto 30.

del 43 al 50, xq los buenos ingenieros como yo escribimos TODO en una funcion y no rompemos en subfunciones ni usamos OOP ni cosas de esas. (entre otros temas)

3
PhDfailer

como hariais para mejorar vuestro código si sois el que más sabe de vuestro equipo? (sin ser esto mucho)

Libros, cursos o simplemente seguir practicando e intentando mejorarlo?

Pienso en quizá aprender un lenguaje fuertemente tipado

2 respuestas
B

#45310 pair programming

1 respuesta
PhDfailer

#45311 uno hace los test y el otro los intenta satisfacer?

1 respuesta
Wei-Yu

cambiar de empresa y cruzar los dedos para que te toque gente competente (sale mal)

1 respuesta
PhDfailer

#45313 no es opción, no llevo ni 2 meses y tengo poca experiencia "real" aunque cada vez me doy más cuenta que lo de la experiencia es un engañabobos, hay gente con 15 años de experiencia que no saben ni hacer la 0 con un canuto y otros que cobran 1/4 que esos que son los que llevan el carro

B

#45312 esa es una de las formas, si, pero tampoco hay porque ser estricto, lo suyo es que todo fluya natural y con total confianza contarle a tu pair como te sientes, quizás un día no te apetece soltar el teclado y otro no quieres ni tocarlo... naturalidad ante todo

Fyn4r

#45310 te voy a contar un poco lo que yo hago, no sé si funciona pero bueno xd

Primero define el aspecto concreto a mejorar, ejemplos, estás buscando que el código sea más fácil de testear? Reducir acoplamiento entre componentes? mejorar los tipos de datos de un algoritmo? Simplificar la arquitectura de un servicio? No sé, cosas así, intenta que sean pequeñas y bien acotadas, no quieres acabar con 2 problemas a resolver en vez de uno xd

Sobre contenidos en concreto yo creo que vale todo, blogs, tutoriales, libros, respuestas en stack overflow. Eso si, no se trata de que copies lo que veas, es más bien razonar sobre ello, piensa en cómo X solución de un tutorial afectaría a tu caso de uso concreto, en que se diferencia de lo que tienes montado, etc. Si ves que un contenido no te aporta next, no te fuerces a completarlo porque es perder el tiempo, y siempre puedes volver más adelante.

No sé, supongo que es todo tiempo y práctica

3 1 respuesta
Dr_Manhattan

#45316 buena respuesta pato niño rata

Slowbro

Someone’s Been Messing With My Subnormals!

Not related, pero cosas que a veces se ven y son graciosas:

for ( float32_t step = 0.0f; step < 1.0f; step += 0.001f ) 
{
    // Cosas que esperan que el bucle corra 1k veces
}
desu

Reducir el acoplamiento entre componentes no es ser mejor ,al contrario ,es ser peor ingeniero ...

Lo puse justo en el video de arriba ..

El consejo número uno para aprender es olvidar todo lo lo que crees que sabes ...

B

El consejo número uno es que si puedes evitar hacer algo, evítalo. La complejidad es la que mata los proyectos, el objetivo es aportar el máximo valor posible con lo mínimo.

Lo malo es que va totalmente en contra de todo lo que se suele enseñar.

2 2 respuestas
Kaledros

#45320 Y en contra de todas las métricas de performance que al final es lo que decide a donde va la pasta.

1 respuesta
B

#45321 por suerte, al menos yo, no me mido por ningún tipo de métricas absurdas como esas

r2d2rigo

#45320 por eso yo evito trabajar.

desu

Desde que Casey humillo publicamente a uncle bob esta ganando mucha traccion su contenido.

Me alegro.

Aunque no comparta todo, Casey te invita a pensar por ti mismo.

Y me gusta lo que dice de que las respuestas a su video han sido positivas... Porque la gente esta sufriendo tanto la OOP desde hace decadas que estan hasta la polla. Como yo por ejemplo, que llevo años enseñando data oriented design.


https://zackoverflow.dev/writing/premature-abstraction

Cada vez que decides partir una funcion en subfunciones estas haciendo tu codigo peor por definicion.

En terminos de Casey Muratori estas diciendo: mi cerebro no es lo suficiente como para entender el problema, voy a inventar un sub-problema parecido y resolverlo.

Pero no estas resolviendo el problema.

Por eso siempre hay que hacer todo en una funcion y hacer el refactor al final como yo lo hago. Cuando haces el refactor al final estas considerando los requerimientos de memoria y procesamiento de el programa y ya tienes una version funcional del codigo que hace lo que esperas que haga.

En cambio cuando eres un fpero como Miudev haces una puta porqueria de codigo que luego nadie entiende.

1
laZAr0

En la FP se enseña básicamente OOP, y siempre se dice a los estudiantes aquello de que lo más deseable es tener alta cohesión y bajo acoplamiento. Sin embargo, a la vez se les dice que si una función no cabe en una pantalla de sus IDE, probablemente es porque esté mal y tendrían que dividirla en otras más pequeñas. Al final, gente sin experiencia y que está allí para aprender a programar, acaba con una función que llama a otra función, que a su vez llama a una función que llama a otra función, para obtener información que necesita retornar la primera función; lo cual para el bajo acoplamiento viene de puta madre. Sin embargo, como se ha modularizado, el profesor está súper contento.

1 respuesta
desu

#45325 Si os acordeis yo hace tiempo declare la peor funcion que un programador puede escribir. El anti pattern mas grande y habitual en la programacion.

Puede tener muchas formas pero viene a ser algo de este estilo:

fn some_foo(inputs: []Struct) []Struct {
  const result = []Struct;
  for input, i in inputs { 
     if is_valid(i) {
       result[i] = transform_valid(input);
    } else {  
result[i] = transform_invalid(input) } return result }

Que da lo mismo si es asi:

fn some_foo(inputs: []Struct) []Struct {
  return inputs.filter(is_valid).map(transform_valid) ++ inputs.filter(is_invalid).map(transform_invalid);
}

O asa:

some_foo inputs = transform_valid filter_valid inputs ++ transform_invalid filter_invalid_inputs inputs

Donde da igual el lenguaje, si es gc o manual memory, la sintaxis, si es OOP o funcional o imperativo... Da igual si esto son arrays, slices o un channel de CSP... da igual si estas trabajando con structs o classes... Da igual.

Si tu ves este patron de codigo, lo que habitualmente es un for loop, iterado o stream... Y no te pitan los ojos. Eres mal ingeniero. Bueno, no eres ingeniero, eres un fpero. Un alinea divs como Miudev.

El anti pattern mas grande que existe.

1 respuesta
KooPad

#45326 La estás recorriendo 2 veces

1 respuesta
desu

#45327 En el primer ejemplo no lo hago. Y como digo, puedes suponer que el compilador te optimizara todo ese codigo para que sea la perfeccion absoluta a nivel de memoria, sin alocaciones, y ciclos de cpu. Como si lo escribes a mano en assembly.

Sigue siendo el peor codigo que un programador puede escribir.

No se si alguien se acordara de la solucion ni el porque...

Y te hace un MAL programador, porque como digo, puedes suponer que el compilador sera la perfeccion absoluta a todos los niveles y te hara un assembly optimo que seguira estando MAL.

Un BUEN ingeniero ve el problema al toque.

1 respuesta
Seal67

#45328 Por qué? Porque todas esas funciones las podrías meter en la misma y ya?

1 respuesta
aren-pulid0

Hago set con el valid y no hay compilador que te salve