What I Learned This Week (Week 46/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 46.

What I Learned in Week 46

First, Challenge yourself every day.

I started writing this learning diary because I wanted to keep track of my personal development. To be more specific, I wanted to find out if I am really learning new things on a regular basis. I was thinking that I do, but at the same time I suspected that it might not be true.

And guess what? I was right!

There has been weeks when writing this learning diary has taken a considerable amount of time. I think that this means I haven't pushed myself hard enough.

Learning is a continuous process which never stops. However, since we (hopefully) have other things in our life than just work, it is so easy to "stop" learning.

We go to work. We code. After work we get back to our regular lives. Heck, we will probably even get promoted and gain some authority. And yet, we have no idea what we are doing. We have become expert beginners.

I don't know about you but I don’t want to remembered as the guy who was able to draw beautiful diagrams but had no idea how software is really written.

That is why it is a good thing that this diary reminds me to challenge myself every day.

Should you start writing a learning diary too?

Second, Fix your code one step at a time.

If you have been working on the same project for several years or you just got started maintaining an existing project, parts of the codebase (or the whole codebase) might be a mess. If this happens, you have got two options:

  1. You can continue hacking and hoping that your changes won't break anything.
  2. You can make the codebase better one step at a time.

It is so easy to select the first option. After all, if you have to make only a small change, it doesn't make any sense to do any other changes to the code. Right?


If you make make the change which you need to do and clean up the code around it, you probably won't see the difference. The codebase still looks messy and weird. However, if you continue cleaning up the code when you make changes to it, you will eventually see the difference.

A long software project is not a 100-metre dash. It is more like a marathon. It takes patience and willpower to keep going forward in the best possible way.

If you go too fast, you never finish it. If you go to slow, you run out of time.

These rules apply to software projects as well. If you keep on hacking, your codebase will be unmaintainable pile of shit. If you make your codebase better one step at a time, you will end up with a codebase which has its problems, but you can still be proud of it.

Third, Bootstrap is nice but you have to beware of technical debt.

It is no secret that I am not a great frontend developer. That is why I love Bootstrap. I can create "good looking" and responsive layouts without bothering my web designer friends. I felt that Bootstrap is a perfect solution to my problems.

As usual, I found out that this is not entirely true.

I am not going to trick you to believe that I figured out what the problems of using Bootstrap are. If you are interested to find this out, read the blog post titled Bootstrap without all the debt.

Fourth, ID lists aren't the best solution for the N+1 problem.

I have noticed that enterprise applications often use the following "pattern":

  1. Fetch a list of ids.
  2. Fetch the actual entities by using the id list.

I have always thought that this might not be best the solution. I kept asking myself why I would want to use two (or more) SQL queries instead of a single SQL query, and I couldn’t answer to that question.

Then I decided to ask this question from my Twitter followers, and I got some interesting answers.

Then I received the "definitive" answer. If you want to find it out, read the blog post titled ID Lists Aren’t the Best Solution for the N+1 Problem.

Fifth, No one cares about you (expect your mother of course).

That phrase is pretty popular amongst internet marketers, and I have always thought that there is no truth in it. One reason for this is that internet marketers have a pretty shady reputation. In other words, I thought that they are either spammers or scammers (or both).

However, this week I saw the light (so to speak). I am planning to change the look and feel of my website and during this process I decided to create a new "mission statement" for my website. When I read some tutorials about it, I realized that a person can end up to my website in three ways:

  • He uses Google.
  • He notices an interesting link from a social media service and clicks it.
  • He has subscribed my RSS feed.

If we think about these options, it is clear that the person who has subscribed my RSS feed has already figured out that my content is worth reading. On the other hand, if the person ended to my website from the search results or from a social media service, he hasn't made this decision yet.

He isn't interested to know who I am. He is interested to know how I can help him.

That is nice what has this got to do with software development?

Quite a lot actually.

You cannot sell software development by telling who you are. You sell it by describing how you can help your customer.

You don’t get a job by telling potential employers who you are. You get it by telling how you can help them out.

Got the clue?

What Did You Learn This Week?

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

0 comments… add one

Leave a Reply