No offense to everyone who's behind competitive coding, but the people who just focus on the competitive aspect of coding are missing the real essence of technology and its development.

Let me explain.

Coding was created to help in bringing the technologies that you had imagined to life. It's more of an art than math or science. Musicians use a musical instrument to bring the harmony playing in their heads to live. In the same way, programmers got to bring the technology in their heads to life by coding it. Yes, it does involve a lot of math and logic, but great things have unique results and takes time to build.

Competitive programming focuses on getting a known result from a given input in a short period of time, with an algorithm of lesser time and space complexity. But, have you ever taken a minute to think about what the algorithm you've spent time writing can be used for? Does it bring anything new to the world? Can it result in a technology that can make a difference in the world or innovate something?

When you try to answer such questions, you'll realize that you aren't using code to do what coding was actually created for, and you've wasted time in writing a bullcrap algorithm that can't even be used in your alarm clock to wake you up every morning.

Yes, it will help you sharpen your skills in data structures and algorithms, but does it teach you how to build the product that your dream tech company is known for?

What are the downsides of Competitive programming?

1. Competitive programming problems are usually precisely specified.

Competitive programming is all about well-defined problems that have known answers that can be realized with a small amount of code. Nobody’s livelihood (or physical safety) is at stake. One person will be using the code and it will be discarded as soon as the competition completes. That means that no customers will have to use the code, nobody will have to be hired to maintain the code, and the code will not be ported to other architectures or operating systems.

Most of the hard problems you come across in real-world programming are not well defined. In most cases, deciding what problem to solve will take up much more of your time than solving a problem. Even if you work in an organization with product managers or analysts to determine what the user experience will look like, you will still have a lot of freedom to choose the inputs, outputs, and behavior of your code, which you would not have in competitive programming. With freedom comes responsibility and even brilliant algorithm designers can fall down on these decisions.

2. Plagiarism (Copy someone else's work)

Plagiarism in competitive programming is not new. What many people don’t understand is the fact that competitive programming is a platform for improving your knowledge. But, everyone just wants the results. They just google the coding question and copy-paste someone else’s solution. You may get a high rank, but you are compromising your learning effort for it.

People cheat in every form of sport and competitive programming is not an exception. It can sometimes be really hard to spot the cheaters in competitive programming. Sometimes the cheaters end up being declared winners.

Competitive programming does have these so-called “issues”.

3. Only care about ratings

People get obsessed with ratings, no matter the growth, or how good you are. Everyone tries to hit a wall but the ratings don’t improve or you think that you cannot improve beyond this. It can lead to a feeling of sadness, frustration, wanting to give up, etc, and in worst cases, cheating, just for the sake of rating - which again beats the point of competitive programming. It is supposed to be a fun activity, and having a rating that does not reflect your true skills will not help you in any way.

4. Competitive programming requires less knowledge

Competitive programming typically only requires knowledge of complexity theory, algorithms, and data structures, and a bit about low-level details that affect performance. It doesn't require knowledge about networking, graphics, databases, distributed systems, concurrency, operating systems, compilers, user interfaces, or security. In real applications, all of these things can potentially be important. Generally, competitive programming guys don't know much about other aspects of software development.

5. Great things take time

Most competitive programming problems can be solved in a short amount of time, by a single person. Real-world software typically arises through the collaboration of many people, working over a period of months or years.

Competitive programming focuses almost entirely on your ability to find efficient solutions to difficult but well-defined problems in a short period of a given time. In most cases, you also do this on your own. Most programming jobs are quite different from this.

6. Bad coding practices.

Most competitive programmers (read: almost all) have terrible coding practices (born out of the need to finish the code as fast as possible and the fact that generally, you don’t expect someone else to read the code), such as:

Writing code without proper indentation.
Using variable names such as a, b, c (instead of count, sum, etc) or random variable names such as lol, haha (which is even worse).
Writing no documentation.

7. Values are different

The values are not the same.

In competitive programming, you already have a problem solved many times, and you just need to find a way to solve it again and fastest. It's even not about writing the "best code", but just the fastest and in the fastest way.

in competitive programming, you don't care about evolution, change, etc.

In real-life programming, the entire process is shared among the team members.

Most of the time, developers corporate in a team. In this way, you do not solve a problem alone.
Teams deal with uncertainty if a difficult problem occurs.
The speed of execution is not the biggest problem, and even if you have to do optimization, it's usually in less than 5% of your codebase.
The speed of production is important, but you need to keep in mind the evolution, and so bring the ability to evolve.
Beauty of the code is as important as the speed of execution.
Creativity and innovation are highly valuable.

8. Ownership Problem

Competitive programming does not require a person to have long-term ownership of the problem. Every problem tackled is independent of each other and with zero dependencies and literally no regression pitfalls.

Real-life programming inherently expects you to own up (till your association with the organization) and problems solved are mostly inter-connected to modules owned by your peers within the domain you operate on. This brings in unavoidable dependencies.

9. Business Priorities

In a business, the priorities are

The code should do the necessary task correctly.
Code should be supportable - i.e. easy to read, covered with tests, with necessary documentation and tooling around it.
If you can make it work fast without sacrificing 1 or 2 goods then it’s not critical unless you are working in some real-time system.
Let’s face it - you CAN’T create code fast. So forget about writing fast code and focus on what’s really important.

10. It's not the only way

Many computer science engineering students who are not very good at competitive programming think that it is the only way to build a good career. They get into depression. They stop searching for other ways. Many eventually give up and accept their fate but if you're really interested in coding then spend the same time using it to build something impactful or contribute directly to real open-source projects.

Making real-life projects or contributing to open source projects will help you reach your goal. Competitive programming is overrated. Everyone wants to get into FAANG and make a career out of it but there are other alternatives also that provide many opportunities and a high salary as compared to FAANG that you can get with open-source and believe me that companies will contact to hire you if you have a good open-source portfolio.

Bilal's Blog