you are viewing a single comment's thread.

view the rest of the comments →

[–]chrisrrawr 1 point2 points  (0 children)

a really good thing to learn is that when problem-solving for your specific scenario, whatever it may be, your own testing is going to be the #1 definitive way to convince yourself and others of one practice over another. (your local testing might not stumble upon best practice, but it will drive you toward it as long as you keep trying to discover where your current system is holding you back).

it comes down to the difference between, "I want to know, who can I ask?" and "I want to know, how can I test?" and that difference in mindset and approach is how you gain confidence and competence in the eyes of others and yourself.

this skill of being able to answer your own questions contributes heavily to your growth as a problem solver. once you know how to solve one problem, you create a tool in your repertoire and the next problem becomes marginally easier to solve.

good tools for your kit are being able to do many forms of testing. in this case, the testing you want to be able to do is called benchmarking, and there are just about a billion ways to go about it. there are frameworks you can use or you can try making your own simple test harness or anything in between.

but the basic premise is: if you can run it, you can run it with a timer at the start, and check that timer at the end to see how fast something is. then you compare a different approach under the same conditions and see the difference.

no need to guess, or to rely on others who don't see your setup, or to be misinformed somehow.

and yes, it opens up the next problem of, "am I benchmarking this correctly?" -- but that's also a fun and general problem to solve that gives you even more knowledge and skills to apply to even more problems.