Not so long ago, in a galaxy not so far away... 

1. Microsoft announced the .NET framework.
2. This cool dude, Miguel de Icaza, thought .NET rocked (pun relating to the excellent podcast, ".NET Rocks" fully intended), and began experimenting with creating a Linux version of .NET. 
3. Approximately one year after .NET came out, the Mono open source project spawned from Miguel's experimentation.
4. There were some questionable years, where Mono's future was uncertain, but nevertheless, it persisted, and ultimately became Xamarin in 2011.

For the next 5 years, Xamarin was, in my opinion, prohibitively expensive. Back then the Windows Phone was still a thing (along side iOS and Android), and if you wanted to develop apps for all 3 major platforms it would cost you $1,000 per year, per platform, per developer. I was not a mobile developer at my job, so without a company paying for that huge license fee, I wasn't ready to cough up $3,000/year to tinker around in my spare time. My tinker-budget is substantially smaller than that.

Then... And I can't believe I'm saying this... Microsoft saved the day. In February, 2016, Microsoft acquired Xamarin, and promptly made it free for everyone. This is definitely not the same Microsoft it used to be, and the change I've seen over the past 5 years has been extremely positive.

I have always been a big fan of tools that enable cross-platform development, and here was a framework that was promising to enable me to use my favorite language, C#, and xaml for the UI, to build mobile apps for both iOS, Android, and other devices. Re-energized, I once more started trying to move my career into the mobile side of things, leaving my comfort-zone of the web and desktop development in the dust.

Fast-forward to the present day, and I am now using Xamarin to create mobile apps both at work and in my spare time, and I absolutely love it. It is still very young, and so there are frustrations you will run into, for sure. That being said, as a developer trying to create something new, you almost always hit some road-blocks here and again, even with frameworks that are quite a bit more mature.

To introduce you to Android/iOS development with Xamarin.Forms, I've created a small tutorial. In it, you will learn the basics of Xamarin.Forms, the MVVM design pattern, and dependency injection using Prism and the Unity inversion of control container.

• You can grab the tutorial on clarify-it.com 
• A completed version of the tutorial is available on GitHub 

If you run into any issues or questions, please feel free to ask about it in the comments. Let me know what you like and dislike, and if you have ideas of how I might make these tutorials more valuable to developers. I hope this will get you up and running with Xamarin.Forms, Prism, and Unity IoC.

Happy coding!

Most software teams I've had the chance to work or interact with have at least some degree of trouble regarding "knowledge silos". You know you have an issue with silos on your team when work grinds to a halt if a particular developer is out sick, or on vacation. You know you have a silo when one top developer is doling out work to less senior developers while not giving any of them enough of the big picture to truly understand how their part of the code/project works with others. When they finish their small task, they have to get back in line to see what needs to happen next. You know you have a silo when one of your team members is afraid to take a vacation, because everything will fall apart without them there. You know you have a silo when you send an employee to an expensive conference, but s/he winds up answering emails or putting out fires no one else can half the time, vastly reducing the benefits that might be gained from the conference.

Some software teams try to mitigate the risk of knowledge silos by practicing "pair programming" (the folks over at Atlassian may have the most entertaining take on this). Two developers work at a single computer, working on the same feature or issue. There are a number of potential advantages: Someone else is always reviewing your code as you go, so there is no need for a separate code review later on. Your partner is just as familiar as you are with every change you make, so when one of you is sick or on vacation, the rest of the team is not stuck in the mud. When one member of a pair knows more about something, the other gets the opportunity to learn (meanwhile the more experienced developer gets the rewarding experience of teaching and helping a peer level-up).

Woody Zuill took the idea of pair programming significantly farther with something he called "mob programming", and it's not just a theory. He implemented the practice at Hunter Industries, based in San Marcos, CA. Mob programming is a development paradigm where a whole team of engineers (approximately 5 developers, give or take) work at just one computer to develop software. My hunch is that most managers, and even most software engineers would initially have a viscerally negative reaction to this idea. How productive can you possibly be with everyone at the same machine, working through tasks serially rather than in parallel? 

The proof is in the pudding, when it comes to software development, and Hunter has discovered the mob programming pudding is absolutely delicious! The knowledge sharing and learning opportunities for the whole team are absolutely unparalleled. There is virtually zero risk of a knowledge silo developing under this paradigm, so there's no problem with any one person going on vacation, winning the lottery, developing the next Angry Hamsters and striking app-gold, or anything of the sort.

So what is it like on a software development mob? Here it is:  A time-lapse video from the original mobbing team at Hunter Industries, long before I was lucky enough to join the team. It seems a bit unreal, but that actually is what our day looks like, even now that the mobbing paradigm has grown to be 5 or 6 development mobs working in parallel on different projects, or parts of projects at any given time.

As a testament to how happy those developers are, almost every one of the developers you see in that video (which is from 2012) is still on the team, and they are now my co-workers (incidentally, we just made a re-boot of the original mob programming time-lapse, now that we've expanded to as many as six simultaneous mobs!). As a testament to the quality of the results, Hunter expanded the mobbing program from just one team working only on internal applications to a whole department working on both internal and external facing software. And yes, we're hiring, so if this sounds as good to you as it did to me, come have a look at Hunter's job site.

Mob programming is certainly not for everyone, and it is not for every company in every situation. As always, there is no silver bullet. That being said, below are a few of the reasons I love it, and why I think it's an option worth exploring for any team:

• Since starting to work in a mob paradigm, I have never been so relaxed at work. This is not because I have a less intense desire to craft great code quickly, but because I know that everything I do is immediately peer-reviewed. It is because I know that when I have a less-than-ideal solution to a problem, the developer right next to me is likely to pipe-up and suggest an alternative approach, and so on.
• I have never had so few meetings at any job, ever. Since we all code together, there is no need to sit around talking about what we've been doing, and how we hope to integrate our work with everyone else's work. It's already done, and it's done constantly. 
• It is the perfect master-apprentice model of work... Except that you act as both master and apprentice every day, switching roles seamlessly throughout the day as the challenge at hand goes from something you are not well versed in to something that you've got eons of experience with.
• There is a very strong emphasis on collaboration and learning how to craft better solutions to our coding problems. Everyone has a vested interested in leveling-up their fellow mob programmers in order to create better and better code.

If this sounds appealing, give it a shot! Here are a few further resources to get you going:

• MobProgramming.org
• Mob programming page on Wikipedia
• ITWorld article on mob programming

As I grow older and older (...and older, and older, annnnnd older), I find that I have obtained a fairly amazing state of laser-like focus on my excessively high falutin annual goal:

To be a slightly less horrible developer this year compared to last.

My normal ticket to ride for this recurring theme revolves around sites like Pluralsight and my newest video training sweetheart, TreeHouse. But I got all excited about a potential opportunity to join a new mobile team and splurged on some great training this year. It's like a luxury vacation, except it's really hard work, and your brain comes out the other side feeling like a bowl of oatmeal that just got shot out of a giant potato gun. It's not pretty, but damn it's fun.

It's tough to choose a training course... They're expensive, and reviews are far and few between. I have occasionally considered attempting at least a temporary career of jetting around to tons of different courses writing up reviews. Wouldn't a site like that be awesome?? As soon as I find my buried treasure, I'm on it. Until then, here's my take on the 7 day course, "iOS Essentials With Swift" offered by the Big Nerd Ranch.

Short version:  It's absolutely awesome. Go sign yourself up.

​Longer version:  

I have now been to The Ranch twice. My first experience was in 2007. The first iPhone had been released, but there was no official SDK yet, and Steve Jobs was telling developers to write web apps. I took the class to learn Objective-C and Xcode, in hopes of writing software for the Mac. I was very new to software development, barely understanding the field at all. Despite my high hopes, the class proved too much for me. My minuscule bits of experience with BASIC, Java and Visual Basic in conjunction with my tiny brain (which resides in a cozy, but overly thick cranium) were not enough to get me over the hurdles of Objective-C and the bits of C one had to dip into on occasion. "Interface Builder" was a nightmarish maze (not to mention a completely separate application from Xcode) compared to the ease of use of the visual designer in Microsoft's Visual Studio IDE. I actually cried. I was terrified that I was simply too stupid to be a developer, and this was a painful wakeup call to let me know that I might be better suited to... pretty much anything.

/*  Here it is, the most important part of this post  */
​
Don't be discouraged! The fact is that I had failed to prepare. I tried to take on two new languages, a new code editor and a new UI designer knowing next to nothing, and I expected to be spoon fed at the training. When that spoon turned out to be an over-sized steel shovel, I was caught completely off guard! It's been frighteningly close to a decade since that fateful experience, and I actually did somehow manage to become a software developer... Just not for Mac apps, and not with Objective-C. I've been eyeing iOS development with envy and desire for a number of years now, and when an opportunity arose at my current company to potentially jump on a new mobile dev team, I jumped at it... But not quite like I did back in 2007.

​The 2016 version of me decided to start preparing immediately. This is the absolute best advice I can provide, regardless of whether you're planning to hit the Big Nerd Ranch, some other organization's training course, or even just hitting up some local user groups (Meetup.com tends to be a great resource for finding them):  You will get infinitely more out of any training, conference or talk with a little prep-work. When you're at the actual event, you'll have peers and experts around to ask questions and play with ideas. Do you want to ask how to declare a string variable, or do you want to ask how to work with strings to internationalize your app? Do you want to ask how to hook up a click handler, or do you want to ask about the underlying command pattern so that you can create a reasonably well architected solution? The amount of legwork you put in up front will pay off in dividends with respect to how much you get out of any training, conference or talk you attend.

The Big Nerd Ranch will send you some pre-reading to do, but it is very elementary, and I would strongly encourage you to spend more time learning the basics and getting familiar with the tools you will be using. Things will come easier and faster to you with that pre-work under your belt, and that can make the whole experience not only more valuable, but also a whole lot more enjoyable!

Once you've got some prep-work out of the way, you're ready for class. Because these classes cost so much, you really want them to be intense. Most of us cannot afford to go to one of these classes more frequently than once every few years. If you are lucky enough to have a company willing to send you to a training like this, grab that opportunity with both hands and milk it for all it's worth! If not, I feel your pain... And it's that much more important to get as much as you can from the whole experience.

There are a few key factors that I feel set the Big Nerd Ranch apart from any other organization I've had the chance to work with and learn from:

1. Big Nerd Ranch instructors are top-notch with respect to skill. They have not learned just enough to teach a focused set of content. The three instructors I've had from the Ranch were all actively working experts (Big Nerd Ranch not only teaches, they also build apps for their own clients) and they were excellent teachers. 
2. Big Nerd Ranch instructors are absolutely unrivaled with respect to commitment. They have an obvious passion for helping their students succeed. During the past week with instructor Joseph Dixon, we met for breakfast at about 7:30am. We started class/coding at about 8:30am. Except for lunch, an afternoon walk (or nap, or whatever), and dinner, we continued learning and coding until about 10:30pm. Every day. Class sessions or not, Joseph was available to help out, answer questions, and troubleshoot issues for essentially every reasonable waking hour of the day. I'm not a 9 - 5 developer. I work much harder than that... And so do the instructors at the Big Nerd Ranch. You don't have to take advantage of the extra time they put in, but I would feel crazy not to capitalize on such a phenomenal resource.
3. Meals and lodging are included. I personally wouldn't care, had I not experienced courses where everyone went to separate hotels and ate on their own. You simply don't get as much out of the training. First off, you lose momentum when you split off from your cohort. By being together with other like-minded learners all week, you talk about ideas. You talk about your struggles. You talk about opportunities. Students help each other out, and students form a real community which we can take with us when we go home. Once you are a Big Nerd Ranch alumnus, you become a permanent part of a community on a private site just for you. One of my classmates took it upon himself to create a team for us all to communicate on Slack. Another classmate created a team for us to work together on our Swift skills on the excellent Exercism site. This is the sort of genuine passion, enthusiasm and camaraderie you can only achieve through a group struggle, not an independent mission.

So if the time is right for you to level-up, and there's a course that fits what you want to learn at the Big Nerd Ranch, it gets my absolute highest recommendation. As for myself, I definitely feel like I have a significant leg-up on my goal of becoming a less horrible developer this year, so I'm patting myself pretty hard on my nerdy back. Go rock out, and be awesome!