How do you guys approach abstractions when reading code?
tirrellp: You get better at code by reading code.That being said, I have NEVER been good at pouring through lines of code to figure out whats going on.  Others seem to be exceedingly good at it.  The closest analogy that comes to mind is music.  Some can read music really well and play from sheet music, others play by ear or by 'picking apart' a song.  I have always had to step through with a debugger and/or read the documentation (if it exists) to get a sense of what is going on.I guess thats why I comment my own code so much, because at the time I am creating it and living in it day to day, I know exactly whats going on... its "in my head" so to speak, but if i take a few weeks off, I am cursing myself for not having commented what was going on, or at least the intent, especially for the hairy/unfinished/broken parts.There are some who dont comment because they are so good at reading code, they dont even think about it.  There are still others who say, "If a fellow coder cant figure out whats going on by looking at the code and ONLY the code, then (s)he sucks", and another camp who want to comment every single line.  YMMV on that one.  To each his own, but I am in favor of a reasonable level of commenting.Bringing my point back from the brink, here is an story for you:  In my 9 to 5 (project manager), I do very little coding anymore, but we always talk about stuff like agility and customer centricity.  There was an issue with my team where half the people thought comments were superflous and the other half wanted to see more comments as part of 'sound engineering practices.'  As the unbiased outsider, I told the team this, "We talk about reacting to customers needs and putting in features, fixing bugs, increasing usability, better user documentation, etc to meet that goal.  You should consider your team mates as customers, and you have an unmet customer need in that you have a customer who is asking for more code comments.  In the end, if it helps the team work better together, then the 5 minutes you take to at least comment the 'intent' or 'high level algorithm' of a method will go a long way when 3 years from now some intern is trying to figure out where the null pointer is coming from.From the standpoint of open source projects, documentation is something I see popup a lot on sourceforge when projects are looking for help.  However, if a person is good enough at reading code with no comments to gain an understanding and write the documentation, they would probably much rather code up a new feature than comment/document.Code almost always runs the risk of becoming unecessarily complex, and there is always a balance to be struck between YAGNI and 'flexible architecture'.  I like to lean in the direction of YAGNI, because most often the assumptions you made about future state to build in flexibility were WRONG, and its a lot easier to refactor for the present than it is to architect 'for the future'