Recientemente me gradué con una licenciatura en Ingeniería Informática y he estado buscando trabajo. He tenido 4 pasantías en el pasado; han estado tanto en el gobierno como en el sector privado, tanto pequeños como grandes. Sin embargo, descubrí que el factor común es que lo colocan frente a una computadora y esperan que codifique durante esencialmente 8 horas seguidas. (Editar: cuando digo 'programa', me refiero a la programación y todo lo que implica de manera realista. No me senté y exploté un código elegante y funcional todo el día. Arreglé errores, busqué soluciones, me cansé y culpé al hardware, etc.)
Ahora, no soy un completo tonto. Sabía que Ingeniería Informática implicaría una gran cantidad de programación cuando me inscribí y que pasaría una parte importante de mi tiempo interactuando directamente con las computadoras. Sin embargo, sentarme y considerar los próximos 40 años de mi vida no sería nada más que esto me dejó un poco perturbado.
No odio la programación; En realidad me gusta bastante. He estado trabajando en proyectos personales mientras estoy desempleado y me siento motivado para codificar en general. Pero no puedo pasar más de 4 horas sin sentirme completamente quemado.
Me pregunto si hay algún trabajo en el que pueda aplicar mi conjunto de habilidades, sin estar atrapado trabajando en una sola cosa durante 8 horas todos los días. Me doy cuenta de que cualquier "otra cosa" que esté haciendo mientras no programe estará fuertemente ligada a la informática/programación (tutoría, investigación, escritura, etc.), lo cual está totalmente bien. Sólo necesito algo para dividir mis responsabilidades.
Estoy seguro de que existen este tipo de trabajos, sin embargo, no tengo la familiaridad con la industria para conocerlos.
EDITAR: Quería aclarar que no pasé 8 horas sacando código nuevo. Estaba trabajando en código preexistente en casi todos los casos. Así que, por supuesto, pasé una cantidad significativa de tiempo depurando y trabajando/aprendiendo el código que escribieron otras personas. Creo que es seguro asumir que, a menos que estés desarrollando tu propia aplicación o trabajando para una pequeña tienda, no crearás tu propio código nuevo desde el principio, y estoy de acuerdo con eso. Sin embargo, sentí que el 90% de mi día estaba sentado solo en mi cubo, mirando una ventana IDE. Esa es realmente la parte que siento que necesito que me separen.
Según lo que nos dices, parece que esos trabajos que requieren que codifiques durante varias horas seguidas pueden estar relacionados con el área de ingeniería de software de CS (aunque 8 horas seguidas suena un poco exagerado en mi humilde opinión).
Ese tipo de trabajos son más intensivos en código: se diseña un proyecto, se dividen y asignan las tareas, y luego es "solo" una cuestión de codificación y codificación hasta que se completan todas las tareas. Según el tamaño de la empresa y las prácticas que tengan a bordo, esto podría resultar en varias (4-6) horas de "codificación directa"... pero en mi experiencia, el tiempo de codificación efectivo puede ser mucho menor.
Siendo realistas, si uno no tuvo errores ni contratiempos, entonces si codificó durante 4 a 6 horas seguidas, seguramente el proyecto estará listo en muy poco tiempo ... pero hay muchos otros aspectos de la ingeniería de software además de codificar como un mono. . Cuando encuentra errores, debe detenerse y pensar cómo resolverlos, cuando comienza una nueva tarea, debe detenerse y pensar cómo proceder o consultar a sus compañeros... como podemos ver, hay mucho más en Ingeniería de Software que "simplemente codificación simple", y si pudiéramos codificar sin interrupciones ni contratiempos, esto funcionaría mejor.
Dicho esto, hay otras áreas de CS que requieren menos código. Uno de ellos, por ejemplo, es el área de Data Science .
En términos generales, en los trabajos relacionados con la ciencia de datos, dedica más tiempo a la parte de pensamiento y menos a la de codificación, ya que estos proyectos tienden a requerir menos líneas de código/repetitivo, pero cada línea tiende a ser más significativa que otros tipos de proyectos. Sin embargo, eso no significa que Data Science sea el paraíso para la gente de CS; codificar es fácil, saber qué codificar es la parte difícil , y la ciencia de datos tiene muchas partes difíciles de pensar (nota: actualmente estoy liderando proyectos de DS y de ingeniería de software)
Entonces, para resumir. Tal vez estaría más interesado en otros campos, como la ciencia de datos, o asumir más roles principales que requieren un poco menos de codificación y más administración. Sin embargo, a veces uno tiene que "escalar su camino" y aprender sus formas, antes de llegar a un trabajo de liderazgo / menos intensivo en código. Esperar que recién salido de la universidad me parezca un poco poco realista, pero no pierdas la esperanza todavía, ya que tienes varias otras opciones :)
Mi trabajo de software nominal (un título que he tenido: Ingeniero de software sénior) requiere que dedique aproximadamente el 85 % de mi tiempo a recopilar requisitos, averiguar qué módulos deberán actualizarse, tratar con "El negocio" (personas que no son de software) , etc. y alrededor del 15% (si es mucho) haciendo codificación real. Del tiempo de codificación, muy poco se dedica a teclear. La mayoría está tratando de descubrir qué hizo el código antes y cómo hacer que haga lo que necesitamos ahora con el menor impacto posible. Varios tipos de jefes en la oficina quieren que descargue la codificación a los jóvenes, pero me niego porque esa es la única parte que "disfruto". No obtengo un placer grande y duradero de la codificación, pero al menos no estoy tratando con los id10T en el negocio. (En cambio, mientras estoy codificando, maldigo a las personas "subóptimas" que trabajaron en los programas antes que yo).
La aplicación en la que trabajo es un sistema de punto de venta para un GRAN minorista (diría que hay un 35% de posibilidades de que lo haya usado). Algunas piezas son ANTIGUAS y datan de finales de la década de 1990. Las piezas son nuevas, no tienen más de unos meses. Todo ha sido escrito y trabajado por personas de diferentes habilidades. Los requisitos cambian y hay que hacer actualizaciones a todo tarde o temprano.
Cuente sus bendiciones. Cuando se trata de código nuevo, no es necesario que actualice el código mal escrito por un compañero de trabajo arrogante y abrasivo que es hostil con cualquiera que toque la perfección de su programa, incluso si está roto y no se puede molestar en arreglarlo. eso.
En respuesta a su pregunta, sí, tales trabajos existen pero tienden a ser de nivel superior. Supongo que sugeriría darle un año o dos hasta que obtenga un poco de experiencia en su currículum y ver si consigue un trabajo con más diseño, etc. y menos codificación directa.
En realidad, no es normal esperar que un ingeniero de software codifique durante 8 horas seguidas al día, porque el tiempo dedicado a codificar no es una medida precisa del progreso. Desafortunadamente, no es tu trabajo lo que está roto, es la cultura laboral en la que te encuentras.
Para un ingeniero de software, su día debe dividirse con cosas como:
Si esa lista no le suena a usted, entonces un cambio de rol/carrera sería bueno para usted.
Sólo puedo salir de mi experiencia. En la última década de trabajo como ingeniero web/software, descubrí que, en promedio, realizo 1 o 2 horas por día de codificación real, si eso es así. Por lo general, alrededor de 10-100 líneas de código, máx. El resto del día se dedica a investigar o descubrir los mejores enfoques para los problemas.
Ahora es difícil decir qué está mal (o no está mal) en tu trabajo. Podría ser que solo te estés obligando a escribir código todo el tiempo que puedas. ¿Podrías investigar, hacer reuniones, hablar con compañeros de equipo, etc.?
Escuché de trabajos de estilo de explotación en todos los campos de TI. Conocí a un animador que era realmente bueno en Maya y 3ds Max, tenía que trabajar de 12 a 15 horas por día haciendo animaciones para esta empresa que se subcontrata para dibujar para algunas empresas más grandes. Básicamente, se le dice que se siente en su escritorio y no puede tomar descansos para almorzar ni hacer otra cosa que no sea animar. A veces también se veía obligado a venir durante los fines de semana para trabajar, especialmente cuando tenían un plazo ajustado o tenían que tomar un descanso.
Observé que estas tiendas tienden a ser pequeñas y con frecuencia anuncian puestos vacantes (ya que anticipan una alta rotación). También tienen su espacio de oficina en un ambiente estilo fábrica con un gran espacio abierto para que todos se reúnan como un hangar o tiendas de piso abierto convertidas en una "oficina". Investigue cómo una empresa publica trabajos en línea. Si los ve subir la misma publicación cada semana o si alguna posición se publica aparentemente de forma indefinida, podría ser una señal de desarrollo de estilo de explotación. Echa un vistazo a sus calificaciones de Glassdoor también.
La gente ha mencionado puestos senior/gerenciales, pero como acabas de graduarte, voy a ofrecerte otra opción potencial que puedes explorar antes: ¡trabajar para una empresa nueva/pequeña! Solo puedo hablar desde mi propia experiencia con esto como desarrollador junior.
Trabajo para una empresa de software B2B que tiene solo una docena de empleados. Debido a que somos tan pequeños, la mayoría de la gente tiene que usar múltiples sombreros. Soy oficialmente un desarrollador de software, pero con frecuencia hago todo lo siguiente:
A veces puede ser frustrante si solo quiero codificar, pero todas las tareas de varias categorías necesitan atención, pero en general, tener tanta variedad de responsabilidades hace que los días sean más interesantes y me da una mejor idea de las posibles carreras profesionales en las que estoy y en las que no estoy interesado. .
Como desarrollador de software que tampoco disfruta escribiendo código sin pensar durante 8 horas al día, recomendaría una preferencia por las empresas más pequeñas. Las empresas más grandes tienden a tener roles más especializados, mientras que las más pequeñas a menudo requieren que los empleados desempeñen una variedad de funciones.
Habiendo dicho eso, literalmente, cualquier trabajo que te haga sentarte y escribir código durante 8 horas al día no es bueno. Si no dedica más tiempo a recopilar requisitos, hablar con las partes interesadas, pensar en los problemas, etc. que en la codificación real, probablemente lo esté haciendo mal. El mercado laboral es bastante bueno en este momento, no hay razón para que tengas que ser un mono del código.
Tenga en cuenta que algunos de los roles descritos pueden no considerarse CE estrictos, pero la experiencia previa en CE es al menos muy valiosa. A veces, la experiencia previa de programador "puro" es esencial y obtienes el rol descrito después de trabajar en un código durante al menos unos años, pero te referías a una perspectiva de más de 10 años.
La lista probablemente no esté completa. Además, a menudo los trabajos combinan más de uno de la lista (he visto que se ofrecen muchos roles BA/DEV y BA/PM), en cuyo caso sus tareas incluyen tareas de ambos roles (una participación puede no ser 50-50).
Este lo describiré a partir de mi experiencia, por lo que mi respuesta será más elaborada aquí.
Un rol de BA se trata de recopilar y documentar requisitos. Puede abarcar desde comprender el negocio como un todo, procesos de remodelación, etc. o centrarse solo en los requisitos para una aplicación específica. Puede recibir diferentes nombres en la descripción de un puesto de trabajo (Analista funcional, Analista de requisitos), pero todos están relacionados con el mismo campo.
La mayoría de las veces BA hace una de 3 cosas:
Además, este trabajo puede tener algo de programación (yo diría ~ 10 % en promedio con proyectos que van hasta un máximo del 50 %), gestión de proyectos (de nuevo ~ 10 % en promedio con hasta 30 % para un proyecto específico), pruebas, capacitación.
Como TA, eres responsable del control de calidad del proyecto. Interactúas más con el producto en sí que con el código fuente del producto. TA realiza una variedad de pruebas para intentar validar que la aplicación se comporte como debería (también si el usuario hace algo que no debería).
Dado que las pruebas están cada vez más automatizadas, este tipo de trabajo suele implicar una buena parte de la codificación (por ejemplo, para definir robots de prueba), pero la parte esencial está en otra parte.
Puede parecer un rol de desarrollo, pero se trata más de comprender el software. La principal área de responsabilidad de SA es definir cómo se deben construir las soluciones de software para estar alineadas con el enfoque estratégico. Hay dos tipos básicos de SA:
En términos generales, el primer tipo de SA entrega los detalles de la tarea a los monos del código ;-) mientras que el segundo tipo valida los requisitos proporcionados por los BA desde la perspectiva de la estrategia de TI.
El SA específico de la aplicación también suele codificar algo, pero esta codificación se limita a las áreas más difíciles e interesantes .
En este rol, será responsable de hacer que las cosas sucedan. Usted administra el presupuesto, el equipo, los plazos, etc. PM informa a la gerencia (patrocinadores) sobre el progreso de los proyectos.
Como PM, no se codifica a sí mismo, pero se asegura de que su equipo de proyecto haga el trabajo correcto.
Como gerente de TI, usted es responsable de su equipo (pero no es un equipo de proyecto como PM). Manejará cosas como nuevas contrataciones, promociones de personas (pero también despedirlos si es necesario), escalaciones, etc. Dependiendo del equipo y el tamaño de la empresa, un gerente también puede hacer parcialmente el mismo trabajo que su equipo, pero por lo general no será más del 50% del tiempo. Por supuesto, un gerente puede ser para cualquiera de los equipos, por lo que puede ser gerente de desarrollo, gerente de BA, etc.
Aparte de todas las opciones ya mencionadas, también hay:
Investigar. Como en la gente que escribe artículos. Normalmente haces un máster y/o un doctorado, un posdoctorado, etc. Principalmente en universidades, instituciones de investigación y empresas muy grandes.
Enseñando. En universidades, escuelas, etc.
Escritura (por ejemplo, libros, artículos). Entiendo que es muy, muy , difícil ganarse la vida solo escribiendo.
Escritura técnica. Especificaciones, manuales de usuario, documentación del software.
Esto depende de lo que defina como programación e interacción con las computadoras.
Estoy de acuerdo contigo en que la idea de sentarme en la oficina 5 días a la semana y producir aplicaciones comerciales o basadas en la web por el resto de mi vida suena como una destrucción del alma. Pero esa no es la única opción para ti.
Por ejemplo, cualquier cosa en estos días que involucre manufactura, industria pesada o envío involucrará computadoras, y las computadoras requieren que las personas las programen. Y no hay nada como escribir código que controle algo grande y físico, y siempre hay una planta nueva y diferente que se está construyendo en alguna parte.
Por ejemplo, en este momento estoy bloqueando el código de una de esas grúas que se encuentra en un puerto de contenedores y transfiere contenedores hacia/desde barcos. En el pasado, también programé plantas siderúrgicas, papeleras, de aluminio, plantas de tratamiento de aguas residuales, fabricación de pilas AA e incluso una lechería. Y en cada una de estas áreas tengo un diseño balanceado, codificación e ir al sitio para que todo funcione.
Entonces, si mira a su alrededor, encontrará una variedad infinita de uso de computadoras en el mundo, lo que lleva a una posibilidad infinita de opciones de carrera.
Finalmente, la programación y las computadoras no son estáticas. A lo largo de su carrera, verá que todo cambia a medida que avanza la tecnología, por lo que estará aprendiendo continuamente para mantenerse relevante.
Es difícil codificar durante más de 6 horas seguidas en un solo día laboral. ~4 horas es un poco menos que el promedio que esperaría en un día laboral típico, pero YMMV. Lo más importante es lo que entregas, no cuántas horas le das a tu trasero la oportunidad de hacer una huella*.
Dicho esto, es posible que la consultoría sea más adecuada, ya que implica cierto contacto con el cliente y posiblemente viajes. Todavía tendría que trabajar duro (probablemente aún más), pero tiene un ritmo diferente al camino del código mono en el que se encuentra actualmente.
Otra opción es convertirse en gerente. Esto está en su ruta de promoción para la mayoría de las empresas y es básicamente una programación a escala. Actualmente administra un desarrollador (usted mismo), un administrador administra varios desarrolladores. Menos programación dependiendo de la compañía, y tendrás que lidiar con tus compañeros/jóvenes.
Si bien siempre puede tener un golpe de suerte, generalmente se espera que un nuevo comienzo haga un poco de trabajo duro durante algunos años antes de que se abra cualquiera de los anteriores. Pero nuevamente, el mundo no es inmutable y su millaje variará.
* Déjame descifrar eso: puedes perder el tiempo todo lo que quieras siempre y cuando nadie se dé cuenta de que estás perdiendo el tiempo. La mejor manera de hacerlo es entregar lo que se espera de usted.
Si está literalmente escribiendo código durante 8 horas al día, probablemente lo esté haciendo mal. Primero, debe tener mucha suerte, trabajando en un proyecto de campo nuevo (es decir, sin código heredado para interactuar en absoluto). Me encantaría tener cerca de 8 horas de codificación por día. En segundo lugar, parece que no está escribiendo ninguna prueba de unidad, o habría mencionado la depuración y la refactorización y que el ciclo de codificación se dividiera en fases de compilación/ejecución/prueba. En tercer lugar, debe ser una tienda muy pequeña, si no tiene que consultar con sus compañeros de equipo sobre las interacciones entre su código y el código en el que están trabajando otras personas. En cuarto lugar, es bastante sorprendente que alguien pueda darte una especificación y que puedas comenzar a escribir código inmediatamente y seguir escribiendo código durante 8 horas, día tras día.
Los ingenieros de software reales dedican mucho tiempo A) a averiguar qué es lo que se debe construir (recopilación de requisitos), B) comprender cómo encaja lo nuevo con lo antiguo/existente, C) comunicarse con varias partes interesadas para asegurarse de que haya no hay conflictos en el diseño/API/etc., D) investigar soluciones existentes, mejores prácticas, bibliotecas u otros componentes que pueda reutilizar, etc.
Ahora, si esto no se parece en nada a su experiencia, hay una razón bastante obvia: su experiencia fueron todas las pasantías .. Si bien una pasantía hace un buen trabajo al exponerlo a las herramientas y personas con las que podría trabajar, un pasante necesariamente tendrá que trabajar en un proyecto que se puede completar en 10 a 12 semanas, por lo general. Eso a menudo requiere un tipo de proyecto poco natural que los ingenieros de tiempo completo no obtienen. En particular, suele excluir una de las fases más importantes de la ingeniería: el diseño. Como pasante, generalmente se le entregará un problema y un diseño, para que tenga algo que mostrar por sí mismo al final de su estadía. Como ingeniero de tiempo completo, eventualmente se espera que usted mismo diseñe la solución. Incluso como principiante, se espera que tenga un ojo crítico y haga preguntas sobre lo que se le pide que implemente.
Por ahora, diría que deberías relajarte . Es casi imposible encontrar un puesto de ingeniería de software de tiempo completo que implique 8 horas completas de codificación por día, durante semanas seguidas. En cualquier entrevista que obtenga, solo pregúntele al entrevistador cuántas horas al día programan, y le apuesto un café a que la gran mayoría de ellos se quejará de las pocas horas que programan y cuánto tiempo dedican. haciendo todas las demás tareas de ingeniería de software (corregir errores, investigar errores, lidiar con herramientas inestables, tratar con compañeros de trabajo inestables, etc.).
Trabaja para una pequeña startup de 5 a 15 personas.
Terminará haciendo todo tipo de otras funciones comerciales. Gestión de proyectos, captura de requisitos, diseño, pruebas, administración de sistemas, ingeniería de experiencia de usuario, trato con clientes, reuniones de estrategia. Tendrás que hacer lo que sea necesario ahora mismo.
También estará muy bien posicionado para dejar el desarrollo de software y asumir otros roles en la empresa. Así que elige una industria/sector que te guste.
Intervendré con una perspectiva diferente: si realmente quieres hacer algo más que programar, entonces la mejor manera de hacerlo es desarrollar habilidades secundarias en otras áreas. Si puede ser muy bueno en algo que no sea la programación y también tiene la capacidad de programar, entonces su utilidad se dispara de inmediato.
Para mí, como ejemplo, mi experiencia es en ingeniería física, ingeniería eléctrica y ciencia de los materiales. No estudié programación en la universidad, pero soy autodidacta y he estado programando, como parte de mi trabajo, profesionalmente durante aproximadamente 17 años. No es, por supuesto, todo mi trabajo.
En este momento trabajo en automatización industrial en una empresa mediana, por lo que el trabajo también incluye mucho hardware (PLC, robots, motores, control de movimiento, sensores, detectores y algunas cosas esotéricas de física). Hay una combinación de trabajo práctico, diseño de sistemas, diseño mecánico y desarrollo de software de automatización, HMI, etc.
Conozco a muchos otros que también trabajan en diferentes campos en una posición similar. El punto realmente crítico es que si desea hacer una variedad de cosas en su trabajo, debe concentrarse en desarrollar competencia en una variedad de cosas .
Las otras respuestas son correctas en el sentido de que es probable que no pase la mayor parte de su tiempo codificando, incluso en una posición de desarrollo de software. He sido desarrollador durante aproximadamente 8 años y puedo decirles que, aunque disfruto estar frente a la computadora más que la mayoría de las personas, generalmente no soy capaz de concentrarme durante 8 horas de una sola vez. Si gana la confianza de su empleador, los trabajos de desarrollo de software tienden a tener un horario más laxo porque saben que usted hace su trabajo. Algunos días trabajo menos o más de 8 horas dependiendo de la carga de trabajo y cuánto disfruto la tarea, pero tiendo a trabajar quizás 3-4 horas por la mañana antes de almorzar y luego tomar una siesta. Después de eso puedo trabajar mucho mejor que si siguiera trabajando sin una siesta. Dormir bien,
La mejor parte de la programación de puestos es que tiendes a ser medido por tu productividad, así que descubre cómo maximizar eso en lugar de sentarte durante 8 horas frente a la computadora.
Hay una serie de otros trabajos que alguien con experiencia en informática puede hacer. A menudo implican algo de programación, pero no es la totalidad del trabajo.
Pero incluso como ingeniero de software, debería haber otras actividades que interrumpan su día:
Sí hay.
Según su descripción, suena como alguien a quien le gusta el rigor académico de la codificación, pero descubre que existe un tedio intenso en la creación de soluciones. Posiblemente también suene como si quisiera más interacción humana: determinar el problema, crear soluciones (no construirlas), etc.
Bueno, hay consultoría.
Si ese es el caso, entonces hay consultoría.
Por lo general, la gente ve a los consultores de gestión como estirados y aburridos, y muy trabajadores. Esto es cierto, pero tenga en cuenta que también ganan considerablemente más, y los proyectos generalmente duran de 1 a 3 meses, por lo que, si bien puede obtener un proyecto aburrido, también puede obtener uno realmente interesante. También trabajas con los más brillantes y ambiciosos. Podrás flexionar ese músculo académico e investigar, pero sin el tedio de escribir código. También trabajas con personas.
Si desea obtener más codificación, la mayoría de las grandes consultorías ahora también tienen un brazo técnico. Obviamente está Accenture, pero McKinsey también tiene una división de consultoría tecnológica.
No caiga en la trampa de "un conjunto de habilidades de codificación significa escribir código".
Además, no caiga en la trampa de "un conjunto de habilidades de codificación significa escribir código". Como parece, Dios mío, todos han notado aquí, estrictamente hablando, la codificación nunca sucede 8 horas al día. Hay aclaraciones, investigación, consideración de casos extremos y determinación de soluciones óptimas, además de la "escritura de código" y la "depuración" más basadas en CS.
Podrías pensar que codificar es "codificar". Honestamente no lo es. "Codificar" es simplemente usar su capacidad intelectual de una manera establecida, pero esa manera también se puede usar para resolver otros problemas . El hecho de que esté capacitado para aclarar, cuestionar, investigar y determinar soluciones óptimas es una bendición para todas las demás empresas e industrias. Si está ayudando a una empresa de calzado a determinar el diseño óptimo de la fábrica, o a una empresa de muebles a determinar a qué mercado expandirse, o si vale la pena invertir en una determinada empresa de tecnología, todavía está haciendo todo lo anterior (aparte de escribir código). ¡Son probablemente unas 5 horas de tu día!
Ah, otras opciones
OH. Y si se lo pregunta, el capital de riesgo necesita personas con esas habilidades. Lo mismo ocurre con el capital privado y el comercio. Además, gestión forestal, think tanks sobre calentamiento global y gestión hospitalaria.
Finalmente
Finalmente, debería considerar seriamente dejar atrás TI si siente que no le gusta trabajar 8 horas por su cuenta todo el día. Hay investigaciones significativas que muestran que la persona encuentra el trabajo. Por lo tanto, en ventas, normalmente encontrará personas que son naturalmente entusiastas y disfrutan trabajar con personas (y competitivas). En TI, encontrará lo contrario: aversión al riesgo, tímido, no le gusta interactuar con la gente, prefiere trabajar solo.
Ahora bien , esto es una generalización , seguro. Pero lo que también significa es que si eres extrovertido por naturaleza o te gusta trabajar con personas, tendrás dificultades para ser feliz en TI, porque muy pocas personas compartirán esas cualidades y el trabajo no está diseñado para ese tipo de personalidad.
Cualquier proyecto no trivial requiere más de una persona trabajando en él (simplemente para hacerlo más rápido) y esto solo significa que no puede pasar todo el día codificando, ya que necesita comunicarse con sus compañeros de equipo. Reuniones, debates, documentación para asegurarse de que todos estén de acuerdo, etc.
Además, en mi experiencia, la mayoría de los esfuerzos de codificación no están limitados por la rapidez con la que escribes, sino por la rapidez con la que piensas, y por lo general necesitas descansos.
Dicho todo esto, la optimización individual más eficiente de su tiempo que puede hacer es aprender a escribir al tacto de memoria. No tanto al programar (ya que hay muchos símbolos difíciles de alcanzar), pero ayuda mucho al escribir prosa, ser documentación o notas de reuniones o simplemente sus correos electrónicos diarios.
Hombre enmascarado