¿Cuánto código escribe un ingeniero de software en un día normal? ¿Cuántas líneas se escriben y cuántas líneas se examinan / depuran para encontrar errores? ¿Cómo difiere eso en compañías como Google, Facebook y nuevas empresas como Quora y Palantir?

Como de costumbre, todo depende, pero en promedio entre 200-250 líneas de código en un día muy productivo.

No se distribuye incluso. P.ej. En un día, podría estar escribiendo 500 líneas de código, y al siguiente, 3-4 líneas y pequeños cambios en la solución de errores del día anterior (eso también lleva mucho tiempo).

Además, los LOC pueden ser muy engañosos, especialmente cuando se trabaja en cosas como iOS donde se trata con Interface Builder y otras herramientas, donde podría estar haciendo mucho trabajo pero no se está traduciendo directamente a líneas de código.

Además, en un día normal, las reuniones, entrevistas y otros eventos te distraerán, por lo que tendrás que adaptarte para eso.

Loc es una mala métrica para la productividad. En realidad, para una característica dada, cuantos más LOC se escriben, peor es, ya que la línea de código está relacionada proporcionalmente con la complejidad de un programa.

Aquí hay un artículo de ingenieros experimentados: ¿Qué tan rápido puede escribir código? Me gusta específicamente esta respuesta:

¿A quién le importa lo rápido que podamos escalar las montañas equivocadas? Sin duda, una mejor medida de productividad es la rapidez con que un desarrollador entrega VALOR.

Piense en un par de algoritmos de línea que toman días, meses e incluso años para construir y mejorar.

Varía, porque no escribe código el 100% de su tiempo, la ingeniería consiste en muchas otras cosas además de la codificación:

• Depuración
• Diseño
• Investigando
• Pruebas
• Configuración
• Construyendo / Compilando
• Reuniones

La respuesta a esto no se puede dar.

Soy el único desarrollador en este momento, escribo el 99.9% del código, el otro .1% es de nuestro diseñador. La mayoría de los días escribiré más de 1000, algunos días borraré 500 ~ líneas y otros no haré absolutamente nada. La planificación es esencial cuando eres la única persona que se desarrolla en una empresa de más de 30

Los programadores necesitan pasar más tiempo preocupándose por escribir código limpio y por qué lo están escribiendo. No cuántas líneas escriben. Otros programadores que tienen que estar constantemente detrás de usted para refactorizar su código no es divertido para nadie. Cumple con las expectativas del sprint. Comunícate cuando te quedes atrapado en un problema. Aprende de tus errores. Programa de pareja. Hacer revisiones de código. No escriba código solo porque llena el espacio, porque es obvio.

Aparte de eso … Depende. No hay nada más frustrante que tener que refactorizar 1000 líneas de código a una llamada API solo porque el programador anterior no pensó en mirar la documentación. ¡Esa es una métrica negativa de LoC allí mismo! Y es por eso que nadie debería preguntarle cuántas líneas de código escribe en un día.

Los idiomas como Java con el marco de trabajo de primavera y las utilidades de generación de código fuente, como los métodos getter y setter que usan un ide como eclipse, pueden agregar líneas rápidamente que realmente no te hacen ningún bien en lo que respecta a la experiencia de programación a la relación de línea de código. Algunos idiomas solo requieren que escriba varias líneas de código para agregar una pequeña funcionalidad. Java está en la cima de esa lista. Pruebe idiomas como python o ruby ​​o incluso perl para agregar habilidades sólidas de ingeniería. 100 líneas de código en ruby ​​o python son probablemente mejores que 250 líneas en java.

Depende del idioma también.
1. Los lenguajes funcionales como C generalmente tendrán más LOC que un lenguaje orientado a objetos como Java.
2. Si está utilizando un lenguaje como Perl o Java que tiene una gran cantidad de bibliotecas de terceros disponibles, el LOC para su proyecto en su conjunto (y, por lo tanto, lo que escribe en un día) sería menor. Probablemente pasará más tiempo buscando en Google componentes de terceros 🙂

Según mi experiencia, y lo que he visto con otras personas que conozco, habría más codificación en las startups que en las grandes empresas. Comencé mi carrera en una startup donde solíamos escribir código para PDA. Escribí poco menos de 10000 líneas de código C en 3 meses. Si considera solo el código que ha entrado en producción (ya sea interna o externamente), probablemente no haya escrito tanto código en los más de 7 años desde entonces, todo en una empresa mediana.

La respuesta puede variar enormemente. En el software que ejecuta el transbordador espacial, los desarrolladores promedian <5 líneas de código por día (1163 líneas / año-hombre). En el proyecto en el que trabajo actualmente, los desarrolladores promedian> 80 líneas por día (pero varía mucho con el tiempo: a veces es casi cero, otras veces es varios cientos).

La razón por la que hay tanta variación es que la respuesta depende de muchos factores:

1. ¿Qué lenguaje de programación se está utilizando? Como otros han señalado, algunos idiomas usan más líneas para hacer lo mismo.
2. ¿Qué tan hábil es el desarrollador? Un desarrollador más talentoso podría hacer lo mismo en menos líneas de código, o escribir código que necesita menos cambios a medida que se agregan nuevas características.
3. ¿Cuál es la naturaleza del software? Los programadores trabajan lentamente y con más cuidado en sistemas que exigen una fiabilidad extremadamente alta, como la aviónica o los núcleos del sistema operativo. En el otro lado del espectro, los sistemas de prototipo o prueba de concepto pueden escribirse muy rápidamente ya que la confiabilidad y la limpieza del código no son importantes.
   Esto juega con la pregunta sobre diferentes compañías. Un programador que trabaja en el núcleo del motor de búsqueda de Google, una fuente crítica de ingresos utilizada por millones de personas diariamente, probablemente cambia muy pocas líneas al día. Un programador que trabaja en una pequeña startup donde el tiempo de comercialización es primordial escribiría muchas más líneas por día … pero lo mismo podría ser cierto para alguien que trabaja en un nuevo proyecto en Google.
4. ¿Qué tipo de trabajo se está haciendo? Escribir una nueva característica a menudo implica escribir un código completamente nuevo que es una adición bastante separada, por lo que los programadores pueden escribir muchas líneas rápidamente. La corrección de errores en el código existente implica mucho más tiempo investigando el problema y pensando en sus ramificaciones, con relativamente pocas líneas que realmente cambian cada día. La naturaleza del trabajo a menudo varía en ciclos: principalmente las nuevas funciones funcionan cerca del comienzo de una versión, nada más que la corrección de errores al final.
5. ¿Qué cuenta como “escribir una línea de código”? ¿Qué pasa si modifica una línea existente? ¿Qué sucede si elimina dos líneas y las reemplaza por una nueva? (La métrica de “impacto” de GitHub es líneas agregadas + líneas eliminadas, por lo que creo que contarían modificando una línea existente como 2 líneas de “impacto”).
6. ¿Qué cuenta como una “línea de código”? Presumiblemente las líneas en blanco no cuentan … pero ¿qué pasa con los comentarios? ¿O líneas que contienen solo una llave de cierre? Si cuenta líneas o comentarios en blanco, los números variarán según el estilo de codificación (cantidad de espacios en blanco o cantidad de documentación en línea).

Los proyectos de código abierto son una excelente manera de investigar esto si está buscando datos más concretos. En GitHub, las vistas “Frecuencia de código” e “Impacto” son una buena visualización rápida. Aquí hay un ejemplo de un proyecto de código abierto en el que trabajo: https://github.com/adobe/bracket … Y con acceso al repositorio de origen en sí, puede hacer un análisis aún más profundo, como esta publicación de blog sobre el kernel de Linux: http://linuxator.wordpress.com/2… .

No suena demasiado alto, pero es como preguntar cuál es la cantidad promedio de pintura que un artista pone en un lienzo en un día. Si está trabajando en algo nuevo, puede escribir bastante. Al refactorizar, puede eliminar un poco. Otras veces puedes sentarte y pensar durante mucho tiempo.
Una mejor métrica podría ser mutaciones con cada mutación que tenga un peso basado en cuánto impacta en el sistema general, pero esto también es muy limitado ya que el verdadero impacto debe evaluarse en términos de valor comercial.

Eso depende principalmente de la empresa, así como de los proyectos que tiene asignados para completar. Por lo general, para compañías bien establecidas que ya han desarrollado un producto / servicio (s) y están en el negocio por más de 5 años, probablemente tendrá que pasar la mayor parte de su tiempo depurando código y agregando algunas líneas aquí y allá para corregir errores .

Esto puede cambiar si la empresa desea desarrollar un nuevo producto y tiene la suerte de ser asignado al trabajo del nuevo producto o si la empresa es una startup.

Recuerdo que trabajé en una empresa y el total de líneas de código que escribí yo y todos mis compañeros de trabajo no superaron las 100 líneas después de 6 meses de trabajar allí, simplemente porque la empresa tenía un producto que tenía algunos errores que no requerían más de Un par de líneas agregadas o eliminadas para ser reparadas.

Mientras no se sienta cansado.
No hay tal cosa como “demasiado”.
Ve lo más lejos que puedas. Empuja tus límites un poco más duro día a día. Y sigue continuando.
Para alguien, un simple programa para revertir un número es suficiente por un día. Para otros, pasar 4-5 horas en GitHub es una rutina. Por lo tanto, todo depende de cuánto lo desee y cuánto pueda tomarlo.

Esto es como preguntar cuántos bostezos hace el programador promedio en un día típico.

Hay una respuesta, pero no es una medida muy útil.

Las líneas de código son una de las * peores * formas de medir la productividad del programador. 10 líneas del código correcto pueden hacer el mismo trabajo que 200 líneas del código incorrecto, y hacerlo más rápido y limpio.

Lea “El mes del hombre mítico”.

Cuando fui a la universidad, dijeron que el promedio era de 10 líneas. Eso me parece un poco bajo.

Mi única muestra real de mi producción que rastreé fue de 250,000 líneas personales durante aproximadamente 5 años, y eso da un poco menos de 200 líneas por día. Sin embargo, había otras 4 personas en el código responsables de 250,000 líneas más, y obviamente escribieron el código, aunque solo 2 de ellos trabajaron los cinco años completos en él, y uno tenía otras responsabilidades. Esto tampoco cuenta el código que fue a la basura, solo las líneas que lo hicieron. El número era mucho más bajo por día al final que al principio, pero no tanto como la mayoría de los programas, porque se podían agregar muchas características en tiempo constante.

Creo en la declaración ” si hubiera tenido más tiempo , habría escrito menos código “.

después de escribir el código, voy a limpiarlo … generalmente después de que todo está hecho … he eliminado la mitad de mi código original …

así que para mí prefiero ver que produzcas un código pequeño pero bueno que miles y miles de líneas de código incorrecto.

Hola,

Soy desarrollador ui, así que codifico principalmente en javaScript, tengo 3 años de experiencia. En mi pequeña carrera he completado 6 proyectos, 5 de ellos fueron proyectos de desarrollo y 1 fue un proyecto de apoyo.

Yo diría que todos ellos eran totalmente diferentes. En proyectos de soporte, codificamos mucho menos. Quizás 10–20 líneas al día es muy productivo. Puede ir a 1–5 líneas la mayoría de los días. Muchos días incluso pasan sin una sola línea de código.

En el desarrollo de proyectos de codificación es más. En uno de los proyectos de pesadilla solía codificar casi 200 líneas al día. Pero allí estaba desarrollando una aplicación desde cero y era el único desarrollador de interfaz de usuario.

Espero que esto ayude

Si escribe código que genera código, entonces muy poco.

Tan poco como sea posible. Tanto como sea necesario.

45-60 líneas de código completamente comprobables a través de pruebas unitarias y pruebas de integración y que no rompió el sistema de construcción continua se cuenta informalmente como una productividad aceptable. Aunque contamos con herramientas para informar esta métrica, rara vez se analiza. La mayoría de las veces estamos demasiado ocupados escribiendo un buen código para resolver problemas difíciles.

Voy a decir generalmente que no muchos. Si está escribiendo un código nuevo, tal vez mucho. Al hacer cambios o corregir errores, puede cambiar o corregir solo varias líneas de código en un día.

La mayoría de las líneas que publico son en realidad código repetitivo que mi ide escribe para mí.

Si estoy en un nuevo proyecto y estoy escribiendo un montón de código nuevo (que casi todo es repetitivo o código que requiere poco), serán unos pocos cientos.

Si estoy cambiando las cosas a lo que quieren mis jefes y enviando correos electrónicos a la gente todo el día, entonces no demasiados. Tal vez como diez o quince.

Si estoy arreglando errores oscuros, puede ser mucho más pequeño. Tal vez una línea al día.

Editar: Creo que los principios 80/20 (¡o quizás los principios 99/1!) Son lo más importante aquí. La mayoría del código es código repetitivo y quizás el 10% del código dice algo significativo. Por lo tanto, establecer un nuevo código te da mucha LOC. Para cada línea de código que cambie (o cada línea completa de significado que escriba), debe leer y comprender muchas líneas de código. (Diré que necesitará leer de diez a 200 líneas de código para cambiar una línea de código o agregar una línea al código existente).

Una medida de productividad a menudo mejor es cuántas líneas de código puedo eliminar.