Introducción
Uno de los posts más visitados de este blog es el que dediqué a analizar los conocimientos mínimos que un desarrollador Javascript debería tener antes de considerarse experto. La motivación del artículo era el denunciar cómo frecuentemente los candidatos que optan a un puesto laboral engordan su currículum añadiendo altos niveles de conocimientos en lenguajes de programación sobre los que realmente no tienen la experiencia necesaria.
Los comentarios a dicho artículo han sido numerosos, tanto desde el lado de los desarrolladores como desde el de los responsables de contratación de diversas empresas. Y, por lo general, todos coincidían en que la idea general se repite una y otra vez en el mundo laboral actual.
Ha pasado ya un tiempo desde aquel borrador y he reflexionando mucho sobre el tema; finalmente, he llegado a la conclusión de que quizá me equivoqué identificando el origen del problema. En principio, nada ha cambiado: he continuado realizando entrevistas para diferentes empresas con diferentes perfiles a muchos candidatos cuyos méritos sobre el papel prometían una productividad y rendimiento extraordinario. Sin embargo, como tantas veces me ha ocurrido en el pasado, el resultado ha sido por lo general decepcionante.
¿Que por qué me equivoqué entonces? Pues porque el problema no es el desconocimiento de un lenguaje concreto; realmente no importa si un desarrollador no recuerda el orden de los parámetros en una función concreta; o si no es capaz de explicar correctamente en qué consiste la herencia prototípica. El problema es mucho más serio; es un problema de base: no es que no sepas Javascript, es que no sabes programar…
Desconocimiento de tu medio
Robert C. Martin me ha dado las claves de lo que significa ser un profesional del medio, nuestro medio. Parte de las siguientes cuestiones:
- ¿Sabes qué es un Diagrama Nassi-Shneiderman? Si no lo sabes, ¿porqué no?
- ¿Sabes cuál es la diferencia entre una máquina (de estados) Moore y una Mealy? Pues deberías!
- ¿Eres capaz de escribir un algoritmo quicksort en tu lenguaje favorito sin tener que buscar la fórmula por Internet? ¿Y en un segundo lenguaje?
- ¿Sabes lo que quiere decir el término ‘Análisis de transformación‘?
- ¿Puedes realizar una descomposición funcional de un algoritmo utilizando un Diagrama de Flujos?
- ¿Sabes que significa el concepto de ‘datos vagabundos‘ (Tramp Data)?
- ¿Has oído alguna vez el término Connascence?
- ¿Sabes lo que es una Tabla Parnas?
Estudiar, estudiar y estudiar
Durante la breve historia de la computación, son muchas las disciplinas, técnicas, herramientas y conocimientos que se han ido almacenando en libros y artículos. ¿Cuánto de todo ese conocimiento deberíamos saber? Excelente pregunta.
Por lo general, un desarrollador poco comprometido con el medio, dará una respuesta generalizada: la informática avanza cada día, ¿por qué voy a tener que perder el tiempo con todas esas viejas ideas que ahora son irrelevantes?
Y ahí tenemos la clave del problema. La primera parte de la respuesta anterior parece en principio obvia. Es cierto que en nuestra profesión los cambios se suceden a un ritmo vertiginoso. Pero sin embargo, esos progresos son en la mayoria de los casos periféricos. Es cierto que ya no tenemos que esperar 24 horas para que compile un código. Es cierto que podemos escribir sistemas con varios gigabytes de tamaño. Es cierto también que trabajamos inmersos en una comunidad global que provee acceso instantáneo a la información. Pero por otro lado, en último término, todavía estamos escribiendo los mismos if y while que los pioneros utilizaban hace 50 años. Mucho ha cambiado, pero también hay mucho que no.
La segunda parte de nuestra respuesta estándar es directamente falsa: ‘muchas ideas de hace 50 años son ahora irrelevantes’. Tenemos que reconocer que algunas de ellas ciertamente han sido marginadas. La metodología de desarrollo en cascada por ejemplo ha caído en desuso, pero esto no implica que no debamos saber qué es, cuáles son sus puntos fuertes y cuáles los débiles.
Más aún, la gran mayoría de grandes ideas que se forjaron en los 70, continúan siendo valiosas a día de hoy; quizá incluso más de lo que fueron en su día. Siempre resulta interesante tener presente la idea de que ‘quien no conoce la historia, está condenado a repertirla‘.
Qué tengo que saber como programador
A continuación se enumeran, como en el artículo sobre Javascript, una lista mínima de competencias que todo desarrollador responsable y comprometido debería manejar en profundidad:
- Patrones de Diseño: Deberías ser capaz de hablar y comentar cada uno de los 24 patrones presentes en el Libro GOF y la mayoría de los que se recogen en la colección POSA. Estamos hablando aquí de ser capaces de reproducirlos de memoria y de entablar una discusión sobre cómo funcionan.
- Principios de Diseño: Debes conocer el principio SOLID y todos los conceptos que implica.
- Metodologías: Debes entender XP, Scrum, Lean, Kanban, Cascada (Waterfall), Diseño Estructurado y Análisis Estructurado.
- Disciplinas: Debes practicar TDD, diseño y programación orientada a objetos (POO), Programación Estructurada, Integración Continua y Programación en Pareja.
- Herramientas: Debes conocer como usar: UML, Diagramas de Flujos de Datos (DFDs), Diagramas de Estructuras Compuestas, Red de Petri, Diagramas de Estado y Árboles de Decisión.
Siempre al día
Y además de lo anterior, el cambio frenético que sacude constantemente a nuestra industria supone que los desarrolladores deben continuar aprendiendo diariamente: lee libros, blogs, tweets… Ve a conferencias, a grupos de reunión sobre programación. Aprende cosas que estén fuera de tu zona de comodidad. Si eres un programador .NET, aprende Java. Si eres un desarrollador Java, aprende Ruby. Si eres experto en C, aprende Lisp. Si de verdad deseas exprimir al máximo tu cerebro, aprende Prolog y Forth!
No hay otro camino; la única forma de convertirse en un profesional y ser valorado como tal, es trabajar duro hasta conseguirlo. Hasta entonces, podemos ir asumiendo pequeños trabajos en diversas empresas que terminaremos sacando adelante de una forma u otra. Pero en el fondo, si nos detenemos un momento y hacemos un exámen de humildad, la verdad termina por salir siempre a flote: no sabemos programar.
Mmm,
Un par de ideas que me surgen a raiz de tu artículo…
coincido contigo (y con «tio» Bob, disfruté bastante «Clean Code», «Clean Coder» se me está atragantando un poquito…) en la necesidad de, como profesional, ser responsable de tu educación continua, y que lo que uno recibe en la educación reglada no es sino las bases para seguir aprendiendo. Entre otros motivos, porque cuantas más técnicas, algoritmos e ideas conozca, mejor servicio daré a mi cliente (o mejores programas escribiré, o más entenderé del código de otros, …)
Me parece arriesgado en una lista MINIMA incluir la exigencia (ese «Debes»…) de hacer (o usar) Integración Continua y, sobre todo, Programación en Pareja. Estoy de acuerdo en que es deseable, e igual en tus proyectos personales puedes plantearlo como un mínimo, pero en los proyectos laborales no siempre se cuenta con la disposición del cliente/jefe/… a trabajar con metodologías ágiles y sus herramientas.
Me falta en tu lista de «Debes» (que me parece más una desiderata, un manifiesto, un ideal a alcanzar) la parte de practica continua (katas, proyectos personales, participar en proyectos open source, asistir a dojos, …). De nada sirve mucho conocimiento teorico sobre una técnica si no la has implementado y has entendido sus limites y ventajas…
My 2 cents
La programación en parejas debería ser una constante en todo puesto de trabajo: la productividad que se alcanza es tan alta, que resulta absurdo no aplicarlo. Es cierto que puede suponer para los jefes una dura decisión: ‘no estoy malgastando dos recursos para lo que se supone que debe hacer solo uno? La respuesta para quienes practicamos este tipo de desarrollo (o lo dirigimos) es que obviamente no. Los mejores fragmentos de código, o algoritmos, o rutinas, o módulos, se realizan cuando programamos junto a un compañero. La concentración es mucho mayor, el número de bugs se reduce drásticamente, las opiniones de tu compañero amplían tu visión general sobre lo que estás haciendo, etc… Y la prueba irrefutable es que se termina una sesión de pair programming agotado: es difícil distraerse cuando tenemos a alguien al lado concentrado en lo que hacemos.
Sobre los katas, estoy de acuerdo: es necesario practicar. La idea no es solo estudiar y luego realizar tu trabajo de la forma más digna posible, sino poner en práctica todo lo aprendido para así afinar nuestras habilidades. Como recomienda el tío Bob, toda rutina laboral debería incluir al menos dos katas diarios: uno recién empezada la jornada y otro momentos antes de concluirla. El objetivo de los mismos puede ser, desde practicar un determinado patrón de diseño hasta simplemente recuperar agilidad en los dedos con determinado lenguaje o recordar atajos de teclado de nuestro IDE favorito. Cualquier excusa es buena…
No tomes esto como una crítica a tu artículo sino más bien a la idea general.
El problema de todo esto es que se termina cayendo en un academicismo extremo, pero a la vez bastante aleatorio. Es *necesario* manejar estos conceptos, independientemente de que los uses o no, pero además, es necesario manejar *estos* conceptos, *estos* que he elegido yo. ¿Por qué es «necesario» practicar POO, por poner un ejemplo, pero no programación funcional, por poner otro ejemplo? ¿Por qué XP, Scrum, Lean, Kanban, por qué concretamente esas y no otras?
Y como digo no es una crítica a tu selección particular, eh. Es simplemente que me temo que cualquier selección que se haga va a tener que caer en uno de dos problemas: O es una selección particular desde una perspectiva particular y por tanto se deja cosas fuera; o es una selección tan amplia que es practicamente imposible de alcanzar en ningún caso.
A mi, por ejemplo, siempre me ha parecido que la inclusión del GOF como «referencia obligada» es un claro síntoma de que la selección ya está sesgada. GOF es un libro interesante, es «bueno» leerlo, no lo niego. Pero su aplicación no es universal. Otro problema similar es UML. Está bien entender *lo básico* de UML. Pero más allá de lo básico no creo que nadie sepa ni cómo aplicarlo. Y sin embargo, gente que sabe que no lo usa, que sabe que no lo va a usar, sigue pidiéndolo como requisito.
Yo creo que has dado un buen paso de abstracción al pasar de «No sabes Javascript» a «No sabes programar», pero aún hay que abstraer más. Hay que subir a otro nivel aún. En mi muy modesta opinión, valores fundamentales para un programador son:
– ¿Sabes aprender? ¿A qué velocidad y con qué profundidad?
– ¿Tienes interés?
– ¿Eres capaz de entretener en tu mente conceptos que chocan con lo que crees que sabes?
– ¿Tienes espíritu crítico para analizar, desechar y aceptar?
– ¿Eres creativo, práctico, pragmático?
– Y, por supuesto, saber contestar correctamente a la pregunta: ¿Qué herramienta consideras indispensable para tu trabajo?
La selección de conceptos no es tan aleatoria; cada elemento de ese listado está ahí porque ha demostrado ser válido y, lo que es más importante, ha servido de punto de partida para evoluciones posteriores. Es el caso por ejemplo de las metodologías: XP está en la lista porque de ahí se deriva Scrum puede constatarse como una forma de incrementar la productividad de un equipo de forma significativa en la gran mayoría de los escenarios posible. La POO supone una evolución necesaria de la programación estructurada e, independientemente de que no se utilice en determinados desarrollos porque puede no resultar necesaria, si es importante conocer el paradigma por el simple hecho de que expande nuestro horizonte mental.
Si que estoy de acuerdo en que temas como el UML pueden parecer prescindibles en si mismos, pero la cuestión es que manejarlos, implica un cambio en cómo nos enfrentamos después a los problemas que nos puedan surgir. Muchas veces no se trata de la materia en si misma, sino de lo que conseguimos a nivel global abstrayéndola. Ser capaces de organizar un flujo correcto de forma mental puede determinar la mayor o calidad de un software. Si no conocemos ningún sistema para representar esas ideas, nos perderemos durante su implementación: igual que los músicos precisan de un sistema de notación rápido para ir estructurando sus melodías, los desarrolladores tenemos que contar con algún sistema que estructure las funcionalidades que queremos obtener de un programa. Llama a ese sistema UML o de cualquier otra forma, pero conócelo.
Tu lista de puntos finales me parece impecable y deberíamos tratarla en la v3 de esta serie 😉
Es sencillo, si te gusta lo que haces cada día te exigirás mas y querrás aprender cosas nuevas, sorprendiéndote cada mañana de cuan ignorante eres en realidad, y si lo único que pretendes es saltar de un día a otro sin prestar atención a lo que estas haciendo, olvidando que algún día te gustó aquello que hoy te da de comer, entiendo que te conformes con lo que ya sabes y que cualquier cambio te asuste. Al final, para innovar y aprender hay que trabajar duro, y a algunos, eso de trabajar les gusta mas bien poco.
«Muchas veces no se trata de la materia en si misma»
A eso exactamente me refiero con la relativa aleatoriedad de la selección. Si muchas veces no se trata de que sea «concretamente X», ¿por qué seleccionar explícitamente X? Terminará dependiendo de opiniones personales.
Porque muchas veces, X es la base de Y 😉
No es necesario saber latín para hablar castellano, pero conocerlo nos ayuda a comprender la etimología de casi todo nuestro vocabulario.
No es necesario hacer una licenciatura en matemáticas para desarrollar videojuegos, pero conocer álgebra lineal es imprescindible para comprender entornos en 3D.
No es necesario saber programar en C, pero si dedicamos un tiendo a entender este lenguaje, mejoraremos inmediatamente nuestro nivel Javascript.
Toda lista termina siendo subjetiva, pero es una buena base sobre la que luego ir añadiendo casos de estudio concretos.
No obstante, este debate resulta muy interesante 🙂
Estoy bastante de acuerdo con todo lo que dices, que básicamente es lo que dice el tio bob en clean coder, libro que todo desarrollador que se precie debería leerse por cierto.
Sobre la lista de cosas, creo que lo primero es interpretarla correctamente, no es una lista de «objetivos» o de que «debería de saber para ser un gran programador», en mi opinión es una lista de mínimos, son una serie de prácticas totalmente básicas sin las que nadie debería escribir código profesionalmente. Teniendo en cuenta esto la lista se reduce y no es tan arbitraria, sólo se trata de aquellas cosas absolutamente imprescindibles.
De todos modos, de momento veo lejos el día en que la evidente brecha que existe entre desarrolladores apasionados por su trabajo y que saben todas esas cosas y aquellos que sólo ven en esto una forma de ganarse la vida como otra cualquiera y no muestran ningún interés por seguir aprendiendo. Lo malo de este post o de libros como el clean coder es que al final sólo los leen aquellos que ya están convencidos, el trabajo duro esta en hacer que estas ideas se extiendan más allá de los círculos de siempre.
Completamente de acuerdo contigo 😉
La parte más dura es sin duda la difusión; con que solo unos pocos lectores sientan curiosidad por algunos de estos conceptos y sigan los enlaces para ver de qué se trata ya es un pequeño paso en esa dirección.
Pues me has fastidiao «sólo sé que no sé nada», esto es como las vacaciones santillana de la programación. xD
Feliz verano maestro.
Me quedo con la frase : «…Aprende cosas que estén fuera de tu zona de comodidad…» , todo lo que se aprenda a partir de ahí es un avance para cada programador un granito de arena en su conocimiento.
El aprendizaje de nuevas técnicas y lenguajes , modificando hábitos preestablecidos, ayuda a superar el umbral de cada uno.
Como me alegran el día leer estos posts!
La mayoría de los programadores de nivel medio llegan a las mismas conclusiones que toda la parafernalia que has escrito.
De qué te vale saberte todo eso al pie de la letra como si te fueras a examinar de ello si no sabes ponerlo en práctica? Todas esas metodologías las acabaras adquiriendo con la práctica y la constancia. Si de veras tienes una mente de programador (experiencia), cuando escribes código sabrás como desenvolverte, qué es más óptimo, qué sería más conveniente, pararte en el camino y anteponer los resultados teóricos a los prácticos (en ocasiones lo teórico no es tan óptimo) y un sin fin de cosas más.
Está claro que muchos conocimientos los adquirirás leyendo, pero muchos otros los adquirirás con la práctica sin saber que lo que estás haciendo tiene un nombre.
100000 €. Eso es lo que yo pediría a quien pretendiese que yo poseyera y aplicase esos conocimientos (y los habituales de varios lenguajes de programación, las API de tal y pascual, entre 5 y 10 años de experiencia…).
Como ya te han indicado, además, parece totalmente subjetiva. Supongo que estará adaptada a unas necesidades concretas de buscar a un supermán-programador.
Te voy a contradecir en tu último comentario también sobre C y Javascript (aunque puede que hayas escogido un mal ejemplo): se parecen como un huevo a una castaña. En cuanto creas tus primeras variables y funciones al estilo de C en un programa Javascript te darás el primer porrazo descubriendo como JS trata el ámbito «a su manera»… Como mucho te ayudará a saber cuándo abrir y cerrar una llave y te acostumbras a poner ; al final de cada instrucción.
Que me digas que lo de C++ se aplica a Java, C# e incluso PHP y Python, pues quizás, pero Javascript es un caso aparte. Y sigue siéndolo aunque ya se ha convertido en «lenguaje de servidor», con Node.js y similares. Yo lo he aprendido de malas manera por esperar que las cosas fuesen como en C#.
Yo creo que al señor Martin le ha dado un jamacuco o está ya mayor. Quizás si eres profesor te puedas permitir el lujo de hacerte con cientos de conocimientos teóricos y mantenerlos al día, pero fallarás en lo que se paga en la empresa: en producción. Y para mantenerte al día con las APIs y lenguajes que necesitas has de «olvidar» (o dejar en google) ciertas tareas. No todos los días necesitas un quicksort, ¿para qué quieres saberlo de memoria?
Si de contratar se trata y buscas a un buen profesional pídele que te enseñe qué proyectos ha hecho fuera del ámbito laboral. Algunos, sin ser superfrikis, participan/mos en proyectos open source, katas e historias similares. Si alguien se preocupa por dedicar su tiempo libre al desarrollo no suele ser precisamente un mal profesional.
Pero es mi opinión. Tengo más, y cada una es distinta 😛
Bueno, decir que C y Javascript no se parecen es desconocer un poco ambos lenguajes y en concreto el origen del segundo: Javascript proviene directamente de C. Brendan Eich era por 1995 uno de los mayores expertos en lenguaje C, sin duda, el mejor dentro de la Netscape Corp. de ahí que utlizara mucho de su filosofía mientras desarrollaba el primer borrador.
El resto es también discutible, pero es tu opinión y, por tanto, respetable como cualquier otra.
Saludos!
esto de aprender y aprender aplica en todas las carreras, de hecho no se si por eso se llamen «carreras» pero el que mas aprende es el que mas sobre sale, el que llega primero al conocimiento es el que esta arriba.
con cuerdo que muchas cosas se van a quedar en que las estudie mas nunca las aplique, yo en mi vida he hecho algo para mi trabajo en C, pero este me ayudo a dominar todo los lenguajes que he aprendido la gran mayoria de forma autodidacta, de tomar un libro, blog o tutorial y aplicar.
siempre he acostubrado leer algo al inico de mi jornada y aprender algo, tras aprenderlo implementarlo en cuanto sea posible, al final tengo 6 años trabajando y siempre proyecto a proyecto he tenido una evolucion en cuanto a calidad, tecnicas y de mas conociemientos..
pero creo que el fin es morir sabiendo que tan ignorantes somos ya que mientras mas aprendemos sabemos que hay mas cosas que no conocemos(yo no conosco muchas cosas de tu lista) pero tras tu recomendación a checarlo y tratar de aplicarlo en cuanto se pueda,,
La parte mas interesante de este post (y de otros) es definitivamente sus comentarios, siempre complementan de manera maravillosa.
Por otra parte, yo no nunca he tomado clases de programación de la forma tradición (ir a un aula y que un maestro te enseñe), todo lo que se de programación proviene de artículos, libros o tutoriales que he encontrado en Internet, así que resulta natural que muchas cosas que tal vez puedan ser básicas se me escapen, principalmente relacionadas con la historia.
Concluyendo, seria bueno si publicara una lista como tal, de las cosas que un programador debería saber.
Posdata: me encanta este blog.
¿Qué diferencias y semejanzas hay entre un mutex, un semáforo y un monitor y cómo se relacionan entre sí? Si no lo sabes no sabes programar… Además es un tema absolutamente necesario en la época de los procesadores con más y más nucleos y es por lo que se paga hoy en día.
Uuuuuy Prolog… eso me recuerda mis años mosos estudiando programacion… lo malo es que decidí dejar la carrera para estudiar diseño grafico. Irónicamente, debido a que tengo roces con el diseño web me estoy viendo en la necidad de retomar la programacion y estudiar Java… que cosas no? Tomaré tu articulo como base para empezar! X3
Lo que he posteado eran mis opiniones y sí, son tan discutibles como las tuyas. Siento no estar de acuerdo, pero no suelo entrar en el blog de nadie a hacer la pelota porque sí.
Desde mi punto de vista no se necesita saber hasta latín para ser un buen programador y hacer un gran trabajo. Si las necesidades de lo que haces lo requieren no te queda más remedio que aprender nuevas técnicas, pero como no estamos en el cole podemos echar mano de material de consulta.
Desde el tuyo parece que necesitas ser Donald Knuth para hacer el mismo trabajo repetitivo de siempre (pantalla, base de datos, pinta un gráfico, introduce texto).
Se te ha olvidado que la personalidad y la inteligencia también influye. A muchos se les da mejor cazar bugs, a otros optimizar código, a otros les va mejor el diseño de GUIs e incluso hay algunos que son capaces de ejecutar Oracle en su cabeza. Se llama especialización.
Además las empresas habituales, a las que muchos envían sus curriculum desde Infojobs, no te van a contratar por saberte el quicksort de memoria, y esas son mayoría. No vale la pena ni molestarse porque te van a pagar la miseria de siempre.
Las no habituales (donde nacen y se hacen los proyectos chachis) supongo que estarán dispuestas a pagar por ello mucho. Lo que pasa es que hay muy pocos puestos y son necesidades puntuales.
Sobre las insinuaciones de que no conozco C y Javascript, piensa lo que quieras. Yo he dado un ejemplo de lo que puedes sacar útil de C: la sintaxis. Si hay algo especial que no puedas aprender de lenguajes más «amables» como Java o C# y que C sí tenga, por favor ilumíname.
De todas formas, aunque no esté de acuerdo con este artículo en concreto (momento pelota) tu blog es muy interesante y he encontrado mucho material de referencia en tus twits 😛
La siguiente afirmación no es cierta:
Efectivamente como Impalah ha comentado:
Otra afirmación falsa, en este caso con cierta componente descalificadora:
Ciertamente las «sintaxis» de un huevo y una castaña pueden tener cosas en común, para que vamos a negarlo, pero
no veo como hacer una tortilla con la semántica que me aporta una castaña.
¿Podría ser que en la siguiente sentencia confundas «lenguaje de interés» con lenguaje en que se implementa el interprete de nuestro «lenguaje de interés»?
Para terminar: mencionar los diagramas Nassi-Shneiderman ha sido una broma ¿verdad?
A todo lo anterior no estaría de más aprender Linnear Programming (metodo simplex les suena?) y un gran libro es el siguiente de Winston Wayne, Operations Research: Applications and Algorithms : http://www.amazon.com/Operations-Research-Applications-Algorithms-InfoTrac/dp/0534380581/ref=sr_1_3?s=books&ie=UTF8&qid=1310786539&sr=1-3
«Bueno, decir que C y Javascript no se parecen es desconocer un poco ambos lenguajes y en concreto el origen del segundo: Javascript proviene directamente de C.»
Realmente el decir que un lenguaje estructurado, fuertemente tipado, de (relativo) bajo nivel como C, se parece a un lenguaje con caracteristicas funcionales y de OO, dinámico, de alto nivel como Javascript es desconocer no ya un poco, sino bastante, ambos lenguajes. Su sintaxis esta influenciada, como muchos mas que vinieron después de C, pero de ahí a decir que se parecen…
«Brendan Eich era por 1995 uno de los mayores expertos en lenguaje C, sin duda, el mejor dentro de la Netscape Corp. de ahí que utlizara mucho de su filosofía mientras desarrollaba el primer borrador.»
De la entrada de la wikipedia de Brendan, «In 2010, he wrote about JavaScript: «JS had to “look like Java” only less so, be Java’s dumb kid brother or boy-hostage sidekick.». Así que no, no utilizo nada de su filosofía, y de Java tan solo parte de la sintaxis (y parte del nombre).
Lo de que Brendan era el mejor experto de C dentro de Netscape, es como la mayoria de las afirmaciones de tu post, totalmente arbitraria, y en esta caso completamente subjetiva. Me refiero al listado de competencias que en tu opinión debería de conocer un programador, por incompleta y por existir tantas otras con muchísima mas importancia, carece de validez alguna.
Sobre la moraleja del post: la formación continuada y la búsqueda de la mejora personal, totalmente deacuerdo, hay poco que objetar y nada que no se aplique a cualqueir profesión cualificado se dedique a lo que se dedique.
En cuanto a que mi post de anoche desapareciera (básicamente idéntico a este para todo el que no lo haya llegado a leer), ¿era necesario borrarlo porque la cuenta de correo fuera de @example.com? ¿o mas bien te molesta que te dejen en evidencia?
Hola; el comentario estaba en la carpeta spam, pero ya está en su sitio 😉
Y con respecto al tema de la similitud entre Javascript y C bueno, no es el objetivo del artículo pero solo quería reiterar lo que comenté más arriba: Javascript es un lenguaje de la familia C; conocer estructuras y patrones en este último es muy recomendable para crear un buen código con el primero. Pero bueno; es mi opinión como desarrollador JS; si otros programadores son capaces por ejemplo de concebir un Dispositivo Duff en Javascript sin haberlo visto nunca en C, pues enhorabuena. Idem para cualquier otro patrón poco ‘intuitivo’.
Y en cuanto al resto del comentario, nada que objetar.
Gracias por la participación.
Saludos!
En cuanto al perfil que buscas en tu empresa, creo que lo vas a tener chungo. Mi experiencia me dice que los programadores (más aptos para tener los conocimientos que tú pretendes que se tengan) suelen despreciar Javascript, y los maquetadores no suelen tener conocimientos de programación. Entre estos últimos, están los que recurren al copy & paste y acaban usando 3 frameworks en una misma página y los que han aprendido a manipular el DOM, trabajar con AJAX y validar formularios, conocimientos con los que se cubren el 90% de las necesidades de uso de Javascript en un proyecto web «normal».
Existen los niveles y las especializaciones y es imposible ser experto en todo. Por ejemplo, ya que tu artículo es un pelín hiriente, te puedo decir que tú no eres experto en accesibilidad ni en usabilidad como afirmas, aunque puede que creas serlo. Así de tontamente se engorda el currículum.
Crees que John Resig, Brendan Eich, Angus Crall, Rey Bango, Ben Alman, Douglas Crockford, Zakas, etc no dominan todos y cada uno de los campos que se han mencionado en el post?
Yo no busco perfiles para una empresa concreta, sino que hago de consultor para varias entidades aportando experiencia tanto en soluciones de arquitecturas de software como en selección de personal cualificado. En cuanto a los temas de usabilidad y accesibilidad, es el rol que he desempeñado durante varios años en la Administración Pública siendo, además, dos campos en los que trabajado como docente.
De todos modos, no es mi perfil el que hay que evaluar; yo solo me preocupo de continuar aprendiendo siempre que me es posible y ese es el fin de este artículo. Si tú estás satisfecho con lo que sabes, me parece bien: este blog entonces no es para ti.
Saludos.
Hey, felicidades por este post, ciertamente toca muchos puntos importantes para un desarrollador de software. Confieso que varios no los conozco, y otros los conocía sin saber su nombre verdadero. En fin, pienso que también depende de la persona el nivel de profundidad al que quiera llegar en una rama de la ciencia. Recordemos que mientras más se estudia algo, más complejo se torna.
Haces referencia al abominable Duff’s device y su «implementación» en JavaScript. Vamos a ver, ¿puede un profesional de la selección de personal pretender establecer criterios de selección como los que has enunciado y al mismo tiempo confundir un simple loop unrolling (que es a lo que dedicas tu artículo http://www.etnassoft.com/2011/03/18/dispositivo-duff-en-javascript) con una construcción NO ESTRUCTURADA como es el inventito de Duff? ¿Puede defender tal profesional la tesis de que es posible reproducir tal engendro propio de los tiempos del goto en un lenguaje realmente estructurado?
Por cierto, sigo sin saber si la mención a los diagramas Nassi-Shneiderman era una broma.
No entiendo la alusión sobre los diagrama; éstos, son una parte fundamental de las ciencias de computación igual que a día de hoy lo es UML nos guste o no. Estos de Nassi-Shneiderman son especialmente interesantes para métodos y algoritmos pequeños y conocerlos es ser conscientes de la historia de nuestro medio. Como dije más arriba, no es imprescindible el latín para hablar castellano, pero ayuda a conocer parte de la realidad actual de esta lengua. Lo mismo pasa con los textos históricos sobre computación: conocer el pasado nos ayuda a entender el presente y a aprender tanto de sus errores como de sus aciertos.
En cuanto al Duff, no tengo nada más que comentar. Si te resulta interesante su estructura (y sobre todo si la entiendes) pues lo usas o juegas con ella. Si no, pues no pasa nada; no vas a encontrar trabajo con ella. Hay gente que se encuentra satisfecha consigo misma porque sabe hacer un bucle while, y hay otros que saben que éste, puede optimizarse con un recurso tan original como este de los tiempos del GOTO. A mi, por lo menos, me resulta mucho más interesante conocer alternativas y soluciones más creativas.
Creo que esto se está conviertiendo en un pique por todas partes…
Entiendo que el post de Carlos es atrevido y para muchos sea como un «zas! en toda la boca!».
Hay que tener claro que esta profesión es una carrera continua por el aprendizaje y que un verdadero profesional debe de tener un mínimo de entusiasmo,y dicho sea de paso, de frikismo, por aquello en lo que trabaja.
Hay mucha gente que a lo mejor ha llegado a este mundo sin estudios informáticos, y no por ello tiene que ser mala. Ha estudiado y se ha preparado como el que más por otras vías, y quizás se conozca la lógica y el uso del lenguaje mejor que nadie. Pero claro, quizás le falten muchos conocimientos teóricos, algo de base; quizás no es un ingeniero informático, hasta puede que sea un autodidacta.
Con esto quiero decir que existen programadores más funcionales que teóricos y en muchas ocasiones, esto no tiene que reflejarse negativamente en la calidad del trabajo.
Respecto al mundo laboral, yo hasta ahora no he visto que se pida a un desarrollador front -y digo front, no java, ni .NET etc- muchas de las cosas que se mencionan en el post. O eso, o me queda mucho mundo por ver, que eso es seguro.
Como dijo un paisano en su comentario, también es importante hoy en dia primar la disciplina, el compromiso, su interés, los proyectos personales, si dedica de su tiempo libre a seguir aprendiendo, si se «moja» en los temas relacionados y está en contacto diariamente con el mundillo etc.
De qué vale una persona que sabe la teoría y el lenguaje porque se lo han enseñado en la carrera pero que luego, en la práctica, no es comprometido con su trabajo y que solo se dedica a picar el código que le manden de cualquier manera, descuidadamente, que se irá a su casa dejando todo mal, que chapuceará el código porque no le da la gana de echar un rato más o simplemente de pensarlo mejor. Quizás trabaje de eso y a lo mejor es una bestia de programador en potencia pero -con perdón- le interesa una mierda, ¡menuda ética profesional!, es simplemente su forma de ganarse la vida, lo he visto mil veces.
Llegados a este punto, ¿qué tipo de programador interesa más?
En fin, en esto cada uno tendrá su punto de vista en función de su conocimiento, su posición laboral o sus estudios.
Un saludo a todos!
A ver Carlos, no es posible implementar el truco de Duff en lenguaje «modernos», por tanto no se trata de conocer alternativas creativas. Insisto, ¿puede ser que confundas el truco de Duff con un loop unrolling?
Para que se entiendan los motivos por los cuales el truco en cuestión funciona en C y no en lenguajes más actuales voy a mostrar las producciones gramaticales correspondientes a
switchen C y en ECMAScript. Empecemos por el segundo:EcmaScript 5 :: 12.11 ó A.4
SwitchStatement : switch ( Expression ) CaseBlock CaseBlock : { CaseClausesopt } { CaseClausesoptDefaultClause CaseClausesopt } CaseClauses : CaseClause CaseClauses CaseClause CaseClause : case Expression : StatementListopt DefaultClause : default : StatementListoptPodemos observar que el cuerpo de
switchno puede ser cualquier cosa, debe ser un CaseBlock.ANSI C ANSI X3J11/88-090)
Teniendo en cuenta que el truco de Duff data de 1983 creo que la especificación que utilizó (1988) será suficiente:
En este caso observamos que el cuerpo de
switchpuede ser cualquier otro statement. Como podemos ver gramaticalmente no hay restricciones, tendrán que venir impuestas por la semantica. Y en este caso no prohibe que uncasecontenga undoque se cierra ¡fuera del «bloque» delcasede apertura!. En la práctica loscaseson simplemente etiquetas destino de salto.Yo me temo, Carlos, que no hayas temrinado de ver dónde está la «gracia» del Duff. En tu artículo, como dice joseanpg, lo único que haces realmente es desenrollar el bucle.
Es decir, tú haces esto:
1- Sé cuántos [bits voy a copiar|elementos voy a recorrer]. Decido recorrerlos en bloques de 8.
2- Empiezo: Calculo cuántos «quedan sueltos». Por ejemplo, 3
3- Recorro esos tres primeros.
4- Hago un bucle en el que, en lugar de recorrer de 1 en 1, recorro de 8 en 8.
Hasta ahí, lo único que estás haciendo es algo que se ha venido haciendo desde tiempos inmemoriales: desenrollar un bucle.
El Duff hace algo más, y ahí está su «gracia». La «gracia» del Duff es que hace los pasos 3 y 4 en un solo paso, en un mismo bucle. Es decir, únicamente tiene 1 bucle, para el bloque de 8, y luego salta en medio del bucle enredando el bucle con un switch. Esa es la gracia del Duff, no el hecho de desenrollar el bucle, que, repito, es algo que ya se venía haciendo desde antes.
Es decir, lo que mejora el rendimiento es el desenrollado del bucle. Lo que hace el Duff es un mero «truco». Un truco tan… ehem, discutible, como meter un goto. Y como en Javascript no hay goto y, como ha señalado joseanpg, no puedes enredar el switch con el do-while, puedes hacer el desenrollado del bucle, sí, pero no puedes replicar el truco de Duff.
Pero, porqué os obcecáis con los ejemplos concretos y no con la idea general?
Cómo dice Madman más arriba, y estoy de acuerdo con el, solo se trata de aprender, de tener entusiasmo en lo que se hace y de no quedarse con lo más elemental. Vosotros conocéis el Duff, genial: podéis debatir sobre él e indicar si su implementación es útil o no: esa es la idea de este post!
Joseanpg parece conocer la diagramación Nassi-Shneiderman pues la cita como si fuera algo que hay que tomarse a broma; genial también! Esa es la idea de este post!
Si pensáis que conocer estos conceptos no os aporta nada en absoluto y que sería mejor no saberlos, pues lo siento por vosotros. Si por el contrario, os sentiis bien por manejar esos recursos, estupendo: seguro que de una forma u otra, os facilitan la vida como desarrolladores.
Y, esa es la idea de este post.
Yo no me obceco con nada, Carlos. Sólo comentaba lo que pasa con el Duff (ejemplo que, por cierto, has sacado tú).
«Esa es la idea de este post!»
Pero entonces volvemos a lo mismo que decía al principio… Esta lista es bastante arbitraria (no aleatoria, vale, pero sí arbitraria). Si de lo que se trata al final es de aprender y tener interés… decir que manejar «kanban», por poner un ejemplo, es necesario, es bastante inútil. Porque en el fondo, dices, no se trata de Kanban, sino de tener interés y aprender.
Estupendo, estamos llegando a lo que decía más arriba: Que es la lista concreta es bastante arbitraria e irrelevante.
¿Estamos jugando al teléfono escacharrado? xD
uy por dios, no se nada! y yo que pensaba que andaba bien.
Hola Carlos,
Estoy en parte de acuerdo con tu articulo y en parte en desacuerdo.
Comparto tu opinion en cuanto al hecho de que una persona con un buen curriculum no tiene por que ser necesariamente un buen programador. Tener buenas notas, haber hecho muchos cursos, e incluso tener mucha experiencia no son, en mi opinion, garantias de ser un buen programador. Pienso que programar es algo basicamente practico, y al igual que «a programar se aprende programando», tambien uno demuestra que sabe programar… programando 🙂 Si fuese un entrevistador, haria programar en la pizarra a los candidatos al puesto de trabajo. Y no pediria precisamente un quicksort, que es un algoritmo «estandar» y que hay gente que sabe de memoria sin entenderlo, sino cosas mas tipo algoritmos de Estructuras de Datos de 2o, en plan eliminar elementos repetidos de una lista doblemente enlazada, buscar subcadenas en una cadena o calcular permutaciones. Son cosas cosas que son faciles pero que hay que parar a pensarlas, y que te van a dejar ver la capacidad de resolucion de problemas de un candidato y su forma de pensar.
Y con esto ultimo enlazo con la parte que no estoy de acuerdo de tu post. En mi opinion, todos esos conceptos y procesos de los que hablas no son tan importantes (ni si quiera los patrones, que son algo fundamental y que se utiliza en el dia a dia, pero que puedes hacer que el candidato aprenda una vez contratado). No son aplicables a todos los proyectos, y en caso de ser necesario aprenderlos es muy bastante sencillo hacerlo y adaptarse al resto del equipo. Pienso que la principal caracteristica de un buen programador es que DOMINA una serie de conceptos basicos, de principios, que son aplicables a cualquier lenguaje y que utiliza continuamente; y ademas de eso, es bueno resolviendo problemas, se enfrenta a ellos de la manera correcta, con el modelo mental adecuado. Por que al fin y al cabo, programar trata de eso, de resolver problemas. Tambien creo que no debemos olvidarnos de los aspectos que no son tecnicos y son MUY IMPORTANTES para un programador, como las habilidades de persuasion (ser capaz de convencer a otra persona de que tu disenyo es correcto para ese problema), las habilidades de trabajo en equipo (ayudar a otros programadores juniors a crecer) o las meras habilidades sociales (que le caigas bien a la gente, que el resto de companyeros confien en ti y esten contentos de tenerte en el equipo).
Decir que un tio que no sabe lo que es scrum, pair programming o una tabla parnas (que no lo habia oido en la vida, por cierto) no es un buen programador me parece una barbaridad, en serio. Soy un gran fan del TDD, pero a veces tengo la impresion de que hay mucho «fanatico» en ese mundillo que cree que el TDD y XP son el Santo Grial y es la unica manera posible y aceptable de desarrollar software, y todo el que no lo practique o no lo sepa no es un buen programador.
Un saludo y gracias por el post, sin duda da pie a un buen debate 🙂
Angel.-
Hola Ángel;
como hemos comentado por ahí arriba, la idea de fondo es que si un desarrollador no sabe lo que es scrum o pair programming, no es un profesional responsable. No hablamos de que lo practique, pero si que lo conozca: hay que tener, como profesionales, la inquietud de estar con un ojo en lo más reciente del sector y otro en el pasado. Con la primera perspectiva, estaremos en disposición de contribuir al avance del medio aportando algún tipo de valor a las nuevas tendencias; con la segunda, estaremos aprovechándonos de lo que otros investigaron para evitar reinventar la rueda.
No es necesario que se memoricen los patrones de diseño, pero si que se hayan leído alguna vez y comprendido: un profesional no debería ‘descubrirlos’ a medida que los necesite o se los enseñe la empresa que lo ha contratado. Ese tipo de conocimiento debe llevarlo ‘aprendido desde casa’ porque es la base mental a partir de la cual estructurará su trabajo.
Las comparaciones con otras profesiones son siempre muy reveladoras: imagina un cirujano que aprende anatomía una vez en la plantilla de un hospital; o que descubre el corte con láser cuando su empresa le enseña la máquina que tiene que usar; o que aprende la organización y estructura del personal en quirófano una vez que está dentro del equipo ya operando… no tiene porqué preferir el láser al bisturí, pero DEBE saber que existe… Pasa exactamente igual con las prácticas del pasado: no tiene porqué defender técnicas como una lobotomía, pero si saber qué es, cómo se practicaba y cuáles fueron los resultados. Será mejor médico con ese conocimiento? SIn duda: contará con más recursos en los que basarse a la hora de escoger el procedimiento a seguir según cada caso o escenario.
Saludos!
Una gran parte de lo que viene en tu post, si bien es cierto, la mayoría de ello no, y dejame decir que te has aventado una buena copia de lo que viene en el libro The Clean Coder, prácticamente me parece un copy – paste, solo que traducido, como por ejemplo en la pagina 18, solo por dar una muestra.
Si; como comenté ahí arriba, este artículo es una ‘reacción’ tras la lectura del Clean Coder.
Lo que comenta el tío Bob es tan importante y tan ignorado en general por el gremio, que se merecía una reseña. Yo sólo he dibujado el contexto con el que enmarcar sus ideas buscando un mayor impacto.
Es, como me comentó recientemente un colega, un «post para despertar conciencias».
Saludos!
La cantidad inmensa de referencias sobre las Tablas Parna en Google demuestra la necesidad inexcusable que de su conocimiento tiene todo programador que se precie…
Ahora en serio: vale que hay que formarse y que todo profesional responsable debe hacer bien su trabajo. Pero la lista roza lo pedante. Sólo te falta incluir ‘Inventarse un lenguaje Turing completo esotérico con un alfabeto no-latino’.
Coincido con la mayoria de las cosas, en las que no estoy de acuerdo es en lo referente a las metodologías, creo que eso es mas de lo que un programador debe saber y se mete a otros campos como la administración del tiempo, el trabajo en equipo, etc; que si bien es importante conocer un poco de ellas no me parece esencial para ser un buen programador.
Me parece que para ser un buen programador debemos mirar a las bases. En donde vivo algunas universidades decidieron que lo importante es formar a los estudiantes de sistemas e informática de acuerdo a las exigencias de la industria, dicho de otra manera se dedicaron a enseñar Java obviando el diseño de algoritmos, las estructuras de datos, entre otras cosas. Los muchachos al egresar podran hacer diagramas UML pero no sabran explicar un algoritmo Quicksort.
Por cierto me parece que el titulo adecuado para este post deberia ser: «Lo que todo buen ingeniero de software debe saber» ;-).
Caray, definitivamente ya me estoy volviendo viejo, muchos de los conceptos que manejas ni siquiera los vimos cuando estaba en la carrera, aunque claro… ya han pasado algunos añitos. 🙂
Yo agregaria conocimientos de estructuras de datos (Listas, colas, pilas, arboles, grafos, etc). Normalizacion, Recursividad.
Hola Carlos!
Muy buen Articulo, déjame Felicitarte, y también
estoy 100% de acuerdo contigo y mas en la parte
de que siempre tendremos que estarnos actualizando e
innovando.
Haciendo una reflexión… Yo NO se Programar u.u
Gracias!, y de nuevo Felicidades.
wow… la verdad si me impresiono el articulo… pero mas aun el debate de comentarios… aprendi mucho y que en verdad hay un mundo ahí afuera… necesito mas experiencia y mas dedicacion… y no nos queda mas que aprender… aunque estoy de acuerdo en que unas bases (como lo son c y c++) bien cimentadas te ayudaran a aprender lenguajes de alto nivel como lo son c# y java… aunque se puede prescindir de estos y resolver problemas en la practica… aunque… gracias a dios… cada problema tiene muchas soluciones el chiste es buscar cual es la que mejor se adapta al proyecto… pero en si… estuvo muy bien el post… me gustaria algo de lecturas recomendadas gracias… buen año
Es muy temprano aqui donde vivo y no he podido leer todos los comentarios pero yo me ire un poco mas alla de la simple base de conocimientos que se ha propuesto en el articulo, si revisamos el curriculum estara lleno de lenguajes de programación acompañados de certificaciones y diplomas que avalan ese conocimiento, pero ninguno de esos documentos nos indicara el nivel de abstracción del programador, en un prinicpio se contrata por su experiencia pero se desconoce si posee las capacidades necesarias para abstraer la realidad del mundo cotidiano y dibujarla cual pintor o artista en el entorno del lenguaje de programación, cierto es que muchos de los conceptos mostrados aqui son de metodologias básicas en las que se aplica esta capacidad que estoy comentando, mencionaba mi primer maestra de programación que queda uno posee un nivel de abstracción diferente y que eso hace diferente el codigo de cada programador y lo demostraba creando versiones mas eficientes y reducidas en lineas de cada codigo que nosotros escribiamos en el pizarron, y es en ese punto en dodne muchos programadores actuales fallan, al no buscar como mejorar su trabajo, de hecho podemos ver que existe actualmente una generación o varias no se, de programadores copy-paste, aquellos que en lugar de pensar en como se hace, buscan en internet quien ya lo haya hecho y solo copiar y pegar los codigos prefabricados, y esto no seria tan malo sino fuera porque ni se molestan en entender como funcionan
Para saber todo eso se necesita dedicación exclusiva durante 25 años … osea que si empiezo ahora podré encontrar trabajo dentro de 25 años …
Esto me suena a selección de personal inhumana que desechan a carnes con ojos solo porque no conocen por ejemplo metodología ¡’Scrum’!, o no se conocen de memoria y recitándolo los 24 tipos de patrones en programación, cuando quizás esas personitas resultan idóneas para el puesto y, es más, podrían aportar más a la empresa que algún que otro coder dromedario que conoce 200 lenguages distintos y aplica 100 patrones a la vez (alguno incluso sin descubrir aún), pero no se compromete con la filosofía de la empresa, o no tiene la mente abierta para solucionar los problemas que surjan …
Hombre, yo creo que no se puede ser tan radical, estos requisitos no lograrían dominarlos más de 40 personas en todo el mundo.. ¿y los demás de qué comemos si además tenemos que ocuparnos de más menesteres aparte de escribir código?
Si bien el sitio me gustaba bastante en general, este post es muy, muy pedante…, no sabía que pensaba usted así sobre el resto de mortales que no dominan los 300 requisitos que usted sí …
… Por cierto yo añadiría lenguage Máquina, código Morse, lenguage Sordomudo Internacional, y por supuesto BASIC … sin menospreciar experiencia demostrable en «Movimiento de Tiro Obliquo con Proyectiles» …
.. Creo que confunde usted saber programar, o saber Javascript, con ser un gurú de la programación o un «Hacker Master del Universo» … pero le FELICITO, tiene la polémica servida para que la página prospere en los buscadores y gane SEO.
Mis respetos y SALUDOS de un mercenario del código que no pretende ser Robert C. Martin…
P.D.: Me voy a poner ahora mismo a implementar un mecanismo para conseguir que BASIC siga el paradigma OOP… ya subiré la solución dentro de 25 años…
Ahora se lleva lo asíncrono. Y no estudié nada de esto. Programó por hobby. La máquina de Estados a cambiado desde el primer libro que se escribió. A mi parecer la programación como cualquier arte, se diferencia en dos tipos: los que nacen con el y no tienen ni puñetera idea de como lo hacen, ylos que lo quieren hacer y se compran los fasciculos de por ejemplo aprende a pintar.