Programming Update

Today was New England Code Camp 11: Developer Stimulus Package. What an awesome name. Thanks to Chris Bowen for organizing it. Unfortunately for me, I could only stay for the first four sessions. Got to learn about Silverlight, F#, and .NET 4.0. As always, Richard Hale Shaw was excellent, and Andy Beaulieu was also quite good. Fun times for all.

These programming conventions always give me extra energy for working on projects. This one came at a great time, because I had stopped work on Walrus since all of my fantasy baseball teams had already drafted. I now know (thanks to RHS) how F# really fits in, and how to use it as a library extension to my C# projects. Yay!

I also need to work on smaller projects. Things I can build quickly and learn small things at once. I plan to build an ASP.NET MVC app soon, but it has to be super simple so I can get it out the door fast. Maybe I'll build a blog. Easy, but somewhat boring. I haven't thought this through yet.

Nick is also urging me on, mostly by blogging and conversations on the train. He's on Twitter now at @nswarr, so you can follow him if you want. Eric always gets mad points for energy boosts. 

Any ideas for what to put on edschwehm.com?

The Balance Between Safety and Speed; or, Does the Turtle Really Beat the Rabbit?

Eric and I argue about programming all the time and about every little thing, but we're really just arguing about one thing. I value safety, and he values speed. Let me elaborate.

The safety I'm talking about is making sure my code works right. I'm for strong typing because it can help find errors at compile time. I believe that databases have to enforce their constraints as best they can even if you're the only client. I prefer centralized version control (CVCS) over distributed version control (DVCS) because the restrictions CVCS enforces promote healthy branching and code. I believe in continuous integration, including full unit and integration tests.

The speed Eric talks about is being able to write "5.times.per.day" in Ruby and have it just work the way you expect. Eric loves git because he's able to get input seamlessly from developers around the world and easily integrate new code. And he loves easily discoverable features of his languages of choice.

Most of the time, the programming context determines the value of the two assets. Building a mission-critical app that handles financial data? Safety rules the day. Building a site to determine if it is Christmas or not? Speed please.

Programmer personality also is a significant factor. I know I make mistakes, so I prefer to use tools that prevent/detect said mistakes. I also know that others might use my code at some point, and as anyone who has ever worked with someone else knows, other people are dumb.

The reason I just started writing about this was because I had to change a "Thread.Sleep" call in one of my integration tests from 2 seconds to 5 seconds. To make this change and formally deploy the code to my project's development environment, I had to run the code through the entire 12 minute build process. And that's AFTER running the unit tests locally (5 more minutes). It would've been so nice to circumvent the whole process. And I wanted so much to do just that! But I held fast to my rules, and now I know the published package built from that build is ready to be released to QA.