¿Cuánto tiempo lleva estudiar la especialización en TI (desarrollo de software)?

¿Cuánto tiempo lleva convertirse en programador? En Estados Unidos, todo el mundo es experto en hosting. En Europa, un camarero puede tener que someterse a 10 o incluso 20 años de formación antes de poder servir en un restaurante de primera clase. En Estados Unidos, siempre que te postules según el anuncio y te pongas una toalla en el antebrazo, serás camarero. La programación es otro campo donde no faltan expertos. Según la visión estándar, 6 semanas de "formación" son suficientes para elevar a una persona al nivel de "experto". La persona no necesita aprender ningún conocimiento nuevo, es decir, está cualificada para diseñar un sistema de rescate de vidas en línea. . Si ve un anuncio de programadores "experimentados", normalmente significa uno o dos años de experiencia. De hecho, si alguien tiene 15 años de experiencia en programación, la gente pensará que esa persona simplemente es retrasada. Si realmente tuviera algo de inteligencia, debería haber aprendido todo sobre programación hace 14 años. Después de esto, debería haberse cansado de este negocio y cambiarse a un puesto de gestión, ventas u otro puesto. No estemos demasiado ocupados riéndonos de las personas que sostienen este punto de vista. En primer lugar, debemos admitir que 15 años de experiencia, por sí solos, tal vez no le enseñen nada en programación. Conozco algunos camareros americanos con "15 años de experiencia" que ni siquiera saben poner los platos en la mesa antes de la comida. También sé que algunos profesores universitarios estadounidenses con "15 años de experiencia" ni siquiera pueden enseñar a un cachorro a mover la cola. De manera similar, también conozco a algunos programadores estadounidenses con "15 años de experiencia" que todavía dan el archivo de transacción (archivo de transacción) antes de actualizar el archivo maestro de acceso directo (archivo maestro) en un sistema al que acceden múltiples procesos. 2. Para convertir una variable con un valor entre 0 y 5 en una variable con un valor entre 1 y 6 (usada como subíndice en el lenguaje FORTRAN), alguien usó 5 declaraciones IF, ¡más 5 declaraciones de asignación! 3. Al escribir programas COBOL, algunas personas no utilizan la cláusula "ELSE" porque "puede que esto no funcione". 4. Al escribir programas PL/I, algunas personas nunca usan cadenas de longitud variable porque "esto no es lo suficientemente eficiente". 5. Algunas personas no escriben ninguna subrutina porque "es demasiado complicado". Esta lista se puede escribir indefinidamente. La cuestión aquí no es que haya tanta gente que parece programadores profesionales haciendo el ridículo, sino que pocos directivos saben si están tratando con uno de "ellos" o con "nosotros", "uno de los miembros". Esto es particularmente similar a la situación de los camareros estadounidenses. Muy pocas personas en los Estados Unidos han tenido alguna vez el servicio de un camarero profesional, por lo que incluso si conocieran uno, no notarían la diferencia. O tal vez sea mejor decirlo de esta manera, simplemente no se dan cuenta de que lo que consideran un camarero “estándar” en realidad todavía está en un nivel “subprofesional”. Del mismo modo, a menos que sea un programador competente, es difícil medir la calidad del trabajo de un programador. Hay muchas empresas pobres en el mundo que nunca han podido retener a un programador verdaderamente competente durante mucho tiempo, por lo que no cuentan con un conjunto de estándares para medir la profesionalidad de los programadores. El estándar de estas empresas es tratar a las personas mediocres como genios. Y estos estándares también son muy extraños, varían de un lugar a otro e incluso de diferentes departamentos dentro de una misma empresa. Cada vez que voy a una nueva empresa para trabajar como consultor, le pido a mi gerente que me muestre algún código típico por adelantado. Los gerentes a menudo no pueden creer que realmente quiera ver el código y siempre tengo que insistir en pedirlo varias veces antes de recibirlo. Con solo mirar un pequeño fragmento de código, normalmente puedo tener una idea bastante precisa del entorno de trabajo en esa empresa. A veces mis palabras son tan precisas que la dirección se sorprende y piensa que ya he hablado antes con los empleados en privado. Los propios gerentes nunca miran el código. El código es para un gerente lo que los platos sucios son para el jefe de camareros. Una vez que te sacan de ese montón de basura, nunca más vuelves a tocar esa basura, ni siquiera como broma. Una vez, cuando estábamos en la universidad, los estudiantes sugerimos que los profesores también debían tomar el examen de maestría con los estudiantes, para dar ejemplo y establecer un estándar para los estudiantes. Más de 2/3 de los profesores se asustaron por esto y gracias por su insensibilidad. Ellos mismos han pasado por más de 20 años de tortura en los exámenes y ya no están dispuestos a volver a ocupar el puesto de candidatos; esto les recordará su antiguo estatus humilde. Del mismo modo, la renuencia de los directivos de nuestra industria a codificar sugiere que la profesión de codificador se sitúa ligeramente por encima de los ladrones de tumbas y por debajo de la gestión en la jerarquía humana.

Según esta forma de pensar, escribir código no puede constituir una habilidad independiente, no puede ser un talento, ni puede ser una profesión decente con su propio estatus, y por respetabilidad me refiero a no tener que competir con los ladrones de tumbas, la administración y los administradores. similares se miden en la misma escala. Mientras prevalezca esta actitud en la industria del procesamiento de datos, todavía habrá expertos y gerentes de seis semanas que ni siquiera escucharán a los programadores altamente remunerados con 15 años de experiencia. ¿Existen similitudes entre ser profesor, camarero y programador? ¿Por qué todo el mundo cree que puede hacer estas 3 cosas como un profesional? Al principio, estos trabajos parecen fáciles de entender porque muchas personas comunes y corrientes tienen experiencia relevante. Todo el mundo ha enseñado a alguien más en un momento u otro. Todo el mundo ha puesto los platos sobre la mesa o ha guardado los platos sucios. Pero no todo el mundo ha realizado alguna vez una cirugía en un cerebro vivo, y no todo el mundo ha argumentado un caso ante un jurado. No estoy seguro del contenido específico de los cursos de formación ejecutiva actuales de IBM, pero durante muchos años este curso incluyó el famoso "Problema de Manhattan" como único ejercicio de programación. En los Estados Unidos, la mayoría de los libros de texto de introducción a los cursos de procesamiento de datos hablarán sobre este "problema de Manhattan". Si alguno de los lectores nunca ha aprendido esto, lo repetiré aquí de acuerdo con la forma en que está escrito. Libro de texto: (Si el 4,5% de la tasa de interés anual es baja, es porque esta pregunta se publicó en 1956 y ha sido copiada en diferentes libros de texto por generaciones de autores desde entonces). La "solución" de esta pregunta, si Dejando de lado algunos detalles insignificantes, escrito en lenguaje FORTRAN, es un bucle de este tipo: I = 1627PRINC = 24.002PRINC=PRINC*1.045I = I + 1IF(I-IYEAR)2,1,11WRITE (3,601) PRINC es al menos. Trescientos o cuatrocientos miles de estudiantes, desde administradores hasta estudiantes de primer año de la universidad, han aprendido esta "solución". Para algunos de ellos, el código anterior es el único programa que "han escrito alguna vez", pero los califica para escribir un sistema operativo, un sistema de implementación de fuerza laboral, un simulador de gestión de requisitos de piezas, un controlador de procesamiento en línea, o cualquiera que sea la complejidad de El sistema que puedas imaginar. Y, por supuesto, en los cursos ejecutivos, cada alumno también cuenta con un programador profesional como mentor "para ayudarle a afrontar los detalles". De hecho, el problema de Manhattan sirve como una excelente herramienta para enseñar a los ejecutivos una de las lecciones más importantes que deben saber sobre la industria de la programación. Suponga que les deja escribir el programa anterior y les admite que, de hecho, es una "solución" al problema. Luego les pregunta cuánto tiempo llevó programar el programa, cuánto tiempo llevó ejecutarlo y luego les pregunta si creen que estos números son "buenos". Cuando entreguen su tarea y resuman sus sentimientos, permítales mirar el siguiente programa y decirles que dicho código puede lograr el mismo resultado: PRINC=24.00*(1.045**(IYEAR-1627))WRITE(3,601 )PRINC compara su tiempo de programación y tiempo de ejecución. Probablemente pueda encontrar que este último programa solo toma 1/5 del tiempo de programación y 1/100 del tiempo de ejecución. Por supuesto, la proporción específica variará en diferentes entornos. Luego les preguntas: "Si para un programa tan simple, la diferencia entre dos códigos diferentes puede ser 5 veces o incluso 100 veces, ¿qué pasa si un programador profesional y un programador aficionado escriben la misma operación? ¿Cuánta diferencia habría si fuera un sistema? "Para que la programación sea tratada como una profesión formal, el público -incluidos los propios programadores- debe ser educado de alguna manera. Deben comprender que incluso 15 años de experiencia pueden no ser suficientes para adquirir conocimientos de programación, a menos que el alumno tenga una dedicación especial.