¿Qué tipo de desarrollador de software escribe más código?

Esta es una pregunta interesante, por lo que trataré de dar una respuesta más profunda en lugar de recitar algunos puntos.

Suponiendo la misma habilidad (por lo que la respuesta no es solo el codificador más asqueroso), la respuesta generalmente sería la que tiene que lidiar con el mayor contexto y puede aprovechar la abstracción lo menos posible.

Piensa en ello como un árbol binario. Podrías expresar algo de 10 niveles de profundidad con tan solo 10 números. O podría expresarlo en términos de muchos cientos de números de un árbol binario completo con 10 niveles.

En el primer árbol, hay mucho menos contexto en cada capa que la segunda. La estructura abstracta es mucho más significativa en términos de lo que se extrae que el contexto de los números específicos en el primer árbol.

Es un poco difícil de explicar, pero básicamente cualquier cosa en la que la mayor parte de lo que estás escribiendo es describir estructuras abstractas y aprovechar la abstracción en lugar de escribir componentes contextuales específicos tendrá menos código.

Por lo tanto, desde este punto de vista, el desarrollo del front end sería muy pesado en este tipo de trabajo contextual, porque la estructura en ciertas áreas puede permanecer en la misma capa conceptual, por así decirlo, pero puede tener 30 botones diferentes y 10 etiquetas, y varios Funciones onClick, etc.

También los proyectos que tienen que gastar mucho código trabajando con el sistema en lugar de trabajar en la lógica tendrán el mismo tipo de cosas.

Entonces, como si necesitara integrarse con un montón de bases de datos y API, y la mayor parte de su código es solo eso: en la misma capa conceptual, con poca lógica, enfocada principalmente en unir cosas.

Como habrás notado, tiene mucho más que ver con lo que estás haciendo en un proyecto que el título de tu trabajo.

También algunos proyectos en lenguajes de nivel inferior (piense ensamblador) que tienen que lidiar mucho con las restricciones de tamaño de bytes, así como cosas que tienen que depender de un conocimiento específico del sistema operativo y gastar mucho código “lidiando” con el sistema. mucho código

Es por eso que estoy emocionado de presenciar el surgimiento de plataformas sin servidor como Google ML y AWS Lambdas, porque gran parte de ese trabajo sucio se habrá ido y optimizado, dejando al desarrollador escribir menos código y permitiéndoles enfocarse en lo que importa.

Una vez escribí muchos miles de líneas de código importante de manera muy rápida y precisa en cuestión de semanas. La bala de plata era Prueba de Unidad.

Estaba creando la capa de manipulación de datos de un sistema bellamente diseñado y completamente diseñado. Estaba codificando completamente en objetos en C #, por lo que todo el entorno era muy puro y simple, con pocas influencias y limitaciones externas. El resultado fue cientos de métodos, algunos simples, otros muy complejos, que generalmente eran independientes entre sí.

Fui / soy un desarrollador altamente calificado en el entorno relevante.

Cada etapa del proyecto comenzaría con una breve comprobación de la cordura del diseño, que generalmente condujo a algunos cambios menores de diseño, y podría comenzar.

Primero, produciría cientos de pruebas unitarias (UT). Este es un trabajo muy productivo, porque simplemente no tiene que ser preciso, ni 100% minucioso, ni considerado cuidadosamente, ni probado cuidadosamente; puedes golpearlos hasta que tus dedos se cansen. Es el Santo Grial de la codificación rápida: su único objetivo es obtener el código para compilar:

• No es necesario probar los UT en el momento de la escritura; se probarán implícitamente cuando se usen más adelante.
• Si de alguna manera olvidas escribir un UT, o logras escribir un error en un UT, lo que significa que obtienes un falso positivo cuando se ejecuta, probablemente nunca importará. Ese error de UT tendría que alinearse perfectamente con un error presente en el código de la aplicación, y las posibilidades de que eso ocurra son bastante escasas.
• Si escribe dos UT que se superponen o prueban lo mismo, no importa.
• No hay forma de que un problema en una UT cause un problema en otra UT.
• No importa en qué orden escribas los UT, no dependen el uno del otro. Dilación sobre los difíciles durante el tiempo que desee.
• El código de la aplicación aún no tiene que existir.
• Puede agregar UTs a voluntad más adelante en el proyecto si piensa en otra cosa al escribir el código de la aplicación.
• Las interrupciones no importan, estás escribiendo material muy granular contra una especificación exhaustiva.

A continuación, escribiría el código de la aplicación para esa etapa, que por supuesto fue mucho más difícil. Pero ahora había estado pensando en las estructuras de datos y la semántica durante algún tiempo, y ya sabía exactamente lo que iba a escribir.

¿Alguna vez ha tenido que escribir el mismo código dos veces porque perdió su primera versión? Toma alrededor de una quinta parte del tiempo, porque ya sabes qué hacer. Fue más o menos así, a menudo escribiendo código tan rápido como pude.

Estaba codificando contra un diseño detallado con muy pocas dependencias internas y un conjunto completo de UT. Santo Grial otra vez; el objetivo es una compilación exitosa, podría escribir código muy interesante y desafiante a un ritmo vertiginoso.

• No hay necesidad de probar su código a medida que avanza, los UT lo harán más tarde.
• Si te pierdes algo, los UT lo recogerán.
• Si se hace evidente un nuevo requisito cuando se mira más de cerca un problema, es muy fácil agregar algunos UT y seguir adelante.
• Las interrupciones importan menos de lo habitual, está escribiendo material muy granular contra una especificación completa.
• Si algo necesita más reflexión, solo déjelo para más tarde, los UT lo mantendrán honesto.

El siguiente paso fue ejecutar los UT, corregir los errores que aparecieron, iterar hasta que estén limpios. Fácil. La codificación menos estresante que he hecho; Nunca pensé en mi trabajo cuando volví a casa.

“Bueno, eso es bastante casual”, puede decir, “¿cómo sabe que lo hizo bien?”

Debido a que la próxima semana, otros tipos escribirán y probarán el código de front-end que depende completamente de mi código, y estoy bastante seguro de que me avisarán si me perdí algo o me equivoqué.

Para mí, ha variado de un proyecto a otro, independientemente de la tecnología utilizada.

Escribí un programa integrado en lenguaje ensamblador Intel 6052 para un medidor de flujo de gas experimental. Eso fue bastante intensivo en código, ya que terminé portando un conjunto de métodos matemáticos de punto flotante Intel 8080 como parte del programa.

Escribí un controlador de dispositivo para una impresora / trazador electrostático. El desarrollo inicial requirió un uso intensivo del código, pero la depuración consistió principalmente en esperar que la máquina se reiniciara repetidamente, ya que los errores provocarían un bloqueo del sistema y la instalación de cambios requería un reinicio.

Escribí bastantes aplicaciones de escritorio, que en su mayoría eran intensivas en código en ese momento porque los marcos y las bibliotecas disponibles en ese momento eran mucho más limitados de lo que son ahora.

La mayoría de las veces hago trabajo de back-end, con un poco de interfaz. Algunos de ellos son de código pesado, otros son principalmente de configuración.

Si, como yo, está involucrado en todo el proceso, desde la discusión con los clientes sobre sus necesidades, hasta el diseño de una solución, la implementación, las pruebas y la depuración, la entrega y el soporte, descubrirá que algunos días requieren mucho código. , otros días tienen poca o ninguna escritura de código.

Cuanto más cerca esté del hardware, más específico tendrá que ser.

Si está trabajando en un lenguaje de alto nivel como JavaScript, ni siquiera tiene que especificar el tipo de una variable al definirlo, y puede reasignarlo con tipos de valores completamente diferentes en un solo comando. ¿Desea que una variable de cadena sea ahora una matriz de objetos? Simplemente cámbielo en una sola línea.

Pero si está en un lenguaje de bajo nivel como C ++, el tipo de variable realmente importa y con frecuencia maneja su administración de memoria. ¿Quiere cambiar una variable de cadena a una matriz de objetos? No será un comando simple y simple.

Mucha gente dirá que los buenos programadores escriben tan poco código como sea necesario, y eso es completamente cierto. El código conciso y legible es hermoso, efectivo y fácil de mantener. Es solo que, naturalmente, estará escribiendo más líneas / comandos cuando tenga que manejar cosas como memoria física, hilos de CPU, canalización de GPU, etc.

Agregaré a su lista uno que sea independiente del título del trabajo. Estos son desarrolladores que codifican en tecnologías antiguas / heredadas a diario. Podría ser una aplicación de escritorio, incrustada o incluso web. Por ejemplo, piense en el desarrollador que escribe el código MFC C ++ para una aplicación de gráficos. Tienen que escribir muchas líneas de código para una característica simple que podría haberse escrito con mucho menos en un marco moderno. Compare eso con alguien que está desarrollando una aplicación similar en WPF C # o JavaFX.

Las cosas que actualmente son autogeneradas por frameworks y scaffolders deben escribirse manualmente. Cuando hice mi pasantía, tenían una gran aplicación de procesamiento de imágenes escrita en MFC y C ++. Realizar pequeños cambios en la interfaz de usuario requería pasar un montón de eventos al constructor de la vista y declarar muchas variables / indicadores que MFC usa internamente. Huelga decir que todas sus aplicaciones modernas están escritas en .NET y las características críticas de rendimiento están escritas en C ++, donde se usa una clase de contenedor para interactuar con el código principal de .NET.

Los marcos de desarrollo web también están abstrayendo cada vez más el código tedioso y repetitivo para facilitar la vida del desarrollador. Por ejemplo, muchas plataformas que se basan en la arquitectura MVC proporcionan características de enlace de datos / modelo. Este es un gran aumento de la productividad, ya que no tiene que escribir usted mismo las asignaciones entre las entradas de la interfaz de usuario y sus clases de modelo.

Estoy de acuerdo con la respuesta de Garry Taylor de que son principalmente los desarrolladores de aplicaciones de escritorio los que escriben más código que otros tipos de desarrolladores.

Bueno, no importa cuántos pacientes un médico brinde consultas médicas. Un médico es médico y su trabajo es proporcionar consultas médicas. No importa cuántos. Lo que importa es qué tan bueno es el médico al proporcionar consultas médicas y, por lo tanto, cuidar a los pacientes.

Ah! lo siento, acabo de preparar su pregunta nuevamente y dice “Desarrollador de software”. Bueno, todavía puedes relacionarte con el ejemplo anterior que di. No importa cuánto código escriba un desarrollador. Cuando habla de un perfil de “desarrollador de software”, está hablando de escribir código. Lo que más importa es cuál es la calidad del código que él / ella escribe, y sirve al propósito o no.

En una nota seria, la cantidad de código depende de cuán hábil e inteligente sea el desarrollador. El mismo código se puede escribir de muchas maneras usando el mismo lenguaje de programación y tecnología.

Espero haber podido responder a tu pregunta.

te perdiste uno

• uno malo

Los desarrolladores de software no deben ser juzgados por la cantidad de código que escriben.

Cualquier desarrollador puede escribir líneas de código, es muy fácil ser ineficiente y escribir toneladas de código. El truco es obtener el código más eficiente con la menor cantidad de líneas escritas.

También observe los diferentes tipos de programación, los lenguajes de alto nivel lo hacen programar de cierta manera y cuando compila el código, se vería completamente diferente. Entonces, ¿estás buscando quién escribe la mayor cantidad de código? ¿O quién pasa la mayor cantidad de tiempo desarrollando código?

Durante la mayor cantidad de tiempo desarrollando código, aún agregaría una nueva categoría de nuevo desarrollador. Los desarrolladores senior generalmente tienen almacenes de código que reutilizan todo el tiempo o están en una posición de gerente de proyecto técnico que Code Monkey

El que escribe un programa para escribir el código para él.

Honestamente … quiero un objetivo difícil … No vayas a escribir la mayor cantidad de código. Ve por hacer un buen trabajo, con un recuento de línea NEGATIVO

Solo con el objetivo de reducir la cantidad de código utilizado en lugar de aumentarlo, lo mejorará. Ser el tipo que elimina la biblioteca o función no utilizada, te hará fácilmente convertirte en una de las personas más queridas y valiosas del equipo.

Las líneas de código y quién escribe más es una métrica inútil. El impacto es lo que importa.

En mi propia experiencia personal, son las aplicaciones de escritorio.

No pretendo que sea una verdad global, solo mi propia experiencia.

Solía ​​volver a escribir el código final, cosas que se ejecutaban en servidores Sun para la industria financiera. Lo que ocurre con las grandes empresas es que a menudo tendrán un conjunto de requisitos, y esos requisitos no cambiarán durante años. Planean proyectos de software para los próximos años. Por lo tanto, puede trabajar en estos servicios durante más de 10 años y terminar con menos de 100,000 líneas de código.

Por otro lado, las aplicaciones de escritorio pueden cambiar rápidamente y es una carrera enviarlo y comenzar a ganar dinero. La última aplicación de escritorio que escribí tomó 4 meses y terminó en aproximadamente 45,000 líneas de código. Entonces, en términos de “líneas por día”, las aplicaciones de escritorio terminan siendo mucho más, en mi experiencia.

Creo que las aplicaciones móviles son muy parecidas a las aplicaciones de escritorio, ya que es una carrera terminarlas, pero en general tienden a ser más pequeñas. Mi aplicación de 45,000 líneas es bastante pequeña en cuanto a aplicaciones de escritorio, pero probablemente bastante grande para una aplicación móvil.

Creo que las cosas web pueden estar en los extremos opuestos del espectro, he trabajado en sitios web comerciales que son <1000 líneas de código de fondo, pero también he visto 100 veces más grandes y más.

No puedo comentar sobre sistemas / cosas integradas realmente.

Si por “la mayoría”, quiere decir “la mayoría de las funciones”, el tipo de desarrollador que trabaja en los problemas más complejos.

Si te refieres a “la mayoría de las líneas de código”, entonces, como dijo Gage Randall, el programador trabaja más cerca del metal. Pero C no es muy bajo nivel. Un programador en lenguaje ensamblador produciría muchas más líneas de código para un programa dado escrito en ensamblador que un programador en C (para el mismo programa) escrito en C. printf es rápido y es una línea. Una función similar en el ensamblaje podría ejecutarse en 10 o 20 líneas (o mucho más, si desea sobrecargarla para manejar todos los tipos de datos). Y no puede acercarse más al metal que al ensamblaje (excepto el microcódigo en algunas máquinas).

Yo diría que cualquiera de las personas que actualmente están en el proceso de desarrollar algo (especialmente por su cuenta) van a escribir significativamente más código que la mayoría de las personas. Esto se debe a que están trabajando solos, por lo que escriben más código personalmente y no mantienen nada, por lo que prácticamente escriben código todo el tiempo. Sin embargo, de estos, los desarrolladores front-end y los desarrolladores móviles estarían bastante unidos, porque solo hay una tonelada de código que se escribe inicialmente.

Si no es así, diría que serían desarrolladores front-end, porque pasan la mayor parte de su tiempo (al menos en mi experiencia) escribiendo código para nuevas características. Además, el código que escriben los desarrolladores front-end es muy extenso y se necesita mucho para realizar incluso tareas simples.