The other end of the telescope

Revision en8, by gkcs, 2015-09-30 07:22:14

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.

Good Coding Practices for Competitive Programming

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

Tags coding practices, competitions, java, youtube

History

 
 
 
 
Revisions
 
 
  Rev. Lang. By When Δ Comment
en30 English gkcs 2018-02-21 10:42:03 0 (published)
en29 English gkcs 2018-02-21 10:41:26 60
en28 English gkcs 2018-02-21 10:40:58 21 (saved to drafts)
en27 English gkcs 2016-03-04 07:52:23 11 Tiny change: 'topics are as follows:\n\n<ol>\' -> 'topics are:\n\n<ol>\'
en26 English gkcs 2015-11-02 22:59:32 0 (published)
en25 English gkcs 2015-11-02 22:59:10 2 Tiny change: 'i> Github integration' -> 'i> Github Integration' (saved to drafts)
en24 English gkcs 2015-10-22 23:04:08 4 Tiny change: 'ading! :-D' -> 'ading! :-D\n\n'
en23 English gkcs 2015-10-22 23:03:42 278
en22 English gkcs 2015-10-22 23:01:34 0 (published)
en21 English gkcs 2015-10-22 23:01:13 278 (saved to drafts)
en20 English gkcs 2015-10-17 11:30:06 0 (published)
en19 English gkcs 2015-10-17 11:29:45 24 Tiny change: 'elow.\n\n[Good Coding Practices for Com' -> 'elow.\n\n[Software principles for Com' (saved to drafts)
en18 English gkcs 2015-10-04 22:02:13 0 (published)
en17 English gkcs 2015-10-04 22:01:57 11 Tiny change: 's, we are told: "you should ' -> 's, we are advised: "You should ' (saved to drafts)
en16 English gkcs 2015-10-01 22:32:26 0 (published)
en15 English gkcs 2015-10-01 22:31:51 6 Tiny change: 'e list is below.\n\' -> 'e list is shown below.\n\' (saved to drafts)
en14 English gkcs 2015-10-01 06:05:28 0 (published)
en13 English gkcs 2015-10-01 06:05:15 13 Tiny change: 'he lectures are shown below.\n\' -> 'he lecture list is below.\n\' (saved to drafts)
en12 English gkcs 2015-09-30 07:26:47 0 (published)
en11 English gkcs 2015-09-30 07:26:33 20 (saved to drafts)
en10 English gkcs 2015-09-30 07:25:07 0 (published)
en9 English gkcs 2015-09-30 07:24:51 17 Tiny change: 't folk on HackerEarth. \n\nT' -> 't folk on Codeforces. \n\nT' (saved to drafts)
en8 English gkcs 2015-09-30 07:22:14 0 (published)
en7 English gkcs 2015-09-30 07:21:59 85
en6 English gkcs 2015-09-30 07:21:39 167
en5 English gkcs 2015-09-30 07:18:04 112 Tiny change: 'der="0" align="middle" allowful' -> 'der="0" allowful' (saved to drafts)
en4 English gkcs 2015-09-30 07:10:24 0 (published)
en3 English gkcs 2015-09-30 07:09:43 127 (saved to drafts)
en2 English gkcs 2015-09-30 07:06:05 0 (published)
en1 English gkcs 2015-09-30 07:05:27 4789 Initial revision (saved to drafts)