8 Valuable lessons from the history of programming in 35 __ programming

1. Always remind yourself: Learn

The first step in learning something is admitting that you don't know. This sounds normal, but the experienced programmer remembers how long it will take to really let yourself admit it. Many computer science majors have a very arrogant attitude when they graduate, that is, "I know the best", but it's just a bluff, they don't know where the confidence comes from, it's like they know everything and need to prove it to every new colleague. In other words: what you call "I know what I'm doing." "This attitude will prevent you from learning new things.

2. Don't try to prove that you are right

To be a good person, you must learn to a fall into your wit. But be careful, experience may teach us to repeat bad behavior, and even teach us to form some bad habits. We've all met programmers with 8 years of experience. For them, the same experience was repeated 8 times. To avoid this syndrome, look at everything you do and ask yourself: "How can I make it better?"

Novices (and many experienced developers) will look at the code they write themselves and appreciate the wonders of it. Instead of trying to get it to run, they write tests to prove that the code they write is ready to run. Really good programmers will actively find out where their mistakes are, because they know the end users will find these missing bugs.

3. "Code can run" This goal is not the end, but the starting point

Yes, your first step is always to write high-quality code, and the code is full of comments. But the average programmer quits at this point and then goes on to the next thing.

But once the "finish" stops the idea is like taking a snapshot and expecting it to be a piece of artwork. Great programmers know that the first iteration is just one iteration. It's running up, congratulations! But you have a lot of work to do. Now, make it better.

In fact, this process is to define the meaning of "better". What's the value of making it faster? What are the benefits of being more reusable? The answer varies with each application, but the process is the same.

4. Write three times code

A good programmer's goal is to write software that can be run. The great programmer writes out the software goal is to run very well. It is almost impossible to write this situation once. The best software is usually written three times:

First, write the software to prove to yourself (or the customer) that the solution is feasible. Other people may not realize that this is just a proof of concept, but you did.

The second time allows it to run normally.

The third time you can make it run smoothly.

When you see the work of the best developers, this level of work may not be obvious. Everything they do looks great, but what you don't see is that even the big names in the development world may have abandoned the first and second versions before showing their software to others. Discarding the previous code and starting to write another version is a powerful way to integrate "better" into your personal workflow.

If there are no other cases, you can tell you how many ways to solve the problem by "write three code". And it can prevent you from being stuck in a stagnant state.

5. Read a lot of code

You might want me to be able to guide this advice, which is, in fact, the most common and valuable advice for improving your programming skills. It's also important to read other people's code, but it's not obvious.

When you read other people's code, you'll see how other people are solving programming problems. But don't think of it as a literary work, but as a lesson and a challenge. To get better, ask yourself:

What should I do with that code? Now that you've seen someone else's solution, what's your idea?

What I have learned. How do I apply this technology to the code I wrote in the past? ("I never thought I could use recursive descent to process that piece of logic").

How do I improve this code? If this is an open source project and you have more confidence in your solution, do it.

Write the code in the author's style. Practicing this can help you get into the author's mind, which can improve your compassion.

Don't just think about these steps in a casual way. Write your own answers, whether in a personal log, blog, review code, or in a forum that communicates with other developers. Just as explaining a problem to a friend can help you solve a problem, documenting and sharing your analysis can help you understand why you're reacting to someone else's code in a particular way. This is part of the introspection I mentioned earlier, helping you to calmly judge your own strengths and weaknesses.

Warning: It's easy to read a lot of code without having to be a good programmer, just like someone who wants to be a writer can read great literature without raising his prose. Many developers are looking for open source or other software to "find the answer" and are likely to copy and paste the code to solve similar problems. Doing so will actually make you a worse programmer because you blindly accept the wisdom of others and not look at it. (in addition, it may be more troublesome than a summer picnic, but because you don't take the time to understand it, you'll never realize that you're like a nature porter, just doing manual work.) )

6. Don't just think of writing code as a task

There are many advantages to engaging in individual programming projects. First, it provides you with a learning tool and a way to learn techniques that are not available in your current job, but that will make you more market in your next job. Whether you're contributing to an open source project or doing a good job for a local community organization, you get technical skills and confidence. (in addition, your personal project proves to prospective employers that you are a person who never stops learning.) )

Another benefit of writing code is that it forces you to solve the problem yourself. You can't leave these difficult questions to others, so it will ask you to ask for help prematurely.

Professional tip: Don't just select individual projects that you never fail. You need to fail! But you may not want to fail at work, or you don't want to fail when you limit your time limit.

7. Do everything you can to meet other developers in person

It is helpful to listen to others ' opinions. This could mean pairing programming, or participating in a hackathon, or joining a programming user group (such as Vermont coders Connection). When you're contributing to an open source project, take a look at the feedback you get from users and other developers. What do you see in common in their criticisms?

In doing so, you may be fortunate enough to meet a mentor who can trust you fully, and you can trust him with no path to coding or career decisions. So don't waste these opportunities.

8. You are learning technology, not learning how to use tools

Programming languages, tools, and methods these are only temporary. That's why you need to gain as much experience as you can in so many languages and frameworks. Focus on the basics of programming, because the foundation never changes; it's more about architecture than programming. If you feel that there is only one right way to do something, it may be time for a realistic check. Restrictions can hinder your ability to learn new things and make it difficult for you to adapt to change.

I can move on, but the key principle of self-improvement is knowing when to stop.

After reading this article, please leave a message to share your thoughts with us.

More Highlights

“

Husband monthly 50,000 programmer Lady 丨 70后 Programmer's Revelation 丨 programmer lift appearance 丨 Wang Xiaobo programmer 丨 I will program 丨 Tanabata Confession 丨 programmer top honors 丨 programs Ape (yuan) CP 丨 worship 丨 python lyrics 丨 Tesla 丨 program Yuan 丨 live 丨 contempt chain 丨 code 丨 404 丨 Wedding 丨 Facebook 丨 How to get into bat 丨 girlfriend Diary 丨 Guide 丨 computer Professional 丨 skills dry 丨 programming habits 丨 Lurkey speech 丨 self-help guide 丨 Zhou Hongyi talk about entrepreneurship 丨

”