This was my first unconference, my first Ruby conference, and really my first programming event that was primarily in the open source space. That’s probably too much to go over in one post, so I’ll try to talk about the event over several posts with some logical division.
There seem to be four topics here:
- What an unconference even is
- My impressions of the Ruby community
- Terms and concepts I heard of for the first time
- Concrete advice and information that I got from the conference
I’m going to treat these topics in reverse order. There was a lot of good advice at the event, and I want to capture as much of that as I can. The book recommendations will probably be in separate posts.
One major piece of advice was “use side projects as your primary tool for learning.” I think a great example of following this advice comes from this post. His first programming project was building a website for a magazine he worked on in grad school. My first project was building a little program that would format vocabulary quizzes for me. I think the distinction here is that we don’t learn programming by locking ourselves in the attic for 24 days with a copy of “Learn Java in 24 Days.” Instead, we iteratively tinker, communicate, and improve. To learn quickly, we need to do the thing we’re trying to learn, not read merely read about the thing we’re trying to learn. We need to watch our input/output ratios. It was also very comforting to hear people who are quite senior and successful Ruby developers recommend writing side projects. I’ll have to come up with a good Ruby side project and write about it here.
Specs and Spikes
One of the other attendees made a distinction I hadn’t heard before: If you’re building a specific, well-defined feature, writing a spec, and tests, and code, and following the usual pattern is a good procedure. But if you’re trying to make a tool easier to use, or otherwise making improvements that are not well-specified, making spikes is more useful. Someone added that “a spike is a rough draft.” I think that’s the best term for explaining what spikes are that I’ve ever heard: we don’t know whether this feature will work, so we’re going to write a rough draft of part of it, then see where we are.
One particular technique presented was writing a spike until the desired behavior becomes clear, then writing good tests, then refactoring or even re-writing the code from the spike. Deciding whether to spike based on how predictably some code can be specified upfront seems like good advice, and I look forward to a change to try it out.
Zones and Communication
Some of the most interesting discussion was in a conversation on Domain Driven Design, but this conversation was also some of the hardest to distill into concrete advice. I think I will need to go read the Domain Drive Design book at some point, but in the meantime, one of sentences that sticks out was to the effect of “make zones where people can write whatever they want.” I needed to understand this sentence by contrast: If I’m trying to write some method, and I have to worry a ton about instance variables that other methods care about, and about different callers with different parameters, and about different return values for different callers, I’m not writing whatever I want. It seems likely that I’m not writing whatever I want because I’m crossing logical boundaries in the business domain I’m working in. For example, the accounting code cares how much line items cost, and the shipping code cares how much line items weigh, and if I’m in code that is worried about weights and costs I’m failing to respect a natural divide in the business domain. This respect for the logical divisions of the business domain is definitely worth thinking about.
Only One Test Should Fail
If I have one bug that blows up 27 integration tests and 35 unit tests, there’s strong evidence that some pieces of code are getting exercised too often.
I’ve always heard test coverage talked about only in terms of having enough tests. People speak as though more tests are always good. I think that this is a side effect of the fact that many testing talks are directed at people who are reluctant to write tests. But it was very interesting to hear the danger pointed out in testing too many things redundantly. This topic probably deserves its own entire post in the future.
Anyway, it was a great conference, and I’ll be writing more about it soon.
Till next time, happy learning!