10 Things I learned from being Software Engineer for 5years

It was 5 years pass since I graduated from university. Now, it’s a good time to review what I learned for many years.

I saw many bad things and good things from being a freelancer, an employee in a small company, and 3 big companies. I developed both project base and own product base. I worked for both international company, multi-national company, and the local company. These are some experience I learned from being a software engineer, software developer, and freelancer.

1. Basic of computer science is the most important

Since the internet is everywhere in this world. Everything is a lot faster than it used to. It causes many people be impetuous. They want to get a lot of money in the short time. They want to do many things fast. So does the software development.

I used to read a lot of code from many developers. Some are copied from ` stackoverflow, some follow the tutorial. Some created a form for the inputs from user, then they save into database. They didn’t protect important user data. Many use too much if/else. When the system slow, they optimize the code rather than change the appropriate data structure or the design.

Finally, the software were so fragile, unstable, unreliable. Even somebody use the sophisticated technologies. Since everybody has different skills level, some are genius, but some are just ordinary. As long as you have to work together, you ought to understand this fact. You ought to use the basic so that everybody could understand, or not be too difficult to learn in short time.

2. Use framework to control the flow

I prefer to work in the project which use a framework. The advantage of using this is the team understand the same flow, implementation, and pattern. Since there are so many ways to implement, without the framework, everything will be so chaotic. On the other hand, framework helps the team work together in the same way.

3. New technologies are not always better than the old one.

I think it’s a good idea to learn new technologies to have new ideas. Then, adapt it. There are a lot of new technology in the world but only a few ones will survive. In addition, there are only a few survive ones are good. You need some experiences to distinguish between the good and bad one. Don’t waste your time to learn every new ones. Just only some you need are enough.

4. Each technology had been invented to solve some problems, use it correctly

When you start a project, there are so many technologies in the list, and you need to select some of them. If you select because it’s easy and help you finish project fast, please make sure that the technology was invented to solve that problem.

I used to work in a project that the CTO decided to use the Neo4j graph database. The (weird) reason was he had wanted to use relational database but the data was schemaless. So he decided to use this technology because it’s similar to relational database and it’s the NoSQL.

When the project started, everything was so easy. After 2 months passed, the project was bigger than we thought, along with the wrong technology. Finally, we could not carry on the project anymore, the customers didn’t satisfied, and the project failed.

5. Avoid using a lot of technologies in the same project

Learning curve is one of the problem for developers. Using a lot of technology causes new developers need to spend a lot of time to learn all those stuff.

A lot of technology can cause the incompatible problem between 2 technologies. The important thing is You don't know what you don't know. Sometimes, you need to spend a lot of time to investigate the bugs. Finally, you found out that it came from the other technology, not from your code. Then, you had 2 choices. First, you wished someone would fix it. The other one is you changed to use other technology. Finally, you end up with the regression test which cause a lot of time.

You might think that using a lot of technology can speed up your productivity. Unfortunately, from my experiences it’s the root of evil. It helps the team to start the project quickly, but slow down velocity later on. Finally, it becomes an enormous obstacles. If you don’t have a lot of genius in your team, avoid it. I saw many project failed because of this.

6. Data structure is the good performance, not optimization

Have you ever tried to find the way to improve the system performance? I always see developers spend their time to optimize the code. Then, the result just a bit faster than before, and the high code complexity altogether. It doesn’t have any significant at all. On the other hand, if you change the design, the data structure, the speed will be a lot faster. What would happen if you can improve the O(n²) to O(nlg(n))? The answer is here.

Now you understand that the good design and data structure can improve a lot of performance.

7. Configuration make your system be more flexible

Whenever I start my project, I create the configuration first because changing the code can affect some other part. Starting from configuration helps me to focus on What to do, not How to do. When I know what I need to do, I can see the whole part of the system rather than spend time to focus on a small part by coding. Finally, I can design the system easily because I know that which part will be changed in the future. Besides, I can separate the business in the configuration, and the code will have only logic.

On the other hand, when I worked for the companies, many of them didn’t have any configuration design. They start design the database, use the framework, then implement the system immediately. The code from this practice makes them use a lot of if/else statement. Finally, when they want to add or change some part, I need to change at the coding level.

8. Write the document, not comment

Could you differentiate between document and comment? The document helps you understand what does it do?, while the comment helps you to understand the code. For example, if you have a function to check the prime number

/**
 * @return true if the number greater than 1 that has no positive 
 * divisors other than 1 and itself, false otherwise
 */
boolean isPrime(int number){
    if(number < 2) return false;
    if(number == 2) return true;
    if(number % 2 == 0) return false;
    /* 
     * try to modulo the number using the odd number until reach 
     * the square root of the number, since the number could come 
     * from the multiplication between the same numbers (49 = 7x7)
     */
    for(int i=3; (i*i) <= number; i+=2){
        if(number % i == 0) return false;
    }
    return true;
}

From the code above, the message above the function name is document, while the message above for loop is comment.

Misleading comments are usually found if you write the code and comment, then someone else modified only the code, or even the programmers themselves write the wrong comment. Then, your team has to spend a lot of effort to find the bugs

9. Database is a bottleneck of the system, don’t use it too much

I always see the overuse database from many projects. The same data is always be queried for many requests. Even the data that rarely and never change like province, zipcode, choices, etc. It’s not a good idea to let the database queries the same data every time. It doesn’t matter how fast the query you have. Not even if you use Oracle, DB2, or SSD. It’s always slower than the memory, and waste a lot of memory due to the same data store in the memory during the query time. Why don’t you load those stuff into the memory?

What would happen if the server cannot response quickly? Let’s assume if there are 100 users simultaneously send the request to the server. Then, it queries the same data for all of them, it causes users wait for the long time. So, they press the refresh button again to send those request to the server again along with the new request from new users. Now, the server has to process the old request, and the new one altogether. Finally, the server down because of not enough memory.

10. Focus on quality, not quantity

I used to work for a project that the customers wanted to launch lots of features quickly. They focused on the competition between them and their rivals, not the users. They didn’t care the quality much as long as they launched the project in time. Many features never used, many were rejected during the development. They wasted lots of money, time, etc. Finally, the project failed because only few people use it. Even the developers don’t want to use it.