To try and understand the psychology of a problem solver, let us ask a few abstract questions:

1) Why do you like solving problems?

2) What is the biggest challenge you face when implementing your solution?

3) Which key area in your skill set can you improve simultaneously along with problem solving?

The answers to the first question are very interesting: Contestants swear about how much they love math/algorithms and designing data structures. I have never heard someone say : "Oh, I love checking for integer overflows!" or "Finding the maximum in an array is so awesome!". And yet, we find ourselves stuck doing these exact same things, again and again, till our minds are trying hard to stick to the original problem while our fingers frantically type out the code.

So we have an answer to our first question. We solve problems to challenge our mind, to sooth our egos by looking at green ticks and savour the adrenaline coursing through our veins when we are put in crunch situations. Conversely, doing monotonous tasks like checking for integer division is not why we come here. There is a way around this...but now let's talk about question two.

The second question is often mistaken to be trivial: writing code is, of course, the most difficult task! Oh, and how do we speed that up? "Why, you just practice harder!" the sages quip. "Work smart, dude!" advise others, before sinking into monitors to debug their programs.

No. Coding an algorithm may be the most important task, but code that does not work is not too different from code that does not exist. More often than not, the meat of your time will be taken up by debugging. Especially if the algorithm was difficult to implement. We will be talking on mitigating this after discussing the last question.

The final question is a little vague. What can we enjoy doing simultaneously? Guitar lessons. Gym. Watching por- I mean, TV shows. But as software engineers, data scientists or algorithm designers, we have another responsibility. The job of communicating our ideas. And very often, all that people have to understand our ideas is our code.

As competitive programmers, we are told: "you should be lazy". No. Laziness is not a compulsion. It is a skill, and like any other skill, it must be used only when required. Being lazy while designing the algorithm and naming variables saves us 3 minutes of coding time and costs an additional 20 minutes through penalties/debugging. We need a better approach.

It is now time to look at the bigger picture.

Design patterns, programming principles, Github integration etc... are not core to competitive programming, but they are core to software development. And because they help abstract out complicated processes, we save time in both coding and debugging our problems. Using tools, libraries and patterns in our code when solving problems is not only easier, it helps answer all the three original questions.

1) We focus on facing the programming/mathematical challenge instead of other mundane tasks.

2) Our testing and debugging time is greatly reduced when using library functions and following coding practices.

3) We come here for a purpose. To have fun, but also to learn lots. Outside the world of competitive programming, lies that of software development. While honing the skills of algorithm design and data structure usage, we can learn how to write clean code. Writing functions that take only those parameters that they need and leave no side effects (A side effect is your brother asking you to clean the trash and you throwing away the dust bin too). Good variable naming may not be very romantic, but saves time which you can invest on the next problem.

I have summed up the above mentioned topics relevant to competitive programming into a video series. It shows how and where these practices are implemented. The topics are as follows:

1. Good Coding Practices
2. Test Case Generation
3. Fast I/O in JAVA
4. Github integration
5. Testing through multiple solvers
6. Java 8 Features
7. Multithreading

The lectures are shown below.

Although the examples are in java, the lectures are quite generic and can be applied to competitive programmers at large. Most of the series is based on my experience and observations of fellow programmers. There is lots of scope for improvement in our community, and I look forward to hearing from the all the smart folk on HackerEarth.

Thanks for reading! :-D