Hidden_Text

Buscar empleo en tiempos de IA: de la abundancia al desierto ENSAYO — MERCADO LABORAL TECH Buscar empleo en tiempos de IA: de la abundancia al desierto Hace cuatro años sobraban las conversaciones. Hoy sobra el ruido. Una mirada honesta a cómo cambió la búsqueda de trabajo en software entre el boom de la pandemia y el desierto algorítmico de ahora. 24+ años en desarrollo de software · Notas desde la búsqueda activa Hace cuatro años, en plena pandemia, buscar trabajo como desarrollador de software se sentía casi como elegir entre ofertas. Las empresas competían por talento, l...

Keyed Services en .NET 8: Registrando y Resolviendo Dependencias con Claves Desde .NET 8, el contenedor de Inyección de Dependencias (DI) de Microsoft incorpora una característica muy esperada por la comunidad: los Keyed Services (servicios con clave). Esta funcionalidad permite registrar múltiples implementaciones de la misma interfaz y resolverlas usando una clave específica, sin recurrir a trucos como fábricas manuales o el patrón Strategy implementado a mano. En este post vamos a ver qué son, qué problema resuelven, cómo se registran y resuelven, y un ejemplo práctico de uso real. ¿Qué problema resuelven? Antes de .NET 8, si tenías varias implementaciones de una misma interfaz (por ejemplo, distintos proveedores de notificaciones: Email, SMS, Push), el contenedor de DI solo te devolvía la última registrada al pedir IServiceProvider.GetService<INotificador>() . Para elegir una implementación específica, la mayoría de los desarrolladores recurríamos a: Registr...

Koalite: Sobre velocidad y coste de desarrollo Koalite: Sobre velocidad y coste de desarrollo blog.koalite.com/2025/12/sobre-velocidad-y-coste-de-desarrollo Al desarrollar software, y más cuando se trata de un producto maduro, es habitual que surja la sensación de que «antes sacábamos cambios rápido y ahora todo va más lento» y, por tanto, se proponga «contratar más gente para volver a ir rápido». Desde fuera puede parecer que el equipo simplemente se ha vuelto menos eficiente. Desde dentro, normalmente lo que está pasando es bastante más mecánico y predecible: A medida que el software crece, su coste mínimo de mantenimiento y evolución sube. A medida que crece el equipo, la capacidad productiva media por persona decrece. Esto, que puede parecer algo exclusivo del mundo del desarrollo, se hace patente en muchas otras áreas. Por ejemplo, en el nivel de vida de una persona. La complejidad tiene un coste Cuando un software es pequeño, t...

Shallow Focus Flags — Stop Naming Your Variables "Flag" Shallow Focus Flags thatamazingprogrammer.com — Stop Naming Your Variables "Flag": The Art of Boolean Prefixes The Problem You inherit a codebase and find this: public class OrderProcessor { private bool open; private bool flag; private bool done; private bool status; public void Process(bool check) { if (open && flag) { flag = false; status = true; } if (done) { // what happens here? } } } Readable? No. What is open ? Is the store open? Should the file open? What is flag ? That's a variable screaming "I'll fix this later." And is done a question ("is it done?") or a command ("mark it done")? Boolean names are ambiguous land mines. They look innocent until you have to figure out what they mean during a 3 AM outage. ...

Cuando me topé por primera vez con el término NNPP (siglas de "Net Negative Producing Programmer") no puedo negar que me hizo cierta gracia. Cuanto menos, resultaba curioso pensar que podían existir desarrolladores cuyo saldo en las aportaciones a un proyecto resultara negativo, o lo que es lo mismo, que el valor de su producción fuera superado por el coste de los errores y defectos que introducían en las aplicaciones. Y con el término "desarrolladores" no me refiero exclusivamente a programadores; el concepto es válido para analistas, arquitectos, testers, o cualquier otro rol relacionado con la construcción de software. Aunque seguro que todos hemos trabajado con profesionales que consideramos desastrosos poco habilidosos en la ejecución de sus tareas, probablemente no hayamos reflexionado lo suficiente sobre el impacto que tiene esto en un proyecto, y el coste final que clientes, nuestra empresa, o nosotros mismos ...

En estos días me he puesto a pensar ¿Que es lo que hace realmente que un equipo sea eficiente?, después de pensar y leer unos artículos bastantes buenos, estuve de acuerdo con todos los puntos mencionados en estos artículos, uno de ellos menciona 9 pasos para formar equipos de alto desempeño . A continuación enumerare los 9 pasos. 1. Define un objetivo. Me parece el mas importante, tener un objetivo en común, no cuenta el obtener el salario al fin de mes. 2. Busca a las personas correctas. Rodéate de las personas correctas, la diversidad crea un conocimiento colectivo :). 3. Crea una estructura de trabajo. Se necesita de una estructura, reglas, roles, objetivos, estándares, etc.. 4. Comunica con claridad. Uno de los mas importantes y que muchos equipos fallan, comunicación “con claridad”, ser claro en todo, nunca esperar que los demás “infieran”, eso facilitara el trabajo y ahor...

Don Larry Wall , el creador de Perl, escribió en Programming Perl estas 3 cualidades que todo programador debe de tener. Pereza La calidad que te hace ir por un gran esfuerzo para a la larga reducir el gasto de energía. Te hace escribir programas que ahorren trabajo y que otras personas encuentran útil, y documentar lo que escribes para que así no tengas que responder tantas preguntas sobre ello. Por lo tanto, esta es la primera gran virtud de un programador. Impaciencia La ira que sientes cuando la computadora esta siendo perezosa. Esto hace que escribas programas que no solamente reaccionen a tus necesidades, sino que hasta las anticipen. O por lo menos pretendan hacerlo. Por lo tanto, esta es la segunda gran virtud de un programador. Arrogancia Orgullo excesivo, el tipo de cosa por el cual Zeus te castiga. Esta calidad te hace escribir (y mantener) programas sobre los cuales otras personas no quieran hablar mal. Por lo tanto, es...

Cuando hablo con un cliente sobre su sistema de información, le suelo pedir que piense cómo puede ayudarle un sistema de información a: reducir teléfono : moviendo toda la información por la que le llaman a Internet, en forma de página pública o extranet. reducir mostrador : lo mismo que el anterior. Y, además, muchas veces las personas vienen a un mostrador a por cosas que podría enviárseles por correo electrónico o que podrían descarse de las extranets de cliente o proveedor. reducir papel : en muchas empresas todavía se comunican cosas entre empleados imprimiendo un papel y pasándoselo físicamente. Y mucha gente imprime un papel para tenerlo a mano mientras pica datos en un formulario. Un buen sistema de información tiene que tener la ambición de reducir el papel a cero, aunque haya casos en los que sea imposible. automatizar tareas repetitivas : los ordenadores son tontos, pero son ...

“No te preocupes si no funciona bien. Si todo lo hiciera te quedarías sin trabajo “ ~ La ley de Mosher para la Ingeniería de Software

Una rápida: TechRepublic destaca las 10 habilidades que los desarrolladores necesitarán estos próximos cinco años . Como siempre, mejor leer el original, pero en cápsulas: Uno de los tres grandes: Java, .NET o PHP RIAs : Flash, pero también Flex, Air, probablemente JavaFX o Silverlight y, con un poco de suerte, HTML5 Desarrollo web: HTML, CSS, JavaScript Servicios web: REST o SOAP, JSON o XML… Habilidades ‘blandas’: hay que saber ‘cómo moverse’ dentro de la entrada empresa (perdón) Un lenguaje de programación dinámico y/o funcional: Ruby, Python, F#, Groovy… Metodologías ágiles de desarrollo Conocimiento del dominio: más vale saber del campo en el que estás trabajando “Higiene de desarrollo”: ‘b...

Study this small story, Hope that helps make a Good change . Professor began his class by holding up a glass with some water in it. He held it up for all to see & asked the students "How much do you think this glass weighs?" '50gms!' .... '100gms!' .....'125gms' ...the students answered. "I really don't know unless I weigh it," said the professor, "but, my question is: What would happen if I held it up like this for a few minutes?" 'Nothing' …..the students said. 'Ok what would happen if I held it up like this for an hour?' the professor asked. 'Your arm would begin to ache' said one of the student "You're right, now what would happen if I held it for a day?" "Your arm could go numb, you might have severe muscle stress & paralysis & have to go to hospital for sure!" ….. ventured another student & all the students laug...

En nuestra larga trayectoria, en unas cuantas ocasiones, nos hemos visto en la situación de que un cliente nuevo nos llama para rescatar un proyecto con caracter de urgencia. El patrón suele ser el mismo: * Un cliente con el que no has trabajado antes. * Un proyecto empezado, o que debía haberse empezado hace bastante tiempo, y cuyo plazo está a punto de expirar, o incluso ha expirado ya. * Suele suceder que, al menos una empresa o “profesional”, les ha dejado ya en la estacada y recurren a ti en última instancia. * Lo habitual es que este cliente haya movido cielo y tierra buscando a un salvador, y que alguien, al que posiblemente le has salvado algún proyecto en alguna ocasión, te haya recomendado. Lo normal es que abordes con ilusión este tipo de proyectos. Si lo resuelves con solvencia, habrás ganado un nuevo cliente, el cuál además quedará en gratitud contigo. También presentará un reto profesional, lo cual resulta un incentivo y además pone a prueba tus capacidade...

Las tres responsabilidades (mejor que roles) para Scrum. El grado de funcionamiento de Scrum en la organización depende directamente de estas tres condiciones: Características del entorno (organización y proyecto) adecuadas para desarrollo ágil. Conocimiento de la metodología de trabajo en todas las personas de la organización y las implicadas del cliente. Asignación de responsabilidades: Del producto. Del desarrollo. Del funcionamiento de Scrum. Responsabilidad del producto: El propietario del productoEn el proyecto hay una persona, y sólo una, conocedora del entorno de negocio del cliente y de la visión del producto. Representa a todos los interesados en el producto final y es el responsable del Product Backlog.Se le suele denominar "propietario del producto" y es el responsable de obtener el resultado de mayor valor posible para los usuarios o clientes.Es responsable de la financiación necesaria para el proyecto, de decidir cómo debe ser el resultado final, del lanzamiento...

¿Como editar cualquier página? Haciéndolo desde el navegador, basta con solo teclea en tu navegador javascript:document.body.contentEditable='true'; document.designMode='on'; void 0 Algo curioso que nos permite jugar con cualquier página editando su estructura y contenido.

Cuando las estimaciones van mal Ayer encontré un artículo que me dió que pensar y cuyo título reza lo mismo que el mío. El artículo está escrito por Elizabeth Keogh, que en mí opinión no tiene mucha pinta de ser autóctona, lo digo porque yo, al menos, tiendo a pensar que en otros sitios las cosas no se hacen como aquí y todo es maravilloso como te contaban en la facultad, cuando la realidad es que todas las casas cuecen habas. El artículo que al final todos los proyectos tienen un presupuesto ya que las horas de los trabajadores cuestan dinero, así que cuando uno se pasa de horas tiene que mendigar más de ese presupuesto, como si le pidiera a su madre que le aumentara la paga, lo cual es verdaderamente humillante, amén de responder a todas las preguntas incómodas acerca del porqué de ese retraso. Pero, ¿que motivaciones tiene un programador cuando todo ha ido mejor de lo esperado? Pues a decir verdad, ninguna, ya que por parte del jefe de proyecto lo que esperará es que la siguiente v...

Una razón algo más técnica para no escribir métodos largos Hoy en día creo que más o menos todo el mundo tiene claro que escribir métodos muy largos es una mala práctica. Nos lo dicen en la universidad, nos lo dicen en los libros de programación, de ingeniería del software, de patrones o de refactorización. Los paquetes de métricas y de detección estática de errores nos avisan de que nuestros métodos son demasiado largos y el jefe nos echará una buena bronca si ve que hacemos un método de 5.000 líneas. Aún así, cuando uno está programando siempre hay esos momentos en que se siente un poco vago con algún método al que va añadiendo cosas y cosas, porque total, estamos haciendo sólo un boceto, ¿no? El problema es que esos bocetos se convierten en la versión definitiva (doy fe, que tengo un par de métodos grandes por ahí que verguenza me dan) y ahí ha quedado. Pero bueno, funciona, ¿no?. Y no lo va a tocar nadie nunca jamás de los jamases, ¿no?, ¿qué hay de malo entonces?. Pues sí, incluso...

IT: la profesión más estresante (según una encuesta de 33wytv) ¿Qué profesión a nivel mundial es más estresante? . Esto es algo, que tal vez, todos los que estamos enrolados en el mundo IT somos consciente, pero que muchas veces no tenemos tiempo como para sentarse a conversar de este tema. oohhh!!!, gran sorpresa??, pos no!!!, esto ya se sabia, la diferencia es que este artículo habla con encuestas a la mano, y eso tiene mucho valor, confiabilidad y sobre todo, credibilidad...!!!! Esta encuesta revela que los profesionales IT tienen más probabilidad de padecer de tensión nerviosa que cualquier otro profesional, así como, un 97% de personas que trabajan en el área de tecnologías de la información encuentran diariamente en su trabajo una gran tensión diariamente. Alqo que me llamó la atención es que por ejemplo, 4 de 5 IT se sienten estresados antes de entran en el lugar de trabajo, debido al aire quejas, la presión de gerentes y otros aspectos. Según la encuenta, esta es la lista de...

20 Tips para ser un mejor programador 9 Noviembre 2007 - Escrito por: Pablo En Programación Ya llevo varios años programando, a nivel web el lenguaje que mas me gusta o al menos el que mas domino es PHP, voy a intentar dar algunos tips que realmente me han servido mucho durante mi aprendizaje. 1. Estudia, estudia y estudiaEl estudiar nos permite perfeccionarnos, cuanto mas estudiemos mas oportunidades de programar mejor tendremos, no solamente estoy hablando de universidades, ni tampoco de cursos, hoy por hoy gracias a internet existen infinidad de tutoriales y manuales, sin ir mas lejos el sitio oficial de PHP es realmente muy bueno. 2. Busca antes de preguntarEsto es un mal común del que quiere aprender a programar, es mas fácil preguntarle a alguien que sepa, pero realmente no tiene que ser así por varias razones, primero por que es algo de muy de vago, luego que cuando alguien nos da la respuesta fácil no aprendemos nada, lo interesante cuando se nos presenta un problema es buscar...

Postbacks entre páginas diferentes en ASP.Net (Cross page postbacks) Las primeras versiones de la plataforma .Net introdujeron el PostBack como el mecanismo de recarga de una página gracias al cual era posible la persistencia del estado de controles y la interacción con ellos de forma muy sencilla y potente en el lado del servidor, modificando la filosofía de programación de webs que habíamos usado hasta entonces (ASP clásico, CGIs...).Sin embargo, si querías usar los controles de servidor en todo su esplendor te veías obligado a meter tareas completas dentro de una misma página; así, aquellas que presentaban funcionalidades relativamente complejas se convertían en batiburrillos donde se incluían formularios de entrada de datos, código de validaciones, formularios de salida de información, etc. Por ejemplo, podíamos tener en un mismo Webform paneles de introducción de criterios de búsqueda, paneles de información o errores, paneles con un grid para mostrar los resultados e incluso otr...

La ambigüedad es muchas veces la causa principal del fracaso de un proyecto Evaluar de manera imprecisa o equivocadamente el alcance, los objetivos, los plazos y las tareas necesarias de un proyecto es, mucho más comúnmente de lo que se cree, la causa que lleva al mismo al más rotundo fracaso. Comenzar a transitar un proyecto en esas condiciones es como dormir con el enemigo en la misma cama.El motivo por el cual un proyecto se evalúa equivocadamente es, en general, la falta de experiencia de quien lleva a cabo la tarea. No haber transitado proyectos similares, no conocer las herramientas adecuadas para el estudio del mismo, o no dedicarle el tiempo necesario a ese estudio, no son más que tres caras diferentes de la misma inexperiencia.Muchas veces se olvida de que lo que no se piensa antes, difícilmente podrá arreglarse después y entonces se inicia el proyecto salteando esta importantísima etapa previa, pensando que aquel viejo dicho de que "las cargas se acomodan durante la marc...