ok. i finally finished the book a couple of days ago. so, here is a list of the remaining practices of an agile developer on agile collaboration:
38. schedule regular face time. use stand-up meetings. stand-up meetings keep the team on the same page. keep the meeting short, focused, and intense.
39. architects must write code. good design evolves from active programmers. real insight comes from active coding. don't use architects who don't code-they can't design without knowing the realities of your system.
40. practice collaborative ownership. emphasize collective ownership of code. rotate developers across different modules and tasks in different areas of the system.
41. be a mentor. knowledge grows when given. there's fun in sharing what you know-you gain as you give. you motivate others to achieve better results. you improve the overall competence of your team.
42. allow people to figure it out. give others a chance to solve problems. point them in the right direction instead of handing them solutions. everyone can learn something in the process.
43. share code only when ready. never check in code that's not ready for others. deliberately checking in code that doesn't compile or pass its unit tests should be considered an act of criminal project negligence.
44. review code. basic styles of review include: the all-nighter with the entire team; the pick-up game where another developer "picks" up the code as soon as the code is ready (rotate developers); and pair programming where one person is the driver, the other navigator and they occasionally switch roles. code reviews are invaluable in improving the quality of the code and keeping the error rate low. if done correctly, reviews can be practical and effective. review code after each task, using different developers.
45. keeps others informed. publish your status, your ideas and the neat things you're looking at. don't wait for others to ask you the status of your work.
resources:
agile developer www.agiledeveloper.com/download.aspx
pragmatic programming www.pragmaticprogrammer.com
up next, version control and subversion! yes, very exciting i know...
Sunday, February 10, 2008
Thursday, February 7, 2008
I Suck At Agile Development (Part 3)
yep, i still suck at agile development as i am still not done with the book.
so, here are some more pointers (about agile feedback, agile coding, and agile debugging):
19. put angels on your shoulders. use automated unit tests. good unit tests warn you about problems immediately. don't make any design or code changes without solid unit tests in place. unit testing provides instant feedback. unit testing makes your code robust. unit testing can be a helpful design tool. unit testing is a confidence booster. unit test can act as probes when solving problems. unit tests are reliable documentation. unit tests are a learning aid.
20. use it before you build it. write tests before writing code. use test driven development (tdd) as a design tool. it will lead you to a more pragmatic and simpler design. (in tdd, you write code only after writing a failing unit test for that code. the test always comes first. usually, the test case fails either because the code under test doesn't yet exist or because it doesn't yet contain the necessary logic to all the test to pass.)
21. different makes a difference. automate to save time. run unit tests on each supported platform and environment combination, using continuous integration tools. actively find problems before they find you.
22. automate acceptance testing. create tests for core business logic. have your customers verify these tests in isolation, and exercise them automatically as part of your general test runs.
23. measure real progress. focus on where you're going. measure how much work is left. don't kid yourself- or your team- with irrelevant metrics. measure the backlog of work to do.
24. listen to users. it's a bug. every complain holds a truth. find the truth, and fix the real problem.
25. program intently and expressively. write code to be clear, not clever. express your intentions clearly to the reader of the code. unreadable code isn't clever.
26. communicate in code. don't comment to cover up. comment to communicate. document code using well-chosen, meaningful names. use comments to describe its purpose and constraints. don't use commenting as a substitute for good code.
27. actively evaluate trade-offs. no best solution. consider performance, convenience, productivity, cost, and time to market. if performance is adequate, then focus on improving the other factors. don't complicate the design for the sake of perceived performance or elegance.
28. code in increments. write code in short edit/build/test cycles. it's better than coding for an extended period of time. you'll create code that's clearer, simpler, and easier to maintain.
29. keep it simple. simple is not simplistic. develop the simplest solution that works. incorporate patterns, principles, and technology only if you have a compelling reason to use them.
30. write cohesive code. keep classes focused and components small. avoid the temptation to build large classes or components or miscellaneous catchall classes.
31. tell, don't ask. keep commands separate from queries. don't take on another object's or component's job. tell it what to do, and stick to your own job.
32. substitute by contract. use inheritance for is-a; use delegation for has-a or uses-a. extend systems by substituting code. add and enhance features by substituting classes that honor the interface contract. delegation is almost always preferable to inheritance.
33. keep a solutions log. don't get burned twice. maintain a log of problems and their solutions. part of fixing a problem is retaining details of the solution so you can find and apply it later.
34. warnings are really errors. treat warnings as errors. checking in code with warnings is just as bad as checking in code with errors or code that fails its tests. no checked-in code should produce any warnings from the build tools.
35. attack problems in isolation. prototype to isolate. separate a problem area from its surroundings when working on it, especially in a large application.
36. report all exceptions. handle or propagate all exceptions. don't suppress them, even temporarily. write your code with the expectation that things will fail.
37. provide useful error messages. provide an easy way to find the details of errors. present as much supporting detail as you can about a problem when it occurs, but don't bury the user with it.
i'm hoping the finish the rest of the book shortly...
so, here are some more pointers (about agile feedback, agile coding, and agile debugging):
19. put angels on your shoulders. use automated unit tests. good unit tests warn you about problems immediately. don't make any design or code changes without solid unit tests in place. unit testing provides instant feedback. unit testing makes your code robust. unit testing can be a helpful design tool. unit testing is a confidence booster. unit test can act as probes when solving problems. unit tests are reliable documentation. unit tests are a learning aid.
20. use it before you build it. write tests before writing code. use test driven development (tdd) as a design tool. it will lead you to a more pragmatic and simpler design. (in tdd, you write code only after writing a failing unit test for that code. the test always comes first. usually, the test case fails either because the code under test doesn't yet exist or because it doesn't yet contain the necessary logic to all the test to pass.)
21. different makes a difference. automate to save time. run unit tests on each supported platform and environment combination, using continuous integration tools. actively find problems before they find you.
22. automate acceptance testing. create tests for core business logic. have your customers verify these tests in isolation, and exercise them automatically as part of your general test runs.
23. measure real progress. focus on where you're going. measure how much work is left. don't kid yourself- or your team- with irrelevant metrics. measure the backlog of work to do.
24. listen to users. it's a bug. every complain holds a truth. find the truth, and fix the real problem.
25. program intently and expressively. write code to be clear, not clever. express your intentions clearly to the reader of the code. unreadable code isn't clever.
26. communicate in code. don't comment to cover up. comment to communicate. document code using well-chosen, meaningful names. use comments to describe its purpose and constraints. don't use commenting as a substitute for good code.
27. actively evaluate trade-offs. no best solution. consider performance, convenience, productivity, cost, and time to market. if performance is adequate, then focus on improving the other factors. don't complicate the design for the sake of perceived performance or elegance.
28. code in increments. write code in short edit/build/test cycles. it's better than coding for an extended period of time. you'll create code that's clearer, simpler, and easier to maintain.
29. keep it simple. simple is not simplistic. develop the simplest solution that works. incorporate patterns, principles, and technology only if you have a compelling reason to use them.
30. write cohesive code. keep classes focused and components small. avoid the temptation to build large classes or components or miscellaneous catchall classes.
31. tell, don't ask. keep commands separate from queries. don't take on another object's or component's job. tell it what to do, and stick to your own job.
32. substitute by contract. use inheritance for is-a; use delegation for has-a or uses-a. extend systems by substituting code. add and enhance features by substituting classes that honor the interface contract. delegation is almost always preferable to inheritance.
33. keep a solutions log. don't get burned twice. maintain a log of problems and their solutions. part of fixing a problem is retaining details of the solution so you can find and apply it later.
34. warnings are really errors. treat warnings as errors. checking in code with warnings is just as bad as checking in code with errors or code that fails its tests. no checked-in code should produce any warnings from the build tools.
35. attack problems in isolation. prototype to isolate. separate a problem area from its surroundings when working on it, especially in a large application.
36. report all exceptions. handle or propagate all exceptions. don't suppress them, even temporarily. write your code with the expectation that things will fail.
37. provide useful error messages. provide an easy way to find the details of errors. present as much supporting detail as you can about a problem when it occurs, but don't bury the user with it.
i'm hoping the finish the rest of the book shortly...
Wednesday, February 6, 2008
I Suck At Agile Development (Part 2)
since i have yet to finish the book my coworker (tim) lent me and thus, still suck at agile development, here are some more lessons:
10. let customers make decisions. decide what you shouldn't decide. developers, managers, or business analysts shouldn't make business-critical decisions. present details to business owners in a language they can understand, and let them make the decision.
11. let design guide, not dictate. design should be only as detailed as needed to implement. a good design is a map; let it evolve. design points you in the right direction. it's not the territory itself; it shouldn't dictate the specific route. don't let the design (or the designer) hold you hostage.
12. justify technology use. blindly picking a framework is like having kids to save taxes. does the technology really solve the problem? will you be tied to this technology? what about maintenance costs? don't build what you can download. choose technology based on need. determine your needs first, and then evaluate the use of technologies for those specific problems. ask critical questions about the use of any technology, and answer them genuinely.
13. keep it releasable. keep your project releasable at all times. ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment's notice.
14. integrate early, integrate often. code integration is a major source of risk. to mitigate that risk, start integration early and continue to do it regularly. never accept big bang integration.
15. automate deployment early. deploy your application automatically from the start. use that deployment to install the application on arbitrary machines with different configurations to test dependencies. qa should test the deployment as well as your application.
16. get frequent feedback using demos. develop in plain sight. keep your application in sight (and in the customer's mind) during development. bring customers together and proactively seek their feedback using demos every week or two.
17. use short iterations, release in increments. develop in increments. release your product with minimal, yet usable, chunks of functionality. within the development of each increment, use an iterative cycle of one to four weeks or so.
18. fixed prices are broken promises. estimate based on real work. let the team actually work on the current project, with the current client, to get realistic estimates. give the client control over their features and budget.
10. let customers make decisions. decide what you shouldn't decide. developers, managers, or business analysts shouldn't make business-critical decisions. present details to business owners in a language they can understand, and let them make the decision.
11. let design guide, not dictate. design should be only as detailed as needed to implement. a good design is a map; let it evolve. design points you in the right direction. it's not the territory itself; it shouldn't dictate the specific route. don't let the design (or the designer) hold you hostage.
12. justify technology use. blindly picking a framework is like having kids to save taxes. does the technology really solve the problem? will you be tied to this technology? what about maintenance costs? don't build what you can download. choose technology based on need. determine your needs first, and then evaluate the use of technologies for those specific problems. ask critical questions about the use of any technology, and answer them genuinely.
13. keep it releasable. keep your project releasable at all times. ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment's notice.
14. integrate early, integrate often. code integration is a major source of risk. to mitigate that risk, start integration early and continue to do it regularly. never accept big bang integration.
15. automate deployment early. deploy your application automatically from the start. use that deployment to install the application on arbitrary machines with different configurations to test dependencies. qa should test the deployment as well as your application.
16. get frequent feedback using demos. develop in plain sight. keep your application in sight (and in the customer's mind) during development. bring customers together and proactively seek their feedback using demos every week or two.
17. use short iterations, release in increments. develop in increments. release your product with minimal, yet usable, chunks of functionality. within the development of each increment, use an iterative cycle of one to four weeks or so.
18. fixed prices are broken promises. estimate based on real work. let the team actually work on the current project, with the current client, to get realistic estimates. give the client control over their features and budget.
Tuesday, February 5, 2008
I Suck At Super Tuesday
before i forget, happy mardi gras! if only i had some beads... if only i had some beads...
anyway, i'm not normally into politics. the presidential race this year, however, has become quite exciting with the closeness of the competition between the potential candidates of both parties. as of right now, the projections are as thus:
for democrats:
clinton is the projected winner in oklahoma, arkansas, tennessee, new york, massachusetts, new jersey, and missouri;
obama is the projected winner in georgia, illinois, delaware, alabama, utah, kansas, north dakota, connecticut, idaho, minnesota;
for republicans:
mccain is the projected winner in new jersey, connecticut, illinois, delaware, new york, oklahoma, and arizona;
huckabee is the projected winner in west virginia, arkansas, alabama and georgia;
romney is the projected winner in massachusetts, utah, and north dakota;
it seems like mccain has all but wrapped up the republican nomination. for the democrats, it still appears too close to call. what is also interesting is that (much like al gore in the 2000 presidential election), it's not the popular vote that actually matters, but the votes of the state delegates. so, it's conceivable that the democratic winner of the popular vote can actually lose the delegate vote (and hence lose the nomination).
anyway, this very exciting day got me thinking... because i suck at super tuesday... how does someone not affiliated with either the democratic or republican party vote in the primary?
here is the answer from my friend... wikipedia:
there are actually types of primaries that vary according to each state, which may/may not allow for unaffiliated people to vote:
in case you are curious, massachusetts is a semi-closed primary... so voters must be affiliated with a party in order to vote in that party's election, but may change enrollment at the polls.
for more information about massachusetts primary voting, go here:
http://answers.yahoo.com/question/index?qid=20080113063653AAtXLTW
so, to answer my original question of "how does someone not affiliated with either the democratic or republican party vote in the primary?", the gist of the answer is as follows:
If you are a registered voter and your political party designation is "unaffiliated," then on election day you may choose whichever party ballot you wish to vote on (i.e., Republican or Democrat). For the presidential primary, I believe you must then switch your designation back to "unaffiliated" after you vote, which you can do at the polling place when you check out. I believe if you don't do this then you will now be a member of the party you just voted.
Also, remember there is an "independent" party now, I believe you must be "unaffiliated" to be able to pick your ballot, not "independent."
anyway, i'm not normally into politics. the presidential race this year, however, has become quite exciting with the closeness of the competition between the potential candidates of both parties. as of right now, the projections are as thus:
for democrats:
clinton is the projected winner in oklahoma, arkansas, tennessee, new york, massachusetts, new jersey, and missouri;
obama is the projected winner in georgia, illinois, delaware, alabama, utah, kansas, north dakota, connecticut, idaho, minnesota;
for republicans:
mccain is the projected winner in new jersey, connecticut, illinois, delaware, new york, oklahoma, and arizona;
huckabee is the projected winner in west virginia, arkansas, alabama and georgia;
romney is the projected winner in massachusetts, utah, and north dakota;
it seems like mccain has all but wrapped up the republican nomination. for the democrats, it still appears too close to call. what is also interesting is that (much like al gore in the 2000 presidential election), it's not the popular vote that actually matters, but the votes of the state delegates. so, it's conceivable that the democratic winner of the popular vote can actually lose the delegate vote (and hence lose the nomination).
anyway, this very exciting day got me thinking... because i suck at super tuesday... how does someone not affiliated with either the democratic or republican party vote in the primary?
here is the answer from my friend... wikipedia:
there are actually types of primaries that vary according to each state, which may/may not allow for unaffiliated people to vote:
- Closed. Voters may vote in a party's primary only if they are registered members of that party. Independents cannot participate. Note that due to the appropriation of the term "independent" by some political parties, the term "non-partisan" is often used to refer to those who are not affiliated with a political party.
- Semi-closed. As in closed primaries, registered party members can vote only in their own party's primary. Semi-closed systems, however, allow unaffiliated voters to participate as well. Depending on the state, independents either make their choice of party primary privately, inside the voting booth, or publicly, by registering with any party on Election Day.
- Open. A registered voter may vote in any party primary regardless of his or her own party affiliation. When voters do not pre-register with a party before the primary, it is called a pick-a-party primary because the voter can select which party's primary he or she wishes to vote in on election day. Because of the open nature of this system, a practice known as "raiding" may occur. "Raiding" consists of voters of one party crossing over and voting in the primary of another party. Although no cases can be shown where this has happened successfully, the theory is that opposing party members vote for the weakest candidate of the opposite party in order to give their own party the advantage in the general election.
- Semi-open. All voters may vote in any single primary, but must publicly declare which primary they will vote in before entering the voting booth. Typically this declaration is accomplished by requesting a ballot. In many states with semi-open primaries, election officials record each voter's choice of party and provide the parties access to the information.
- Blanket. This system allows voters to vote for one candidate per office, regardless of which party they were a member of.
- Run-off. A primary in which the ballot is not restricted to one party and the top two candidates advance to the general election regardless of party affiliation. (A runoff differs from a primary in that a second round is only needed if no candidate gains a majority in the first round.)
in case you are curious, massachusetts is a semi-closed primary... so voters must be affiliated with a party in order to vote in that party's election, but may change enrollment at the polls.
for more information about massachusetts primary voting, go here:
http://answers.yahoo.com/question/index?qid=20080113063653AAtXLTW
so, to answer my original question of "how does someone not affiliated with either the democratic or republican party vote in the primary?", the gist of the answer is as follows:
If you are a registered voter and your political party designation is "unaffiliated," then on election day you may choose whichever party ballot you wish to vote on (i.e., Republican or Democrat). For the presidential primary, I believe you must then switch your designation back to "unaffiliated" after you vote, which you can do at the polling place when you check out. I believe if you don't do this then you will now be a member of the party you just voted.
Also, remember there is an "independent" party now, I believe you must be "unaffiliated" to be able to pick your ballot, not "independent."
Monday, February 4, 2008
I Suck At Agile Development (Part 1)
my coworker (tim) lent me a book to read which he thought i would enjoy. the book is called "practices of an agile developer" by the pragmatic programmers venkat subramaniam and andy hunt. basically, the book is a collection of best practices for... being an agile developer... which is of particular use for software developers in the ever changing environment of technology. and by agile, i don't mean doing cartwheels or somersaults... although that would be interesting. agile, in this sense, refers to the ability to adapt to situations.
to many who are not into software developing, this content would normally sound pretty dull. some lessons, however, actually translate well into the non-software developing area. since i suck at agile development, here are some of the lessons thus far:
1. work for outcome: blame doesn't fix bugs. instead of pointing fingers, point to possible solutions. it's the positive outcome that counts.
2. quick fixes become quicksand: beware of land mines; don't code in isolation; use unit tests; don't fall for the quick hack. invest the energy to keep code clean and out in the open.
3. criticize ideas, not people: negativity kills innovation; set a deadline; argue the opposite; use a mediator; support the decision; take pride in arriving at a solution rather than proving whose idea is better.
4. damn the torpedoes, go ahead: do what's right. be honest, and have the courage to communicate the truth. it may be difficult at times; that's why it takes courage.
5. keep up with change: learn iteratively and incrementally; get the latest buzz; attend local user groups; attend workshops or conferences; read voraciously; you don't have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.
6. invest in your team: raise the bar for you and your team. use brown-bag sessions to increase everyone's knowledge and skills and help bring people together. get the team excited about technologies or techniques that will benefit your project.
7. know when to unlearn: expensive mental models aren't discarded lightly. learn the new; unlearn the old. when learning a new technology, unlearn any old habits that might hold you back. after all, there's much more to a car than just a horseless carriage.
8. question until you understand: keep asking why. don't just accept what you're told at face value. keep questioning until you understand the root of the issue.
9. feel the rhythm: tackle tasks before they bunch up. it's easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events.
i have yet to finish the rest of the book, but so far... i would recommend the book to anyone. it's easy to read and the concepts make sense. i will post more lessons as soon as i get to it...
to many who are not into software developing, this content would normally sound pretty dull. some lessons, however, actually translate well into the non-software developing area. since i suck at agile development, here are some of the lessons thus far:
1. work for outcome: blame doesn't fix bugs. instead of pointing fingers, point to possible solutions. it's the positive outcome that counts.
2. quick fixes become quicksand: beware of land mines; don't code in isolation; use unit tests; don't fall for the quick hack. invest the energy to keep code clean and out in the open.
3. criticize ideas, not people: negativity kills innovation; set a deadline; argue the opposite; use a mediator; support the decision; take pride in arriving at a solution rather than proving whose idea is better.
4. damn the torpedoes, go ahead: do what's right. be honest, and have the courage to communicate the truth. it may be difficult at times; that's why it takes courage.
5. keep up with change: learn iteratively and incrementally; get the latest buzz; attend local user groups; attend workshops or conferences; read voraciously; you don't have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.
6. invest in your team: raise the bar for you and your team. use brown-bag sessions to increase everyone's knowledge and skills and help bring people together. get the team excited about technologies or techniques that will benefit your project.
7. know when to unlearn: expensive mental models aren't discarded lightly. learn the new; unlearn the old. when learning a new technology, unlearn any old habits that might hold you back. after all, there's much more to a car than just a horseless carriage.
8. question until you understand: keep asking why. don't just accept what you're told at face value. keep questioning until you understand the root of the issue.
9. feel the rhythm: tackle tasks before they bunch up. it's easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events.
i have yet to finish the rest of the book, but so far... i would recommend the book to anyone. it's easy to read and the concepts make sense. i will post more lessons as soon as i get to it...
Sunday, February 3, 2008
I Suck At The SuperBowl
it's a going to be a very sad few days here in new england.
the new york giants have just upset the new england patriots in superbowl 42 by a score of 17-14. it's most unfortunate because everyone will always remember the superbowl loss and not the extraordinary season the patriots had in 2007. the patriots went 16-0 in the regular season; 2-1 in the playoffs. that feat has never been done in the modern era of professional football and it should be remembered regardless of the whole "spygate" incident.
needless to say, the giants deserve the win. they outplayed the patriots and were more "hungrier" for the victory than the patriots. apparently, plaxico burress was correct in predicting the giants victory and he was pretty close at predicting the final score too of 23-17. the dreadful offensive performance by the patriots should make brady eat his words when he scoffed at burress's prediction and retorted "we're only going to score 17 points? ok. is plax playing defense? i wish he said 45-42 and gave us a little credit for scoring more points."
as it turns out, there was no need to give the new england patriot offense credit for scoring more points because tom brady and the patriot offense sucked at the superbowl. i blame gisele...
the new york giants have just upset the new england patriots in superbowl 42 by a score of 17-14. it's most unfortunate because everyone will always remember the superbowl loss and not the extraordinary season the patriots had in 2007. the patriots went 16-0 in the regular season; 2-1 in the playoffs. that feat has never been done in the modern era of professional football and it should be remembered regardless of the whole "spygate" incident.
needless to say, the giants deserve the win. they outplayed the patriots and were more "hungrier" for the victory than the patriots. apparently, plaxico burress was correct in predicting the giants victory and he was pretty close at predicting the final score too of 23-17. the dreadful offensive performance by the patriots should make brady eat his words when he scoffed at burress's prediction and retorted "we're only going to score 17 points? ok. is plax playing defense? i wish he said 45-42 and gave us a little credit for scoring more points."
as it turns out, there was no need to give the new england patriot offense credit for scoring more points because tom brady and the patriot offense sucked at the superbowl. i blame gisele...
Saturday, February 2, 2008
I Suck At Hanging Out With Ron
last night, i went to the bbc (british beer company) in pembroke to meet up with some friends. the whole thing came about almost spontaneously. i have this friend (ron) who, as it turns out, i haven't seen for almost a year. the last time i saw him was the last super bowl weekend. it's amazing how time flies and before you know it, it's been x amount of time since you last saw so-and-so.
anyway, i've known ron for a long time... since childhood. in fact, i think he may be one of the few people who have never annoyed me... ever. (it's a select few and i consider myself a patient person). ron, incidentally, lives in the next town over so it's not like he's that far from me. he's got a great family: his parents are great; his wife is awesome; his daughters are adorable. he has done very well for himself and deservedly so.
out of blue, ron contacted me to get together and catch up. naturally, i jumped at the chance and gathered some friends together. we ended up at the bbc, where as it turns out... the cover band that was playing there was also scheduled to play at the restaurant owned by my other friend (garv). garv, of course, wanted to scope them out. needless to say, the groupies were fun to party with and i had a great time. i think ron had a great time too because he suggested that all of us do this more often as he hadn't gone out in quite a while to just "hang out".
naturally, it got me thinking... i suck at hanging out with ron. how come, in the past, i haven't done this more often with him? like i said, he's in the next town over. we should have been hanging out and having fun. i think i'll have to try and work on that... before it becomes another year (near superbowl weekend) that i see him again.
anyway, i've known ron for a long time... since childhood. in fact, i think he may be one of the few people who have never annoyed me... ever. (it's a select few and i consider myself a patient person). ron, incidentally, lives in the next town over so it's not like he's that far from me. he's got a great family: his parents are great; his wife is awesome; his daughters are adorable. he has done very well for himself and deservedly so.
out of blue, ron contacted me to get together and catch up. naturally, i jumped at the chance and gathered some friends together. we ended up at the bbc, where as it turns out... the cover band that was playing there was also scheduled to play at the restaurant owned by my other friend (garv). garv, of course, wanted to scope them out. needless to say, the groupies were fun to party with and i had a great time. i think ron had a great time too because he suggested that all of us do this more often as he hadn't gone out in quite a while to just "hang out".
naturally, it got me thinking... i suck at hanging out with ron. how come, in the past, i haven't done this more often with him? like i said, he's in the next town over. we should have been hanging out and having fun. i think i'll have to try and work on that... before it becomes another year (near superbowl weekend) that i see him again.
Subscribe to:
Posts (Atom)