If you go there, search for a tag, sort by popularity, etc. - most of those techniques and approaches and patterns are, if not timeless, then mostly timeless and relevant.
A person who hasn't mastered loops and conditionals will fail FizzBuzz. That is bad, you recognise that I hope. But it doesn't end there, you can master so many more powerful parts of programming and get as fast as you were at FizzBuzz att many other much more complicated tasks as well. Ultimately programming takes time due to all the parts you didn't master, but when you have mastered enough parts then you can fit just about any problem into parts you have mastered and code them up extremely quickly.
So the speedup you see is roughly the speedup you saw from at first struggling a lot with loops and conditionals early on when learning programming, to today when you do them effortlessly and instantly. Now the other things to master aren't as simple patterns as loops or conditionals, but the end result is the same improvement in speedup and effort.
For example, competitive programming is about mastering a ton of such chunks. You don't memorize solutions to get fast, you master thousands of such chunks and compose them to solve problems in 5 minutes that would take regular programmers 5 hours if they can solve it at all. I went that route and it is similar to how people master chess, a grandmaster makes better moves after a few seconds of thinking than a typical chess player who has played for years thinking for many minutes.
It took about a year and then I could solve hard problems at similar pace as the best in the world with basically no errors, compare that with spending 4 years in college, I think the practice is worth it, I have never needed to practice that again as the chunks I mastered doesn't go away, it is like learning how to ride a bike. You forget the details, but your subconscious wont forget those chunks. Of course I can't solve hard competitive programming problems in 5 minutes today, but I can solve most leetcode "hard" problems I haven't seen before in under 15 minutes and basically all of them in under 30 even though I haven't practiced these things for many years.
Now, this wont solve all your programming woes, you still need to understand requirements, talk to customers, learn API's etc. But at least you are no longer bottle necked by composing programs. Instead you can throw together MVP's quickly, show prototypes to make discussions more fruitful etc. Also most jobs doesn't requires this level of mastery, only do it if you aim to join top teams using your technical skills if you really get good at this then many teams that wouldn't care about you before now gets very interested in you since so few are this fast, or if you want to build your own products on your own, or if you find mastering things fun.
Edit: Sorry for edits, but here is last bit. When I worked at a high performing team at Google I averaged over 500 lines of code a day going through code review and running in production when I wasn't constrained on non-programming bits like understanding the problem etc. To do that you write 10 changes, each about 50 lines and trivial to review since everything is super clean, otherwise you can't get through code reviews fast enough. Code reviews, unit tests, fixing edge cases etc, none of that are excuses for being slow. Now it is still fine to be slow, I don't blame people, I'm just saying it is possible to be fast if you deliberately practice a lot to be fast.
No matter how small or clean the PRs were, I'm pretty sure I couldn't get reviews for 10 in one day.
If the change adds tests, has proper naming, solves the issue it says it is solving in a reasonable way, doesn't solve anything it doesn't say it is solving, and none of the tools complains then you just accept it after looking at the tests being reasonable and the code not looking strange. It takes a while to get new engineers where they do this consistently before review, and then review takes time, but once you know how to write changes that are easy to review then reviews are very quick.
Edit: Btw, optimizing the code you write to reduce review time is also another aspect of productivity. It isn't productive to give a lot of extra work to others, so you practice until everything is as obvious as possible. And as people get used to your changes being easy to review it gets even quicker.
I work remotely, so my (Small) team mostly works async even though we're in similar time zones. I doubt trying to ping them for 10 PR reviews in a single day would go well.
Async + people trying to do their own stuff + 10 interruptions is not a great combo. Comments/discussion on a PR can grind things to a halt as well.
I completely agree everything you're saying about making PRs easy to review though. My team already tend to do those things thanks to our manager.
Also as long as you have a pending review sent to you it shows up as a "you have stuff to do" icon in the google tools until you respond to it, just like if you got a message, I guess that helps as well.
I would say it's not uncommon to have to wait a day for reviews.
I completely agree that senior and lead people should be doing more reviews and thus help everyone else, ultimately benefiting other programmers and the whole organization overall.
So the most important part is that the reviewer should be just as visible in all processes and tools as the writer of the code. That way both gets recognition and both gets the blame when the code is bad or adds technical debt. And for performance reviews you don't just look at all the code they wrote, you also look at all the code they reviewed.
You are right that it is dumb to just count the number and say more is better, but the same goes for code submissions. They are very similar problems though so you can just use the same process for both of them.
You mentioned another metric "code submissions", so say the number of reviews done is augmented by number or PRs merged. You've just created another incentive to just get a lot of code out fast.
After all, that's the point of the metrics, right? Have a few numbers that accurately describe the "value" of that employee. </sarcasm> No qualitative analysis needed, that would take time and money we don't have. Been there, had to do that (or write huge amounts of text to say why I think that this employee is actually really good at what they do and the number of PRs they did was low because they got the short end and worked on the hardest problems in the worst parts of our code base and did an amazing job especially given they were new.
If that's not how it's actually done where you work, great!
For example, when is it useful to create a function instead of writing the code inline? Many times the amount of code grows exponentially with problem size unless you properly create good functions, so you need to learn to get good at that. Code reuse also greatly improves how fast you can write the solution and reduces bugs, so it is good even when it isn't absolutely necessary.
Where should the data be, who should own what data, how is the data supposed to be found where you need it? And so on. Many problems requires you to create quite elaborate data structures and relationships, finding the right data in a reasonable amount of time is one of the hardest problems to solve even in competitive programming.
Caching and lazy computations as well, it is used everywhere in competitive programming. The fastest solution is where you don't do anything at all, so you get good at understanding how and when to cache results, when to throw out caches in order to handle new data etc.
Writing proper tests, since you get no credit if your code fails for any case you need to write tests that stresses all parts of the code you are unsure about. This teaches you to get really good about understanding the weaknesses in the code you write, debugging and creating solutions that are bug free.
Stuff like that is really important to get good at competitive programming, you need to be able to get good answer those questions in minutes for complex problems if you want to compete with the best in the world. Now you might notice that many basic data structures and algorithms are just solutions to the above problems, the point is to learn many generic cases of the above so you can compose your own data structures and algorithms as everyone of the harder problems requires you to do that.
And as you can realize these things are very useful for any sort of program, not just competitive programming. Managing data layouts and when it is useful to create functions is the majority of normal programming, if you can do those really quickly then there isn't much left that will take time.
Now, the bad rep competitive programming has is mostly that people just do the easy problems that can be summarized as "implement this basic algorithm". Real competitive programming isn't like that at all. Of course you need to be able to do the simple algorithms, but knowing how to implement the algorithms is just table stakes.
"Don't I practice these things when writing normal programs?"
Not in the same way. Competitive programming is about doing these in their pure form. In normal programming there are so many other things that it is hard to focus on the code, while in competitive programming all you have is code and then a really good test suite you can do to verify your solution once you think you are done. This way you practice a huge range of programming chunks really quickly, compared to trying to test them out and learn them in real world codebases.
Edit: Btw, last time I checked Leetcode didn't have many questions that stresses these important points, its mostly just useful to learn algorithms used in these interviews, it isn't good to learn programming. There are many good competitive programming sites to use instead. Leetcode is good if you want to pass interviews with minimal effort right now, but it isn't good if you want to get good. Also you just get good at chunks, you will still need to practice writing and structuring larger programs and solutions. But practicing that is way easier when you have mastered these chunks.
https://codeforces.com/?f0a28=1
It has the widest selection and types of problems as far as I know but that was a while ago. It runs competitions all the time, the problem descriptions are well defined unlike leetcode which often misses a lot of requirements, it has way more kinds of problems than topcoder, you can test yourself against old competitions as if they ran real time to properly ensure you don't take too much time or accidentally cheat etc.
> What would be the best way to learn these skills in your opinion?
I think today it is hard to practice without competitive programming. Ideally someone would make a similar format pushing your limits like this but without so much focus on complex algorithms and maths, but since that doesn't exist competitive programming is what we are left with. The competition aspect is really important since it is how people push each others limits. It is easy to think "you can't get much better than this" when you just sit and code by yourself, but in programming competitions you see how fast and accurately others can solve problems, so you realize that you could get just as fast and accurate with a bit of practice.
And no, it is not memorization. Consider this easy problem which mediocre competitive programmer manages to solve but those below mediocre fails at (we can see that from how well people did on it in the competition):
https://codeforces.com/contest/1496/problem/B
There is no algorithm you have to know for that, it is just good old logic and some coding. It is really easy and I could solve in in a few minutes even my todays rusty self, but you can't memorize solutions to such problems, you just have to be fast both with the reasoning and the code. Note "mex" is not a standard term, it is just something they made up for that problem.