Conclusion

◀ Resources Amazon You have learned a lot. A conclusion you can probably draw from how to write a program efficiently is that there are no rigid rules to follow; everything is flexible.

For example, small code size of a function is not necessarily good because a recursive function, while usually taking fewer lines of code, could have an incredibly big time complexity as opposed to a non-recursive function.

There is almost always tradeoff between two approaches, and you are the one who should decide which one better fits your requirements and the situation.

Based on experimentation, I have found that very often a hybrid approach is the best approach to solve a large-scale problem. You should be aware that no single approach is worth sticking to forever.
For example, I wrote a program to find two points that has the shortest distance many points on a two-dimensional plane. The simple and obvious way to do this is to compare every single pair of points and see which one has the shortest distance. The time complexity, N being the number of points, is theta(N2).

However, I used divide-and-conquer approach and achieved theta(NlogN). I thought this approach is a lot better than total brute force, but to my surprise, brute force works better with a small set of points. It turns out that using divide-and-conquer approach until seven points, then using brute force gives the best run time.

“A little knowledge is a dangerous thing.” As much cliche sounding as it is, there is evident and time honored truth in it. You need to acquire many tools and be selective in choosing which ones to use in a particular situation. Software engineers tend to write functions on their own while overlooking what they are already provided with.

Therefore, my final word of advice to you is “Broaden your horizons and be flexible.”

The average person has 2.6 million sweat glands in his skin.
◀ Resources