¿Aproximadamente qué porcentaje de tiempo pasa realmente desarrollando software en su trabajo?

El desarrollo de software es un proceso. Una gran parte de esto es comprender el resultado deseado y trazar una serie de pasos para llegar a ese punto. Y es muy cíclico. Algunos días pasaré la mayor parte de mi tiempo escribiendo código. Otros días pasaré todo el día desarrollando nuevas ideas o características.

Para las aplicaciones web, comenzaré escribiendo el resultado / funcionalidad deseado.

Luego, dibujaré un marco de alambre rápido, para poder obtener una buena imagen mental de cómo todo encajará en la pantalla y / o interactuará.

Finalmente, puedo comenzar a escribir código y pasar por ciclos de prueba para asegurarme de que las cosas funcionen como se esperaba y eliminar cualquier error grave.

Para el análisis de datos, comenzaré por comprender muy bien cuáles son los datos entrantes y cuál será el resultado deseado. Qué lógica o transformaciones estarán involucradas para llegar de A a B a C.

Después de haber trabajado con algunos proyectos de manipulación de datos realmente complejos, he aprendido que ahorra MUCHO tiempo entender claramente lo que el cliente realmente quiere que suceda. Incluso pequeños malentendidos sobre cómo expresaron algo pueden crear retrasos significativos o producir un resultado final muy diferente.

30% – 50% de mi día lo paso codificando.

Dejame explicar:

Depende de cómo se defina el “desarrollo de software”. Hay mucho que entra en eso. En mi contexto, soy un ingeniero de software full-stack que trabaja en una startup con un pequeño equipo de ingenieros. Es probable que el flujo de trabajo sea muy diferente para otros tipos de organizaciones (especialmente organizaciones empresariales). Donde estoy, mi tiempo se divide de la siguiente manera: hay reuniones (planificación de sprint, preparación del trabajo atrasado, una reunión general de ingenieros), y luego el tiempo dedicado por mí mismo o con otros conceptos de ” pizarra ” (arquitectura de software). Luego, está la parte de codificación real, y luego las solicitudes de extracción en Github que revisamos el código y luego cambiamos el código antes de fusionarlo. Ah, y no se olvide de cosas diversas , como almuerzos y entrevistas (tenemos muy pocas personas en nuestra empresa, por lo que “llevamos muchos sombreros”, lo que significa que a veces entrevisto a desarrolladores de software e ingenieros de control de calidad). Iré pieza por pieza:

Reuniones

Hacemos sprints de una semana, por lo que hacemos la planificación del sprint temprano los lunes, y esto dura aproximadamente una hora.

A mediados de la semana, alguien se sentará con el gerente de producto y tal vez otro ingeniero, y revisaremos el trabajo atrasado de las tareas para ver si todavía estamos en camino y qué debe cambiar. Esto dura aproximadamente una hora.

Dedicamos aproximadamente una hora a la semana para tener una “reunión general de ingenieros”, donde nuestro equipo de 4 ingenieros se sienta y discute temas que no están directamente relacionados con el trabajo de la semana (esto es útil y nos da la oportunidad de discutir temas futuros, cosas que nos gustaría mejorar, etc.)

Pizarra (“arquitectura”)

Muy rara vez me siento y codifico sin tomarme el tiempo para “tomar decisiones” primero. Algunas cosas podemos sentarnos y codificar: por ejemplo, si necesitamos un nuevo componente de React front-end o algo así. Las decisiones más grandes toman algún tiempo (por ejemplo, estamos avanzando hacia el uso de un nuevo tipo de arquitectura de servidor, por lo que pasaré unas horas en la pizarra cada día, a veces solo, o le preguntaré a uno de los otros ingenieros para ayudarme).

Codificación

Esta es la parte donde me siento, me pongo los auriculares y abro mi editor. Yo diría que obtengo aproximadamente 3 horas continuas de codificación en un día de trabajo normal (un día de trabajo normal para mí es de 6 a 10 horas, dependiendo del día. A veces, si se necesita hacer mucho, podría trabajar voluntariamente por más tiempo). )

Revisión de código

Cuando haya codificado todas mis cosas y creo que está listo, enviaré una solicitud de extracción a uno de nuestros repositorios (actualmente privados) en Github y se lo haré saber a mi equipo. A veces, las solicitudes de extracción son tan simples que solo requiere una revisión rápida y se fusiona de inmediato.

Otras veces, los cambios son importantes, y requiere que alguien más se siente solo, conmigo o, a veces, con todo el equipo de ingeniería para discutir y decidir sobre cualquier cambio adicional que deba hacerse. A veces, la revisión puede tomar 10 minutos, pero a veces un RP estará abierto durante una semana.

Diverso

Almuerzo: como comida. Esto lleva aproximadamente media hora. A veces como mientras reviso el código de otra persona. A veces salgo de la oficina por una hora y voy a sentarme a comer al parque. Depende.

Entrevistas: nuestra organización es lo suficientemente pequeña en este punto donde no tenemos algún tipo de equipo de entrevistas dedicado. Yo y los otros ingenieros somos el equipo de entrevistas dedicado. Una vez a la semana más o menos, alguien podría hacer una pantalla de teléfono, y si tenemos candidatos para una sesión en persona, un ingeniero o el equipo completo podrían reservar un bloque de tiempo (unas pocas horas) para entrevistar al candidato. . Las entrevistas ocurren una vez cada 2 semanas más o menos.

Ping pong y baloncesto. Este se explica por sí mismo …

El desarrollo de software no es solo codificación. El aprendizaje también es esencial. Y hablando de código (o cualquier otra cosa).

Puedo aprender algo muy útil en algún seminario de investigación para el desarrollo que haré la próxima semana. A menudo tengo buenas ideas sobre el código (o depuración) cuando duermo y sueño.

Entonces, en mi humilde opinión, su pregunta podría no tener ningún sentido.