Yesterday's Bug#
Yesterday, I shared a bug encountered in the project in an article - after modifying the Apollo remote configuration, the modified value cannot be read in the project. Today, I asked a colleague who is responsible for encapsulating this framework in the company to help investigate. The conclusion is that there is a cache pool in a jar package that encrypts the SpringBoot configuration file application.yml in the project. The values obtained from the configuration center will be cached here first. This is why multiple modifications result in the inability to retrieve the value.
What Can We Learn in a Big Company?#
The company I am currently working for is a listed enterprise.
There are many departments within the company, and the complexity of the work processes is difficult to accept. This is my first time working in such a company, and each department within the company has its own rules for handling tasks.
Within the company, what I come into contact with the most is how to coordinate work between departments and how to get sister departments to assist in quickly solving problems (like the bug I encountered yesterday). The most common method they use is - email.
We use enterprise WeChat for communication. However, private chats often cannot solve practical problems. The most effective and simple way is email, but it needs to be copied to the leader of one's own department and the assisting department. This way, colleagues will have the motivation to handle the tasks.
Work efficiency varies from person to person. There is no specific and clear statistical requirement for the amount of code to be submitted daily within the company, and there is no very strict time limit for the development of a specific module. A "pre-production" date will be set, which I understand as the final verification before the production environment. Such rules seem very relaxed and may give people a sense of slack. However, in reality, I found that it is not the case. Of course, there will be a few employees who slack off, but most colleagues seem to be very diligent and responsible. They try their best to complete tasks quickly.
During my one year here, I have understood the business of a product, come into contact with three other products of the company, and am gradually becoming familiar with the business processes of these products. I have also learned to use the monitoring platform and data abstraction tools developed internally by the company's research institute based on open-source projects and adapted to the company's business. There are also some office technologies, such as how to reply to emails, how to handle blame-shifting messages in private chats, or how to coordinate scheduling a meeting. Ninety-five percent of what I have described, I feel is almost useless for my next company.
I have spent a lot of time learning and mastering internal tools that are not used or even exist in other places. These tools will help me complete some work in the current company, but they will not be helpful for the next job. In other words, this specific knowledge is not transferable.
Today, I happened to come across an article that also mentioned this, and I will borrow the last sentence of the article:
So, selfishly, I tend to think this way: if 90% of what I’m doing today won’t help me in the next job, then I should either reduce that 90% (for example, by focusing on general-purpose ideas, systems, abstractions, technologies), just not care as much about that 90% (as I used to), or find a job where I’m willing to sacrifice that 90% of my time because I think the cause is really important or the money is so good.