English Русский 中文 Deutsch 日本語 Português 한국어 Français Italiano Türkçe
Cómo ser un mejor programador (parte 03): 5 cosas que evitar para convertirse en un programador exitoso de MQL5

Cómo ser un mejor programador (parte 03): 5 cosas que evitar para convertirse en un programador exitoso de MQL5

MetaTrader 5Ejemplos | 16 septiembre 2021, 08:14
610 0
Omega J Msigwa
Omega J Msigwa

Tabla de contenidos

  1. Deje de luchar por el pasado.
  2. Renuncie a no creer en sí mismo.
  3. Deje de creer que todo el mundo debería pensar como usted.
  4. Comience a dar, en lugar de tomar.
  5. Deje de confiar solo en sí mismo.

Introducción

En lo tocante al mundo de la codificación, los novatos son los codificadores más incomprendidos. La impredecibilidad es uno de los comportamientos más manifiestos de los novatos. Nunca se sabe lo que puede ocurrírseles dentro de su código, incluso si dicen lo que quieren implementar. Entre todas las razones, la principal es que son inconsistentes en lo que están haciendo.

En el tercer artículo de esta serie, veremos los 5 hábitos que evitar para tener una carrera de codificación exitosa en MQL5.

Novato vs Profesional

01 — Deje de luchar por el pasado

"El secreto del cambio consiste en concentrar nuestra energía en construir lo nuevo, no en luchar con lo viejo."
— Sócrates

En sus primeros días de programación en MQL5 o incluso más tarde, es posible que usted creara un Asesor Experto (EA), una Biblioteca, un Indicador o un fragmento de código criticado por la mayoría de sus clientes.

O tal vez crease uno o dos EA cuyos errores causaron ejecuciones comerciales no deseadas, haciendo que no solo perdiera sus fondos, sino que también viera su reputación destruida ante sus clientes en Codebase, Freelance, o algo así. Debo reconocer que eso es malo, pero resulta peor recordar esos momentos y pensar en ellos.

En lugar de perder el tiempo recordando esos momentos dolorosos, momentos que pueden hacerle sentir un codificador miserable, ¿no sería mejor invertir ese mismo tiempo en trabajar para mejorar sus puntos débiles?

  • Si comete muchos errores, concéntrese en aprender cómo depurar esa esfera en particular, o los principios generales de depuración, si fuera necesario.
  • Lea la documentación sobre el tema y practique continuamente.
  • Si aún no está seguro, pregunte a los participantes del Foro qué podría estar mal.

Mirar temas antiguos del foro en los que formuló lo que ahora le parecen preguntas tontas, por el simple hecho de criticarse a sí mismo, es una pérdida de tiempo y recursos (electricidad, datos y almacenamiento informático).

Ideas como:

  1. "Debería haber hecho el código de esa manera"
  2. "Debería haber utilizado ese indicador en mi EA"
  3. "Mi indicador podría haber sido mucho mejor si solo hubiera…"

y otras ideas similares mermarán su autoestima, si las usa para catigarse por un pasado que ya no puede cambiar. Si hay cambios que desea implementar, comience a hacerlo ahora para sus sistemas futuros.


02 — Renuncie a no creer en sí mismo

Si desea escribir un sistema determinado, no espere el permiso o el visto bueno de quien usted considera un experto/profesional.

Con frecuencia, veo a los novatos publicando su código en el foro, que les da el resultado que quieren. Pero el verdadero motivo por el que preguntan es porque no creen en sí mismos: quieren que el código sea validado por expertos, y no están seguros de si lo que han encontrado por su cuenta podría ser la solución a los problemas con los que han estado luchando.

A mi juicio, en la codificación, es el código el que dice si tenemos razón o no. Si el código no tiene errores, usted lo comprenderá al cien por cien, y sabrá exactamente lo que quiere.

Si funciona de la forma que desea, entonces estará muy cerca de ser correcto. La mejor manera de saber que un código está fatal es comenzar a buscar la aprobación de cada programador (aquí incluimos a los novatos), ya que cada uno tiene su propia forma de escribir código que le ayuda a alcanzar el objetivo común que desea lograr. 

Es la forma humana de tener opiniones diferentes y no hay nada de malo en ello. Por consiguiente, no existe una manera específica de implementar algo, aunque algunas son mejores que otras. Por eso debemos saber qué estamos implementando y qué deseamos obtener como resultado. Cree el código, depúrelo y pruebe su efectividad.

Que uno crea en sí mismo no significa que no comparta sus puntos de vista en el Foro y haga todo por su cuenta: ¡no! No me malinterprete. Solo tiene que conocer la diferencia entre estar abierto a nuevas y mejores ideas o simplemente buscar la aprobación de programadores profesionales.


03: — Deje de creer que todo el mundo debería pensar como usted

No resulta nada saludable esperar que todos codifiquen igual que usted. Tampoco lo es rodearse de personas que piensan y codifican como usted. Si es usted un novato y se rodea de compañeros novatos, solo puedo decirle que eso es ridículo.

Como he explicado en el punto anterior, a la hora de abordar un determinado problema, los seres humanos tenemos diferentes conciencias, formas de comprensión y puntos de vista. Así que no se desanime cuando alguien le muestre un punto de vista y un código diferentes al suyo: lo importante es que todos tengan un objetivo común que quieren alcanzar.

Si ve el código de alguien en el foro, no se apresure a explicar su forma de codificar, en cambio, ofrézcale una solución en la línea del problema planteado porque, ¿acaso puede estar seguro de que la forma en que usted codifica resultará mejor para él? No es su trabajo convertir a todos los programadores en robots genéricos (no adaptativos) que se adhieran a los mismos patrones 24 horas al día, 7 días a la semana en todo el mundo.

Ser diferente es lo que permite la creatividad y hace que nuestra carrera de codificación resulte emocionante. 

"Considere lo difícil que es cambiarse a uno mismo y se dará cuenta de las pocas posibilidades que tiene de intentar cambiar a los demás".
—Jacob M. Braude.

No confundamos las formas de codificación de alguien particular con las soluciones a las respuestas en el foro. Las formas pueden incluir las bibliotecas que preferimos o los indicadores de nuestra elección, pero las soluciones son principalmente las que harán posible que las cosas funcionen a su manera.


04 — Comience a dar, en lugar de tomar.

"La gente que da, hace progresar al mundo; la gente que toma, avanza ella sola a la vez que retiene al mundo."
—Simon Sanek

Es hora de dejar de consumir código en CodeBase y productos gratuitos en el Mercado: empiece a producir cosas para ayudar a otros, tal como lo ayudaron a usted cuando comenzó a codificar. 

Comparta con el mundo lo que ha aprendido y lo que ya sabe, incluso si todavía lo está aprendiendo (los programadores profesionales son buenos aprendices, mientras que los novatos creen que ya lo saben todo).

Poniéndose en la ecuación, acelerará su aprendizaje. Esto no se aplica a la publicación de códigos y productos en el Mercado, resulta muy importante en el Foro, ya que todos los que están allí son programadores. Responda a las preguntas cuya respuesta conozca, y preste atención a las que no. No tiene idea de cuántos programadores profesionales del Foro participan activamente para ayudar a los novatos (se lo agradezco).


05 — Deje de confiar solo en sí mismo.

"El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos."

—Michael Jordan

Los novatos no están familiarizados con el término Open Source y no saben cómo usarlo; además, se mueren de miedo cuando alguien solicita ver su código extendido en el Foro para poder responder mejor a su pregunta. Es por eso que dije anteriormente en el artículo de introducción: son codificadores incomprendidos. Puedo relacionar esto con los novatos que piensan que el código que han codificado es muy especial (aunque tenga errores que ni siquiera pueden detectar y corregir ellos mismos): piensan que alguien podría robar su código especial y usarlo para crear el Santo Grial, sin saber que ofrecen pocas descripciones sobre un determinado problema, no hablemos ya del código y las cosas que ha intentado, lo cual hace que resulte difícil responder al tema... Así que terminan sin tener respuestas en el foro y, obviamente, sin entender nada.

Todas estas cosas negativas encuentran su origen en novatos que solo confían en sí mismos.

Siendo un desarrollador web, no puedo decirle cuántas veces he visto grandes proyectos, algunos de ellos de millones o miles de millones de dólares, que son de código abierto en Github

Creo que no hay mejor manera de acelerar el crecimiento y la popularidad de un proyecto que permitir a otros desarrolladores contribuir al mismo 

"Dos cabezas son mejores que una".
— Dicho africano

Conclusión

Para ser honesto, yo no soy tan magnífico, y mi carrera en programación de MQL5 o de desarrollo web no ha sido perfecta. Aún soy un aprendiz en el mundo de la codificación, y su aprendizaje no tiene fin, porque nunca deja de enseñarnos. Siempre me esfuerzo por mejorar en ello todos los días. El motivo por el que tengo las agallas de compartir esto con ustedes (de enseñar siendo un aprendiz) es porque quiero ayudar a la gente que comparte mi pasión por convertirse en un mejor programador.

¡Hagamos este viaje juntos!
Atentamente

Traducción del inglés realizada por MetaQuotes Ltd.
Artículo original: https://www.mql5.com/en/articles/9746

Gráficos en la biblioteca DoEasy (Parte 81): Integrando gráficos en los objetos de la biblioteca Gráficos en la biblioteca DoEasy (Parte 81): Integrando gráficos en los objetos de la biblioteca
Vamos a comenzar a integrar los objetos gráficos ya creados en el resto de objetos de la biblioteca creados previamente, lo que finalmente dotará a cada objeto de biblioteca de su propio objeto gráfico, permitiendo al usuario interactuar con el programa.
Gráficos en la biblioteca DoEasy (Parte 80): Clase de objeto "Fotograma de animación geométrica" Gráficos en la biblioteca DoEasy (Parte 80): Clase de objeto "Fotograma de animación geométrica"
En este artículo, optimizaremos el código de las clases de los artículos anteriores y crearemos una clase de objeto de fotograma de animación geométrica que nos permitará dibujar polígonos regulares con un número determinado de vértices.
Cómo ser un mejor programador (parte 04): Aprendiendo a desarrollar más rápido Cómo ser un mejor programador (parte 04): Aprendiendo a desarrollar más rápido
Todo desarrollador quiere poder escribir código más rápido, y eso no es algo tan difícil de conseguir: debemos saber que codificar de forma más rápida y eficaz no es un tipo de habilidad especial con la que nazcan solo unas pocas personas. Es una habilidad que todos los codificadores pueden aprender, independientemente de la experiencia acumulada con el teclado.
Cómo ser un mejor programador (parte 02): 5 cosas que evitar para convertirse en un programador exitoso de MQL5 Cómo ser un mejor programador (parte 02): 5 cosas que evitar para convertirse en un programador exitoso de MQL5
Este es un artículo de lectura obligada para cualquiera que desee mejorar su carrera como programador. Esta serie de artículos tiene como objetivo convertirlo a usted en el mejor programador posible, sin importar la experiencia que tenga. Las ideas analizadas funcionan tanto para principiantes como para profesionales de la programación en MQL5.