¿Dónde trabajan los desarrolladores de software débiles?

Tenga cuidado al definir a los programadores supuestamente “débiles”.

Debido a que una compañía con los llamados desarrolladores de “estrella del rock” a bordo suele ser una clara indicación de un entorno de trabajo disfuncional, uno en el que un pequeño número de personas realiza tareas de selección y otra en la que el conocimiento no se transmite a través de la organización.

Una organización es sólida solo si todos están capacitados y actualizados, y se documentan los conocimientos. Y realmente me refiero a todos. Porque, ¿qué pasa si estas élites son despedidas, o se van, o mueren o desaparecen de alguna manera? La organización tiene que seguir croando de alguna manera o adquirir experiencia costosa en forma de contratistas o nuevas contrataciones. De cualquier manera, están rellenos en comparación con si hubieran extendido la experiencia orgánicamente.

Por mi propia admisión, también me definiría como un programador “débil”. He soportado la humillación de no tener idea en más de una ocasión durante la codificación de entrevistas. Afortunadamente tuve la humildad de aprender de estos y seguir perseverando. Me las arreglé para lograr todo lo que quería lograr con una capacidad de atención más larga que la mayoría, en lugar de un coeficiente intelectual estratosférico, y estoy feliz de que estoy razonablemente libre del efecto Dunning-Kruger.

Los desarrolladores débiles que se convierten en gerentes y ya no se desarrollan ya no son desarrolladores. Son gerentes. Pueden ser muy buenos en eso y aprecian las dificultades.

Los desarrolladores débiles trabajan en todas partes. Los trucos son:

(1) Haga que su equipo sea seguro; evitar que los débiles hagan daño al equipo o que su producción llegue a tiempo, dentro del presupuesto y cumpla con los requisitos.

(2) Convierta a los débiles en miembros productivos del equipo, asignando, como ya han sugerido algunos encuestados, tareas a los débiles que pueden lograr con éxito.

(3) Ayuda a los débiles a ganar habilidades.

(4) Diseñe el proyecto y los programas para que los fuertes:

1. (a) cree una arquitectura y un diseño que aísle los elementos duros en bibliotecas y marcos, los que los miembros fuertes seleccionan o desarrollan y que todos los demás utilizarán.
2. (b) cree patrones, ejemplos, plantillas (e incluso documentación) para que todos puedan plagiar el uso de mejores prácticas de las bibliotecas y los marcos.

Cuando haces eso:

(1) Los desarrolladores fuertes se divierten produciendo cosas buenas que otros usarán correctamente sin necesitar más que un comienzo guiado. La reputación de sus gurús crecerá, por haber hecho lo difícil y facilitar su explotación. Pasan el trabajo repetitivo a los más débiles.

(2) Los más débiles producen muchas instancias necesarias que usan lo que los fuertes han producido.

(3) Las fallas duras y los errores de interacción en el software subyacente están aislados en las bibliotecas.

En términos OO, los fuertes crean las clases, mientras que los débiles crean las instancias.

No estoy inventando esto. Muchas compañías han estado haciendo esto durante aproximadamente 60 años.

Vivo en Rusia, pero lo que está escrito a continuación es cierto para toda la ex URSS y probablemente también para Europa del Este. Entonces, ¿dónde trabajan todos esos tipos?

Outsourcing Las grandes compañías de outsourcing como EPAM y Luxoft son el paraíso para pintores y yeseros de programación. Esto sucede debido a una combinación de los siguientes factores:

• Salarios bajos. Las empresas de outsourcing venden personas, no productos. Cuanto más bajo es el salario, más alto es el beneficio
• El 99.9% de los proyectos es algún tipo de automatización de negocios, ya sea PHP / MySQL basura o Java / Oracle basura o .NET / SQL servidor basura. Como resultado:
• Bar de alquiler muy bajo. El mejor tipo de empleado son los graduados universitarios. Los talentosos se van muy pronto o son promovidos a líderes / arquitectos

Servicios de TI del gobierno. Simplemente visite el portal de servicios estatales de Rusia (gosuslugi) o el portal de inspección fiscal y obtendrá la idea de qué se trata la programación débil. Incluso la contratación externa se ve bien en comparación con esto.

Primero: Todos somos / fuimos malos desarrolladores de una forma u otra.

Segundo: Para resumir una larga historia: ¡En todas partes!

La cantidad de malos ingenieros que conocí en persona (estudié o trabajé) que lograron encontrar su camino en prácticamente todas las empresas de “nivel A” es increíble (y si no me cree, simplemente elija cualquier SDK / “excelente código fuente del producto “y eche un vistazo).

Para más del 80% de las empresas con las que un desarrollador soñaría trabajar. El proceso es una entrevista de panel de pizarra blanca de 4 horas que se centra solo en algoritmos / estructuras de datos. Y luego estudiar “descifrar el código de entrevista” y practicar en “LeetCode” durante unos meses es una receta comprobada para pasar … También recuerde, los solucionadores de algoritmos contratan solucionadores de algoritmos. ¡Hay un gran ego en esta industria, y resolver las preguntas de la entrevista del código se convirtió en una especie de culto!

La ingeniería es una ciencia aplicada, el envío de software de calidad es un proceso mucho (¡mucho!) Más complicado que escribir estructuras de datos (aunque no estoy negando el hecho de que debería ser un elemento importante en una matriz de contratación).

Pero una buena parte de la tecnología. las empresas aún no pueden obtenerlo. Si contrató a alguien solo porque conoce los intentos y los árboles binarios negros y rojos, podría perder una cantidad de tiempo increíble (hasta el punto de afectar realmente la entrega) discutiendo temas sin sentido como: “No me gusta la excepción marcada en Java, no los usemos “o” No me gusta OOP “! Porque este tipo o ese tipo que nunca entregó un sistema a gran escala listo para la producción, quiere sentirse tan especial y más inteligente que James Gosling … Y con 2 o 3 personas así en un equipo, entonces buena suerte con la entrega de un código de calidad a tiempo .

Otro elefante en la sala que debe abordarse es la “cultura bros hiring bros”, muchas personas serán más empáticas con un candidato con el que sienten que “pueden beber una cerveza después del trabajo” (literalmente me han dicho eso ¡por un compañero entrevistador una vez!) Entonces, edad, sexo, origen étnico, acento, todos cuentan. Al menos en el entrevistador subconsciente.

Me definiría más como un administrador de sistemas que escribe código que un desarrollador de software, pero siempre he trabajado con desarrolladores de software y los he apoyado y, a veces, he tenido trabajos de desarrollo, por lo que creo que puedo responder esta pregunta desde adentro.

Primero, llamaré a BS a cualquiera que diga que tienes que tener un título en CS o un campo relacionado para ser un desarrollador de software sólido. Muchas de las mejores personas con las que trabajé tenían antecedentes militares donde aprendieron a trabajar con el equipo y a hacer el trabajo. Otros tenían un título en algo más y eran autodidactas en codificación, tendían a ser mucho mejores trabajando con los expertos en la materia y aprendiendo nuevas habilidades. Las personas con títulos en tecnología tendían a estar demasiado seguras de saber la forma correcta de hacer las cosas, incluso cuando el jefe decía que eso había sido considerado y que íbamos a hacer algo más por razones comerciales. (Estas son generalizaciones, por supuesto).

Luego, la definición de débil es muy subjetiva. Siento que no soy muy bueno escribiendo código nuevo. Si me entrega un nuevo y completo proyecto en el que empiezo sin nada, comenzaré lentamente, pero eventualmente mi proyecto terminado tendrá un conjunto completo de pruebas y será aprobado por expertos en la materia o clientes, mientras que otros desarrolladores que conozco tocarán algo a su mejor estimación de cómo el proyecto debería funcionar muy rápidamente. Dependiendo del juez, cualquiera de nosotros podría definirse como débil o fuerte según este desempeño. Aun así, soy lento en un prototipo rápido (si es que puedo codificar de esa manera) y cuando me veo obligado a construir algo al nivel que es mi defecto, la mayoría de los codificadores que conozco pueden quejarse, pero lo hacen de manera más oportuna. Realmente me gusta consultar con expertos en la materia, para los cuales CS y los programas de ingeniería tienden a preparar mal a las personas. (No siempre puede contar con que su diseño y las hojas de especificaciones sean correctas en estos aspectos, a veces tiene que llamar a alguien y verificar dos veces).

Por otro lado, creo que soy bastante fuerte trabajando con código heredado. Puedo averiguar qué se supone que está haciendo, asegurarme de que sea (agregar pruebas), arreglarlo y expandirlo. Conozco a muchos desarrolladores que solo juzgarán dicho código como un montón de basura y le dirán a su jefe que debería ser reemplazado. Esto a pesar del hecho de que la “gran reescritura” generalmente no es buena para los negocios. Tal vez el código es un montón de basura, pero ¿quién es un desarrollador débil: el que puede salvar con seguridad un activo comercial problemático o el que lo abandona por una alternativa arriesgada que encuentran más divertido?

Y el código heredado podría ser algo que escribió el codificador que acaba de renunciar o está de vacaciones esta semana, no solo las cosas que han estado flotando durante 3, 5 o 10 años más.

A menudo, débil o fuerte tiene más que ver con lo que una organización necesita esta semana que con cualquier otra cosa.

Además, he trabajado con personas que son un experto absoluto en tecnología o lenguaje de programación X. La mayoría de las personas en la organización los definiría como un programador fuerte. Luego, generalmente por razones comerciales o porque pasa el tiempo, se implementa un nuevo lenguaje o tecnología. Esa persona puede ser completamente incapaz de adaptarse (a veces incluso una nueva versión de la tecnología es un problema). (Tenga en cuenta que estas personas siempre parecen ser personas que aprendieron en la escuela, no las que tenían antecedentes militares o autodidactas). ) Otras personas que simplemente continúan haciendo su trabajo no pueden tener problemas para convertirse a nuevas tecnologías. ¿Quién es el programador más fuerte, con el que puede contar para realizar el trabajo cuando comienza a usar MySQL en lugar de Oracle o el que generalmente es súper productivo pero está completamente bloqueado durante 2 meses y solicita ir a clases cuando Microsoft implementa un nueva versión de SQL Server?

Hay personas que no son aptas para el desarrollo de software y que acaban de ingresar. Lamento la idea de que todos deberían aprender a codificar, porque creo que para muchas personas hay muchos mejores usos de su tiempo. Si ha aprendido el desarrollo de software y le gusta, es un gran campo y hay un lugar para sus fortalezas. Si lo odias, hay otros campos donde puedes aplicar ese fondo. En ambos casos, áreas como la seguridad informática pueden interesarle. Sé que varios de mis ex compañeros de trabajo que querían hacer algo más continuaron enseñando matemáticas en la escuela secundaria. (Les encantaba el software, pero querían hacer algo más después de una larga carrera). Muchas personas con una filosofía o psicología parecen tener buenos resultados en informática, lo contrario podría ser cierto. Existe una gran necesidad de abogados de propiedad intelectual con experiencia en software. No soy un consejero de carrera, esto es justo lo que sé de mi cabeza.

Esta es una pregunta difícil de responder porque ¿qué define a un programador débil?

Trabajé para una empresa que contrató a un chico nuevo. Se rumoreaba que era un tipo talentoso. Terminó la entrevista sin ningún problema.

Pero, cuando se trataba de trabajar, era horrible. El fue lento. ¡Confió mucho en Google! Dejó vulnerabilidades de inyección SQL en el código. No probó muy bien su código e hizo suposiciones sin considerar las posibles ramificaciones de lo que estaba haciendo. ¡Incluso su sangría apestaba!

Sin embargo, era apasionado. Y determinado. Se iba a casa todas las noches y estudiaba para el trabajo. Pasaba la hora del almuerzo codificando proyectos personales. Se quedó sin pagar para cumplir con los plazos.

En cuestión de meses pasó de ser un mal programador a ser un activo para la empresa. Eso fue solo a través del trabajo duro y la determinación.

No olvidemos que muchas de las grandes startups que ahora están en auge fueron iniciadas por desarrolladores que no tenían / ​​mucha experiencia en la programación en el entorno comercial. El código de Facebook fue (y todavía está en algunos lugares) ¡horrible! Zuckerburg nunca ha sido un gran programador y se rumorea que ya no puede escribir software.

Además, mire todos los errores que Twitter, Google, Facebook, etc. dejan en su código. Es por eso que tienen perfiles en HackerOne y BugCrowd porque sus propios desarrolladores dejan errores triviales en su código que hacen que otros exploten su sistema. En mi sincera opinión, los errores triviales como XSS, Inyección SQL y Ejecución remota de código no deberían existir en las plataformas de hoy … pero solo muestra que incluso los desarrolladores que trabajan para las compañías más grandes del mundo todavía están cometiendo errores escolares.

Por otro lado, mire a Notch. Creó uno de los juegos más populares del mundo. Se destaca por ser un mal programador. Lucha con problemas de salud mental y no puede replicar su éxito porque las personas tienen una visión tan alta de los programadores que es difícil para él estar a la altura de ese nombre.

Aquí hay un secreto. Ser un programador fuerte no siempre es útil, importante o incluso deseable. Y un equipo lleno de grandes programadores es a menudo disfuncional y casi siempre ineficiente para cumplir los objetivos del equipo.

Si tuviera que encontrar el equipo ideal de programación de dos pizzas de, digamos, siete personas, tendría al menos una persona con cada una de las siguientes habilidades básicas (puede hacer que las personas encajen en más de una categoría):

Tres de lo que llamarías programadores fuertes

• Un solucionador de problemas curioso, del tipo que es agnóstico hacia las herramientas y los lenguajes de programación, curioso por aprender y se preocupa profundamente por encontrar la mejor solución técnica, incluso si eso significa nadar en aguas desconocidas (por ejemplo, adoptar nuevas tecnologías). El último puerto de escala para problemas relacionados con la integración de sistemas, sistemas múltiples y otros problemas complejos.
• Un programador incondicional que está contento con las herramientas y los lenguajes que estamos utilizando (tienden a odiar que los obliguen a trabajar fuera de su tecnología preferida). Este es el tipo para el que el código es el fin, no un medio para un fin. El último puerto de escala para problemas técnicos que confunden al resto del equipo.
• El hacker de sombrero blanco: también tu experto en redes, cualquier conocimiento de redes que esta persona no tenga, solo puedes Google. La persona que enloquecerá por la seguridad, como el ingeniero, a menudo los ignorará, pero los necesita en la habitación. Si no tienes a alguien que viva seguridad, no vas a construir nada útil hoy.

El resto, miembros igualmente importantes:

• El ingeniero de software: la persona apasionada por la ingeniería de software *, que sigue las mejores prácticas, desea un diseño en su lugar, mira con anticipación las consecuencias de las decisiones. No siempre escucharás a esta persona, pero necesitas esa voz en la habitación. Esta es la persona que se queja de no hacerlo bien ágilmente, de omitir etapas en el proceso de lanzamiento para satisfacer a un cliente problemático. Esta persona ahorrará el culo de su empresa semanas, meses o años más adelante.
• El adherido concienzudo: el codificador que hace cumplir las convenciones, se asegura de que la ingeniería de construcción de su proyecto cumpla con las especificaciones y, por ejemplo, una nueva persona puede unirse a su equipo y tener un entorno de desarrollo y desarrollo actualizado en una hora. Aplicarán convenciones de código, harán revisiones de código real, se asegurarán de usar Git correctamente, tendrán una visión sólida de las pestañas y los espacios, podrían ser un poco más antiguas y parecer lentas y metódicas a sus jóvenes pistolas.
• El recolector de información: esta es la persona que no odia escribir tanto como el codificador promedio (es decir, no le gusta pero no lo detesta). Molesto y quisquilloso con la documentación, especialmente con la documentación actualizada * concisa *. Idealmente, es un poco vago y le encanta la automatización para que no obtenga tomos de documentación obsoleta que nadie mira. Esta persona también puede escribir correos electrónicos de longitud de tweet que comuniquen clara y transparentemente el quid de la cuestión y no tiene precio para actualizar a cualquiera que no pueda estar allí para reunirse personalmente con el equipo. También obsesivo con el monitoreo y estar al tanto de lo que realmente sucede con sus sistemas. Un buen indicador sería cuán entusiastamente esta persona habla sobre la observabilidad.
• El comunicador: esta persona generalmente sería el gerente de una empresa convencional, pero no estamos tratando de serlo. Esta persona debe ser un miembro igual del equipo con responsabilidades diferentes a los demás, pero no un superior con ‘informes’. Todos los miembros deberían poder hablar con el resto de la organización, pero esta persona y el recolector de información son las personas clave. Trae en términos molestos como prioridades comerciales y demandas de los clientes, * debe * tener el respeto del equipo. Puede ser el maestro de scrum con ingeniero y suplente de stickler.

He gestionado el desarrollo de software y también he escrito mucho código, tanto en compañías pequeñas (6 personas) como grandes (Raytheon, Rockwell, TRW). Siempre hay una distribución de talento, a menos que esté haciendo el trabajo solo. Las grandes organizaciones siempre tienen algunas personas capaces de esconderse en la carpintería que no hacen nada de valor y, a menudo, en realidad obstaculizan a las otras personas en un proyecto. Sin embargo, el punto principal que me gustaría destacar es que toda la evolución de la codificación ha sido la creación de herramientas y procesos que permiten que las personas con hábitos de trabajo, habilidades y conocimientos más pobres aún puedan contribuir positivamente al grupo. Tales cosas como herramientas de depuración, IDE, conjuntos de pruebas, revisiones de códigos, manuales de codificación, CMMI y muchos otros están destinados a tratar de asegurarse de que las personas cometan menos errores, los encuentren más rápido o no arruinen el trabajo que otras personas ya tienen hecho. No funciona todo el tiempo, pero funciona con la frecuencia suficiente para que la mayoría de las grandes empresas y muchas pequeñas adopten una variedad de ellas para ayudar a reducir el desperdicio y el esfuerzo. Alguien más señaló que la mitad de todas las personas que codifican están por debajo del promedio (una buena tautología), pero lo más importante es darse cuenta de que con el enorme crecimiento de los trabajos relacionados con el software, la persona promedio general que está siendo contratada tiene que ser más pobre que cuando la industria era pequeña y para hacer algo, alguien tenía que ser muy inteligente. Simplemente no hay muchas personas muy inteligentes en el mundo.

Lo creas o no, los desarrolladores de software débiles son tus superiores.

Trabajo en TI durante aproximadamente 10 años, principalmente en pequeñas y medianas empresas (20–300 empleados). En este tipo de empresas, los enlaces más débiles progresan más rápido en el líder . Es una paradoja pero es verdad. Aquí hay algunos ejemplos del mundo real.

Ejemplo 1: Si bien los buenos desarrolladores trabajan en proyectos heredados, el mal desarrollador se justifica a sí mismo ante la administración porque todo el proyecto se realiza de la “manera incorrecta”. Así que el mal desarrollador fue ascendido a líder de equipo con la misión de hacerlo “de la manera correcta”.

Ejemplo 2: la empresa tiene un equipo de desarrolladores trabajando en un proyecto muy grande. Necesitan un gerente de proyecto, por lo que promueven el desarrollador más débil a gerente. Nadie lo echaba de menos como desarrollador porque la persona era muy mala en la codificación y la gestión justificaba este movimiento al no necesitar unos meses adicionales para presentar una nueva persona al proyecto.

Ejemplo 3: El inicio muy en perspectiva tuvo una gran expansión en el número de desarrolladores. Entonces promovieron a los desarrolladores que trabajaban más tiempo en la compañía como líderes de equipo. Su calidad de codificación puede ser superada por cualquier niño en la escuela primaria. Trabajaron más tiempo en la empresa porque trabajaban por un salario mínimo. No se confundan porque no aceptaron el salario mínimo porque creían en el producto y mejores días, aceptaron el salario mínimo porque nadie quería pagar más por su nivel de habilidades.

Ejemplo 4: Otra startup en perspectiva tenía dos tipos de personas en equipo. A los que no les importa y los que quieren hacer las cosas bien. Después de unos meses de lucha contra la gestión ignorante y la mala parte del equipo. Todos los buenos desarrolladores abandonan sus trabajos. Adivina quién fue ascendido para administrar un nuevo equipo.

Ejemplo 5: Un desarrollador de software muy malo fue despedido por un mal desempeño. Él demanda a la compañía por despedirlo y gana. Su aumento fue que escribe la mayoría de las líneas de código al día de todos los desarrolladores, por lo que está haciendo la mayor parte del trabajo. Esto era verdad Personalmente refactoricé su clase de 8000 líneas de código a 230 líneas. Más tarde, la compañía le dio un año de sueldo para dejar de fumar.

Ejemplo 6: El desarrollador malo siempre se quejó a la gerencia sobre la revisión del código a la que otros desarrolladores lo obligan a asistir porque él era la única persona en toda la empresa para crear códigos de mierda que causen caos en cada confirmación. Después de un tiempo, convenció a la gerencia de que la revisión del código era una pérdida de tiempo y dinero y, al no hacer las revisiones del código, la compañía ahorrará $ XXX. Se convirtió en líder de equipo y luego en líder de departamento porque todos los buenos desarrolladores abandonaron sus trabajos a los pocos meses de su promoción.

Ejemplo 7: La rápida y creciente startup de TI demandaba recursos humanos. Entonces contrataron a toneladas de desarrolladores de software. Todos los desarrolladores que no se estaban presentando como programadores fueron promovidos a gerente de proyecto o representante de ventas y muy pocos fueron transferidos a marketing, equipo de diseño y rara vez desarrolladores.

Ejemplo 8: En muchos casos, los codificadores débiles que no eran lo suficientemente comunicativos para el rol de líder de equipo y gestión de proyectos se trasladaron a analistas de datos, diseñadores de software, arquitectos de software, etc.

Ejemplo 9: En empresas más grandes, el desarrollador va y viene. Por lo general, los buenos desarrolladores se van por un trabajo mejor pagado y los desarrolladores débiles se quedan porque obtuvieron un buen trabajo seguro con un salario decente. Después de un período de pocos años. Los desarrolladores débiles solo son constantes en la empresa, por lo que son los primeros en ser promovidos.

Tengo muchos más ejemplos. No tiene sentido escribirlos todos. El punto base es que si usted es un codificador débil, todavía hay una buena oportunidad para que tenga un buen trabajo con un buen salario (a menudo mejor que un buen codificador). Y si usted es un buen programador, probablemente no será promovido porque es un recurso valioso como programador. Si la Compañía lo promueve, no habrá nadie para hacer las cosas.

Puede encontrar esto extraño, pero muy pocas compañías valoran a sus desarrolladores como Google, Facebook, Amazon, etc. En la mayoría de los casos, el desarrollador de software se considera una fuerza laboral sobrepagada que siempre genera pérdidas para la compañía. Mientras que en realidad es todo lo contrario.

Este tipo de situación me enfurece mucho porque, como desarrollador de software, no puedo hacer mi trabajo porque todas las otras etapas del desarrollo del software no se realizan correctamente porque lo hacen ex desarrolladores débiles que continúan haciendo un trabajo débil en sus nuevos puestos.

En todos lados.

Para mí, un desarrollador de software débil es alguien que tiene grandes dificultades para aprender nuevos conceptos técnicos y nuevas herramientas y técnicas, y es alguien que lucha por razonar de manera organizada, estructurada y lógica y en diferentes niveles de abstracción y detalles. La mayoría de estos desarrolladores, naturalmente, terminan en compañías y organizaciones que tienen “problemas de TI”, es decir, casi todas las empresas y organizaciones, desde aerolíneas hasta grandes bancos, agencias gubernamentales y telecomunicaciones, lo que sea.

Estos lugares tienden a contratar consultores y contratistas. No tienen ni idea de cómo medir la calidad del software. Muestran una tendencia a asignar personas no técnicas, como MBA y contadores con un certificado de MP, a roles de gestión de proyectos. Esto crea una situación en la que hay dos campos: los empresarios (gerentes) y los ingenieros / desarrolladores. Un campamento habla ruso y el otro habla chino. Entonces, la gerencia termina midiendo todo sobre la base del costo a corto plazo.

En general, es bastante fácil escribir software malo y salirse con la suya en estas organizaciones. En la mayoría de los casos, el software no necesita funcionar de manera óptima, siempre hay mejoras incrementales y parches que se pueden hacer más adelante y para las pocas partes críticas, solo se necesita un puñado de grandes desarrolladores para trabajar en ellos.

Los desarrolladores débiles trabajan en todas partes y son una parte importante de la industria. La mayoría de las compañías no son Google o Amazon y no pueden atraer a los mejores talentos, de hecho, la mayoría de las compañías son bastante aburridas. Si una empresa no puede atraer al mejor talento, su siguiente mejor estrategia es encontrar una manera de tener éxito con desarrolladores promedio o incluso por debajo del promedio. La gran mayoría de los puestos de desarrollador no están en desarrollo de productos, mantienen sistemas existentes o ayudan a implementar productos desarrollados por otra persona. Este tipo de trabajo generalmente requiere mucha menos experiencia que el desarrollo de productos. Muchas de las tareas son repetitivas o siguen patrones bastante bien establecidos. Copiar y pegar es la habilidad más importante en este nivel. Los desarrolladores débiles proporcionan un buen valor a buen costo en este nivel. ¿Por qué contrataría a un ingeniero superior fuera de Google si todo lo que necesito es alguien para mantener y ejecutar scripts de importación de datos? Esa tarea no puede ser realizada por un no desarrollador, requiere cierta habilidad de desarrollo. Pero ciertamente no requiere un ingeniero superior con el costo del salario que podrían exigir. No es que sea capaz de retener a un ingeniero superior en ese rol de todos modos, no sería lo suficientemente desafiante.

Muchos de ellos no lo hacen. O trabajar en Starbucks. O trabaje por el maní en lugares que prefieren barato a bueno.

O, trabajan en trabajos donde la programación no es importante. (La gente me contrata para diseñar sistemas, hacer estudios y escribir propuestas. Puedo, y lo he codificado, pero no recientemente, y estoy oxidado, si no débil. No me contrataría para escribir código en estos días. )

ADICIÓN:

Debo agregar que también hay muchos graduados nuevos que entienden los conceptos básicos, pero necesitan unos años para aprender los entresijos del diseño y estructuración de software, escribir código limpio, documentar, evaluar, etc. Tienden a trabajar como pasantes, o ingenieros junior, o desarrolladores junior, y mejorar. O se mueven a roles que (algunos empleadores piensan) no requieren tanta habilidad, especialmente pruebas, administración de configuración, tal vez administración de sistemas.

Del mismo modo, hay personas con antecedentes en varios otros campos, que recogen algo de codificación en el camino, por ejemplo, analistas financieros que tienen que construir hojas de cálculo y tal vez escriben algo de SQL para acceder a los datos. Muchos de ellos escriben código horrible, y / o simplemente no hacen mucha codificación.

Los desarrolladores de software débiles trabajan en todas partes en TI comercial que incluye organizaciones comerciales y gubernamentales. Al igual que los desarrolladores de software débiles, la gestión de desarrollo de software débil es omnipresente. Debido a esta “debilidad”, los proyectos de desarrollo de software fallan rutinariamente: la falla se define por un sistema que está muy por encima del presupuesto y / o cronograma o donde se han gastado $ millones y no se logra ningún progreso real.

Aquí estoy hablando sobre el software comercial para el papel electrónico dentro de las empresas y organizaciones gubernamentales: esta es mi caseta de gobierno. No estoy hablando de empresas que fabrican y venden aplicaciones y otro software.

Permítame dibujar un dibujo para usted usando un edificio físico como comparación: cuando se va a construir un edificio físico, hay un proceso establecido que se parece a esto:

• Un arquitecto diseña la estética de un edificio y hace modelos 3D y de cartón.
• Un ingeniero estructural / mecánico diseña la estructura del edificio, electricidad, HVAC, plomería, etc. Los planos son aprobados por ingenieros municipales.
• Un contratista toma el trabajo y planifica y ejecuta la construcción de acuerdo con los planos del proyecto: los subcontratistas son contratados para colocar los cimientos, construir las paredes de carga, piso por piso y hasta el techo. Luego plomería, HVAC, electricidad, luego enmarcado interior y paneles de yeso. Luego accesorios y pintura.

Existen prácticas de ingeniería de software establecidas para imitar un nivel comparable de rigor donde el software está diseñado a fondo, luego se ha diseñado meticulosamente y, finalmente, los programadores adquieren las habilidades adecuadas para construir y probar el sistema.

El desarrollo ordenado de los sistemas de software rara vez ocurre como el anterior.

Lo que sucede rutinariamente se puede demostrar con la siguiente analogía: Cómo se vería un edificio físico si se construyera como se construye el software:

• Un arquitecto diseña la estética de un edificio y hace modelos 3D y de cartón.
• El diseño de ingeniería estructural se omitiría (o al menos se daría un buen servicio)
• Se contratarían balsas de oficiales: carpinteros, albañiles, electricistas, plomeros, etc., entregarían los dibujos y se les pediría que construyeran.
• El edificio procedería de una manera caótica y poco sólida y los pisos se derrumbarían y la estructura se derrumbaría y los hombres del viaje serían los culpables del fracaso (o simplemente dejarían de hacerlo por frustración).
• El proceso de construcción del edificio procedería al estilo de arrojar barro contra una pared y mantener lo que se pega.

¿Un edificio en el que te gustaría vivir? No lo creo.

Tenga la tranquilidad de que los proyectos de software del Departamento de Defensa se gestionan adecuadamente y en realidad se parecen a una progresión ordenada y cuentan con ingenieros capacitados en todos los niveles y casi todas las publicaciones. Sus cosas funcionan porque están diseñadas.

El software comercial de TI es simplemente débil. Dirigir el equipo es caro y la gerencia piensa que la cantidad (de programadores, por ejemplo, nómadas tecnológicos H1B) supera la calidad. La ingeniería es lamentablemente escasa y este enfoque de “centavo y tonto” es la razón por la cual cada compañía y organización gubernamental es donde trabajan los desarrolladores de software débiles (y los administradores de software).

Hay excepciones a esta regla: alrededor del 20% de los proyectos comerciales de TI que he visto funcionan bien.

Cualquier compañía donde el software no sea vendido o utilizado directamente por los clientes, sino que solo sea un mal necesario significa un fin. En mi experiencia, se trata de compañías de automóviles, así como de compañías que producen datos como producto (como datos de atención médica, por ejemplo).

Sí, he trabajado en ambas industrias y he visto desarrolladores que no podían codificar su salida de una bolsa de papel.

Un síntoma de esto es la contratación de grandes ejércitos de contratistas externos (en tierra o en alta mar, no hay diferencia). Estas compañías están listas para ser arrancadas por gurús ágiles, entre otros depredadores. Estos bromistas son como el Music Man titular en el musical: “Tenemos problemas aquí en River City, ¡Problemas con una Capital T!”

Agile Guru con bastón (arriba)

Hay muchas respuestas potenciales para esto; porque no definiste lo que querías decir con “débil”, la mayoría de ellos son probablemente sarcásticos.

Si por “débil”, quiere decir “no muy bueno, pero capaz de aprender”?

• Laboratorios de computación de la universidad, porque todavía son estudiantes y aún no son desarrolladores
• Pasantías, porque todavía son estudiantes
• “¿Está conectada la impresora? OK, intentemos reiniciar su computadora … “(mesas de ayuda)

Si por “débil”, quiere decir “graduado con un BSCS, pero sin experiencia en la industria”?

• Puestos de nivel de entrada, porque carecen de experiencia real y no aprovecharon las oportunidades de pasantía cuando todavía eran estudiantes.
• “Bien, ese es un nuevo auricular Nokia. Voy a necesitar toda su información personal … No sé por qué, la caja registradora no me permite llamar a alguien sin el nombre de su hámster, solo lo necesito … OK. Ahora, ¿trajiste tu tarjeta de batería gratis? ¡Gracias por comprar en Radio Shack! ”

Si por “débil”, quiere decir “¿realmente no es capaz de ser mucho mejor en eso”?

• Amazon: suponiendo que puedan levantar 50 libras de manera segura
• Starbucks, pero solo si tienen una memoria decente; la gente a menudo ordena cosas con siete o más calificadores
• “¿Le gustaría papas fritas con eso?”

No todos están hechos para ser desarrolladores de software.

A menudo se convierten en gerencia.

Seguramente no levantan cajas grandes. Entonces, ellos son los que no marcan la casilla sobre estar dispuestos a levantar más de 50 libras.

Es decir, CIERTAMENTE, políticamente incorrecto.

En cualquier caso, he trabajado en gimnasios y me doy cuenta de que las mujeres en realidad no levantan tanto como los hombres a menos que sean equipos olímpicos. (Y, soy un desarrollador de software). No era semana. En cualquier caso, generalmente noté que 50lbs desafiaron a las chicas muy en forma e inteligentes. Sin embargo, podrían ser grandes desarrolladores de software. ¡Sí! Es un juego mental.

OKAY. Mas serio…. Los desarrolladores de software débiles en el sentido de no saber qué hacer o tener ideas realmente estúpidas sobre el desarrollo o simplemente acosar sexualmente a las personas y nunca parecen ser despedidos, etc.

Estos tipos, si son tan horribles que no se convierten en jefes, se quedan allí para siempre. Y, los muchachos que obtienen buenos resultados en los desafíos de algoritmos, crean nuevas teorías viables y cosas similares son despedidos y abandonados en desgracia.

Yo se esto. Llegué a la cima de Hacker Rank en una categoría, me gradué de una escuela superior de CS, desarrollé nuevos tipos de software y varias aplicaciones similares, y a menudo me han despedido. Ahora deseo haber tenido un trabajo bien remunerado. Pero, tengo algunos de mi propia consultoría. Solo que no mucho.

Me han despedido lushes, matones y pervertidos. O bien, la configuración ha sido realizada por tales personas y la gerencia vendría caminando con una mirada agria en su rostro y mostrando la puerta.

Un lugar, una señora que había visto desnuda en San Francisco era el jefe, y un niño que bebió durante su primer año en el estado de Chico fue su “mascota de maestra”. Entonces, él todavía tiene su trabajo. Y, me despidieron por incompetencia, aunque demostré muchos pequeños programas para salvar sus negocios del desastre. Esa fue una.

Fui una de las mejores universidades para IA y computadoras. Me pusieron en una oficina con un tipo que pagó para que su doctorado fuera escrito dando a su fantasma los servicios de su esposa. El tipo entraba a la oficina, se quitaba la ropa y me decía que necesitaba expresar mi identidad homosexual. No tengo un ser homosexual. De todos modos, me obligaron a abandonar la universidad por no “encajar”. Y, hasta el día de hoy, me alegra decir que no encajé.

Trabajé en el famoso software de servicio de TV en SF. Allí, muchas de las programadoras habían sido strippers en SF. Y, los chicos pensaron que eran geniales. Tan genial, de hecho que no tuvieron que terminar los programas. Eso dejó eso a los consultores que fueron despedidos por no “encajar”.

Trabajé en un lugar “innovador” en San José. Una vez más, fue una configuración de la situación del contratista en la que el alcohólico, gordo y calvo entró con especificaciones pésimas y actuó lindo y tímido cuando olvidó usar ropa interior para trabajar, un hecho que señalaría con su gordo y peludo, nalgas desnudas sacando sus pantalones. Para eso, le dije a la compañía contratante que nunca quería volver a trabajar allí. Por lo tanto, nunca tuve otra colocación por parte de la empresa contratante.

No pasará mucho tiempo antes de que esté en una dieta forzada.

Probablemente los mejores desarrolladores de software trabajan en Starbucks, y la basura tiene un trabajo en una compañía de la lista Fortune 500 con un contrato militar de los EE. UU. Y sus impuestos están pagando por este estado de cosas.

Hay una película llamada “EL CUBO”. Vea eso para comprender cómo se toman las decisiones en el trabajo.

Encontré a los desarrolladores más débiles dentro de las compañías más grandes jamás vistas. Eso es porque dentro de esos lugares no pueden hacer cosas imposibles en los pequeños. No estoy hablando de compañías de TI como Google o Apple, estoy hablando de compañías sin enfoque en TI y sólidas basadas en contratistas y consultores de TI.

Estas empresas tienen un uso intensivo de características como:

1. Fuertes “marcos” que nunca cambian
2. Tecnología obsoleta que no puede evolucionar debido a las cajas negras heredadas
3. Procedimientos burocráticos increíblemente lentos que requieren días para su aprobación
4. Gran jerarquía con jefes de jefes e incluso gerentes y administradores más grandes, etc. Estas personas ocultan a los desarrolladores más estúpidos y perezosos que puedes encontrar.

¡Estos entornos son lentos, pesados ​​y están llenos de convenciones, no encontrarás gente realmente experta y versátil en las partes más avanzadas de la computadora de Ciencia allí! ¡Solo usan bibliotecas y herramientas desarrolladas por los verdaderos inteligentes, pero tales profesionales son muy hábiles en política dentro de las compañías para cubrir sus propios culos!

¿Qué significa exactamente ser un desarrollador de software “débil”? Creo que eso tiene que definirse, porque sospecho que CADA desarrollador de software es “débil” en algún sentido. En ese caso, funcionan en todas partes.

Solo desde una perspectiva de orden cero, no he conocido a un desarrollador de software que conozca TODO el lenguaje, y dudo mucho que tal persona exista o incluso se acerque a él. Por lo tanto, no se puede esperar que ningún desarrollador de software pueda comenzar a ejecutar cualquier trabajo de codificación que uno pueda imaginar, ya que no tendrán conocimiento del idioma. ¿Esto hace que un programador sea “débil”?

En otro nivel, algunos desarrollos de software requieren otro conocimiento específico para la aplicación que están programando. No he conocido a un programador de software que sepa todo acerca de cada proyecto para el que alguien necesite un código escrito. ¿Podemos considerarlos “débiles” como resultado?

Luego está la cuestión del enfoque filosófico de la programación. Algunas personas solo quieren que la maldita cosa funcione para la aplicación en particular. Algunos son mucho más puristas e insisten en que las mejores técnicas, perfectamente escalables y que a veces se adhieren a reglas arcanas, son una necesidad. ¿Es incorrecto adoptar un enfoque de fuerza bruta para un problema, incluso si no es elegante? Resuelve la necesidad inmediata. ¿Es apropiado insistir siempre en que el código se adhiera a estándares extremadamente altos que solo unas pocas personas pueden lograr con regularidad? ¿No es posible que haya “debilidad” en ambos extremos?

Un programador débil generalmente hace una de dos cosas, se vuelve más inteligente (y hay muchas maneras de hacerlo) o cambia de carrera. En el sector privado, una empresa con experiencia en el desarrollo de software eliminará a los programadores débiles porque son demasiado caros para seguir empleados. Sin embargo, una empresa con poca experiencia en las tareas y requisitos para obtener software en línea no se dará cuenta de que podría estar progresando con un empleado diferente y luchará innecesariamente hasta que se den cuenta de su error.

Una vez que un programador se da cuenta de que no es especialmente bueno en su oficio, puede optar por ser más inteligente y permanecer en el campo de la programación. Esto suele suceder si disfrutan del trabajo o no quieren aprender otra cosa. La forma ideal de ser más inteligente es aprender el oficio y practicarlo fuera del horario laboral. Este es el mejor método para la industria y para el individuo, asumir la tarea y aprender a través de la fuerza de voluntad y la automotivación. De hecho, esta es la ruta más desafiante, pero es una forma mucho más gratificante de ser más inteligente. Otro sabor de este método es a través de la capacitación en el trabajo, comenzando como un empleado que no requiere mucha programación y luego avanzando a un puesto que lo hace en función de las habilidades obtenidas a través de sus logros laborales. Este método es negociado en el sentido de que el empleado trabaja con la empresa para desempeñarse en niveles adecuados conocidos por ambas partes.

Alternativamente, un programador débil podría encontrar oportunidades de empleo a corto plazo. Esta vía les permite recibir el pago por su tiempo, pero tampoco tener un período sostenido de exposición a sus diversos empleadores. Esto evita que el empleador descubra realmente su falta de habilidad y, simultáneamente, como empleado, intente encontrar algo que pueda hacer para ayudar a una empresa con una pequeña tarea. Este enfoque no requiere mucho aprendizaje y no es especialmente siniestro si realmente logran algo mientras están empleados, ya que ningún trabajo es igual a otro. La programación de empleo a corto plazo se puede encontrar en la contratación y consultoría. Sin embargo, si son especialmente pobres en el comercio, desarrollarán una reputación que dañaría su capacidad de mantener este método.

Otro método para ser más inteligente es encontrar empleo en una posición gubernamental. Si el empleado candidato puede atravesar el proceso de la entrevista, puede encontrarse en un entorno muy seguro, a menudo sin la amenaza inminente de ser despedido debido a las malas habilidades de programación. El trabajo del gobierno a menudo dispersa la carga de las tareas a muchas personas que pueden compartir la carga de trabajo para minimizar el fracaso (de todos modos, esa es la teoría actual). Como resultado, puede ser más fácil no exponer un desempeño deficiente pero cumplir con habilidades que no son de programación en actividades relacionadas y aún así proporcionar un beneficio al empleador de manera alternativa. Este es un hecho común en el trabajo del gobierno, donde la habilidad y el rendimiento no son primordiales y dependen de unos pocos héroes. Si no hay héroes disponibles, entonces el proyecto falla y solo el contribuyente pierde. El principio de Peter también prospera en entornos de trabajo como este.

Dado que la mayoría de las oportunidades de empleo no son cargos gubernamentales, un programador débil a menudo descubrirá el mayor éxito simplemente cambiando de carrera. Esto puede ser especialmente desafiante si han invertido significativamente en su carrera de programación a través de un título universitario u otras influencias. Además, esta vía ofrece una gran recompensa tanto para la industria como para el individuo: la industria se satura más con profesionales calificados y el individuo puede descubrir una mano de obra que es mucho más agradable y puede obtener más ganancias personales con menos esfuerzo.