Performance of applications I write was always something I deeply cared about. I’m talking about using as few resources as possible, but of course not in the detriment of other important things. Teams often neglect this and take action only when there is a perceivable performance issue.

When is the right time to optimize?

I would say it always need to be on your mind, but before you wrap up the project it is always good to tighten the screws and optimize what you can.

Decisions around your data model will have a big impact on performance and it is very hard to change at the end phase of a project. This is the reason why I say, you need to be mindful about performance all the time.

In the last sprints of the project, most of the important flows are already there. You understand the application a lot better then you did in the beginning. Since everything is there this period is a good opportunity to poke around and see how some important flows perform. Also you are in a better position to form and educated opinion whether something needs improvement or not.

What are code reviews?

Code review is a very common and important process throughout development phase where code developed by individuals gets peer reviews in order to improve the overall quality of the source code.

Is there a problem with this practice?

Not per se, I’ve seen it poorly implemented too many times. Close your eyes and imagine you are sitting in a kickoff meeting and you hear something along this line. Usually from a very eager, but inexperienced team leader.

“I would like that every line of code to be reviewed by the entire team. Everybody makes mistakes, even senior developers do, and even junior developers can have valuable feedback, so everybody should participate in reviewing.”

Don’t get me wrong, I like this way of thinking. It comes from a very noble place. Unfortunately when put in practice with a mid-size team, you will see some shortcomings surface.

It always amuses me how movies depict people who work in the IT industry. In general they show somebody who is a technical genius but socially very awkward, or they are a hacker underground magician who can break into any complex system just by typing very fast. Just think about Internship, Silicon Valley, The Social Network, etc. While there are people who are like that, in my opinion somebody who has a long and successful career in IT probably also have very strong communication skills.

Think about it, we work in teams and our daily work depends on others, most of the applications that you hold dear were done by a handful of dedicated individuals who knew how to work together to reach a common goal. Let’s go through a few non-technical activities in the order in which you generally start doing them.

I know that nowadays this doesn’t seem anything special, but long ago I started to work on a project, which I deemed impossible, not worth to try, and I could have bet against its success. It wasn’t that long ago, but instead of just simply giving you the year it will be more fun to remember some facts, so let’s see if you can set your time machine correctly.

• Robert Downey Jr escaped from a cave in an Iron Suit
• We came out of Vault 101, got scared walking on USG Ishimura, and explored the universe on a ship called Normandy.
• People were jamming in their cars singing “Pa Pa Poker Face …”
• Smartphones just started to become a thing
• You still had a chance to buy something called “Zune”
• We were slowly moving to 16:9 screens from 4:3
• Facebook celebrated its 100 million active users
• Michael Jackson was still bla…, just kidding just kidding he wasn’t
• We learned that the burst of some bubbles are not fun for anybody

See what I mean? It feels very long ago doesn’t it?