Innovation Fridays - Learn C#
Internally, my company has experienced a push to get 'Innovation Fridays' started up again. Every month developers are given a 4 hour period to pursue various projects or learning. For this block of time, the Automated Test Scripting team, ATS for short had been interested in learning how to write and use C#. Given my familiarity with the Team, and my knowledge of the language, they asked if I would be willing to lead a workshop on it. Naturally I couldn't refuse such a request from friends, and moreover, I knew this would be a chance to strengthen my core on C#. As everyone knows, to teach something is to learn it far better than when you first were taught. I figured that my workshop plan, while good, had some chinks in its armor and that it might also make interesting reading. So for the purpose of getting some additional insight and for the freedom of information I decided to post a series on my plans and activities relating to the workshop. Now before I start, I want to express that I have a good deal of experience in running workshops on a variety of topics, including some rather technical ones. I somehow got into doing this when I was in high school, wherein I would help teach Tae Kwon Do to kindergartens, while working on my black-belt and after. Further, while in College I was blessed with an A in Calculus-based Physics, and so was asked by an enrichment program to lead a Physics workshop, which I did every semester for perhaps 3 years or so, until I graduated. I very much enjoyed the work, and was blessed with some help paying for school by it. Among the most enjoyable was creating questions and problems for the students to work on, especially in Mechanical Physics. However I found that for the majority, the workshop was not totally ideal, since it must keep pace with the class. And sadly, many students could not keep up with the class in the first place. This is perhaps the single biggest obstacle that I am working to overcome with my present workshop plan. Overall, I am planning to follow the recommendations made by Josh Kaufman in his 20 Hours TED talk, which I have mentioned before. Naturally I think the four steps are very well suited for learning C#, so my workshops will generally be focused on one or perhaps at most two of these steps at a time.With any luck, I will run these for the next 6 months or so, and have our learning concluded by that time. However for the first workshop which occurred last Friday, most of our time was spent on step 2, or Learning Enough to Self-Correct, and on deciding on project infrastructure. For this discussion I will talk more about the project infrastructure, and perhaps will elaborate more on the learning portion at a later time. Now, getting back to the obstacle I mentioned earlier. Everyone on the ATS team is at different levels of skill, which means each will need a different levels of instruction and will be able to accomplish different amounts in the same time. So to support the needs of the high-performing team members, while maintaining the approach-ability for those who need more guidance, I elected to pursue Project based learning as the workshop model. On this topic, I put the team size and project type to a vote. It was decided that, for the most part, everyone would pursue their own project. As a result we have 6 teams, for 7 people. As to the projects they are covering, those are somewhat less varied as there are 4 different projects at the moment. They are as follows:
- A Sudoku Game application
- A Music Player
- A Rich-Text-Format Text Editor
- An internal Installation tool for our Company's Software
Of course, you can see that each of these will have different technical challenges, but also each has some elements of similarity. For instance many of these will need File Access, and each will need some component of UI. As a result these projects cover a breadth of topics making them good candidates for learning C#, while still maintaining some common ground for group discussions. To make things easier on myself, I have had all the teams setup the following organization for their projects, so that we can work with others more easily. Every Team project will have at least 4 separate Code Projects( the place where code is dropped in Visual Studios Solutions). These are the Infrastructure, the UI layer, and the test associated with both. By separating the Infrastructure from the UI, I am hoping to provide the necessary grounds for following better design principles. Of course with how small these projects will be, It may feel somewhat silly to have all this extra separation. But since the purpose of this workshop is not simply to write the Project and get it done, but is instead to learn how to write C# well, I think it is a fair trade-off. If we are going to be working so that our project structures are similar, it would make sense to ensure we are all using the same tools. And sadly, since most of our participants are using personal laptops, they don't have easy access to the Company WiFi, or the source-control servers, which means we needed another place to store our code. This way the projects could be shared between teams when the time came. For this I have selected Github, as I am familiar with it due to personal side projects, and because it would be free to access for all involved. All I would have to do would be to add the ATS team as contributors to the selected Repo. For those of you who are also familiar with Github, you should recognize that git is very Command Line heavy without a GUI. So to make the transition easier for the team, I had them all download GitKraken, which is my preferred GUI for Github. So far, this has seemed to make the process much easier. But I will know more when we next met about a month from now. Lastly, no code project would be complete without an IDE. And for this we turned to Microsoft Visual Studios community edition. We have a mix of 2013 and 2015, since that is what the team members were able to find. I am hoping that this will not cause problems later on when the projects are viewed by other teams, but we shall cross that bridge when we come to it. So during our first meeting, we covered all of the project set-up minutia, and some of the basic principles that I am hoping to pass on. I will share this in my next Innovation Friday post. These will likely include the various links that I used and other references that I find to be very useful! In the meantime, I would love to hear any suggestions or ideas you have! After all, I only had my experience and my gut to go on, and I am certain I might have overlooked some great opportunities!