Miguel Salazar

Am I just a stupid guy, writing more stupid code every day?

The best engineering teams I have worked with are those that promotes a culture of critical thinking; where putting ideas up for discussion, asking for and accepting opinions and getting feedback are fundamental practices.

¿Cómo mejoramos la dinámica con managers? Se habla mucho de cómo ser líder, pero poco de quienes soportan visión y estrategia. Mis opiniones y uno que otro punto aprendido de libros/blogs, sobre como mejorar la dinámica con líderes técnicos y managers: open.substack.com/pub/thebugdev/…

Estuve preguntando con varias personas, desarrolladores y líderes técnicos, y varios asocian el concepto de “managing up” con “técnicas para lidiar con entornos tóxicos o con managers negligentes”. ¿Así se percibe en general en tech?

Here’s the uncomfortable truth: it doesn’t matter that whiteboard coding tests / LC don’t measure a lot of things a dev needs to do day to day. They are the currently known most economical filter to hire *at scale*. I’m talking when you hire 100+ devs per year (or 1,000+) Hiring is done by people who are devs themselves and you want to keep a similar bar between different parts of the org. Yes, tasks that simulate day-to-day work give better signal. But they require far larger investment and it’s problematic when the question leaks. (When you do more than 20-30 interviews with the same question, expect it to leak and be googleable when people search for what your hiring process is). With algorithmic questions it makes no difference if it leaks, given companies have a question bank in the hundreds! A nice side effect for large companies is they self select for people who are willing to put up with BS things: aka spend considerable amount of time to do something mostly pointless (prepare for these algo interviews), just because it’s how things work and what it takes to get the job. Those who refuse to do this would likely not be a fit for these environments where these interviews are not the first or last things that are process you follow… just because. And make no mistake: these places screen for soft skills, teamwork etc. Those are done via recruiter screen, hiring manager interviews, to some extent architecture and bar raiser. The coding / algorithm interview is usually 1 or 2 out of 5-6 interviews. And the coding part is usually the most trivial to pass (for anyone putting in the effort to prep - see the point on putting up with mostly pointless stuff the job asks for) The problem is not that Big Tech uses these hiring processes (it makes perfect sense for them!) It’s when small companies hiring 5-10 ppl per year copy it, without thinking. More on how to build a sensible hiring process without blindly copying this: newsletter.pragmaticengineer.com/p/hiring-softw…

@powerhdeleon Creo es más un tema de costo-beneficio, y evaluar el escenario. A veces les sacamos la vuelta por situaciones donde tener SPs empujan a tener un fuerte acoplamiento en otras capas. Y ya maduro el proyecto se vuelve complejo iterar/refactorizar encima de eso.

Los Stored Procedures no son malos, de hecho, pueden sacarte de situaciones particulares de una manera rápida y pueden ser parte de una Arquitectura. El problema es, que no saben usarlos.

Cada idea, cada línea, cada bloque requiere una prueba. Esta prueba es buscar claridad y que haga sentido. Entonces depuras la primer idea, luego la segunda y así, vamos iterando hasta encontrar la mejor forma de expresar algo.

Parte de hacer una exploración, hacer garabatos en papel sobre como se conecta una idea con otra, dibujar una especie de esqueleto o mapa de ideas... luego entras al detalle de cada idea o pensamiento, pruebas una forma de desenvolver, pruebas otra y así...

Siempre he sentido que escribir, el proceso de escritura, comparte muchas similitudes con la programación...

Es más difícil leer código que escribir código. Pagar deuda técnica implica ambas, pero mayormente la primera.

Vengo del futuro, ya tengo más de un año usando warp. Agregaron la opción para tener el prompt en la parte superior.

Estaba probando @warpdotdev y está bastante cool. Tiene buenos features. Peeero, chiales, no puedo vivir con el prompt hasta hasta abajo y no hay opción para ponerlo arribita 😪 Seguiré fiel a mi hermosa iterm2

Sonará trillado o hasta cliché pero a mi me sigue sorprendiendo… Leemos un libro y, aunque sabemos que es de valor, no tiene un gran impacto. Pasan los años, lo volvemos a leer, y se siente bien natural como todo encaja y hace sentido. No es libro, somos nosotros cambiando

@_axtone Mi playlist, claro que sí open.spotify.com/playlist/3Z8j2…

Lo bueno de Threads, es que me acordé que tenía Twitter; y pos aquí andamos.

A veces*

Yo nada más hice mi cuenta en Threads para calmar mi FOMO. Si ya ni tuiteo, menos threadearé.

En el full stack

🙌🏻

I lean very heavily towards YAGNI and readable code with minimal abstractions until needed. I appreciate that every situation is different, but like anything it's hard to appreciate the benefits when the "scale" problem isn't evident.

I see the role of an Architect as twofold. They teach the teams how to do architecture, and they work with the teams to guarantee architectural coherence. They don't design much, but rather help the teams create great designs.