¿Alguna vez los ingenieros de software se cansan de codificar durante más de 8 horas todos los días? ¿No se vuelve aburrido en algún momento? ¿Cómo lo manejan?

Veamos … Podría ser aburrido hacer lo que amas más de 8 horas todos los días. Pero, ¿no es aún más aburrido hacer algo que solo puedes tolerar más de 8 horas todos los días?

Yo código a menudo 12 horas todos los días, durante 5 días a la semana.

Y generalmente no siento que esto me esté evitando algo más interesante en otros lugares.

¡Me hace pensar que estoy en la cima de mi carrera!

Porque cuando regreso a casa, mi hermano, que es abogado, aún no regresó a casa del trabajo.

Parece que todo el mundo muele esta cosa de 9-5.

Aquí hay 5 consejos que uso para mantenerme en la cima de mi trabajo y nunca sentirme quemado.

1. Planifica tu día. Antes de terminar mi día, generalmente escribo un plan detallado de lo que haré mañana. Esto garantiza que cuando llegue a mi escritorio la próxima vez, mi mente ya está configurada y preparada para las tareas y está lista para comenzar.
2. Escribe un prototipo. Una vez que he decidido qué tarea exactamente debo hacer, tomo algún tiempo y descubro la solución completa. Después de esto , lo anoto de manera visual . Yo prototipo el código, dibuja diagramas de flujo, representa flujo de lógica y toma nota de diferentes casos de prueba. Esto liberará mi cerebro para enfocarse en el código una vez que empiece a codificar porque ya no tengo que preocuparme por la lógica
3. Escribe el código Comencé diciendo que codifico por 12 horas pero ahora sabes que la codificación viene como la tercera o la cuarta cosa que tengo en mis manos. Una vez que lo tengo todo en papel, cuál es la tarea, el código para escribir y la tecnología a usar, el flujo de código en mi cerebro es casi una segunda naturaleza . De vez en cuando me detengo para hacer referencia o documentación y luego me vuelvo a subir al caballo.
4. Escribir pruebas unitarias Lo que a menudo hace que la codificación sea innecesariamente difícil para mí es cuando se rompe una característica y no sé exactamente qué es lo que se dispara. O quiero implementar una nueva característica, pero tengo que asegurarme de que no rompa nada más. Resuelvo esto escribiendo pruebas unitarias para mis aplicaciones . Entonces, cuando regrese al código, no siento que deba saber qué hay en esa montaña de código. Solo hago lo que pasa hoy. Escriba las pruebas unitarias antes de cerrar la computadora e irse a casa después de codificar la característica o ¡nunca la escribirá!
5. Tomo descansos de 10 minutos cada una hora. Para mantener mi mente fresca, me gusta lo que hago y no me siento abrumada, hago varios descansos entre mi codificación. Entre 5 y 10 minutos durante los cuales camino hacia la puerta o tomo un trago de agua limpia del dispensador. Intentando enfocarte en otra cosa mientras tanto. No tengo que dirigirme a ninguna parte en particular, solo me aseguro de estar lejos de mi escritorio, pero no más de 5- 10 minutos.

Cuando hago esto, no me siento abrumado con mi trabajo.

Pero claro, tengo que cansarme porque hay pocas horas en que un ser humano puede estar atento a una cosa antes de que su atención anhele otra cosa y se sienta cansado de hacer la tarea actual.

Puede que no sea un problema particular con los ingenieros de software, probablemente con todos los demás.

Una vez que las rutinas diarias comienzan a repetirse, te acostumbras.

Comienzas a sentirte menos emocionado.

Pero hay formas de engañar a tu cerebro y mantener su atención de primera clase.

¡Aclamaciones!

Nadie codifica durante 8 horas todos los días.

La jornada laboral de 8 horas es una gran mentira que se hereda de la revolución industrial y los trabajos de mano de obra.

Todos saben que solo se puede mantener alrededor de 4-6 horas de concentración al día. y si lo haces, día tras día, 4 horas es la figura sostenible.

Resulta ser la cantidad de tiempo que los músicos profesionales entrenan todos los días; saben que ir por encima de esto está disminuyendo los retornos porque los agota para tratar de mantener ese nivel de concentración más allá de esa duración.

Entonces, todos saben que solo hay 4-6 horas de trabajo real en el día, pero Dios no permita que pasemos del modelo de 40 horas a la semana. Todos esquivan y toman descansos y caras de libros y demás, nadie habla de eso abiertamente, y el mundo sigue corriendo.

Además, reuniones, correo electrónico, chats grupales, todo eso, eso llena el resto del día …

Estarás bien, no te preocupes.

Bueno, tan bien como puedes estar usando Java, pero fino.

Absolutamente todo sobre mi trabajo fue abrumador los primeros días. Está bien, todos han estado allí. Sus nuevos colegas no esperan demasiado de usted desde el primer día. Todos ellos tuvieron los primeros días también. La codificación en el entorno de trabajo no estructurado es más difícil que la tarea CS porque no sabes cuándo terminaste. Esta fase pasa muy rápido, y empiezas a sentir que perteneces allí.

Fred (“Mythical Man Month”) Brooks midió la cantidad de tiempo que los desarrolladores gastan en escribir el código, y esto representó el 19% del tiempo. Usted hace muchas otras cosas además de escribir el código. Claro, en algunos días, puede escribir código todo el día. Lo más probable es que mire hacia arriba para darse cuenta de que está oscuro afuera de las ventanas de la oficina y se pregunte dónde fue el día. Te levantarás rígido y adolorido por sentarte en el mismo lugar durante horas, y deambular a casa. La codificación es tan absorbente algunos días.

Algunos días el código es desafiante, o te sientes desmotivado (y todos tenemos esos días), o estás mirando un cursor parpadeante en una pantalla en blanco, sin saber por dónde empezar. Hay muchas cosas para hacer en esos días. Termine esa documentación, escriba ese informe de estado, vuelva a armar su segunda computadora, limpie los anillos de café de su escritorio.

O ve a una reunión. ¿Crees que te cansarás de codificar? Espera hasta que descubras las reuniones. Reuniones de personal interminables sin un propósito aparente. Reuniones interminables de entrenamiento sobre cosas que ya sabes. Reuniones en las que Alice y Bob empiezan a discutir sobre algo inútil, o donde Charlie no puede ver que se calle, y le ofrecerías tu alma a Satanás solo por la oportunidad de volver a tu escritorio y código. Mejores organizaciones consideran las reuniones como la exposición a la radiación y tratan de limitar su dosis acumulada.

Le costará trabajo venir algunos días y es difícil dejarlo en otros. Hay aproximadamente 2,000 lunes en una carrera laboral promedio. Pero la codificación es crear. Está destilando conocimiento en forma ejecutable con el poder de tu mente solo. La codificación será su recompensa por asistir a reuniones, por vivir en el interior, por estar sentado todo el día. No te preocupes por el código.

“Codificando por más de 8 horas por día” … Querido Dios, lo haces sonar como si estuvieras poniendo ladrillos o lavando platos todo el día.

La ingeniería de software no codifica. La codificación es simplemente la parte más aburrida: traducir una idea / solución / especificación / diseño en un código.

En realidad, la ingeniería de software casi nunca es aburrida. Si lo haces bien, casi siempre hay un desafío involucrado. Inicialmente, está aprendiendo a trabajar con idiomas, tecnologías, bibliotecas y el dominio del problema del proyecto en el que está trabajando. Hasta que tengas un buen conocimiento de esas cosas, deberías y probablemente estarás trabajando en problemas más simples, y eso será un desafío suficiente.

Una vez que haya pasado la etapa de aprendizaje y las tareas sencillas ya no representen un desafío, simplemente cambie a una velocidad superior: comience no solo a implementar las ideas y especificaciones de otras personas, ¡cree las suyas propias! Piensa en cómo hacer algo de la mejor manera posible. Cómo hacer que su solución sea la más útil, la más flexible, la más escalable; cómo elegir las mejores herramientas para trabajar; cómo construir la mejor arquitectura; cómo hacer que su código sea más legible y más fácil de construir y mantener; cómo hacer la mejor experiencia de usuario; cómo hacer que el producto se venda mejor, generar más ingresos, etc. etc. Hay una lista interminable de desafíos y oportunidades para la creatividad que casi siempre están disponibles para abordar, si así lo desea. Nadie le dirá a un ingeniero creativo y competente que se limite a la codificación aburrida básica.

Cada pieza de código que vas a escribir va a ser completamente nueva y única, y va a tener una historia diferente. Si no es único, entonces lo estás haciendo mal. Por ejemplo, si obtiene una tarea para codificar 100 formularios de ingreso de datos y siente que es un trabajo aburrido y laborioso, no lo haga así. En su lugar, cree un marco para la generación automatizada de formularios (o busque y use una solución de código abierto). Resolver este tipo de problema es mucho más interesante, más desafiante y más productivo a largo plazo. Si obtienes una tarea tediosa y repetitiva, piensa: “¿Qué tipo de solución puedo construir, para que nunca tenga que hacer manualmente esta tediosa tarea?” Pensar a un nivel más alto es mucho más divertido y también te convierte en un mejor ingeniero.

En mi carrera de más de 20 años, casi nunca sentí que mi trabajo fuera tedioso o aburrido. Extenuante sí, pero es agotador porque estoy resolviendo problemas muy difíciles y desafiantes, no por “8 horas de codificación”. Y los problemas difíciles, una vez resueltos, dan una gran cantidad de satisfacción, por lo que vale la pena.

Si agotas los desafíos disponibles en un trabajo (lo que ocurre con frecuencia después de 1 a 3 años), cambia de proyecto, cambia de trabajo, crea tu propia empresa e intenta que funcione. Si lo haces funcionar, intenta construir un negocio de mil millones de dólares y cambiar el mundo. ¿Cómo es eso de una buena lista de desafíos divertidos que puedes perseguir como ingeniero de software? 🙂 Sin embargo, debes comenzar en algún lado, y hacer algunos trabajos con Java parece ser un buen lugar para empezar.

He estado en los campos de software e ingeniería de redes durante más de 36 años y debo decirle que cada día es diferente. Experimentarás largos períodos de solo escribir códigos, pero tu carga de trabajo consistirá principalmente en pensar. Eres un think tank; leer y comprender especificaciones, diseño, uso, audiencia (la vista de uso prevista de los usuarios que maximiza su productividad / comprensión / intuición), rendimiento, algoritmo de diseño antes de codificarlos, esquema (s) de base de datos, cuellos de botella de red, estructura de codificación. Luego, hay API para descubrir y cómo aquellos con interfaz con lo que estás diseñando. Mantenibilidad de lo que está codificando, funciones reutilizables para mejorar la productividad en proyectos futuros. Proporcionar ganchos para que los ingenieros de automatización de SQA automaticen la prueba de su invención. Toda la carga / estrés, IU, funcional, casos de borde, datos de inicialización, mantenimiento continuo, huella, dependencias de terceros, dependencias de hardware, … Podría seguir y seguir, diseñar y programar reuniones de revisión, reuniones de personal, etc. … Es una experiencia increíble estar involucrado en un proyecto de 3 años con un equipo de 30 a 50 ingenieros de redes o software, nunca pasa de moda porque a menudo se descubre algo nuevo para aprender, investigar y comprender, incluso en el mismo proyecto. Si te encanta la codificación (diseño y escritura de código), es posible que te distraigas por todas estas otras cosas que te roban tiempo creando tu idea original. Así es como me sentía a veces. Cuando finalmente ve los resultados de su pensamiento / investigación / análisis / imaginación / inteligencia / lógica masiva corriendo en las manos de millones de personas que nunca conocerá, y sabiendo de alguna manera que ayudó y tocó sus vidas de alguna manera, usted siente ese gran sentimiento que hace que todos y cada uno de los pensamientos que has tenido que atravesar valen la pena.

Esto era algo que me preocupaba antes de tener una experiencia de tiempo completo. Lo tomé como una buena señal de que podía pasar horas enteras en los laboratorios, trabajando en tareas, proyectos y depuraciones, y me sentía como si estuviera resolviendo un rompecabezas, en lugar de frustrante o aburrido. Sin embargo, fue solo después de completar mi primera pasantía a tiempo completo que tuve la evidencia experiencial de que podía hacer el trabajo a tiempo completo.

Lo que aprendí a través de la experiencia reforzó lo que aprendí en la escuela. La ingeniería de software es mucho más que escribir código. Cuanto más grande es el proyecto, más verdadero es esto.

Una de las cosas más importantes que aprendí en esa primera pasantía fue que la codificación no ocurre cuando estás escribiendo el código. La codificación ocurre cuando resuelves el problema. Este fue mi primer momento de fluidez en la programación, cuando después de un par de intentos para resolver el problema codifiqué sobre la marcha y tuve problemas en mi código, di un paso atrás y dediqué un momento a pensar en el problema, resuelto en mi mente, y luego escribió el código, que posteriormente funcionó perfectamente.

Otra lección fue algo que aprendí temprano en mi primer puesto de tiempo completo. No entendía por qué a veces me sentía menos productivo que otros. Encontré una publicación de blog clásica por Joel en Software, que me ayudó a entender que esas fases eran normales.

También aprenderá que el software no se crea en el vacío. Esperamos que su programa lo haya preparado al incluir muchos proyectos grupales. Desarrollar software en proyectos más grandes requiere mucha gente y, por lo tanto, implica mucho trabajo con otras personas.

Finalmente, aprendes que solo tú puedes cuidarte. Tienes que aprender, en cualquier trabajo, en cualquier campo, lo que necesitas para ser más productivo. ¿Cuál es su proporción de ruptura ideal? ¿Cuánto necesitas dormir? Permanecer hidratado, alimentado, con cafeína, interrupciones de movimiento, etc. Esas son todas su responsabilidad, pero es posible que encuentre que algunas compañías son más propensas a capacitarlo para satisfacer sus propias necesidades de equilibrio que otras.

¡Buena suerte y disfruta de la experiencia de aprendizaje!

Nadie escribe código en realidad durante 8 horas al día. La mayor parte del día se dedica a hacer otras cosas relacionadas con el código que se escribe o el proyecto en general. Si me preguntas, este es el aspecto más gratificante de ser un ingeniero de software profesional. Hay tantas profesiones en el mundo que son monótonas y repetitivas: algunos puestos de trabajo de contabilidad, ventas, oficina, atención al cliente, etc.

El software de escritura es diferente todos los días. Algunos días entras y no tienes nada que hacer. Estos son los días en que se abordan ciertos componentes en el código que o bien se intentó refaccionar u optimizar, pero que no han tenido tiempo libre. Algunos días tienen que ver con la investigación y el diseño, ya sea leyendo la documentación de API, características, creación de prototipos o aprendiendo a usar una biblioteca o componente. Algunos días puede estar trabajando estrechamente con equipos de apoyo en el diagnóstico de problemas de los clientes en producción, y por supuesto siempre hay revisiones y reuniones de códigos para analizar la importancia de lo que todos están trabajando y solicitar opiniones del equipo sobre cómo o qué debe hacerse. siguiente.

En cuanto a enterrar su cara en el código, el código se lee con más frecuencia de lo que está escrito. En muchos casos, estás trabajando en bases de códigos existentes y no importa la frecuencia con la que hayas trabajado con un componente, siempre tienes que volver atrás y estudiar un cierto aspecto diferente de él para poder realizar tu tarea. En muchos casos, puede estar escribiendo código adicional solo para ayudar a solucionar un problema (mensajes de registro, lógica para forzar el comportamiento de ciertos sistemas, volcar archivos y manipular datos manualmente en tiempo de ejecución).

Si no le gusta lo que hace, cualquier cosa se volvería tediosa si tiene que hacerlo las 8 horas del día. Sin embargo, es raro que encuentres a alguien que realmente sobresalga en algo que odia y puede mantenerlo por un tiempo prolongado, esprints cortos quizás, pero no toda una carrera. Pero incluso los ingenieros de software más apasionados y eficientes no pasan todos los días la codificación diaria durante 8 horas seguidas.

Piense en la ingeniería de software como la construcción de una casa. El proceso tiene una serie de pasos especializados. Estos van desde el diseño, el edificio, el mobiliario y la decoración. Los constructores, plomeros, electricistas, decoradores, pintores y carpinteros carpinteros no comienzan inmediatamente a balancear martillos y pintar paredes. Primero necesitan planes de los arquitectos y diseñadores. Antes de cortar un trozo de madera, primero deben medir dos veces, como dice el refrán.

La ingeniería de software tiene las mismas preocupaciones, pero la misma persona es responsable del diseño, la planificación y la construcción. Como resultado, es posible que tenga ingenieros de software que programen durante 8 horas seguidas, incluso más a veces. Pero ese no es su trabajo completo. También necesitan pasar mucho tiempo antes y durante el proceso de codificación, planificando lo que hacen y decidiendo qué hacer a continuación.

Dicho esto, algunos ingenieros comienzan a programar primero y descubren a dónde van mientras codifican. Pero generalmente usan este método porque prefieren codificar para pensar en la codificación. En este caso, probablemente prefieran codificar todo el día todos los días.

En última instancia, la ingeniería de software se trata de resolver problemas en lugar de codificación. Algunos prefieren pensar en el problema antes de abordarlo, mientras que otros prefieren trabajar en los problemas mientras codifican. Lo que une a estos dos tipos de ingenieros es que les apasiona resolver problemas y con gusto dedicarían todo su día laboral a eso todos los días.

Esta publicación contiene buena información sobre cómo probar a los ingenieros de software para ver si son buenos solucionadores de problemas.

En realidad, ingresar código con un teclado es solo una parte del trabajo. Una de las partes más mundanas, realmente.

A pesar de lo que mucha gente piensa, la ingeniería de software es un proceso creativo , que simplemente es posible gracias al conocimiento técnico . No solo estoy instruyendo a una computadora qué hacer; Estoy construyendo algo. Llevando algo de un concepto, a un prototipo funcional, a una solución funcional completamente pulida y concreta.

Eso es emocionante. ¿Cuántas personas pueden ir a trabajar y hacer eso todos los días?

Esta es probablemente la pregunta más relevante para mí que he intentado responder.

Después de haber trabajado en el departamento de recreación de mi ciudad durante toda mi vida adulta (de 15 a 25), me volví extremadamente sociable y disfruté cada minuto de mi increíble trabajo. Pero cuando llegó el momento de pasar a la ingeniería, lo que he estado haciendo solo y en la escuela desde las 12, no pensé que podría manejar la temida vida del cubículo.

Las primeras semanas en el cubículo: Infierno. Sentí ganas de tirar la toalla. Mi departamento de informática me regaló un ThinkPad en mal estado, mi escritorio era una gran placa de vacío, las luces eran brillantes y la señora que estaba a mi lado parecía tener EPOC (tosía todo el día). No creo que pueda codificar más de 30 minutos a la vez, especialmente porque mi viaje de 2 horas a Long Beach, CA fue mentalmente agotador.

Un mes en el cubículo: Cambiado en el ThinkPad para Macbook Pro, reconstruí mi viejo escritorio para usarlo como estación de trabajo, compré unos excelentes auriculares de MonoPrice y me mudé al Condado de Orange. ¡Las cosas fueron mejores! Finalmente pude codificar durante varias horas al día. Afortunadamente, mi gerente fue increíble y me permitió manejar la transición a mi propio ritmo.

Pocos meses en el cubículo: el cubículo se convirtió en un problema cuando descubrí las cuerdas. Podría codificar unas 4-5 horas diarias. En este punto, comencé a trabajar a distancia algunos días, tomar descansos cuando los necesito y hacer otras cosas para mantenerme en buena forma. (Nada más asume un mayor costo en su productividad que su salud, he encontrado).

No muchos días puedo hacer 8 horas de codificación directa, y creo que la mayoría estaría de acuerdo. Al haber encontrado mi propio equilibrio, me he vuelto muy productivo y he superado las fechas límites con Mike Tyson como la velocidad.

Mis mejores decisiones fueron pedir el Macbook Pro, aprender Vim y seguir con IntelliJ, me ayudan a trabajar con gran concentración y productividad.

¡Buena suerte y no dudes en PM!

De hecho, hay algunos que codifican más de 8 horas por día. Terminan su trabajo y codifican más para proyectos personales.

Si te gusta codificar como yo, me parece que en realidad me da más energía. Puede ser emocionante cuando resuelves problemas interesantes y haces cosas nuevas que no se han hecho.

Solía ​​trabajar en la venta minorista más joven y descubrí que más de 8 horas de tratar con personas realmente me cansan más de 8 horas de codificación. La gente puede ser francamente desagradable sin ninguna razón más que el hecho de que pueden hacerlo. Para mantener mi trabajo, me veo obligado a aceptar el mantra “el cliente siempre tiene la razón”, por lo que a veces me disculpo por sus fallas para hacerlos felices. Sip. tratar con humanos puede ser ilógico e impredecible. El estrés puede desgastarte.

La codificación tiene mucho estrés pero es más física que emocional. Depende de cuánto esfuerzo quieras poner en él. Si eres un buen ingeniero de software, probablemente resolverás la mayoría de los problemas fácilmente. Si desea generar un código que simplemente funcione, puede hacerlo sin problemas. Ya puede hacer lo que el 97% no puede hacer o desea hacer de todos modos. Eso es bastante bueno para mí. Si quieres trabajar duro para sobresalir en tu carrera, también puedes. No hay impedimento para implementar una nueva visión o solución. Eso depende de cuánta energía tienes. Cuando creces, ralentizas un poco. Hay límites 8 horas de codificación directa con cafeína es difícil a 40 algo. Pero con la experiencia, comete muchos menos errores, se concentra más en lo que es importante, pasa más tiempo planificando y elaborando estrategias, lo que reduce el tiempo de codificación. También aprende a confiar en los demás y no a hacer todo usted mismo. Cuando era más joven, pasaba mucho tiempo tratando de resolver cómo resolver cada problema o implementar cada algoritmo o hacer que el código fuera “perfecto” para demostrarle al mundo lo bueno que era. Trabajar de manera inteligente y no dura puede hacer 8 horas más placenteras.

Ahora-a-días estoy haciendo más de 8 horas de codificación efectiva en mi proyecto actual. Aún así creo que necesito más tiempo para hacer eso. A veces llego a la oficina a las 10 am y me voy después de las 11 pm (trabajo en una MNC india). Ningún cuerpo me obliga a quedarme hasta tarde. ¿Por qué me quedo hasta tarde? Solo para obtener la santificación de lograr algo. Digamos que estoy atrapado en un problema durante 4-5 horas, cuando se resuelve por ese minuto me siento la persona más feliz del mundo. Así que es como un juego, lo disfruto. El día en que salgo de la oficina sin resolver el problema en particular en el que me he quedado atrapado, mi cerebro parece estar bloqueado. No puedo pensar en otra cosa para esa noche. Incluso yo veo esa cosa en mis sueños. Cuando me despierto es lo primero que me viene a la mente.

Sí, eso es amor. Amor por la programación. N nadie se cansa de amar.

La mayoría de los días no lo escribo durante 8 horas al día, pero estoy trabajando con software por aproximadamente 12-14 horas al día. Tengo empleo a tiempo completo, así como proyectos paralelos y un producto empresarial que estoy construyendo. Lo que puedo decir es que me cansé de sentarme más que codificando. Sin embargo, mi subconsciente está obviamente cansado de escribir código ya que me he interesado mucho más en el entretenimiento en los últimos 2 meses.

En general, no veo televisión, películas o YouTube, pero últimamente he estado viendo muchos videos de H3H3 Productions (h3h3Productions) y algunos otros canales de YouTube. Principalmente solo comedia, bromas y otras cosas que en su mayor parte carecen de sentido. Es solo un sinsentido con el que puedo relacionarme y, a menudo, después de producir tanto código. Siento que me identifico más con un sistema de base de datos o con algún tipo de arquitectura informática que con las personas. Realmente no disfruto ese aspecto, pero es un signo seguro de fatiga / agotamiento.

Todavía tengo un largo camino por recorrer, lo que significa que no tengo fin en el sitio para los 7 días a la semana con 12-14 horas de trabajo en general. Lo disfruto, me está yendo muy bien para pagar todas mis deudas, aumentar mis inversiones y expandir mi biblioteca de libros / novelas gráficas.

De todos modos, si no quiere codificar 8 horas al día, solo consiga un trabajo diario que tenga muchas reuniones. Se perderá en aquellos que deseen poder volver a su máquina y contribuir con el código.

Nunca conocí a un codificador que codificó 8 horas en un día de trabajo.

Una división mucho más común es:

• 2 horas pensando en el problema
• 2 horas de codificación
• 2 horas corrigiendo errores, o problemas de interoperación cuando lo ajuste al sistema más grande
• 2 horas de trabajo complementario: reuniones, redacción de documentos, pruebas de corrección de cambios, lectura de cómo hacer las cosas, etc.

También hay una cierta cantidad de espera de cosas, que varía mucho, dependiendo de cosas como “¿Tengo que desplegar toda una infraestructura local para escribir código en este proyecto?” O “¿Las pruebas tardan 40 minutos en finalizar? “O” Realmente no he codificado ir en 2 años? Olvidé usar: = en 100 lugares “.

Muchos encuestados han comenzado sus respuestas con “Nadie codifica durante 8 horas al día”.

Esto no es verdad, código con mucha frecuencia durante más de 8 horas al día.

(¡Por supuesto, no escribo más de 8 horas al día! La codificación es principalmente pensar, basta de buscar en Google soluciones a los problemas, y probablemente menos del 20% realmente está ingresando / probando / depurando el código).

Actualmente trabajo por mi cuenta y trabajo en solitario en un proyecto, lo que explica por qué, a diferencia de la mayoría de los encuestados, estoy haciendo mucha más codificación que todas las otras cosas que conforman el desarrollo de software.

Durante la mayor parte de mi carrera profesional ha sido diferente, aunque aún así no era inusual tener días que tuvieran más de 8 horas de codificación. Hay momentos en que todos los desarrolladores de software de “otras cosas” te vuelven loco, porque en realidad estarías codificando algo bastante genial todo el tiempo. Hay momentos en que su tarea actual de codificación es algo aburrida, y preferiría estar haciendo las otras cosas.

Sin embargo, para responder a la pregunta, sí, por supuesto, hay días que son tediosos. 8 horas dedicadas a tratar de localizar un error obstinado o pérdida de memoria rara vez es divertido. No puedo imaginar que haya muchos trabajos en los que no haya días aburridos. Pero personalmente, nunca he encontrado que la codificación en sí misma se vuelva tediosa. Hay algunas tediosas tareas de codificación, pero hay muchas más tareas de codificación gratificantes que aburridas.

Todo esto depende del tipo de ambiente de trabajo que tenga. Las modernas tiendas de software deberían darse cuenta de que un desarrollador feliz y relajado es un desarrollador productivo.

Cuando entro en la rutina, no hay nada que desee más que resolver el problema. Entonces, una vez que funcione, podría quedarme hasta tarde y seguir refabrándolo hasta que sea algo de lo que realmente pueda estar orgulloso. Ese es un buen ambiente.

Por lo general, en mi experiencia, no me han sometido a tanta presión de fecha límite, pero obviamente tiene que adaptarse a su situación particular.

Si su empleador tiene suficiente experiencia, se dará cuenta de que su cerebro está trabajando en el problema de fondo, incluso si no se encuentra físicamente sentado frente a su computadora.

He estado escribiendo código durante casi 40 años y cada 2-3 años cambio mi paradigma de programación. Hay ocasiones en que yo diseño, diseño o administro equipos. Pero siempre escribo un código. Puede bajar al 5% cuando estoy haciendo las otras tareas, pero siempre estará allí.

¿Por qué? Porque, al menos para mí, necesito tomar los conceptos más abstractos y traducirlos en cosas reales para comprender completamente cómo funcionan las cosas. Al menos así es para mí en seguridad. Otras personas tienen diferentes formas de trabajar.

Incluso cuando administro equipos, resulta que he acumulado mucha experiencia y puedo compartir ese conocimiento con otros ingenieros experimentados o novatos. No puedo hacer eso si no puedo escribir código. De lo contrario, seré un administrador puntiagudo que diga cosas como: “Solo divide el problema en problemas más pequeños …” sin comprender nada.

La ingeniería del conocimiento es muy diferente de la fabricación típica de widgets. Es bastante creativo y requiere mucho esfuerzo mental.

Sin embargo, sí conozco a muchos programadores a los que les gusta escribir código. Consiguen una increíble cantidad de conocimiento de los sistemas simplemente por estar en el medio de las cosas. Hay otros a los que les gusta depurar volcados. Son como detectives.

Pero incluso ellos no programan 8 horas al día, todos los días. Un buen gerente los arrastrará a tomar una cerveza.

¿Por qué crees que las nuevas empresas de Silicon Valley se tratan de cervezas 🙂 Bueno … casi.

He estado escribiendo código profesionalmente y por placer durante más de 10 años y apenas puedo recordar un día en el que pasé horas codificando 5 horas completas, y mucho menos 8+. La estimación de mi estadio para cuántas horas al día el ingeniero de software promedio escribe activamente el código es de 0 a 5 horas por día.

Para ser justos, el hecho de escribir el código en sí puede ser aburrido y, por lo tanto, agotador, pero solo cuando hayas resuelto completamente el problema en tu cabeza y ahora solo sea cuestión de expresarlo en una computadora. Te contaré un pequeño secreto: no tenemos idea de lo que estamos haciendo una gran parte del tiempo, por lo que las cosas suelen ser … interesantes. Definitivamente, se necesitan conocimientos importantes para la ingeniería de software, pero la mayoría de las veces se resuelve en el trabajo. La mayoría de nosotros nos apoyamos mucho en las búsquedas de Google (que generalmente conducen a una comunidad llamada Stack Overflow) para obtener ideas y mejores prácticas sobre cómo resolver problemas particulares. Eso es porque los ingenieros de software son humanos y se olvidan de toneladas de información sobre el tema tan complicado que es la ingeniería de software.

Lo que lo mantiene interesante, incluso después de hacerlo durante varios años, es trabajar para resolver nuevos problemas todos los días. No hay dos días iguales.

Me siento cansado al final de algunos días, pero no es por la codificación en sí, sino por la imposición mental de pensar en problemas difíciles todo el día.

Soy directa e indirectamente responsable de los aspectos de los proyectos de software que involucran a más de 2.300 desarrolladores de software internos. Espero que ni uno solo codifique más de 8 horas al día. Ningún desarrollador eficiente y eficaz puede hacerlo de forma sostenible. No operamos una fábrica de software donde los programadores son el equivalente de los trabajadores de la línea de montaje.

Soy consciente de que algunos de nuestros socios de desarrollo subcontratados (Wipro, TCS, Infosys, etc.) en otras partes del mundo operan de manera diferente.

¿Puedo preguntar en qué parte geográfica del mundo estás?