"Efficient" is the ability to meet the required items on time

As a software engineer , what you want to get from your job is a steady salary, opportunities to get involved in the project , a good springboard for the job, or just being a good friend with other programmers . Here, "efficient", I mean the ability to meet the requirements of the project on time. After a lot of software writing experience, I believe the following practices will help you to learn "efficient", while improving professional reputation, extend professional life, and obtain personal satisfaction

Understand your needs

The first step in becoming an efficient programmer is to ensure a reasonable distribution of time. Nothing is more wasteful than spending time on a completely unprompted job.

Start as soon as possible

Complete an intuitive system as soon as possible. This means creating the interface first, either as a program or as a user interface, and then generating a stub code for the internal function, if necessary. This is done for the convenience of the "client" to see the contradictions or omissions in the original code, either by executing the user interface or by writing program interface code. Even before the first delivery, you may notice problems or areas for improvement.

There is a classic belief that if you design everything well in advance, then you have to write only the code you need to do. If you've done exactly the same project before, that's certainly true. But if you do not, you're likely to fall dead, that is, you're just guessing or doing a dubious assumption.

When working for a new company in a wireless network long ago, we had a two-month meeting to design a wireless portal and gateway to be released in six months. In the end, we got tired of meeting and started writing code. For the first two weeks, the part I was responsible for did not match the original design. The first wireless connection test two months later showed that I completely misunderstood the wireless protocol.

This is not to say that design is not necessary. But to a certain extent, design is just a guess. The design should be validated, and the early execution is always better than the late implementation.

Even if the original design is adequate, as long as you find the place to be adjusted, you should improve it. Hardware products, buildings, and large-scale software projects suffer from a zombie "prefabrication", but for software you can refine project requirements early in the project and create a suitable interface. However, this must be done as soon as possible.

Start as soon as possible is conducive to establishing your professional image. He will be happy if he can show some results to your boss. On the other hand, early start-up helps to ease anxiety.

Often delivered

Once you have done something useful, do not just leave it as "proof of concept." Let others try it out, look at their reactions, and then have it direct the development process prioritization. Observe how people use your software, this is an irreplaceable way. Customer surveys and focus studies may provide some useful advice, but it may be risky to let the designer's design decisions and characteristics be led by the client.

In particular, QA staff should be delivered to the software as soon as possible, often submitting results, preferably at predetermined intervals. It's also good to have them test the results of the day, or at least the weekly results. This will make QA staff feel they are involved in the project development throughout their career, so as to develop a sense of professional responsibility and be more willing to detect and report problems. The first thing that needs to be prioritized is the problem that caused the product to fail, such as a crash or a dead-end - making the problem as diverse as possible and familiar with the product as a whole, so that it is possible to detect design problems earlier.

At a small 3D software company, I was responsible for porting leading products from SGI to Windows NT. Six months later, the transplant was not completed, with the tendency to collapse. I reluctantly delivered the first round of results to the test team. Fortunately, because of too many holes, the QA manager insisted that I fix the problem that caused testers to use the program meaninglessly. If it's my own test, I should be busy with core 3D issues that seem more difficult and more important, and may seem less commonplace, such as user interface, load-save functionality, and planned hardware support compatibility.

Programmers often do not want to prematurely deliver code to testers - they do not want to hear bugs that they already know; and testers will most likely not want to test something that does not work at all. But the tester's job is to find these problems. If programmers want to see the results as soon as possible, the vulnerability report should be treated as a good thing.

Take the job seriously

Run the software as close to completion as possible. You never know when you have to demo the system, send an evaluation backup or even deliver it.

Use real data

If you are only testing for the sample data at the tip of an iceberg, then your program may sink as soon as the big iceberg hit real data.

I have been involved in the development of a supply chain management product to evaluate advanced semiconductor absolute values. After crossing this barrier, we received news that the first real data they entered was still being processed - two days ago. I am sympathetic to the main programmer, who had to work for two weeks at the urging of managers and clients. Glad to meet people who are not me.

Use the official version

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

In a recent game development project, I was in charge of the user interface, and I received reports from the QA that some colors were wrong. Finally, I found that the problem only appeared in the delivered version, and another programmer found a bug using a dedicated host debugging tool. The result was actually a stupid mistake I made two months ago, without specifying the initial color value. The debug version always chooses a specific default, but the delivery version changes, and the end result is less certain. If I pay attention to running delivered versions often, I will immediately find the problem, not lose a lot of time.

Often merged

Promptly incorporate your code into the main codebase - the longer you drag, the more tedious the job is.

I worked with a programmer and he found that all the new code and data changes in the database were "cumbersome" every day. Indeed, this allows all other programmers to spend time each day merging, and he can start running some nice, stand-alone samples just by glance at the code and data. But every time it is delivered in phases, it takes us several days to re-attach the individual code to the current code base, sometimes with delays in delivery or at risk of losing the entire project.

Separating your code from the official version means programmers can not evaluate your code, and testers can not spot vulnerabilities early. Probably you do not want others to pick your code, but finding problems early is better than later - so let's endure.

Understand your code

Life is full of wonderful mysteries, but your code is not suitable for these mysteries. You do not have to know how your car works - if the engine makes strange sounds, give it to a car mechanic just fine. But replaced by your code, if you do not even know how it is running or what went wrong, nobody knows.

Have your own style of writing

My childhood piano teacher said of me and my sister's brother: "Your sister has a strong sense of time and your brother's keyboard is doing well." Then he paused and said: "Well, um, you work hard. "

Programming is something that some people can do what some people can not do, but others are geniuses. Although I had many years of practice, the piano still did not play well; although I liked playing so much, the level was still average. But I do think I have the talent for programming and writing. Do not be surprised, I think good programs are like good essays. Prose and code are text, grammar, syntax, spelling and semantics. This is enough for most people who write code and people who write, but good writers and good programmers have a sense of beauty, their work is characterized by the structure and style can often be identified Author.

Many Windows programmers are curious about why bad old Unix / Mac / Amiga / Lisp programmers are frustrated with Win32 / MFC / .NET, but you probably do not even know if all your application interfaces come from Microsoft Is better.

copy and paste

The opposite of stylized programming is copy and paste. From where to copy some of the code may be useful, a little adjustment, merge, repeat, and then you're done. Your software is simply a hodgepodge.

A few months after leaving a company, a former colleague emailed me and he copied and pasted 10 pages of code into an algorithm that would not work. I really do not know how to answer it. If you can not explain how your own code should run, who do you expect to save you?

I've even done a lot of trouble diagnosing code I've copied and pasted from sample code. It makes sense to start new code from copy and paste, but you can not let it go because it seems to work - you have to go back and see if you read each one and sort out the code for your own purposes.

Clean up the code

The best way to keep your home / apartment / house tidy is to take a day to clean it up or at least clean it once a week. If you wait until the chaos to a certain degree of cleaning, then this trouble is very big. Unless you hire a cleaner.

Assuming you can not afford luxury to hire a person to help you clean the code every day, you should regularly check your code, clean up accumulated dead code, obsolete annotations and wrong names, or you will get a Not come up to see the code. If you do not think you can not afford to lose someone, well, you do it.

A programmer I directed always reported to me that her code was "done." This is what managers are willing to hear, but it makes me very crazy. Her code has never been done - you have to debug it, maintain it, improve it until it's completely OK.

problem? Comment?

Some people think programming is a craft, and some think programming is a project. More often, it is an archeology. You dig in the code for the deposits and wonder what these weird artificial products are for. For later people think about it, leave some clues.

I asked the programmer who mentioned before to "finish" with a comment. The result is that a comment with the function name "GetData" is actually "Gets data". It's not just nonsense - it's an insult. What data? What format? From where? Not to mention the server is not available or send interrupt what kind of such a small detail.

Document your code to prevent anyone from using it at any time. The potential person to use is you - think about how many times you have to revisit the code if you do not?

When working with a former boss, he asked me to browse through the code that no one had time to see. At first, I think it's bad, I do not know what it is. After that I slowly figure out what this code is doing, so I barely agree that it is not too bad. Finally, I finally recognized the goods actually two years ago I wrote. Lesson: Leave more comments.

When you write a code, remember the comment, rather than waiting for a handy cleaning phrase - annotate your code so it even clearly reflects what you were writing. You can be your own companion.

Now you can generate beautiful HTML or other formatted files from source code annotations with javadoc and doxygen. Ideally, what you do every night is part of the doc generation that is available through your intranet.

Watch for warnings

Ignoring the editor and runtime warnings can hurt you. There is a "warning" for a reason.

I have done a Unix-based application, it can not successfully connect some of the functions. We solve the problem by connecting these functions again at run time. Six months later, when we implemented a clean new version, we realized that we turned off the warning that we could remind us of an unknown connection vulnerability. In the supplier's denunciation, we will solve the connection problem. But the result is that we can connect as long as we have to rearrange the library.

Improve the editor's warning level, comment code, and warnings about record creation and uptime, and preferably include a standard that addresses warnings so that you know if the problem is resolved or ignored.

4. Optimize programming

Write the code with the purpose

The other extreme of people who copy and paste code is simply changing the code to make the code look more beautiful, at least for them. While programming aesthetics is commendable, changing the code to make you feel pretty is just a waste of time (useless adventures). Browse and change the code people write, make it look more beautiful, really annoying.

I have a discerning colleague who deletes all the extras as they browse our code base. If he just cleaned up code written by entry-level employees, nobody might say anything, but those add-ons are written by the technical leadership of our team, who is one of the best people in our company.

Do not spoil

"Code Refactoring" is now very popular, but programmers often think it refers to code clean-up or redesign. This technique refers to reorganizing the code without breaking other things. If you spoil existing functions in the name of improvement, what you mean is that either you spend more time than others, or you do not destroy the whole code.

I have a particularly disagreeable colleague who has decided to re-execute the parser in our system, but as a result the code becomes something that everyone else does not know how to write. I let him restore the status quo, then found the code can be prepared, but can not run - ask him what's going on, he said "should be your request," he removed the entire parser. Really no team spirit.

Keeping your code running requires some patience and extra work - you're diligently returning to testing your work, and when adding functions to your new code, you may need to keep the old code and interface temporarily. But for all who are involved with this code base, this is a must.

Find the bottleneck

People always talk about "best", but this is not the right word. We rarely target the best - on the contrary, our goal is to improve and weigh to achieve good enough performance.

During a Google telephone interview, I was asked how to search for a number in a set of ordered numbers. Obviously, the person who asked the question is asking the binary search method. But in real life, I might make the "wrong" choice - find the tail from scratch. If the program behaves well enough, it takes twice as long to write twice the code that must be maintained and debugged, that is pointless, especially if that code is not a bottleneck in the program (I seriously doubt if that data is Bottleneck part, you will actually arrange it linearly).

If you really need to get the best speed or space in your program, tossing any part except the bottleneck is just a waste of time.

Self-management

You may complain about your nasty boss, your complaint may be true. So you have to be your own manager. Even if your boss is good, he will not stand behind you to tell you what to write and how to write fast (though I'm sure many employers can not wait to do so).

estimated time

It is notable that programmers can not provide useful time estimates. But I think this is an irresponsible accusation, as management tends to make worse predictions and programmers' warnings are often ignored (this could be a common disaster for all projects). However, a reasonable estimate of time is still critical to completing the project on time.

In a commercial software project, some of my colleagues are actually happy to forget the delivery date of the product - someone asked if it has been delivered or not, and the other person was surprised to find out that days have passed.

Worse yet more generally, the time the programmer can give is estimated to be "only a few days." Every time I hear that, or I say it myself, I feel jealous.

The president of an imaging software company wanted to make the product supportive of VRML (then it was the next big move), including the product that we will release in two months and support for VRML as well. He might have thought (he was right) I would refuse to start a new project, so he asked another engineer and he got the answer he thought: "It only took a few days." Two days later, I told the president that we had just wasted him And two days of my time, because of more than two hundred more important loopholes to fix, he thinks my reason is sufficient. (Afterword: VRML is not too successful.)

Another programmer has absolutely no concept of time estimation. But there is no need to completely reject the vague attribute of time - after all, just an estimate, in fact you should avoid being too precise. If you are an experienced engineer, you know how long you have previously done similar work, and if you are not, then ask experienced people.

I have a smart friend who is often assigned to develop experimental prototypes. He asked me, "How do you estimate the time?" I think this is a rhetorical question, but even pure researchers have to estimate time. Someone paid them and hoped to get the result, even though it was published in many demo samples or some time.

If you really do not know how much time you are not allowed to decide, then you are not the right person to do this task.

Sometimes programmers are reluctant to promise time because they are afraid of promises. Indeed, the world is not that beautiful, the manager will bargain with you over time, competitors may run in with harsh or unrealistic arrangements and hopefully you fail. After your promised time, you are tragedy, you do not want to get any result you want.

I once asked a boss about the completion time: "Are you sure?" But when asked about his hardware and other related issues, he would say: "I try my best."

I can only say that, hurry up and give a realistic estimate. Any concession should be based on the actual transaction between the product and the resource. According to the assumptions, related matters and resources to do time arrangements, find a place to write down, so you do not have to trouble you later to force the memory.

planning schedule

You will not jump in the car before you decide where to go, right? You may have a route in mind when driving. Similarly, before you start writing on a computer, you should know what you are trying to accomplish today, with some ideas.

Every day, you get distracted, so you can not always do what you want to accomplish. Contrary to the idea of ​​those who think of a software engineering team as a vending machine, some tasks can not be completed in a single day. So think about what you're supposed to do by Friday, and if you're done, then you'll be fine over the weekend.

Keep learning

A member of a club football team once asked me if we had tight studs practiced everyday. What are the secrets of C programming? "If there is such a secret, I am sure I will advertise on nightly TV shows how to make a fortune on real estate. Sorry, there is no shortcut - you have to learn, practice and make mistakes. You do not have to rely on group training or school education - there are many national and local professional groups, books and, of course, the internet.

Programming is science

Programming is called "computer science" for a reason. Without formal computer science education, anyone can easily start programming (which may be too easy). In particular, those who have studied other projects and sciences can program very quickly to make a living. But to handle important tasks efficiently, you must know the inherent capabilities and limitations of the software and identify the prerequisites so that you will not be bothering with repetitive tasks. You do not have to know everything, but you should at least roughly understand many areas and do some additional research where necessary.

For example, someone who creates a new file format should know something about the editor. I do not mean that all code-generated optimizations, such as looping, are about the basic issues and the importance of various edited phrases and most of the specified tags and syntax. Today, most people use XML by default, that's a good thing,

But until then, it is generally crude to write some text formatting that points to some of the generated sample documents as files, and then others who have written another parser will make up some, but not all, of the things that are being read in the document. In the case of mistakes, you have two ways to shirk responsibility - either the reader or the author too bad. No matter what, more popular products will win.

One of the last things I can not tolerate in the 3D graphics industry is that too many file formats are unknown. When I executed the OBJ file parser for a 3D work, each of my exported works produced significantly different files, such as whitespace and line breaks. In contrast, one of my furry colleagues designed a new game exchange format with grammar and lexers (now it is no longer a big deal - most new image file formats seem to be Based on XML).

A programmer who simply puts a simple script and user interface together and a programmer who can handle the actual problem, if any, distinguish between complex computations, such as how the algorithm affects the size of the problem . Every programmer should know the basic terminology of complexity and common sense about the complexity of common problems.

My first job was in computer-aided semiconductor design involving a number of scalability issues, including some NP-complete issues (very difficult to handle). But every time you see problems that can not be solved in linear time, and we boast of "linear" algorithms that can mean mostly linear time, some engineers are excited to say, "This is the traveler's problem!" (Traveling Merchant The problem that TSP is a typical combinatorial optimization problem with an important engineering background in graph theory has proved to be an NP-complete problem, that is, if a traveler has to go to several cities to do business, how to get the shortest The route made him arrive in these cities at once.)

Free beer, free discussion, freeware

Well, there's actually no free beer; but programmers are doing pretty well now (despite the downturn and the outsourcing industry) - after all, what you need online tutorials, discussion groups, and free software are available. You have to solve only the hardware and broadband issues.

Respect

One of the requirements of an effective software engineer is to be taken seriously. You must be respected by your co-workers and your boss, at least out of your technical ability, to have the power over your work and to influence others.

Stupid question

Really, there are many stupid questions in this world. Proposing a clever question will increase others' respect for you, but it is a technical activity. A good question of exposing unresolved issues will make others see your profound connotations and your acute thinking. Ask questions about technical parameters and demonstrate your ability to read and identify problems.

If your question is not answered, the question itself may be wrong, so do not repeat it. Put another way, ask for more details or background. If you are the one who is asking you, or you take the time to respond to a novice problem, you will thank you for your consideration.

Being able to maintain good relationships with technical support staff is something that makes me proud of myself. But I do remember a past event when I was asked the question, "What happened to the question a few weeks ago?" You can imagine how annoyed others are - "What did you say is What, and what are you talking about?

Rudeness is not rewarding, especially if you are asking for free guidance or advice from the discussion group. Even if you are asking questions under the umbrella of a support agreement, it can be detrimental to your long-term cooperation to anger your technical advisor.

I used to explain to new, angry people why their problems were problematic or what they were doing wrong from the very beginning and it was really tiring. Now, I give you a quick fool filter - "I just want to know ..." or decisively disregard it.

Let everyone know that you read the file and Google searched for the issue. In addition to avoiding the inevitable "RTFM" (RTFM means reading the damn instruction manual.) When you need information or solve a problem, you should take a moment to try and find what you need before asking for help.) And " Google is your friend, "shows that you have done your homework, and those who help do not have to search the same resources. If you really expect them to search for those resources for you, then you mean, your time is more than their precious, you are murdering them.

Stupid answer

If you want to show that you know what you're saying, then you really should know what you're talking about. Engineers sometimes communicate more about showing off their knowledge than providing information (I honor you if you can). This is often not conducive to job interviews, the interviewer is in fact under the guise of "find out what you think", throwing empty questions to job seekers. Of course, job seekers who have a bit of self-knowledge may also have unexpected results.

A technical director called to interview me, asking me to outline the resulting stack framework for C ++ editing and give him an oral reply. I step by step to draft, each time I give him the correct answer, he in turn asked me to say a wrong answer, so that we can double-check why that choice does not work. I do not know if I am writing to show how clever I am or how clever he is.

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

I am fortunate enough to work with a senior engineer, he never makes mistakes. When his Java code crashed in a multiprocessor system, it was a big loophole. When I took the code that the UI code does not support multithreaded runs, he insisted there was only one thread. When I listed the seven threads in the code (I can find out), he agreed not to keep so many threads, and the best change. But he still wrote the code as usual - he did not fix any bugs, he just covered the bugs with more code.

Finally, a time-saving suggestion: Do not tangle with stupid arguments that stupidity is contagious.