Many readers often ask me
What is the difference between programmers in large companies and small companies? Can programmers go to small companies?
I have worked in both large and small companies, and today I will tell you about my experience, starting with small companies.
As mentioned in the previous article, my first job was as a programmer in a small company in Beijing. There were 6 or 7 people in the whole company. At first, everyone was crowded into a room of more than ten square meters. When he left, conditions improved and he moved into a two-bedroom apartment.
There are 3 programmers in the company including me, and the others are sales. The sales go out to pick up the project, and the programmer is responsible for developing the project.
When a small company does a project, it requires you to do everything. During my more than two years in the company, several projects I participated in were completed by myself.
For example, a project I did was to build a CRM system for a mobile phone sales chain in Tianjin. Except for the outsourcing of UI, the rest of the system was done by myself. At that time, the advanced concept of front-end and back-end separation had not yet appeared. The mainstream Java, Servlet, JSP, and JS I have learned and used now, and I can still cope with it.
The company is small and there is no special test. This is actually not bad. You can develop your own test by yourself. The system is not too complicated. You can test it yourself carefully.
The most troublesome thing is to travel to Tianjin customers. From the initial research needs, to the mid-term report and presentation, to the final deployment and launch, and training for customers, I went there alone, and went back and forth many times.
Every time a client asks "Did you do this project alone?", I try to calmly say "No, we have 3 people to do it together" (this is the answer taught by the boss in advance).
We can understand the customer's question. After all, a system with a cost of 100,000 yuan only sees me every time - a young programmer who has just graduated for a year. At that time, the average house price in Beijing was less than 10,000 yuan, and this 100,000 yuan was enough for the down payment of a small-sized house.
Another problem for small companies is that they are not standardized. At the time, I didn’t know what the standardized process was. Worked on several projects and barely wrote documentation. It is too painful for some customers to design documents and user manuals. I thought it would be better for you to add a few more requirements to me.
Maybe you can't think of it at all. I didn't even use log4j and logback at that time, and I used System.out.println to solve the problem from beginning to end.
I have never heard of CodeReview and SVN, let alone used them.
In addition, taking the scale of the few people in our company as an example, we are destined to not be able to do big projects, always do small projects, and always write CRUD, which is meaningless after a long time, and the technical level has not improved much.
In those few years in the small company, although the things I did were complicated and irregular, looking back now, that experience is quite precious:
- Doing more than one person by one person really trains people.
- Work efficiently, if you have anything, you can discuss it with the boss as soon as you turn your head.
- The atmosphere is good, and everyone often goes out to eat, drink and play together. It may also be because the company has less people and less money, and there is no need to gang up to fight.
Later, with the job-hopping, I have experienced companies with hundreds, thousands, and tens of thousands of people, and then I will talk about my experience in large companies.
1.
The company is bigger, there are more people, and there are more excellent people. I met two excellent programmers in a company, and I benefited a lot from working with them. They took them to learn technology, share technology, and translate books. These were written in previous articles, so I won't repeat them here. .
All in all, they are the people who have helped me the most in my more than ten years of programming. After getting to know them, my technology started to advance by leaps and bounds.
2.
In a medium-sized company I once worked for, within a few days of joining a project team, I felt various contradictions between technology and business. For a while, the business said that the technology was misunderstood, and the developed functions were not as designed; for another time, it was the technology that the last time the business was set, it changed. It was discussed and discussed, and the project was revised repeatedly during the development. In the end, there was a problem with the launch of the project, and they blamed each other again, and a new round of dumping conferences was held.
The above situation has also occurred more or less in other project groups.
After several customer complaints, the boss couldn't sit still and hired an executive from a large company with a high salary. This executive really has the ability to force the document output of the business team and the result output of the technical team. In general, a series of process specifications are formulated and enforced.
The effect was immediate, and the company's various projects landed at a faster pace. At that time, I was still a development soldier, but the benefits were felt for myself, there were not so many meetings, and there was not so much rework.
Who knows, the good times didn't last long. After more than a year, the executives left, it is said that it was because of the factional struggle in the company.
After the executives left, the standardized implementation was no longer so effective, and slowly it became the same bad shape it used to be.
This experience left a deep impression on me, and for the first time I realized the importance of standardization.
3.
Large companies have more complex projects, and complex projects can force programmers to improve their skills.
Along the way, I found that my technical level is often forced to grow with the development of the project. In fact, many times, one's own level cannot reach the level that can successfully complete the architecture project, but one can only grit his teeth and insist, forcing himself to keep learning.
The technical level of a programmer depends on how many systems he has built, and more importantly, how many pits he has stepped on.
Just like making several single systems, it is better to make a high-concurrency and distributed system with high gold content. But I have been staying in a small company, and I don't have much contact with high concurrency. The solution to this dead end can be found in this article I wrote before: I hired a "parallel" programmer
4.
Sophisticated project enhancement techniques - this one doesn't always work either.
More than ten years ago, I participated in a project of the Shanghai Stock Exchange, which can be said to be a large and complex project.
- Large - there are hundreds of people in the whole project, which is the largest project I have ever participated in. It is estimated that this record will not be broken even when I retire.
- Complex - projects related to stocks and money, needless to say.
But what I want to say is that this project does not really help my technical growth. why?
During the development, the entire project was divided into very fine details, and each group and individual were responsible for those functions, and various specifications also set rules for everyone. For example, the log requires that debug, info, warn, and error must be in the correct format, and the input parameters, output parameters, and time consumption are strictly required to be printed out.
We joked that writing code was like sticking a matchbox. According to these matchboxes based on the documents and pictures, I don't know what kind of magnificent system can be built.
Programmers in many large companies are like screws, everyone does their part, and each person is only responsible for one piece of content. After a long time, if there is no job rotation, there will be a day of dry vomiting sooner or later.
5.
When I didn't go to a big company, I was very envious of the training provided by the big company. How good it is, the company pays for the growth of the employees.
When I first joined a large company, I found that most of the old employees were not interested in the company's training and would not go if they could. I didn't quite understand it at first.
As I participated in many trainings, I gradually became the same as those old employees.
- A lot of training has nothing to do with technology
- Some trainings can't be finished, such as OKR
- Usually work is tired enough, I can't study anymore, I want to lie down
- The training is arranged on weekends, not sincere
6.
The benefits of big companies are good, the work intensity is high, and they can gild individuals... I think everyone knows these things, and there is no need to write them.
The above is my experience and feelings in small companies and large companies.
The above are all personal experiences. The family's words may not be correct, but they do not accept refutation.
Both big companies and small companies have their own advantages and disadvantages. No matter what kind of company you are in, look at the advantages of your own company:
- Large companies are standardized and professional; small companies are flexible and efficient
- Large companies have complex projects and great challenges; small companies train programmers to be all-rounders
- Large companies have many excellent people; small companies have fewer people and less right and wrong
- Large companies have a perfect promotion mechanism; in small companies, if you have strong ability, you may be promoted quickly
Finally, if you are entering a large company for the first time, I would like to give you a few words of advice:
1. Don't ask about salary . There are not many people in the small company, and the interpersonal relationships are simple. Everyone has a lot of contacts and is familiar with each other. Sometimes they have few scruples. Large companies require employees' salaries to be kept secret, so it's better to ask less about other people's salaries. The big deal is that in the future, if you know the bottom line of good colleagues who play well, find a private place to chat and say hello.
2. Don't point fingers at established norms . After going to a big company, the various development specifications made me, a programmer in a small company accustomed to wild ways, very uncomfortable. Later, I understood that those who set the specifications in large companies of course know that the specifications will slow down the speed, but in addition to the pursuit of "fast", they pursue "stability", the quality of development, and the maintainability of the project in the future.
3. Get to know more good people . There must be my teacher in the three-way trip, not to mention that there are many excellent people in big companies themselves.
4. Don't set limits on yourself . When I first went to a big company, although there was a special test, I was used to developing my own tests in a small company, so I would test it myself before submitting the test, which not only caused less trouble for the test, but also appeared myself Code quality is high.
5. Participate in core business as much as possible . If you are involved in a non-core business, even a large company, maybe the business will be cut down one day, such as the education section of Bytes a few days ago.
And finally:
Whether you are in a large company or a small company, look at the advantages of the company. Those things that cannot be changed are useless no matter how tangled.
Adjust your mind and cherish the moment.
That's all for writing, I hope this article is helpful to you. Originality is not easy, I hope to get your support.
Hello, I'm Shimonai.
The technical director of a listed company, managing a technical team of more than 100 people.
I went from a non-computer graduate to a programmer, working hard and growing all the way.
I will write my own growth story into articles, boring technical articles into stories.
Welcome to pay attention to my official account. After following, you can receive high concurrency and algorithm learning materials.
