Tu no sabes programar!

[[AgustinOrtu]]

Un articulo muy interesante: Tu no sabes programar!

[[Al González]]

Empezado por AgustinOrtu

Un articulo muy interesante: Tu no sabes programar!

¡Escalofriante! Me he reído bastante con esta parte:

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 lenguaje 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…

De lo que dice el autor, creo que se rescatan dos o tres cosillas. Pero me quedo con las coherentes respuestas que el/la comentarista gnz/vnk le da ahí mismo.

Por cierto, no considero ser un programador profesional. Suelo sentirme algo incómodo cuando alguien me presenta como tal.

Saludos.

Al González.

[Casimiro Notevi]

Empezado por Al González

... me quedo con las coherentes respuestas que el/la comentarista gnz/vnk le da ahí mismo.

[Ñuño Martínez]

Totalmente de acuerdo con el maestro Al, como casi* siempre.
____________________

* Pongo "casi" para curarme en salud. Nunca se sabe.

[roman]

¿Que el artículo no lo escribió maese Delphius?




LineComment Saludos

[[Delphius]]

Empezado por roman

¿Que el artículo no lo escribió maese Delphius?




LineComment Saludos

¿Alguien me llamó?

Pretender resumir que la programación se basa solamente en aprender cosas relacionadas con la Ingeniería de Software y algunas buenas prácticas es un grave error.

Si, son útiles las buenas prácticas. Pero por si mismas no van a llevar a nada. ¿De que te sirven poner las bases y cimientos si después no usas los ladrillos adecuados para trabajar la sismo resistencia del lugar de manera correcta?

Rescato que siempre hay que estar estudiando, y de vez en cuando salir de nuestra zona de confort. Pero en última para programar hay que meter código. Y para ello, hay que tener a mano el manual o la documentación. Los lenguajes van y vienen, asi que casarse con uno no es buena idea, pero tampoco se puede pretender sabernos 30.
La otra parte de ser desarrollador es ir asimilando conceptos que son transversales. Por ejemplo: los paradigmas. Voy a decir hasta el cansancio: una cosa es estudiar POO y otra es estudiar POO con Delphi. Lo fundamental es aprender los paradigmas, luego tomar los lenguajes que los soporten.
Cosas como REST, JSON, etc. también son fundamentales y necesarias. Nuevas tecnologías irán apareciendo. Hay que ir aprendiendolas, y un error es estudiarlas como algo fijo y atado a una solución/implementación en particular para un lenguaje en particular sin ver en si el concepto.

Un gran mal que veo en los estudiantes: no saben entender abstracción de conceptos. Siguen apareciendo preguntas como "¿Que es una clase de JAVA?" En lugar de "¿Que es una clase?", o "¿Como se usa el while de C?" en lugar de "¿Que es y cual es el principio o idea detrás de un ciclo WHILE?"
He notado también que se ha perdido cosas tan básicas como que no saben entender que es recursión. No saben que son los TADs. Simplemente no saben pensar. Usan sin saber usar. Usan, sin saber.

Extraño que en el artículo no haya dedicado algo sobre saber realizar un análisis de algoritmo para determinar si la complejidad computacional es adecauda. O al menos siquiera que dedique una mención a la complejidad ciclomática.
También no dice nada de un análisis de acomplamiento/cohesión...
Estas 3 cosas para mi son fundamentales para ser un desarollador. No basta con picar código, sino que el mismo sea óptimo, analizado, estudiado.


La verdad es que viniendo del fundador de Open Libra, me esperaba algo mejor que esa simpleza de artículo.
Yo no podría escribir eso, sinceramente.
De redactar algo, mínimo armo un libro explayando cada tema que he mencionado en este post.

No es que me crea un experto desarrollador, pero es que lo que digo es lo mínimo de esperarse. Me importa tres pedos si la formación la adquiere en una universidad o si es totalmente autodidacta. Lo importante es que lo tenga.

Saludos,

[mamcx]

Quien no a caido en esa forma de pensar?

Se ve muy a menudo. Es muy notable entre quienes afirman que hay que tener un solido conocimiento matematico para ser un buen programador.

Se podria argumentar que es facil sobre-valorar la influencia del conocimiento de un area en otra. Como quien dice que es super-util aprender latin.

Por ejemplo, de joven leia mucho sobre historia. Excesivamente. Argumento que saber historia es critico para ser un buen programador! porque en *mi mente* soy buen programador y ademas me encanta la historia. "Obvio" estan ligados.

Pensandolo mejor, pa' lo que me ha servido es que leer mucho te prepara para .... leer mucho. Asi que leo todos los dias mucho, sobre programacion, por ejemplo. Asi que hay un efecto, pero quizas no por las razones que podrian pensarse.

-------
Es facil confundir conocimiento aplicado a sabiduria. Lo que necesito en especifico, sobre lo general.

Por ejemplo:

http://www.etnassoft.com/2011/07/14/...bes-programar/

- ¿Sabes qué es un Diagrama Nassi-Shneiderman? Si no lo sabes, ¿porqué no?

Otra forma de visualizar. Visualizar es util, pero esta forma en especifica no es tan util como para ser indispensable.

- ¿Sabes cuál es la diferencia entre una máquina (de estados) Moore y una Mealy? Pues deberías!

Saber como hacer un maquina de estado es MUY util. Pero la forma mas util, es muy simple y no hay que preocuparse por otras.

- ¿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?

Saber como implementar quicksort es util. Saber cual es el sort mas practico es MAS UTIL.

- ¿Sabes lo que quiere decir el término ‘Análisis de transformación‘?

Ni idea. Pero transformar cosas es util.

- ¿Puedes realizar una descomposición funcional de un algoritmo utilizando un Diagrama de Flujos?

Descomponer y recomponer codigo es util. Es mas veloz hacerlo directamente que ir a otra herramienta.

- ¿Sabes que significa el concepto de ‘datos vagabundos‘ (Tramp Data)?

Limpiar datos es muy util. https://en.wiktionary.org/wiki/tramp_data no te enseña nada que no sepas ya.

Los otros son asi por el estilo. Pueden ser utiles dado el caso, pero NO SON INDISPENSABLES.

------

Sobre "Que debes saber como programador"

- Patrones de Diseño

La mayoria son debido a idiosincracias de los lenguajes OO, pero innecesarios en lenguajes funcionales:

http://fsharpforfunandprofit.com/fppatterns/

- Principios de Diseño:

SOLID solo aplica a OO. No es la unica forma.

SOLID *no es* un principio de diseño. Es como decir que "principios de mecanica" es como usar una fresadora electronica industrial.

- Metodologías:

Es mas util como descubrir cuando la metodologia esta estorbando o perjudicando el diseño.


- Disciplinas:

Conocer disciplinas esta bien. Curiosamente unas disciplinas eliminan, invalidan o hacen menos relevantes a otras.

- Herramientas:

Y en herramientas solo lista las de diagramas. Son poco utiles en la vida real. MAS UTIL es como hacer visualizadores de codigo, desempeño, relaciones etc. El *tipo concreto* de diagrama se escoje de acuerdo

-----

Asi que que realmente seria util?

Me gusto esto:

http://worrydream.com/LadderOfAbstraction/

Pregunta: How can we design systems when we don't know what we're doing?

Esto es programar!

When designing at this boundary, the challenge lies not in constructing the system, but in understanding it. In the absence of theory, we must develop an intuition to guide our decisions. The design process is thus one of exploration and discovery.

...
...
Likewise, the most powerful way to gain insight into a system is by moving between levels of abstraction. Many designers do this instinctively. But it's easy to get stuck on the ground, experiencing concrete systems with no higher-level view. It's also easy to get stuck in the clouds, working entirely with abstract equations or aggregate statistics.

Se podria argumentar que la habilidad mas importante de un programador es darse cuenta que esta perdido y sin rumbo, y saber encontrar su camino.

Para ello. Lee. Hacer experimentos/prototipos. Visualiza. Comete errores, busca que paso, donde esta la causa. Hace preguntas (normalmente a google!), mejora su comprension de sus herramientas, esta dispuesta a dejarlas atras y aprender otras.