Profile picture
Fran @nflamel
, 328 tweets, 42 min read Read on Twitter
Seguro que esto no llega a ningún sitio, pero...

Un like - > Una cosa que he aprendido después de más de 10 años trabajando como programador.
1. Ninguna empresa merece que sacrifiques tu salud mental ni tu estabilidad personal. Tampoco que trabajes gratis ni a cambio de promesas.
2. No existe ninguna herramienta perfecta, ni ningún lenguaje definitivo. Siempre se llega a soluciones de compromiso y eso hace que haya unas cosas mejor resueltas que otras en cada herramienta y en cada lenguaje.
3. Enlazando con lo anterior en general es buena práctica asumir que todo está roto. Siempre, sin excepciones. Por lo tanto es conveniente estar preparado para ello: tener una forma de detectar dónde están los errores y por qué aparecen es clave junto con tener un plan B.
4. A veces es también conveniente tener un plan C. Si tu plan B es una solución alternativa no descartes que necesites un plan C: Deshacer el cambio por completo, reevaluar el problema, la solución y completarlo una vez esté solucionado lo que no sabías al principio.
5. A raiz de esto:

Siempre que te digan que te van a dar más responsabilidad y que luego te prometan que más adelante se verá cómo te suben el sueldo es mentira. Si no te suben el sueldo después de un ascenso es que no tienen intención de hacerlo.
6. Quien se inventó esa milonga del "código autodocumentado" se equivocó. Escribir documentación tiene mucho más valor que explicar el código y lo más importante que puede explicar es por qué se programó algo y el contexto en el que ese algo se hizo.
7. Las meritocracias NO EXISTEN. Cualquier empresa que te intente vender que tienen una estructura plana y no necesitan jefes porque son una meritocracia en realidad vive en un infierno de luchas de poder interminables en las que todo se hace por los cojones de alguien.
8. Despreciar el uso de herramientas de calidad (como los tests) hace que el código a la larga sea cada vez más difícil de cambiar y crea nichos de información dentro de los equipos.
9. Enlazando con lo anterior, si el código que acabas de escribir no es fácil de cambiar por otra persona que no seas tú, entonces no está terminado y no debería salir a producción.
10. Pensar que existen tecnologías "menores" y despreciarlas es de imbécil. Recordad, TODO ESTÁ ROTO. Sí, ese lenguaje tan molón que usas y por el que te sientes una superestrella y miras a la peña por encima del hombro también.
11. Aprender a usar un debugger te cambia la vida, pero el "puts" debugging (escribir trazas a lo largo del código) puede ser trementamente potente si sabes lo que haces. e.g. tenderlovemaking.com/2016/02/05/i-a…
12. Invertir tiempo en encontrar un editor con el que sentirse a gusto es muy importante y hace el trabajo más fácil.
13. Programar es solo una parte del trabajo. Aprender a comunicarse bien y a ejercer de mentor/a (si tienes un perfil más senior) es una parte clave de lo que hacemos. Sentarse a solas en un rincón a programar aislado en plan "yo trabajo solo" es una mala práctica.
14. Si te lo puedes permitir, invierte en un buen teclado. A mi me encantan los mecánicos, pero con que sea ergonómico suele ser suficiente para evitar problemas a largo plazo en las manos.
15. Si te duelen las manos, las muñecas, etc después de un buen rato trabajando ve al médico cuanto antes. Algunas lesiones relacionadas con este trabajo se pueden cronificar y es una mierda.
16. La falta de diversidad es un problema grave de esta industrian, no solo por una cuestión de justicia social, sino porque además silenciamos de forma sistemática las voces de mucha gente que tienen aportaciones importantísimas que hacer.
17. XKCD ha dibujado algunos de los mejores chistes sobre el mundillo que se han escrito jamás... y este en concreto es maravilloso xkcd.com/378/
18. Una parte bastante grande de empresas ignoran por completo todo lo relacionado con la seguridad. Si no les han robado ya los datos es simple cuestión de suerte.
19. Tener cerveza en la oficina no es un perk deseable ni una ventaja. Es una barbaridad y ayuda a perpetuar algunas mierdas de las que tendríamos que intentar deshacernos.
20. Revisar tu código con la misma atención al detalle que revisas el código de el resto del equipo ayuda un montón a detectar problemas y a darte cuenta de cosas que no has explicado bien.
21. Tener un buen equipo de QA/Calidad/Testers es clave. Que además tengan la última palabra para decidir cuando una feature no cumple los estándares mínimos para salir a producción es una bendición.
22. Tener un buen equipo de producto que entienda como funciona el desarrollo de software y que sea capaz de calcular el alcance mínimo de una funcionalidad para que sea significativa y tecnicamente factible es clave también.
23. Planning is guessing m.signalvnoise.com/planning-is-gu…

Y lo puedes aplicar tanto a la empresa en general (y tu plan de negocio) como a esa feature nueva tan chula.
24. No todo se puede decidir de forma conjunta y democrática y además en una empresa no tiene ningún sentido. En una empresa alguien tiene que tener la responsabilidad de decidir.
26. Usar una tecnología nueva que no conoces en producción sin conocerla lo suficiente suele ser una mala idea. Recuerda que TODO ESTA ROTO.
27. Esto me recuerda que merece la pena tener algunas herramientas preparadas y a mano cuando las necesitas. Yo lo tengo aquí github.com/franciscoj/dot… y está basado en los de @jhbabon
28. Los procesos internos son importantes, pero un arma de doble filo. Es difícil mantener el equilibro entre burocracia y eficiencia, pero definitivamente ignorar por completo esos procesos no es la solución y crea un caos continuo.
29. Todo es más fácil si aprendemos a decir "No lo sé"
30. También es todo mucho más fácil si aprendemos a decir "Vaya, pues llevas razón y yo no".
31. No me acuerdo a quien se lo leí, pero el software bien hecho es software hecho.
32. Si optimizas las cosas antes de medir y de necesitarlo te vas a equivocar casi seguro (softwareengineering.stackexchange.com/questions/8008…)
33. Merece mucho la pena leer a @sandimetz. Sus libros son muy buenos y enseñan mucho sobre como escribir mejor software. En concreto sandimetz.com/99bottles me parece una obra maestra.
35. JavaScript está rotísimo en muchas cosas.
36. Sin embargo, aunque esté rotísimo el trabajo que se hace para mejorarlo de forma continue me parece ENORME y merece mucho la pena echarle un ojo a como funciona el TC39 github.com/tc39 porque merece un aplauso del mundo entero.
37. Además de esto, mucha de la tecnología más puntera que se escribe ahora para muchas cosas se escribe en JS, mis dieces a este lenguaje.
38. Esto es bastante importante. Equipos pequeños mejor que grandes
39. code formatters >> linters >> far west sintastico
40. tiene razón, de hecho lo poco que he trabajado para la admin publica (en consultoría) la impresión que me ha dado es que ha sido aún peor que algunas empresas privadas.
41. El código no es tu bebé. Tú lo vas a escribir, pero no tienes por qué mantenerlo tú y lo único seguro es que se va a cambiar. Por ti o por otra persona, pero se va a cambiar.
42. Al hilo de lo anterior... mucho de lo que escribimos es completamente efímero y va a desaparecer al cabo de un tiempo (las empresas cierran y los proyectos cambian) aprender a no tomarselo a pecho es una buena idea.
43. La diferenciación backend/frontend a veces no existe. Si no eres fullstack es bastante buena idea aprender un poco sobre otras partes del stack y tomarte en serio el feedback que te dan miembros del equipo ajenos a tu stack.
44. Cuando una tarea se repita y requiera tiempo, intenta automatizarla.
45. Tener criterios más o menos predefinidos sobre cómo y cuándo automatizar cosas, ayuda bastante y ahorra tiempo y dinero.
46. Las automatizaciones que hagas: TAMBIEN VAN A ESTAR ROTAS.
47. Aunque los perfiles fullstack están muy de moda, hay cosas que solo un experto es capaz de hacer.
48. La infraestructura es una de esas cosas en las que vas a querer a un experto trabajando en el tema. Llámalo devops si quieres, pero que sea una persona experta en infraestructura.
49. Existe cierto bias inherente al ser humano que también te afecta al tomar decisiones técnicas, ser consciente de él puede ayudarte a evitarlo. Esta charla lo ilustra muy bien (en inglés) destroyallsoftware.com/talks/ideology
50. El equipo que la da soporte al producto que desarrollas es posiblemente el que tiene el feedback más valioso de toda la empresa y además con toda seguridad el que aguanta más mierda para que no te llege a ti. Se una buena persona y ayúdalos en todo lo que puedas.
51. No merece la pena aguantar a gilipollas y malas personas que enrarecen el ambiente y violentan a los demás solo por que sean buenos programando.
52. Tus derechos como trabajador son increiblemente valiosos. Infórmate sobre ellos y si encuentras algún sindicato que creas que te repersenta afiliate y ayúdalos. Una empresa no se va a preocupar por estas cosas.
53. OPINION: A mi me gustan mucho @Informatica_CGT pero soy un perezoso y aún no me he afiliado 😅
54. DRY no es aplicable siempre. A veces es necesario que haya cosas que se repiten durante un tiempo hasta que se entiende el motivo de esa repetición y se sabe si hay que solucionarlo o no (y cómo).
55. DRY aplicado ciegamente puede convertir el código en un infierno inmantenible.
56. Sí, DRY tampoco es un silver bullet y sí, también está roto.
57. Merece la pena leer algunas cosas clásicas sobre desarrollo e ingeniería de software e incluso leer un poco sobre la historia de nuestra profesión.
58. Las mujeres fueron en muchos casos pioneras en el desarrollo de software hasta que se convirtió en una disciplina famosa. Yo creo firmemente que la actitud tóxica que los hombre hemos tenido históricamente ha contribuído de forma negativa para echarlas del sector.
59. Ayudar a otra persona a aprender algo nuevo es una de las experiencias más gratificantes que existen. Esta charla de Avdi Grimm en ese contexto es MARAVILLOSA (Habla sobre metaprogramación, divertirse programando y sobre esa maravilla que es enseñar)
60. Aunque yo todo esto lo esté contando como hechos contrastados, la mayoría son opiniones. Pero mi experiencia me dice a que muchas de estas cosas ayudan muchísimo.
61. Descansar, alimentarse bien y tener una vida fuera del trabajo es importante. Si tu trabajo no te deja hacer eso es bastante posible que necesites la ayuda de un sindicato de clase que te asesore sobre tus derechos laborales.
62. No tener "side projects" de programación fuera del trabajo no te convierte en un bicho raro ni hace que tu trabajo sea menos valioso. No está bien que nos intenten obligar a que siempre aprendamos en nuestro tiempo libre.
63. Que una empresa te permita dedicar parte de tu tiempo de trabajo a aprender e investigar es muy imporante y algo que no me parece un perk en absoluto si no una obligación (de la empresa)
64. Ten siempre papel y lapiz a mano, aunque sea para hacer un dibujo/esquema de la solución que tienes en mente.
65. Esta cosa rubberduckdebugging.com que parece estúpida y ridícula funciona. Y además funciona muy bien.
66. El trabajo en remoto es guay pero no vale para todo el mundo.
67. Trabajando en remoto es muy importante saber comunicarse bien y aprender a dar y recibir feedback sin tomárselo de forma personal.
68. Si te agobias, te falta el aire, te cuesta pensar y tienes nauseas constantemente a lo mejor sufres un problema de ansiedad, ir al médico es lo mejor que puedes hacer al respecto como primer paso.
69. Las metodologías ágiles son una herramienta y como cualquier herramienta TAMBIEN ESTAN ROTAS. Además es importante entender que son una herramienta para un fin y no un fin en si mismas.
70. No siempre es una buena idea añadir una dependencia al tu proyecto. Si esa libreria/gema/paquete solo soluciona un 80% de tu problema y vas a necesitar malabarismos para solucionar el 20% restante y acomodarlo a la libreria/gema/paquete... a lo mejor no deberías usarlo.
71. La arquitectura de Von Neumann en.wikipedia.org/wiki/Von_Neuma… es algo bastante interesante de estudiar y aprender y ayuda a comprender un poquito como funcionan los ordenadores modernos.
72. Tocar la BBDD de producción a mano no es buena idea.
73. Por más experiencia que tengas vas a cometer errores y vas a colar bugs en producción. Es importante encontrar un equilibrio personal en cúando estás lo suficientemente código con la calidad de lo que haces para que vaya a producción.
74. Si entras en un proceso con una empresa y lo que te encuentras no te gusta, no te sientas en la obligación de terminar el proceso. Dilo claramente: No me llama la atención lo que ofrecéis, no me motiva el proyecto, el sueldo es bajo...
75. Hacer entrevistas es un entrenamiento y nunca sabes muy bien de antemano como van a salir. Pero si hay cosas que ayudan:
76. Investigar la empresa en glassdoor.com y similares. Si no hay feedback puedes intentar buscar a algún ex-empleado o noticias sobre la empresa en prensa.
77. Ver si puedes averiguar que stack usan, cómo lo gestionan y si se ajusta a lo que sabes hacer o lo que quieres aprender.
78. Pregunta sobre los procesos internos en las entrevistas
79. Pregunta también sobre quiénn decide las features que se incluyen y en qué trabaja cada persona.
80. Si no sacan el tema del salario, saca el tema. Tenemos que dejar de considerar hablar sobre el salario un tema tabú.
81. Cuando los empleados de una empresa saben lo que cobran los demás, los salarios suelen ser más estables y también suele haber menos salarios bajos.
82. Que los salarios sean conocidos hace también que la empresa tenga menos capacidad de negociarlos a la baja, lo cual es 👍
83. A veces los recruiters son bastante desconsiderados y entran a saco. No te sientas en la obligación de responderles si no cumplen con tus estándares minimos de calidad humana.
84. Yo prefiero sin lugar a duda a las empresas que tienen procesos internos para encargarse de reclutar ellos mismos y no delegan en recruiters. Me hace pensar que se preocupan de contratar a quien necesitan y no en plan "necesito 1kg y 1/4 de dev"
85. Esto, en general python.org/dev/peps/pep-0…
86. Prepararse de antemano para una demanda inesperada es casi imposible (que es básicamente lo que me ha pasado a mi con este hilo).
87. La única vez en mi vida que he estado en un juzgado ha sido por un problema laboral. No conozco prácticamente a nadie que no tenga problemas parecidos o no los haya tenido alguna vez en su vida.
88. Trabajar 8 horas al día 5 días a la semana es un máximo. Trabajar más se termina convirtiendo en un problema de salud (entre otras muchas cosas)
89. Me gustaría hacer hincapié en la importancia de esto

Sin embargo es algo sobre lo que no me atrevo a hablar mucho porque se que es delicado (y porque sé muy poco). Este es un gran recurso al respecto github.com/folkswhocode/a…
90. Mejorar el inglés es una buena inversión
91. No está bien asumir que todo el mubdo ha tenido el mismo background o el motivo por el que no saben algo.
92. Aprende a explicar cosas técnicas a gente no técnica de forma que se enteren sin los detalles técnicos pero entiendan lo demás es importante over 9000
93. Esta me la chiva @jhbabon (que es muy majo)

“En programación web vas a trabajar en un sistema distribuido, que va mucho más allá de lo que hagas en tu máquina. Aprende un poco sobre concurrencia y race conditions”.
94. Si haces uso de CI es importante no obsesionarse con que todo vaya al CI.
95. Un CI lento es un dolor y debería ser una bandera roja.
96. Si vas a depurar unos tests lentos, lo mejor es usar herramientas de profiling para averiguar dónde está el problema.
97. Si usas Ruby on Rails el problema es casi seguro que tus tests dependen demasiado de la base de datos.
98. La prepotencia con los miembros no técnicos del equipo es una epidemia en el sector y somos unos capullos por consentirlo.
99. Volviendo al CI... Si usas CD asegúrate de que tu proceso de deploy no depende de un servicio que no controlas y de que puedes desplegar a mano sin ese servicio. (si, tu servicio de CD también está roto)
100. Me he ido de más empresas por tener malos managers que eran inaguantables y unos malos gestores que por ganar más dinero... Y me consta que no soy el único.
101. Una empresa que no confía en el trabajo en remoto es bastante posible que no confíe tampoco en sus trabajadores.
102. Acceder al estado de una instancia de tu clase de forma directa es mala idea siempre.
103. Linux está roto.
104. Mac está todavía más roto.
105. Windows no lo he usado para programar así que no puedo opinar.
106. Monolito vs. Microservicios es un falso dilema en la mayoría de los casos (si, aquí tb se aplica lo del bias)
107. Si te vas a integrar con una API de terceros más te vale prepararte para que todo esté AÚN MÁS ROTO.
108. Ser autónomo no es tan guay como parece.
109. Si eres autónomo y te lo puedes permitir, busca a un asesor que te resuelva el papeleo porque esto tb está roto y los errores te pueden costar mucha pasta.
110. Si decides emprender con otra gente tenlo siempre todo por escrito y ten contratos firmados de cada acuerdo al que lleguéis.
111. Hay gente que te va a intentar engañar y aprovecharse de tu trabajo.
112. Montar una empresa es muy difícil y las posibilidades de que salga mal son astronómicas.
113. Emprender si no tienes dinero de antemano y dependes solo de tu trabajo es muy difícil o casi imposible.
114. Cuando dos empresas hablan de un "merger or equals" suele ser porque no es para nada entre iguales. Una se queda todo y despiden a los trabajadores de la otra.
115. Los bonos variables sobre el sueldo y el equity no me parecen algo para nada rentable para los empleados.
116. Dia vende estas toallitas que no están mal tener a mano para limpiar tu mesa si lo necesitas... Aunque huelen un poco fuerte.
117. En respuesta a

Si es mecánico desmonta las teclas y limpialas con lo que mejor te venga (las toallitas valen, pero mejor agua y jabón).

De membrana ya es más difícil... Pero tb se puede desmontar.
118. Guardar el teclado en un cajón o en una funda hace que se llene menos de polvo y lo mantiene limpio más tiempo.
119. Una oficina limpia y silenciosa es clave para trabajar bien.
120. Un porcentaje altísimo de las veces que me he sentido atacado en un chat o en una review escrita ha sido un malentendido y se han solucionado preguntando de viva voz a la otra persona si es que no les había entendido.
121. A veces hay gente que simplemente tiene mala intención.
122. Nunca he tenido clara la diferencia entre CTO y VP de ingeniería.
123. Somos un sector que a veces se toma las críticas muy a pecho.
124. En Elixir, IO.inspect hace muchas cosas. Para empezar devuelve lo que recibe como parámetro por lo que encaja dentro de un piping y además tiene muchas opciones. Es buena opción leer la documentación.
125. Si un lenguaje/herramienta/librería tiene buena documentación es importante leerla a fondo.
126. Los proyectos de software libre hacen un trabajo excepcional y en muchos casos las empresas que los usan no hacen casi nada por devolver el valor que obtienen gracias a ellos.
127. Es mentira que rails no escale.
128. Es imposible escalar un framework porque lo que tienes que escalar es tu aplicación.
129. Usar un microservicio para solucionar algún problema con un stack más apropiado puede ser una buena idea, pero hay tanto tradeoff y se añada tanta complejidad que hay que tener mucho cuidado.
130. El framework que usas no es tu aplicación.
131. No hay muchos casos en los que merezca la pena no usar un framework. Si decides no hacerlo asegúrate de que no es un capricho.
132. Nunca, bajo ningún concepto, dejes una instalación de WordPress abandonada en tu infraestructura.
133. Si usas un framework es conveniente aislarse ligeramente de él. Ayuda bastante en cosas como los updates.
134. Jugar al ping-pong es muy difícil.
135. Merece la pena leer a gente que haga cosas completamente distintas a ti en lenguajes que no tengan nada que ver.
136. Aprender a mecanografiar ayuda a evitar problemas en las manos y muñecas.
137. Eso que estás intentando hacer ya lo ha intentado hacer alguien antes y está en github o similar.
138. Sí, lo que hizo esa persona va estar roto por algún sitio.
139. Lo que hagas tú también va a estar roto.
140. Reinventar la rueda es una pérdida de tiempo y un desperdicio de energía la mayoría de las veces.
141. El concepto de deuda técnica es una forma maravillosa de explicar como funciona el desarrollo de software.
142. Un refactor no es algo que hagas un día porque sí para dejar el código más guay. Eso es un rewrite y es bastante mala idea.
143. Para que un refactor sea tal tiene que tener un objetivo, que en general suele ser hacer el próximo cambio que vas a hacer más fácil.
144. Confundir refactor con rewrite me ha llevado a escribir más de una mierda a lo largo de mi carrera. Sorry a quienes lo estén manteniendo 😅
145. Los test rápidos son la mejor cosa del mundo.
146. Un objetivo test coverage demasiado alto no merece la pena. Acabas añadiendo tests que no necesitas.
147. Las cosas automáticas son guays, pero como en el caso del CI y el CD que decía antes, hace falta que también se puedan seguir haciendo a mano.
148. Su usas github atyda bastante tener una plantilla para las pull requests.
149. "obligar" en la plantilla a poner un gif tonto ayuda a que la peña se ría y se relaje un ratito.
150. A veces uno tiene más cosas de decir de las que piensa y es mejor hacerse un blog que venir a dar la turra en Twitter.
151. Aprender a decir que no y poner límites a las cosas es difícil. Pero también es importante.
152. Nunca he visto una estimación que no se haya desviado.
153. Ya lo he dicho antes sobre sus libros, pero las charlas de Metz son magistrales tb sandimetz.com/speaking
154. RTFM es una forma horrorosa de decirlo. Pero si hay un manual deberías leerlo.
155. Durante una época trabaje como profe de programación y aprendí MUCHÍSIMO.
156. Que enseñes un poco a programar a alguien que se pelea con la asignatura en la facultad y se acaben ganando la vida haciendo eso da calrcito en el corazón.
157. Una de las cosas más importantes al hacer code review es no ser un gilipollas arrogante.
158. Pido perdón por la veces que yo lo he sido :( pero de eso también se aprende que se puede dejar de ser un gilipollas arrogante ^^
159. Cuando una API no hace lo que esperas, lo mejor suele ser releer la documentación.
160. Hacer una API rest y no documentarla en condiciones es malvado.
161. Hacer uso de la composición por encima de la herencia es una muy buena idea y después de usar programación funcional un poco estoy aún más convencido de esto.
162. Aprender un paradigma nuevo no es fácil, pero aprendes el doble porque además te hace reevaluar cosas que ya sabías.
163. Git es jodidamente complicado pero muy, muy útil.
164. Git sería mucho más útil si no fuera tan jodidamente complicado.
165. Git rebase sólo en ramas para una persona. Para todo lo demás, git merge, por favor.
166. Estos alias de git, junto tener un alias g=git en mi shell me ahorran mucho trabajo github.com/franciscoj/dot…
167. Una vez tuve un jefe que se puso a cambiar la cuenta de una usuaria en producción pensando que era un staging, me pasé horas revisando logs para dejarlo todo como estaba.
168. Las expresiones regulares son una herramienta potentisima. Posiblemente también estén rotas pero desgraciadamente nunca he aprendido tanto sobre ellas como para encontrarme con problemas.
169. Si puedes poner límites a las cosas es mucho mejor. Si dejas una API abierta en la que, por ejemplo, alguien puede comprar 10 millones de tickets, a lo mejor te tiran el servidor. (si, me ha pasado)
170. Los problemas de concurrencia y las race condition alcanzan un nivel máximo de horror cuando hay un pago de por medio.
171. Programar cosas relacionadas con pagos tiene mil problemas asociados.
172. Una vez introduje un bug que cobró 27 veces una cosa a la misma persona. Aprendí que usar bien las transacciones de BBDD es importante.
173. También aprendi que si hay una API de un tercero involucrada, puedes joder la BBDD si tu transacción espera la repuesta de la API.
174. En general, en una aplicación web, cuantas menos cosas haga tu controlador, mejor.
175. Cualquier proceso que requiera más de milisegundos debería ir fuera del controlador y manejarse de forma asíncrona. Sobre todo si hay APIs por ahí metidas. (si, esto tb está roto)
176. 10 años dan para bastante, creo... Pero todo esto lo he aprendido de gente que ha tenido la paciencia de enseñarme.
177. También de gente que ha ido a joder.
178. El estrés es una mierda horrorosa que se come tu vida y no dejéis que nunca jamás nadie os intente vender lo contrario.
179. Una vez me encargaron un pequeño proyecto que no me pagaron. Era muy inexperto y no tenía las tablas para exigir lo que me correspondia. Aprendí que siempre hay que exigir al menos una parte del pago por adelantado.
180. Si un recruiter o una empresa en concreto se ponen pesados, suele funcionar decirlo de forma clara "oye, es el noveno mail que me mandáis este año, no estoy interesado y agradecería que pararais"
181. Una vez me contactaron para un puesto relacionado con el machine learning y aprendí que algunos recruiters no saben ni lo que buscan.
182. Si compartes el espacio con una persona junior sé una buena persona, déjale ver que puede acudir a ti en busca de ayuda y muestra comprensión a la hora de ayudar. Todo el mundo pasa por eso.
183. En momentos en los que el estrés y la ansiedad me estaban machacando, un bullet journal chisquero me ha sacado del apuro.
184. En momentos en los que no me consigo concentrar, la técnica pomodoro me ayuda a concentrarme de forma puntual.
185. El zero inbox es demasiado exigente y no sé si merece la pena. Pero lo hago desde hace tiempo.
186. Si un test es muy difícil de hacer... A lo mejor no merece la pena hacerlo. O a lo mejor es un indicativo de que el código acumula demasiada complejidad y partirlo en partes pequeñas sería beneficioso.
187. Si no sabes si hacer un refactor ahora o luego suele significar que no lo necesitas y que lo puedes hacer luego. Es mejor hacerlo luego.
188. Vim y su mecanismo de edición modal son muy interesantes. Si no te gusta Vim, pero te gusta la edición modal, prueba a buscar un plugin de Vim para tu ide/editor, seguro que hay.
189. Emacs también mola, pero sus combinaciones de teclado me resultan dolorosas (literalmente)
190. Que una librería no tenga muchos cambios recientes no significa que esté anticuada. Puede que haya alcanzado un estado estable en el que resuelve el problema que quería resolver.
191. Casi todos los casos que conozco en los que alguien ha decidido crear una librería para ponerla en github y luego usarla, han sido un fracaso de una u otra forma.
192. Al crear una API nueva para una librería, la API no suele ser estable. Si la creas de forma externa para usarla de forma interna vas a crear una complejidad extra que te va a tocar sufrir.
193. Esto también es un caso de optimization prematura.
194. Si una librería dentro de tu base de código es estable, puede tener sentido extraerla para usarla en más sitios o por el simple hecho de compartir. E.g. github.com/basecamp/name_…
195. Otro buen ejemplo es este: github.com/departurerb/de… que empezó como una librería interna y creció hasta poder extraerse.
196. Separarnos de nuestro ORM en ese momento nos facilitó actualizar la versión de rails por separado en esta librería y en la app que desarrollabamos. Además tuvimos ayuda de la comunidad.
197. Kudos infinitos a @prez_pau por el currazo y porque es un maestro del OOP. Me enseñó un montón.
198. Un buen ORM te permite desacoplarte de él, pero en mi experiencia estamos demasiado mal acostumbrados y no lo hacemos.
199. Ecto, un wrapper para bases de datos para Elixir, tiene cosas parecidas a ActiveRecord de Rails, pero encuentra mejor ese equilibrio entre funcionalidad y libertad de movimiento.
200. A veces pienso que esto se debe porque Ecto está más pensado con la composición en mente y AR usa la herencia para casi todo.
201. La programación funcional no me parece una buena introducción a la programación para nadie.
202. Ruby o Javascript me parecen los mejores lenguajes que conozco para iniciar a gente en el mundillo.
203. Estoy mirando Typescript en mis ratos libres y me está gustando. Lo cual me fastidia porque me había hecho a la idea de que no me iba a gustar.
204. Crees que hacer front es difícil? Imagina hacer front... PARA UNA TELE. Es definitivamente uno de los ecosistemas más chungos que he visto en mi vida.
205. Las teles hacen sus propias movidas con sus motores.
206. Cosas chungas como repetir requests si fallan. Por su cuenta. Sin ningún tipo de control por el front.
207. Algún día habría que mirar si hay una correlación y una relación causa efecto entre lo de repartir carnets de true dev y el síndrome del impostor. Espoiler: yo diría que sí.
208. La programación de videojuegos me parece una cosa fascinante de la que no tengo la más remota idea en absoluto. Lo he intentado alguna vez y nop. No es lo mio.
209. Empecé a aprender Elixir porque la sintaxis me recordaba a Ruby y pensaba que se parecían. Jajajaja, no, no se parecen en nada. Ni en la sintaxis prácticamente.
210. Las dependencias no son inherentemente malas, pero si son un tradeoff muy difícil de hacer.
211. El autocompletado es una ventaja molona en entre el set de herramientas de un lenguaje y ayuda mucho a aprender.
212. Un editor que hace esto muy bien es visual studio @code
213. Una vez hace mucho tiempo me obligaron a trabajar con Rubymine (IntelliJ) me pareció una experiencia tremendamente frustrante por la obligación.
214. Rubymine es un gran IDE a pesar de que a mi me obligaran a usarlo.
215. Las herramientas básicas de Unix son maravillosamente potentes, pero muy difíciles de usar. Por suerte muchas están muy bien documentadas.
216. No tengo muy claro si los DSL me gustan para según que cosas. Los intento evitar en general.
217. He perdido la cuenta de las veces que me he dado un infartito por tener que tocar cosas en producción. Ya lo he dicho antes, tocar la BBDD de prod a mano es mala idea.
218. Es muy guay tener amiguis fuera del trabajo que programen con los que despotricar de las miserias de tu empresa.
219. No se programación móvil y me gustaría aprender, pero es una cosa más en una lista interminable.
220. Svn estaba muchísimo más roto que Git. Me fascina que aún se use. Pero si lo usas, git tiene esto git-scm.com/book/en/v1/Git… y puede hacer tu vida más fácil.
221. Releyendo creo que me he equivocado aquí la justicia social es lo importante. El. Beneficio que podamos obtener lo secundario.
222. Esto lo saqué de aquí: belenalbeza.com/articles/lesso… y creo que estáis tardando en leerlo.
224. Discutir sobre cómo formatear el código es una pérdida de tiempo. Lo único que hay que hacer es
225. Herramientas como prettier github.com/prettier/prett… que ya toman todas las decisiones de antemano por ti son una bendición.
226. Hasta ahora, la herramienta para instalar diferentes versiones de lenguajes que me he encontrado es asdf github.com/asdf-vm/asdf soporta un montón de cosas y es muy fácil de usar.
227. Si alguna vez tienes que hablar en público es crucial prepararlo un poco.
228. Las transparencias llenas de texto no ayudan nada a quienes siguen tu charla.
229. Preparar transparencias con poco texto, que apoyen lo que dices y te ayuden a mantener el hilo es difícil.
230. La universidad y los títulos no son muy importantes en esta disciplina. Pero no me queda claro por qué.
231. Si te gusta programar por hobby además de hacerlo por trabajo, ayuda bastante tenerlo todo separado.
232. Casi todas las empresas mienten en las entrevistas. Si le contaran a la gente como se trabaja allí, nadie querría hacerlo.
233. Una vez en una entrevista me dijeron que no me preocupara, que lo que ellos hacían era tener a todo el mundo de autónomo, así reducían costes de personal y la peña pagaba menos impuestos. Ni habían pensado que fuera ilegal.
234. Las empresas que piden colaboraciones en OSS como parte del CV no saben que lo que hacen está mal.
235. Pedir colaboraciones en OSS implica que obligas a la gente a dedicar tiempo fuera de su trabajo (la mayoría no te dejan hacerlo durante el horario laboral)
236. Y además suele ser un mal indicativo de que no saben muy bien como probar a los candidatos.
237. Hacer entrevistas a gente me parece un proceso complejisimo para el que no estoy nada preparado. Lo he hecho varias veces y me cuesta una barbaridad.
238. No todas las empresas dan feedback si te rechazan en una entrevista, pero merece la pena preguntar.
239. Si te llevas tupper a la oficina este libro es una bendición.
240. Desayunar antes de salir de casa se nota.
241. Si trabajas con git, esto es muy útil github.com/tj/git-extras
242. Si trabajas con Ruby, esto es muy útil github.com/troessner/reek sin embargo no te obsesiones con usarlo porque los smells son eso... smells. Antes de eliminarlos tienes que asegurarte de que realmente representan el problema al que huelen.
243. En general, ver los resultados de las herramientas de calidad como un fin y no como un medio para un fin, es una mala idea. Acabarás introduciendo cambios que no necesitas para acallar a una herramienta que te dice que a lo mejor eso que haces ahí no es buena idea.
244. ripgrep funciona muy bien github.com/BurntSushi/rip…
245. En ruby no es nunca una buena idea capturar excepciones generales (Exception o StandardError), mejor una subclase, mejor aún una subclase propia.
246. Si vas a hacer un test de que algo lanza una excepción, testea que lanza la excepción que tu quieres y no cualquiera, porque eso puede hacer que tu test de falsos positivos.
247. Si trabajas en un lenguaje que tiene NULL (nil, o como lo llame), no devuelvas nunca NULL, pero espéralo como argumento si lo necesitas.
248. Si necesitas devolver NULL, mejor usar un Null Object.
249. En lenguajes funcionales con tipos, no tienes de que preocuparte :)
250. En Elixir no devuelvas nil. Usa una tupla {:ok, valor} o {:error, error} y luego gestionala con with o pattern matching.
251. El problema con Null es que puede tener un monton de significados y puede aparecer en un monton de sitios. Depurarlo se convierte en una tarea titanica y la mejor forma de prevenir esto es evitar usarlo.
252. Si tienes que abrir una transaccion de base de datos, procura que la cantidad de codigo que se ejecuta dentro sea la minima imprescindible. Nunca operaciones largas, NUNCA JAMAS REQUESTS A OTRA API.
253. Si montar el sistema de desarrollo en local se acaba transformando en una locura por la complejidad de tu infraestructura, Docker + docker compose suele ser un buen amigo que te salva tiempo.
254. Silenciar una excepción es una receta maravillosa para el desastre. Algo se romperá y nadie se enterará. Si una excepción salta, registrala y logeala.
255. Las herramientas tipo sentry.io/welcome/ funcionan muy bien. Pero requieren una disciplina bastante alta para mantenerlas útiles.
256. Si hace cientos o miles de entradas en tu registro de errores y la última vez que alguien las miró fue hace semanas, tienes un problema.
257. Si eres un ecommerce además tienes 2 problemas porque estás perdiendo una cantidad brutal de ventas.
258. La información por defecto que estos logs envían es bastante pobre. Invierte tiempo en añadir información a las partes críticas de tu aplicación. Así lo tendrás mucho más controlado y los errores serán más fáciles de encontrar.
259. Con la cantidad de soluciones PaaS que hay hoy en día, hay que pensarselo bastante bien antes de meter una pieza nueva en tu infraestructura. El coste de instalación y mantnimiento puede ser mucho más alto que simplemente pagar un PaaS... que además lo hará mejor.
260. Si tienes un proceso de Elixir que arranca con tu aplicación y carga datos en su callback init, procura que no falle o tenga un buen fallback, pero que no explote. Te puede joder la release.
261. Esta extensión del navegador es útil si trabajas con github github.com/sindresorhus/r…
262. Este es un motivo de los más importantes por los que automatizar merece la pena
263. La deuda técnica es un concepto muy amplio en el que incluimos muchas cosas que yo creo que no son deuda, sino malas prácticas.
264. La distinción puede parecer irrelevante, pero al ser problemas diferentes hay que solucionarlos de forma diferente.
265. No sé si hay muchas formas de lidiar con la deuda, pero creo que mi preferida es tener un tablero específico en el que poder visualizarla en equipo y decidir qué partes hay que amortizar antes y cómo.
266. Amortizar deuda tiene que formar parte del proceso normal de desarrollo. Igual que con la deuda financiera, no te puedes endeudar por siempre y pagar cuando quieres.
267. No tener documentadas las features no es deuda técnica. Pero va a generarla.
268. El código viejo y estable no es deuda técnica.
269. El código viejo, inestable e infumable no es deuda técnica tampoco. Es un problema distinto y se tiene que solucionar de forma distinta.
270. Si no hay un plan de amortización no es deuda, es una chapuza, no es lo mismo arreglar chapuzas que amortizar deuda.
271. A veces hay que hacer chapuzas y luego transformarlas en deuda para poder pagarla.
272. Arreglar chapuzas a veces genera más deuda.
273. Todas estas cosas sobre deuda me las estoy sacando de la chistera... pero hace mucho tiempo que las pienso y no las había dejado escritas => A veces poner las cosas por escrito te puede ayudar a hilar tu razonamiento.
274. Si tienes un DBA, seguramente sabrá más que tu de BBDD, hazle caso cdo te hable.
275. Si el DBA dice algo que a nivel de código es una locura es evidente que hace falta una solución de compromiso, pero tanto DBA como tú sabéis dónde están los extremos, ahora es más fácil.
276. Lo mismo para cuando tengas que hacer cosas que implican a sistemas, devops, etc...
277. Tener usuarios nominales no es un "nice to have" y si no los tienes te vas a arrepentir.
278. Compartir un certificado privado entre toda la empresa para conectarte al servidor no es una medida de seguridad.
279. Aprendí que los backups son importantes cuando casi me da un ataque al corazón al borrar datos de producción de un cliente al hacer una prueba en desarrollo. Hice un backup 2 min antes.
280. Nunca es buena idea tener acceso a la BBDD de producción desde desarrollo... y si no que se lo pregunten a gitlab about.gitlab.com/2017/02/01/git…
281. Programar integraciones con APIs usando Elixir es una delicia y esto funciona muy bien github.com/teamon/tesla
282. Esta inspirado en esto, que tambien funciona MUY bien github.com/lostisland/far…
283. A veces un cliente simple y básico también vale, pero de cara a buscar estabilidad, métricas y buenos logs, las herramientas que tesla y faraday te ponen a mano son demasiado potentes como para ignorarlas.
284. Property testing es una herramienta muy chula, pero a veces aún me cuesta saber si estoy usándala demasiado o no lo suficiente.
285. Me costó meses entender redux porque pensaba que era algo mucho más complejo. redux.js.org

Muchas veces somos nosotros los que nos empeñamos en hacer los problemas grandes cuando son pequeños y simples.
286. La arquitectura de Elm me parece muy útil, pero el cambio de paradigma es tan total que no sé si me gusta. El lenguaje como tal me parece muy bonito.
287. No sé programación de sistemas y las pocas veces que me he intentado pelear con C me ha resultado muy frustrante, pero creo que si tuviera que hacer algo así ahora usaría Rust.
288. No sé gran cosa sobre patrones de software. Sé que existen y sé que son convenientes. Si tengo un problema suelo buscar antes de resolverlo para averiguar si algún patrón me puede ayudar.
289. Buscar bien en Google es la cosa más útil que una persona que programa puede aprender.
290. Si un lenguaje/herramienta tiene buena documentación cuesta muy poco hacer una PR para corregir pequeños errores y los mantenedores suelen estar super agradecidos.
291. Los offsite en los que todo dios se pone hasta arriba de alcohol me incomodan muchísimo y no creo que sean una buena idea. Los evito siempre que puedo.
292. He ido a más de los que me gustaría reconocer y me he emborrachado de mala manera.
293. Si tienes que ir a trabajar con mucha resaca es importante hidratarse bien y desayunar bien, pero no demasiado fuerte. Es mejor comer poquito varias veces a lo largo de la mañana.
294. El Ballmer Peak no existe, pero es muy gracioso de contar xkcd.com/323/
296. Leer un artículo que explica algo interesante y correr a aplicarlo suele desembocar en aplicarlo donde no se debe. Hay que intentar documentarse más antes de hacerlo.
297. Los fondos oscuros me ayudan a que los ojos se me cansen menos. Los fondos verde oscuro aún más. No sé qué habrá de científico aquí, pero hace mucho que lo noto.
298. La iluminación es extremadamente importante. Es de lo primero que miro en una entrevista.
299. Lo mejor que he hecho en mucho siempo ha sido aprender la distribución del teclado de USA, la española no sirve para programar.
300. En una terminal (bash, zsh, etc...) CTRL + r te deja buscar entre la historia.
301. Aquí tenéis un montón más de atajos readline.kablamo.org/emacs.html
302. Usar o no el ratón es cuestión de gustos, a mi me distrae, por suerte los atajos de antes funcionan en muchos sitios y en algunos incluso los de Vim.
303. Bash y zsh hace muchísimas más cosas de las que se ven a simple vista. Merece la pena leer un poco sobre cómo funcionan y se configuran porque son herramientas muy potentes.
304. Depende de gustos, pero los clientes de terminal ligeros tienen una ventaja más, puedes completarlos con tmux. github.com/tmux/tmux
305. Tmux plugin manager tiene cosas muy útiles github.com/tmux-plugins/t…
306. Por ejemplo tmux fingers github.com/Morantron/tmux…
307. En arch tienes un control muy bestia sobre casi todo. Pero si quieres un instalador básico puedes probar antergos.com
310. Eso de que si algo funciona es mejor no tocarlo... Nunca me ha gustado.
311. Si tienes que reportar un bug, los detalles son importantes. Navegador, so, hora aproximada, que hacías, una captura si hay mensaje de error... Es imposible saber qué puede ayudar.
312. Si el setup de un test se me empieza a enfarragar de código me huelo que hay algo que es demasiado complejo en lo que testeo.
313. Un test que falla de forma random no sirve, es mejor borrarlo.
314. Si se intenta arreglar, un debugger y un montón de trazas son bastante buena ayuda.
315. Casi todos los tests random que me he encontrado eran culpa de depender de la BBDD demasiado.
316. Si quieres probar qué ocurre cuando algo no existe, el id 0 suele ser la mejor solución. Cualquier otro id puede existir en algún momento en los tests.
317. Si es unitario mejor usar un mock.
318. Si tienes que testear código que depende de una API, lo más fácil es usar un mock del cliente e inyectarlo en los tests.
319. Si usas Ruby, VCR está muy bien pero solo para testear tu cliente. Cualquier otra clase que haga uso de él debe usar un mock.
320. Mantener tests que han abusado de VCR es un infierno.
321. Los tests mal hechos pueden ser peor que no tener tests.
322. Hacer TDD es más difícil de lo que parece, pero merece la pena intentarlo. Ayuda mucho a decidir de qué forma organizar el código.
323. Aprender que significa SOLID y aplicarlo de forma continua me ha resuelto problemas y ayudado a encontrar algún que otro marrón que me estaba generando a mi mismo.
325. El 99 bottles de Sandi Metz es un repaso muy bueno a SOLID.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Fran
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!