Cambio de sector profesional (Música y Enseñanza => Diseño Web / Programación)

Vas por el buen camino. Lo más complicado de saltar a la programación es que ésta te guste. No es un trabajo cómodo si no te ves 6-8 horas sentado al día trabajando de ello. Quizá no lo sepas bien todavía, pero creo que vas bien.

Mi primera recomendación es que elijas la vertiente que más te llame la atención. Ya sea frontend o backend (o incluso móviles). A priori no te recomendaría tocar todos los palos, eso podría llegar en un futuro. Si quieres aprender diseño web (o sea, CSS y temas así) pues frontend parece que es lo que más te llama (y en mi opinion, lo que más salida tiene hoy en día).

Te entiendo cuando dices que no te ves capaz de trabajar de ello todavía y no quiero asustarte, puede que nunca te sientas capaz, pero luego no es tan terrible.

React es una muy buena opción y lo mejor que puedes hacer ahora mismo es hacer proyectos para tu portfolio. Eso te dará confianza y puntos de cara a buscar trabajo. Yo soy tan músico como tu programador (bueno, llego algunos años tocando jeje), así que alguna app para temas de música te resultaría mas fácil.

Sobre gestión de proyectos, si bien no te vendría mal saber de scrum, ni de coña vas a poder dedicarte a ello a corto plazo, quizá ni a medio plazo.

Cordelay escribió:Buenas gente!

Tengo bastantes dudas sobre cómo afrontar un cambio de dirección en mi vida laboral, a ver si alguien que controle del tema o del sector puede contarme cómo ve la película...

Os cuento, soy músico, tengo 40 años, llevo currando 24 como músico de directo y estudio de grabación, y 22 años como profe particular de música, tanto en academias como por mi cuenta.

He vivido en "mij cannes" el empeoramiento drástico de las condiciones laborales en el mundillo musical (como tantos otros sectores, claro) y por otro lado cada vez se está poniendo más complicado mantener una cartera de alumn@s que dé para vivir sin ir ahogado.

Por esto y por otras razones, antes de arrancar 2020 decidí comenzar a estudiar Diseño Web y Programación por mi cuenta.
Dejar claro también que entiendo que este sector tampoco es la gallina de los huevos de oro, aunque así te lo vendan en bootcamps y cursos online...

En lo que va de año he ido haciendo algunos cursos de Udemy/Platzi/Coursera, tengo los certificados de freecodecamp de Web y Javascript, y aunque todavía no me veo con conocimiento ni capacidad resolutiva para ponerme a currar "ya", sí que me gustaría ir dando pasos en la dirección correcta para no tirarme tres años haciendo cursos de todo y estancarme en "Tutorial Hell".

Buscando ofertas así por encima me da la sensación de que lo que más se demanda es Frontend Senior con React y backend con no-se-qué stack... En principio y desde la inexperiencia, cualquiera de las dos opciones me parecen interesantes y de momento no tengo especial predilección por ninguna de las dos vertientes.

Lo que me causa un poco de conflicto es que estoy tan acostumbrado a trabajar de tú a tú o con equipos muy pequeños, buscando soluciones a las problemáticas del cliente, que no sé si me da el perfil y el conocimiento para entrar como "Junior" en algún sitio a "picar" código como me han comentado conocidos.

Por otro lado también me interesa el tema de gestión de proyectos y una amiga consultora me recomendaba que me sacara alguna certificación Agile / Scrum / Kanban, pero no sé si es algo que se demande así de primeras a un pringadete junior...

Os agradeceré cualquier comentario que dejéis al respecto, por lo pronto mi plan de estos mesecillos es hacer un par de proyectos personales para ir haciendo portfolio e ir viendo qué camino seguir...

Muchas gracias!

Ingeniero informático de sistemas, antiguo plan. 16 años de experiencia en el sector de los cuales 13 en desarrollo de software, tanto web como de escritorio, llevo 2 años trabajando en un hospital de celador y este año empiezo 3° del grado de enfermería. Espero que la programación te apasione, por tu bien.

Saludos y mucho ánimo en tu decisión.

Cordelay escribió:por lo pronto mi plan de estos mesecillos es hacer un par de proyectos personales para ir haciendo portfolio e ir viendo qué camino seguir...

This. Esto sin duda para mí es lo más importante, en general van a querer ver cosas que hayas hecho que por muchas titulaciones que puedas tener al final es lo que cuenta. Eso sí, te diría que te pensases qué te mola más antes de tirar por un camino u otro. Y sobre todo si te ves haciendo esto por una larga temporada.

Yo hago backend (normalmente trabajo en Scala en proyectos de microservicios y big data) por si tienes preguntas no te cortes .

Dale caña!

Taiyou

Muchas gracias por los comentarios, ver que uno no lleva mal camino da mogollón de ánimo

@Fox
React me está gustando mucho, principalmente por el contraste con respecto a usar directamente html+css+js, y aunque aún no he llegado a ver nada de redux ni hooks, de momento me atrae la idea de usar un framework / librería que dé unas pautas de trabajo más o menos definidas.
Por otro lado, sigo teniendo la duda de si meterme con React sin controlar más en profundidad javascript y algoritmos es centrarme demasiado pronto en Frontend y hacerme un flaco favor a la hora de formarme...
¿Qué instrumento tocas?

@Taiyou
Terminé el mes pasado el curso de "Full Stack" de Udemy de Colt Steele, en el que se trabaja en backend con Node, Express y MongoDB, y me pareció muy interesante, pero me temo que es demasiado básico como para dar una impresión clara de lo que es el curro: No me imagino a alguien currando exclusivamente haciendo las rutas REST y configurando la base de datos de sitios chiquiticos.
Cuando hablas de microservicios, ¿te refieres a conectar la app con tal API y con tal otra API?
Es que me da un poco la sensación de que para currar en Backend hay que haber ganado experiencia/conocimiento suficiente, y perdón por alimentar el mito de que frontend < backend (algunos de esos memes son gloriosos).

@Latitude
Las experiencias vividas y las preferencias personales está claro que nos llevan a veces a denostar opciones de vida que para otra gente serían la gloria.
La cantidad de gente que al comentarles que "sobrevivo" de la música ven con envidia dedicarse a "lo que a uno le gusta" pese a las penurias económicas constantes, y mi planteamiento, mucho menos romántico y más pedestre, es encontrar un curro que tenga un horario más o menos rutinario, que me permita llegar fin de mes en condiciones, y que sea un poco (o un mucho) retador a nivel intelectual.
Si has sustituido el curro de desarrollador por el de celador supongo que te habrá merecido la pena, quizá por temas de horarios más fijos o por poder compatibilizar con los estudios de enfermería.
En cualquier caso suerte y mucho ánimo con la carrera, pocas cosas son más necesarias que buenos profesionales sanitarios, por experiencia (y más con la que está cayendo).

Un saludote a todos!

Cordelay escribió:Cuando hablas de microservicios, ¿te refieres a conectar la app con tal API y con tal otra API?

Por microservicios me refiero a que en vez de tener todo el backend corriendo dentro de una única aplicación (lo que a veces se llama "monolito"), divides la lógica en varios "backends" separando las responsabilidades de cada uno. Por ponerte un ejemplo, imagina que Netflix hace esto (de hecho lo hace) y tiene a lo mejor un microservicio que se encarga de controlar los usuarios, otro la lista de vídeos, otro temas de cachés, otro para comunicarte con el frontend, otro de CDNs... (esto es una versión ultra-simplificada, realmente en Netflix lidian con cientos de microservicios).

Esto tiene cosas buenas y malas. Por un lado te permite mucha flexibilidad (puedes incluso usar diferentes tecnologías entre cada uno), puedes tener gente centrada en un conjunto pequeño de ellos y tener mucho control sobre la lógica de cada uno, y sobre todo que si hay algún problema (rollo red, un fallo en los servidores...) si lo has diseñado todo más o menos bien no tiene por qué afectar a la integridad de todo el sistema. Por otro lado la pega es que divides mucho el diseño y normalmente acabas necesitando más gente, necesitas comunicación muy rápida entre los servicios para que no introducir muchos retrasos e introduces complejidad extra conforme crecen en número (ej: cómo lidiar con los modelos de los mensajes que se intercambian cuando algunos microservicios son mejorados y otros no sin romper compatibilidad).

Usualmente esto se hace teniendo clusters donde corren instancias de estos microservicios, comunicados con algún protocolo rápido (idealmente gRPC, también es común que se use HTTP o directamente sockets). Es normal también contar con un sistema de cola de mensajes que sirva tb de backup por si algún microservicio se cae, cuando se instancie de nuevo pueda recuperar esos mensajes y actuar como si no hubiera pasado nada (para esto hay muchas opciones pero la que más he usado es Apache Kafka). Al ir todo esto en clusters de servidores también es usual usar bases de datos que funcionen bien en estas situaciones (la que más he usado es Cassandra, pero PostgresSQL tb es común). Luego para lidiar con los despliegues lo que más he usado es Docker para contenedores y Kubernetes/Helm para lo que son los despliegues en sí. Además los proveedores de nubes generalmente ofrecen estas soluciones o las suyas propias para correr estas aplicaciones y que todo quede en casa .

Yo normalmente trabajo con Scala como lenguaje de programación (pero es común que se use Java tb). Un framework muy común para lidiar con estos problemas es Akka (que proporciona mil herramientas para trabajar con paralelismo de manera segura, trabajar con temas de streaming, crear APIs REST, crear y gestionar clusters y nodos...). La mayoría de tecnologías que he mencionado son libres hasta cierto punto (Akka tiene módulos de pago pero en general es open source), así que si quieres trastear no deberías tener muchos problemas.

Perdona el tocho y la sobrecarga de información, pero así creo que queda resumido muy superficialmente con lo que lidio a diario . Si te interesan estos temas y necesitas que te resuelva alguna duda (ten en cuenta tb que soy normalito, ningún experto ni nada!) me comentas ok?

Taiyou

EDIT:

Cordelay escribió:es encontrar un curro que tenga un horario más o menos rutinario,

Cuidao con esto, que yo he tenido épocas de locuras horarias muy heavies... incluyendo viajes transoceánicos y palizas de jetlag que no eran nada sanas .

Cordelay escribió:es encontrar un curro que tenga un horario más o menos rutinario,

Aunque me dedico a software industrial y está claro que una fábrica no puede parar, sé por algunos colegas programadores de estas movidas de las que habláis (he dicho ya que odio el desarrollo frontend? ) que esto también les pasa en entregas de proyecto:

Yo he tenido jornadas de 16 horas. Y aunque es cierto que no es sostenido (o mueres), me he tirado así 10/12 días seguidos, según cargas de trabajo (o más bien, comisionado, pero esto es específico de industria)

O que surja algún problema en producción (en entorno, no me refiero a fábrica propiamente dicha) y tu jornada de 8 pasa a 10 horas ese día.

jorcoval escribió:O que surja algún problema en producción (en entorno, no me refiero a fábrica propiamente dicha) y tu jornada de 8 pasa a 10 horas ese día.

Yo me he pasado más de un par de años trabajando de tarde y noche por tener un proyecto con cliente americano que exigía parte de la jornada sincronizada con ellos. Te acabas acostumbrando pero no es fácil. Y estas cosas te llegan de un día para otro literalmente.

Taiyou

Es lo que digo siempre. Trabajo hay y bien pagado también pero te gusta o te gusta, si no, pues se vive amargado.

Y si, epocas chungas hemos tenido todos. Yo por ejemplo he trabajado todo julio non stop (desde que me levantaba hasta dormir) porque soy autonomo y en agosto quería 3 semanas de vacaciones y poder tenerlas lo más tranquilas posibles.

PD: Toco el piano y sintetizador.

Fox escribió:Es lo que digo siempre. Trabajo hay y bien pagado también pero te gusta o te gusta, si no, pues se vive amargado.

Y con esto se puede ir cerrando el hilo. Meterse a programar porque tiene salida es sinónimo de dejarlo en un par de años. Es un mundo que te tiene, ya no que gustar, si no apasionar.

@Taiyou
Vaya tochazo !
Te agradezco la explicación detallada, hay muchas tecnologias que ni siquiera sé qué funcionamiento tienen en la cadena (bueno, en realidad no tengo claro del todo ni para qué sirve la cadena, jur)...
Por eso decía que me daba la impresión de que con el frontend todo parece ser más concreto (sin meternos a fondo con temas de frameworks, que supongo que pueden tener tremendas complejidades), mientras que en el backend los conceptos son más abstractos, al menos para un novato como yo

@Fox @jorcoval
Respecto a jornadas interminables, sin tratar de desmerecer, en todos sitios cuecen habas.
He currado en bastantes trabajos diferentes en mi vida y en todos en los que he cobrado mensualmente o por obra y no por horas, en algún momento me ha tocado apencar.
Y lo que ha marcado que esas horas extra fueran más o menos soportables no era tanto el sector en sí mismo como la relación que tuviera con la gente con la que curraba, con lo que, para bien o para mal, me aventuro a decir que no es algo exclusivo ni representativo necesariamente del sector.

Lo que sí he oído a menudo es que a mucha gente lo que más les cuesta dentro de esto es tener que estar enfrentándose constantemente a los errores propios y el tener que reciclarse constantemente...
En principio esto no lo veo como muy problemático, pero supongo que si le sumas el hecho de que en general los clientes siempre lo quieren todo para ayer...

Pregunta concreta, y si soy muy plasta no me respondais: ¿Cómo lidian en vuestros respectivos curros (jefes/superiores y clientes) cuando no se pueden alcanzar deadlines? ¿O cuando surgen fallacos inesperados que de repente impiden desarrollar ciertas funcionalidades o qué-sé-yo?

De nuevo, gracias por haberos tomado tiempo para responder.

Taiyou escribió:

Cordelay escribió:Cuando hablas de microservicios, ¿te refieres a conectar la app con tal API y con tal otra API?

Por microservicios me refiero a que en vez de tener todo el backend corriendo dentro de una única aplicación (lo que a veces se llama "monolito"), divides la lógica en varios "backends" separando las responsabilidades de cada uno. Por ponerte un ejemplo, imagina que Netflix hace esto (de hecho lo hace) y tiene a lo mejor un microservicio que se encarga de controlar los usuarios, otro la lista de vídeos, otro temas de cachés, otro para comunicarte con el frontend, otro de CDNs... (esto es una versión ultra-simplificada, realmente en Netflix lidian con cientos de microservicios).

Esto tiene cosas buenas y malas. Por un lado te permite mucha flexibilidad (puedes incluso usar diferentes tecnologías entre cada uno), puedes tener gente centrada en un conjunto pequeño de ellos y tener mucho control sobre la lógica de cada uno, y sobre todo que si hay algún problema (rollo red, un fallo en los servidores...) si lo has diseñado todo más o menos bien no tiene por qué afectar a la integridad de todo el sistema. Por otro lado la pega es que divides mucho el diseño y normalmente acabas necesitando más gente, necesitas comunicación muy rápida entre los servicios para que no introducir muchos retrasos e introduces complejidad extra conforme crecen en número (ej: cómo lidiar con los modelos de los mensajes que se intercambian cuando algunos microservicios son mejorados y otros no sin romper compatibilidad).

Usualmente esto se hace teniendo clusters donde corren instancias de estos microservicios, comunicados con algún protocolo rápido (idealmente gRPC, también es común que se use HTTP o directamente sockets). Es normal también contar con un sistema de cola de mensajes que sirva tb de backup por si algún microservicio se cae, cuando se instancie de nuevo pueda recuperar esos mensajes y actuar como si no hubiera pasado nada (para esto hay muchas opciones pero la que más he usado es Apache Kafka). Al ir todo esto en clusters de servidores también es usual usar bases de datos que funcionen bien en estas situaciones (la que más he usado es Cassandra, pero PostgresSQL tb es común). Luego para lidiar con los despliegues lo que más he usado es Docker para contenedores y Kubernetes/Helm para lo que son los despliegues en sí. Además los proveedores de nubes generalmente ofrecen estas soluciones o las suyas propias para correr estas aplicaciones y que todo quede en casa .

Yo normalmente trabajo con Scala como lenguaje de programación (pero es común que se use Java tb). Un framework muy común para lidiar con estos problemas es Akka (que proporciona mil herramientas para trabajar con paralelismo de manera segura, trabajar con temas de streaming, crear APIs REST, crear y gestionar clusters y nodos...). La mayoría de tecnologías que he mencionado son libres hasta cierto punto (Akka tiene módulos de pago pero en general es open source), así que si quieres trastear no deberías tener muchos problemas.

Perdona el tocho y la sobrecarga de información, pero así creo que queda resumido muy superficialmente con lo que lidio a diario . Si te interesan estos temas y necesitas que te resuelva alguna duda (ten en cuenta tb que soy normalito, ningún experto ni nada!) me comentas ok?

Taiyou

EDIT:

Cordelay escribió:es encontrar un curro que tenga un horario más o menos rutinario,

Cuidao con esto, que yo he tenido épocas de locuras horarias muy heavies... incluyendo viajes transoceánicos y palizas de jetlag que no eran nada sanas .

Me ha molado hasta a mí.

Al op, siempre puedes apuntarte a DAW o DAM. Yo me apunté y me cambió la vida.
También ha habido mucho inútil en mi curso que solo esperan que alguien les solucione la papeleta.

Yo sin saber nada y ahora 5 años después de empezar a estudiar sé bastante.
Yo estoy con PHP en el backend y js en el front aunque hay apps en mi empresa con react.

Ahora estoy intentando hacer una app con react-native.
Poco a poco vas tocando todo.

Cordelay escribió:Por eso decía que me daba la impresión de que con el frontend todo parece ser más concreto (sin meternos a fondo con temas de frameworks, que supongo que pueden tener tremendas complejidades), mientras que en el backend los conceptos son más abstractos, al menos para un novato como yo

Pero eso es normal, eso se debe al background que tienes: A mí me pasa al revés, las tecnologías de frontend en general me parecen muchos mas abstractas? raras? que el backend en general (aunque no me he especializado en ninguno de los dos, pero si tuviera que decir a qué me parezco más, diría que a backend).

Cordelay escribió:Pregunta concreta, y si soy muy plasta no me respondais: ¿Cómo lidian en vuestros respectivos curros (jefes/superiores y clientes) cuando no se pueden alcanzar deadlines? ¿O cuando surgen fallacos inesperados que de repente impiden desarrollar ciertas funcionalidades o qué-sé-yo?

De nuevo, gracias por haberos tomado tiempo para responder.

Es otro rollo - sobre todo cuando vas a trabajar en sitios que no siguen la clásica mentalidad de ver cuantas horas estás calentando la silla.

Los deadlines, en general, si no se alcanzan pues se notifica al project manager de turno (para el cual parte de su trabajo es comerse el marrón de avisar a los responsables de que va a haber retrasos; y después replanificar).

Sobre los "fallacos inesperados", pues depende de la gravedad del problema, del impacto, y de lo fácil que sea de solucionar. Si algo es importante, y estás en horas de trabajo, pues te pones a arreglarlo y punto. Si no son horas de trabajo, pero no es crítico, pues se deja para el dia siguiente/lunes siguiente. Y si es crítico, pues normalmente los equipos que tienen esa responsabilidad suelen tener rotas/turnos de gente que está mas o menos pendientes del tema, y si se rompe algo, pues sí, se conectan y ponen un parche que aguante hasta el dia siguiente que pueda ponerse el equipo completo a arreglar el problema en condiciones.

Resumiendo: Al final lo que se acaba valorando más es el impacto que hayas tenido en los proyectos de la empresa. Esto también puede traer bastante estrés, pero ocurre de forma muy distinta. Es raro ver a alguien que esté con el reloj controlando cuando empiezas/dejar de trabajar, o que se acabe el mundo por simplemente no llegar a un deadline.

Cordelay escribió:@Taiyou
Vaya tochazo !
Te agradezco la explicación detallada, hay muchas tecnologias que ni siquiera sé qué funcionamiento tienen en la cadena (bueno, en realidad no tengo claro del todo ni para qué sirve la cadena, jur)...
Por eso decía que me daba la impresión de que con el frontend todo parece ser más concreto (sin meternos a fondo con temas de frameworks, que supongo que pueden tener tremendas complejidades), mientras que en el backend los conceptos son más abstractos, al menos para un novato como yo

Uy pues a mí el frontend me parece magia negra D. Tiene su complejidad tb, yo creo que al final la dificultad en lo mío es manejar mucho volumen de datos (o número de fuentes de datos) y no perder rendimiento. En el caso del frontend hay que ajustarse a diseños, prestar mucha atención al rendimiento también, no sobrecargar el navegador dentro de lo posible...

Pregunta concreta, y si soy muy plasta no me respondais: ¿Cómo lidian en vuestros respectivos curros (jefes/superiores y clientes) cuando no se pueden alcanzar deadlines? ¿O cuando surgen fallacos inesperados que de repente impiden desarrollar ciertas funcionalidades o qué-sé-yo?

Suelo ser más duro conmigo mismo que mis jefes/clientes, la verdad. Antes de que me pidan nada ya estaré yo echando horas de noche si veo que no se llegan a los plazos... Pero claro, en esto hay culpa compartida: si ha sido culpa de una planificación chunga o decisiones cuestionables "desde arriba" es diferente que si no llego porque he tomado un camino equivocado o porque me encuentro un bug para el que no soy capaz de localizar la causa . En mis últimos años el ambiente (respecto a los plazos de entrega) siempre lo he tenido muy bueno, por suerte.

Taiyou