Si me llegaran a preguntar si soy un experto en programación con .net, inicialmente les podria responder que es algo dificil de acotar ya que antes de conocer un lenguaje, plataforma o entorno de desarrollo se requiere un conocimiento sólido en fundamentos de programación.

Este aspecto es uno de los que lamentablemente muchos de nosotros adolecemos, pues no puedo mentir, he conocido profesionales que confunden la programación estructurada con la orientada a objetos y bueno, respecto a al programación funcional no puedo opinar mucho, pero si hablamos de conocer personas que dominen ese aspecto… si, he conocido de esas, pero fuera del país… triste, no?

Me parece preocupante que hayan profesionales que consideren que la creación y uso de clases se pueda tomar como programación orientada a objetos.
Lamentablemente hay mucho sesgo en el mercado educativo, por que seamos honestos, hace mucho que esta rama se ve como un mercado -ya no- virgen en el cual por un monto módico algunos profesionales se prestan a dictar clases de programación, modelamiento o incluso diseño de software!

Pero si regresamos a la programación y especificamente seguimos hablando de .NET me he tenido que topar con bromas de amigos, conocidos e incluso desconocidos que han levantado las cejas cuando les he dicho “yo trabajo sobre plataformas .NET”, y aunque en en realidad tal situación no me deprime, debo admitir que me preocupa y me lleva a la mente “qué tipo de programadores han conocido?”

Sobre todo esto, me siento en la obligación de poner una mano en mi corazon y otra en el teclado para decir, eso no es asi! y si lo es, dejará de serlo!
Tenemos que romper muchos paradigmas, de momento aqui listaré algunos:

1. Para programar en .net necesitas conocer la sintaxis: Mentira!! conocer la sintaxis no nos asegura nada más que hacer un if, un for y posiblemente un switch. Y en realidad, que funcionen correctamente… es otra historia!
2. Además de las sintaxis, es bueno saber acceso a datos y algunas librerías: Aqui el tema es muy delicado porque hay muchas personas que no salen de los temidos DataSets o ya siendo optimistas, están preguntándose si sería más rápido usar un buen DataReaderMencionar ”algunas librerías” suena muy optimista, y lo que más me preocupa aqui es la falta de conocimiento para poder diferenciar un namespace de un assembly y de estos, saber cual se referencia y cual se puede importar.
   
3. El drag and drop es mi amigo: No amiguito! el drag and drop sirve muchas veces para hacer una buena demostración del producto o en la mejor de las situaciones, cubrir casos ideales que lamentablemente no llegarán a más del 20% de lo requerido 😦
4. Mira… esto hay que reutilizarlo, sólo es tema de copiar, pegar y hacer algunos ajustes: Como dice mi abuelita, “el ocioso trabaja doble” y aunque en realidad se requiere bastante precisión para copiar/pegar/ajustar, resulta muy trabajoso tener que replicar algún cambio por mejora o correción.Recuerdo que una vez la tarea asignada de una persona fue replicar la funcionalidad de un formulario basándose en uno que ya estaba terminado, y bueno, algunos se toman muy en serio eso de “replicar”, ya que llegado a un punto nos encontramos con controles, imágenes y código que había sido copiados y luego modificados sin tener en cuenta que muchas de las llamadas a las clases, funciones y estilos estaban referenciando al formulario anterior!
5. Eso no es tan complicado si se puede hacer, tenemos que modificar el control …: Les voy a contar, salvo pocas oportunidades he conocido empresas que paguen por construir controles personalizados, ya forma parte de nuestra experiencia recomendar algun producto que nos haga la vida más facil y desde aqui, comenzar a pensar en el negocio.
   Y bueno, si no puedes comprarlo, estoy seguro que dependiendo del caso hay muchas variantes y recomendaciones open source muy robustas que permiten tener un nivel de tranquilidad adecuado 🙂
6. Vamos a aplicar el patrón que acabamos de aprender: Cuidado! ´salvo excepciones nadie aprende un patrón de diseño a la primera y menos aun, se debe ser cauteloso para comenzar a incluir aspectos que el resto del equipo no pueda captar rápidamente.
7. Vamos a usar ese framework y sobre la capacitación no te preocupes, la hago en dos horas: Increible!! Dónde quedan las curvas de aprendizaje, dónde?
8. Probar mi código?: Si… el código tiene que probarse y en realidad no tiene nada que ver con verificar si compila o no, pero manejar un equipo que por ejemplo, no sepa de unit testing y que a la fecha no le haya llamado la atención… es como para ponerse a pensar sobre como se manejará todo eso cuando se quieran hacer pruebas de regresión.
9. Control de Versiones? ahh como el SourceSafe!: Debo confesar que para no perderlos les termino diciendo… si! pero mucho mejor 🙂
   Por otro lado siempre quedará el otro espectro de personas que lamentablemente no conocen la utilidad de un controlador de versiones y bueno, mejor ni mencionar Integración Contínua.
10. No puedo avanzar porque el resto todavía no termina: Pues si es asi mejor no les cuento como se hicieron productos como Linux, Windows o incluso Visual Studio, la verdad no creo que todos hayan trabajado de manera secuencial, por lo menos habrán usado stubs o habrán simulado valores de retorno, no?
11. JavaScript? Horror!: Cuidado con esto, es importante conocer JavaScript, y más aún si se quiere hacer uso o construcción de plugins necesarios para el entorno… escuché jQuery? si, necesitas conocer JavaScript si quieres explotarlo como debe ser. No, no todo es hide() 😦
12. Arquitectura de la aplicación? bueno, la que viene por defecto!: No, hasta hace poco tiempo no había algo oficial al respecto, a menos claro te des una vuelta por la web de Patterns & Practices, pero más alternativas? pues si, en mi caso, hace algún un tiempo compré un libro que resume muchas arquitecturas basadas en Java :), no me digan nada! Acaso no han leido El arte de la guerra? 😀

Si bien es cierto he listado muchos argumentos que podrían encontrarse en equipos de desarrollo basados en otras plataformas, hay muchas consideraciones que he encontrado muy arraigadas en programadores .NET (pues si, también he trabajado codo a codo con equipos de otras plataformas :)), las cuales creo que tienen algo que ver con la facilidad de uso que nos da el Visual Studio.  Y no, no estoy culpando a la herramienta, acaso no han visto mi blog? lo baso casi en su totalidad en ella 😀 (No Billy por favor no me borres el blog!)

Tranquilos! lo que sucede que siempre he creido que Visual Studio es una gran herramienta (para mi, la mejor), pero asi como la ven va a terminar haciendo lo que nosotros le pidamos que haga con el lenguaje que creamos conocer. Pues a pesar de que en el transcurso del tiempo Visual Studio ha logrado mejores cambios y funcionalidades, no va a adivinar lo que queremos construir. Todavía no llega ese service pack 🙂

Por otro lado, siempre he creido en que la disposición y sinceridad de las personas para aceptar no conocer un tema  y la flexibilidad que pueda tener para aceptar el cambio, aprender y poner en práctica el mismo, nos dará un vistazo general de las mejoras que se puedan lograr.
De todo esto, no olvidemos que el éxito del proyecto también dependerá de esta característica, de cuál más? 😀

Ya casi para terminar, personalmente no me considero un plus non ultra en la materia (aunque claro, mi abuelita piense lo contrario :)), y a pesar de haber trabajado con versiones de .NET y Visual Studio desde ediciones muy pasadas, haber experimentado muchos casos y haber tenido mucha suerte en varios de los proyectos, admito haber cometido muchos errores, y estoy 9998.5% seguro de que eventualmente volveré a cometer otro mas bonito que el anterior,

Quizá por ello ahora, en esta etapa de mi vida, me muestro mucho mas abierto a observaciones, comentarios, alternativas de solución y propuestas.  Mientras tanto,  trato firmemente de eliminar esos paradigmas de mi persona, y claro! si el tiempo y mi equipo lo permiten, encontrar con el resto, el camino correcto 🙂

Un Abrazo
@Jersson
PD: No crean que he olvidado el viejo y conocido “Déjalo así, ya funciona”