Sometimes the Hows are necessary, particularly when you want to make leaps within a field of study or of practice; other times, the Whos, Whats, Whens, and Wheres are sufficiently clear for practice on their own. Knowing the Hows can be interesting, and will never leave you worse-off, but they're not the goal or the means behind every journey.

In a vacuum, knowing How is always better, but outside the vacuum, knowing How thing X works is an opportunity cost -- knowing means learning, and learning takes time, energy, and perhaps money. Learning X is time away from Learning Y, or practicing Z. In the end, we only have so much time, so much energry, and so much money, and you need to choose what things you will invest those resources in.

If they'd told me Fourier Transforms were going to be responsible for real time streaming of mucky videos instead of saying they were optional and not on the exam I probably would have gone to more lectures!

Until you understand the theory behind what you are doing you will always be at the mercy of others. Instead of solving problems on your own you will create problems for others to solve and your productivity will drop heavily when you have to wait for a reply/someone to help each and every time.

Although you may be able to contribute to the general community a fun game once-in-a-while, you will never contribute to the research community that allows games to continue to be more advanced. Your games will most-often feel scraped together rather than clean, polished, and technically balanced.

You will never be the highest paid programmer in your company, never be CTO, etc.
On the plus side, companies love low-cost employees who can do the grunt work.



In contrast, knowing theory leaves you perfectly able to also make fun games for the general populace once-in-a-while, but also the ability to contribute to the progress of gamekind.
Even without a Bachelor’s you can show enough insight and problem-solving skills to reach top positions such as CTO and earn a much higher salary. You can lead others. You can use those same problem-solving skills to more efficiently solve your own problems without having to wait on others to get around to you.
You can invent new rendering techniques or help to solve problems that have yet to be solved (of which there are too many to count).


Fairly obvious when you look at it that way.

The reason for this is that, as soon as I believe I understand something, I need to refactor/optimize it. This would lead to me developing an engine instead of a game, and this would be counter-productive for what I'm trying to achieve.

So writing reusable optimized code that may or may not be classified as an engine is counter-productive for your goal, but writing unoptimized and non-reusable code that is in need of refactoring is…productive/conducive of your goal?


L. Spiro

Until you understand the theory behind what you are doing you will always be at the mercy of others. Instead of solving problems on your own you will create problems for others to solve and your productivity will drop heavily when you have to wait for a reply/someone to help each and every time.

Again, it's a question of how deep you need to go. You will never understand all the theory. You should understand the tools you're working with, but you probably don't need to understand how the compiler, os, cpu, transistors, semi-conductive materials and quantum physics at anything other than a superficial level. Really, it's turtles all the way down. :p

So writing reusable optimized code that may or may not be classified as an engine is counter-productive for your goal, but writing unoptimized and non-reusable code that is in need of refactoring is…productive/conducive of your goal?

If his goal is to get some software to market, then possibly yes.

As a general rule programmer time is more valuable than cpu time. Not everything needs to be reusable and super-optimised. If the existing code is Good Enough*, then really you're just wasting time (which is fine as long as the time is your own).

Of course, if the code in question is used a lot and time critical... refactor away.

* good enough = works as expected and isn't causing a performance issue.

Unity uses a graphical representation of it to help set your animations. My understanding of what a state machine even was, was nil when I started, but I still managed to use it correctly without understanding it.

People love to label something that is actually simple in nature and practice with a name and theory that make it sound so complicated. The term "state machine", or as Wikipedia says it, "Finite State Automata" makes it sounds so complex. Then, people love to define and and give names to the little things happening in the system, e.g. "It can change from one state to another when initiated by a triggering event or condition; this is called a transition."

Or this:

"Running is a means of terrestrial locomotion allowing humans and other animals to move rapidly on foot"

While this formalizes the field, and thus make it easier to discuss and write about, I personally feel that learning from theory to practice takes a much larger mental effort. I certainly belong to the learn-by-doing camp. My brain can't handle too much theory or instructions. I need to back them up with practical experiences.

I like knowing shit. Simple as that.

Off the top of my head, I more or less know how a refrigerator works, I more or less know how a microwave works, do I fix microwaves and refrigerators for a living? No. Does this knowledge helps me better utilize both things? Nope. Do I care? Nuh huh. I just like to know. It feels good to know, it gives a little bit of context to a little bit of a part of your life.

So keep calm and know stuff.

I like knowing shit. Simple as that.

Off the top of my head, I more or less know how a refrigerator works, I more or less know how a microwave works, do I fix microwaves and refrigerators for a living? No. Does this knowledge helps me better utilize both things? Nope. Do I care? Nuh huh. I just like to know. It feels good to know, it gives a little bit of context to a little bit of a part of your life.

So keep calm and know stuff.

Well, it might help you not blow up the microwave or refrigerator by misusing them...

Not everyone is the same, but I usually find the best way to understand a theory, is to try and employ it rather than to try and understand it before employing it.

Not everyone is the same, but I usually find the best way to understand a theory, is to try and employ it rather than to try and understand it before employing it.

This I think is true only for the most simple things, but the more complex you get, the more likely it is to end badly....

Playing with a television remote before understanding how to use the remote-- Okay

Microwaving things before knowing what happens when you microwave metal-- Potentially not okay.

Driving a car before knowing how to drive a car-- potentially less okay.

Well, it might help you not blow up the microwave or refrigerator by misusing them...

Yeah, if you try really hard you can come up with practical applications for everything. Point is, I don't actively seek practical applications of what I learn. Some things I just like to know.

I often think, when I hear people say "Why are we learning these things if we're never going to use them?", which happens in the context of school and university (prolly we all have heard/thought the same thing more than once), I simply don't like to look at it that way.