Optimization, Code Improvements, Code improvising... Questions, Questions, Questions...
Members - Reputation: 582
Posted 08 September 2011 - 11:19 AM
I was thinking of a imaginary book on Amazon.com that teaches a learner how to optimize a program, in a way that it's easy to do these things. And probably thinking that it's a intermediate level programming book. Or another imaginary book that guides a person who has finished an introductory book of a specific programming language, towards a more appropriately difficult level of programming.
You know, a book that's in the middle between Beginner and Advanced. If we have read this imaginary book, do we learn optimizations and/or code improving skills? Or, suggested by some people, we should continue to program/code, until we get tons of Eureka! moments while doing it, and learn from those experiences?
I know there are no shortcuts, knowingly that it takes about some X number of years to get it right, even I have read an article on being a good programmer in 6 really hard steps and felt it's a responsibility as a programmer to achieve it (well, sort of...).
I'm in a mood where I wanted to blurt out questions, and just wanted to kill time reading people's opinion on topics I'm interested in, such as this. I'm back to having a programmer's block, in a good way, as I've completed a hurdle (however large or small it seems...) in Java. Oh yeah, loved this new block.
And there's a rumor I've heard while Googling. If you're programming while doing a commentary, you'll sort of learn how to think in accelerated mode, meaning that ideas/thoughts/words keeps popping into your brain, and forcefully causes you to think faster while trying not to pause or go silent. Is that "code improvising"? Would it be in the same league as "optimization"?
Crossbones+ - Reputation: 6999
Posted 08 September 2011 - 11:36 AM
tl;dr Its ok to read and learn, but just make sure you are aware of the dangers and pitfalls and are vigilant in protecting yourself from the traps.
Members - Reputation: 104
Posted 08 September 2011 - 11:56 AM
I code this way if I already know the results I'm looking for and how to get them, without laying out an outline or writing 5000 lines of comments that explain my logic and reasoning.
If I'm coding this way, I will do either one of two things:
*Realize the instant I write something that it can be written better, in less lines, or more efficiently, then re-write it.
*Finish the snippet of code at hand, weather it's a class, a set of functions or an entire module, then scour through it and see where changes are necessary, then make them.
I don't focus on optimizing the crap out of something when I first write it, but I try to keep things as simple as possible, which brings me to this guideline I was taught when I started programming 7 months ago: The simplest solution, though not always the most straightforward, is usually the best. I'd rather see results NOW and worry about making those results less taxing later on. As long as things are abstracted to an appropriate level which allows you to do this, IMO this is the best way to do things.
Members - Reputation: 108
Posted 08 September 2011 - 12:52 PM
As others have mentioned, just worry about making an actual playable game first. And as I'm sure someone would / will point out; the compilers these days can optimize vastly better than most people can (even if they can write assembly themself). Make your layout, program your game, once it's playable run it through a profiler which will show you where the "bottlenecks" are. This way you can focus on and optimize areas that actually need it. Thus saving time, you actually stay motivated longer as you see results faster, and you avoid the foresaid pitfall above, "optimizing this, optimize that, optimize everything!"
Crossbones+ - Reputation: 4700
Posted 08 September 2011 - 01:09 PM
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts
Crossbones+ - Reputation: 3754
Posted 08 September 2011 - 02:08 PM
Do we learn all of these things when we are coding and nothing but coding?
No, not just coding. Practice is practice no matter what you do. Set a goal a little beyond your skill, work to achieve that goal, reflect on what you did (what was good, what was bad, how it could be better).
If we have read this imaginary book, do we learn optimizations and/or code improving skills?
You can learn techniques, but you cannot be good at them without practice. Optimization especially needs you to have some example to work off of. Some metric that you're measuring, optimizing; repeating that process as needed.
Or, suggested by some people, we should continue to program/code, until we get tons of Eureka! moments while doing it, and learn from those experiences?
You won't get tons of Eureka moments. You'll get the one for pointers, you'll get one around monads, you'll probably get one for recursion... maybe a few more where something is inscrutable simply clicks and stuff makes more sense. The majority of your improvement will come from failure. You write bad code, and as you try to expand/maintain/debug that code, you understand why it is bad. You get the gut feel for what things are bad, what things are good, and why. Books cannot teach you that. A design pattern book can tell you things that other programmers have found to be good, but not always why, and certainly not all the different scenarios you could use them in and why they're particularly good or bad in those scenarios.
GDNet+ - Reputation: 10270
Posted 08 September 2011 - 02:35 PM
Typically there are a few kinds of books relevent to programming -- beginner/introductory language/technology books, advanced language/technology books, references, algorithm books, patterns and practices books, reference books and hardware books.
If you've moved beyond the beginner's books (and you should be totally honest about whether you have), I would recommend to move on to algorithm, patterns and practices, and hardware books as a next step, and get lots of practical experience by writing *real* programs. As you complete these real programs, reflect on what went well or did not, and either carry that experience to the next program, or re-tackle the old one and try to do it better (though don't get stuck in that pattern too long, a new problem is always more challenging than a known quantity).
Members - Reputation: 462
Posted 08 September 2011 - 02:52 PM
Don't set the goal too far, you will fail and lose motivation. Failing a project you have spent a lot of time will take the fun out of programming. Sometimes it's better to drop failed project than try to repair it. Maybe even do the project again from scratch, but better.
To learn to optimize, you should first write a working program. Then run profiler for it, measure where most time is spent, and only then start the research why is it slow and can it be improved.
Crossbones+ - Reputation: 5978
Posted 08 September 2011 - 03:01 PM
Now I am going to contradict all of that and mention a book that taught me so friggin much about optimization it was scary...
Michael Abrashes Zen of Graphic Programming.
This book is old, very old, but damned if it didn't rewire the way I looked at code. Abrash just had this nack for explaining how to optimize code. I haven't read it in years, but it was about the only book that directly taught me optimization techniques.
I'm not recommending you pick it up... the subject matter just ins't relevant for the most part these days ( that book did the equivalent of writing Open GL or Direct X! ) as we don't work at the low of a level anymore, but it was a very profound read from an amazingly talented guy.
That said, even with that book, nothing taught me optimization like experience. Also, coming to the realization that 90% of code doesn't actually have to be optimized and benefits greatly from being readable... that one took a while to sink in.
Senior Staff - Reputation: 21866
Posted 08 September 2011 - 06:31 PM
EDIT: Just realised you actually mentioned this article in the original post -- my apologies, but I'll leave the link here for the benefit of anyone else reading the topic.
Don't let the article scare you off however; the steps listed generally take a long time, and they're not easy to achieve, but it's not all rough-going with no reward along the way -- as you learn you'll experience a lot of rewarding moments where you manage to solve problems, where things click and you understand things you didn't before, and you'll probably make at least one or two pieces of software that you're really proud of and/or which help you out a lot in your day-to-day life.
If you feel you're getting beyond beginner books I'll second the recommendation of finding some more advanced books covering algorithms and/or data structures, or you could consider looking for a book which takes a more in-depth look at a particular subject (AI, graphics programming, whatever) which interests you. Don't be afraid to go back to your beginner books if you find you've bitten off more than you can chew, and don't be afraid to use reference materials. The important thing is to continue writing code and not to get too hung up on trying to do everything correctly the first time around -- just work towards making things work, and you'll find that the mistakes you make along the way will be your most valuable learning experience; you'll also get a feel for what works well, what doesn't work so well, and when/where it's worth putting in the effort to optimise.
You should also put in the time to learn how to use your tools properly.
Get really familiar with your debugger and the various functionality it provides; if you're new to using the debugger get some relatively simple (but bigger than "Hello World" -- you'll need enough to play with!) that you're familiar with and mess it up on purpose -- cause compile errors and learn how to efficiently look up the error messages -- cause logical errors and learn how to step through your code and examine the contents of your variables and track down where things are going wrong.
Find a profiler and learn how to use it -- until you're working with real code this probably won't click with you, but it's worth trying to start early so you can get familiar with the tools and get into the habit of checking which parts of the program could really benefit from optimisation.
Learn how to use some sort of source control -- get some different advice (there should be plenty of posts and articles on the topic) on different ways to use source control and try them out with your small projects so that you can learn different work-flows and figure out what works for you.
Hope some of the helps!
- Jason Astle-Adams.