Jump to content

  • Log In with Google      Sign In   
  • Create Account

Gain experience by learning(studying) or by doing?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 blowfish4   Members   -  Reputation: 137


Posted 13 March 2013 - 09:15 PM

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

#2 Ludus   Members   -  Reputation: 1017


Posted 14 March 2013 - 12:08 AM

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.

#3 larspensjo   Members   -  Reputation: 1561


Posted 14 March 2013 - 12:23 AM

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.

Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

#4 blueshogun96   Crossbones+   -  Reputation: 2131


Posted 14 March 2013 - 01:57 AM

My opinion, until you actually apply what you have studied, how do you really know if you've learned anything? smile.png


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!



Follow Shogun3D on the official website: http://shogun3d.net

Posted Image Posted Image Posted Image Posted Image

"Yo mama so fat, she can't be frustum culled." - yoshi_lol

"One objection to a “critique of C#” would be that you can’t talk about C# without talking about the whole “.Net experience”. However, one can approach the topic of Hitler without a complete discussion of Nationalist Socialism, so I feel justified." - Steve White.

#5 L. Spiro   Crossbones+   -  Reputation: 24026


Posted 14 March 2013 - 03:48 AM

Firstly, everyone learns differently. Your balance my vary, but these are probably the most common.

Gain experience by learning(studying) or by doing?

Experience by definition means “doing”. This is the difference between book smarts and street smarts.

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?

There are times for each. Generally you want to make well-structured code, but frankly where can I say the balance lies?
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?

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?

This is a false question.
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.

I'm wondering, what do YOU guys think are the best ways to learn how to code?

The way that works best for the person.
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

Edited by L. Spiro, 14 March 2013 - 03:53 AM.

#6 metsfan   Members   -  Reputation: 674


Posted 14 March 2013 - 01:08 PM

Why not both?  I read during my commute to and from work, and I code when I get home.  Best of both worlds.

#7 ScarletThread   Members   -  Reputation: 187


Posted 16 March 2013 - 12:44 AM

Do both...Learn a little then apply a lot... learn a little more then apply more... etc. etc. etc. works for me. 

#8 Chad Smith   Members   -  Reputation: 1343


Posted 16 March 2013 - 02:05 AM

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...

#9 french_hustler   Members   -  Reputation: 466


Posted 16 March 2013 - 04:28 PM

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....

Edited by french_hustler, 16 March 2013 - 04:30 PM.

#10 TheChubu   Crossbones+   -  Reputation: 8501


Posted 16 March 2013 - 06:35 PM

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.



My journals: dustArtemis ECS framework and Making a Terrain Generator

#11 derekxec   Members   -  Reputation: 101


Posted 18 March 2013 - 04:29 PM

the way i figure is do it with the knowledge you have and then after you get something working go back and look at your code...once you get something working youll feel like you have accomplished something 


then when you go back and look at your code you could learn new ways to optimize your code and/or do it the proper way...by doing stuff this way i have kept myself motivated enough to keep going with my projects and also have learned the correct and more optimized way of writing things...so now when i write to get something going i remember oh i found a better way to write this last time and then i start doing it the correct way the first time


either way i wish you the best of luck on everything you do :)

#12 Hawkblood   Members   -  Reputation: 858


Posted 18 March 2013 - 06:58 PM

I generally get bored with examples and small projects for learning, so I will start a large project like a game and implement concepts I learned from my previous projects. I set a goal (finishing the game) and work to that end. It keeps me going and I get satisfaction when I finish a section of it. Most of the time I run into some self-inflicted flaws that might make me quit or start over-- no big deal. I'd say I've started 10 games and only finished 2, but I'm not working for anyone but myself, so whenever I want to start/stop it's my decision. 


The point of jumping in with both feet is that you will prod yourself to finish something.


Doing small projects that have only one feature won't show you how it will look/interact with other features. This is also a good reason to come up with a large project and push till your fingers bleed.




The fastest code is the code never written.

#13 AngleWyrm   Members   -  Reputation: 554


Posted 18 March 2013 - 07:41 PM

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 the project is finished after the 5hr/30min time specified, then it doesn't really matter, and so 30minutes is cost effective.


But if the project is not finished after the hurried 30minute spaghetti code, it is much less likely to be finished later on, or ever.


Building a birdhouse doesn't require much skill. Building a skyscraper does.

--"I'm not at home right now, but" = lights on, but no ones home

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.