Code complexity is a subject that is taught early on in Computer Science curricula. Not sure if early is the reason why many software developers tend to forget what it is and how to apply it.
Last week a group of developers were talking about the complexity of algorithms and Big O Notation came up. As a matter of fact when considering complexity there are:
| Theta notation |
| Big O notation |
| Omega notation |
The theta notation bounds a function from above and below, so it defines exact asymptotic behavior. The Big O notation defines an upper bound of an algorithm; it bounds a function only from above. Just as Big O notation provides an asymptotic upper bound on a function, Ω notation provides an asymptotic lower bound.
Every year I purchase (typically through Amazon Prime) and read a couple
dozen technical books. If something calls my attention, I spend a few days experimenting with a particular subject. If you really want to learn something, reading tends to fall short. You need to get your hands dirty to reach a full understanding on most technical subjects.
The side picture captured with my phone shows the three books I have next to me when I work at home. My first approach is to look up the subject on Google. If I need to go deeper, typically find algorithms information in one of the previously mentioned books. In particular the “Art of Computer Programming” set is my second copy. In one office move I lost my first copy which I purchased a long time ago. My current copy was purchased in 2010. I can tell when I purchase every book because I write my name and the year of purchase on the first page.
A week or so ago I read the post Let’s simplify algorithm complexities! by Shruti Tanwar on Medium in which the author touches on algorithm complexity.
Depending on what I am doing, occasionally I ran into the need to analyze an algorithm to determine if and how it could be optimized. I do not learn by hard a set of topics. I believe that is a waste of time. I work around nine hours a day and spend a couple hours of my own time learning something new or relearning something that, with time, has faded but for one reason or another my interest was piqued.
For algorithms I typically consult the following books which sit on one of my pedestal computers in my home office. In no particular order:
| Introduction to Algorithms | Thomas Cormen, Charles Leiserson, Ronald Rivest and Clifford Stein |
| Algorithms Fourth Edition | Robert Sedgewick & Kevin Wayne |
| The Art of Computer Programming | Donald E. Knuth |
For a good introduction to the subject of notations chapter 3 “Growth of Functions” in “Introduction to Algorithms” covers the three types of notation.
During the same conversation last week, the way to generate prime numbers came up. At the time I did not have access to a computer, but I immediately recalled the Sieve of Eratosthenes to compute prime numbers. I have read about it and spent time studying the algorithm. If you are interested in it I have a post in this blog Prime Numbers that I wrote in December 27, 2016. It includes Java code to generate prime numbers and has some timing information which is always needed when experimenting with algorithmic performance.
Every time someone comes up with the subject of algorithmic performance I recall the advice of Robert Sedgewick and Kevin Wayne regarding this subject. You can spend time coming up with a good algorithm to apply to a specific task (e.g., generating prime numbers) which includes development, testing and peer review; or you can use one of the best existing algorithms for the task at hand.
I spent time working with encryption so I am somewhat familiar with prime numbers and pseudo random number generators. This is why when someone mentions prime numbers the Sieve of Eratosthenes algorithm comes to mind. That does not mean that I have memorized the algorithm. I recall its name and I have used it several times (see the Prime Numbers post in this blog). If a real world situation comes up regarding the 
generation of prime numbers I do not have to spend time looking for an algorithm, getting familiar or writing the code from scratch. I can go and quickly look it up and deploy a solution a lot faster than a person that has never heard of it. Generating prime numbers is not something that you learn on every single software development job. It depends on the type of work you do. That is why it is so important to spend every single day a couple hours on something new that is not directly related to your regular job. I have been doing this for a while. Give it a try. You will be surprised how new things tend to align with previous subjects and the ease they come up when dealing with challenges at work.
If you have comments or questions regarding this or any other post in this blog, please leave me a message or if you prefer send me a message via email. I try to spend a couple hours every day learning, experimenting and posting in this blog.
Enjoy;
John
john.canessa@gmail.com
@john_canessa