Written on the first day of winter-a female programmer's work summary for the seventh year

The weather seems very warm this year. Although it is already winter, we are still in autumn.

 

This is the seventh year of my work. If I have a feeling, it's just seven years. If you make a summary every year in your feelings, isn't there any legendary hurdle.

My company is not big, and the place is not big. I don't know much about it, and I don't have enough depth. I have to admit that I am a fool and a lazy guy. This article is just a summary of my work in the past year. If you are a young man with an ideal or ambition, you should read a negative textbook and spur yourself to work harder. In addition, my current state of mind is also my experience after so many years of work. Read the previous summary and you may find a resonance there.

 

1 individual Technology

In the first two years of my graduation, I felt that the technology was going up and there were a lot of things, and then it was slow to crawl in a few years. One is that the nature of my work is that I did not discuss any profound technical points in my application, and the other was that I was too lazy to take advantage of time to enrich myself.

The popularity of 64bit this year, the survival of AutoCAD began to abandon the ancient VB6, the labor market, and other reasons that I had to grasp the new technology. Some technical points, such as the spatial part of SQL Server, introduce the GIS Theoretical Algorithm to my application field, and redesign existing systems using the. NET class of AutoCAD. LINQ, C # multithreading, and beautiful UI for compiling WPF. Learning new technologies is a process of enjoyment, and you feel that you are starting to keep up with the pace of the times. Of course, if the project time is tight, there will also be pressure. I always feel that the development time has been greatly increased by using the original technology for a short time. Compared with the previous system study, I had to be more sedated this time. Although I have not made any technical advances in the past few years, the basic skills have become more solid, I don't know where to start from. This time, I felt a lot better when I learned it in a step-by-step manner.

 

The learning and application of technical points not only improves my personal abilities, but also helps the software re-architecture to a great extent. Thanks to the conversion of the platform, we have the opportunity to re-analyze and design the original system. I used to be a complete implementer, but now I am playing more of a designer. This shift in roles means greater responsibility. If something goes wrong, it is not a waste of time but a waste of team resources as a whole. When I wrote a summary last year, I was looking for the software design suggestions. This year, the system looked at the UML and design patterns. It is not easy to understand the theory and use it flexibly. My practice is to select a relatively independent sub-system from a large system, build a design based on the learned theory, think about another one, and discuss it with the group to find the feeling. In this process, I rely heavily on mindmap, flowchar, and UML.
The initial draft is mindmap that segments the requirements and then UML establishes the relationship between blocks. UML is a good thing. Although its various specifications increase the proportion of design in the software life cycle, its considerations for details are very good. If I can picture the class diagram and sequence of the software, it will basically prove that I want to understand it, and I can also explain it to other members. In terms of design, I usually focus on readability from the business logic, or the structure is more in line with the human brain logic. The distribution of some functions and classes does not seem so smooth unless it is very efficient. At this time, relevant documents must be provided. Most of the reasons for this layer come from poor self-confidence. without the support of these chart documents, I am not sure whether I can clearly and accurately convey the meaning to other members of the team, of course, it cannot be guaranteed that you will not forget it after a period of time. At present, I am still struggling. I really hope that one day I will be able to use UML tools to become a qualified software architect.

 

For me, the architecture process is a process that challenges my decision-making ability. After all, software has a life, and it continues to grow and improve, or some parts will be removed in the near future. I can't see it that far. The design time is too long to affect the project progress and can only compromise the balance. Implementation is the same. The same function can be implemented in different ways. Balance and game are beyond the capabilities of software design and implementation, that is, the old saying goes, experience. I am still very young in this regard.

 

2. Team Management

 

In my summary last year, I wrote the method that I thought to lead a small team. Now I have summarized it into four words: "Agile development ". At the beginning of the year, one of my team members recommended me to read agile development books to find that the methods created in my practices are actually part of agile development. Theoretical learning based on practice makes people feel confused. Next I will write about the methods that I thought were particularly important to record after reading the books last year.

1. TDD, testdriven develop. only when I read a book can I know how important this is. As a programmer, I can write code with a stuffy head. But if I write a test, many people will be reluctant (especially for small companies, there is no script specifically written for testing ). However, the establishment of test case is very important for function expansion and maintenance. Although it seems that writing test at the beginning is a little troublesome, it will save a lot of time and resources in the future. it is still difficult for my project to write scripts, so I asked my team to write documents.

2. When we end every bug/feature, it is really over, not half-hanging. End with code, comments, and corresponding documents. When a team builds a build, it will not be delayed because of a bug that seems to have been completed, which actually requires two or three sentences.

3. No matter whether it is for customers or not, each build is a complete MSI, archiving and filing. In this way, we can easily compare different versions.

Two more people belong to my team in the past two months. We met to standardize and unify the encoding specifications. For example, three single quotes will be added before each function. net, which can automatically generate help ). for example, how to name functions and variables. In fact, after working together, everyone's coding specifications have been gradually unified. This time, it was just officially made clear so that new team members can get started as soon as possible.

"Agile development" is a popular software development model. I know that it is very suitable for a small team of eight people to work flexibly. It gives full play to the initiative of team members, and can adjust the status in a timely manner to reduce resource consumption. Although agility has a formal management model and tool, the root of everything comes from frank communication and mutual trust among team members. These two are not the same as Ben "min". Everyone has their own tips, so it is better not to use "agility ".

There are no hard standards for trust and frankness. You can only rely on your team to work together slowly. In this regard, I am lucky to have a very good atmosphere for group discussions. I have learned a lot from these hardworking team members who are more experienced than me.

At present, this operation mode of our group has been recognized by department managers and has been upgraded to the existing management software, so I can manage it in a more standardized manner based on the "agile" mode.

 

This year, our department made a personnel change, and the inaction manager mentioned last year came to a new place. To some extent, I need to assist him in his work, which also provides me with some opportunities to represent participation in inter-department meetings and decision-making layer meetings. One kind of meeting is to deliver comments to everyone and a speech is needed. I am not confident in my formal speech, so I am afraid that I cannot express my meaning accurately. As a result, we set up a demonstration platform, made case analysis, and used PPT as the main context. The results were unexpectedly good and received a lot of positive feedback, which will be helpful for future development ideas. The other is to listen to your opinions. The pre-sales buddies are very capable of "nitpicking. The key is that it is not long before the end of the development cycle to say that a change is troublesome. In the past, I was not the main character, but now I have become a listener. The first reaction is resistance and defense. However, it is my turn to speak. I can only say sorry. We are not considerate. We will pay attention to it next time and hope to talk more in the development process. This is why we have been working for a long time. We should not say this when we are young. "I'm sorry" I obviously feel relieved before the Sales. Development and sales are not the two opposite sides, but the problem of "pick" is refined, loop in the development process can reduce unnecessary cost waste. We are a small company. When talking to each other, we don't need to officially sit down in the conference room. People are willing to come here if they are willing to give their attitude towards development and welcome comments and suggestions.

 

At last, I would like to summarize the status of my work this year. I have been learning and exploring. Adapted to the Role Change and learned how to deal with the problem. If you cannot cope with it, you will find the right person for help.

 

Outside of work, I remember that I wanted to go to Tibet last year, so I had a Christmas New Year in the snowy highlands. This year's trip was made in the late autumn of September, and it was estimated that I would not go far in the winter.

 

The last sentence

Bow down to work, head up to be a person
Happy little day :)