7 important habits of becoming an efficient programmer

As a software engineer, what you want to get from your work is a stable salary, a chance to participate in a project, a stepping stone for a good job, or just a good friend with other programmers. Here, "efficiency" refers to the ability to finish qualified projects on time. After many software compiling jobs, I believe the following practices will help you learn "efficiency", increase your professional reputation, prolong your career life, and obtain personal satisfaction.

1. Understand your needs

The first step to become an efficient programmer is to ensure reasonable time allocation. Nothing is more wasteful than spending time on jobs with no future.

Start construction as soon as possible

Complete an intuitive system as soon as possible. This means to create an interface, whether it is a program interface or a user interface, and then generate the internal function's Stub code (if necessary ). In this way, you can easily view the customer. by executing the user interface or writing the code on the program interface, you can find the conflicts or omissions in the original code. Even before the first delivery, you may notice problems or improvements.

There is a classic idea that if you design everything in advance, you will have to write code. If you have done the same project before, this statement is correct. However, if not, you are likely to get stuck, that is, you just conjecture or execute a suspicious assumption.

A long time ago when I was working in a new wireless network company, we held a two-month meeting to design a wireless portal and gateway that will be released within six months. In the end, we get bored with the meeting and start coding. In the first two weeks, the part I was responsible for was not in line with the original design. The first wireless connection test two months later showed that I had completely misunderstood the wireless protocol.

This does not mean that the design is unnecessary. To a certain extent, design is just a conjecture. The design should be confirmed by implementation, and early execution is always better than late execution.

Even if the original design is adequate, you need to improve it as long as you discover the areas that can be adjusted. Hardware Products, buildings, and large software projects will be damaged by rigid "pre-fabricated", but for software, you can refine the project requirements in the early stages of the project and then create a suitable interface. However, this must be completed as soon as possible.

Starting work as early as possible will help you establish your professional image. It would be nice to show your boss some results. On the other hand, early start helps relieve anxiety.

Regular delivery

Once you have done something available, do not just leave it as "conceptual evidence ". Let others try to execute it, look at their responses, and then let it guide the development process in priority. It is irreplaceable to observe how people use your software. The customer survey and focus research may provide some useful opinions, but it may lead the developer's design decisions and characteristics to be taken by the customer. This is an adventure.

In particular, the software should be delivered to QA personnel as soon as possible and results should be submitted frequently, preferably at a predetermined interval. It is also good to have them test results every day, or at least weekly results. This will make the QA staff feel that they are fully involved in project development, so as to cultivate a sense of professional responsibility and are more willing to discover and report problems. The most important problem to be solved is the failure of the product, such as a crash or an endless loop-so that the problem can cover as many aspects as possible and be familiar with the entire product, so that it is possible to detect design problems early.

At a small 3D software company, I was responsible for porting leading products from SGI to Windows NT. Six months later, the migration was not completed, but it was prone to collapse. I reluctantly delivered the first round of results to the testing team. Fortunately, due to too many vulnerabilities, the QA manager insisted that I immediately solve the problem that caused testers to be unable to use the program meaningfully. If it is my own test, I should be busy with core 3D problems that seem more difficult and important, and may neglect the common problems, such as the user interface, the load-Save function, and compatibility with the hardware supported by the plan.

Programmers often don't want to deliver code to testers too early-they don't want to hear the vulnerabilities they already know, and testers are very likely not to want to test things that basically don't work. But the tester's job is to find these problems. If programmers want to see the results as soon as possible, they should regard the vulnerability report as a good thing.

2. Take the work seriously

Run the software as close as possible to completion. You never know when you need to demonstrate the system, send assessment backups, or even deliver them.

Use real data

If you only use the sample data at the tip of the iceberg for testing, your program may sink as soon as it hits the big iceberg of real data.

I used to develop a supply chain management product to evaluate the absolute value of an advanced semiconductor. After crossing the delivery hurdle, we received a message saying that the first batch of real data they entered is still being processed-it has been two days. I sympathize with the main programmer. He had to stay busy for two weeks at the urging of managers and customers. I am glad that the person who met this incident is not me.

Use the official version

Remember, what you create with your own machine is not formal.

In a recent game development project, I am responsible for the user interface. I have received reports from QA that some colors are incorrect. Finally, I found that the problem only occurred in the delivery version. Another programmer found the vulnerability using a dedicated host debugging tool. The result was a stupid mistake I made two months ago, with no initial color value specified. The default value is always selected for the debug version, but the delivery version is changed, and the final result is uncertain. If I pay attention to running the delivery version frequently, I will immediately find the problem, instead of losing a lot of time.

Frequent merge

Promptly add your code to the main code base-the longer you drag, the more tired you are.

I once worked with a programmer. He thought all the new Code and data changes in the database every day were "very troublesome ". Indeed, this allows all other programmers to spend some time merging every day so that they can run some good standalone samples only by scanning the code and data. However, during each phase of delivery, we have to spend several days re-connecting the code to the current code library, sometimes even delaying delivery or risking the loss of the entire project.

Separating your code from the official version means that the programmer cannot evaluate your code and the tester cannot detect the vulnerability as soon as possible. Maybe you don't want others to pick up your code, but it's always better to discover problems early than to find them later-so, let it go.

3. Understand your code

Life is full of mysteries, but your code is not suitable for these mysteries. You don't have to know how your car works-if the engine sounds strange, just give it to a car technician. But it's your code. If you don't even know how it runs or what went wrong, no one knows.

Have your own writing style

My piano teacher said this to me and my sister in my childhood: "Your sister has a strong sense of time. Your brother's keyboard is good ." Then he paused and said, "You, um, you are working very hard ."

Programming is something that some people can do but some others can't, but others are talented. Although I have been practicing for many years, I still cannot play the piano well. Although I like playing basketball, the level is still normal. But I do think I have a talent for programming and writing. Don't be surprised. I think a good program is like a good prose. Both prose and code are texts, including syntax, syntax, spelling, and semantics. This is enough for most people who write code and writers, but good writers and good programmers have a kind of aesthetic. Their work is characteristic in structure and style, this can often identify the author.

Many windows programmers are curious about the bad temper of the old UNIX/MAC/Amiga/lisp programmers on Win32/mfc /. net is not satisfied, but if all application interfaces come from Microsoft, you may not know what else is better.

Copy and paste

Copy and paste is the opposite of stylized programming. Copy some useful code from somewhere, make some adjustments, merge, and repeat, and then you will be done. Your software is a hodgedge.

After leaving a company for a few months, a former colleague emailed me and asked me why he copied and pasted ten pages of code into an algorithm. I really don't know how to answer this question. If you cannot explain how your code runs, who else do you expect to save you?

I even made a mistake in diagnosing the code I copied and pasted from the sample code. It is reasonable to start the new code from copy and paste, but you cannot let it go because it looks like it can run. You have to go back and see if you have read every line, sort out the code based on your own purposes.

Clear code

The best way to keep your house/apartment/room clean is to spend some time cleaning it every day, or at least once a week. If the house is cleaned up to a certain extent, it will be very troublesome. Unless you hire a cleaner.

If you can't afford to hire someone to clean up your code every day, you should regularly check your code, clean up the accumulated dead code, eliminate outdated comments and wrong names, otherwise, you will surely get a code that does not dare to show people. If you don't think you can afford it, okay, you can.

A programmer I guided always reports to me that her code is "finished. This is what managers are happy to hear, but it makes me crazy. Her code has never been completed-you have to debug it, maintain it, and improve it until it is completely okay.

Question? Comment?

Some people think that programming is a craft, and some people think that programming is a project. More often, it is an archaeology. You dig into the sediment of the code and want to know what these strange artificial products are. For future users, leave some clues.

I asked the previously mentioned programmer if he had commented out "done. The result is that the comment for a function named "getdata" is actually "gets data ". This is not just nonsense-it's an insult. What data? What format? Where is it from? Let alone small details like what will happen when the server is unavailable or the transmission is interrupted.

Make your code into a document to prevent anyone from using it at any time. The person you may want to use is yourself-think about how many times you have to re-access the Code if you don't do this?

When working with a previous boss, he told me to browse a piece of code that nobody had time to read. At first, I thought it was very bad and I didn't know what to write. Then I found out what the code was doing, so it was not too bad to agree. Finally, I finally recognized this product as I wrote it two years ago. Lesson: Notes for multiple reserved points.

When you write code, remember to comment, instead of waiting for a convenient phrase-Comment your code so that it can even clearly reflect your ideas during writing. You can become your writing partner.

Now you can use Javadoc and doxygen to generate beautiful HTML or other formatted files from source code annotations. Ideally, what you do every night is the part generated by Doc, which can be obtained through your intranet.

Note: Warning

Ignoring the editor and running time warning will harm you. There is a "warning" for the reason.

I have worked on a UNIX-based application that cannot successfully connect to certain functions. We solve the problem by connecting these functions again at runtime. Six months later, when we executed a new clean version, we found that we had turned off the warning that could remind us of unknown connection vulnerabilities. We solved the connection problem with the criticism of the supplier. But the result is that we can connect to the database by reorganizing the database.

Improve the warning level of the editor, comment out the code, and record the warning information for creation and running time. It is best to include the criteria for solving the warning so that you will know whether the problem is resolved or ignored.

4. Optimize programming and write code with Purpose

Another extreme for people who copy and paste code is to change the code to make the Code look more beautiful (at least for them. Although the aesthetic of programming is commendable, it is a waste of time (useless adventure) to change the code to make you feel pretty ). Browsing and changing the code written by others makes it look more beautiful, which is really annoying.

I have a picky colleague who deletes all additional languages when browsing our code library. If he just cleared the code written by entry-level employees, no one would say anything, but those additional words were written by our team's technical leaders, he is one of the top figures in our company.

Do not destroy

Code refactoring is now very popular, but programmers often think it refers to code cleaning or re-design. This technique refers to reorganizing the code without disrupting anything else. If you destroy an existing function in the name of improvement, you mean: either your time is more expensive than other people's time, or you do not need to destroy the whole code.

I have a very annoying colleague who decided to re-execute the parser in our system, but the result turned the code into something that everyone else did not know how to write. I restored him to his original state and found that the code could be written, but he could not run it. -- asked him what happened, and he said, "At your request," he removed the entire parser. Really no team spirit.

It takes some patience and extra work to keep the code running-you are diligent in regression testing your work, and you may need to temporarily retain the old Code and interface when adding functions to the new code. But for all people related to this code library, this is required.

Locate the bottleneck

People always talk about "best", but this is not a correct word. We have made the best decisions-on the contrary, our goal is to improve and weigh to achieve adequate performance.

During a Google phone interview, I was asked how to search for a number in a group of ordered numbers. Apparently, the person asking the question is asking about the binary search method. But in real life, I may make a "wrong" choice-from the beginning to the end. If the program performs well enough and spends twice as much time writing the code that must be maintained and debugged, it is meaningless, especially if the code is not the bottleneck of the Program (I seriously suspect that if the data is the bottleneck, you will arrange it linearly ).

If you really need to achieve the best speed or space in the program, it is only a waste of time to toss anything other than the bottleneck.

5. self-management

You may have various complaints about your nasty boss. So you have to become your own manager. Even if your boss is good, he won't stand behind you and tell you what to write and how to write it quickly (although I'm sure many bosses wish to do this ).

Estimated time

Programmers cannot provide useful time estimates, which are well known. But I think this is an unreasonable accusation, because the management often makes worse predictions and the programmer's warnings are often ignored (this may be a common disaster for all projects ). However, reasonable time estimation is critical for project completion on time.

In a commercial software project, some of my colleagues were so happy to forget the product delivery date that someone asked if the product had been delivered. Another person was surprised to find that it had been several days before.

Even worse, it is more common that programmers can give an estimate of the time that "it only takes a few days ." Every time I hear this, or I say it myself, I feel ashamed.

The President of an image software company wanted to support the product (which was the next big task at that time), including the product we will release within two months. He may have thought (he is correct) That I would refuse to start a new project, so he asked another engineer and got the answer he thought: "It only takes a few days ." Two days later, I told the President that we have just wasted two days with him and me. Because more than two hundred important vulnerabilities need to be fixed, he thinks my reasons are sufficient. (In other words, it is not too successful to use this language .)

Another programmer has no concept of time estimation. But there is no need to completely reject the fuzzy attribute of Time-after all, it is just an estimate. In fact, you should avoid being too precise. If you are an experienced engineer, you will know how long it takes for you to do similar jobs. If you are not, ask experienced people.

I have a smart friend who is often assigned to develop experiment prototypes. He asked me, "How do you estimate the time ?" I think this is a rhetorical question, but even pure researchers need to estimate the time. Someone pays for them and wants to get the result even if it is a lot of demo samples or articles published at a certain time.

If you are sure you are not sure how long it will take, then you are not the right person to do this task.

Sometimes programmers are reluctant to promise time because they are afraid to promise. Indeed, this world is not so beautiful. Managers will negotiate with you on time, and competitors may use harsh or impractical arrangements to compete with you. I hope you will fail. After you promise the time, you will be miserable. You don't want any expected results.

A boss asked me after the completion time: "Are you sure ?" But when asked about the hardware conditions and other related matters, he would say, "I try my best ."

All I can say is to hurry up and give realistic estimates. Any concession should be based on the actual transaction between products and resources. You need to make time schedules based on assumptions, related issues, and resources, and find a place to write them down. In this way, you will not have to bother with your poor memory.

Schedule

You won't jump on the bus before deciding where to go, right? You may have a route when you are driving. In the same way, before you start writing on a computer, you should know what you want to accomplish today and have some ideas.

Every day, you may encounter distractions, so you cannot always do what you want to do. Unlike those who use software engineering teams as vending machines, some tasks are not completed in one day. So think about what you will do by Friday. If you do, you will have a good weekend.

6. Continuous Learning

A member of the football team once asked me, "What is the secret of C Programming ?" If such a secret exists, I will certainly publicize how to make money through real estate on evening TV programs. Sorry, there are no shortcuts-you must learn, practice, and make mistakes. You don't have to rely on group training or school education-there are many national and local professional groups, books, and networks.

Programming is a science

Programming is called "Computer Science" for a reason. No formal computer science education is required. Anyone can start programming easily (probably too easy ). In particular, those who have studied other engineering and science fields can program on hand very quickly and then make a living. But for efficient processing of major tasks, you must know the Inherent functions and limitations of the software, and identify the premise, so that you will not do repetitive work in vain. You don't have to know everything, but you should have at least a rough understanding of many fields and do some additional research if necessary.

For example, the person who created the new file format should know something about the editor. I don't mean the optimization of all code generation, such as loop expansion, but the basic problems and the importance of various edited phrases and most of the specified markup and syntax. Today, most people use XML by default, which is a good thing,

However, before that, some text formats were roughly written, pointing to some generated sample documents as files, other people who have written another parser will add some things they have read in the document, but not all of them. If something goes wrong, you have two ways to shirk responsibility-either the reader is not good or the author is too bad. In any case, more popular products will win.

One of the most intolerable aspects of the 3D image industry is that too many file formats are unknown. When I execute an OBJ file parser for a 3D file, each exported file I tested generates a significantly different file, such as blank and line feed. In contrast, one of my first colleagues designed a new game exchange format (now, this is no longer a big deal-most new image file formats seem to be XML-based ).

Programmers who only put simple scripts and user interfaces together and programmers who can handle practical problems, if there is any difference between the two, it is the ability to understand complex computing, for example, how algorithms affect the problem size. Every programmer should know the basic terms of complexity and have a common sense of the complexity of common problems.

My first job was a computer-aided semiconductor design that involved a lot of scalability problems, including some NP-complete problems (very difficult to handle ). However, every time we see problems that cannot be solved in linear time, we may boast that most of them are "linear" algorithms of linear time. Some engineers will say with excitement: "This is a Travel Salesman Problem!" (Traveling salesman problem (TSP) is a typical combination optimization problem with an important engineering background in graph theory. It has been proved to be an NP complete problem. That is, if a traveling salesman has to do business in several cities, how can he take the shortest route to make him arrive in these cities at one time .)

Free beer, free discussion, Free Software

Well, there is actually no free beer, but now programmers are doing well (although the recession and outsourcing industry are controversial)-after all, there are things you need online tutorials and discussion groups, you can also use free software. You only need to solve the hardware and broadband problems.

7. Respect

One of the requirements of efficient software engineers is to be taken seriously. You must be respected by your colleagues and bosses, at least out of your technical skills, have a leader in your work, and have an influence on others.

Stupid question

Really, there are many stupid problems in this world. Asking a smart question will increase others' respect for you, but this is a technical activity. A good problem that exposes unsolved things will let others see your profound connotation and your keen thinking. The technical parameter requirements indicate your ability to read and discover problems.

If you don't get an answer to your question, it may be because the question itself is incorrect. Ask questions in another way with more details or background. If you have been asked, or you have taken the time to reply to questions from new users, thank you for your consideration.

I am proud to be able to maintain good relations with technical support staff. But I did remember the past. At that time, I threw out a question: "What is the problem that came out on a few weeks ago ?" You can imagine how annoying others are to answer-"What are you talking about ?"

Being rude is not rewarding, especially if you require free guidance or consulting discussion groups. Even if you ask questions under the protection of the support agreement, your technical advisor will not be good for long-term cooperation.

I once explained to new people with bad temper why they have problems or what they have done wrong from the very beginning. Now, I will give you a quick and effective dummies filter-"All I want to know is ......" Or decisively ignore.

Let everyone know that you read the file and Google searched for the problem. In addition to avoiding the inevitable "rtfm" (rtfm means: Read the damn instruction manual. When you need information or solve the problem, you should spend some time searching for what you need before asking the other party for help .) And "Google is your friend" both show that you have done your homework, and those who help you do not have to search for the same resource. If you really expect them to search for those resources for you, you mean that your time is more expensive than theirs, and you are killing them.

Idiot answer

If you want to show that you know what you are talking about, You should know exactly what you are talking about. Engineers sometimes show off their knowledge rather than provide information (if you can do the same, I would like to salute you ). This is often not conducive to job interviews. In fact, the interviewer uses the guise of "discovering what you think" to throw empty questions to job seekers. Of course, if a job seeker is a bit self-aware, it may also produce unexpected results.

A technical director called me to interview me and asked me to outline the result stack framework edited by C ++ and give a verbal reply to him. I draft a draft step by step. Every time I give him the correct answer, he will ask me to say a wrong answer, so that we can carefully check why that option is useless. I don't know if I show how smart I am or how smart I am.

As an engineer, you cannot rely too heavily on money and looks-credibility is your capital. So if you make a mistake, just admit it.

I have the honor to work with a senior engineer who never makes mistakes. When his Java code crashed in a multi-processor system, it turned out to be a major vulnerability. When I pointed out that the UI code does not support multithreading, he insisted that there is only one thread. When I list 7 threads in the Code (which I can find), he agreed that this multithreading should not be retained and it is best to modify it. But he still writes the code as usual-he does not fix any vulnerabilities, but he just masks the vulnerabilities with more code.

Finally, a time-saving suggestion: Don't get stuck with stupid arguments. Being Stupid is contagious.