Are my programming aspirations ruined?
So, to illustrate my point, imagine thinking the letters A-B-L-E first, then conclude it spells "able". There is no way the person can figure things the other way around. I'm so sick of this being the case with me.
I am starting to get into programming, so I don't know if I should give up. I don't feel like the logic of my brain is adapted to that of the "normal" world. Most problem-solving doesn't work the way I described.
How can I even think about breaking down a pet software project like a game into infinity? How am I able to use goal setting if I can't "break down" the details from the main concept.
I feel like I have broken logic and I want to know what can be done about it.
Keep notes.
Get a whiteboard.
Plan the architecture of it in your head like blocks feeding data into other blocks.
Break the problem/goal down ruthlessly while keeping the individual pieces/functions useful.
Drink coffee. Have code dreams. Learn continuously.
_________________
[Play Vawe here]-[Play Severance here]
There's nothing wrong with that. I learn a lot from tutorials and examples. I see how things are done, and learn how to do various things, and eventually, I can take that knowledge and make something bigger. If you're a beginning programmer, don't worry about being addicted to tutorials.
It sounds like what you are saying is you have an idea, let's say it's a game like flappy bird, and the problem you are experiencing is that you have the idea, but don't know how to break it down into components of the whole. (I.e. User taps screen bird flaps it's wings or to use your example you know the word 'able', but don't know how to get L A B E to spell it)
Is that right?
If so I have an exercise for you to try that should help with some practice and patience. This will help you rewire your brain to think more in line with a programmers.
First grab two (2) pens and some paper. Put the second pen in front of you. Now with the other describe on paper the first pen. Don't worry about being right or wrong just describe it like you are talking to someone who can't see or touch the pen. Be as detailed as you can about it. Ask yourself questions like, how would I describe the weight or ink color?
When you feel like you can't think of anything else to describe about it. Find another object like a stapler and do the exercise again. This time though try to describe it without saying what it is. So if it's a stapler, don't write, 'The stapler is...' instead write, 'The object is...'
When you finish that and feel you have described it the best you can give the paper to someone to read. Ask them to tell you what they think it is. Don't tell them what you are describing. Try this a few times with different objects.
The next step is to describe a process. Like making a cup of tea or getting dressed. Be detailed. Practice writing the process of several different things. Select more difficult processes each time. I.e. Boiling water could be your first, making tea your second, making gumbo your third, etc.
Now describe a process and each of its parts. So let's say you pick making a cup of tea, describe the act and the cup, water, stove, tea, etc. it should read something like, 'First grab a pot. The pot is a 4qt stainless steel 2mm thick pot with....'. Do that several times.
Once you feel comfortable doing that, then go back to your idea and describe it and it's processes from start to finish. Say it's a game, you don't start at the game over screen do you?
Should this be moved to the IT/Computers forum?
If you are saying that you can follow instructions to build a program, but don't know how to independently translate an idea or intended outcome into steps/code here are some ideas:
1. Use Nassi Shneiderman diagrams to plan your program. If you don't know what it is, look it up - there are lots of example pictures. A Nassi Shneiderman diagram breaks down any process into step, like the code required for a program. You need to pretend that you are manually doing the steps that your program will do (or writing instructions for a robot to do the same), and write each thing you do down in the diagram (including tiny checks or decisions, like 'Is there anything in Textbox1? If so.../If not...'). You should be able to find instructions for Nassi Shneiderman diagrams on the internet.
2. Use programs you made using a tutorial, and implement your own design changes to alter the outcome (this means deciding what you want the new outcome to be first, then implementing changes, though making changes and observing the result can be useful, too)
3. Start with really easy programs, even if they can't do anything very useful (e.g. generating and displaying a random number, finding the area of a rectangle given the dimensions etc.). Any practice will help, and projects that you can complete are better for your learning that ones that are ridiculously hard and which you cannot achieve.
4. Practise as much as you can. The human brain can always learn new skills through practice. There is still hope. It may sound cliché, but it will become easier with practice.
Good luck, and enjoy programming!
_________________
Diagnosed: Autism Spectrum Disorder Level 1 without accompanying language impairment
I find it easiest to connect with people through the medium of fandoms, and enjoy the feeling of solidarity.
Too often, people say things they don't mean, and mean things they don't say.