1–10 of 30 posts
I get writing lots of code-- but reading lots of code? I'm not so sure.
What are your thoughts?
Moreover, reading code is a skill, and much of being a good developer involves working with other people code, which means being able to efficiently parse other people's code.
If you don't read other people's code, you are stuck understanding things in terms of the idioms of your own comprehension. Moreover, reading code is a skill, and much of being a good developer involves working with other people code, which means being able to efficiently parse other people's code.
Of course we read a lot of people's code, but I'm not so sure it's something that needs to be actively practiced rather than done naturally over a career (which makes recommending people to read code pointless if it happens naturally).
I see one interpretation of better as "can copy, repeat, fix, comprehend, maintain." And the other as "comprehends and exceeds - often without explicitly 'reading' that which is comprehended in the first place"
The first group will argue that you have to read. The second will argue that it's optional.
I am in the second group but would argue in favor of the first. It never hurts to stand upon the shoulders of the giants who came before you.
That being said, I never read other's code unless its to fix it.
-It lets you work effectively as part of a larger team or project
-Gives you a much larger surface area of material to learn from: you can learn new patterns and libraries by seeing how other people use them instead of having to find documentation or tutorials
-Sometimes there are bugs in libraries (open source or otherwise) that you depend on. You will find these much quicker if you are good at reading code.
What does it mean to be a good developer? Do you simply want to write your own black-box undocumented software? Then there is a much lesser advantage to reading other projects' code. On the other hand, if you want to manipulate another codebase, or use another library, reading code is a necessity.
That leaves one final question: Is it beneficial to your own development skill to read others' code? Yes. Proficiently reading others' code is a very beneficial skill, even if you do not intend to write code to be read by someone else. Not only will you get better at reading your own code, you will learn idioms and practices that will improve your comprehension, and writing skill.
If you don't read other people's code, you are stuck understanding things in terms of the idioms of your own comprehension. Moreover, reading code is a skill, and much of being a good developer involves working with other people code, which means being able to efficiently parse other people's code.
I'm not so sure that's a bad thing? If you understand and work well enough, what's wrong with understanding through your own idioms, etc? Of course we read a lot of people's code, but I'm not so sure it's something that needs to be actively practiced rather than done naturally over a career (which makes recommending people to read code pointless if it happens naturally).
If you don't read other people's code, you are stuck understanding things in terms of the idioms of your own comprehension. Moreover, reading code is a skill, and much of being a good developer involves working with other people code, which means being able to efficiently parse other people's code.
I'm not so sure that's a bad thing? If you understand and work well enough, what's wrong with understanding through your own idioms, etc? Of course we read a lot of people's code, but I'm not so sure it's something that needs to be actively practiced rather than done naturally over a career (which makes recommending people to read code pointless if it happens naturally).
But if all you do at work is line of business apps in VB6 for years on end, then I would recommend reading the source code for some games, database servers, your OS kernel, your favorite text editor, or something unrelated to your job. The point is to expand the scope of the projects that you're capable of undertaking.