In reply to Navyscourge.

This is fantastic advice.

Well done with this great analogy for coding; such a great explanation.
If I may, can I extend it a little, since you mention that coding is like writing a story. A good story will benefit with a little planning. Just a few lines will do that cover the plot. These will help you to keep focussed on what you are writing. You can discuss your plot with someone to see if it makes sense, even before you have written a word of the story. When you have finished the story, you would check the spelling, grammar and so on, even checking that Henry the dog has not become Henry the cat.
In coding, the simplest design establishes what your code should do. You can identify the ‘tricky’ bits and tackle those first, so if you can’t make the code do what you want, and have to do it differently, you don’t have a lot of code to rewrite. You should probably get into the habit of finishing the code for the design before you start adding new features too.
The checking bit is important; if your code breaks the users are not going to use that code for very long. Pretend you are now your enemy, and that you need to prove this code is rubbish! Try to break it, use it in ways it was not intended and give wrong answers to any questions asked. This can be fun if you do this yourself, or get a friend to do it too if you can accept it when they do break it.
The design and testing of code is not often mentioned when encouraging people to code. If you do design, code and test you might find that your code is better than if you don’t.

I forgot to mention the URL, my site is https://codermoji.com

Great article. I strongly believe we need many different points of view in the tech world, and especially more creatives and designers.

The problem with the plant approach is if, you get into a shouting match; when the plant doesn’t agree with your path of logic :-)

Also if you apply the KISS principle (Keep It Simple and Stupid) it tend to keep the Murphy’s law at bay.

I particularly love this bit: “Treat learning to code like learning a language”. I studied languages at university and have always been interested in understanding how a language works and the relevant grammatical rules and make sure I fully understand this before I need to write an essay in that language.

My approach to learning Python was therefore exactly the same, I started with the basics and worked slowly through it. When someone gave me an answer to a solution, I took time to 高雅人妻被迫沦为玩物 why the answer worked.

I am therefore always surprised when people say they’re new to coding and are attempting to do incredibly complicated things without learning the basics first as it’s an approach that just doesn’t make sense to me (don’t worry, I still try to help – I’d hate to deter people from coding!).

I love the feeling of fulfilment I get from learning a new language and when you get to point where the code “feels” right.

In a previous job, we had a small bear that could sit on top of your monitor, (I would probably use a Tux these days!) if stuck, you explained the problem to the bear and almost always it got solved!

I never thought of a plant. I guess because I never had one in my office. I knew it would die in about a week. Plants do not do well around me. I am glad it worked/works!

Re (3), a few jobs ago I adopted the rule that I wasn’t allowed to go to my line manager for help with a technical question until I’d already tried asking the plant I kept on my windowsill. My boss was great at finding solutions and explaining things and was always happy to chat, but I started to feel silly about the number of times I’d ask him something and realise as I reached the end of the question that the answer was obvious. The plant approach doesn’t work quite so well in shared offices, unfortunately.