tr1coder

Just for anybody wondering, the corresponding shortcuts on Linux (and probably on Windows) are:

- home/end: start/end of line

- Ctrl + home/end: start/end of file

- Ctrl + Shift + home/end: corresponding selection

- Ctrl + left/right arrows: word movement

- Ctrl + Shift + left/right arrows: corresponding word selection

- Ctrl + a: select all

- Alt + 1/2/3/...: switch between tabs in Chrome and VSCode where I tested it, don't know if it is working in ALL apps, for example it does not work on alacritty+tmux (where I spend most of my time) for obvious reasons.

I don't know about the consistency, but some of these make more sense semantically, like Alt+1/2/3 - "alternate to a different tab".

That depends on your company I guess. If your entry salary is, or is close to 6 figures then yeah. But if you pay that only for skilled developers _specializing_ in front-end then it is not too much to ask that they are up-to-date with their field.

The inexcusable fact here is that he said that he didn't know how it works. A font-end developer not knowing grid is not worth 6 figures.

I partially agree. While I use git rebase on my branches, if somebody refuses to do it because of whatever reason and has on their branch a bunch of merge commits (usually `develop` into their branch) due to a stale PR, or a bunch of typo fixes or, worst of all, a bunch of emoji commits - so be it. BUT when they merge it back into develop/master I expect all that silliness to be squashed to one or more commits with clear commit messages.

It boils down to: what you are doing on your own branches is your thing, but when interacting with shared ones do so with some professionalism and decency.

Do you think that those outcomes would not be so detrimental if you did those tweaks more gradually, say over a year period you would get from 2 hours of focused productivity per day to, for example, 5 without those side-effects?

By the same logic an endurance runner that trains to run 1 km more every few training sessions would end up ...running indefinitely?

Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.

Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive hours? Or is burnout (or another complication) a more likely outcome? Has anyone tried this?

You can view it for free in incognito.

I find vimtutor to be the best source for beginners, at least it was for me.

Jonathan Blow has a good presentation containing some interesting facts about the companies that employ thousands of engineers and can't get simple things to work. It's the first part of https://www.youtube.com/watch?v=k56wra39lwA

EDIT: OMG it is you! xD

Aren't they already doing this? An Uber driver explained to me a situation where he drove a drug dealer (didn't know it at the time) who refused to pay him and ran away. After contacting Uber support they said to him that they reviewed the audio recording of their conversations in the car and established that the driver was telling the truth and paid him part of the fare.