+possible. There's **"Run Extension (Debug Build)"** launch configuration for this.
+
+In general, I use one of the following workflows for fixing bugs and
+implementing features.
+
+If the problem concerns only internal parts of rust-analyzer (ie, I don't need
+to touch `rust-analyzer` crate or typescript code), there is a unit-test for it.
+So, I use **Rust Analyzer: Run** action in VS Code to run this single test, and
+then just do printf-driven development/debugging. As a sanity check after I'm
+done, I use `cargo xtask install --server` and **Reload Window** action in VS
+Code to sanity check that the thing works as I expect.
+
+If the problem concerns only the VS Code extension, I use **Run Installed Extension**
+launch configuration from `launch.json`. Notably, this uses the usual
+`rust-analyzer` binary from `PATH`. For this it is important to have the following
+in `setting.json` file:
+```json
+{
+ "rust-analyzer.serverPath": "rust-analyzer"
+}
+```
+After I am done with the fix, I use `cargo
+xtask install --client-code` to try the new extension for real.
+
+If I need to fix something in the `rust-analyzer` crate, I feel sad because it's
+on the boundary between the two processes, and working there is slow. I usually
+just `cargo xtask install --server` and poke changes from my live environment.
+Note that this uses `--release`, which is usually faster overall, because
+loading stdlib into debug version of rust-analyzer takes a lot of time. To speed
+things up, sometimes I open a temporary hello-world project which has
+`"rust-analyzer.withSysroot": false` in `.code/settings.json`. This flag causes
+rust-analyzer to skip loading the sysroot, which greatly reduces the amount of
+things rust-analyzer needs to do, and makes printf's more useful. Note that you
+should only use `eprint!` family of macros for debugging: stdout is used for LSP
+communication, and `print!` would break it.
+
+If I need to fix something simultaneously in the server and in the client, I
+feel even more sad. I don't have a specific workflow for this case.
+
+Additionally, I use `cargo run --release -p rust-analyzer -- analysis-stats
+path/to/some/rust/crate` to run a batch analysis. This is primarily useful for
+performance optimizations, or for bug minimization.
+
+# Code Style & Review Process
+
+Our approach to "clean code" is two fold:
+
+* We generally don't block PRs on style changes.
+* At the same time, all code in rust-analyzer is constantly refactored.
+
+It is explicitly OK for reviewer to flag only some nits in the PR, and than send a follow up cleanup PR for things which are easier to explain by example, cc-ing the original author.
+Sending small cleanup PRs (like rename a single local variable) is encouraged.