5 ms·

In my experience, writing a lot of your own code teaches you MUCH more about good design than looking at others'. Most of the design process is actually in the

by psyklic 18y ago

In my experience, writing a lot of your own code teaches you MUCH more about good design than looking at others'. Most of the design process is actually in the reasoning behind WHY a certain process was employed, which is not easily evident from code alone! But since you asked: (1) Run the code and understand what the software DOES. If a library, write a driver program which tries out most of the functions. (2) Look at the high-level classes (or the major organizational structures, e.g. source files) and figure out the purpose of each (e.g. CLogger -> logs errors to a file or the display) (3a) (the fun way) Come up with a cool, simple feature you'd like to add, or something simple you'd like to change. Do it. Repeat. -OR- (3b) (the boring way) Find the main() function and step through the code with a debugger, stepping over function calls which are self-explanatory. Step into ones you're unsure about. In reality, this all depends on how well the code is written. Understanding some code just isn't worth the price of admission.

nostrademons 18y ago
You can't do either in isolation. If you just write code, you end up ghettoizing yourself into a style that works for you but has little to do with how others program, and misses out on all the nifty tricks they've discovered. If you just read code, you don't understand why the author employed the tricks they did, as you say. I usually alternate between the two: find a good piece of code. Then try to modify it to do something different. Then look at the style of the code around the parts you touched, and see if there's a better way to do your modification. Then modify something else in the general vicinity, and repeat. When I started at Google, I basically just hacked the Google webserver to display "Hello world" in various parts of the result page until I understood what it was doing enough to start contributing to my team.

by psyklic 18y ago

nostrademons 18y ago

You can't do either in isolation. If you just write code, you end up ghettoizing yourself into a style that works for you but has little to do with how others program, and misses out on all the nifty tricks they've discovered. If you just read code, you don't understand why the author employed the tricks they did, as you say. I usually alternate between the two: find a good piece of code. Then try to modify it to do something different. Then look at the style of the code around the parts you touched, and see if there's a better way to do your modification. Then modify something else in the general vicinity, and repeat. When I started at Google, I basically just hacked the Google webserver to display "Hello world" in various parts of the result page until I understood what it was doing enough to start contributing to my team.