- 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".
CSS grid is only recently becoming a reasonable tool to use in practice. I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.
Based on experience, the kind of person who would be able to use it from memory either 1) is very skilled AND had a reason to use it recently, or 2) someone of medium skill who just recently read the spec but in almost all other ways is less skilled than the people I mentioned in the first paragraph.
> I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.
You probably don't mean it that way, but not having to use the documentation surely isn't a requirement for competency. I resort to the docs all the time, even with topics I'm quite famialiar and experienced with.
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.
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.
> 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?
> Would this eventually lead to 8 productive hours?
In same way that sleeping 10 minutes less each day leads to you not needing sleep at all or showering at 1 degree more each day makes you impervious to boiling water. So, no, absolutely not and potentially dangerous to your health.
Your example is not quite as obviously wrong depending on your definition of "running" and "indefinitely". With a bit of hand waving I would personally count hiking all day, a marathon also feels long enough to me to count as indefinitely. Furthermore, cross-country marathons are a thing, see for example the movie "Forest Gump".
I tried something like that multiple times - removing all distractions and non work or replacing them by educational activities. Each time it lead to overall slowing down. Peek ceased to be as good. Once it lead to depression, when I replaced all entertainment and chill in my life by "productive activities".
You can do that in short term, the real problem is usually when I tried that for weeks.
Some amount of downtime is necessary. Now I intentionally take breaks and exercise a bit in between coding. The exercise actually helps. With breaks you gotta measure them a bit tho, else you risk taking too long breaks too often.
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?
That's why I stay home when I need a long stretch of productive time on one or two things.
But the office has upside when the task is not well defined or I work on a lot of small stuff. At home, my brain will wander around more easily between context switches.
> I'm working on something that's been de-risked. I know what I need to do and I know how to do it
Thanks for including this one. I think the biggest stresses in my dev career have come from times where I didn't really know what needs to be done or when I was way out of my depth. I believe this reason alone was a huge driver of my procrastination in the past, especially when I was the lone programmer on the project.
That's why I hate doing interviews and always procrastinating when I need to find a new job. Once I talk to an engineer I know if the job is a good fit for me or not, till then I fell HR/recruiters just wasting my time.
Productivity is a function of concentration and understanding. If you have sufficient knowledge, what lacks is concentration. I'm perpetually amazed how people 1) fail to see this and 2) think their concentration power is fixed for life.
An example of this is when you do pair programming, your pair forces you to keep concentrated (and you force him too) - if you are screensharing you won't alt tab to reddit) so it's an example on how you can keep focused for longer periods than normal, at the expense of being more tired at the end of the day.
I'm guessing this is an average rather than absolute amount every day, and I also don't quite think it's possible to 'force' yourself to be more productive, as being productive is both about how fast you think, how fast you type and how fast you come up with solutions to a problem.
No matter how much you force yourself you can't just force yourself not to feel exhausted/restless/depressed or whatever else is effecting your productivity, you sure can alleviate these symptoms, but that's improving your well-being generally rather than forcing yourself to be productive.
So it sort of depends what you mean by force, I'm guessing it would just cause you more stress and make you eventually burn out because you're not in reality becoming more productive by focusing more, you're only stressing yourself out further.
It really depends on the context of the work. Usually I'm getting interrupted, or I worry that I'm going to get interrupted. Then there are meetings, coffee breaks between them. All these things prevent me from being productive.
I don't think working 8 hours of productive work will get you to burnout. It's more a matter of habit and discipline and interest in the project.
In my experience, what leads to burnout is a bad working environment and/or working a lot for long period of time.
How do you define productive so that you could add a time goal to it?
Because I read it as "There are on average about two hours of productive in-context work to be done and the other hours are about building that context for those two hours that not often transfer between days." You can't add 10 minutes to that.
I found that best way to improve productivity is automating development work as much as possible. 2-4 productive hours a day are enough if you spent it on solving important problems. I have always worked less hours than my colleges with roughly the same amount of work done and the same error rate because they are refusing to change their workflow.
Write test for everything, don't do manual testing. If the test is green my code is good. Don't spend time manually testing your code.
Touch typing was a huge improvement. I'm not a fast touch typer so it wasn't really improved my typing speed. It's more of that I outsourced my typing from my brain to my hand, so while I type I can stay focused on the problem.
The whole point of this is that it's not a binary state, and it's not "writing code".
So, tl,dr : no, it's not because you are most likely not the bottleneck. You are not the master of the cognitive overload you operate in for instance.
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
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.
How can you "refuse to pay" with uber? You have to have a card on file to order a ride. Not having a payment interaction with the driver is half the appeal.
- 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".