Well, I am no coder, as my friend jokingly told me "You couldn't even write a Hello World script without copy/paste..." But as little meaning as he wanted to give to those words, he actually does almost speak the truth. While I could do it now, it is only because I've practiced using BGT's alert function so much that I have the code memorized. I could not yet write functions of my own or construct new working code from that knowledge. But, I think the advice in post 2 is very helpful. I'm not totally sure what your boss would think of your code, or even if he would examine your code, so I can't really respond to that. But don't worry about that now... make code you're confident in first. Read my below post carefully and try to implement all the advice you get into your coding.
While I don't program, I do other things which can, to a certain degree, be approached with a programmer's mind set. An example of this is MML, which is a simple music notation language used a lot in making music for old video game sound chips. I'm known to do interesting things with it, such as trying to emulate difficult to play passages, which are about 500 times more difficult to type and render correctly. While a lot of my mml code does look a little gibberish to me sometimes, I can piece it together. If the thing refuses to compile into something that can be played, or if it plays and sounds wrong, I can normally step through the mml script and find the problem, not by trial and error but by looking at what I've typed and seeing the error. MML is ridiculously simple by comparison though, as it's more meant for musical/math geeks like myself. So it's just a simple matter of knowing what each command does and being able to add their effects up in your head. The commands don't' have much in the way of context either.
A programming language is much different. In MML I don't have to step back and piece together how I've constructed an array or a function, or how I've set an object's properties, and then figure out how that leads to the result I'm getting. There is backtracking in MML yes, but only to recall references I may have made and forgotten, not to read methods which I've written or used and later cannot decipher. That kind of stuff makes my head hurt. I've tried to grasp BGT. I really tried. But because my brain doesn't work the way BGT does, I end up tying it in hopelessly tangled knots. No doubt I could untangle them given time, patience, and a mentor who could see me through. That same friend who joked about my inability to write Hello World also told me that if I did grasp BGT or a similar language, he would not be surprised if I did great things with it which nobody else had thought of yet. But I'm not there yet, and I suspect I won't be for a while.
Even though I am not a coder, I can tell you this much. No matter the system or method for inputting the instructions, whether it's mml, bgt, Python, or even sitting in front of an editor that doesn't have scripting of any kind, the process should be similar. You should at least have an idea of what you're trying to do and how you're going to do it before you start working. That doesn't mean you must have the whole program code scripted in your head. It does mean though that you will have to know how to chunk your program into smaller parts which you can then plan out before you start. Sometimes planning can be done in your head, but writing extremely detailed instructions that leave nothing to chance is the best way to really plan your script before you start writing it. This helps you not only split your project into individual pieces, but also more importantly, it helps you figure out how you will connect the pieces, at least hypothetically. If you are frequently becoming overwhelmed with the demands you put on yourself, or are constantly thinking "I'll never be able to work through this!" this is a sign that you are pushing yourself too hard too soon. It is never a good idea to push yourself too hard too soon. This only leads to discouragement. Acknowledge what you can and cannot do confidently, and push yourself as much as you feel comfortable. Only you will know what you can and cannot manage.
Remember, a programming language is a language. You can't always take it in chunks or sentences, without first piecing the sentences together. It's the same with writing novels. Not only do authors understand the sentences they write in their novels, but they choose the words they use based on impact, on context, and on language structure. Nothing they write is written just because... or at least it shouldn't be. Coding should be the same way. You write commands with an understanding of what they all do. You have a reason for every word or special symbol you write. Perhaps the simplicity of MML commands is why I grasp it so well. Those commands do one thing which for the most part is immediately obvious. If there is a problem, I'll be sure to notice it by just listening to the output. But a programming language puts meanings to those words, meanings that only make sense if you understand the linguistic structure. They are not immediately obvious unless you have context within the language which defines them. Furthermore programs have layers of functions, objects, arrays, variables and so forth, which require a lot of backtracking. Kind of like looking through written paragraphs and stepping through he's, she's, I's, you's, them's, they's, and stuff like that to find the path that leads to real meaning and context. , Thus, trial and error is not really a good strategy to determine problems, unless you have narrowed your possible problems down to a few suspects. Even then, it is not bad practice to figure out why option A works and option B doesn't.
Finally. I would not expect many people to be able to even start conceptualizing how they would transcribe a complicated song. I would not expect many people to try to juggle half a dozen numbers at a time as he tries to pull off something which the system wasn't quite designed to do. I'd expect myself to do both of the above, but that's obviously because I know what I can push myself to do. But I would not expect myself, in the near future anyway, to create some sort of financial calculator. My point here is, anyone who tells you "A 10-year-old could learn to program by following this tutorial" is just promoting the tutorial. While there may be many 10-year-olds who could indeed learn those things, there will be many 40-year-olds who would set the book on fire in frustration because they simply cannot grasp it. I know that now after reading the BGT manual, where it was advertised that anyone could master the simple script. Now, I'm not trying to knock the BGT manual, I think it is well written, but I still had difficulty in following it beyond a point. That happens for the same reason that some people are naturally good at, say, basketball, while some are not. The ones who aren't so good may improve with long arduous practice, but whether that is worth it is really a personal choice. To be really honest, if I had a choice between someone who mastered a programming language in 1 month with average or below average daily practice time, as opposed to someone who spent 5 years practicing 10 hours every day without fail, I'd gravitate toward the former, as they obviously have a knack for it which is unmatched by sheer willpower and determination alone. They may not necessarily be better, but they still got more done in less time, which so far is little more than a mystifying mystery. The person who can just grasp and hold onto such things quickly will, more often than not, provide more potential to be expanded and refined, to nurture a growing talent. The person who takes forever to grasp something may just run in place, or drift forward very slowly. While that might not be bothersome depending on the person, it still puts them at a disadvantage.
I hope this helps you to better assess how you tackle coding. Good luck!
Make more of less, that way you won't make less of more!
If you like what you're reading, please give a thumbs-up.
