I’ve noticed that my productivity is directly correlated with the size of the feedback loop. Even little things like inline errors or a particular keybinding that you use can mean a big difference, I feel! Please feel free to share anything—I’d love to hear about your environments!
I used to love IDEs with immediate feedback on the code, and a modern VSCode setup can really shine in this regards. But these days I’m going for a minimalistic approach where I don’t want to see anything in my screen but the code. I use Neovim and while I use plugins for formatting code on save, my screen is absolutely code only. No linting hints, no function definition appearing when I hover thr mouse, nothing at all. It’s far less distracting and you also feel much less constrained, even if I unconsciously already write the code in a way that the linter doesn’t complain (too much) later. I haven’t noticed any drop in my productivity in the last year I’ve been doing this.
@Blackthorn Same, that’s why I recommend using the ‘zen’ mode JetBrains IDEs where necessary (ctrl|cmd+alt+z) -> https://www.jetbrains.com/help/idea/ide-viewing-modes.html
My whole work environment is tightly integrated ensuring I can use the same tools nearly everywhere. Things like keybindings (deleting a sentence, spellchecking a region, multiple cursors), macro’s (ad-hoc repetitive command sequences), the consistent mostly text-based visual look & feel. All of this lowers the cognitive load.
Comparing to an IDE, Emacs is more of a hyper-configurable integrated work environment. In my case, my code editor (Emacs), my knowledge base (org-roam), my tasks manager (ad-hoc on top of org-mode), my email client (mu4e), my tiling window manager (exwm), interaction with git (magit) and git issues and PRs (forge) as well as some other tools are controlled from Emacs. I call them ‘my’ because they’re sometimes slightly modified to scratch my own itches. I could integrate my calendar but Google’s webdav APIs seemed flaky at the time and FireFox only gets some consistent keybindings.
Just a few more years and Emacs will turn 50 years old. You never know what the future will bring but there’s a reasonable chance I will not have to throw away what I have learned so far.
Some examples of this integration:
- When I start developing on a project as full-stack I usually have a
M-x develop-projectname
command that boots up the application, arranges my windows with the right folders open, backend and frontends started, and a place for FireFox (not integrated, only uses some of the same keybindings) - It is not uncommon for me to receive about 100 emails in a day, some just informative and some requiring action. Processing these can lead to tasks or just information. In any case, treating them and doing actual work on the same day requires focus and a smooth path from throwing it away to drafting out tasks.
- An email can lead to an action to be taken on a server. When managing a server (local or remote), I’ll outline the tasks to execute. I can execute these tasks through org-mode’s code-blocks on the remote host and have a read-back of commands and output. In this use my knowledge base becomes similar to a Jupyter Notebook but integrated with all the rest. I can also reuse the results whilst working on it and I can mail the read-back to whomever would need to have the result in a readable email.
If you want to come to the dark side and like VIm’s keybindings, you may want to use Emacs’s evil-mode and keep them. It might just be the best of both worlds.
I love the idea of Emacs (especially of Doom!) I’ve played around with Doom a bit a few months ago and it was enjoyable to use, if a bit difficult to learn. Unfortunately, getting native compilation to work on Mac OS was making my install really brittle, but I might give it a second try after your comment.
- When I start developing on a project as full-stack I usually have a