Desarrolladores explotados

Developer9 · #1 (**permalink**) 01/02/2006, 15:52

Que tal compañeros.... he aquí un dilema... llegar a ser un gran conocedor de la programación es dificil. Muchas de las cosas que nos enseñan en la uni son solo simulaciones pero que no dejan de ser la base para aprender. El trabajo como desarrollador es un tanto complicado para los que somos estudiantes, trabajamos todo el día y vamos a clases a la u en la tarde y noche. Hace días mi mejor amiga me dijo: "yo quisiera trabajar pero no quisiera ser explotada" ya que nos ve muy metidos en el trabajo y a veces no hay hora fija de salida, incluso a veces nos quedamos hasta mas tarde programando y no vamos a clases, y cuando vamos a clases vamos a dormir a clases por estar sentados todo el dia frente a una compu. Ella es becaria en Microsoft, en las oficinas locales aquí en la ciudad, donde su mision es preparar charlas a empresas sobre los productos microsoft y estudiar para las certificaciones gratis donde ya tiene una, ella es MCP.

Continuando con lo que me dijo: "...quisiera estar en un proyecto de software pero ayudar en algo... no trabajar todo el día..." ya que se ha dado cuenta que los que trabajamos sabemos mas cosas que en clases no nos enseñan o nos enseñan en teoría, sin contar con la experiencia que se adquiere. Ella quisiera aprender pero no quiere la presión del trabajo...

Y por ultimo yo pienso y se lo he dicho que aunque ella sea MCP yo se programar mas en .net que ella.

Ustedes que piensan...

cbwarz · #2 (**permalink**) 01/02/2006, 17:10

La experiencia siempre va a ser mejor que el conocimiento teorico.
Por otro lado, puede ser un "buen" programador, pero sino has estudiado las tecnicas y tecnologias "nuevas" igual quedas "resagado".

Un buen programador debe tener un conocimiento profundo del lenguaje, tener buenas practicas de programacion, conocer de patrones de diseño, etc.

Entonces, claro a nadie le gusta ser explotado, pero de algun lado tienes que sacar la experiencia no?
La mayoria de las personas que salen de la universidad (yo lo fui en algun tiempo atras) sabes muy "poco" (esto es relativo claro) sobre las nuevas tecnologias.
Ademas no te enseñan a trabajar en equipo, a tener fechas de entrega "reales", etc.

Y por si fuera poco estamos a 2 años de quedar obsoletos sino continuamos estudiando.

Son mis 2 centavos :)

axy108 · #3 (**permalink**) 01/02/2006, 17:17

pues igual y la experiencia es valiosa, pero tu no puedes llegar a una empresa con tu linda cara y decir yo si se programar debe de haber algo que lo avale y para eso existen las Certificaciones (a pesar de que quien las tenga no necesariamente sabe programar), y desgraciadamente en esta carrera que elegimos estudiar nos volvemos obseletos en muy poco tiempo y es por eso que necesitamos actualizarnos todos los dias.

Con respecto a de que a veces el tiempo no alcanza para terminar y hay que quedarce a seguir programando, yo opino que eso es debido a nuestras malas practicas a la hora de programar, no tenemos una buena planeacion ni nada por el estilo y es por eso que a veces los tiempos que estimamos no son suficientes.

Bueno eso es lo que yo opino no se los demas...

SALUDOS

jeubeda · #4 (**permalink**) 02/02/2006, 06:19

Cita:

Iniciado por Developer9

Que tal compañeros.... he aquí un dilema... llegar a ser un gran conocedor de la programación es dificil. Muchas de las cosas que nos enseñan en la uni son solo simulaciones pero que no dejan de ser la base para aprender. El trabajo como desarrollador es un tanto complicado para los que somos estudiantes, trabajamos todo el día y vamos a clases a la u en la tarde y noche. Hace días mi mejor amiga me dijo: "yo quisiera trabajar pero no quisiera ser explotada" ya que nos ve muy metidos en el trabajo y a veces no hay hora fija de salida, incluso a veces nos quedamos hasta mas tarde programando y no vamos a clases, y cuando vamos a clases vamos a dormir a clases por estar sentados todo el dia frente a una compu. Ella es becaria en Microsoft, en las oficinas locales aquí en la ciudad, donde su mision es preparar charlas a empresas sobre los productos microsoft y estudiar para las certificaciones gratis donde ya tiene una, ella es MCP.

Continuando con lo que me dijo: "...quisiera estar en un proyecto de software pero ayudar en algo... no trabajar todo el día..." ya que se ha dado cuenta que los que trabajamos sabemos mas cosas que en clases no nos enseñan o nos enseñan en teoría, sin contar con la experiencia que se adquiere. Ella quisiera aprender pero no quiere la presión del trabajo...

Y por ultimo yo pienso y se lo he dicho que aunque ella sea MCP yo se programar mas en .net que ella.

Ustedes que piensan...

Si tu dilema es entre experiencia y estudio, mi opinión es que la experiencia es importante, y es muy valioso tu esfuerzo de trabajar y estudiar, que es un hecho muy repetido entre nosotros; pero el estudio no es reemplazable ni minimizable. El estudio sistemático y dirigido, en un plan de varios años, aunque no te de experiencia (pero sería muy bueno que existieran prácticas que te den esta experiencia durante tu estudio), te da una imágen global y consistente que de otra manera no lograrás con la práctica. La práctica sola te cierra el panorama, o te lo reduce a un ámbito estrecho, limitado con el trabajo que vas resolviendo. Ambas cosas son necesarias.
En general, el problema en nuestros países es que el plan de estudios "deja que desear" por lo menos, sin entrar en algo que de por sí requeriría un foro entero.

Developer9 · #5 (**permalink**) 02/02/2006, 12:49

Cita:

Iniciado por cbwarz

La experiencia siempre va a ser mejor que el conocimiento teorico.

mmm.. eso tambien pienso yo. Debido que la teoría no es nada en comparación con la realidad.

Cita:

Iniciado por axy108

pues igual y la experiencia es valiosa, pero tu no puedes llegar a una empresa con tu linda cara y decir yo si se programar debe de haber algo que lo avale y para eso existen las Certificaciones (a pesar de que quien las tenga no necesariamente sabe programar),

Para una certificación estudias de un libro, te haces conocedor del lenguaje, pero no tienes una practica real. Por ejemplo, para validar textbox en asp.net se usa un control llamado RequeridFieldValidator, que en mi trabajo lo veía hasta en la sopa... un día hablando con mi amiga Martha sobre las preguntas de la segunda estrella de Microsoft había una que se refería a ese control... Y yo no dudé ni un segundo en saber cual era la respuesta correcta, mientras que mi amiga fue a ver su libro ya que lo había leido antes. Y eso que ella es MCP (Microsoft Certificated Profesional)

Cita:

Iniciado por axy108

Con respecto a de que a veces el tiempo no alcanza para terminar y hay que quedarce a seguir programando, yo opino que eso es debido a nuestras malas practicas a la hora de programar, no tenemos una buena planeacion ni nada por el estilo y es por eso que a veces los tiempos que estimamos no son suficientes.

Eje!! con respecto a los tiempos... en primer lugar los desarrolladores no hacemos el diagrama de Gant

a mi parecer el problema es que allí si nos quieren explotar... ya que siempre los jefes del proyecto quieren que terminemos rapido para darnos mas pantallas gracias a que ellos no supieron planificar bien el tiempo, en mi caso cuando entré a trabajar aprendí rapido el lenguaje (fue cuando empecé desde cero en C#) y el jefe estaba contento con que haga una pantalla diaria... luego eso se transformó en dos (cuando había que hacer ventanas de ayuda) y luego me mandó a hacer una ventana transaccional (donde había que aplicar una lógica mas pesada, conocer el lenguaje ya no era el problema) y siempre taba atras mio diciendo... ya! ya terminó!

Pero al final aprendí asp.net, a administrar SQL Server y mucho lenguaje sql

TolaWare · #6 (**permalink**) 02/02/2006, 20:59

Lamentablemente, siempre se tiende a empezar a codificar sin siquiera haber hecho la planeacion del software que tenemos que desarrollar. Este es un punto muy importante. Por suerte en mi facultad tenemos 3 materias que se dedican a enseñarnos la importancia de la planeacion y como planear un proyecto en forma correcta.

MaxExtreme · #7 (**permalink**) 12/02/2006, 04:43

Developer9, ¿crees que un MCP significa algo? Claro que sabrás tú más que tu amiga... Normalmente presumir de títulos es lo contrario a saber de verdad.

Por otro lado, lo que has dicho del TextBox, saberlo o no saberlo, es algo superficial. No sabes más de programación por saber eso... No es más que un dato concreto de un control concreto de una plataforma de desarrollo concreta de un lenguaje concreto (...). El saber programar se demuestra en el conocimiento profundo de un lenguaje, o ahora, dado que todo está copiado unos de otros, saber técnicas de programación: POO (polimorfismo, interfaces, pimp...), programación genérica (contenedores, metaprogramación...), raii, punteros inteligentes, reflection... y mil cosas más.

¿A qué te refieres con "pantallas"?

¿Al final olvidásteis VB6 y os pasásteis al lado oscuro? (Rama C)

RootK · #8 (**permalink**) 13/02/2006, 10:40

El hacer una pantalla con algunas cosas, y que de algun resultado no quiere decir propiamente que sabes programar, hay cosas mas importantes como la lógica, conceptos de POO (de acuerdo con MaxExtreme), diseño de patrones, estandarizacion, estilos de programacion, personalmente me he encontrado con mucha gente que dice saber programar y me enseñan sus sistemas y realmente cuando ves el código (hablando de c#) te das cuenta de que su estilo es bastante estructurado, no hay reglas, no separan la lógica de negocio, de datos, de componentes, etc... y repiten código como no tienes idea, es decir, no tienen las bases para mejorar ese estilo, pero bueno, ya es cuestion de cada quien

Salu2

MaxExtreme · #9 (**permalink**) 13/02/2006, 12:40

Cierto, yo sólo consideraré a alguien que sabe "programar", y no "hacer pantallitas", a cualquiera que sepa:

Ensamblador, o...
Sockets Berkeley, o...
POO con interfaces, downcasting, herencia de varias clases (no un típico Mueble->Silla,Mesa,Armario; sino algo con consistencia), o...
Programación genérica, o...
Programar una aplicación con GUI a puro "código", o...

...cualquier otra cosa que de evidencia de que tiene idea de algún campo en concreto (aunque sólo sea uno) y no arrastrar controles a un formulario, darles doble click e introducir 4 líneas de código.

Eso es la perspectiva de lo que yo llamo "programación" y similar, no lo otro que más bien es "diseño", que parece más complicado Flash+ActionScript que VB.

Developer9 · #10 (**permalink**) 14/02/2006, 11:18

Cita:

Iniciado por TolaWare

Lamentablemente, siempre se tiende a empezar a codificar sin siquiera haber hecho la planeacion del software que tenemos que desarrollar. Este es un punto muy importante. Por suerte en mi facultad tenemos 3 materias que se dedican a enseñarnos la importancia de la planeacion y como planear un proyecto en forma correcta.

Que tal compañero TolaWare... bueno el problema por aca no es que no se sepa como hacer una planeacion, vemos materias como Administración de Proyectos de Software, Gestión de Proyectos, Ingenieria de Software la cosa es que se lo utilicen bien. Y como lo tipico es dejar todo para el ultimo, al ultimo andan a la carrera tratando de terminar proyectos en el tiempo planificado.

Developer9 · #11 (**permalink**) 14/02/2006, 11:25

Cita:

Iniciado por MaxExtreme

Developer9, ¿crees que un MCP significa algo? Claro que sabrás tú más que tu amiga... Normalmente presumir de títulos es lo contrario a saber de verdad.

Una certificación en un curriculum puede marcar diferencias

Cita:

Iniciado por MaxExtreme

Por otro lado, lo que has dicho del TextBox, saberlo o no saberlo, es algo superficial. No sabes más de programación por saber eso... No es más que un dato concreto de un control concreto de una plataforma de desarrollo concreta de un lenguaje concreto (...). El saber programar se demuestra en el conocimiento profundo de un lenguaje, o ahora, dado que todo está copiado unos de otros, saber técnicas de programación: POO (polimorfismo, interfaces, pimp...), programación genérica (contenedores, metaprogramación...), raii, punteros inteligentes, reflection... y mil cosas más.

¿A qué te refieres con "pantallas"?

¿Al final olvidásteis VB6 y os pasásteis al lado oscuro? (Rama C)

Me refiero a un caso de uso con todos sus escenarios. Un caso de uso tiene como minimo una pantalla (llamese ventana en el caso de una aplicacion windows o pagina en el caso de asp)

vb6 ya quedó en el olvido desde hace chance. Lo utilizo a veces cuando tengo que hacer algun proyecto sencillo de la u. En lo que se refiere al trabajo ahora estamos con .net 2005

Developer9 · #12 (**permalink**) 14/02/2006, 13:02

Cita:

Iniciado por RootK

El hacer una pantalla con algunas cosas, y que de algun resultado no quiere decir propiamente que sabes programar, hay cosas mas importantes como la lógica, conceptos de POO (de acuerdo con MaxExtreme), diseño de patrones, estandarizacion, estilos de programacion, personalmente me he encontrado con mucha gente que dice saber programar y me enseñan sus sistemas y realmente cuando ves el código (hablando de c#) te das cuenta de que su estilo es bastante estructurado, no hay reglas, no separan la lógica de negocio, de datos, de componentes, etc... y repiten código como no tienes idea, es decir, no tienen las bases para mejorar ese estilo, pero bueno, ya es cuestion de cada quien

Salu2

Eje!! claro pero el motivo del tema no iba por ese lado, asumimos que ambos tenemos una buena logica, sabemos poo y como programar ordenadamente, aunque los estandares cambian dependiendo de la compañia, solo hay que adaptarse a ellos.

No pretendia analizar que significa saber programar, sino el costo/beneficio de las maneras de aprender

Developer9 · #13 (**permalink**) 14/02/2006, 13:08

Cita:

Iniciado por MaxExtreme

Cierto, yo sólo consideraré a alguien que sabe "programar", y no "hacer pantallitas", a cualquiera que sepa:...

Yo creo que mas bien se debería tener otro enfoque no orientado a las lineas de codigo sino a los procesos de ingenieria que se juegan mucho antes de empezar con la codificacion

MaxExtreme · #14 (**permalink**) 14/02/2006, 16:08

Cita:

Iniciado por Developer9

Yo creo que mas bien se debería tener otro enfoque no orientado a las lineas de codigo sino a los procesos de ingenieria que se juegan mucho antes de empezar con la codificacion

Realmente pongo esos ejemplos debido a que quien sepa hacerlos, normalmente es que ha tenido un proceso previo para llegar ahí. Es como decir que un atleta de 100 metros lisos le consideré como tal si lo hace en menos de 15 segundos, porque si lo hace en más, de atleta no tiene mucho. Es como un "listón". Para llegar ahí se supone que antes hay que saber unas cuantas cosas más.

Los patrones de diseño de los que hablas, fundamentalmente sacados de la universidad y libros, aún no los he usado. Acepto la documentación automática, acepto los diagramas UML para grandes equipos, etc. Pero no acepto "patrones" sin sentido. Aún no me he encontrado una aplicación en la que seguir ningún patrón.

n cualquier caso, el que se encarga de estas cosas es el líder del proyecto, no un programador, por lo que el programador sólo debe saber implementar lo que le diga el diseñador, es decir, codificación. Por eso se les llama "picacódigos".

MaxExtreme · #15 (**permalink**) 14/02/2006, 16:10

Cita:

Iniciado por Developer9

Que tal compañero TolaWare... bueno el problema por aca no es que no se sepa como hacer una planeacion, vemos materias como Administración de Proyectos de Software, Gestión de Proyectos, Ingenieria de Software la cosa es que se lo utilicen bien. Y como lo tipico es dejar todo para el ultimo, al ultimo andan a la carrera tratando de terminar proyectos en el tiempo planificado.

Como te he dicho antes, estimo esas asignaturas inútiles.

Primero, porque para programar hace falta práctica, experiencia y familiarización de las utilidades/herramientas y sistema operativo a usar; no patrones de diseño.

Segundo, porque estos patrones los implementa un diseñador, que ya ha sido anteriormente programador avanzado, normalmente el líder del equipo, no los programadores en sí (qué desastre si cada programador usase el patrón que le parezca mejor en ese momento).

MaxExtreme · #16 (**permalink**) 14/02/2006, 16:15

Cita:

Iniciado por Developer9

Una certificación en un curriculum puede marcar diferencias

Me refiero a un caso de uso con todos sus escenarios. Un caso de uso tiene como minimo una pantalla (llamese ventana en el caso de una aplicacion windows o pagina en el caso de asp)

vb6 ya quedó en el olvido desde hace chance. Lo utilizo a veces cuando tengo que hacer algun proyecto sencillo de la u. En lo que se refiere al trabajo ahora estamos con .net 2005

¿Qué diferencias marca? Como tú mismo dices, sabes más que ella. Las empresas importantes esto lo saben, y por tanto no exigen títulos de Microsoft o cualquier otra academia/empresa.

Lo que te dan es un examen relacionado con el lenguaje(s) a usar, piden resolver problemas, describir técnicas, detectar bugs... Además de cuestiones acerca de la memoria, redes, sistema operativo, herramientas, lo que sea. Los que mejor nota sacan, entran. Los que peor, se quedan fuera. Así de simple.

También suelen pedir algo de experiencia en otra empresa, pero no es imprescindible. El que demuestra que sabe, sabe y nada más ;)

Sobre esto Eternal Idol os puede confirmar todo. Ciertamente él no tenía ningún título (ni MCP ni academia ni universidad), ni ninguna experiencia, y siendo muy joven entró a trabajar de programador. Luego pasó a otra empresa muy conocida a nivel mundial, que, de igual manera, le puso un examen de C++. El sacó de las mejores (si no la mejor) notas (gracias a rellenar una parte de ensamblador y otras cosas avanzadas) y entró. Así de simple. El que sabe, sabe ;)

MaxExtreme · #17 (**permalink**) 14/02/2006, 16:19

Cita:

Iniciado por Developer9

Eje!! claro pero el motivo del tema no iba por ese lado, asumimos que ambos tenemos una buena logica, sabemos poo y como programar ordenadamente, aunque los estandares cambian dependiendo de la compañia, solo hay que adaptarse a ellos.

No pretendia analizar que significa saber programar, sino el costo/beneficio de las maneras de aprender

¿Seguro que tienes suficiente lógica? ¿Seguro que sabes POO? ...

Deberías replantearte esas preguntas. Una cosa es saber lo que aparece en tutoriales de Internet o te dan en la universidad de POO, y otra saberlo de verdad.

No cuestiono lo que sabes, simplemente te aviso de que decir "sabemos POO" es una afirmación muy peligrosa. Yo aún creo que no sé ni la mitad (repito, ni la mitad) de las posibilidades/técnicas que ofrece la POO (con base en C++ o cualquier otro lenguaje más o menos potente)... y por lo que te conozco creo que entiendo de POO un poco más que tú; así que me parece que ninguno de los tres ni de los presentes "sabe POO".

MaxExtreme · #18 (**permalink**) 14/02/2006, 16:22

Cita:

Iniciado por Developer9

Me refiero a un caso de uso con todos sus escenarios. Un caso de uso tiene como minimo una pantalla (llamese ventana en el caso de una aplicacion windows o pagina en el caso de asp)

vb6 ya quedó en el olvido desde hace chance. Lo utilizo a veces cuando tengo que hacer algun proyecto sencillo de la u. En lo que se refiere al trabajo ahora estamos con .net 2005

Pues dibujar una ventana y su programación suele ser trivial, es decir, no requiere ninguna parte importante/avanzada de código. Como supongo que programáis "ordenadamente" y por capas, tendréis en otro módulo las partes del código importantes.

Para que te hagas a la idea, de la aplicación tú programas la GUI. Pero en Nero, los botones son lo de menos, lo importante es que grabe bien. (Por poner un ejemplo).

cbwarz · #19 (**permalink**) 14/02/2006, 17:16

MaxExtreme: lee bien por favor, acepta otras ideas, y no cambies los temas para volver a caer en lo mismo.

Developer9 se referia a que "tipicamente" un caso de uso generalmente tiene una interfaz de usuario, no que la Ingenieria de Software, Arquitectura de Software, etc, etc. es programar/dibujar una UI.

Afirmaciones de que alguien sabe mas que otro NO lleva a nada!

Y asi, y asi, etc, etc.

Me gustaria platicas mas orientadas a buscar algo de provecho ya que es de los pocos foros que frecuento y la verdad no cuento con mucho tiempo.

Sinceramente
Carlos

TolaWare · #20 (**permalink**) 14/02/2006, 21:54

Cita:

Iniciado por MaxExtreme

¿Seguro que tienes suficiente lógica? ¿Seguro que sabes POO? ...

Deberías replantearte esas preguntas. Una cosa es saber lo que aparece en tutoriales de Internet o te dan en la universidad de POO, y otra saberlo de verdad.

No cuestiono lo que sabes, simplemente te aviso de que decir "sabemos POO" es una afirmación muy peligrosa. Yo aún creo que no sé ni la mitad (repito, ni la mitad) de las posibilidades/técnicas que ofrece la POO (con base en C++ o cualquier otro lenguaje más o menos potente)... y por lo que te conozco creo que entiendo de POO un poco más que tú; así que me parece que ninguno de los tres ni de los presentes "sabe POO".

El concepto de Objetos es bastante simple. No confundas el concepto de Objetos, con "lo que se peude hacer con un lenguaje Orientado a Objetos".

saber objetos es comun. Saber aplicarlos en forma correcta es algo muy distinto.

MaxExtreme · #21 (**permalink**) 15/02/2006, 07:46

Cita:

Iniciado por TolaWare

El concepto de Objetos es bastante simple. No confundas el concepto de Objetos, con "lo que se peude hacer con un lenguaje Orientado a Objetos".

saber objetos es comun. Saber aplicarlos en forma correcta es algo muy distinto.

Yo estaba hablando de POO (programación orientada a objetos)... Es decir, como "aplicar", no del concepto de objetos. Developer9 también hablaba de POO.

MaxExtreme · #22 (**permalink**) 15/02/2006, 07:51

Cita:

Iniciado por cbwarz

MaxExtreme: lee bien por favor, acepta otras ideas, y no cambies los temas para volver a caer en lo mismo.

Developer9 se referia a que "tipicamente" un caso de uso generalmente tiene una interfaz de usuario, no que la Ingenieria de Software, Arquitectura de Software, etc, etc. es programar/dibujar una UI.

Afirmaciones de que alguien sabe mas que otro NO lleva a nada!

Y asi, y asi, etc, etc.

Me gustaria platicas mas orientadas a buscar algo de provecho ya que es de los pocos foros que frecuento y la verdad no cuento con mucho tiempo.

Sinceramente
Carlos

Siempre trato de aceptar otros puntos de vista. Lo que no acepto son razonamientos ilógicos. 1+1=2, y no hay vuelta de hoja.

Una aplicación "típicamente" no usa una GUI, sino que la GUI es parte de la aplicación. Son diferentes puntos de vista, pero Developer9 compartirá mi opinión: En ésas asignaturas se estudia que la GUI es un módulo de un proyecto más grande, no la parte esencial.

La afirmación que había hecho está clara, el objetivo es dar a conocer que ni Developer9 ni tú ni yo ni ningún otro sabe toda la POO, ni siquiera la mitad. Las afirmaciones que NO llevan a nada son las que dicen lo contrario "sabemos XXXX cosa".

PD: Aquí la gente contesta por voluntad propia, no porque a ti te falte tiempo ;) Como tú mismo me dices, deja el egocentrismo y acepta otros puntos de vista.

cbwarz · #23 (**permalink**) 15/02/2006, 08:44

MaxExtreme:
Exactamente a esto me refiero, un comentario lo vuelves una afirmacion de blanco o negro, ve los matices de las preguntas/respuestas.
Hazte la pregunta: ¿Que realmente estará preguntando o tratando de comunicar XXXX persona?
En vez de: Nadie sabe POO y esto lo afirmo yo (MaxExtreme)

I'm out :P

MaxExtreme · #24 (**permalink**) 15/02/2006, 10:26

Cita:

Iniciado por cbwarz

MaxExtreme:
Exactamente a esto me refiero, un comentario lo vuelves una afirmacion de blanco o negro, ve los matices de las preguntas/respuestas.
Hazte la pregunta: ¿Que realmente estará preguntando o tratando de comunicar XXXX persona?
En vez de: Nadie sabe POO y esto lo afirmo yo (MaxExtreme)

I'm out :P

Creo que "Nadie sabe POO" es una afirmación estadística que representa bien a este foro. Ahora, lo que no representa a nadie es "sabemos POO". En lo que sí te doy la razón, es que quizás no haya querido decirlo como "sabemos TODA la POO", pero había un post de TolaWare que descalificaba a la POO y la XP dado que no habíamos encontrado nada mejor, por ello digo que hay que lograr exprimir bien la POO, la XP y todo lo demás antes de descartarlos como obsoletos. (Lo mismo viene pasando con C++, se le acusa de ser obsoleto, cuando ni siquiera se sabe hasta dónde llegan sus capacidades de POO, programación genérica y mil cosas más... Si la POO está obsoleta, imagina cómo de obsoleto estarán todos los lenguajes...)

Developer9 · #25 (**permalink**) 20/02/2006, 08:55

Cita:

Iniciado por MaxExtreme

...Los patrones de diseño de los que hablas, fundamentalmente sacados de la universidad y libros, aún no los he usado. Acepto la documentación automática, acepto los diagramas UML para grandes equipos, etc. Pero no acepto "patrones" sin sentido. Aún no me he encontrado una aplicación en la que seguir ningún patrón.

n cualquier caso, el que se encarga de estas cosas es el líder del proyecto, no un programador...

Dos cositas... Primero, para un proyecto se necesita de ley un modelo, lineal, secuencial, espiral, prototipo... el que sea, el que mejor se adapte. Pero me parece que la diferencia es que tu no has trabajado en el desarrollo de este tipo de proyectos por lo que difieres en las opiniones, entonces de allí nacen todas las diferencias de concepto.

Segundo, no se tu, pero por lo menos yo no me quiero quedar de programador, en la vida hay que ser emprendedor, me parece que nadie quisiera quedarse de programador de por vida al mando de algún ingeniero lider del proyecto que va a ganar mucho mas que los programadores, aquella persona que no le va a interesar ni sentirse orgullosa de saber como hacer una ventanita a puro codigo sin utilizar alguna herramienta RAD sino mas bien elaborar un buen analisis, crear el mejor diseño, estimar bien el tiempo y negociar bien el proyecto ya que todo eso representa dinero. Cosa que nuestro horizonte no se limite solo con saber mucho de una herramienta de programación

MaxExtreme · #26 (**permalink**) 20/02/2006, 15:19

Vamos a ver, tú no te quieres quedar de programador, me parece muy bien por tu parte, pero NO hables por mi: Yo ni siquiera trabajo de programador.

En los proyectos de programación en los que participo NO se requieren normalmente "ventanitas" ni herramientas RAD. Pese a lo que creas, hay mucho trabajo que hacer detrás del escenario. Si no, infórmate del software libre y pregunta dónde conseguir uan herramienta RAD para hacer un una aplicación, modificar el kernel, el compilador, un engine 3D, etc. Ahí se aprende a programar, no haciendo ventanitas.

Yo no tengo la programación por trabajo, aunque tengo planeado usarla para la realización de proyectos más importantes. No me voy a quedar de programador con herramientas RAD, eso tenlo claro. Por ejemplo, me puedo ir a Irlanda, allí hace falta mucho C++. O trabajar a distancia en un proyecto de sofware libre (sí, pagan), o irme a alguna empresa de programación 3D... No pienso hacerlo y no sé siquiera si tengo el nivel o le tendré el día que tenga la oportunidad de presentarme, pero programador de aplicaciones de gestión: No, gracias.

Sobre los patrones de diseño... Mira, eso se usa en TU campo. Haz un driver primero y luego me hablas de patrones de diseño de bases de datos y esquemas UML... O haz un engine 3D y me hablas de los métodos de un TextBox, de ODBC... ¿Acaso sabes hacer un simple makefile? ¿Has programado algo alguna vez con el bloc de notas y la consola? Cada uno trabaja en su campo. Me parece genial que uses C# o lo que quieras para tu trabajo, es lo que debes hacer si quieres que la empresa produzca rápido, pero no extrapoles tu trabajo al de los demás. Nada más.

Como tú mismo muy bien dices: "No nos basemos en aprender una herramienta de programación". Yo aún no he aprendido ninguna. Si tú gastas tu tiempo en aprender las clases de Java o C#, allá ;) Yo opto por aprender un lenguaje como C++ que me da posibilidades de mil tipos, en una u otra plataforma, en un lugar u otro, con unas librerías o con otras. En cualquier caso, aunque C++ no se usase dentro de cinco años, lo que he aprendido me sigue valiendo, porque aprendo _programación_, no un IDE, una especificación de clases, etc.

En definitiva, estamos de acuerdo: Cada uno programa en su campo y no hay que cerrarse puertas.

Developer9 · #27 (**permalink**) 20/02/2006, 16:15

Eje!! me parece bien, aunque hablando de IDEs yo me quedo con el Visual Studio

C++ me pareció chevere para aprender a programar, porque allí no había codigo generado, uno tenía que escribir toditita la clase y la gente en realidad sufría.

Volviendo al tema, que piensas del tema original, pero pasando por alto todo lo que para cada cual significa saber programar

MaxExtreme · #28 (**permalink**) 20/02/2006, 17:22

Pues que si te sientes explotado, deberías buscar algo mejor. Pero te comprendo, las cosas están muy mal en el campo de la informática de gestión y es difícil encontrar buenos trabajos. Trata de ascender en tu empresa, demuestra tu valía (hazte valer)... No sé como anda la situación por allí, pero en España es penosa, o eso dicen, o es que la gente no vale.

Sobre IDEs: En Windows, Visual Studio 2005, claro. Pero no por ser RAD, sino por que es un gran IDE con su gran compilador/debugger (de C++ nativo hablo) que hacen muy fácil dentro de lo cabe, depurar programas y partes críticas. En otros sistemas, no suelo usar ninguno, y si lo necesito, en todo caso alguno que soporte la integración con Qt si es que el programa necesita GUI.

Developer9 · #29 (**permalink**) 20/02/2006, 19:14

No, no es que yo me sienta explotado, esa es la idea que una amiga tiene y por eso no se mete a trabajar en un proyecto real, que es donde "la papas queman". Acaso no habeis leido bien el tema. Oye por cierto, enviame tu mail para agregarte al messenger

MaxExtreme · #30 (**permalink**) 21/02/2006, 00:34

Entonces perdona, no entendí bien tu problema. Pero si tu compañera no se mete porque "las papas queman", tiene bastante razón. Trabajar de programador siempre ha sido duro y termina agotando/quemando a cualquiera, más tarde o más temprano.

Encargos como los de "estúdiate esta API (de 500 páginas) para dentro una semana y me implementas un generador de informes con ella dentro de dos", son los que de verdad queman. Espero que tengas un equipo y un jefe de proyectos mejor.

El e-mail ahí va, en un privado.