Some people at a previous job used vscode, passed their day clicking at stuff with their mouse, navigating directories via a native file explorer, using GUIs to commit their changes, using windows with no knowledge related to virtual desktop management, automating nothing etc... That wasn't no problem at all : they did their job and at the end of the day they wrote code. But then, with the right tools you could have done what they did in half the time, minimizing all the unnecessary micro-movements with some keybindings and some editor plugins or some really good text editor. Now, if paired with this mechanical mastery you have a good ability to pack related problems/functionalities to implement and are efficient at solving them/implementing them; then you can add some multiplier to the mechanical speed explained in the previous paragraph. That's some weird way to think about this, but let's say the ideal instance of the project requires X lines of code; if you work faster, then you reach a higher level of expertise on the project codebase and by this excess of expertise you gain speed relatively to others which in turn makes you more expert and so on. Except, working "fullspeed" is more tiring than working "normally" and you usually don't want to have a tornado in your team that write 50+ -major changes- commits a day and that cannot cooperate with others because they cannot follow up and are "too slow" to even review those changes. You decide to fire "slow" workers, but then the tornado must work 9+ hours a day to keep up with your expectations and finally burn-out leaving a work that every other member of the team fails to understand, due to too much litterature to read written by some sort of alien. So I'm fine with programming 2 to 4 hours a day, since, as an alien-tornado, I prefer my code to be read, reviewed, and understood by my peers.