&gt; it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation &#x27;to make it faster&#x27;.<p>There is a circularity to this logic that you should address.<p>On the one hand, you shouldn&#x27;t write your own abstractions because someone else did a good-enough one already.<p>On the other hand, you shouldn&#x27;t try to write more appropriate abstractions because you should have working code first.<p>Well, which is it? If you intend to write appropriate abstractions(and that&#x27;s a goal of HH), you <i>have</i> to start off being a bit too crude and slow so that you have a working test case; then you can gradually improve that with better algorithms as you uncover the performance profile.<p>Jumping to &quot;use someone else&#x27;s code&quot; introduces a dependency and a guess about average-case behavior. That is okay if we&#x27;re making &quot;Premade Hero&quot;,  but it teaches nothing about algorithm design.<p>And w&#x2F;r to your own project, there are a lot of guesses about what will be useful or helpful - the specifications boil down to &quot;it would be fun to add more physics and scripting to Thrust&quot; which, as a game design goal, is quite impoverished. HH also lacks for design right now, but everything in it is built on direct experience and isn&#x27;t going to box in Casey later. It is motions he is going through to show to the crowd how it all works if you were going to do it yourself.