7 ms·

I'd disagree with this assessment. In my own experience, I've found that competitive programming is useful in teaching a few skills. However, the apparent point

I'd disagree with this assessment. In my own experience, I've found that competitive programming is useful in teaching a few skills. However, the apparent point of competitive programming--building up a good repertoire of advanced algorithms and data structures--is pretty close to useless. In my professional career, the most complex algorithm I've ever had to code myself is ... union-find (on like two occasions), with a custom BFS/DFS being the most common algorithm I reach for. Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare. No, the most useful impacts of competitive programming has to do with actually teaching you how to program effectively. The most important advice I got for competitive programming was walk away from the computer. The biggest trap when programming is to write code before you know how to solve a problem, as this will tend to encourage you to spend all of your time making no progress towards actually getting a solution. The tale of the Sudoku solver [1] is salutatory here. Another useful skill is how to debug algorithms. Debugging a competitive programming problem usually amounts to taking an input that fails and trying to understand where in the algorithm (as expressed in poorly written and commented code!) the mistake is. Doing so under the time pressures of a competition also requires being able to rapidly decide if the algorithm is wrong, or it is the implementation is wrong, as well as figuring out where the most likely places for errors are likely to creep in. This kind of experience translates very usefully into professional programming, and debugging is a skill that seems to be poorly acquired by most young programmers. When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO. But there's still a lot of skills that need to be acquired to move up competitive leaderboards before you reach that point. [1] https://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html https://ravimohan.blogspot.com/2007/04/learning-from-sudoku-...

alerighi 5y ago
To me competitive programming doesn't make you a good software engineer. It will teach you bad practices, like abusing of dangerous programming constructs or data structures to optimized the code or just save some typing while writing the code (like one letter variable names, macros, etc), global variables and state in the program, not using common design patterns, not using OOP, not documenting the code and in general writing code that is difficult to maintain because it's not well engineered. You would say that a person would do that only in competition, but in my experience I saw that is not true, because if you learn to program a particular way, you would do the same also in other contexts. Also, the competences that you will acquire by doing competitive programming are next than useless: in the real life I've yet to encounter a situation in which I have to use an algorithm used in a competitive programming competition (yes, I did them with even good results). And if you need them, you don't implement them yourself, but you use a library that manages all the work. The Dijkstra implementation that most competitive programmers use is a toy implementation, not something that you would never use in any sort of enterprise software. The fundamental skill that competitive programming doesn't teach you, that to me is the most important thing for a good software engineer, is using Google to find documentation online. Most of the errors I see by young software engineers could easily been prevented if they did a simple Google search and read the official documentation (not a random blog post)! And yet in competitive programming you are forbid to use the internet, to me it's stupid, it's like requiring to write code with a typewriter just because in the past keyboards and monitors didn't exist.
- deleted 5y ago
  [deleted]
- xenocratus 5y ago
  Competitive programming doesn't teach you only algorithms and data structures, it teaches you to think very clearly about program flow, edge cases, debugging etc., points which you seem to just gloss over from the comment you're replying to, just to justify a conclusion you had already reached.
  - andrekandre 5y ago
    definitely, alot of the "algorithms" in leetcode practice look deceptively simple on the surface, but deep down, there are lots of edge cases and are good practice to think deeply about them on the otherhand, they can also encourage messy and hard to maintain code, or super efficient implementation can be brittle which you dont want in production unless there is a really really good reason... if "competitive coding" also judge on other criteria such as clarity, readability and maintainability, in addition to efficiency and "correctness" that would be great imo
- tempodox 5y ago
  Not using OOP is a bad practice? That's a hard sell.
- anonymoushn 5y ago
  Not using design patterns seems like pure upside. I don't think it's reasonable to use a library for most things one implements in competitive programming, because the work of getting your problem instance in and out of the library is probably greater than the work of writing the solution yourself, in code length and in runtime. As an example, the only time I ever needed to use A* was on a state space that was larger than the main memory of any computer on Earth. I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me, but I can just bash out my own A* that's fused with the definition of the state space. Maybe this is so easy to do partially because I did a bunch of programming contests in which I wrote BFSes that were fused with the definitions of graphs.
vlovich123 5y ago
> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare. This undercuts your claim a bit as someone has to be able to write the library in the first place. Yes it’s rare, but the software engineering industry is big enough that “rare” can be a “this happens all the time in domain X”. Overall though I’d agree that it’s not useful for the majority of engineers and isn’t a good judge of programming ability just like math competitions aren’t either. They are “something” though.
- kamaal 5y ago
  You most likely need strong grasp over OO, and design patterns to be a good library designer/programmer than Algorithms that you can easily look up online.
- derefr 5y ago
  Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge. It’s not often that you’re writing such code “in anger”, under time-pressure to ship to fix downtime, with no time to get peer review. This is in large part because the downstream client of an algorithms/data structures library, would almost-always prefer a robust but less-efficient option, over an alpha-quality implementation of a more-efficient option. Dataset-size scaling challenges that recommend algorithmic efficiency increases can, almost always, be temporarily put off by “throwing machines at the problem” until the more-efficient library becomes high-quality enough to be fully relied upon. Until then, the business logic will make do with the simpler/more naive algorithm. And in most language runtimes, there’s a simpler/more naive algorithm or data structure to solve every problem already laying around in the core stdlib; so it’s not like you, as the library writer, have to implement that code “in anger” either. Your internal customers can upgrade from depending on stdlib types, to depending on your lib’s types, when using your lib becomes an unalloyed win for them; and until then, do nothing.
  - 5y ago
eeegnu 5y ago
> When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO. I found this post [1] by the current rank 5 competitive programmer on codeforces to be an interesting take on this perspective. It's not as much about knowing the fancy algorithms, as being able to derive their ideas when needed, that makes you really move up. [1] https://codeforces.com/blog/entry/92248 https://codeforces.com/blog/entry/92248
derefr 5y ago
I’d love a programming competition that wasn’t about speed of implementing algorithms, but rather was about speed of implementing solutions, using a provided standard library of algorithms and data structures. Competitive glue-code programming, per se, but glue code that still requires that you understand the need for specific advanced algorithms in order to pull them out of a toolbox.
- natdempk 5y ago
  Isn't this basically what competitive programming is? Maybe I'm a bit clueless, but my assumption was most people have standard libraries of common algorithms/implementations they pull from and tweak/glue as needed to fit the problem in front of them. Those libraries are not standardized, but there is for sure basically a common set of things you need to be competitive, right?
  - anonymoushn 5y ago
    There is a common set of algorithms that most people who do well in such a contest can implement whenever they like, but most of the effort involved in solving the problems happens before they write any code, and many (half or more?) problems can't be solved by just applying the techniques from this repertoire.
    - baobabKoodaa 5y ago
      This is correct. A typical CodeForces problem is intentionally constructed as a unique snowflake that can't be solved by just calling a library function. You need to be able to design an algorithm that solves that specific unique snowflake on the spot. Perhaps your algorithm also makes some library calls to other algorithms in your comp.coding library, but those are merely building blocks for your own thing, which you have to invent.
  - squeaky-clean 5y ago
    I haven't done competitive programming in years, but when I did we were allowed to use things like Boost in C++ or the standard library in Python. I can't really recall any scenarios where a stdlib datastructure was slightly too slow, but re-implementing your own version was just fast enough to get by. The problems were typically created in a way where using any common algorithm was 1000x too slow, and you needed something like dynamic programming to make things run in a reasonable amount of time. Or they were a math problem masquerading as a programming problem.
baobabKoodaa 5y ago
> However, the apparent point of competitive programming--building up a good repertoire of advanced algorithms and data structures--is pretty close to useless. That's not the point of competitive programming. If you talk to anybody who is good at competitive programming, they will tell you it's _not_ about memorizing algorithms and datastructures. It's about developing algorithmic problem solving skills; skills that you can leverage to design (create) algorithms, in order to solve problems.
- watwut 5y ago
  I have seen successful competitors people do basically that. And I have seen them train how to write basic algorithms super fast again and again. Yes, they had also algorithmic problem solving skills. But they learned huge amount of algorithms and datastructures so that they don't have to derive them each time. And they spend time literally training how to write them fast without mistake. It was not just about problem solving skills. It was a lot about knowledge base.
  - baobabKoodaa 5y ago
    Ok. I'll take your anecdote at face value and shift my views slightly in that direction. I'll also note that even if some competitors do memorize algorithms & train how to write them fast without mistakes, this memorization perhaps gives them a slight edge, but it's not the core skill that separates winners from losers. A small edge, perhaps.
    - watwut 5y ago
      Necessary edge. There was tons of preparation specifically for competitions. Not sure why would that be surprising. Same thing happen in chess, scrabble, anything competitive. Once there is enough competition, you can't go in with hope and talent alone. You have to train specifically for competition format. Chess players don't base their play on pure problem solving either. They memorize and train specific plays.
      - 5y ago
baobabKoodaa 5y ago
> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare. Developers who have no interest towards algorithms will not even have the skills required to identify opportunities where algorithms should be used, much less the skills required to identify which algorithm should be used. For example, I had a conversation here on HN a few weeks back where somebody said that they will not need to learn anything about sort algorithms, because they can just google bubble sort and copypaste it if they need sorting at work. And that's how you end up with 5-minute load times for GTA.
- tester756 5y ago
  >And that's how you end up with 5-minute load times for GTA. was it actually the reason?
  - chrisphilip 5y ago
    https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... tl:dr; O(n^2) string parsing and O(n^2) duplicate removal
  - rnotaro 5y ago
    https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
  - baobabKoodaa 5y ago
    Bubble sort provides O(n^2) time complexity for a task that can be easily solved with O(nlogn) time complexity. The 5-minute load time for GTA was caused by a developer using an algorithm with O(n^2) time complexity when they could have used an algorithm with O(nlogn) time complexity. So, yes, I would say it actually was the reason (unless you are specifically asking if the bad algorithm choice was bubble sort, in which case the answer is no).
  - karlding 5y ago
    No they weren't using bubble sort. When parsing JSON, they were calling sscanf (which internally was calling strlen). In addition, those parsed objects were stored in an array which was iterated through on each insert to check for duplicates. There was an article [0] and subsequent discussion on HN [1] about reverse engineering and patching the binaries. [0] https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... [1] https://news.ycombinator.com/item?id=26296339 https://news.ycombinator.com/item?id=26296339
Dopameaner 5y ago
I believe the author will agree with your assessment. > Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless.
Rd6n6 5y ago
The worst part of competitive programming is that you need to do it for job interviews. This turned a legitimately fun and deeply engaging activity into a truly tedious and draining one

alerighi 5y ago

To me competitive programming doesn't make you a good software engineer. It will teach you bad practices, like abusing of dangerous programming constructs or data structures to optimized the code or just save some typing while writing the code (like one letter variable names, macros, etc), global variables and state in the program, not using common design patterns, not using OOP, not documenting the code and in general writing code that is difficult to maintain because it's not well engineered. You would say that a person would do that only in competition, but in my experience I saw that is not true, because if you learn to program a particular way, you would do the same also in other contexts. Also, the competences that you will acquire by doing competitive programming are next than useless: in the real life I've yet to encounter a situation in which I have to use an algorithm used in a competitive programming competition (yes, I did them with even good results). And if you need them, you don't implement them yourself, but you use a library that manages all the work. The Dijkstra implementation that most competitive programmers use is a toy implementation, not something that you would never use in any sort of enterprise software. The fundamental skill that competitive programming doesn't teach you, that to me is the most important thing for a good software engineer, is using Google to find documentation online. Most of the errors I see by young software engineers could easily been prevented if they did a simple Google search and read the official documentation (not a random blog post)! And yet in competitive programming you are forbid to use the internet, to me it's stupid, it's like requiring to write code with a typewriter just because in the past keyboards and monitors didn't exist.

deleted 5y ago
[deleted]
xenocratus 5y ago
Competitive programming doesn't teach you only algorithms and data structures, it teaches you to think very clearly about program flow, edge cases, debugging etc., points which you seem to just gloss over from the comment you're replying to, just to justify a conclusion you had already reached.
- andrekandre 5y ago
  definitely, alot of the "algorithms" in leetcode practice look deceptively simple on the surface, but deep down, there are lots of edge cases and are good practice to think deeply about them on the otherhand, they can also encourage messy and hard to maintain code, or super efficient implementation can be brittle which you dont want in production unless there is a really really good reason... if "competitive coding" also judge on other criteria such as clarity, readability and maintainability, in addition to efficiency and "correctness" that would be great imo
tempodox 5y ago
Not using OOP is a bad practice? That's a hard sell.
anonymoushn 5y ago
Not using design patterns seems like pure upside. I don't think it's reasonable to use a library for most things one implements in competitive programming, because the work of getting your problem instance in and out of the library is probably greater than the work of writing the solution yourself, in code length and in runtime. As an example, the only time I ever needed to use A* was on a state space that was larger than the main memory of any computer on Earth. I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me, but I can just bash out my own A* that's fused with the definition of the state space. Maybe this is so easy to do partially because I did a bunch of programming contests in which I wrote BFSes that were fused with the definitions of graphs.

vlovich123 5y ago

> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare. This undercuts your claim a bit as someone has to be able to write the library in the first place. Yes it’s rare, but the software engineering industry is big enough that “rare” can be a “this happens all the time in domain X”. Overall though I’d agree that it’s not useful for the majority of engineers and isn’t a good judge of programming ability just like math competitions aren’t either. They are “something” though.

kamaal 5y ago
You most likely need strong grasp over OO, and design patterns to be a good library designer/programmer than Algorithms that you can easily look up online.
derefr 5y ago
Writing foundational algorithms/data-structures libraries (e.g. language-runtime stdlibs like libc) is usually treated as a sort of sacred ritual in programming—something where it’s “obvious” that it should be done slowly, carefully, and without distraction, with each change audited carefully by many peers before accepting a merge. It’s not often that you’re writing such code “in anger”, under time-pressure to ship to fix downtime, with no time to get peer review. This is in large part because the downstream client of an algorithms/data structures library, would almost-always prefer a robust but less-efficient option, over an alpha-quality implementation of a more-efficient option. Dataset-size scaling challenges that recommend algorithmic efficiency increases can, almost always, be temporarily put off by “throwing machines at the problem” until the more-efficient library becomes high-quality enough to be fully relied upon. Until then, the business logic will make do with the simpler/more naive algorithm. And in most language runtimes, there’s a simpler/more naive algorithm or data structure to solve every problem already laying around in the core stdlib; so it’s not like you, as the library writer, have to implement that code “in anger” either. Your internal customers can upgrade from depending on stdlib types, to depending on your lib’s types, when using your lib becomes an unalloyed win for them; and until then, do nothing.
- 5y ago

eeegnu 5y ago

> When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO. I found this post [1] by the current rank 5 competitive programmer on codeforces to be an interesting take on this perspective. It's not as much about knowing the fancy algorithms, as being able to derive their ideas when needed, that makes you really move up. [1] https://codeforces.com/blog/entry/92248 https://codeforces.com/blog/entry/92248

derefr 5y ago

I’d love a programming competition that wasn’t about speed of implementing algorithms, but rather was about speed of implementing solutions, using a provided standard library of algorithms and data structures. Competitive glue-code programming, per se, but glue code that still requires that you understand the need for specific advanced algorithms in order to pull them out of a toolbox.

natdempk 5y ago
Isn't this basically what competitive programming is? Maybe I'm a bit clueless, but my assumption was most people have standard libraries of common algorithms/implementations they pull from and tweak/glue as needed to fit the problem in front of them. Those libraries are not standardized, but there is for sure basically a common set of things you need to be competitive, right?
- anonymoushn 5y ago
  There is a common set of algorithms that most people who do well in such a contest can implement whenever they like, but most of the effort involved in solving the problems happens before they write any code, and many (half or more?) problems can't be solved by just applying the techniques from this repertoire.
  - baobabKoodaa 5y ago
    This is correct. A typical CodeForces problem is intentionally constructed as a unique snowflake that can't be solved by just calling a library function. You need to be able to design an algorithm that solves that specific unique snowflake on the spot. Perhaps your algorithm also makes some library calls to other algorithms in your comp.coding library, but those are merely building blocks for your own thing, which you have to invent.
- squeaky-clean 5y ago
  I haven't done competitive programming in years, but when I did we were allowed to use things like Boost in C++ or the standard library in Python. I can't really recall any scenarios where a stdlib datastructure was slightly too slow, but re-implementing your own version was just fast enough to get by. The problems were typically created in a way where using any common algorithm was 1000x too slow, and you needed something like dynamic programming to make things run in a reasonable amount of time. Or they were a math problem masquerading as a programming problem.

baobabKoodaa 5y ago

> However, the apparent point of competitive programming--building up a good repertoire of advanced algorithms and data structures--is pretty close to useless. That's not the point of competitive programming. If you talk to anybody who is good at competitive programming, they will tell you it's _not_ about memorizing algorithms and datastructures. It's about developing algorithmic problem solving skills; skills that you can leverage to design (create) algorithms, in order to solve problems.

watwut 5y ago
I have seen successful competitors people do basically that. And I have seen them train how to write basic algorithms super fast again and again. Yes, they had also algorithmic problem solving skills. But they learned huge amount of algorithms and datastructures so that they don't have to derive them each time. And they spend time literally training how to write them fast without mistake. It was not just about problem solving skills. It was a lot about knowledge base.
- baobabKoodaa 5y ago
  Ok. I'll take your anecdote at face value and shift my views slightly in that direction. I'll also note that even if some competitors do memorize algorithms & train how to write them fast without mistakes, this memorization perhaps gives them a slight edge, but it's not the core skill that separates winners from losers. A small edge, perhaps.
  - watwut 5y ago
    Necessary edge. There was tons of preparation specifically for competitions. Not sure why would that be surprising. Same thing happen in chess, scrabble, anything competitive. Once there is enough competition, you can't go in with hope and talent alone. You have to train specifically for competition format. Chess players don't base their play on pure problem solving either. They memorize and train specific plays.
    - 5y ago

baobabKoodaa 5y ago

> Almost everything you will ever need is already implemented in a library for you to reuse, and even reaching for that library is pretty rare. Developers who have no interest towards algorithms will not even have the skills required to identify opportunities where algorithms should be used, much less the skills required to identify which algorithm should be used. For example, I had a conversation here on HN a few weeks back where somebody said that they will not need to learn anything about sort algorithms, because they can just google bubble sort and copypaste it if they need sorting at work. And that's how you end up with 5-minute load times for GTA.

tester756 5y ago
>And that's how you end up with 5-minute load times for GTA. was it actually the reason?
- chrisphilip 5y ago
  https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... tl:dr; O(n^2) string parsing and O(n^2) duplicate removal
- rnotaro 5y ago
  https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
- baobabKoodaa 5y ago
  Bubble sort provides O(n^2) time complexity for a task that can be easily solved with O(nlogn) time complexity. The 5-minute load time for GTA was caused by a developer using an algorithm with O(n^2) time complexity when they could have used an algorithm with O(nlogn) time complexity. So, yes, I would say it actually was the reason (unless you are specifically asking if the bad algorithm choice was bubble sort, in which case the answer is no).
- karlding 5y ago
  No they weren't using bubble sort. When parsing JSON, they were calling sscanf (which internally was calling strlen). In addition, those parsed objects were stored in an array which was iterated through on each insert to check for duplicates. There was an article [0] and subsequent discussion on HN [1] about reverse engineering and patching the binaries. [0] https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... [1] https://news.ycombinator.com/item?id=26296339 https://news.ycombinator.com/item?id=26296339

Dopameaner 5y ago

I believe the author will agree with your assessment. > Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless.

Rd6n6 5y ago

The worst part of competitive programming is that you need to do it for job interviews. This turned a legitimately fun and deeply engaging activity into a truly tedious and draining one