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.

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

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

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.