When working on an open-source project, get in the habit of downloading the latest version of the code (preferably from their source control system) so you can review its history and track future developments. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. Not only will it give you a better understanding of the projects; Also make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for the Git distributed source control system written by Linus Torvalds, or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally make use of data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools your own. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something very important. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

 When working on an open-source project, get in the habit of downloading the latest version of the code (preferably from their source control system) so you can review its history and track future developments. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. Not only will it give you a better understanding of the projects; Also make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for the Git distributed source control system written by Linus Torvalds, or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally make use of data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools your own. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something very important. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.