2012, a journey to the software workplace

2012 is a special year. In 2012, there is the legendary end of the world, and the increasingly fierce competition in the IT, mobile, and Internet fields has evolved.

In the first half of 2012, I was a graduate student. In the second half of, I became a member of the software development industry. When I was still at school, I especially wanted to know how the real software development environment looked like. It was a mysterious place. As soon as I went into school, I began to have a real experience.


In February July, less than 10 days after entering the company, the company undertook the first task: developing programs or tools to complete the data correction required by the project. The boss said, I can select Java or Python. Eventually I chose Python and use the recommended web. py framework. Because, I think Java may be very troublesome to do this job, and it is not as convenient as Python. From the project perspective, this is actually a simple technical model selection. Of course, this choice is actually risky, because I learned and used it; however, there are bosses and colleagues familiar with Python who do code review, which reduces the risk. There are three most impressive points in this project:

1. demand changes are very frequent, and communication needs are very close. Multiple teams are required to work closely together. There are new and changed requirements almost every day. There are interactions and project progress follow-up from various teams in the mail every day. The company is a small team. Each team has a minimum of 10 employees and is responsible for a sub-system. I think this is the real software development environment and the challenges to be faced. Requirement mining and management, project management, and team collaboration communication are worth exploring carefully as a subject.

2. The greatest danger lies in the most inconspicuous place. Development programs must consider the real environment. In the logic of data correction, there is a complicated logic, so it takes a lot of time and effort to ensure correctness. However, the logic of a table is very simple, therefore, the SQL statements that seem to be very ordinary are used. The results are troublesome: the performance of the real environment is not considered, and the efficiency is very low, so I almost gave up the release plan.

3. Your own growth is inseparable from support and encouragement from the boss and work partners. It was with the support and inclusiveness of all working partners that the first task was successfully completed with the support and support of the boss and their own efforts. I am very grateful. Therefore, it is important to maintain a good relationship with our partners.

For more information about this project release, see my blog: first project release experience. This is not detailed here.


Next, I went to another subsidiary of the company to pick up a project. In addition to SSH, I also used flex technology. One thing I learned this time is that to do good things, you must first sharpen your tools. Initially, the deployment of flex thermal debugging seems cumbersome, so I will ignore it for the moment and focus on business learning and project taking over. As a result, the entire flex project must be compiled for every small flex change. Although the script is compiled to complete automatic compilation and deployment, you can do other things during compilation and deployment, but the root problem remains unsolved. In general, it takes a lot of time. As a result, I finally had to learn about the hot deployment of the Flex project, which made the flex Development feel a sigh of relief. Conclusion: Before starting a project, you must deploy the project for hot debugging in advance. So far, I have been taking over this project for four months. I have basically been able to develop relevant requirements and have also made some basic thoughts. For more information, see the blog post: How to build software.

The two projects that I took over need to learn new languages and new technologies. I think this is nothing new. However, I want to propose my own Development Learning Philosophy: people with more than two years of development project experience should pay more attention to understanding, rather than indulge in learning a certain technology. Understanding the nature of development activities, the nature of development technology, can bypass the analogy, rather than learning to use one. In addition, programmers try to explore a wider range of technical fields and accept new technologies and fields, rather than sticking to a single technical field. Be good at attention and dare to give up. Every discard is a leap.

My boss also gave me two pieces of advice. For the first time, he pointed out that I paid too much attention to technology rather than business learning. I think this is also a common problem for many technical personnel. We dream of becoming a System Architect rather than a business expert. In fact, from the perspective of social needs and career promotion, business is the key, not technology. Technology is only a means to provide value for the business, and products are the specific implementation form of the business. The second time, he probably saw that I was too addicted to fulfilling my needs and had too little intersection with my colleagues. He told me that a person must have his own expertise and have his own unique values, when it comes to something, you are the first thing people think. This is also a good piece of advice. You don't have to be good at exaggerating your work, but you also need to show your work in a proper amount; you need to have your own expertise, and you can do nothing at all. We need to go deep into the core of things, rather than understanding and using things on the surface.

 

It is necessary to cut down learning projects, contract the front, concentrate on solving certain sub-themes, and establish their own expertise and competitive advantages;

Learn and study things with the way and mentality of exploration, and go deep into the core and essence of things.

In addition to code, programmers must also face their own future and emotional problems. Therefore, during this period, I thought more about my career and technological development path, and adjusted my life attitude, instead of putting myself into technology learning. Direction is a prerequisite for hard work. Programmers need to persistently read and learn to learn knowledge and inspiration, exercise to ensure sustainable and long-term development, and communicate with others to make friends with like-minded people, it is necessary to expand your perspective and knowledge by extensively covering various fields of information, and to carry out serious self-reflection to solve your own emotional problems. It is summarized into five words: Reading, sports, communication, information, and introspection. A real man must be able to solve his or her own problems, rather than spending time idle. Application developers are keen on familiarizing themselves with and using various development frameworks, but have you ever wondered how to develop a rational and scalable framework for your own life, career, and emotional development?

In general, I think my internal thinking is quite adequate, but I am not paying enough attention to it. I personally think that people seem to be too concerned about technological innovation and competition for IT products. Although technology can bring convenience to people's lives, it is only convenient. There is no technology capable of solving this fundamental problem. From the perspective of outsiders, we feel that people are paying attention to the root cause, or people have long realized that they cannot solve this fundamental problem, just as the Turing shutdown proves, I had to turn my eyes on the complex outside world?


The end of 2012 is over. I wish all developers the hope of the New Year ~~~ Wish your dreams come true ~~~

2012, a journey to the software workplace