Que tiene de malo para ti (que le falta, que no te gusta, que crticas) el original que has puesto?
https://roadmap.sh/pdfs/backend.pdf
Que si bien no es perfecto ni esta actualizado ni se explaya mucho en que cosas exactamente importan cubre bastantes temas.
#31 si lo dices por mí nada.
Simplemente porque de toda esa lista, entiendo que en el día a día se trabajan con X cosas a menudo, de ahí que pregunte por lo que más se usa o no se usa de la lista que pongo yo y he ido adaptando con comentarios para que alguien que quiere empezar se mire esas cosas o añada esas cosas a su lista mental o algo que esté obsoleto o no se use se quite, etc...
Cómo "base".
#32 siguiendo el roadmap original
donde no importante significa que una lectura a la teoria suele ser suficiente, no lo vas a usar en la vida, la gente que lo usa no tiene ni puta idea, cosas opinionadas y/o situacionales...
donde importante significa que es conocimiento util, transversal, que vas a usar cada dia durante el resto de tu vida, deberias tenerlo siempre en mente cuando picas o diseñas
aprende lo importante y porque es imporante, aprende porque algo no es imporante.
#34 No problem, pregunta lo que quieras y seguro que la gente te ayuda. No creo que mis recomendaciones esten muy lejos de la opinon de la mayoria. Por lo que he leido por atras...
Voy a explicar un par de no importantes por ejemplo para que se entienda por donde va la recomendacion:
En cambio es super importante entender como funciona el OS, si sabes como va el OS y la networking ya sabes la teoria para hacer todo lo anterior bien.. Es la base. Cuanto mas sepas mejor.
#29 Un especialista en base de datos por ejemplo, DynamoDB, MySQL/Aurora, etc se entiende perfectamente, conocer los detalles de cómo funciona etc y actúa generalmente como consultor (bien pagando y sin intermediarios).
Un especialista en un lang sería muy similar, ayudaría a desarrollar libs de plataforma, el core de la app y el paved path asi como enseñar cómo hacer las cosas a los demás.
Ser generalista ayuda a llegar hasta staff engineer. Ser especialista te permite llegar a principal o distinguished engineer.
Y ser un soft skilled te permite tirar por lead engineer.
Todos empezamos siendo generalistas, llegados a un punto toca elegir, así que si, todos somos generalistas hasta cierto punto.
#36 Lee bien. No he dicho que no se use. Digo que no es importante dedicarle mucho tiempo. Cualquier SVC lo aprendes en una tarde... Y la metodologia de trabajo en un par de dias...
Ademas Git por ejemplo. La industria actual esta de moda usar metodologias basadas en pull request que son una mala practica. Y te diria que el 99.9% de la gente ni lo saben. Asique para empezar todo lo relacionado con Git en el mundo empresarial se hace mal. Para seguir lo mas importante de "Git" es el frontend/tooling como GitKraken/Tortoise para user y para hacer reviews cosas como Critique o Github/Gitlab... Y es lo mismo con cualquier otro SVC. La mayoria de gente no sabe en que Git es bueno o malo vs otros SVC y nunca los han usado. Ni conocen alternativas / hibridos. Y no importa una mierda. Solo le importa a Google o Facebook que tienen cien millones de LOC. O la gente del kernel de linux. Ah, y que no falte un abuelo cebolleta que hace 20 años uso XXX y te dira que Git es la polla mientras te hace una PR de mil LOC tocando 50 ficheros. Porque al igual que Git añade features cada año, los otros SVC tambien eh... Y te diria que Git en cuanto a usabilidad es el peor SVC por problemas de diseño muy core /hilo
En fin, que no vale la pena perder mas de una tarde. Si nunca necesitas o quieres dedicarle tiempo ya lo haras.
#39 En mi empresa usamos Subversion, pero es algo raro, lo normal es encontrarte Git en el 99% de las empresas
#41 El mismo hilo es aprovechable perfectamente sin importar el lenguaje que se utilice para el backend.
El mismo roadmap de #1 se llama "backend roadmap", no "js backend roadmap", y en él puedes ver que sugieren lo mismo para JS, C#, Java, Go, etc.
Otro ejemplo de ésto mismo, comentarios que aportan como #12 #27 o #33 son perfectamente válidos y aplicables cualquiera que sea el lenguaje "elegido".
Pero si hay dudas específicas de un lenguaje en sí, no creo que el OP tenga problemas en que preguntes aquí o a una mala, se crea un hilo similar por lenguaje, sin miedo, se aprende investigando y preguntando
#39 Ninguna empresa grande usa git "a pelo" porque suelen tener monorepos o no te interesa que sea distribuido (git es distribuido) para montar tooling encima. Tienes scalar (evolucion de vfsforgit) de microsoft, google tiene piper, repo y gerrit.. y meta tambien tienen cosas sobre svn que no se muy bien porque no he tocado.
El kernel de linux funciona sin PRs al igual que muchos proyectos open source. La manera correcta de usar git distribuido. Con emails XD Asi se invento y diseño Git. En mi experiencia muy comodo y yo uso un workflow parecido al que se usa para contribuir al Kernel aunque al final haga una PR.
Deberias aprender como funcionan los productos de AWS o GCP o Azure o deberias aprender lo que hay por debajo? Con Git es lo mismo, Github y Gitlabs solo son empresas que te queiren encerrar en su ecosistema y lo que te proponen no es la mejor manera... De hecho es una mala manera a proposito para que pases el maximo tiempo en sus servicios y dependas de ellos para todo. Eso si, si quieres una alternativa haztela tu. Y para sorpresa de nadie las empresas prefieren dejarse millones (o cientos de miles) en pagar a uno de estos antes de aprender a usar un SVC en condiciones para su problema.
Mi solucion para el 99.99% de las empresas seria no usar Gitlab/Github y seguramente no usar Git tampoco. Dicho esto, el 99.99% de los "ingenieros de software" no saben usar Git ni otro SVC. Normal que estemos donde estamos. Por desgracia la cultura de la industria esta tan mal en este tema que empresas grandes ahora sacan proyectos open source con Git en Github/Gitlab porque es lo unico que entiendien los pajeets... XD Cuando la gente dice "aprende git" en verdad te dice "aprende a usar github" y eso es perder el tiempo.
Este mismo analisis lo puedes aplicar a las "tecnologias" del roadmap. Es perder el tiempo.
#43 y qué no es perder el tiempo?
Joder hay muchas cosas ese roadmap que son básicas para este puesto o eso creo 
#44MrN4N0:que son básicas
una lectura en diagonal o un mini proyecto para aprenderlo un dia es suficiente...
imagina que tienes que escribir el docker de un servicio nuevo. cuantas veces vais a escribir ese docker? pues 1 vez al principio y como mucho lo tocareis para upgradear alguna version. para que quieres dedicarle 2 meses a escribir dockerfiles multi stage y aprender como hacer cosas super complejas que no usaras en la vida? si el caso de uso basico que es hacer un container tardas 5 minutos en googlear un Dockerfile para tu stack?
otro tema es que quieras aprender en profundidad los detalles tecnicos de como funcionan las vm, las microvm, los contenedores... que al final es estudiar OS y eso siempre es bueno.Y eso siempre es bueno porque no veo que vayamos a re-escribir toda la industria del software en los proximos 50 años.
si por ejemplo tu trabajo es de devops y trabajas optimizando contenedores y gestionandolos, entonces puedes ampliar el tiempo a docker... porque cambia tu situacion. pero para cualquier persona normal que no se dedique a desarrollar contenedores, vms, servicios serverless, nse, con saber googlear y hacer copy paste es suficiente.
#45 Y los conceptos un poquito en diagonal que sino sacan far containers de 1Gb (que los he visto) con absolutamente de todo instalado por hacer copy paste de stack overflow o del blog de turno que ha copy pasteado de otro blog que ha copy pasteado de otro blog que ha copy pasteado de stack overflow. Es la nueva industria del copy paste blogging y ebook.
