Solo he producido 5000 líneas de código en un año, ¿son muy pocas para un desarrollador a tiempo completo?

El conteo se puede hacer de múltiples maneras.

Es interesante cómo lo contó. Puede contar el código repetitivo o no. Los programadores modernos a menudo usan fragmentos, generadores de andamios, etc. Puede generar fácilmente un montón de código de esa manera.

Las líneas de código no son una buena métrica de productividad.

Debería poder escribir tal cantidad de código incluso en un mes o menos. Especialmente en aplicaciones orientadas a negocios, donde una gran cantidad de código no son algunos algoritmos de ciencia espacial. Pero dependiendo del contexto y múltiples factores, esos 5000 podrían estar bien.

Solo debe escribir el código tan pequeño como sea necesario para resolver un problema. Según sea necesario, no lo más posible. Muchos programadores tienden a olvidarse de ese código de escritura que es realmente difícil de mantener, ampliar y leer por otros desarrolladores.

También recuerde eliminar código antiguo y refactorizar. Puede llevar mucho tiempo, pero es necesario para mantener los proyectos más grandes limpios y bien organizados.

Los programadores trabajan no se trata de escribir toneladas de código

Existe una idea errónea, especialmente en las mentes de las personas fuera de la industria, de que un programador debe escribir código 8 horas al día. No llamaría a alguien así programador. Más de un usuario de teclado sin sentido.

Algunas tareas diarias que un programador real hace:

• Algoritmos de diseño, capas de aplicación, vistas, etc.
• Elegir las herramientas adecuadas para hacer el trabajo, que a menudo requieren un poco de investigación.
• Colaborar con otros desarrolladores para estar más o menos en la misma página y mantener estándares comunes
• Encontrar errores reportados / detectados
• Arreglando esos errores
• Aprender nuevos idiomas, herramientas, bibliotecas, marcos.
• Eliminar código antiguo / refactorización
• Actualización de dependencias
• Hacer documentación
• Escribir varias pruebas
• Escribir un código (lógica de aplicación)

Mejores métricas para rastrear en lugar de varias líneas escritas

Usar métricas es bueno, ya que sabemos si estamos progresando o no y cuánto. Sin embargo, es importante usar otros más adecuados como:

• Número, gravedad y frecuencia de los problemas informados (por clientes y miembros del equipo)
• Valores de Número / Puntos de historia de tareas no entregadas en el tiempo planificado
• Ejecución de rendimiento de componentes particulares y una aplicación completa
• Cobertura de código probado

Depende de qué tipo de código y cuál es el nivel de proceso involucrado. Por ejemplo, si forma parte de un equipo que diseña una API de biblioteca destinada a proporcionar una infraestructura central para los productos de software de su empresa, y usted es responsable de crear un documento de diseño detallado y un plan de prueba a partir de los requisitos de software de alto nivel para su módulo central , así como la codificación del diseño detallado, entonces promediar 20 líneas de código de producto por día probablemente esté bien.

Otro ejemplo: supongamos que su código depende mucho del hardware, y el hardware aún no está listo o tiene errores que necesita solucionar. Su código es un código de nivel de controlador de dispositivo en el sistema operativo, por ejemplo. O bien, es la parte del núcleo del sistema operativo responsable de la tarea y el cambio de espacio de direcciones (y depende de la implementación de hardware de la MMU que tiene errores). Otro ejemplo en el que escribir 5000 líneas de código de producto en funcionamiento en un año probablemente esté bien.

No, líneas negativas de código; cuántos puede eliminar por día es una métrica mucho más valiosa. Eliminar las líneas de código, siempre que cumpla con sus requisitos es una mejora. Reduce la complejidad, aumenta la claridad, la facilidad de mantenimiento, la eficiencia y la cobertura de prueba.

En los idiomas OO podemos aplicar programación declarativa, aplicar la Ley de Demeter, también conocida como TellDontAsk y HollywoodPrinciple. Este enfoque reduce el acoplamiento y aumenta la cohesión, estas son cosas muy buenas. También sucede a resultados en significativamente menos líneas generales de código. Polimorfismo en lugar de declaraciones de cambio o si las escaleras hacen lo mismo.

El número de líneas de código que escribió es irrelevante, lo único que importa es cuántos de los tickets que se comprometió a entregar en cada sprint completó realmente (que no se le devolvieron debido a errores o pruebas perdidas), qué tan bueno es su código y sus pruebas fueron, y que dejó la base del código mejor de lo que lo encontró, si es posible.

Algunas de mis semanas más productivas o sprints mi recuento de líneas fue negativo. Una vez fueron miles de líneas negativas, porque reemplacé docenas de clases con una sola clase que podía adoptar un montón de rasgos, cada una de las viejas clases ahora era una colección de rasgos, y mi nueva fábrica elegante sabía cómo crear e inyectar Los rasgos apropiados. También colapsé todas las pruebas en una clase y eliminé miles de pruebas (duplicadas). Tuvimos algunos errores de todo eso, pero si mi recuento de líneas hubiera importado, no lo habría hecho de esa manera. Tal vez.

El punto es que el recuento de líneas es solo un número, no dice nada sobre la calidad de los cambios que realizó.

Editado para aclarar que la tasa de cierre de boletos es el porcentaje de cumplimiento de su compromiso, no solo el recuento de sus boletos.

Esta no es la métrica que deberías medir.

Si estoy duplicando una pieza de funcionalidad, por alguna razón, que implica copiar y pegar código, estoy “escribiendo” muchas líneas de código. O tal vez estoy escribiendo una nueva funcionalidad que me obliga a escribir muchas líneas de código, ¿eso significa que estoy siendo productivo?

¿Qué pasa con el tiempo que me pidieron que solucionara un problema con un sitio web? Pasé 2 horas analizando su código desde el momento en que abrí los archivos por primera vez hasta que solucioné el error. El error implicaba cambiar una condición de , ¿qué es eso improductivo? ¿Resolví un gran problema para su sitio web pero cambié un personaje y me tomó dos horas? No. Mi trabajo en su sitio web se realizó extremadamente rápido, teniendo en cuenta que no tenía ni idea de cómo funcionaba y que no tenía forma de darme ningún consejo sobre cómo funcionaba. Mi mente estaba en marcha, estaba leyendo y analizando el código como una bestia absoluta, realmente me impresioné y el cliente se sorprendió de la velocidad con la que encontré el problema.

Escribir líneas de código depende completamente de lo que está haciendo y es irrelevante.

Analice los objetivos logrados en función de la escala de tiempo que se definió para esos objetivos. ¿Qué porcentaje de objetivos lograste? ¿Qué porcentaje de esos logró a tiempo y dentro del presupuesto? ¿Fue correcto el tiempo estimado que le dio a esos puntos o lo sobreestimó?

Hay muchos valores que debe analizar para comprender qué tan bien se está desempeñando en su trabajo y las líneas de código no son uno de esos.

Las líneas de código nunca han sido una métrica muy valiosa, tampoco lo es aquí.

Cuando vi tu pregunta, pensé en esto: Scott Berkun en Twitter

A menudo, el código que no escribe o el código que elimina es más valioso que lo que agrega. Es por eso que muchos escritores dicen que su editor es realmente su mejor compañero, porque ayudan a eliminar los bits que no necesitan estar allí.

Busque otras formas de cuantificar su beneficio y valor: algunas de las mejores formas para que un desarrollador de software se vuelva valioso son: Ayudar al resto del equipo a comprender el código (útil si tiene gente de operaciones especialmente), discutir áreas donde el código podría se mejorará e implementará en una nueva rama: una vez implementado, analice las ventajas y desventajas de cada enfoque y vea si debe fusionarse, conviértase en la persona del equipo que experimenta con ideas o mejoras. Pero deja de contar LOC.

[Editar: Reformado, para mostrar lo que es realmente importante primero.]

Ningún líder de proyecto decente mide el rendimiento individual o del equipo en líneas de código. (O no debería). La medida real son las tareas completadas. Objetivos alcanzados. Si lo hizo con un código adecuadamente concebido y mantenible, dentro del horario, todo debería estar bien.

Si insiste en la métrica LOC, echemos un vistazo. Como otros dirán: depende.

• El idioma: algunos idiomas requieren más líneas para llegar al mismo.
• El entorno de desarrollo: algunos entornos requieren menos código ya que la IU se resuelve en forma gráfica.
• Tu propia experiencia con el medio ambiente. ¿Un par de meses? ¿Un año? ¿5 años? 10? Cuanto menor sea la experiencia, menores serán las expectativas.
• Toda su experiencia de desarrollo (referencias al mismo tiempo).
• Su definición de tiempo completo: ¿inicio o trabajo corporativo? ¿Esto es 6,5 días a la semana o 5 días a la semana? ¿8 horas al día o 16 horas al día?

Hay una métrica muy antigua para el desarrollo corporativo, que ejecuta un entorno en el que la interfaz de usuario no necesita estar profundamente codificada: 20 líneas de código libre de errores (significa que no hay errores lógicos a lo largo de un año) al día hacen un buen desarrollador. Trabajando de 9 a 5.

Veamos tu propio rendimiento:

• Estás trabajando de 9 am a 5 pm.
• Trabajó alrededor de 240 días a lo largo del año (260 días hábiles / año – 10 días festivos – 10 días de licencia).
• Escribiste 5000 líneas de código libre de errores en un año. Esto significa 20.8333 … líneas por día. ¡Un cabello justo por encima de la métrica! ¡No está mal!

Luego, comparémoslo con una startup (mítica), en el mismo entorno de desarrollo:

• Estás trabajando de 8 am a 12 am. Agregue un factor de 1.5 (No, no duplica su productividad diaria cuando duplica su día. De hecho, es más propenso a errores. Es por eso que tiene que trabajar más. No solo el horario).
• Debe escribir 20 líneas / día x 1.5 = 30 líneas de código libre de errores por día.
• Escribiste 5000 líneas en 300 días (312 días laborables / año – 10 días festivos – 2 días de licencia. Sí, solo dos días de licencia. ¡Es una startup, hombre!)
• Usted escribió 16.666 … líneas de código libre de errores por día, en promedio. ¡UPS! Por debajo del promedio esperado. ¡Casi a la mitad!

¿Significa esto que cualquier situación en el medio de ambas comparaciones es un fracaso? Absolutamente no.

Prof. Dr. Edsger W. Dijkstra, en su ensayo titulado ” Sobre la crueldad de enseñar realmente ciencias de la computación”, escribió :

“A partir de ahí, solo es un pequeño paso para medir la ‘productividad del programador’ en términos de ‘número de líneas de código producidas por mes’. Esta es una unidad de medición muy costosa porque fomenta la escritura de código insípido, pero hoy estoy menos interesado en lo tonta que es una unidad incluso desde un punto de vista comercial puro. Mi punto hoy es que, si deseamos contar líneas de código, no debemos considerarlas como ‘líneas producidas’ sino como ‘líneas gastadas’ ”

Bill Gates dijo algo como esto:

“Medir la productividad del codificador por líneas de código es como medir la seguridad del avión por peso”.

No te preocupes por las líneas de código. Preocúpese por si entregó o no un producto estable a tiempo y si las personas para las que lo escribió lo encuentran útil.

Como está haciendo la pregunta, debe preocuparse por su productividad. Mi mejor respuesta es que no sé, ya que proporcionó cero detalles sobre lo que se suponía que debía hacer, el idioma y el IDE que estaba utilizando, si esto era una pequeña parte de un gran proyecto (o al revés) y si tuvo éxito ?

Si bien los LOC generalmente son una mala métrica, pueden ofrecer alguna información. Hay situaciones en las que 5K es patético y otras en las que serías un as. Pero no tenemos los datos para hacer esa llamada.

Tampoco creo que los que respondieron la pregunta hablando sobre la eliminación de líneas respondieron la pregunta. Sí, refactorizar y limpiar el código es una tarea noble, pero ese no parece ser el trabajo que tenía que hacer. Pueden haber comenzado con una pantalla en blanco y hacer una compilación de abajo hacia arriba. Quién sabe.

Las líneas de código no importan, podrían ser 20000 líneas de basura y código de espagueti. De hecho, las mejores piezas de software que he escrito fueron menos detalladas y tardaron mucho más en escribirse. Un código bien estructurado, productivo y eficiente es lo que cualquiera debería esforzarse, y eso no se mide en líneas. Una mejor medida (pero no completamente tangible) en mi estimación sería contar cuántos problemas resolvió de manera correcta y limpia. Al final del día, la programación se trata de construir soluciones y resolver problemas, no de escribir.

Si mide su productividad por la cantidad de líneas de código, entonces, como desarrollador, hay algo inherentemente incorrecto.

Los tiempos están cambiando, pero la mentalidad no puede seguir el ritmo.

anagramMap = wordSet
.corriente()
.map (word -> word.toLowerCase (). replace (“”, “”))
.map (word -> word.replace (“‘”, “”))
.collect (Collectors.groupingBy (Anagram :: sortChars));

Ahora, escriba el código anterior sin lambdas usando un margen de 80 ancho y luego cuente las líneas. Por cierto, quizás he usado solo 50 de ancho como máximo.

Entonces, la pregunta que debe hacerse es, ¿cómo ve sus líneas? ¿Vertical u horizontalmente? ¿O ambos?

Esta es una pregunta que encontrará en todas las fases de su vida y no solo al escribir código. Así que trata de ver las cosas desde una perspectiva holística.

No debemos juzgar esto por el número de líneas de códigos.

Depende de la lógica, las habilidades y la cantidad de proyectos diferentes en los que haya trabajado.

Por ejemplo, una vez que mi compañero de equipo con más experiencia reescribió mi código, que era de 400 líneas a alrededor de 200 líneas para lograr la misma funcionalidad.

Me ayudó a entender que la lógica y los patrones son importantes que el número de líneas.

Así que aguanta ahí. Comprenderá las buenas prácticas de codificación después de escribir un código incorrecto durante un tiempo.

Sigue aprendiendo y sigue creciendo.

¿Por qué estás contando cuántas líneas de código escribes? Esa es una métrica terrible para medir.

Aquí hay un escenario.

Mi amigo escribió una pieza de software “pequeña”. Eran unas 3.500 líneas de código. Una vez que lo completó, me lo envió para su revisión. Después de revisarlo, supe que necesitaba una refactorización, así que pensé que sería una buena experiencia de aprendizaje. Terminé refactorizando su código a 750 líneas. Mis 750 líneas de código fueron:

a) mucho más manejable

b) más rápido y más eficiente

Entonces … ¿por qué te importaría la cantidad de código que escribes? Como desarrollador senior, estoy mucho más interesado en que escribas código limpio, simple, legible y manejable.

¿Honestamente preferiría tener un software que haga lo mismo en 500 líneas de código o 5,000 líneas de código? Tomaría las 500 líneas cualquier día.

Mire la calidad del código que está produciendo sobre la cantidad. Calidad sobre cantidad.

Cuando estaba aprendiendo a programar me sentí orgulloso porque había escrito un programa que creó 10000 (diez mil) carpetas. Me tomó algunas horas, pero finalmente pude terminarlo. El objetivo se logró mediante muchas copias. Diez mil líneas de código como este pseudocódigo:

CreateFolder (“1”);
CreateFolder (“2”);
CreateFolder (“3”);
CreateFolder (“4”);
…
CreateFolder (“9997”);
CreateFolder (“9998”);
CreateFolder (“9999”);
CreateFolder (“10000”);

Creo que todos ya se han dado cuenta de lo que quiero decir con eso. Lo que importa no es la cantidad de código que escribes. Es la calidad.

Solo he producido 5000 líneas de código en un año, ¿son muy pocas para un desarrollador a tiempo completo?

Las “líneas de código” como medida de la productividad del desarrollador son una métrica de mierda que solo usan los aficionados y los tontos.

Disculpas si eso parece duro, pero lo que me preocupa no es que un desarrollador de tiempo completo produzca 5k líneas de código en un año (eso podría significar algo o nada), sino que de alguna manera terminaron pensando que la productividad podría medirse en líneas de código.

Quien te haya dicho eso y te haya metido en ese modo de pensar, debes alejarte de ellos. Es una señal de peligro clásica para una administración extremadamente pobre (o desarrolladores extremadamente desorientados, pero para ser honesto, nunca he conocido a un desarrollador que use esa métrica).

Y de todos modos, cuando se trata de código, menos es más. El año pasado hice un buen trabajo de refactorización y limpieza, y mi contribución neta de líneas de código para el año podría ser un número negativo. Estoy tan feliz con eso como con cualquier otro resultado.

No debe medir su productividad en líneas de código. Es una mala métrica y depende mucho de la situación.

Si está escribiendo código de un solo subproceso desde cero, sin dependencias, sin requisitos extremos, resolviendo problemas directos, entonces es bastante bajo.

Si está agregando cosas a una base de código antigua, escrita por otra persona, donde hay muchas deudas técnicas sin resolver, uso de concurrencia, y hay dependencias de muchas cosas con las que no está demasiado familiarizado, y puede producir 5,000 líneas de código de alta calidad en un año, entonces probablemente sea un desarrollador muy productivo.

Los números que he visto para la productividad promedio (que son casi inútiles, por todas las razones anteriores), 5,000 líneas están un poco por encima del promedio.

Varios respondedores han dicho que las líneas de código no significan absolutamente nada. Creo que eso va un poco demasiado lejos. Las líneas de código son una mala métrica, pero no son totalmente inútiles. No puede decir que 10,000 líneas es “más” que 5,000, incluso en el mismo idioma, pero también puede estar bastante seguro de que un proyecto de 500,000 líneas es más grande que uno de 5,000 líneas. No puede estar completamente seguro, porque el 500,000 puede ser solo basura total escrita por un loco, o el 5,000 puede ser la implementación de un nuevo algoritmo brillante, pero estas son situaciones bastante inusuales después de todo.

Algunos también escribieron que ningún desarrollador mide líneas de código. Bueno, lo hago, ocasionalmente. No para comparar la productividad, pero si me encargo de mejorar algún componente escrito por otra persona, ciertamente verifico cuántas líneas de código hay, para tener una idea de cuánto tiempo llevará estudiar el código. Por supuesto, no solo miro el número de líneas, también considero el lenguaje de programación, el tipo de código, el estilo del autor (es), la calidad de la documentación, etc. Es como leer un libro. Es posible que pueda leer algunos libros de 500 páginas en un día, y a veces 50 páginas pueden llevar semanas. Sin embargo, no hay forma de que pueda leer 500 páginas (de texto denso en una fuente de tamaño normal) en diez minutos, por lo que el recuento de páginas tiene algún impacto.

OK, vamos a sacar un descargo de responsabilidad.

No podemos medir la productividad / calidad / atractivo del desarrollador en función del número de líneas de código.

Sin embargo, diré que si bien es posible que no necesite escribir más de 5000 líneas de código en un año, probablemente debería poder hacerlo .

Sé que se supone que debemos fingir que un programador de basura escribirá 150,000 líneas para hacer un juego de teléfono inteligente, y un programador increíble aparecerá diciendo “Mira esto” y reemplazará el código con 2 líneas de Haskell y un archivo JSON.

Es una mierda. Las líneas de código no son una medida para juzgar la calidad del código, pero es mejor que creas que algunos programas son necesariamente más largos que 2 líneas.

Haber escrito 5000 líneas está bien si has hecho bien tu trabajo. A medida que se vuelve más mayor, puede que tenga que escribir más, puede que tenga que escribir menos. Realmente depende de tu campo.

Sin embargo, las líneas de código escritas no son una medida de la productividad del desarrollador …

1. Algunos programas son necesariamente largos.
2. Algunos plazos son necesariamente cortos.

Esa es solo la realidad de la programación para un trabajo.

Como desarrolladores, se supone que debemos seguir golpeando el tambor de que las líneas de código no importan, pero ninguno de nosotros señala el proyecto del que estamos más orgullosos y son 50 líneas.

Se supone que debemos golpear el tambor para que las líneas de código no importen, pero también para el tambor que es importante poder crear un gran proyecto por su cuenta. Entonces, ¿cómo estamos definiendo “grande” excepto por líneas de código?

Continué más de lo que había planeado, así que TLDR:

5000 líneas está totalmente bien, si has hecho bien tu trabajo.

Ese número puede aumentar, puede disminuir, dependiendo de su trabajo.

La longitud del código no es una medida de la calidad del código, pero algunos códigos de calidad son necesariamente largos.

Si eso fuera una verdadera medida y si sus desarrolladores recibieran bonificaciones al escribir, digamos 20k + líneas al año, ¿eso no los alentaría a cometer códigos incorrectos, solo para obtener sus líneas?

Digamos que tiene un sitio web y necesita un simple CSS escrito, y estas reglas también se aplican a los archivos CSS. Tienes 2 desarrolladores y te gustaría comparar su trabajo por alguna estúpida razón, y su gerente pone su cuota en 4500 líneas al mes para obtener un bono. Por debajo de 1,000 líneas son expulsados.

A Dev 1 le gusta obtener tantas líneas como sea posible para su bonificación, y produce un archivo CSS loco de 5000 líneas de código.

Dev 2 no se preocupa por su bonificación, pero solo le gusta comprometer un trabajo de calidad. Su archivo tiene 350 líneas de largo.

Sus productos finales son 100% idénticos en la interfaz de usuario y el front-end.

Resultado:

Dev 1 obtiene su bonificación

Dev 2 es despedido

Sé a quién contrataría de los dos.