Multi-Device Development in Visual Studio

Tue, May 27, 2014, 09:20 PM under Career

You've read on Soma's blog post that Microsoft is broadening Visual Studio's reach to other platforms (including for example Android)…  specifically this is what Soma wrote:

"With bring-your-own-device trends in the enterprise, and heterogeneity in the consumer mobile device market, developers are increasingly focused on building apps that can target a variety of devices. We are committed to enabling developers to build apps for this heterogeneous, mobile-first world with Visual Studio for the technology of your choice - whether .NET, C++ or JavaScript."

If you live in Washington state in the USA (or are willing to relocate here) I am looking for a Program Manager to help with this effort – read the rest of the job description here which is also where you can apply for the position (or email me).


Attend my Tech Ed 2014 session: Debugging Tips and Tricks

Mon, May 5, 2014, 06:48 PM under Events

Just a week away, at Tech Ed 2014 NA in Houston Texas, I will be giving a demo presentation that you will not want to miss (assuming you code in Visual Studio). Add it to your calendar now:

DEV-B352 Debugging Tips and Tricks in Visual Studio 2013 (link)

Monday, May 12 1:15-2:30 PM, Room: General Assembly C

As a developer, regardless of your programming language or the platform that you target, you use the debugger on a daily basis. Come to this all-demo session to learn how to make the most of the Visual Studio debugger, and hence be more productive and effective in your everyday development. We tour almost all of the debugger surface and many of its commands, throwing in tips and tricks as we go along, and also calling out what is brand new in the latest version of the debugger in Microsoft Visual Studio 2013. Whatever your experience level, you are guaranteed to leave with new knowledge of debugger features that you will want to use immediately when you are back at your computer!

 

I am also co-presenting another session later in the week.

DEV-B313 Diagnosing Issues in Windows Phone 8.1 XAML Applications Using Visual Studio 2013 (link)

Thursday, May 15 10:15-11:30 AM, Room: 340

Come to this demo-driven session to learn how to use the latest diagnostic tools in Visual Studio 2013 to make your Windows Phone 8.1 XAML apps reliable, fast, and efficient. Learn how to make the most of existing capabilities in the debugger as well as new debugging features for diagnosing correctness issues. Also, see the Visual Studio Performance and Diagnostics hub in action with its performance analysis tools for diagnosing CPU usage, memory usage, and energy consumption. The techniques covered in this session apply equally well for Windows Store apps as well as Windows Phone Store apps, so all your device development needs will be covered.

 

Links to both sessions from my Tech Ed speaker page. See you there!


Work for me on Visual Studio Diagnostics

Mon, January 13, 2014, 03:54 PM under Career

Do you want to work as a Sr Program Manager on the team that owns the Visual Studio debugger, profiler tools, and IntelliTrace? Do you fulfill the requirements outlined in the job description? If you do, then email me or apply online.


Best of “The Moth” 2013

Tue, December 31, 2013, 12:47 AM under Personal

As previously (2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012) the time has come again to look back over the year’s activities on this blog, and as predicted there were 3 themes

1. It has been just 15 months since I changed role from what at Microsoft we call an “Individual Contributor” (IC) to a managerial role where ICs report to me. Part of being a manager entails sharing career tips with your team and some of those I have put up on my blog over the last year (and hope to continue to next year): Effectiveness and Efficiency, Lead, Follow, or Get out of the way, and Perfect is the enemy of “Good Enough”.

2. It has also been a 15 months that I joined the Visual Studio Diagnostics team, and we have shipped many capabilities in Visual Studio 2013. I helped the members of my team blog about every single one and create videos of many, and then I created a table of contents pointing to all of their blog posts, so if you are interested in what I have been working on over the last year please follow the links from the master blog post here: Visual Studio 2013 Diagnostics Investments. We are busy working on future Visual Studio releases/updates and I will link to those when we are ready…

3. Finally, I used some of my free time (which is becoming eve so scarce) to do some device development and as part of that I shared a few thoughts and code: Debug.Assert replacement for Phone and Store apps, asynchrony is viral, and MyMessageBox for Phone and Store apps.

To see what 2014 will bring to this blog, please subscribe using the link on the left… Happy New Year!


Debugging and Profiling in Visual Studio 2013

Thu, July 18, 2013, 08:51 AM under VisualStudio

The recently released Visual Studio 2013 Preview includes a boat-load of new features in the diagnostics space, that my team delivered (along with other teams at Microsoft). I enumerated my favorites over on the official Visual Studio blog so if you are interested go read the list and follow the links:

Visual Studio 2013 Diagnostics Investments


Effectiveness and Efficiency

Fri, April 12, 2013, 09:22 PM under Career

In the professional environment, i.e. at work, I am always seeking personal growth and to be challenged. The result is that my assignments, my work list, my tasks, my goals, my commitments, my [insert whatever word resonates with you] keep growing (in scope and desired impact). Which in turn means I have to keep finding new ways to deliver more value, while not falling into the trap of working more hours. To do that I continuously evaluate both my effectiveness and my efficiency.

EFFECTIVENESS

The first thing I check is my effectiveness: Am I doing the right things? Am I focusing too much on unimportant things? Am I spending more time doing stuff that is important to my team/org/division/business/company, or am I spending it on stuff that is important to me and that I enjoy doing? Am I valuing activities that maybe I have outgrown and should be delegated to others who are at a stage I have surpassed (in Microsoft speak: is the work I am doing level appropriate or am I still operating at the previous level)?

Notice how the answers to those questions change over time and due to certain events, so I have to remind myself to revisit them frequently. Events that force me to re-examine them are: change of role, change of team/org/etc, change of direction of team/org/etc, re-org, new hires on the team that take on some of the work I did, personal promotion, change of manager... and if none of those events has occurred since the last annual review, I ask myself those at each annual review anyway.

If you think you are not being effective at work, make a list of the stuff that you do and start tracking where your time goes. In parallel, have a discussion with your manager about where they think your time should go. Ultimately your time is finite and hence it is your most precious investment, don't waste it. If your management doesn't value as highly what you spend your time on, then either convince your management, or stop spending your time on it, or find different management: Lead, Follow, or get out of the way!

That's my view on effectiveness. You have to fix that before moving to being efficient, or you may end up being very efficient at stuff that nobody wants you to be doing in the first place. For example, you may be spending your time writing blog posts and becoming better and faster at it all the time. If your manager thinks that is not even part of your job description, you are wasting your time to satisfy your inner desires. Nobody can help you with your effectiveness other than your management chain and your management peers - they are the judges of it.

EFFICIENCY

The second thing I check is my efficiency: Am I doing things right? For me, doing things right means that I deliver the same quality of work faster [than what I used to, and than my peers, and than expected of me]. The result is that I can achieve more [than what I used to, and than my peers, and than expected of me].

Notice how the efficiency goal is a more portable one. If, by whatever criteria, you think you are the best at [insert your own skill here], this can change at two events: because you have new colleagues (who are potentially better than your older ones), and it can change with a change of manager (who has potentially higher expectations). That's about it. Once you are efficient at something, you carry that with you... All you need to really be doing here is, when taking on new kinds of work that you haven't done before, try a few approaches and devise a system so that you can become efficient at this new activity too... Just keep "collecting" stuff that you are efficient at.

If you think you are not being efficient at something, break it down: What are the steps you take to complete that task? How long do you spend on each step? Talk to others about what steps they take, to see if you can optimize some steps away or trade them for better steps, or just learn how to complete a step faster. Have a system for every task you take so that you can have repeatable success.

That's my view on efficiency. You have to fix it so that you can free up time to do more. When you plan a route from A to B - all else being equal - you try to get there as fast as possible so why would you not want to do that with your everyday work?

For example, imagine you are inefficient at processing email: You spend more time than necessary dealing with email, and you still end up with dropped email threads and with slower response times than others. How can you improve? Talk to someone that you think is good at this, understand their system (e.g. here is my email processing system) and come up with one that works for you.

Parting Thoughts

Are you considered, by your colleagues and manager, an effective and efficient person at your workplace? If you are, what would you change if you were asked by your management to do the job of two people? Seriously, think about that! Your immediate reaction may be "that is not possible", but it actually is. You just have to re-assess what things that were previously important will now stop being important, by discussing them with your management and reaching agreement on relative priorities. For example, stuff that was previously on your plate may now have to be delegated or dropped. Where you thought you were efficient, maybe now you have to find an even faster path to completion, perhaps keeping in mind that Perfect is the Enemy of “Good Enough”.

My personal experience (from both observing others and from my own reflection) is that when folks are struggling to keep up at work it is because of two reasons:

  1. They are investing energy in stuff that they enjoy doing which the business regards as having a lower priority than a lot of other things on their plate.
  2. They are completing tasks to a level of higher quality than what is required (due to personal pride) missing the big picture which almost always mandates completing three tasks at good enough quality than knocking only one of them out of the park while the other two come in late or not at all.

There is a lot of content on the web, so I strongly encourage you to use your favorite search engine to read other views on effectiveness and efficiency (Bing, Google).


Lead, Follow, or Get out of the way

Thu, March 28, 2013, 10:16 PM under Career

This is one of the sayings (attributed to Thomas Paine) that totally resonated with me from the first time I heard it, which was only 3 years ago during some training course at work:

"Lead, Follow, or Get out of the way"

You'll find many books with this title and you'll find it quoted by politicians and other leaders in various countries at various times... the quote is open to interpretation and works on many levels.

To set the tone of what this means to me, I'll use a simple micro example: In any given conversation, you are either leading it or following it, at different times/snapshots of the conversation. If you are not willing or able to lead it, and you are not willing or able to follow it, then you should depart. The bad alternative which this guidance encourages you NOT to do is to stick around and obstruct progress by not following, not leading, and simply complaining or trying to derail the discussion in no particular direction.

The same pattern applies at your position/role at work. Either follow your management/leadership team, or try to lead them to what you think is a better place, or change jobs. Don't stick around complaining about the direction things are going, while not actively trying to either change things or make peace with it.

In the previous paragraph you can replace the word "your management" with "the people reporting to you" and the guidance still holds. Either lead your direct reports to where you think they should go, or follow their lead, or change jobs. Complaining about folks not taking direction while doing nothing is not a maintainable state.

To me this quote is not about a permanent state, it is not about some people always leading and some always following: It is about a role/hat that anybody can play/wear at any given moment. One minute I am leading you, the next I am following you, and the next we are both following someone else and so on... When there is disagreement, debate the different directions for as long as it takes for you to be comfortable that you can either follow or lead. If you don't become comfortable with either of those, get out of the way. Something to remember is that it is impossible to learn how to lead well, without learning how to follow well (probably deserves its own blog entry)...

Things go wrong when someone thinks that they must always be leading, or when everybody wants to follow and nobody steps up to lead... Things go wrong when more than one person wants to lead and they don't try to reach agreement on a shared direction, stubbornly sticking to their guns pulling the rest of the team in multiple directions... Things go wrong when more than one person wants to lead and after numerous and lengthy discussions, none of them decides to follow or get out of the way... Things go wrong when people don't want to lead, don't want to follow, and insist on sticking around...

While there are a few ways things that can go wrong as enumerated in the previous paragraph, the most common one in my experience is the last one I mentioned. You'll recognize these folks as the ones that always complain about everything that is wrong with their company/product but do nothing about it. Every time you hear someone giving feedback on how something is wrong or suboptimal, ask them "So now that you identified the problem, what do you think the solution is and what are you doing to drive us to that solution?"

The next time things start going wrong, step up and remind everyone: Lead, Follow, or Get out of the way.

For more perspectives, and for input to help you form your own interpretation, search the web for this phrase to see in what contexts it is being used (bing, google). Finally, regardless of your political views, I hope you can appreciate if only as an example this perspective of someone leading by actually getting out of the way.


MyMessageBox for Phone and Store apps

Tue, February 5, 2013, 02:41 AM under MobileAndEmbedded

I am sharing a class I use for both my Windows Phone 8 and Windows Store app projects.

Background and my requirements

  1. For my Windows Phone 7 projects two years ago I wrote an improved custom MessageBox class that preserves the well-known MessageBox interface while offering several advantages. I documented those and shared it for Windows Phone 7 here: Guide.BeginShowMessageBox wrapper.
  2. Aside: With Windows Phone 8 we can now use the async/await feature out of the box without taking a dependency on additional/separate pre-release software.
  3. As I try to share code between my existing Windows Phone 8 projects and my new Windows Store app projects, I wanted to preserve the calling code, so I decided to wrap the WinRT MessageDialog class in a custom class to present the same MessageBox interface to my codebase.
  4. BUT. The MessageDialog class has to be called with the await keyword preceding it (which as we know is viral) which means all my calling code will also have to use await. Which in turn means that I have to change my MessageBox wrapper to present the same interface to the shared codebase and be callable with await… for both Windows Phone projects and Windows Store app projects.

Solution

The solution is what the requirements above outlined: a single code file with a MessageBox class that you can drop in your project, regardless of whether it targets Windows Phone 8, or Windows 8 Store apps or both. Just call any of its static Show functions using await and dependent on the overload check the return type to see which button the user chose.

// example from http://www.danielmoth.com/Blog/GuideBeginShowMessageBox-Wrapper.aspx
if (await MyMessageBox.Show("my message", "my caption", "ok, got it", "that sucks")
== MyMessageBoxResult.Button1)
{
     // Do something
     Debug.WriteLine("OK");
}

The class can be downloaded from the bottom of my older blog post.


    

asynchrony is viral

Mon, February 4, 2013, 07:46 PM under VisualStudio

It is becoming hard to write code today without introducing some form of asynchrony and, if you are using .NET (e.g. for Windows Phone 8 or Windows Store apps), that means sooner or later you have to await something and mark your method as async.

My most recent examples included introducing speech recognition in my Translator By Moth phone app where I had to await mySpeechRecognizerUI.RecognizeWithUIAsync() and when moving that code base to a Windows Store project just to show a MessageBox I had to await myMessageDialog.ShowAsync().

Any time you need to invoke an asynchronous method in your code, you have a choice to make: kick off the operation but don’t wait for it to complete (otherwise known as fire-and-forget), synchronously wait for it to complete (which will entail blocking, which can be bad, especially on a UI thread), or asynchronously wait for it to complete before continuing on with the rest of the method’s work. In most cases, you want the latter, and the await keyword makes that trivial to implement. 

When you use the magical await keyword in front of an API call, then you typically have to make additional changes to your code:

  1. This await usage is within a method of course, and now you have to annotate that method with async.
  2. Furthermore, you have to change the return type of the method you just annotated so it returns a Task (if it previously returned void), or Task<myOldReturnType> (if it previously returned myOldReturnType). Note that if it returns void, in some cases you could cheat and stop there.
  3. Furthermore, any method that called this method you just annotated with async will now also be invoking an asynchronous operation, so you have to make that change in the body of the caller method to introduce the await keyword before the call to the method.
  4. …you guessed it, you now have to change this caller method to be annotated with async and have its return types tweaked...
  5. …and it goes on virally…

At some point you reach the root of your user code, e.g. a GUI event handler, and whoever calls that void method can already deal with the fact that you marked it as async and the viral introduction of the keywords stops there… This is all wonderful progress and a very powerful mechanism, and I just wish someone had written a refactoring tool to take care of this… anyone?

I mentioned earlier that you have a choice when invoking an asynchronous operation. If the first time you encounter this you wish to localize the impact of all these changes and essentially try to turn the asynchronous behavior into synchronous by blocking - don't! For reasons why you don't want to do that, read Toub's excellent blog post (and check out the rest of his blog with gems on async programming starting with the Async FAQ). Just embrace the pattern knowing that when you use one instance of an await, you'll propagate the change all the way to the root user code method, e.g. typically an event handler.

Related aside: I just finished re-writing my MessageBox wrapper class for Phone projects, including making it work in Windows Store projects, and it does expect you to use it with an await :-). I'll share that in an upcoming post for those of you that have the same need…


Debug.Assert replacement for Phone and Store apps

Sun, January 13, 2013, 09:42 PM under MobileAndEmbedded

I don’t know about you, but all my code is, and always has been, littered with Debug.Assert statements. imageI think it all started way back in my (short-lived, but impactful to me) Eiffel days, when I was applying Design by Contract. Anyway, I can’t live without Debug.Assert. Imagine my dismay when I upgraded my Windows Phone 7.x app (Translator By Moth) to Windows Phone 8 and discovered that my Debug.Assert statements would not display anything on the target and would not break in the debugger any longer! Luckily, the solution was simple and in this post I share it with you – feel free to teak it to meet your needs.

Steps to use

  1. Add a new code file to your project, delete all its contents, and paste in the code from MyDebug.cs
  2. Perform a global search in your solution replacing Debug.Assert with MyDebug.Assert
  3. Build solution and test

Now, I do not know why this functionality was broken, but I do know that it exhibits the same broken characteristics for Windows Store apps. There is a simple workaround there to use Contract.Assert which does display a message and offers an option to break in the debugger (although it doesn’t output the message to the Output window). Because I plan on code sharing between Phone and Windows 8 projects, I prefer to have the conditional compilation centralized, so I added the Contract.Assert workaround directly in MyDebug class, so that you can use this class for both platforms – enjoy and enhance!