What's the best way to develop for the TX2?

I’m building a robot that will use computer vision, machine learning, and other technologies that the TX2 is great for. Pardon me if this is a basic question, but I can’t seem to find an answer: should I code directly on the TX2 or somehow deploy code from a remote source?
In other words, should I install an IDE directly on the Jetson and develop on it, or deploy code from, say, my laptop? What’s the best way to do this? I’d like to deploy/iterate my code as fast as possible. I’m developing in Java, Python, and C++. I’m coding everything, from basic structures to object recognition services and web servers. I’d like to use CUDA, Tensorflow, ROS, and other libraries.
The more specific the answer, the better. I’m sorry if my question isn’t clear. I’m relatively new to Jetson development.
Let me know if you have any questions, and thanks in advance!

You can do either. If your Jetson will sit inside a robot, and not be easily accessible for development, then developing on another machine and pushing to the Jetson might be simpler. If you use vim and make over an SSH connection, then it might not matter. If the Jetson is sitting on your desk, with a nice big monitor, developing on the Jetson would be okay. (Although, for big programs, the Jetson eMMC disk makes compiles slower than a good workstation computer.)

No matter what you do, you should also keep a remote code repository that you push your edit/changes to frequently (like, hourly.) That way, when your robot meets its inevitable fiery doom, you will still have all of your hard work available for checkout.
It might also be useful to make all configuration changes (package installs, etc) on the Jetson through some automated method – either a script that you can re-run, or using a configuration manager of some sort (like Puppet or Nix or whatever.)

If you develop by building on a workstation, and building a new file system, and flashing/pushing the entire filesystem each time you deploy, the configuration management will take care of itself, but that’s also the slowest and most cumbersome way to do it; I would recommend against that for smaller, more incremental, iterative development, even if it’s good to have scripts that can do this every once in a while so that you know your full build is reproducible.