¿Como encontrar las soluciones?

Cambia de carrera ;-)

Ya en serio, pues creo que documentarte sobre el tema es importante.
Por decir un ejemplo: Quieres meter seguridad a una aplicación web.
Entonces, pues checas en internet algo como seguridad aplicacion web java( así colocas los términos, medio feo, pero en fin..)
De ahí creo que es un buen punto de partida, viendo tutoriales, y viendo si en el lenguaje de programación que usas (documentación), hay algo construido para tal fin. O de menos alguna convención/estándar que te dé un indicio; de igual forma algún documento de mejores prácticas para desarrollo de alguna solución para lo que buscas.

O sea la única forma es LEYENDO.

Es lo primero que me llega a la mente, pensando en un tema en específico,igual alguien por ahí te indica más cosas, o complementa mi respuesta.

A mi me ha funcionado. No tener miedo de preguntar aunque sea lo más trivial o parezca estúpido. Leer mucho, repasar temas, etc. Y lo más importante, tener iniciativa.

Decidí, junto con otros compañeros, participar en un concurso de programación. Hasta allí todo bien.
Me dije a mi mismo; seguro que son cosas simples, que arreglos/matrices por aquí y cálculos por allá, nada del otro mundo

La iniciativa la tienes.

Créeme en la universidad mis compañeros no tenían nada de iniciativa solo se conformaban con el certificado de estudios. Y ustedes hasta participan en concursos de programación.

Suerte 0_o

Gracias por responder chicos, lo que mencionan me parece genial, incluso una que otra cosa ya me la estaba planteando (leer y preguntar).
Ahora recuerdo cuando estaba con mi primer Linux, no sabia nada, no quedo otra que leer hasta que se me cerraban los ojos XD. Fui completamente autodidacta y he aprendido muchas cosas del mundo GNU/Linux. ~Ah!, cuando compile Gentoo~. Aunque me faltan muchas mas >.<, ya me desvié del tema...

Pero no termino de entender como es que se resuelven los problemas. Sera que siempre se usa el: "yo creo que es así...", "a mi se me ocurre esto...".
Y ese tipo de ideas dentro del desarrollo del software. Ósea, ¿Existe una técnica que te diga como enfrentarte a un problema y encontrar su solución?

Sé que están los métodos de desarrollo de software. Por ejemplo el análisis, el diseño, el desarrollo, etc... Pero no te dicen como pensar, como encontrar las respuestas. ¿Le estaré dando muchas vueltas a esto?

Bueno aqui un libro sobre como resolver problemas ,esta en openlibra,sin duda en un futuro puedes buscar libros sobre algoritmos o cualquier tema.

Si el concurso del que hablan es el ACM-ICPC,el nivel es muy alto,los problemas estan a un nivel de dificultad superior a el de la mayoria de los desarrolladores,segun se lo que mas te recomiendan es ser bueno en matematicas tipo matematicas discretas,los temas son muy diversos,aunque los problemas son mucho mas dificiles de lo que se encuentra en la universidad y general es mejor empezar por categorias o tomando de base los cursos de algoritmos y estructuras de datos para saber que problemas puedes resolver o no , aqui la pagina de un Méxicano que a escrito algo sobre esto .

Sobre las ultimas preguntas,creo que solo la practica las resolvera.

Híjole, BT, si es ese. Ya me espantaste. No me había dado cuenta de que el muro que pensaba brincar riéndome es en realidad una montaña... ha salido el tiro por la culata. Jeje, no importa, vamos a echarle ganas.

Gracias por tu comentario, por el libro y por la web. Has sonado como un maestro jedi =)
Acepto más consejos :3
Saludos.

Hace tiempo tenía algunos problemas realmente serios. Muchas veces pensé si me había equivocado de carrera, comprendí que un título no te hace profesional ni un sabelotodo.

Tenía miedo de preguntar sobre programación en los foros que visitaba. Sin embargo, la necesidad es más fuerte y me atreví hacerlo.

El problema que tienes es algo común, en las escuelas no te enseñan a resolver problemas de ningún tipo. "Afuera es todo distinto" ... tienes que estudiar bastante para lograr algo.

Una forma de hallar las soluciones es: ayudando a otros

Pues como la ves que yo nunca (hasta ahora) me he sentido fuera de la carrera, o será que no lo he querido aceptar jaja.
La verdad es que el titulo me importa pero solo para levantar la moral familiar. A veces es complicado ser la única persona de toda una familia que estudia el nivel superior. La familia espera que lo logres, no es como si me atormentaran diciéndome que yo soy el orgullo familiar y esas cosas y tampoco es como si me obligaran a hacerlo, si he seguido estudiando es porque así lo he querido yo y mis padres me han apoyado económicamente.

Básicamente a mi solo me importa aprender y conocer cosas nuevas que me gusten/interesen. Por eso es que me preocupa tanto entender las cosas, hacerlo mas rápido y mejor. Eso es algo muy importante para mí. Es posible que este mal pero, por ahora es lo único que quiero hacer.

No sé si se note, pero cada que puedo me aviento los retos de ayudar a los demás, en algunas cosas doy unas metidas de pata que uff, para que se las cuento (basta ver mi perfil y seguir mis comentarios).
Pero eso no me hace retroceder. Si no lo intento nunca saldré de burro jaja.

Gracias por tus comentarios @Sr. Negativo, tu siempre apoyando a este novato ñ_ñ
Saludos.

Ash.. como siempre me avente un mega choro:

TL;DR; Preguntar y preguntar.

Uy no , ser maestro de preescolar no es nada fácil.

A mí también me pasa

Acá he de hacer una confesión ( similar a la que ecamacho hizo hace tiempo ) y cuya importancia recién voy aprendiendo: a mi me pasa exactamente lo mismo, muchas veces no sé como resolver los problemas.

Y no digo que me pasaba ( que ciertamente me pasaba cuando estudiaba la carrera ) o que me pasó al iniciar a trabajar o que me pasa cada vez que llego con un cliente nuevo, no, también me pasa siempre que voy a hacer un programa nuevo, siempre que voy a moverle una línea de código a un proyecto que está en producción, siempre que voy a hacer incluso mis ejercicios chiquitos de programación, digo: "Uy y ahora?"

A veces es realmente incómodo, a veces pienso "Tengo tantos años haciendo esto, de esto vivo y siento que no sé algunas cosas que parecen tan básicas" o peor aún se siente terrible cuando sabes de entrada que lo que tienes que resolver es muy complejo y desconocido ( por ejemplo una tecnología que solo conozcan una decena de personas en el mundo y de la cual google es completamente ignorante y donde tú tienes que resolver el problema) y la pregunta surge "Y ahora, como rayos voy a resolver esto?"

Ok, esto es lo que yo hago:

- Entro en pánico por 10 segundos
- Trago saliva
- Cierro los ojos y me imagino corriendo en círculos.

Tomar una buena actitud para resolver el problema

Si después de esto el problema sigue ahí acepto, la realidad y con verdadero entusiasmo empiezo a atacar el problema y suceden varias cosas.

Si hay alguien que sepa acerca de la materia en cuestión le pido que me de algo de contexto, es increíble como puedes ver un problema cuando alguien te platica a grandes rasgos de que se trata todo, luego empiezas a ver todo con otros ojos y muchas veces el problema no es tan grave. Empiezas a meterle mano y ya con más conocimiento de causa puedes hacer preguntas más específicas. Eventualmente la persona ya no sabe que responderte porque ahora eres tú el que tiene más detalle de la situación.

Usar el método científico

Y viene la siguiente fase, hay que aislar el problema, identificar exactamente lo que está sucediendo y evitar hacer suposiciones mágicas ( "Esqueeee nomás le di enter re-fuerte y ya funcionó, si le das quedito no jala" ) en pocas palabras aplicar el método científico

Es decir, hacer una hipótesis ( "funciona con \r\n pero no con \n" ) comprobar la hipótesis! ( ahh no funciona igual con los dos retornos de carro ) y si no se soluciona el problema intentar algo nuevo.

A veces esto es más que suficiente. Si las cosas no están dando resultado intentar algo diferente, je je je aquí recuerdo algo que le oí decir a ezamudio hace casi 12 años, cuando una persona estaba haciendo las mismas pruebas una y otra y otra y otra vez ¿Que?! ¿lo quieres agarrar desprevenido o que? Si no está funcionando lo que estas intentando, haz otra cosa ( a veces esas otras cosas se te ocurren caminando por un vaso de agua )

En este proceso de hacer las hipótesis y probarlas se encuentran también muchas cosas buenas, por ejemplo, yo hago programas chiquitos donde trato de reproducir el error, con esos programas entiendo donde puede estar la causa y muchas veces esos mismos programas aislados me sirven para preguntar en un foro de discusión. Incluso muchas veces mientras escribo la pregunta, me doy cuenta de la solución ( me pasa creo como el 30% de las veces ) Al hacer un esfuerzo por explicarlo ( porque la gente no lee la mente - bueno no todos - ) estructuras tu pensamiento de tal forma que luego dices: ehhh ya nada, ya lo resolví :)

Buscar una alternativa

Si nada de lo anterior funciona es hora de pensar en alternativas, de hecho hay veces que pasa el tiempo y digo ahh... y si leo todo el archivo de una vez? Y dadaaaa muchas veces el workaround da resultado. A veces hay que hacer más trabajo a veces no se puede. A veces el workaround es más complejo y al preguntarlo con alguien más ( el cliente, el PL, el gerente, o DBA etc. ) resulta que no es tan grave y mejor será no hacer nada. A veces la solución está en un punto intermedio con el workaround y lo que estabas intentando.

Y a nivel micro

Todo esto es a nivel "macro" problemas relativamente grandes ( ejemplo, no se copia nada de información a la base de datos, o cada día se pierden 20 peticiones de forma misteriosa ) Para problemas más chicos es básicamente lo mismo, pero acá los recursos son más fáciles de encontrar.

Como son problemas pequeños, las preguntas son más específicas, google sabe mucho, la documentación del lenguaje/herramienta sabe mucho, tus compañeros saben mucho, tú mismo haciendo micro experimentos das con la respuesta. Pero sobre todo y creo yo lo más importante es tener una forma más o menos ordenada de resolver los problemas

- Primero entender el problema ( no ladrarle al árbol equivocado )
- Luego pensar como solucionarlo manualmente ( si es, no sé un ordenamiento, pensar como lo harías con cartas de baraja a mano )
- Hace un pseudo código ( que pseudo compile )
- E intentar con el lenguaje

Todo esto conforme se tiene más experiencia se va automatizando.

Aprender la lección

Y finalmente aprender de todo lo que haces: Si encontraste la solución explicarla, o documentarla de alguna forma, o si ya funcionó de repente no decir "fue pingüe" sino tratar de reproducir la solución. Cuando alguien pregunte lo mismo que tú responderle!, por ejemplo en los foros de discusión.

En el proceso de la búsqueda aparecen varios artículos o cosas que aunque no resolvían tu duda resultaron interesantes hay que leerlos cuando haya tiempo. Muchas veces esas cosas traen consigo otras y otras y poco a poco vas aprendiendo más y más. A veces no es claro cuando se va a poder usar algo, pero siempre ayuda tener contexto de las cosas que se pueden hacer.

Buscar aprender lo que no sabes

Identificar las áreas de oportunidad ( como les dicen ahora a las cosas que no sabes :P ) y esto la verdad cuesta trabajo, porque por algo no las sabemos, a mi me cuesta mucho por ejemplo cosas de matemática avanzada o algoritmos, quizá porque generalmente llego a una solución antes usando fuerza bruta ( con un desempeño razonable ) o porque encuentro alguna alternativa eficiente, pero al reconocer que es lo que no sabemos podemos aprenderlo.

y..... ya, mucho choro por ahora

Les dejo un link que me llegó via @MachinesAreUs sobre este mismo tema: Exponer tu ignorancia ( EN )

P.D. También es importante fortalecer áreas que no son directamente de desarrollo de software, como por ejemplo aprender a leer, aprender a escribir ( increíble no? ), dedicarle un rato a conocer tu editor, aprender inglés, aprender a sonreirle a la vida ( seeehhh se oye muy Cornejo, pero si el problema esta muy difícil, y lo tienes que resolver, sentirte miserable no ayuda en nada, mejor es pensar que si, se puede, si se puede #okMeCalmo )

Saludos

Pues ya somos varios los que andamos en el mismo sendero del guerrero.
Expongo mi caso, yo sueño/trabajo/aprendo/estudio/sigo trabajando/sigo aprendiendo, por la meta que es para mí ser "arquitecto de software", pero pues sé que me falta un buen, que si ya te aprendiste un patrón de diseño, tienes que aprenderte otros 20, que si ya los aprendiste, ahora apréndete otros varios específicos de JEE (por mencionar algo), que si aprende a hacer benchmarks para pruebas de comparación entre bibliotecas (algo como lo que hizo @ezamudio con lo de logback y log4j ), que si aprende varios frameworks que satisfagan la misma necesidad, aprender las ventajas/desventajas de cada uno, cuándo carajos usarlo, buenas prácticas de programación, ora que aprende otro lenguaje ( de otro paradigma ( en mi caso Scala) ) para que aprendas a "torcer" tu cerebro, de modo que puedas resolver un problema de 2 ó 3 formas distintas, luego, que si aprende otras cosas (como inglés si te falla, para leer documentación e incluso lidiar con clientes extranjeros); sin mencionar, que si optimización del application server, y otras más que ya ni menciono para no seguirme traumando.

Muchas de las cosas que menciono, las vas aprendiendo sobre el camino, otras, las más "finas" pues sí que hay que invertir tiempo para aprender cómo se aplica, y cuando, pero sí es un trabajito aprenderse todo, y por cada proyecto, ir analizando qué aplicar para satisfacer alguna necesidad del negocio específica.

Yo quisiera saber, qué necesita saber uno, para llamarse arquitecto de software ( creo que por ahí andaba un tema referente, pero pues no comentaron mucho, si mal no recuerdo).

Entonces, pues, la única premisa, es no quedarse inmóvil, seguir leyendo, preguntando, informándose, y tener bases bien cimentadas de conceptos para saber de qué nos hablan, sin importar el lenguaje de programación, patrón de diseño, o buenas prácticas aplicadas a X lenguaje.

Ya me desahogué en tu tema José Manuel, suerte en tu encomienda, y por ningún momento titubees, no te rindas, algún día serás un buen profesor de preescolar ... digo, un excelente ingeñero en sistemas; Suerte!

Graaciiiaas!!(Yo con lagrimas en los ojos...XD).
Creo que ya veo la luz al final del túnel chicos, ya más o menos me están llegando las respuestas a mis interrogantes. Sus consejos me son/serán útiles y nos los desperdiciare.

@OscarRyz
Jajaja, tu siempre con ese sentido del humor tan característico :O sabes, en la oración donde dices:

...- Luego pensar como solucionarlo manualmente (si es, no sé un ordenamiento, pensar como lo harías con cartas de baraja a mano)...

La parte de "pensar como" es precisamente la que quiero obtener/mejorar/desarrollar. Sé que van a decir: "hay mano, mas bruto no se puede". El libro que me proporciono @BT es lo mas cercano que he obtenido para lo cometido. De nuevo, sus consejos son algo que no he encontrado en los libros y es que supongo que esas cosas no salen allí.

En algunas cosas no les entiendo pero supongo que es como dices Oscar, Buscar y aprender lo que no sabes. Y para nada es mucho, al contrario, le hubieras seguido >.<
Y totalmente de acuerdo con que hay que fortalecer las áreas que no están directamente relacionadas con el desarrollo de software.

@neko069
Camarada, aquí he expuesto todo mi pesar, que no cunda el pánico jajaja, ¿Que te puedo decir? Yo inicie el tema haciendo las preguntas jeje. Pero claro que no me rajo, puede que me aviente mi rato terminando pero no desistiré, chance y termine como maestro del tecnológico XD.

Gracias de nuevo chicos, haber de a como nos toca en el concurso, a la mejor y no salgo ni del concurso interno pero hay que medir la capacidad actual.
Saludos!