¿Cómo convertirse en un programador "más rápido"?

Mi última evaluación de trabajo incluyó solo un punto débil: la oportunidad. Ya estoy al tanto de algunas cosas que puedo hacer para mejorar esto, pero lo que estoy buscando son algunas más.

¿Alguien tiene consejos o sugerencias sobre lo que hacen para aumentar la velocidad de su producción sin sacrificar su calidad?

¿Cómo estimas las líneas de tiempo y las mantienes? ¿Qué haces para hacer más en períodos de tiempo más cortos?

Cualquier comentario es muy apreciado, gracias

Apaga la computadora. Agarra un lápiz y un poco de papel. Dibuja tu diseño. Revísalo con tus compañeros. Luego escribe el código.

Algunas ideas...

• Evite el chapado en oro: haga solo lo que se le pida (en términos de requisitos)
• Comprenda los requisitos comerciales y hágalo bien la primera vez
• Comprenda a fondo su entorno y herramientas
• Conviértase en un mecanógrafo fantástico, use métodos abreviados de teclado en lugar del mouse
• Adopte un enfoque iterativo e incorpore controles de cordura para asegurarse de que está en el camino correcto
• No reinvente la rueda, considere reutilizar el trabajo pasado y el trabajo de otros
• Elimine las distracciones, no siga revisando el correo electrónico, mirando afuera, hablando con compañeros de trabajo, etc.
• No trabajes demasiado: reconoce cuándo necesitas tomar descansos

Su deseo de ser un programador "más rápido" por sí mismo es loable. Sin embargo, no entregar a tiempo no significa que sea lento, significa que el proyecto se planificó mal. Ser un programador "más rápido" no ayudará; solo significa que pasarás la fecha límite más rápido.

Usted (y su equipo) están cometiendo uno de los siguientes errores (o todos ellos):

• subestimar el trabajo que hay que hacer;
• falta un gran requisito o pieza de arquitectura durante la planificación;
• confundir estimaciones de trabajo con estimaciones de calendario y no tener en cuenta cosas como reuniones / teléfono / otros gastos generales;

Hay varias formas de abordar cualquiera de las tres anteriores. Pero antes de que pueda mejorar cualquiera de ellos, necesita saber por qué las cosas van como están. Haga una autopsia de las últimas dos o tres estimaciones de proyectos en comparación con el tiempo real empleado y averigüe a dónde fue el tiempo extra.

Lo repetiré nuevamente: ser lento al escribir el código no hará que se pierda el plazo , si lo ha planificado adecuadamente para tener en cuenta ese hecho.

Realmente, realmente aprende tu editor. Si usa un IDE, asegúrese de estar usando todas las funciones que ofrece. Obtenga una hoja de trucos para aprender los atajos de teclado para su editor de elección. Si está utilizando un acceso directo de configuración de shell para directorios de uso común

"¿Alguien tiene consejos o sugerencias sobre lo que hacen para aumentar la velocidad de su producción sin sacrificar su calidad?"

Muchas, muchas personas luchan por la calidad "máxima" a expensas de algo que es (a) simple, (b) confiable y (c) correcto.

La forma más importante de acelerar su desarrollo es simplificar lo que está haciendo para que sea lo más simple posible.

La mayoría de las personas que tienen problemas para entregar a tiempo están entregando demasiado, demasiado. Y las razones dadas son a menudo tontas. A menudo son solo requisitos percibidos, no requisitos reales.

He escuchado a mucha gente decirme lo que el cliente "espera". Esta es una mala política.

Construye lo más simple posible. Si el cliente requiere más, construya más. Pero construya lo más simple posible primero.

Evite pulir su código a la perfección, solo haga que funcione. Eso es lo que el negocio espera.

Pero a menudo, aumentar la velocidad implica sacrificar la calidad.

Reutilización: trato de descifrar cualquier fragmento inteligente de proyectos anteriores, para poder usarlo nuevamente en futuras empresas. Siempre vale la pena preguntarse "¿podría volver a usar esto algún día?"

Mantenlo simple.

Si usa TDD, debe seguir " rojo, verde, refactor ":

1. Escribe una prueba reprobatoria ( roja ). (A menudo, para la funcionalidad, su código aún no tiene).
2. Comete crímenes horribles de codificación para que tus pruebas pasen ( verde ). Hardcode si es necesario.
3. Refactorizador , probablemente rompiendo pruebas por un corto tiempo, pero en general mejorando el diseño.

Descargue localmente toda la documentación de sus idiomas / bibliotecas en su computadora, luego desconecte su cable de red / apague el Wi-Fi .

No trato de ser gracioso aquí. ¡Esto realmente me ayuda!

Observe cuando ha estado leyendo Stack Overflow durante demasiado tiempo. La excusa de "compilación" solo funciona por mucho tiempo. :)

Evite cambiar de tarea con demasiada frecuencia. Las distracciones y el cambio de tareas pueden matar un día, incluso si usa herramientas como Mylyn para administrar sus tareas.

Calcule una granularidad (por ejemplo, 30 minutos) y solo trabaje en cosas relacionadas con la tarea en cuestión. Cualquier otra cosa (nuevos informes de errores, correos electrónicos sobre otros problemas, cuestiones de procedimiento que no están relacionadas) se retrasa al menos hasta el "próximo punto de control". Asegúrese de deshabilitar las notificaciones emergentes de correo electrónico para que no se deje engañar.

Es especialmente efectivo si tienes un amigo en tu equipo que te hará saber si las cosas realmente se derriten y requieren tu atención inmediata.

Hazlo bien, la mejor manera, la primera vez. Si eso significa que tienes que detenerte y pensarlo por un tiempo antes de comenzar, entonces hazlo. Funciona el 90% del tiempo.

Aprenda a escribir con el teclado lo más rápido posible .

Yo hago mañana .

Hacer las cosas también es inmensamente útil.

De todos modos, tengo poco tiempo de atención, así que estos libros me ayudan a mantener mi enfoque ... ¿qué estaba haciendo de nuevo?

Práctica y trabajo duro.

Debe dedicar tiempo y esfuerzo. A medida que se sienta más cómodo y seguro con las herramientas que utilice, la velocidad y la creatividad deben seguir.

Si desea mejorar alguna habilidad en particular, también puede ayudar a diseñar ejercicios que le permitirán trabajar específicamente en eso. Si su lentitud está en la fase de diseño, intente encontrar problemas de diseño para trabajar en línea. Rehacer el mismo ejercicio le permitirá completarlo más rápido y practicar la velocidad. Personalmente, me gustan los ejercicios de algoritmo de TopCoder para practicar la velocidad de programación. También tienen desafíos de diseño, pero no los he probado.

Aprende acerca de The Zone, aprende cómo meterte en ella y aprende a reconocer cuando no estás en ella.

Una vez que estoy "en la zona", soy extremadamente productivo y el código simplemente sale de mí, a menudo puedo hacer la codificación de 2 o 3 días en 1 día. Pero me parece que a menudo es difícil llegar a ese lugar, me encuentro postergando, distrayéndome con otras cosas (por ejemplo, Stack Overflow).

Cita de qué-trucos-haces-usas-para-hacerte-en-la-zona

Conocer bien su IDE y marco. Tener que recurrir a Google para cada pequeña cosa lleva tiempo.

Emacs

Antes de comenzar a desarrollar:

• Salga de su buzón
• Apague cualquier cliente de mensajería instantánea
• Cortésmente pídale a sus compañeros que le den tiempo para concentrarse
• Por supuesto, deja de navegar por Internet

Cada vez que lo interrumpan, disminuirá la velocidad ya que le toma tiempo a su mente volver a encarrilarse con sus pensamientos. He escuchado cifras de que para cada interrupción, la mente humana tarda entre 5 y 10 minutos en restablecer el proceso de pensamiento que tenía antes de la interrupción. Con tanto tiempo por interrupción, no lleva mucho perder todo el día.

La gente de nuestra empresa realmente ha bloqueado el tiempo en sus calendarios y luego se ha mudado a una sala de conferencias vacía durante un par de horas cada día.

Conozca su desarrollo IDE dentro y fuera. Aprende las teclas de acceso directo. Aprende a usar menos el mouse. Me parece que esto me ahorra mucho tiempo.

¿Eres más lento que tus colegas o tus estimaciones son más optimistas?

Para producir software más rápido, he descubierto que lo mejor que puede hacer es aprender su API de tiempo de ejecución lo mejor posible. No escriba la lógica de la lista cuando lo haga una extensión LINQ; no cree un grupo de oyentes de eventos cuando el enlace funcionará, etc.

En cuanto a la estimación, eso viene con la experiencia. Puede utilizar el software de estimación para ayudarlo a calcular mejores estimaciones.

Personalmente, descubrí que con los desarrolladores de nivel junior, tome la estimación inicial y multiplíquela por 2, luego duplíquela. Esto explicará todo el aprendizaje, las reuniones, el tiempo perdido, etc. Los desarrolladores de nivel superior tienden a trabajar en un factor de 2 sobre sus estimaciones.

Muchas veces, la pregunta no es si su estimación fue incorrecta. ¿Ha calculado su cuenta para todas las cosas correctas? ¿Está dando sus estimaciones y plazos en términos de esfuerzo de codificación o en términos de tiempo calendario? Piense en todo el tiempo de su día y en qué cantidad es real, codificación productiva frente a reuniones, aprendizaje, depuración, etc.

Dos cosas que podrían estar implícitas, pero aún no he visto entre las respuestas aquí que aumenten la productividad son:

• Utilice algún tipo de scripts de compilación y despliegue. Compilar, implementar, reiniciar el servidor de aplicaciones y no debe absorber ni el tiempo ni el enfoque, debería ser algo con un solo clic.

• Tener algún tipo de control de versiones. Tener que codificar sin poder revertir un cambio es como tratar de caminar sobre los huevos

Se me ocurren un par de ideas:

1. Obtenga otras opiniones sobre sus estimaciones. ¿Hay otros desarrolladores a los que pueda preguntarles algo como "Oye, crees que puedes hacer este tipo de función en este plazo?" La idea es que el aporte de otras personas puede ayudar con la precisión en algunos casos, ya que alguien puede notar un montón de cosas que te perdiste al hacer la estimación.

2. Perfeccione su habilidad de estimación: comience a hacer un seguimiento de cuán fuera de las estimaciones y por qué no: ¿Hay otros elementos de trabajo que causan que no se cumplan los plazos? ¿Estás constantemente subestimando lo complicado que es algo? ¿Está dando una línea de tiempo completa cuando no es práctico, por ejemplo, lo que se pregunta es lo suficientemente vago como para que simplemente obtener un prototipo lleve semanas y luego deba reevaluarse qué más se debe hacer? Hacer esto puede ser de gran ayuda para desarrollar esa habilidad, de modo que si dices que algo tomará x horas, puedes confiar en eso porque lo has hecho una y otra vez. Una forma alternativa de decir esto es simplemente practicar, practicar, practicar.

Es cierto que probablemente ya consideró esto, pero pensé que valía la pena decir esto para aquellos otros que podrían no haber considerado estas ideas.

1. Conozca la tecnología por dentro y por fuera.
2. ¡Detener! ¡Pensar! ¡Ir!
3. Arquitecto para lo que pueda surgir, pero implemente solo lo que realmente se solicita.
4. BESO - Mantenlo simple estúpido
5. Si se está volviendo demasiado complejo, probablemente no esté bien pensado. (Regrese a 2 y 4)
6. No se quede atascado en 5. A menudo vale la pena comenzar desde cero (Regrese a 2 y 4)
7. Regrese a 1.

Creo que la palabra clave aquí es "puntualidad". No decían que eras demasiado lento, sino que no eras oportuno.

En la gestión de proyectos, es importante que el gerente pueda estimar cuándo se completarán sus elementos de trabajo con precisión. Sospecho que la razón principal por la cual sus esfuerzos no se consideraron oportunos es que con frecuencia tenía artículos que no se entregaron a tiempo y se entregaron mucho más tarde de lo programado.

Para mejorar su puntualidad, es posible que desee dedicar más tiempo a comprender cuánto tiempo le llevará completar un elemento de trabajo en particular dadas sus habilidades, experiencia y dominio. Esto le permitirá dar mejores estimaciones a su gerente de proyecto. La clave aquí es "mejor" ... podría entregar a tiempo con más frecuencia rellenando todo con un factor de fraude, pero lo que realmente desea es una estimación más precisa.

Discutiría esto con su gerente para ver si este es realmente el problema. De lo contrario, podría terminar programando el doble de rápido, prometiendo cosas en la mitad del tiempo que solía hacerlo y aún siendo criticado por su puntualidad porque sus estimaciones seguirán teniendo el mismo factor de error.

Mantente estable, mantente estable.

Cree algo que implemente un poco de la funcionalidad y asegúrese de que funcione de principio a fin. Luego, manténgalo funcionando mientras agrega nuevos bits de funcionalidad. Sí, esto es en parte una práctica de TDD, pero tiene sentido incluso si no haces TDD.

La razón es que cada vez que he visto a alguien con 2 semanas de código que nunca había sido estable, siempre toma otras 2 semanas para que sea ​​estable.

Si te mantienes estable, eliminas esa incertidumbre y también te das una forma de reducir el alcance cerca de la fecha límite si es necesario.

El contraargumento obvio es que hacer esto llevará más tiempo que solo escribirlo una vez, ya que hará un trabajo adicional para estabilizar el código no final. No compro esto por un segundo. Cuando tienes un código que funciona , cambias 5 líneas y algo se rompe, sabes exactamente dónde debe haber ocurrido el corte.

Si tiene 10,000 líneas de código que nunca funcionaron y tiene que encontrar un descanso, tiene un montón de código para buscar.

Pequeños cambios incrementales en un sistema que es consistentemente estable FTW. Ve despacio para ir rápido.

Para mí, obtener una buena productividad es tener una idea clara sobre lo que está tratando de lograr y cómo llegará allí.

Casi todas las respuestas se han dicho a muerte en numerosos lugares aquí y en otros lugares. O, al menos, lo he oído morir. Aprenda su IDE, aprenda a escribir más rápido, use marcos, use generación de código, etc., etc. Sí, por supuesto, estas cosas ayudarán y dudo que haya muchos programadores que los dominen todos. Pero al ser el tipo de programador que hace estas preguntas y frecuenta sitios como Stack Overflow, ya sabías estas cosas . ¿Simplemente quería repetirlos aquí o simplemente quería desahogarse un poco?

Pero, ¿y si pudiéramos llegar a ese estado? Me refiero a dominar todas estas sugerencias? ¿Qué pasaría entonces? Bien. Supongo que las líneas de tiempo se reducirán aún más. Y nuevamente, volveremos a una percepción de calidad. Quiero decir, nuestro oficio definitivamente ha progresado y se ha vuelto más y más productivo a lo largo de las décadas. Pero, ¿ha aumentado la calidad durante este tiempo (excluyendo los primeros años, por supuesto)?

Mi respuesta es simple: ¡el software de calidad lleva tiempo ! Solo puede intercambiar uno por el otro (calidad / velocidad). Pero sí, todos sabemos que, sin embargo, no somos honestos sobre el grado en que esa compensación a menudo termina en el extremo de la velocidad de la escala. ¡Y somos mentirosos aún mayores al principio de los proyectos!

Yo digo que no tienes la culpa aquí. El problema es la percepción que tiene la gente de cuánto tiempo debe tomar el software de calidad. Nos engañamos creyendo que somos capaces de crear software de calidad con los tipos de cronogramas que nuestros gerentes o incluso estimamos. No hacemos software de calidad . Escribimos software que funciona pero a veces con destellos de calidad en ciertos rincones de una aplicación.

Entonces, ¿qué podemos hacer al respecto? No podemos convencer a nuestros jefes de que necesitamos duplicar o triplicar la inversión en cada uno de nuestros proyectos. Digo liderar con el ejemplo. Cree un software realmente excelente como proyecto paralelo. Dedique su propio tiempo y no se comprometa. Todo el tiempo presta atención a cómo progresas. Tome nota de las tareas aparentemente no relacionadas en las que ha tenido que dedicar una cantidad de tiempo inesperada y vea si puede justificarlo. Compare esto con todos los otros proyectos que ha trabajado. Se brutalmente honestocontigo mismo y con todos los aspectos de este análisis. ¿Se pueden descuidar las cosas adicionales que hizo con su software de calidad en proyectos "reales" en el trabajo? Pero tal vez tu intento falló. ¿Cuál fue la razón? ¿Te aburriste y te apresuraste a hacer las funciones principales? Todavía tengo que hacer algo como esto, por eso termino este pensamiento con algunas dudas, pero tengo la intención de darle una oportunidad real. Te mantendré informado :).

Finalmente, creo que la mayoría (si no todas) las evaluaciones de desempeño son retorcidas y extraordinariamente manipuladoras. No se puede acelerar la calidad y la velocidad al 100%. Su jefe debería calificarlo según un estándar establecido por la organización. El estándar de la organización en el intercambio entre calidad y velocidad. Imaginemos que OrangeSoft Inc. espera 33% de calidad y 66% de velocidad. Por lo tanto, si está escribiendo un código que tiene quizás un tercio de las pruebas unitarias, debería hacerlo, pero compensándolo con velocidad y tiempo de entrega reducido, ¡debe obtener un puntaje cercano al 100% en su revisión! (Estas son analogías bastante aproximadas pero entiendes el punto). Pero en cambio, lo que sucede es que Bob escribe código extremadamente rápido pero que es notoriamente defectuoso. Entonces, en su evaluación de rendimiento, obtendrá 3/5 en calidad y 5/5 en velocidad. Carol, por otro lado, escribe el código mucho más lento pero produce significativamente menos errores. Ella obtiene 5/5 de calidad pero 3/5 de velocidad. De cualquier manera, Bob y Carol quedan atrapados en su aumento. ¿Es posible que algún empleado obtenga una puntuación perfecta? ¿Es justo?

La técnica que uso es la creación de prototipos evolutivos.

Puede buscar en Google más información, pero si la necesidad es producir algo rápidamente, es el único camino a seguir. Además, tiene la ventaja de que cuando los usuarios dicen que le gusta, ya está listo (... y puede comenzar a hacer la documentación).