Here is What is going right: Mob Programming Benefits (Part 3). I will give a short explanation on the two benefits below. Check out the other parts of the series for even more benefits of mob programming.
Temporarily joining another mob
Temporarily joining another mob
Yesterday I found myself alone at my mobbing station. We are not allowed to write production software without at least one other person mobbing with us. So, I rolled my chair over to the closest mob got my name in the rotation and began mobbing with them.
The mob I joined was in a language I have very little experience with and a technology stack I have even less experience with. But I was able to follow along and contributed what I could.
I was mob programming with the team for roughly 45 minutes before we broke out for lunch. During this time I was absorbed into the new mob. It was an easy transition into the other mob. It did not cause disruption in the flow of the mob. And I got to learn more about the technology our teams are using.
Mob programming let me join an entirely different team and share my skills even if just for a short period of time.
When you have a group of 3 or more people all working on the same project at the same time together knowledge is going to be spread. Mob programming reduces knowledge silos essentially to zero. If someone is already very knowledgeable on a subject while the rest are not, the knowledgeable member navigates the others so the knowledge can be shared. Knowledge silos do not last long if they exist at all.
A second major benefit of redundant knowledge is that members can leave. For something as common as getting coffee or water, when a member leaves, the code is still moving forward. And even more importantly if a member goes on vacation all the code keeps on going. We do not run into roadblocks because of the redundant knowledge.
Redundant knowledge means 100% participation by every member of the mob at all times is not necessary. People can come and go as they please without worry.
That concludes What is Going Right: Mob Programming Benefits (Part 3), check out the other posts in the series
I am always interested and looking for new libraries to put to use in Xamarin.Forms. I recently stumbled upon Microsoft Cognitive Services Emotion API and wanted to see what it was all about. After a quick look at some sample code, I knew I needed to sign up and try this library out for myself.
According to comments in the code, which I am always skeptical of, the API can detect happiness, sadness, anger, fear, contempt, disgust, and neutral. It is amazing that it can determine these emotions and with great accuracy. What is even more amazing is that it basically is one line of code.
This one simple line gets the first (highest percentile) emotion recognized from a picture. Using the sample code you can easily take a beautiful selfie, send it with the single API call, and within seconds get an emotion back. I am not sure yet what factors cause it to take longer but sometimes I get results back in under a second.
From my dozen or so attempts at taking a picture of myself, it gave quite accurate results. I have yet to fake fear in a picture but will see if I can one to happen. I am very impressed with the Emotion API’s ability to analyze and image and produce an emotion result. Looking forward to Microsoft adding even more emotions.
The free tier for using the API is quite impressive in terms of the number of calls available. I hope to be writing a post soon showing off an app I have made in Xamarin.Forms incorporating the emotion API.
I have been in the mob for over a year and have more aspects of mob programming that I would like to share. Let’s jump right into What is going right: Mob Programming Benefits (Part 2).
Idea Generation & Development
Efficient use of time
Idea Generation & Development
Mob programming promotes the generation and development of ideas. You have multiple team members to bounce your ideas off of in order to come up the best solution. You do not need to come up with entire solutions on your own or have a fully thought out idea.
I have found myself presenting a half-baked idea, knowing that with the help of my team members we can work the idea into something real. It is a great feeling to be able to present just half of an idea and get input from the team on how to build it out to fruition.
This also helps in the opposite direction. If I present an idea not fully thought out and a team member can point out the flaws; I do not have to waste any more time trying to build the idea when in the end it would not even work anyway.
It is hard trying to take an abstract concept in your head and code it up into a full solution all on your own. But with mob programming, you have the help of your team the whole way.
Efficient Use of Time
Mob programming makes efficient use of the developers time. My mob only has one, yes ONE, regularly scheduled meeting a week. And even better only one mob member has to attend so the three of us on my mob rotate. I go to one regularly scheduled meeting every 3 weeks.
The rest of my time is spent coding. If my mob decides we should discuss a topic more in depth before jumping into code we do not schedule a meeting and find a conference room away from our computer to discuss. We simply swivel our chairs to the whiteboard or just start talking.
On a good mob, impromptu discussion just happens when it needs to. If the code is flowing fast then no need to discuss, if we are up against a challenge start discussing.
Mob programming lets you focus on the code, which is exactly what every developer wants to do!
This blog has turned into more of a technical spot recently; however, it started as a place for me to share my favorite memories. This post will be about my 5-day backpacking trip with an amazing group of friends on the Lost Coast Trail in Northern California King Range National Conservation Area. It is a memory I will never forget and want to share.
Day 1 on The Lost Coast Trail
The first day on the trail started with the group getting some last minute items into our packs in the parking lot of Black Sand Beach trailhead. We were taking the North to South approach to the trail, leaving our cars in Black Sands, and having a shuttle take us to the north end, then hiking down from there.
After a bumpy and windy bus ride to Mattole Beach trailhead, we eagerly threw our packs on our backs and headed to the trail. The trail started out sandy, very sandy. But hey, we knew what we were getting into. The goal for the first day was to get in a few miles nothing strenuous, we wanted an easy introduction to the trail and since we were planning to take 5 days to do 25 miles, we were in no rush.
We were all excited and all full of adrenaline starting out our first day on a camping trip that we had all been looking forward to for months. We easily made it to the major landmark Punta Gorda lighthouse. It was constructed in the early 1900’s to help alert ships of the treacherous tides along the coast and saw service until the 1950’s. We were now the ones taking on the treacherous coast.
Just a half mile past the lighthouse we came across a creek and some camping spots that we decided to stop at and make camp for the first night. The first day of the Lost Coast Trail was an easy one with mostly sand and some hard packed dirt. In all our excitement the sand really did not bother us at all and at this point, we really did not know how precious the hard packed dirt could really be.
The wind was strong on our first day, Fortunately, our camping spot provided some cover but still we experienced a windy night. We half expected to wake up without a tent fly anymore. It really was that strong of wind. Luckily, all our stakes held and the rainfly clips held strong, thanks REI Half Dome 2!
Starting the amazing Lost Coast Trail and all the excitement and adrenaline that came with it
Exploring and playing around the Punta Gorda Lighthouse
Having to have someone hold tent down as we set it up because it was so windy
Having our first campfire on the trail
Day 2 On The Lost Coast Trail
Our second day started off lazy. This day we would be dealing with a tidal zone and low tide was not until 4 in the afternoon. We wanted a noon start so lazily ate breakfast and packed up in the morning. After leaving camp we had a mile to get to the tidal zone and 4 or so miles of the tidal zone to deal with. The tidal zones were exciting for all of us since we did not entirely know what to expect other than the fact that we would basically be face to face with the ocean for most of our hike.
What we did not know or expect were the number of rocks we would be hiking over. We were able to keep hiking at a decent pace but the fear of ankle injuries was definitely in our minds. 4 miles of hiking on rocks meant secure footing was a necessity, full hiking boots a must.
After some scrambling across the rocks, we came to a spot where even during low tide it looked dangerous. This was about a mile into the tidal zone and during low tide, it still looked impossible. We scoped out the area and some knowledgeable hikers came by as well. They informed us this spot would require going up on the bluffs and hiking a half mile or so, then go back down to the beach. Glad we ran into them because going around the point with waves crashing into it would have been a bad idea.
It was quite amazing how one second you are in a zone where the high tide would wash you away and just 50 feet ahead you are back on the bluffs safe from the crashing waves. We made it to the Spanish Flats outside the tidal zone! We hiked another mile and a half to where we would set up camp for the night. Our camping spot for the second night was even better than the first. Well established, very protected, and beautiful views.
First thing first though after getting to camp we all took a bath. We made our way to a spot in the creek where a small pool formed and washed off our dirt and grime. A cold but refreshing bath in the middle of the trail. After a refreshing dip in the creek, we settled into camp making dinner and starting a fire. Some of us stayed up to see the sunset. It was serene being able to sit in solitude on the beach and watch the sun dip down below the horizon. It really felt like we had the entire coast to ourselves.
Hiking along the bluffs, super windy and on the cliff edge
Stepping foot in the tidal zone and realizing damn this trail is intense with nothing but rocks in sight
Making it out of the tidal zone and onto the grassy Spanish Flats, was a relief to be on some solid ground
Sitting by myself on the bluffs watching the waves and soaking in the gracefulcxenvironment
Resting around the camping enjoying the beautiful sunset
Day 3 On The Lost Coast Trail
We had been seeing nothing but the sun since starting our trip but this morning brought on the new weather, fog. The fog was enjoyable, it was a good break from the constant inescapable sun we had been experiencing.
For this day of hiking, there were no tide zones to deal with. We headed out in the morning with the goal of camping just before the next treacherous tidal zone. Without too much sand to deal with we made good time. It was great hiking along grassy bluffs with a mysterious foggy haze over top of us.
A few drops of rain here and there were all we had to deal with while on the trail. Once we got to camp the rain began falling a little heavier. After a somewhat rushed dinner, we jumped into our tents to escape the rain. The rain really was not bad at all but after 3 days of hiking we enjoyed the early bedtime and pitter patter of rain as we fell asleep.
Hiking along the grassy bluff, seeing the grass wave in the wind.
Freaking out a little bit coming across a large group of people performing silent meditation.
Seeing a dead whale on the beach.
Hiking in solitude really experiencing and enjoying the Lost Coast.
Day 4 On The Lost Coast Trail
We awoke to a wet morning. It had not rained hard during the night but a constant drizzle overnight can really get things wet. We packed up our wet gear and made a run for it on the trail.
Today was our another long stretch of the tidal zone that we would be dealing with. Another 4 miles of tidal zone. Upon reaching the tidal zone we were a bit nervous. The rain storm was still occurring and we had shown up only an hour after peak high tide. We could see waves crashing up and taking up the whole beach in front of us.
After waiting half an hour hoping the tides would subside, which they did but only very little. We decided now or never and set out. There were some wave dodging and rock scrambling, but the whole group made it through. The waves crashing so close upped our adrenaline and excitement for sure.
By mid-afternoon the sun had broken through the storm. We made camp just outside the tidal zone at Gitchell Creek. Our last day on the Lost Coast Trail gave us with the best sunset. The lingering clouds and haze looming over the mountains while seeing perfect blue skies over the ocean made for the most magnificent sunset.
Maneuvering through the tidal zone attempting to stay as dry as possible.
Watching the best sunset of the trip, sitting just above the shore break with all my friends
Enjoying the camping area with other campers
Day 5 On The Lost Coast Trail
Our last day on the Lost Coast trail. We took our time packing up because none of us wanted to leave. The 5-day trip had taken its toll on us but still, we were not ready for it to end.
We could see Shelter Cove and Black Sands Beach in the distance. The trail there was not an easy one though. It was all soft sand or tiny rocks that you sank into. It made for a slow pace but we were okay with that.
Upon arriving at the cars we collapsed. Tired, smelly, and hungry for anything other than freeze dried food. We made it! We conquered the Lost Coast Trail.
This was a trip that we will never forget. Are you a backpacker? Then taking the Lost Coast Trail needs to be high up on your list of places to go. If you plan on doing the trail or have already done it yourself, comment below with any questions, concerns, or favorite memories.
I was lucky enough to attend Microsoft Build 2017 this year. A ton of great products were announced and released at Build. And I want to list out some of the ones that got me the most excited while at the conference.
Microsoft Visual Studio for Mac
This is a big deal as I am using a Mac every day for development. Previously we had been using Xamarin Studio for Mac but with Visual Studio (VS) coming out for Mac we will definitely be switching over. Even though I do want to switch over it is not entirely a choice. Now that VS for Mac is released it seems that Xamarin Studio will be phased out. This is not a bad thing as VS for Mac is supposed to have all the Xamarin Studio features and more.
Having all the power of Visual Studio while doing Xamarin development on Mac is very exciting.
Xamarin Live Player is an app for Android and iOS that allows you to pair your Visual Studio (VS) instance on Windows or Mac to your phone. To pair your phone to VS you simply scan a QR code and now you can build your app, push it to the phone, and test all wirelessly. It is even capable of showing your changes in VS live on the phone.
I have not had a chance to try this yet but I am really excited to give it a shot in the next few days. Note that the VS 2017 preview is required to use this feature. The app is available now in your phone’s app marketplace. As of now, it is still in beta, so give your feedback if you see anything buggy or difficult.
Visual Studio Mobile Center
This is Microsofts all in one build, test, and deploy engine. It is in preview right now and estimated to be GA in Fall of this year. For mobile development, mobile center sounds perfect. It can connect directly to Github, TFS, and vsts to start builds, tests, and deployments on every push.
There are plenty of other services available like this but the features included and ease of integration are intriguing. One thing my team like is the ability to notify specific users via push notifications when successful deployment happens. This lets us easily notify users with release notes included of new things they can try and test.
This one will not be out until the Fall creators update of Windows 10 but still, I am excited about it. From the demo, during the keynote of Build, it looks like it should make my GoPro video editing streamlined. It can take a series of videos and utilize artificial intelligence to determine how to organize the videos. It makes cuts and transitions all on its own. It can even recognize faces in the videos so if you want the video to feature a particular person it’s as easy as selecting them as the main focus in settings.
I am really looking forward to seeing what Story Remix can do for me and my GoPro footage.
Microsoft Build 2017 was an eye opening experience. The conference had a few main focuses two of which were cross platform development and utilizing artificial intelligence. I look forward to what the future of these two things means for myself as a developer and all other developers in the Microsoft sphere.
I just hit my one year anniversary at my organization as a mob programming software engineer. I wanted to share one of the experiences I have had over the course of that year.
My first 9 months at Hunter I worked with the same team. The team consisted of eight developers. This team generally had two mobs going. So, I would be switching mobs on roughly a weekly basis. This meant I was changing tasks being worked on and not always seeing tasks to completion since I would switch to the second mob. This all sounds great sharing knowledge and changing mobs being worked with.
The big change came in February. I changed projects. I moved to a team of just three developers including me, so a much smaller team. With just three developers this means we are a single mob all the time, every day. The biggest difference is no more switching between mobs, no more switching between tasks. I am seeing all our tasks from start to finish. It might seem difficult to work with the same two other people every day but honestly, they are great!
This no more switching of mobs, no more switching of tasks has led me to have a much greater sense of accomplishment when it comes to programming. Something I have heard from more than one developer has been their feelings of lack of accomplishment. They think they are just a tiny piece of a much larger project. Or simply the fact that they cannot physically see or hold their project makes them feel less accomplished. Putting your code on a flash drive and waving it around saying, “look at what I made”, is not all that fulfilling.
The fact that all three of us on the team work together always, all three of us complete tasks to the end together, and all three of us struggle through the hard problems makes for a strong accomplished team.
Numerous times while working on my old team of eight, one mob would be struggling on a challenging problem while the other was working on a different problem less challenging. One mob would be having a bad day trudging through a problem while the other was moving forward at a normal pace. The pain was not always shared but due to having two mobs it could not be shared, that is just how it was.
Now, it is never fun to have painful programming days but at least if the whole team shares the pain it can be more of a team building experience rather than team dividing. When a problem is solved by the whole team together a greater sense of ability is shared and most importantly if the same problem comes up again later we can crush it!
I mentioned above the task switching problem and that was a major hindrance to the feeling of accomplishment. At times, I would be working on a problem all week and just when we were about to get to the light at the end of the tunnel I would switch mobs. I felt almost robbed of the accomplishment. I know I was a major player in the completion of the task, but damn, it hurt just a little to be taken away before seeing it to the end.
Do not get me wrong, one of the strongest points of mob programming is the switching of mobs within a team to ensure no knowledge silos are formed. But it is important to see the other impacts that switching teams has. I felt somewhat cheated of getting to complete something I had worked a long time on, but also I felt I lost some learning because I did not get to participate in the final steps to solving the problem.
Overall on my new smaller team, I feel more accomplished. I am seeing all our tasks to completion, I am struggling through the difficult parts altogether as a team, and I get the fullest sense of learning because I was not taken away at any point from the problem. Again, I had plenty of feelings of accomplishment and achievement while on the larger mob, but now I get to experience every accomplishment and achievement with the smaller team.
Expect more post and experience reports about switching from a large mob to small.
When I start down a new solution or looking at how to solve a problem one of the first things to jump into my head are all the crazy edge cases that may or may not ever occur. I see it as a blessing in disguise because, in the long run, it helps out tons to be able to think about the crazy things a user may do. But when just trying to get a proof of concept together it can make the work that much more daunting.
When putting together a proof of concept stick with the happy path. Hard code values, expect perfect reproducible input, and for the proof of concept even lower the security levels a bit. Make sure if using lowered security settings you are in some sort of development environment. Do not go lowering your security on production.
But the key is to make it as easy on yourself as possible. What if you took the happy path and find out your solution did not even work anyway? You do not want to have wasted your time making your ability to accept input the most robust known the man if your strategy to submit the code is
A more real world time when the happy path saved me much time and effort was when the team and I at work were attempting to setup up a cloud solution using AWS. We had a couple different strategies in our minds as to how to build out our cloud solution. It involved security, databases, IoT, Lambda functions. It was going to be an extensive cloud system.
First thing we did was throw security out the door. We knew it needed to be done but would only complicate things. We did not set up a database because again takes time and we had a lot of database knowledge on our team so that did not pose too much of a risk. We just hard coded the data we would receive back when we did end up making the database.
Now we could take a look at the happy path for our proof of concept. Perfect user input, interaction, no confusing security. We found that our first model would not scale well so we threw it out the door. Our second model was not easily supported due to library limitations imposed on us. Our third solution found a happy medium of ability to scale, performance, and ease of implementation. This all did not happen overnight it actually took a few weeks. But imagine if we had added the extra complexity of security or the database. It would have taken months.
Taking the happy path saved us time and frustration. The process of making application development as easy for you as possible. Ignore the edge cases, ignore security, hard code values. Made us more productive and let us explore multiple solution strategies in a shorter amount of time.
“The EventWaitHandle class allows threads to communicate with each other by signaling and by waiting for signals.”
How do I go about testing an EventWaitHandle. Events are being published threads are flying around the application and I want to test my WaitOn() and Set() calls on my EventWaitHandle.
Why I am using EventWaitHandle
I have a function that displays user data, let’s call it DisplayUserData. But I need to make sure I have all the latest customer data before presenting it. I publish an Event that makes API calls in order to gather all the user data, called GetUserDataEvent, in the beginning of DisplayUserData. I need to make sure that my GetUserDataEvent has fully completed before displaying any data. I have a GetUserDataEventCompleted that I am waiting for. EventWaitHandle is the solution I have to pause inside of DisplayUserData until GetUserDataEventCompleted has been received. Below is a simple sample of what I have currently going on in my code, that needs to be tested.
How to test your EventWaitHandle
Now how can I test this? How can I ensure that the code WaitOne() is working and code is not attempting to access user data before the Set() is called? We will use some threading in our test!
We will put our function call on its own thread. This allows the GetUserDataEvent.Publish() and the WaitForUserData.WaitOne() to occur on their own thread. Our test code can continue and verify what is happening.
Directly after the call to start our thread we want to assert or verify that our code for displaying user data is not being called. This can be tested in a couple ways. It is up to you. But for me, I had a mock of my DisplayUserData and was able to verify that it had not been called yet. For a less advanced approach, you can set input a thread delay and ensure that certain values are still null. Such that they have not been populated with the user data yet.
After we have verified our display code has not been called we can populate our user data with simple test data. This is where the mock comes in because since I had mocked out my actually API call no data was coming back. I simply need to input my own test data. I am not trying to test my API calls at this time I have other tests for that, I only want to be testing my EventWaitHandle.
With our test user data generated we can call, GetUserDataEventCompleted. The subscription for this event calls our WaitForUserData.Set(). We expect that once the Set() is called our Display for the user data will be called once. Below is a layout of our entire test created for EventWaitHandle. This now tests that the Display call on user data does not occur until we explicitly get our Set call on WaitForUserData.
The above works due to mocking using moq library. If you are not familiar with mocking I highly encourage you to look into tutorials on how to use the differen mocking libraries available to you.
For help writing your own EventWaitHandle test leave a comment!
I want to call this blog post What is going right: Mob Programming Benefits (Part 1) because I know there are and will be more things going right because of Mob Programming. As of right now, I have been mob programming for just under a year. So for part one, I wanted to explain two of the major factors that are going right in mob programming.
Idea sharing leading to learning
Building strong teams
There is so much more that comes with mob programming, but I want to stick to just two for now. I plan to expand this list greatly but just want short and sweet post for now.
Idea sharing leading to learning
If you are not learning, you are falling behind. Learning should never be undervalued.
With mob programming, you are learning daily. You have the brains of 3, 4, 5 or more developers all being shared. Woody Zuill’s one sentence explanation of mob programming describes the learning perfectly, “All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.”
All the brilliant minds are developing ideas, they are sharing those ideas with everyone. Even if an idea is not entirely thought out it is shared. With all the other skilled developers around you, something great can be built out of your idea. Sharing ideas to boost learning is one of the biggest things going right with mob programming.
A great feeling I have gotten many times while mob programming has been stating an idea to a solution I had that did not solve the whole solution but only part. As soon as I described the idea to the team other members jumped in being able to solve the pieces I had struggled to solve. I learned how to solve the full solution by presenting my partial idea.
Sharing ideas to boost learning is one of the biggest things going right with mob programming.
Building Strong Teams
I have had some of the strongest and most cohesive work teams due to mob programming. The idea of working with the same people 8 hours a day every day may scare some people. But the safe environment we create at work where ideas, even bad ones, are accepted and thoroughly thought through makes a good team.
By spending so much time with the same people, I learned a lot about them. I was able to learn what specialties they have so I knew where I could get specific knowledge if needed. I have even able to pick up on the idiosyncrasies of individuals, so I knew when the right time to coerce ideas out of them in a safe way was or when to be quiet and let them process ideas in their own head.
Spending so much time with everyone on a team built strong work and even personal relationships. We easily learned about each other and with each other. I know I was nervous in the beginning about spending day after day working with together in a team, but it really has been an amazing experience so far that I look forward to every day.
Stay tuned for more short “What is going right” posts.
In this post, I will describe the basics of designing and working with the IntentSchema for an Amazon Alexa skill. To provide some context, an Alexa skill can have multiple intents. Each intent is a specific action within the skill.
Imagine we have a calculator skill. The user can ask Alexa to add or subtract two numbers. The skill would be the calculator and the two intents would be adding and subtracting. The intent schema comes into play because we are allowing the user to add or subtract any two numbers. We use the IntentSchema.json to prepare Alexa to accept those two arguments. Note: The programming idea of an argument is referred to as a slot in the Alexa world, I will refer to them as slots for rest of post.
For our addition and subtraction intents, we would need to define two slots for both of them the first number and second number in the calculation. See below the intentSchema.json currently with only the AddIntent slots defined in it.
Above is an example with both of our intents defined inside of the intentSchema.json Notice slots within the same intent must have unique names but slots inside of a different intent are within a new scope.
All slots must have a defined types. Amazon has some default types that you can use for your apps. These types are the most common:
Able to recognize numbers and convert then to integers. Example: Two converts to 2
Converts times into programmable values. Example: “Set alarm for seven pm”. Converts to 7:00 or 18:00 depending on settings
Able to change durations into usable values Example: “Set alarm for 45 minutes”. Converts to PT45M
Recognizes 4 digit number sequences like years and converts them. Example: “Wikipedia war of eighteen twelve” converts to 1812.
Converts dates into usable formats. Example: “What is the weather today” converts to what is the weather for 2017-3-2
If you find yourself struggling with understanding what the above types do and how they handle user input. Make sample apps and look at what Alexa returns as the data. It is useful to see the real world conversions that Alexa does.
The intentSchema makes Alexa powerful because it can make your skills more dynamic, in that you can accept all types of input from the user. It is possible to build custom slots as well as lists to really build out your skill. I will make a post in the future about these advanced topics.