What I Learned This Week (Week 38/2013)

Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.

First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.

Second, I want to share my findings with you. I hope that you can use some of them in your daily work.

Let’s get started and find out what I learned in week 38.

What I Learned in Week 38

First, Email is not a good a good way to spread information. Using it for this purpose has three problems:

1. The information is spread only to those people who receive the email. This might feel obvious but my experience has taught to me that many people don’t understand this.
2. Even if all the required people receive the information, the problem is that people who might need it in the future have no access to it.
3. Writing good emails (and documents) takes a lot of time. This might not be worth the effort because the information is not spread to everyone who needs it.

It is clear that we have to find a better way to spread information in a such way that is serves our current (and future) needs. This week I realized that I had stopped following a method which I had found useful in the past. I decided to start using this method once again.

This method consists of two steps:

1. When something is asked for the first name, I make a mental note about this and answer by using email.
2. When the same thing is asked for the second time, I document the answer to the project's wiki and send a link to the appropriate wiki page.

When I follow this method, I can recognize the information which is relevant (asked more than once), and ensure that this information is available to everyone who might need it.

Second, Profile all code which use database before you commit it. This might seem like an overkill but if you are using ORM, this will help you to spot performance problems as soon as possible (before it will be a problem).

The problem of ORM frameworks is that they are very complex beasts and it is very easy to shoot yourself to the foot. You might feel that the performance of your application is great because everything works just fine in your development environment.

Don't trust this feeling. Start your profiler and ensure that that everything really works as expected. If everything is fine, this doesn’t take more than a few minutes of your time. On the other hand, if you find a problem, you can congratulate yourself for a job well done.

Third, Monitor the performance of your application in the production environment. Production data has a life of its own, and it is very hard (or impossible) to try to generate similar data to your development environment. This means that even though you do your best to eliminate performance problems, you might still find performance problems from the production environment.

That is why you should constantly monitor the performance of your production environment because this will help you catch potential performance bottlenecks as soon as possible. This is important because it gives you some time to fix the problem before shit hits the fan.

I can recommend a tool called New Relic. It has a great monitoring tools for web applications, and it has helped us to spot potential performance problems before they become a PROBLEM.

Fourth, You can whine about your current situation or concentrate on things you can change. I started recently adding new features to an existing single page web application. Although I have implemented small single page web applications before, this was the first time when I was working on a real life Javascript web application.

PERKELE! What on earth is going on here.

That was my first thought when I saw the source code. That was also my second thought. And third. I was pretty frustrated and I let everyone know about it (sorry guys).

When I left from work that day I was pretty pissed off. Luckily it was my gym day. When I lifted some weights I realized that I had two options:

1. Continue whining and get nothing done.
2. Learn the skills I need to get the job done.

It was pretty clear that the only viable option was the second one. So, what did I do?

1. When went back to work the following day, I decided that I will figure this code out even if it kills me (I have a pretty hard head). So I started reading through the source code, and it started make sense to me. I got a lot of help from my colleagues as well (thanks guys), and I was able to make the first big change to the application. It felt great!
2. I also got a copy of Developing Backbone.js Applications by Addy Osmani. I hope that it will help me to really understand how Backbone.js applications are build.

What was the lesson I learned from all this?

Don't give up. There is always something you can do to get the job done. You just have to find it first.

Fifth, I though that I know Javascript. In reality, I know jQuery. I think that this is not a very uncommon situation, especially amongst “enterprise developers”. It was clear that I should learn Javascript, but it was unclear what was the best way to do this.

I have read Javascript: The Good Parts and I think that it is great book. However, it is not a good book if you want to learn Javascript.

I got a copy of the Javascript Enlightenment and hope that it will help me to understand the inner workings of Javascript. I know that it will not make me a Javascript expert but it is a good start.

If you know other books or resources which could be useful to me, help me out by leaving a comment to this blog post. Thanks!

What Did You Learn This Week?

Share your learning experiences or other comments on the comment section.