Tengo esa duda ya que el año que viene saldré al mundo laboral.
Sé que depende de la empresa, del equipo al que te asignen y de la experiencia que tengas, obviamente. Pero en general, ¿suele ser tocar APIs? ¿CRUDs? ¿Un poco de todo? Me gustaría saber qué me voy a encontrar ahí fuera.
Gracias, saludos.
Yo toco sobretodo spring boot y micro servicios. Parece que tambien hay mucho trabajo de angular y de android (mas de angular creo). Y ya pues todas las herramientas relacionados con ello como son postman, Openshift, SOAP etc ...Llevo poco en esto y obviamente esto es mucho mas complicado del resumen que te he dado y ademas yo aun estoy muy verde xd
Si te vas haciendo cursos de sprint boot o angular y te miras algo de los microservicios y tal, iras mucho mas preparado a las empresas. Pero seguro que aqui hay gente que te podra orientar mucho mejor por su experiencia...
También te puedes hartar de hacer querys y montar Excel también te aviso eh xD.
Depende del proyecto y punto.
1 dia de programacion, 1 dia de testing y 3 de burocracia para subir las modificaciones ( y eso en una semana buena)
Pues tendrás que saber y hacer de todo. Se creen que los informáticos somos dioses y que lo mismo te arreglamos una lavadora que te hacemos una web.
Suena a coña, pero es verdad, el trabajo de software suele conllevar trabajo de analisis funcional, sistemas, testing, todo, el trabajador de IT se ocupa, en la mayoria de casos de todo. Y así van las cosas luego claro.
Yo alineo divs por dinero
Aunque la previsión futura es que también eche la zarpa ayudando a smart contracts y el back, pero con entregas dentro de tan poco no podrá ser hasta dentro de al menos un mes (acabo de entrar en esta)
#12 No hables por mí, yo he trabajado 6 meses como tecnico de hardware y estoy harto de montar historias
Además que, en cierto modo, uno debe saber de hardware, yo cuando hago tareas de arquitectura de software debo saber qué componentes pedir para los servidores de los sistemas, tengo que estar al dia porque eso hay que comprarlo y montarlo y soy yo el que lo decido a pesar de dedicarme al software
Ahora, hay de todo, conozco peña que trabaja programando qu eno sabe ni usar el outlook xddd
#13SikorZ:yo cuando hago tareas de arquitectura de software debo saber qué componentes pedir para los servidores de los sistemas, tengo que estar al dia porque eso hay que comprarlo y montarlo y soy yo el que lo decido a pesar de dedicarme al software
Esto es la locura más gorda que he leído en toda mi carrera. Si mi empresa me dijera que tengo que encargar y montar los servidores, a los cinco minutos estoy saliendo por la puerta con la baja voluntaria entregada.
#1 más del 70% de este trabajo es social, hablar con la gente es primordial. Implementar una nueva funcionalidad cualquiera puede hacerlo, el problema es hacerlo bien, hacerlo como el cliente/jefe/stakeholder/PA/BA quiere y sobretodo que todo el equipo este al tanto de como se va a hacer y lo entienda.
Que la gente que se vaya del proyecto no deje un gran vacio de conocimiento y sea repartido, escribir documentación de calidad y mantenerla, darte cuenta de que el diseño o propuesta que hizo el equipo para implementar algo no es el adecuado hablarlo con el equipo y cambiarlo, no creer en dogmas, sabes que SIEMPRE alguien va a saber más que tu y sobretodo no ser un gilipollas prepotente (que por desgracia los hay a patadas) si controlas bastante.
Para todo lo demás, mastercard.
Yo creo que algunos trabajáis en empresas de mierda u o están explotando haciendo que hagáis 3 o 4 roles distintos (que es correcto si os pagan el sueldo de 4 personas) y no sois conscientes de ello.
Yo no hago absolutamente nada que no sea implementar funcionalidad en mi proyecto y en mi parte.
Ni tengo que hablar con el usuario para entender el problema y que hay que hacer, para eso está el product manager, ni tengo que tocar la parte que ve el usuario, para eso están los diseñadores, ni tengo que mirar por qué un servidor se ha caído o montar la infraestructura del nuevo proyecto, para eso están los de sistemas, y ni mucho menos me viene nadie a que le arregle el email o la fotocopiadora.
#15Kaledros:Si mi empresa me dijera que tengo que encargar y montar los servidores
Es que yo no he tenido que montar nada, sólo he dicho que tengo que decidir las especificaciones de hardware.
Como arquitecto debes hacer una definición tecnica y debes definir que tipo de maquina necesitas para montar todos los sistemas de software. Así como la configuración del OS donde se va a desplegar.
No se que has visto de raro en esto xd, si no defines la potencia minima necesaria para correr los sistemas que hayas definido para la arquitectura no va a funcionar
#14Fyn4r:Vives en los 90?
Por? Tu despliegas las aplicaciones en servidores imaginarios...?
#17cabron:Ni tengo que hablar con el usuario para entender el problema y que hay que hacer
Esto me suena super alien. Usuario, experto de dominio, quien sea, pero parte de análisis sobre las necesidades tienes que tener sí o sí, a mí no me gusta comerme tickets y ya. Habré mordido el anzuelo para ser sobreexplotado o algo así, pero me gusta que todos estemos más involucrados en el proceso de principio a fin.
#18SikorZ:No se que has visto de raro en esto xd, si no defines la potencia minima necesaria para correr los sistemas que hayas definido para la arquitectura no va a funcionar
No sé, yo eso de toda la vida se lo he visto hacer al devops o directamente a los de IT. Nunca he visto a un arquitecto decidir sobre hardware ni creo que sea su tarea.
No he dicho que no se haga, simplemente no es mi trabajo, es el de otras persona, eso no significa que se haga de forma aislada al equipo de desarrollo.
Yo puedo decir que eso que piden no tiene sentido, que hay algo que no han tenido en cuenta, proponer que sería mejor otra alternativa, etc, pero yo no tengo que ir a hablar directamente con el usuario final, yo hablo con el PM y el resuelve lo que sea con quién sea.
#21 ¿Cómo lo van a hacer los de devops? ¿acaso ellos definen la arquitectura en tu empresa?
Eso no tiene ningún sentido xD
El arquitecto al definir los sistemas sabe qué (o debe saber) cuantos recursos necesita el aplicativo conjunto, ¿si no como van a saber los de sistemas que montar?
Vamos, a lo mejor en tu empresa se hará diferente, pero no me fio yo de uno de sistemas ni de coña, el que sabe del software que monta es el arquitecto, el de sistemas está ahí para montar racks y punto, como debe ser.
#24SikorZ:¿si no como van a saber los de sistemas que montar?
"Buenas. Necesito una máquina para rular esta aplicación. Estos son los requisitos de transacciones simultáneas, los tiempos de respuesta y demás consideraciones. Si tenéis alguna duda no dudéis en preguntarme. Gracias."
Y ellos te montan un AWS/server físico/loquesea donde desplegar.
#17 Tiene pinta que desarrollaras un rol poco más que un junior, ¿no?. Hablar como mínimo con el Tech Lead (o similar como lo llaméis en tu empresa) para poneros de acuerdo o pediros opinión de un diseño o funcionalidad me parece lo más básico. Preguntar dudas o inconsistencias en un ticket que tienes que hacer, realizar un pequeño diagrama para entenderlo o explicarselo a otra persona es aún más básico. ¿Qué sois autómatas?
Y ya ni hablemos de la cultura DevOps que todo el mundo esta adoptando, donde ahora el que realiza el desarrollo es el que lo despliega y cada equipo se encarga de sus pipelines.
Supongo que estamos hablando de distintos trabajo, pero desde mi punto de vista, es muy distinto al de "me lo dan mascao, lo implemento".
Te remito al post #22 donde ya he explicado lo mismo.
Que no sea mi trabajo no significa que me den un ticket del que no sé nada ni por qué es así ni de dónde ha salido, y que tenga que hacer lo que pone ahí sin opinar.
De hecho soy el responsable técnico del proyecto en el que estoy y cualquier petición tiene que pasar por mí y tener mi ok antes de empezar a hacerla pero si a tu eso lo llamas un puesto junior por qué no me pongo a modificar el CSS o a discutir con un usuario pues vale.
#25 Ni de coña delego yo eso en un pinchatarjetas, pero vamos, ni loco.
Yo defino las condiciones del software, que para eso soy el que diseña el sistema, no un random cuyo trabajo es apretar tornillos xd
