The most important part of coding is not the coding, beginner contemplations
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
After just a couple months of doing this stuff with MQL5 working on indicators and an EA, time and time again I've seen that slowing down, contemplating, defining, planning, organizing is the most effective use of time to start off, and to regularly engage in, for any project. This is basically all the stuff involved in defining the program without actually coding it. It could be a general write-out or a technical one.
The most toxic behavior to engage in is attempting to sprint to a specific functionality milestone, because this entails focusing entirely on pure implementation and cutting down or eliminating what I mentioned above. Even if it does get the job done faster, it breeds confusion and stress, and it tends to open up the door to unintended bugs.
This is true even at the beginner phase. I find it difficult to predict what type of overarching structure/organization scheme I might be going for in the medium/long term, and often end up "reinventing myself" in those terms. And yet, this is no excuse not to practice deliberate planning and contemplation, because all we can do is the best of what our capabilities/knowledge already is. We do not know when or if that will revolutionize into a new level, and must work with the best of our current capability.
When the pre-coding stuff is done thoroughly and with patience, the actual coding portion tends to fall into place much more easily, and sometimes, even quickly, and will be higher in quality. But simply hopping onto the keyboard and coding right off the bat, I see as increasingly silly when it comes to starting off any project or phase.
--
I also suspect that when it comes to debugging, especially when it's not clear where the problem is, a great deal of patience must be exercised in the investigation, as well as contemplation about whether there are vulnerabilities to additional unintended behaviors. Sometimes it's as simple as a careless mistake somewhere that is otherwise not a big deal, but I've already identified one problem where the problem first happened because of a careless one line code mistake, but then it still happened, although less often, in other situations. Ultimately the problem was the overall approach to what I call trade phase state management. While I was playing around with using certain variables as state switches/etc. to track/regulate different phases of an individual trade setup/execution/position lifetime, I didn't fully plan it out and define/implement discrete phases that all trading activity is specifically gated through. As a result, there was an opening for unintended gaps in behavior regulation, because certain steps of the process were not being deliberately accounted for.
Essentially, instead of fully defining the phases and regulation, I just created ad hoc mechanisms which only loosely correlated with discrete phases of a trade lifetime, and were not explicitly tied to specific stages of the process. It would be easy for me to forget the details of a certain mechanism and have to investigate it again to remember exactly what its purpose/timing is.