Engineers in every field know the limitations of the tools and the materials they use. If you are an electrical engineer, you should be aware of the electrical conductivity of various materials and the various methods of using voltmeter. If you are an architect, you should understand the properties of wood, concrete and steel. And if you're a software engineer, your basic building materials are human ingenuity, and your main tool is yourself. The architect is a detailed design of the structure of the building, and then the design blueprint to others to build, and you are once when you are in the details of the software design, the software generation process is over.
The whole work of programming is like building castles in the castle-it's not pure human activity. So when software engineers study the necessity of tools and materials, they find themselves studying human intelligence, character, and not something visible like wood, concrete or steel.
1 personality is not related to the subject of this book
The very internal characteristics of programming work make the personal characteristics extremely important, you think about how hard it is to concentrate on working eight hours a day, and you may have experienced a listless experience due to the concentration of energy. Or you may work from 8 o'clock in the morning to 2 o'clock in the afternoon one day until you get too involved in the last month and the spirit is going to collapse. Sometimes you work hard from 2 o'clock in the afternoon to 5 and then spend a week revising what you write in between.
It's hard to check the programming, because no one knows what you really do, and we often have this experience, we spend 8o% time doing 20% of the work we're interested in, and spend 2o% time generating the remaining 80% of the program.
Your boss can't force you to be a good programmer, and even after a long time your boss can't tell you if you're a competent programmer, and if you want to be a master, you have to do it all by yourself. It has to do with your personal character.
Once you decide to become a senior programmer, the potential for your development is great, and various studies have found that the time required to create a program is 10:1, and that the time to debug a program, the length, speed, error rate, and number of errors found in the program can be up to 10:1 for different programmers.
You can't change your cleverness, but you can change your personality to some degree, and you've found that character is a more decisive factor in the process of becoming a programmer.
2 Smart and Humble
Cleverness does not seem to be a contribution to personal character. It's not really. It happens that good intelligence is not closely related to being a good programmer.
Why? Does this not require you to have a good intellect?
No, you don't have to, no one is really as quick and agile as the computer. Fully understanding a general program requires you to have a strong ability to absorb details and to understand all the details at the same time, and it is more important that you make good use of your cleverness than how smart you are.
In 1972, Edsger Dijkstra published a paper named "Humble Programmer". In this article, he argues that all programmers should try to make up for their limited intelligence. Those who are most proficient in programming are often those who think their minds are limited, and they are humble. The worst programmers are those who refuse to admit that their abilities are not suited to their tasks. Their ego hinders their ability to become good programmers, the more you learn to make up for your brain, the more you become a good programmer, the more humble you are, the quicker you'll make progress.
Many good programming styles are designed to reduce the burden on your brain, and here are some examples:
The purpose of "decomposing" a system is to make it easier to understand. It is often easy to understand a few simple information rather than a complex piece of information. The goal of all software design methods is to decompose complex problems into simple parts, regardless of whether you use a structured, top-down, or object-oriented design.
Review, check and test are a way to make up for people's mistakes, part of the review method is "error-free programming", and if you don't have any errors, you're not looking at your software, but when you know your ability is limited, you should discuss it with others to improve your software quality.
Making a subroutine shorter will help reduce your workload. You can help reduce your workload by writing programs based on questions rather than computer science terminology and using the highest possible level of abstraction.
Using a variety of conversational styles frees you from a dead end to programming.
You may think that by being smart you can develop people's intellectual activities better, so you don't need these help. You may also think that programmers who use intellectual help are detours. In fact, research has shown that the programs written by humble people who make up for their mistakes in a variety of ways are easy for themselves and for others to understand and have fewer bugs in their programs. The actual detour is the path of error and impact on progress.
3 Curiosity
Once you think that your ability to understand a program is limited, and you realize that effective programming is the way to compensate for your abilities, you begin the long process of exploration in your career.
In the process of becoming a senior programmer, it is important to be curious about technology. The relevant technical information has changed rapidly. Many PC programmers are not in the process of doing the machine, and many programmers have not used the computer's punched cards. The specific characteristics of the technical environment change every 5-10 years. If you can't keep up with this change, you will face the threat of backwardness.
Programmers are often so busy that they don't have the time to be better at work or interested in work. If you do, you don't have to care much, because a lot of people are like you, here are some ways to develop your curiosity, you really should learn it well.
Establish self-awareness in the development process. The more you know about the development process, the more you can understand the changes, whether you're reading from the development process or your own observations, and make your development team move in a better direction. You should also be satisfied if you assign fewer tasks and do little to improve your skills. If you are developing software with good market prospects, half of what you learn will become obsolete over the next three years, and if you stop learning new knowledge, you will fall behind.
In the 1988 to 200O years, the average U.S. job number can increase by 11% to 19%, and computer system analysts can grow by 53%. Programmers can grow by 48% and computer operators can grow 29%--add 556,000 new jobs on the basis of the existing 1,237,000 jobs. If you don't learn anything at work, you can try to find a new job.
Experiment. An effective way to understand programming is to experiment with the programming and development process, and if you don't know much about the working process of the language you use, you can write a short program to check this feature and see how it works, and you can watch the execution of the program in the debugger. It's good to test a concept with a short program rather than a big, poorly understood program.
What should you do if the operation of the short program indicates that the result of the program is not what you expected? This is exactly what you need, and it is best to use a short program to make mistakes quickly in a key way of effective programming, and each time you can gain from it, making mistakes is not a sin, not learning what is a sin.
Read about ways to solve problems. Problem solving is an important activity in software development, and Herbert Simon has reported a series of examples of manual problem solving. They find that people often fail to find solutions to the problem, even though it is easy to learn. This means that even if you want to create the wheel yourself, you cannot expect success, you may design a square wheel.
Analyze and plan before you act. You will find that there are contradictions before analysis and action, and sometimes you have to give up data and actions, and for most programmers the problem is not too much analysis and excessive use.
Learn the development experience of successful projects. A very good way to learn programming is to learn from some good programmers. Jon Bentley thinks you should sit down, prepare a brandy, a good cigar, and read the program as if you were reading a novel. This may not actually be the case, and many people tend to be unwilling to sacrifice their rest time to read the 500-page source program, but many tend to study the design of an advanced program and selectively study specific details.
The field of software engineering rarely exploits examples of past successes or failures. If you are interested in architecture, you may study the design of Louis Sullivan,frank Lloyd Wright and I.m.pei, you may also visit their buildings, if you are interested in structural engineering, you can study the Broolyn Bridge, Tacoma Narrows Bridge and other concrete, steel and timber buildings, you should study examples of success or failure in your field.
Thomas Kuhn points out that any mature science is actually developed by solving problems that are often seen as examples of good work in the field and can be used as examples of future work. Software engineering is just into the mature order
section of Science, in 1990, the Computer Science and Technology Commission has pointed out that in the field of software engineering, there are few examples of success and failure to study the document, in March 1992, "ACM Communications," there is an article advocating for other people programming problems in the study, in short, Learning other people's programming is of great significance.
One of the most popular columns is "Programming", which specializes in the problems that arise in the programming process, which is instructive to us.
You might or may not have a research program, but you can read the code written by a senior programmer, read the code of your esteemed programmer, or read the Code of a programmer you don't like, and then compare their code with your own. What are the similarities and differences between them? Why is there a difference? Which one is better? Why?
In addition to reading other people's code, you should also let other high-level programmers evaluate your code quality, find some high-level programmers to comment on your code, from their comments, you can eliminate those with personal color and focus on those important things. This will improve the quality of your programming.
Read the manual. Handbook phobia is very popular among programmers. In general, manuals are poorly written and organized, but the fear that programmers have of manuals has much to do with their excessive fear of books. The handbook contains some important things. So it is worthwhile to spend time reading manuals, ignoring the information in the manual just as ignoring some common acronyms.
Modern language products typically come with a large library of libraries, and it is worthwhile to take the time to consult a reference manual, and the company that usually provides the language product has written many subroutines that you can call. If so, you should understand the manual and read the manual every once in a while.
Read about books and periodicals. You should be lucky to read this book for yourself. You've learned a lot about software engineering, because a book is read by many programmers every year, reading something may make your expertise a step forward, and if you read a good computer book every two months, your knowledge will be greatly improved and stand out from your peers.
4 Honest
Part of the maturity of the programming career is the Buri adherence to honesty, which is usually manifested in the following areas:
Don't pretend you're a programming expert
Be glad to admit your mistakes
Trying to understand compiler warnings rather than ignoring them
Have a clear understanding of your program, instead of compiling it to see if it's wrong
Provide actual status reports
Provide actual program evaluations and stick to your opinion in front of your boss
Current 1/3 page
123 Next read the full text
