One of the best things about being a developer is the opportunities we get to hang out with other developers and talk technology. Whether it’s hanging out for beers after a user group meeting, sitting around a restaurant table at lunch, or talking smack with each other while playing video games, it is always a good time. The way we tend to have these conversations is by telling our stories. It makes sense, given no two developer stories are alike.
That’s why I was delighted when Pluralsight offered the opportunity for me to talk to even more developers about their stories of technologies and developer practices. Not only will I be getting the opportunity to swap stories with developers, but we get to make a podcast out of it! I mean, what’s more exciting than talking tech? (I really meant that last bit.)
That’s the idea behind the Pluralcast, which came online today. The Pluralcast will be a bi-weekly audio show that focuses on a particular topic each episode, and shares stories from people with experience in that topic. This isn’t just an interview with the latest technology wonk of the day. The intent is to provide real world stories, some insight into the technologies themselves, and maybe a little guidance if you are thinking of trying something new.
The first 2 episodes are online today. Both are fairly light to get us kicked off well, but I already have plenty of stories on disk that get to deeper in technology. We’re going to be talking Silverlight, Agile, SharePoint, Data Access, Microsoft Research, language level features, and plenty more things in future episodes.
The best part is that you get to participate! If you are reading this, there is no question that you have a story to tell yourself. So, tell it! Or tell us what kinds of stories you are interested in hearing.
Every day we learn something is a good day, and I want the Pluralcast to help your day be a little bit better. So, check it out and see what you can learn!
I would definitely like to hear about Scrum purity. Thoughts around keeping a committed sprint sealed. What makes a good backlog item? What are the minimum criteria for a backlog item. Who gets to call things done? When your product owner is just a pass-through for the business. (Product renter.) There are many Scrum problems and open questions that I am always wondering about how do other developers think about these issues, address them or live with them. And where are some authoritative sources we can reflect back to so it not just me saying “hey you’re not following Scrum!” Just some food for thought. I wrote about one of my problems here: http://simpleprogrammer.com/2009/12/05/scrumbut-double-fudge-sunday-and-scrummaster-personal-trainer/