La semana pasada, estaba viendo esta increíble entrevista de Kevin Rose de Phillip Rosedale, de Second Life.
Y tuvieron una discusión increíble sobre cómo encontrar, contratar e identificar buenos programadores, y lo difícil que es encontrar buenos.
Lo que me ha llevado a pensar realmente en la forma en que aprendemos los programadores. Para la mayoría de nosotros, incluido yo mismo, somos autodidactas. Lo cual es genial para ser un programador, cualquiera puede aprender y desarrollar habilidades.
Pero esto también significa que no hay estándares reales de lo que es / es un buen programador, y qué tipo de entorno fomenta el crecimiento de las habilidades de programación.
Esto no es tanto una pregunta, sino solo un deseo en mí, para ver cómo podemos cambiar la cultura de la programación y el gerente de programación, de modo que se aliente la educación y la superación personal.
Hay muchas vías para la educación continua, videos de YouTube, libros, conferencias, pero debido a la naturaleza experimental de lo que hacemos, no siempre está claro qué es importante aprender y dominar.
Veamos los 12 pasos de Joel.
La prueba de Joel
¿Usas control de fuente?
¿Se puede hacer una acumulación en un solo paso?
Haces contrucciones todos los dias.
¿Tienes una base de datos de errores?
¿Tú arreglas los errores antes de escribir un nuevo código?
¿Tiene un horario actualizado?
¿Tienes una especificación?
¿Los programadores tienen condiciones de trabajo tranquilas?
Utilizas las mejores herramientas que el dinero puede comprar?
¿Tienes probadores?
¿Los nuevos candidatos escriben código durante su entrevista?
¿Haces pruebas de usabilidad en el pasillo?
Creo que todo esto tiene un valor importante, pero debido a algo que llamo la Brecha Experimental, si un programador o gerente nunca ha experimentado alguna de las consecuencias negativas por no haber hecho los elementos de la lista, nunca verán la necesidad de hacer nada. de ellos.
La brecha experimental, es mi teoría básica, que cada uno de nosotros tiene diferentes trabajos y diferentes experiencias. Entonces, para algunos de nosotros, que siempre hemos trabajado con docenas de programadores, el control de fuente es imprescindible. Pero para las personas que siempre han sido el único programador, no pueden imaginar la necesidad del control de la fuente.
Y es debido a este gran defecto en la forma en que aprendemos, que evaluamos a las personas según las mejores prácticas que hacen o no, y la razón de esto puede comenzar una guerra de llamas.
Siempre evaluamos a las personas en nuestro campo por lo que hacen, y pensamos "Oh, si este chico / chica no está haciendo las mejores prácticas de xyz, él / ella no puede ser un buen programador, así que no perdamos tiempo ni energía hablando con ellos ".
Esto es exactamente por qué tenemos tantas guerras de llamas de programación, que se convierte, debido a la Brecha Experimental, que no podemos imaginar que las personas no hayan tomado las decisiones que hemos tenido que tomar.
Esto me ha llevado a pensar que necesitamos repensar totalmente cómo entrenamos, educamos y gestionamos los programadores.
Por ejemplo, ¿qué porcentaje de ustedes ha sido alentado por su gerente para ir a conferencias e incluso hacer que paguen por ello?
Para mí, y para mucha gente, esto es extremadamente raro, a muchos de nosotros nos encantaría ir a conferencias, para aprender más, pero el dinero no está ahí para hacer eso.
Entonces, el punto de esta pregunta es realmente despertar mucho de cómo podemos entrenar, aprender y administrar mejor.
¿Cómo podemos crear una nueva cultura de aprendizaje que no insulte a las personas por no tener las mismas experiencias laborales?
Sí, todos tenemos trabajos y trabajo que hacer, pero nuestra capacidad para hacer bien nuestro trabajo depende de nuestro deseo, interés y apoyo para mejorar nuestro dominio de nuestras habilidades.
En este momento, veo que nuestra cultura está bastante desorganizada, apoyamos a la élite, pero esas toneladas de nosotros que queremos mejorar, simplemente no tenemos suficiente apoyo para aprender y mejorarnos.
Quiero decir, ¿nosotros, como industria, queremos ser percibidos como simples engranajes reemplazables?
Gracias...
Respuestas:
Wow, una gran pregunta para pensar, difícil de responder. Debido a que todos tenemos diferentes experiencias y deseos, es difícil encontrar una solución única para todos. Pero arrojaré algunas opiniones que he tenido a lo largo de los años sobre este mismo tema.
1) Deja de ver el salto al trabajo como algo malo y anímalo. Cambiar de empresa cada pocos años. El programador se expone a muchas tecnologías, metodologías y negocios diferentes en el transcurso de su carrera. Las empresas obtienen un flujo constante de nuevas ideas.
2) Deja de verte a ti mismo como un programador en la empresa X y mírate como un profesional que brinda un servicio a la empresa X. Si piensas como un profesional, serás tratado como un profesional. Si nos ven como engranajes reemplazables, es porque actuamos como engranajes reemplazables.
3) Las universidades necesitan cambiar. Deben tener un período inicial de 2 años de educación básica en computadoras seguido de una elección. Informática o Ingeniería Informática. Y la carrera de ingeniería necesita profesionales que trabajen en el campo todos los días, no alguien que solo escriba artículos. Y lo que se enseña debe ser práctico, para que pueda comenzar a trabajar el día después de la graduación. Tal vez tenga un programa de aprendizaje para aquellos que no pasan por un programa de grado.
4) Editar: Esto fue un poco despotricante. Lo que quise decir es que todos tenemos mucho que aprender unos de otros, independientemente de la edad y la experiencia.
5) Algo relacionado con el punto 2. Deje de ver a su empleador como responsable de su carrera. Usted está. Y solo tu. Si desea ir a una conferencia, pague usted mismo si su empresa no lo hace. Reserve dinero cada año específicamente para libros, capacitación y desarrollo profesional. Si espera que su empleador lo envíe a la capacitación, esperará mucho tiempo. El tiempo dedicado a ver tus habilidades se vuelve irrelevante. ¿No gana lo suficiente para pagar eso? Cambiar trabajos.
6) Necesitamos ser honestos con nosotros mismos y con nuestros compañeros programadores. La programación es difícil. Muy duro. Todavía veo publicidad para capacitación en informática con riquezas garantizadas después de la graduación. Eso lleva a muchas personas al campo que simplemente no están calificadas o peor aún no tienen ningún interés real más allá del dinero. Necesitamos encontrar una manera de alentarlos a repensar sus planes de carrera.
En este punto, creo que mi cabeza está a punto de explotar, así que concluiré.
Gran pregunta! Tengo muchas ganas de leer más respuestas.
fuente
No creo que esté desorganizado únicamente como resultado de la falta de enseñanza. Creo que en realidad es reflexivo que las "mejores prácticas" diferirán de un trabajo a otro. Las "mejores prácticas" siempre se basarán en un contexto particular.
Sucede que hay muchas cruces para algunas de las áreas de trabajo más comunes, es decir. desarrollo web. Sin embargo, creo que es una falacia creer que solo porque es bueno participar en una práctica particular en la mayoría de los trabajos, debería usarse en todos los trabajos.
Las prácticas que realice deben provenir de un análisis y experimentación de lo que lo hace trabajar mejor. No deben ser elegidos por creencia ciega. El hecho de que algo se repita a menudo en la red no lo convierte en una verdad en su situación, ni una verdad (para todas las situaciones).
fuente
Gran pregunta para ejercitar la mente, estoy de acuerdo en que hay que hacer algo, pero creo que es imposible responder. Mi intento:
Primero, no mates la creatividad en general. Tengo que decir que estoy de acuerdo con Sir Ken Robinson, mira esta gran charla TED . Nuestro sistema educativo está matando la creatividad y eso tiene que ser modificado. Especialmente para programadores.
Segundo enseñar como patronesnuestro campo profesional no es lo suficientemente maduro. Tenemos muchas cosas diferentes que creemos que son el camino a seguir, pero realmente no podemos estar de acuerdo en ellas. (Piense en TDD, BDD, Agile vs Waterfall, la cantidad de documentación necesaria, Java o .Net) En mi opinión, esto se debe a una discusión sin contexto y a mucha especialización. No puede tomar la decisión correcta sin saber en qué contexto se hace la pregunta y no puede tomar la decisión correcta si solo conoce una opción. Cuando traes esto de vuelta a la educación, parece imposible de resolver. No puede esperar que alguien conozca todos los contextos posibles y todas las soluciones posibles. Pero con los patrones ahora se presentan algunas soluciones generales y los contextos que se aplican y los contextos cuando las soluciones se descomponen. En mi humilde opinión, esta es la forma en que tenemos que enseñar,
Descargos de responsabilidad en el tercer lugar en los ejemplos Creo que hay un problema con los ejemplos que mostramos en MSDN, en blogs, en libros, etc. Pero en los ejemplos más básicos ya hay decisiones en muchos niveles. Estos ejemplos enseñan todas estas otras decisiones equivocadas. Creo que cada ejemplo debe venir con un descargo de responsabilidad que indique cuál es el punto y lo que no debe hacer en general. Un gran ejemplo de esto fue blogueado hoy aquí .
Último Do Do Do Creo que debe haber más trabajo. He aprendido a la mayoría simplemente haciendo, fallando, arreglando y discutiendo.
fuente