Since 4th, January, I have worked in Microsoft as an intern for nearly two months. During the period, I really learned a lot from my colleague so that I want to record them here.
Do exactly what the project supposes you to do
The first lesson from Microsoft is soon after my on-boarding.
I was asked to develop a tool to automatically create an request for submitting deep-learning tasks. The work itself is not complex,which could be considered as a map from one thing to another thing.
The point is to avoid hard code. Obviously, it's not a good choice to write everything in the code such as if(a = "something") b = "another thing";.
For me it's not difficult to find a way to avoid hard code. I thought about three ways to solve this.
Save the mapping data as tables in database and pull them when doing the job.
Save the mapping data as local files such as json and read them in the program.
Write the mapping rules as dynamic libraries and hot-load them.
Well, my final decision is the second one because the first one is related to database and the third one is unworthy. I could format and save data in local first and move them to database at last.
Then, I began to walk into a wrong way. I thought that it's better to add new mapping rules without recompiling and restarting. To realize this, I need to abstract the rule and allow others to make a new rule. Then I need to make a cache to update the rules in the RAM. Moreover, I even wanted to make a simple board for visualization of adding and removing rules.
The point is that I was too ambitious and arrogant. I wanted to show my ability to my colleagues. However, These things are not necessary for the project. The rules are relatively fixed and the people to maintain the system are all developers instead of users. Besides, it's front-end engineer's work to make a board.
I wrote some code and abstract the rule in one week, but the performance was discouraging. My code worked like a machine from last century. It could do the job but sometimes not work. Even when it worked, others may worry that it will fall to pieces in the next minute.
My mentor had a talk with me after reading my code. He asked me to look down and just see what is next to my feet first. He told me that our goal is to satisfy the requirement rather than make a perfect program. I thought a lot about extensibility without stopping and think carefully if it is really needed.
Finally, my mentor asked me just to write the interfaces of this tool first and consider about if the interfaces are reasonable. In this way, my code could work well and not bloated.
Structure first, details last
Another mistake I made is concentrating on details too early. I wanted to make my code worked well as soon as possible. However, details could make your eyes just gazing at stones beside you.
Each time I saw that adding or modifying some code could make the request created by my code works, I immediately did it. However, when the modification accumulated, I found that it's hard to satisfy new requirement. The structure of my code became stiff.
The right way to develop is to have more consideration about the structure each time you want to add a new feature. Though it cost you more time, you save the time of reconstructing your code.
Do not use virtual if you are not sure
During the coding, I worried that someone else may want to have a different implemention for an method. So I use virtual to decorate the method while no derived class in my code overriding it.
My colleague asked me to remove virtual when he reviewed my code. He said that when you don't really need to override it, do not add virtual. The usage of the class I wrote didn't include asking users to give there own implemention. Though it may need to be overrided in the future, its possibility is not big.
Adding virtual could bring in a little loss of speed, but I think this could be ignored. The point is that the signature of a method transfers information to users, telling them what the method does and what they are supposed to do. If I use virtual in wrong place, it may mislead the user of my code.
Use good names rather than comments
What shocked me when I read the source code of the project first is that there was nearly no comment! In the past, I thought that a good developer should not be too lazy to write comments because comments make the code easier to understand.
However, in Microsoft, they cooperate well without comment!
I think it should thank to the good names of classes, variables, interfaces, methods and so on. The names they made were obviously well thought out. The names could describe the usage well so that it is easy for others to read and understand.
Pay attention to test cases
My code have once annoyed one of my colleagues. He needed to work based on my code but he found there was a BUG which could be avoided.
The problem is that I didn't have enough test cases to cover all the possibility before I commited my code. So I made a mistake in my code and cost my colleague's time.
Here I realized that I was in a cooperation. I should take the responsibility because my mistakes may trouble others.
Blance your work and life
The last important lesson is slowing down and thinking more. In microsoft, my mentor never gave me a deadline. As long as I have progress every day, it is completely okay! I work from 10:30 AM to 7:00 PM. And if I'd like, I could choose the timeline by myself. Such circumstance motivates me to think more and improve myself.