Is it better to have well structured code that takes 5 hours in time to make, than have spagetti code that takes 30 mins to pump out? Is it better to become well versed in a particular(or broad) area of study, and then go in and tackle a project, or just learn as you go? I'm wondering, what do YOU guys think are the best ways to learn how to code? btw, for me, it's learning Direct3D right now! :D
Gain experience by learning(studying) or by doing?
Both methods of gaining experience go hand in hand. An effective way to learn is to study a particular concept and then immediately apply it in a small practice project.
I think you learn best from mistakes. After doing something, experiencing the problems from the design, and then learning how it should be done. That is when you appreciate the better solution, and that is when it will stick. So the absolutely best way to learn, is doing much programming, but having an experienced person pointing out improvements. If you don't have access to an experienced person, use these forums. You will always get stuck into something.
After 30 years of programming, I started a big private game project (couple of thousand hours). It turns out I did a huge amount of things wrong, so I spent (and still spend) a lot of time refactoring it the right way (hopefully). I have learned more in two years than in the previous 10.
So the last advice is, don't be afraid to refactor your code. As a minimum, it will make you more proud of it. Even the process of refactoring is precious experience, that can be reused.
My opinion, until you actually apply what you have studied, how do you really know if you've learned anything?
As you study, continuously try to put that new found knowledge into practice somehow. If you are reading a book or tutorial, feel free to deviate a bit by tinkering with the code to see what changes can do what. You'll never know when you find an interesting way of doing things.
One thing I like to do is read the MSDN documentation on certain functions (assuming you're on Windows). This way, not only do you understand how the functions work and what different paremters you can use, but at the bottom of the page, Microsoft usually lists some closely related and similar functions. I've learned much by doing this. You can do this for Win32 APIs and DirectX. Win32 is alot of fun once you really get into it (especially multithreading; I enjoy the potential challenge and nightmare of multithreaded code).
My final bit of advice is the same advice I give everybody. Don't rush yourself or bite off more than you can chew. Study at your own pace, a pace that works best for you!
Shogun.
Experience by definition means “doing”. This is the difference between book smarts and street smarts.Gain experience by learning(studying) or by doing?
There are times for each. Generally you want to make well-structured code, but frankly where can I say the balance lies?Is it better to have well structured code that takes 5 hours in time to make, than have spagetti code that takes 30 mins to pump out?
If you are a very beginner on your own project there is no reason not to pump out quick-but-crap code.
Yet companies prefer structure.
To be quite frank the only way you can truly understand this dynamic balance is by doing both and learning their impacts on your code quality vs. getting results done. In fact you will need to learn the difference between them on your own personal level anyway in order to give accurate estimates to your future employer.
It is a crime to do either one of them in certain situations, so as long as you are a beginner and on your own, why not try them both so that you can get a feel for the dynamics behind them?
This is a false question.Is it better to become well versed in a particular(or broad) area of study, and then go in and tackle a project, or just learn as you go?
You never dive into the deep-end until you have a little background. In fact you simply can’t.
Firstly, you need to be versed in a subject to some degree before you dive.
The point at which you dive marks the balance, and that is up to your learning ability. Everyone is different.
The way that works best for the person.I'm wondering, what do YOU guys think are the best ways to learn how to code?
I guess you meant to ask how we each feel is our own best ways of learning.
For me that is a slight bit of reading on the subject followed by tons of hands-on and active doing.
L. Spiro
Why not both? I read during my commute to and from work, and I code when I get home. Best of both worlds.
Do both...Learn a little then apply a lot... learn a little more then apply more... etc. etc. etc. works for me.
I always say the following: Just Code
When you're learning just code. While we all learn different, I feel just coding is the way for most people in programming. Don't worry too much on if the solution is perfect when working on a project. Honest truth? your code will be ugly starting out. No matter what you do your code will still be ugly.
Just Code. Read and just code. Have a question on solving a problem? Take a step or two back. Write down in plain English how you would solve it in real life. Every step. Most of the time if you can figure out how you would solve a problem in plain English and you wrote down every part of the solution then you can find a way to translate it to code. While you might not know all the tools of the langauge to solve it, that's when researching comes in handy. Just type into Google that step and most of the time you'll get some ideas on features of the language you need to learn. Guess what? Next thing you know you just learned a new feature of the language and solved a problem at the same time!
Don't focus too much on code design right now. Just code. Get code reviews. Apply those code reviews, and guess what? Continue to code. Next thing you know you will be writing decently designed code by yourself just because it all of a sudden became instinct to you.
I feel it is dangerous spending too much time as a beginner worrying about code design. Why? I have experience with that. it seemed no matter what project I started or how simple it was I could program it with not much difficulty but would make the problem so much harder than it was by just worrying about the code design. It dramatically took away motivation away from me because I would say "This code sucks! horribly designed!" Start all over and next thing I know my motivation is destroyed, which in turn is a guaranteed way to kill a project.
So my advice? Just code, It'll come. It really will...
Cowboy programming is very effective for me. I find it extremely hard to "learn" and "progress" without some satisfaction from seeing results. I need that gratification or else I think "what's the point of all this". This is especially true if you program solo. Without help, coding takes a looooooooong time. Unfortunately, with spaghetti code, you will hit a fat brick wall from which you will have to refactor before being able to expand and add features to your project. I think a better question would be at which point do I start refactoring and create a proper architecture. There must be a balance of agility and planning in your development process. Agility is great for learning. It gives you great flexibility to go into things you'd rather learn about.
Of course, studying proper software engineering WILL help you. Learn about patterns, paradigms, and learn about different software architectures. Knowledge is power, but you got to apply these things in your projects. I love software development because you are the creator... the application's building blocks is supported by your architecture, and seeing your application done as you invisioned it is the ultimate satisfaction. And for large scale software, proper architecture and clean code is a must to the product's success.
At the end of the day, you manage your own time. Hence, you must figure out when it is necessary to create clean structures to your code as opposed to hacking things up together. Both have their own advantages....
It depends on the learning curve of the subject really.
I learn't what I know of Java as I went through it. Suddenly I needed linked lists and I read Oracle's Docs about the Collections framework. Needed to interface with native stuff for a library, went to learn about Buffers and how they work.
Thats usually the "simple" stuff. Things that require at most a paragraph to explain. LinkedList is circular? Can I use bitwise operators with any integer type? You can find those easily and code what you want to do with them in 10min.
Other things, like design patterns, general object oriented programming concepts or complex libraries, APIs and such, take time to learn and its best if you read about them before trying to code with them.
I spent quite a while reading about OpenGL before trying to code up something myself with Java, the linear algebra required to do some stuff took me months to learn (though I didn't knew back then I'd use it for OGL :D), most of the object oriented concepts (classes, access identifiers, information hiding, etc) that I'm using in Java right now I read from C++ based material rather than coding my way through it.
There are many many "layers" of understanding. Some of them you can learn just by practicing (trial-and-error) and some of them you need to read quite a bit before even trying to jump in with the code.