#42443 por que no me explicas que esta mal de mi metodo?
imagina que tienes que hacer una custom cdn sobre quic para re-emplazar la de netflix, como enrutas? a caso hay algun error en mi metodo?
imagina que ademas tienes que sacar analitcas de los logs que generas, como lo harias? acaso mi metodo falla?
jeje no puedes
#42451 https://github.com/FiloSottile/mkcert
fijaros como en este mensaje no hay insultos, que podria haberlos, hoy me he tomado la pastilla
Chavales, otra vez, ya es la 4 o la 5, @isvidal me ha dejado tirado en el viaje a Suiza...
Yo de mientras, hello world en React.
Obviamente usando javascript, typescript es para fperos.
#42466 Y eso con toda la sobre enginieria que tienen montada por detras inecesaria. Twitter podria funcionar con 20 ingenieros y 3 charos de rrhh.
El caso de Elon en twitter es el caso perfecto de juego de tronos sobre el que blogee el otro dia.
Una empresa construida para quemar dinero de inversores privados, con perdidas billonarias anuales... Menuda pocilga. Todo con objetivos politicos de controlar los medios de comunicacion. Patetico.
Y gracias a Elon han echado morralla de meta, google, amazon y otras.
#42469 no he puesto mucho pensamiento en el número
pero llevo dos años trabajando en una teoría de cómo evaluar y formar equipos de ingeniería
y cómo determinar si es un buen equipo compuesto de buenos ingenieros como balancear equipos como subdividir como maximizar
el mismo método lo puedes aplicar a la empresa ya que se basa de momento en definir el equipo como un espacio tensorial
seguro que recordaréis mi post donde un ingeniero es un tensor [-1,0,1] y los componentes son skills/campos.
Aun no tengo el modelo definido y demostrado. Obviamente se puede hacer como lo hago pero puede ser interesante usar propiedades de varianza o simetría para simplificar la teoría. En eso ando enfocado.
Tu que tienes base seguro que entiendes rápido la idea.
#42471 #42472 el problema del grupo de 3 mujeres es que no funciona. siempre hay 2 que se llevan mejor y la otra es el paquete al que acaban dejando tirado.
esta teoria ya esta resuelta. en el trabajo lo mejor siempre es 0 mujeres.
asi no tienes problemas de que se te quejen de que cobran menos que un hombre o que haya poca representacion en leadership o tengas que darle la baja por maternidad.
podemos por favor centrarnos en las teorias del futuro?
#42474 los amores de oficina de sexo consentuado* y fuera de horario laboral** no lleva a nada
#42475 o en el crossfit, hace unos dias me he enmone de una bebita tremenda.
los amores de piwi con imigrantes ilegales* casadas por papeles** en tramites de divorcio*** terminan mal
siguiendo con mi libro, el tema de tratar el producto como tangencial vs ortogonal como lo veis? esta seria una vision tangencial
como podeis ver añado un factor de politica, que es el de negocio, que segun mi teoria NO esta relacionado con producto. "hacer ver" que esta relacionado es parte del a politica. el otro dia publique al respecto en el blog.
(podeis ver como no encaja del todo bien la parte tecnica con el producto, el hecho de que algo sea end user o front end depende del producto... esto me hace decantarme por la vision ortogonal donde producto se aplica a TODO)
(y sin entrar mucho podeis ver como de la izquierda hacia la derecha salen todos los puestos de trabajo que hay en un equipo, em (politica), pm (producto), user seria frontend, movile o apis publicas, backend que sirve el frontend, backend que interactua con el os como devops, y infra que seria provisionamiento.)
mi idea es que sobre cada uno de los campos, nos centramos en 3 hard skills/factores:
estos 3 factores cubren todo el ciclo de vida de una entidad en mi teoria. Entidades como pueden ser: equipo, producto, software.
Y los valores posibles que un fpero puede tener para cada campo son [-1, 0, 1]. donde -1 significa que perjudica, 0 no hace nada, 1 contribuye. Donde serian las componentes.
Entonces las dudas las tengo en como componer los resultados para obtener algo parecido a esto:
Pero multidimensional y que se pueda realizar operaciones con los resultados. por ejemplo, comparar dos equipos, maximizar/minimzar areas. Y que sea una vision o proyeccion como la de arriba para que la gente pueda visualizar y entender los resultados de manera facil.
Algunos factores que estareis pensando como la comunicacion y demas soft skills estan dentro de los hard skills. Implementacion, troubleshooting y reliablity ya considera estos factores para cada campo.
Otros factores como "tech debt", realizar MVP vs trabajo a largo plazo escalable, en la vision tangencial de la teoria no encajan muy bien. Deberian ser weights que aplicas desde producto al resto de skills... Y esto no me termina de gustar. Prefiero tener una teoria donde defines un contexto temporal y espacial. Es decir, tener variables globales en lugar de multplicadores.
En la vision ortogonal donde producto esta fuera del sistema y sirve para definir el contexto y propiedades de este, creo que encaja mucho mejor.
#42477 arriba precisamente pongo una teoria que esta mal y te explico porque. y el porque lo hago hablando sobre producto, pero seria tambien con politica si.
para sacar una teoria y que esta sea valida hay que buscar los contra ejemplos, sacar otros puntos de vista etc etc porque por ejemplo, quizas tansolo necesitas cambiar una parte de algo que esta mal para que el resto sea mejor que usando otra teoria. no?
y te lo puedo demostrar facil, si pongo a la izquierda como elementos comunes producto y politics, en lugar de al mismo nivel que los tecnicos, pues ya estaria no? quizas lo hago. aunque hay otros elementos que te romperian el esquema. trabajar en un MVP vs un producto a 5 años por ejemplo. las skills cambian segun estas componentes tambien... por eso digo que es mejor tener frames y componentes ortogonales. ya que la ingenieria es:
enginieria = resolver un problema concreto, en un espacio y tiempo concreto con limites de recursos concretos
lo que yo estaba tratando de hacer era poner al mismo nivel de campos de conocimientos de enginieria los "tecnicos" con los de "producto" y "politica". y que los distintos perfiles como un manager o un product manager, son exactamente los mismos componentes en un equipo que un devops o frontend. de esta manera todos se pueden tratar de la misma manera y tienen las mismas propiedades.
de la misma manera, he hecho lo mismo con el tener como hard skill las famosas "soft skill". Que es algo que me parece mejor que cualquier otra teoria. tu debes saber comunicarte con otros ingenieros, con producto y con politica (manager y leadership). y esto es una hard skill como aprender a programar. lo de que las soft skills van a parte es una mentira y suele ser una tecnica de manipulacion politica que utilizan los managers para controlar a los empleados.
dicho esto, si quieres comentar cualquier cosa adelante.
un tema interesante del que puedes reflexionar es la tech debt o el ciclo de vida de un proyecto. te puedo demostrar matematicamente (segun mi teoria), que la tech debt que comunmente la gente habla no es tech debt, es INCOMPETENCIA. Malos ingenieros/managers/pms. Osea demostrar como 1 + 1 = 2. porque si tenemos un sistema matematico con leyes y propieades, para que esta "tech debt" fuese posible y real, deberiamos romper leyes matematicas XD
de la misma manera, si un equipo va mal, te puedo demostrar que componente hay que echar a la puta calle de manera OBJETIVA. Si va mal por X motivo, puedes hacer un sistema y resolver y sacar que Y esta mal. Normalmente es un manager te lo anticipo.
los problemas que tengo es como meter: componente espacio temporal, complejidad y escalabilidad, fases / ciclo de vida de producto. De manera que estos sean comparables... Porque meter ciclos y temporalidad ya es un sistema diferencial. Igual que el crecimiento de componentes.
No se que matematicas son las mas simples y que mejor funcionan para nuestro problema. Tenemos un sistema simple para un problema concreto, calculo diferencial y probabilidad para compar problemas y simular escenarios... Lo dificil es encontrar los elementos mas simples y que contengan la mayor informacion del sistema y que todo sea facilmente parametrizable. No puedes mezclar en hardskill algo lineal con no lineal por ejemplo.
#42479 separo business de producto. donde producto es lo que da dinero. y business es procesos empresariales y sobrecostes que lo pierden. escribi al respecto el otro dia.
negocio != producto.
product = + dinero
negocio = - dinero
#42481 negocio no significa saber vender un producto. saber vender un producto es producto...
la palabra negocio se ha prostituido, como explique y vuelvo a repetir. parte de la "politica" es parecer que tu trabajo es hacer dinero. pero no es cierto. si tu crees que negocio = producto. es que han hecho un buen trabajo.
negocio son procedimientos internos, agile y scrum certificates, coaches, psicologos, middle managament, heads of engineering sobre VPs, sobre costes, robar dinero de inversores... es como ser politico o funcionario. de ahi la palabra "politica" sea sinonimo para "negocio". Un FUNCIONARIO que puto valor crea para al pais? si esta robando dinero publico ??? pasamos dinero del sector privado al publico.. XD eso no es "crear" nada.
antes de comentar, podriais al menos leer el anterior blogpost por ejemplo donde explico los conceptos de producto y negocio. en lugar de follaros mi definicion y decirme que esta mal mi propia teoria...
porque aparte de quedar como mal educados, que lo sois y mucho. para mi os leo y quedais como autenticos retrasados mentales. que tambien lo sois. como el subnormal de atras, donde he puesto yo un ejemplo de algo que esta mal explicando porque esta mal, y me ha dicho que estaba mal mi ejemplo que estaba mal... de eso iba el post subnormal. @wdaoajw y eso que ayer no te insulte despues de soltar esta gilipollez "meter el cert a cada micro es un coñazo" puto subnormal. es que aparte de no tener ni puta idea de lo que hablas, enseñas a alguien mal y justificas tu incompetencia como si fuera imposible/coñazo dedicar 5 minutos a solucionar el problema.. atontao.
ahora me vais a venir a decir que mi definicion de producto y negocio/politica esta mal. cuando soy yo quien se la ha inventado.
voy a dejar de postear en serio otra temporada, porque cada dia sois mas tontos, decis tonterias mas grandes y os autofelais, no leeis ni tratais de comprender nada... decis mentiras y cosas que estan mal como si fuesen verdades absolutas... incluso contradecis teorias que otros se han inventando XD como va a estar mal mi definicion? si me la he inventado yo?
en serio, cada dia vais a peor. creia que en 1 año de tiempo habriais aprendido algo de programacion o ingeneria. pero seguis siendo los mismos fperos. de hecho vais a peor. sois como los tontos del clean code, o la gente que hacia software en la dot com... las mismas boberias encima.
no se puede postear nada ni tratar de tener debates interesantes sin que os cagueis en los pañales.
#42498 ebpf + ktls
la verdad, no se como lo haceis, sabria hacerlo mejor
estamos hablando de una poc para una prueba que correra en local tontito
que se siente que alguien que no se dedica a lo que haces sepa mas que tu? vas 10 años por detras...
aws y k8s son una puta porqueria, buena falacia de autoridad, hay gente haciendo las cosas mucho mejor que ellos
mejor como yo lo haria si fuese mi trabajo, al menos no seria tan cerrado de mente de soltar una respuesta de 2005 como si fuese la verdad absoluta cuando soy un completo ignorante
me voy a seguir a poniendo botones en mi pagina de react. soy un puto dios del front end.
#42500 claro... supongo que netflix es una compañia que no hace nada y vende humo con sus papers.
un buen ingeniero resuelve el problema de la mejor manera posible.
y yo puedo hacer soluciones que aun nadie ha inventado si la mejor solucion es esa.
igual que otro dia puedo usar una tecnologia de hace 20 años si la mejor solucion es esa.
tu no puedes decidir, porque para decidir se tiene que PODER.
#42502 jeje
es broma compañero, un pique sano, un muy buen abrazo
algun dia, si quieres podemos hacer pair programming, tu me enseñas a hacer el hello world de tls, y yo te enseño como se hara dentro de 20 años
el otro dia, no es broma, tuve que mirarme videos de CORS, no lo entiendo la verdad. el preflight. no entiendo el motivo. me cuesta convencerme de esa decision tecnologica.
#42503 tienen la mejor cdn del mundo
aqui por ejemplo te explican lo de ktls
cuando yo hablo, las libretas y los bolis deberian tomar nota
#42505 me he cansado de ser el mejor y vivir en el futuro
empiezo de zero con el frontend asi puedo saber como os sentis vosotros cuando no sabeis lo que estais haciendo o haceis algo mal
me gusta esta sensacion de ser ignorante y estupido, me acerca a vosotros la gente normal
Elon tiene razon.
Y los que dicen que la culpa es de la directiva y managers tambien.
PERO.
De la directiva y de los managers anteriores que estuvieron haciendo POLITICA en lugar de INGENIERIA. Como ya explique en mi blog post.
El buen software debe ser escrito para ser constantemente re-escrito y re-emplazado, no para ser re-utilizable. Como ya explique en mi blog post.
El problema que ahora tienes cientos de microservicios, de cien equipos distintos, de cien managers distintos que querian crear IMPACTO, de mil senior software engineer distintos que todos querian lucirse con ARQUITECTURA, en cien lenguajes distintos, que co-operan entre ellos sin sentido en una arquitectura que aprovo un head of engineering que no sabe ni lo que es un puntero, pero eh, ha dado trabajo ha mucha gente SINERGIA y ha utilizado muy bien el budget ESCALADO.
El codigo re-emplazable, si tienes el equipo X que se comunica con el codigo de equpo Y. Para ser remplazado necesitas cambiar o X o Y por el equipo Z.
El codigo re-escribible, con el paso del tiempo si tienes un codigo X e Y, puede ser re-emplazado y OPTIMIZADO para que solo sea codigo Z. Quitando tech debet, mejorando la eficiencia y el rendimiento, y reduciendo los costes de ingenieria + los costes de mantener 2 equipos haciendo lo mismo!
Ese codigo se cae a pedazos por si solo como la mayoria del software contemporaneo que da puta pena. Yo si no hago nada en mi servicio, por si solo, se rompe XD En que mundo vivimos en que un puente se rompe cada semana por si solo?
Estais tan acostumbrados a la mala programacion y malas practicas de ingieneria, estan tan arraigadas en la cultura contemporanea, que os cagan y mean en la boca y haceis gargaras antes de tragaros el cocktel.
Cuanta verdad en un solo post, pero claro, a los fperos del hilo no os gusta admitir que haceis mal vuestro trabajo a proposito para mantenerlo, o haceis mal vuestor trabajo a proposito por incompetencia e ignorancia.
Dale un proyecto de 10 equipos a un ingeniero de software y en 5 años tendras 500 equipos, y diez mil micro servicios. Incrementando los costes x100.
Dale el mismo proyecto a un ingeniero mecanico, y en 5 años tendras 5 equipos haciendo lo mismo en la mitad de trabajo. Reduciendo los costes x100.
Por eso la ingenieria informatica NO es una ingenieria de verdad.
Y por esto Twitter se cae a cachos solo.
No haceis nada, lo poco que haceis lo haceis mal y sin tener ni idea.
Cuando estas en tu empresa Paco sin usuarios no le importa a nadie, pero cuando empresa Paco pega el pelotazo y se vuelve algo como Twitter empieza a petar todo y vienen los lloros.
En todos los años que llevo picando codigo a prod, nunca nadie ha tenido que tocar NADA mio. Si lo escribo UNA vez, ya NO SE ROMPE.
Y si se tiene que tocar, es facil de re-escribir y tirar a la basura.
Tampoco hace falta llorar tanto si nadie de aqui tiene ningun tipo de responsabilidad.
En IT no existe la responsabilidad. Es todo humo.
Mañana pueden arder todos los proyectos en los que estamos que no nos pasara nada.
Que va a hacer tu jefe? Echarte a la calle y encontrar a alguien que en menos de 1 año entienda la sobre enginieria que tienes montada? A Elon Musk no le ha funcionando muy bien jeje ha infravalorado a los fperos jeje
Aprovechad el tiempo para ir al gym, leer, estar con vuestros amigos o familia, daros una vuelta en moto, o que pasa? que no teneis nada en vuestra vida a parte de trabajo? jeje
La mayoria de managers y senior tech lead no tienen nada que hacer en sus vidas salvo meterte meetings a las 4 de la tarde para escapar de su familia. Ni tienen amigos, ni hobbies, ni se espera ningun cambio. El trabajo "les llena", o mejor dicho, un puto escape a sus traumas mentales.
Ya lo dicen en blind, para ser manager debes ser un enfermo mental y un psicopata. Estais de acuerdo?
#42564 todos los. Managers son iguales
Gente que cobra más que tu porque tiene RESPONSABILIDAD de llevar gente
Ya me dirás que lleva alguien y como es responsable si mañana se te va el equipo entero y no puedes hacer nada.
Los vende humos por excelencia. Psicópatas de la carrera de la rata que sienten satisfacción MANDANDO cuando no deciden nada.
Tu única responsabilidad es pagarme más que la. Competencia y no saben ni hacer eso
edit:
https://waydev.co/engineering-manager-responsibilities/
Here’s an overview of the most common tasks and duties that usually come with the software management
De todas sus tareas solo hacen la parte de comerle la polla al jefe o tratar de hundir a otros equipos para tener mas budget.
Responsabilidad? Ninguna, todo recae sobre los ingenieros, el PM o HHRR
Si algo falla de lo que "supervisan", siempre son problemas externos. Que si una crisis economica, mucha rotacion en la industria tech, poco talento para esa tecnologia, blah blah. 0 responsabilidad.
Todo politica. Juego de tronos.
#42566 mucha bromita pero solo digo verdades
tu lo sabes bien, vives de estafar inversores y te quejas de que no tienes trabajo ni nadie hace nada
tu trabajo es estafar inversores y ya lo habeis hecho XD
hora de buscar a otros pardillos aunque se vienen tiempos mas duros para vender humos
en las empresas grandes es lo mismo, pero la empresa no se va a la mierda porque hay gente que la usa...
pero vamos, ahora rotacion de C-levels y upper managament ha saco... esta gente no aguanta mas de 3 años en el cargo.
cuando vamos a la playita?
#42571 tu manager? tienes el cerebro comido por la carrera de la rata
nadie es mi manager, nadie es mi jefe, nadie decide nada de lo que yo hago
hay gente que me paga por hacer lo que yo quiera cuando quiera
y hay gente que gana dinero por mirar como lo hago
#42577 si quieres hablar habla, no te pongas a llamar la atencion como un pussy
pero deberias hablar en tu nombre no en el de los demas
#42582 yo creo que los usuarios podeis proponer los temas/topics que querais que os explique como blog post, papers, libros de software, o parrafos de mis rants.
y podemos comentarlo con comunicacion verbal. de manera estructurada y comentando punto por punto el topic.
creo que un stream corto de 20 minutos es un buen formato para comentar punto por punto algo es mas facil de digirir que un tocho post o ensayo mio de 10 minutos.
asi si sale un tema que es complejo o dificil de responder, puede aplazarse para otro stream.
la diferencia con las clases que di en el pasado, es que en lugar de explicar algo con slides mio, cogere algo de otra persona que hayais propuesto y lo destrozare.
nunca sere un abuelo deprecated porque me jubilare antes.
#42584 podriamos hablar de porque el DDD, arquitectura hexagonal, event driven y CQRS y demas como se aplica y discute habitualmente esta mal.
un ingeniero que utiliza estas cosas es un claro ejemplo de mal ingeniero que no tiene ni idea de lo que esta haciendo ni del porque
es el equivalente al javero haciendo TDD y cucumber en 2005 porque lo ha leido en un libro de uncle bob
el otro dia discuti con un famoso autor de libros de testing y le mande pa su puta casa jeje farmeando manitas.
#42584Wei-Yu:edit: pues me he quedado pensando y lo de la arquitectura vernacular y ddd no es tan loco, te cedo la idea sin derechos de explotación
ya sabes que la arquitectura de software no existe
existe la jardineria de software
tengo un blog post al respecto
filtrando por usuario desu
