I am currently learning Java in college. I have noticed a problem I have when I am starting to code to solve problem.
The problem is that I don't know exactly how to start. For instance, if I try to think about the question and a way of coding the solution then I always say to my self "what about this case.. and this case..." and don't know where to start.
So my question for people with experience in programming, is how do you start?
- Do you think about a solution for all the cases first, then start to write the code?
- Or maybe first you try to write the steps in your own language and then go and write the code?
- Or maybe you go ahead from the start, start typing some code and at the same time think about all the options and fixing and changing what you wrote?
I think when you first start programming, what's important is to just...rush at these small programs headfirst. As you learn, and begin to be able to avoid common mistakes you should start looking into Systems Analysis and Design, which is surely a college course you will soon have. This covers how to flowchart, diagram and plan you programs in a systematic way.
ReplyDeleteFirst you should understand your problem. Even do not think in programming terms, just understand. Then try to find divide your problem into separate simpler problems. Write them down. You should be able to describe briefly each sub-task using 5-10 words.
ReplyDeleteNow start thinking in terms of building blocks. What kind of modules, classes, methods you need. Draw these modules as rectangles with arrows that show their reationships. Now think about data structures and algorithms.
Now you are ready to do detailed design. Write down the names of classes, interfaces, methods (still without implementation). When you are done and everything look good start implementing your methods.
Good luck and happy coding.
I find it easiest to start with the data. In other words, what does my program need to be able to remember in order to do its job? During this stage, I group the data into preliminary classes.
ReplyDeleteThe next step is to list the functions I'll need. In other words, what does my program need to be able to do in order to do its job? I just put empty stubs, nothing implemented at this point. This usually jogs my memory about data I need to add, and often triggers a refactoring of the classes.
Then I pick a function and work on it. It's usually pretty clear what to work on first at this point, but basically it's based on what's easiest, what I'll be able to test the soonest, or what someone else is depending on me to complete first. If you get distracted with something else you need, make a stub or comment so you don't forget, and keep going.
I don't often work on user interfaces, but when I do, I find that's a convenient place to start. Once you have an idea of what the GUI should look like, it's usually fairly clear what code you will need.
Also, it helps a lot to write incrementally and test. For example, first create all your widgets, then arrange them how you want, then connect to event handlers, then implement event handlers, testing between each step. Think about what's the smallest thing you can implement with visible results.
When you are beginning to code, I think it is most important to jump into actual coding as soon as possible. So take whatever problem you want to solve and take the first use case and just implement it. Proceed to the next use case you find interesting and so on. You will learn much more by implementing those use cases than you would if you were just pondering about them. If you find yourself in a dead end, just can take a few steps back, you may even need to start over completely. That's fine, you may leave some code behind, but you will take the experience with you. In that case consider the code you discard and early prototype :-).
ReplyDeleteThe time for careful upfront planning will come later.
Basically what the guy above said. If you have a specification for your problem read through it atleast cursorily, then just open your preferred text editor and start writing code, whether it be pseudocode or actual code in your target language.
ReplyDeleteI find that actually attempting to code makes any obstacles more visible, as well as helping my mind start to churn on the problem at hand. In some cases it might be usefull to just do this until you have some understanding of the overall problem at hand, and then put down the code and do something else for a little while (letting your mind rest a little) and then come back and actually implement all the details.
As for where to start, I usually pick a special-case that seems simple, and build up from there, or pick a class that I might need and start from there, usually building upwards from a corner of the problem instead of top-down.
Planning? Neh, I prefer redoing later, with the experience I got from my first attempt as a great resource I wouldn't have had any other way.
I started with C but this may still apply.
ReplyDeleteAfter writing the pseudo code, start at main and keep going. Don't worry about cleanliness yet. Just go line by line converting your pseudo code to actual code. You will have to rewrite it once or fifty times anyways, so don't worry about it. As you are coding you will start noticing, hey I have written this same loop 3 times, let's put that into a method. Then, hmmm... I could think of this set of functions and data as its own object and then you put it into a class and so on...
This is the procedural abstraction way to do things, but it works.
This is messy, but you have to start somewhere. It takes experience with the code to get into a groove that will work for you. The learning curve for programming is exponential and not linear. Your improvement will not be steady, it will seem really slow for a while and then explode. Two years later, you will look back and be astonished at the body of knowledge and skills you have acquired.
Make a solution for the most simple case. Debug it. Correct it.
ReplyDeleteGo to the next case, a bit more complex one. Debug it. Correct it.
Could you get them together in one? Fine. Debug it. Correct it.
Return to 2
Yes, each step starts with words. Some people explain the task to a friend, some to a yellow toy duck. Then write them down. Then try to translate words into some scheme and then into code. It is good to do many models of your solution - text, block scheme, data model, some drawing, tables. Try , if you can translate your solution. Tht means, you understand it. Translation to the code is the hardest one, because it is really strict. It is a real check of your understanding.
You've to start somewhere.I would recommend you to start writing the code using pen/pencil in a paper. For these initial problems most often than not inhibition could be a big problem. Just start writing code whether you are able to solve it fully or not just start writing the code. I started writing codes using paper/pencil approach when i was learning them because it was easier for me to check the flow and correct the changes easily before i migrated them to a PC.
ReplyDeleteJust try to focus on the correctness first. I think once you start writing correct programs you can focus on the next part into abstraction, optimization and other stuff. If you could start writing optimized code straight away then its a definite plus even if you don't you don't need to worry about anything. It comes with plenty of experience.
Java is a good way to start. Good luck!