Time flies. It’s been over a year since I joined CityView. So far, it’s been one of the best decisions I have made in my life. Unless Microsoft comes up with a too good to resist offer, I don’t see myself ever leaving CityView, which could easily be the only company I ever work for. I don’t say this lightly, however. So far, I have declined fantastic potential opportunities with companies such as Amazon, in favor of CityView.
My head hurts. It’s 11 pm at night, and I just finished a 3 hour debugging marathon to fix a bug that has been on my to-do for last 2 weeks. What began as a simple list of items not showing up in the browser ended up in an ill-formatted sql caused by mis-match of enumeration in a switch statement in the deep backend. The fix involved changing a single word, but the path I had to take was treacherous and equally fulfilling. The feeling is serene.
Sometimes, we need to find out if an element is a member of a given set or not. There are many algorithms which solve this problem. However, many are not efficient for large datasets and restricted memory. A good example is a dictionary on an iPhone. While typing, the application needs to verify if the word is in the dictionary or not. The dictionary is huge, and there is just not enough RAM to hold all words. How to find out all the typos? Luckily, there’s a way.
The behavior of a complex system is often complicated. When we try to implement a complex behavior in the program, that complexity is generally not recognized at first, so the behavior is represented as a single method. Gradually that method grows and grows, gaining more lines, more parameters, and more temporary variables, until it is a monstrous mess. This post explains a few patterns to refactor complicated methods.
I have been studying Stoicism for more than 2 years now. The more I read Seneca, Marcus Aurelius and Epictetus, the more I realize how Stoic principles can be valuable when applied to programming. This post is a quick reminder to myself when I am writing software.