Hi, I wrote the majority of that part of the project (canvas stuff) & that section of the article – the simple answer is that I have a lot of experience working with the canvas API directly, but little to no experience using any of the popular JS game engines out there (I played around with Phaser years ago, but not very much). I don't think it would've saved me any time to be honest.

That's totally fair, I get the sentiment. Great job nonetheless!

FWIW, there _is_ a proper styleguide now, it just hasn't been retroactively applied to older js. https://github.com/reddit/styleguide/tree/master/javascript

Nice, looks like they went with a slightly modified version of airbnb's js styleguide. That's what we use at work.

I use bittorrent sync to keep sublime text synced across my machines, works amazingly well.

I can definitely see myself using this. I generally have one terminal tab open just for git anyways, so this would fold into my workflow nicely.

i've seen this problem several times, and I still think its a case of the statistics not representing the reality. For example, if you consider the case where you have originally chosen the correct door, there are two possibilities to consider (host reveals door A vs door B) in which switching/staying results in the same outcome, but considering results in 8 possibilities and puts the odds for both actions at 1/2

Read the article; your theory has been disproven by hundreds of independent experiments. Better yet, go write your own simulation and find for yourself that you are incorrect.

One of the core 'assumptions' is that the host would never reveal the door with the goat behind it. Therefore, in your scenario where you choose the winning door in the first place, there is only one option for the host: reveal the door without the goat / car / whatever.

Javascript, hands down. You'll have a harder time going from CS -> JS than you will from JS -> CS, and knowing only CoffeeScript really narrows what you can do

nice game. got up to 833 before I realized i'd been playing it way too long :)

I think the 10,000 hour rules is a good rule of thumb, but it of course also depends on the kind of programming you are doing during that time. But assuming you are doing a variety of things and actively trying to expand your skill set, and assuming you code an average of 2000 hours a year, it should take about 5 years to become proficient.

Some general tips for improving workflow: - within a specific file/project, try to recognize places where you are retyping the same (or very similar) code blocks repeatedly. try to pull those out into a function to avoid redundant code and typing

- try to recognize code structures that you are typing repeatedly across projects, and see if you can make snippets that reduce the number of keystrokes and time needed

- if you are performing the same action multiple times, try making a macro

- get familiar with the keyboard shortcuts for your editor of choice. Try to do as much without the mouse as possible

- for whatever editor you use, do a bit of research to figure out what good plugins there are that might help you. for example, if you write a lot of HTML, you could benefit from the emmet plugin (zen coding).

- try out a lot of apps. If you think "there should be an easier way to do this", then there probably is.

- avoid shortcuts that sacrifice quality for convenience. doing something quick and dirty will often just create more work for you later.

- don't ever make mistakes. or, if thats not possible, have a plan for debugging.