Global Day of Coderetreat - Attendee Report

Yesterday was my first opportunity to attend a Coderetreat. I am so glad I did. What an amazing day. I think every developer should attend a Coderetreat. Using the closing circle format, allow me to share my experience as an attendee of the Salt Lake City event.

What, if anything, did you learn today?

I learned that I need to slow down and focus on writing code well. The mute session taught me how hard it is to see an architectural vision from the code. It felt like I was painting a picture using the stippling technique and my pair could only see the dots, not the image. I learned that the idea of intention-revealing, self-documenting code cannot be judged by the author only by another developer.
I also learned that Amber Smalltalk is pretty sweet. Thanks, Johnny T!

What, if anything, surprised you today?

The biggest surprise for me was how many developers said the Coderetreat inspired them to go out and actually do TDD. I had expected that most of the attendees would be rather dogmatic about testing and TDD. I know that at several points, I had to remind my pair to write a test before the code.
I was surprised at how far we got and how many tests we wrote in the mute session. It takes a lot of tests to reveal the intent sometimes. We had close to 40 tests when we deleted the folder.
Also surprising was how hard the last session was. We were allowed to pick our own challenge and we really struggled with that. We kind of lost focus and switched challenges midway and by the end, I think we were just coding trying to get as far as we could in the problem.

What, if anything, will you do differently in the future?

I will try harder to value the ideas of others and explore them more deeply. In the last session, my pair told me that was his first session with a bounded world. My pairs and I created a bounded world (array, list, matrix, grid) in every session. I need to open my mind more to alternate ways of accomplishing tasks.
I also need to recognize how attached people can become to the code they write. I had no problem deleting the code I wrote, but more than one person expressed anxiety about it. When others change or remove the code I write, I assume they are improving the application in the best way they understand at that time, so I don't resent the changes. I need to remember that this is not a universally held belief and that changing another developer's code could be considered an insult or attack on them and their abilities.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more