Perdon si es offtopic pero como va en relacion al post y estoy estudiando tambien, no se si se considera tutorial hell, por ejemplo cuando voi a hacer algun proyectillo o ejercicio ahora si no recuerdo algo siempre miro primero la documentación y dejo chatgpt solo si me atacasco en alguna cuestion muy breve o simplemente para que me de alguna pista de por donde deberia buscar x cosa. Pero tengo la sensación de no estar haciendolo bien, quiero decir me siento un poco inutil y sé que el tema de buscar en la documentacion oficial o google es parte del trabajo, que no se trata de memorizar las cosas si no que se van quedando, pero me da esa sensacion como cuando uno sigue un tutorial (cosa de la que he procurado mantenerme alejado).
#150 Comparto lo que dices al 100%. El tutorial hell es muy peligroso.
Eso sí, hay algo que me pasa desde siempre y es que me encanta saber el por qué de las cosas.
Te pongo el ejemplo con el campo donde me considero "experto" que es el entrenamiento con cargas. Yo podría hacer X rutina porque alguien me dijera al 100% que está bien y no querer entenderla, y simplemente hacerla. En mi caso, voy a calcular que volumen semanal cada grupo muscular recibe, qué progresión de cargas usa, qué ejercicios utiliza, qué rangos de repeticiones emplea, etc. Y a partir de ahí, voy a valorar si esa rutina es buena o no.
Obviamente no me hace falta al 100% ni lo voy a hacer porque no dispongo de tanto tiempo pero al menos para mí, puede ser importante en algún momento entender un lenguaje como C. Siempre me preguntaba porque en cursos de tanto prestigio como el CS50 de Harvard usan C como primer lenguaje (aunque no le dedican muchísimo tiempo en el grueso del curso) y al final he comprendido a grosso modo por qué lo hacen.
Quizá estoy equivocado, claro, es una simple impresión que tengo.
Un abrazo crack y gracias por comentar en el diario!
#152 Yo también creo que soy bastante curioso por naturaleza y a veces hasta me obsesiono por querer entender todo antes de ponerlo en práctica e incluso me ha llegado a quitar el sueño en no pocas ocasiones.
He hablado con muchos profesionales de la informática, y sobre todo con desarrolladores, también en este foro, que me dicen que esa sensación de pensar que no sabes lo suficiente, que todavía no estás al nivel necesario para hacer algo, te va a acompañar el resto de tu vida, y no es una cuestión de tener baja autoestima, por lo que no hay que obsesionarse demasiado con querer saberlo todo.
Un hombre con 30 años de experiencia, que ha trabajado en proyectos muy chulos y con gente muy capaz, me comentaba que a menudo pensaba que el resto de compañeros del equipo sabían más que él, que no entendía cómo él había llegado a ese proyecto o a trabajar para esa empresa, o que x persona era un genio y que admiraba sus conocimientos técnicos y el trato que tenía con la gente. Lo curioso es que al comentar esto con terceras personas, descubrió que esa persona pensaba de él exactamente lo mismo.
Al final la cantidad de información, tecnologías y herramientas es abrumadora y nos puede hacer sentir como unos farsantes, pero que no seas capaz de utilizar o comprender una herramienta en un momento dado, no te convierte en peor ingeniero a la hora de resolver un problema.
Al final, la mayoría de la gente con la que he hablado me ha dicho lo mismo. Los conocimientos técnicos son importantes, no hay duda, y la experiencia hará que cada vez dispongas de más opciones para solucionar un problema y que seas capaz de discernir cuál es la más idónea; pero lo que realmente te hará mejor profesional y te dará la posibilidad de dar un salto o pasar al siguiente nivel, será tu capacidad de trabajar en equipo, comunicarte con tus compañeros, ayudar al que necesita ayuda y pedir ayuda cuando la necesites, no tus capacidades técnicas. Así que por eso no te has de preocupar demasiado.
Trata de alcanza un nivel que te permita acceder a un primer empleo, es el consejo que todos me dan, y una vez consigas esto, si tienes predisposición a ayudar, a aprender y a escuchar, la experiencia en el trabajo te dará los medios para desarrollarte como profesional y prosperar. No tienes que saberlo todo. Sólo tienes que ser capaz de resolver el problema, y te podrá ayudar Google, el ChatGPT, la documentación oficial, y tus compañeros. Al día siguiente serás tú el que esté enseñando a otro.
El consejo que te doy, no sé si será el mejor o no, porque estoy en una situación muy similar a la tuya, es que empieces a solucionar problemas ya, no te das cuenta de lo importante que es esto hasta que lo haces. No te centres tanto en la teoría y en el por qué de las cosas, creo que vamos tarde como para empezar siendo más papistas que el Papa. Aprende a solucionar problemas, a hacer código que funcione, a engordar tu portfolio, y después es cuestión de venderte, sobre todo mostrando buena predisposición por ayudar y aprender. Nadie va a pedirle más que eso a un entry-level o junior.
El otro consejo es que preguntes todo lo que no entiendas y no seas capaz de entender en poco tiempo por ti mismo. Queremos ser autosuficientes y no molestar a nadie con nuestras chorradas, incluso en este foro, que no cuesta nada y en el que lanzas preguntas al aire, a veces nos cuesta preguntar porque pensamos que es una chorrada o que tendríamos que entenderlo por nosotros mismos. Nos ponemos a leer documentación, a preguntarle a la IA, a buscar ejemplos, y aquello parece que no termina de hacer click después de horas. En las prácticas he aprendido eso gracias también a que mis compañeros han sido muy buena gente y han tenido siempre predisposición a ayudarme. Que pidas ayuda a una persona y que ésta te la preste de buen grado, es la mayor bendición que hay en este mundo. Hubo una cosa con la que me tiré un día sufriendo para entender y no sabía hacer, y una persona se puso conmigo 10 minutos y vi el cielo abierto.
Mucho ánimo en tu camino, seguro que te irá bien.
29 días después
Por hacer un poco de autocrítica este año actualizo el diario, ya que no tengo mucho que aportar.
Como os dije, estoy haciendo DAW, llevo apenas dos meses así que no hay mucho que contar.
Mi rendimiento está siendo realmente malo. Mi progresión es prácticamente nula y eso se basa un poco en lo que ya me han dicho varias personas en el hilo y fuera de él, soy capaz de focalizar mucho en investigar, buscar información de calidad, etc. pero la ingeniería se basa en ejecución y práctica.
Caí en el tutorial hell (es adictivo de cojones) y sé muchos conceptos, pero en la práctica, soy literalmente un 0.
Primer paso para mejorar y tener algo de qué hablar: acabar el MOOC. Si os parece curioso algún ejercicio que salga interesante lo puedo poner, aunque para la gran mayoría de vosotros serán ridiculeces. A partir de ahora mi único foco va a estar ahí hasta que lo termine. Prohibido ver tutoriales de Youtube/cursos.
Y esto al final funciona como cualquier otra habilidad que ya he aprendido en el pasado. Ejemplo: aprender a hacer press banca; puedes ver dos o tres vídeos de cómo realizar la técnica básica, después la técnica se perfecciona mediante ejecución y repetición. Al grabarte, puedes ver los errores y pulirlos.
Esto, es exactamente igual, solo que yo simplemente estoy haciendo las cosas mal.
No cometáis el mismo error.
Un saludo y feliz Navidad.
Por actualizaros un poco.
Estos días por no empezar la casa por el tejado he empezado el MOOC de nuevo. El inicio es bastante ameno ya que se practican cosas muy básicas como recoger datos del usuario introducidos por consola, declaración de variables (camelCase en el caso de Java) y concatenación de strings + variables en las que hay que saber aplicar los espacios correctos.
Por haceros alguna pregunta de algo que he visto. Os parecen buenas prácticas cerrar el scanner cuando ya no se vaya a usar más o no consume los recursos suficientes como para molestarse en hacerlo?
Os sigo actualizando cuando ya entre en la materia importante.
PD: Como MV permite hacerlo, me estoy habituando a escribir los mensajes en lenguaje Markdown ya que he visto que se utiliza para documentar proyectos en GitHub.
#156 Con respecto a lo del Markdown.
Si usas algún software para tomar apuntes o para almacenar información como Obsidian o Notion, ahí puedes practicar el Markdown de una mejor manera. Yo te aconsejo que todo a lo que le hagas research lo vayas apuntando. Por ejemplo, estás programando y te salta un error, investigas googleando y das con una solución, te ha llevado 20 minutos dar con esa solución que te ha servido para deshacerte del error y avanzar, todo ese proceso lo apuntas en Obsidian o en el software que quieras con Markdown para tenerlo a mano incluso puedes añadir capturas, de tal manera que esa información ya la tienes localizada y la próxima vez que te des de bruces con ese error tendrás la información a tu disposición para solucionarla, a la tercera vez que hagas esto ya te acordarás y ni tendrás que mirar los apuntes.
Y así con cualquier cosa, yo por ejemplo también añado links a papers de interés, a tweets, videos etc.
10 días después
Curiosidad que me ha sucedido en un ejercicio del MOOC.
He llegado a los ejercicios que usan estos operadores lógicos:
The expression of a conditional statement may consist of multiple parts, in which the logical operators and &&, or ||, and not ! are used.
Como este ejercicio:
A year is a leap year if it is divisible by 4. However, if the year is divisible by 100, then it is a leap year only when it is also divisible by 400. Write a program that reads a year from the user, and checks whether or not it is a leap year.
Está dentro de ese apartado y el ejercicio anterior tenía una indicación de resolver el ejercicio usando un solo if (agrupando todas las condiciones dentro del mismo código). Pues me he empezado a complicar la vida. Digamos que casi llego a esta solución:
Pero claro, no he llegado a la solución al 100% por tratar de anidarlo todo en una línea cuando creo que es más fácil la solución a la que se llega haciendo uso de else if en líneas diferentes.
¿Qué utilidad tienen el mundo real los operadores &&, ||, y ! ?
Sin tener ni idea de cómo estructurar código aún, creo que le resta mucha legibilidad al código meter varias condiciones dentro de la misma línea.
#158 De verdad piensas que es más legible tener 3450 ifs uno dentro de otro? Piensa en un caso en el que tengas 10 condiciones, que vas a meter, un if por cada condición?
Al final es álgebra, se lee perfectamente. No diste operadores lógicos en el instituto? AND, OR, XOR, NOR...etc? Juraría que mi hermano en la ESO los tocó, yo que soy un pollavieja no lo di, pero creo que él sí.
Lo más parecido que dí a eso en mi vida fue la Lógica Formal en la asignatura de filosofía de bachillerato. No en matemáticas, física, química, biología o tecnología.
#158RSN:¿Qué utilidad tienen el mundo real los operadores &&, ||, y ! ?
No vas a parar de usarlos. Pero cuando una linea se empieza a complicar, puedes extraer partes en variables:
boolean isLeapYear = (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0);
if (isLeapYear) {
System.out.println(year + " is a leap year.");
} else {
System.out.println(year + " is not a leap year.");
}
Si isLeapYear te sigue pareciendo complejo, lo puedes dividir en más variables.
No los di, no. La cosa no es que los entienda mejor o peor, si no que para estructurar mis ideas a día de hoy es más fácil ver las condiciones por separado. Lo de la legibilidad del código, sin duda, patinada mía y ya está. Canto el mea culpa.
Gracias por tu mensaje!
#162 es normal, como todo al principio es más sencillo si lo partes en trozos pequeños, al tener varios if visualmente estás partiendo las condiciones y por eso te parece más sencillo pero realmente es lo mismo, cuando trabajes de esto te vas a inflar a condiciones así que llegará un momento que te pones a leerlas y ni te enteras, igual que cuando conduces que no vas pensando en cambiar de marcha.
