The CodeRush IVBUG Presentation & Model View Presenter Video
A couple of weeks ago I did a presentation on how I use CodeRush and Refactor! Pro to improve my coding experience. In this post I am going to reflect a little (or much) about what preceded that presentation and the video that came after it.
If you came here just for the video you can find it here. But a few words about the video first:
- I used Camtasia to record my rehearsals for a presentation. In other words, the outcome of the coding session was known and I didn't have to make any design decisions while coding. Every rehearsal turned out a little different, but I was on autopilot. I don't code like that when I have to think. I can often ponder for a significant time on the name of a method.
- The purpose of the video is not to teach you MVP.
- The purpose of the video is not to teach you CodeRush.
- I touch type, but I'm only a decent typist at about 60 wpm.
- I decided to learn to touch type while at University. I spent 30 hours total to learn to touch type.
- While I believe coding efficiency is important, it's only one factor in developing solid software. I have seen people code crap at the speed of light. Giving these programmers CodeRush is a crime.
- Why CodeRush and not R#(ReSharper)? Because I know CodeRush. If I knew neither I would evaluate both.
So what was my purpose with the Video? I strongly believe that tools like CodeRush and R# are not optional add-ins for Visual Studio, but required for everyone coding for a living. I figured that if I did a tutorial it wouldn't get much attention. So I coded away, almost as fast as I can, and added some cool music to make you say "Wow" and get interested in the tools. If you don't use CodeRush or R# and you are a developer my aim is to encourage you to look at these tools. They will make you a better developer. (More on that later in this post)
Now that the Code Monkeys are gone (they came only for the video) I'll try to elaborate on the presentation and some important after-thoughts.
Prelude
For the last 3 years I have been working for Renaissance Computer Systems. Renaissance's CEO Jackie Goldstein is the coordinator of the monthly IVBUG (Israel Visual Basic User Group) meetings. Every now and then we have talked about the content, the past and the future of these meetings. The presenters are dominated by either professional speakers or consultants who speak about their areas of expertise as opposed to presentations by the participants of the group. Some of the smartest people I know are not in the business of going on stage and talking in front of an audience. They do their jobs quietly behind closed curtains. Besides their team members, employers and satisfied customers, you and I don't get to learn from their talent and experience. So how do you break this evil circle? You go on stage yourself and hope that it will encourage others to follow.
The Preparation
Ok, I'll admit that Jackie had to convince me to do it. Not that I'm shy, but I'm not a stage person. Truth is, I love to be on stage, but I can't eat or sleep the last 24 hours before the presentation because of the excitement.
While the video is only 18 minutes, the presentation was 90 minutes. I knew I wanted to do a presentation on CodeRush. The hard part was to figure out how to do it. Doing a feature centric presentation with a mix of small samples didn't appeal to me. I wanted the participants to walk away with both a presentation and some useful code and coding principles.
I first decided on using a scenario from Peter C. Martins' book Agile Principles, Patterns, and Practices in C# where two developers develop a Prime Number calculation. He takes you through the coding thought process and it's pretty cool. I figured that not too many of us care about prime numbers. So I trashed that one.
Here at Renaissance we have been using MVP for UI development successfully for a long time. I decided that I'll go with that and prepared 3 slides on MVP and was ready to skip them if the majority of the audience were proficient with the pattern.
I quickly decided on the sample and had it up and running in about 30 minutes. That is 10 minutes longer than the video session. I rehearsed the email sample a few times and felt that I had it under control.
I had one fear though. What if I freeze on stage? What if I forget what to do? What if I get a compile error and can't figure it out in front of the audience? (I have seen this happen to experienced speakers.) I tried to think of how to create some synthetic stress factor that would make me more prepared for the presentation. The solution for me was to record the coding session. I was really surprised how much the anxiety level rose from the fact that I was recording. During the first recording I had to stop after 1 minute because I couldn't remember how to continue. After a couple of recordings the fact that I was recording didn't affect me much.
The Presentation
I didn't know how many in the audience would be familiar with CodeRush and/or MVP. I was surprised on both polls of the audience. Only a couple had working knowledge of MVP and no-one used CodeRush. I had to spend more time than expected on explaining the purpose and workings of MVP. I then coded through the email sample while explaining almost every key stroke and every method. The hardest part was to go slow.
At the end of the meeting we raffled off a subscription to CodeRush and Refactor! Pro. The license was given by DevExpress. To see who the happy winner is go here.
Post Presentation
In retrospect I found that the fact that so few in the audience knew about MVP bothered me a lot. I can accept the fact that people don't use CodeRush or R#. The tooling industry is so crowded that it's impossible to be familiar with every productivity tool out there. But not being familiar with well known design patterns, the basic pillars of development, is - let's just call it - surprising to me. I am generalizing here. But I guess that if you haven't heard of MVP, then Template method, State/strategy, Abstract Factory, Mediator and others are not in your development arsenal as well. If you were at the presentation and this does not apply to you, I apologize. Maybe you just never do UI development.
A thought that crossed my mind was if there was anything I could do to change this. I decided to create a video recording of the presentation sample and post it online.
I created a first draft and sent it to Mark Miller, the chief architect of .NET productivity tools at DevExpress. I asked him to comment on my usage of CodeRush and Refactor! Pro. He took the time to go through the video and returned his comments. So this way I learnt something as well. I incorporated some of the comments, others I will have to digest at my own pace.
After that Jackie agreed to post the video on the company web site. Julian from DevExpress also has some comments about he video.
Final Thoughts
You might ask yourself, why does he think coding productivity is so important. Time being a limited resource, he (that being me) obviously has spent some significant time learning the tools. There's more to coding productivity tools than speed. Coding productivity tools like CodeRush offload your brain when you code. Compare it to writing an important letter with a pen on paper. Every time you make a mistake you will have to start over or try to cover your mistake on the original paper. Compare this with writing the same letter in a word processor. Compared to the paper solution, it's cheap to err in a word processor. You can go at a higher speed, but that's not the major benefit. The major benefit is that because you don't have to be anxious about making mistakes, you can let your brain and intuition flow in a more efficient way. Don't like what you just did, correct it. Move a paragraph etc.
The same goes for coding. Are you coding against an implementation? Need an abstraction? It's there at the click of a button. See some old code with bad identifier names? At the click of a button (or keystroke) you can rename and update all references. Next time around that corner of code you have your refactored names and don't have to struggle. It takes some time to learn, but the CodeRush learning window will guide you through your coding presenting only the valid options based on the location of the Caret. I still pull up the learning window every now and then to see if I can pick up something new.
While we don't practice strict TDD at Renaissance tools like CodeRush is a real time saver when writing tests first. You can shape your API in the tests and then have CodeRush generate them.
P.S
I'm originally from Norway and have (still) spent most of my life there. I thinks it's cool that a Dane has linked to the video.
Takk skal du ha. Dersom du har noen korreksjoner eller forbedringer vil jeg gjerne se dem.
Update: The source from the video can be downloaded here.