We’ve been in the same offices for several years now, and like many tech people we’ve started to accumulate aging tech equipment, and other stuff just lying around. That’s in addition to all the normal stuff that any business accumulates.

It was time to reorganize the physical space. We allocated last Friday afternoon to finding a place for everything and putting everything in its place.

There was very little pre-planning. Dianne Marsh and I made two specific recommendations: We were moving the bookcases into one office, and mounting a 42” TV / monitor on the wall in the library. Everything else was organized by the team. Our developers, our office manager, our sales and operations staff all pitched in. Everyone looked at where they could best help, took on tasks, and got things done. By the end of the day, all the clutter was stored in closets (neatly). All the equipment was in one space. The TV was on the wall, the bookcases were moved. The books are on the bookcases, totally organized.

No single person was in charge of the process. Everyone made decisions, and then communicated those decisions to others.

What can we learn from this to apply to other activities?

If you want to experience the satisfaction and the efficiency of self-organizing teams, I think there are a few lessons to draw from this example.

First of all, the goal was clearly stated: We need to more efficiently use our space or people. We’ve been consistently growing over the past several years, and if we are too cluttered, there’s not enough room for people. Everything in the office must be neat so we’re ready for customers or colleagues to visit at any time. A secondary goal was to know what we had in the office so we don’t unnecessarily buy more equipment. (I swear cables spontaneously divide and reproduce when left lying around.)

Second, don’t limit people’s contributions. We made very few decisions for others. As long as everything got put in a place that worked, we made no restrictions on how any problem got solved. Any group or individual was empowered to find a place and an organization for anything they found that was taking up space.

Third, positive peer pressure. We were all working together. No one could say they were doing something more pressing and skip out on the cleaning tasks.  I honestly think nothing destroys team dynamics more than some tasks are ‘beneath’ them.

The end result from Friday is great. People have space to work individually, spaces to collaborate. We don’t have to move monitors and cables in order to find space at a desk. And everyone had a hand in it.

The more experience we get with Self-Organizing teams, the more impressed we are. You should try to experience it yourself.

C# Puzzlers are a series of small puzzles that make you think about some specific facet of the C# language. I put together a series of exercises are several different facets of the language. I think it’s an engaging way to get your mind around some of the areas of the language that commonly cause confusion for developers.

You can get the puzzlers at InformIT, or Safari.

We don’t hire models for our booth at conferences, and we’re not going to.

TLDR version: It would misrepresent our company.

OK, if you’re still with me, here’s the lengthy version.

Problem 1: It gives the wrong impression about the company image.

This is the most important issue. We’ve got a great workplace with mutual respect among all our employees, male and female. Hiring models for a conference booth sends messages, subtle and not so subtle, about our company’s attitudes toward the roles of men and women in our business, and our company. Close your eyes and imagine a female software developer at GoDaddy. Their ad campaigns have affected your impression, and probably not in a good way.

When you execute a marketing or advertising campaign, you must live with the impression you’ve created. You don’t get to say “No, no, that’s not really us. We just did that to get your attention.” You’ve created an image, and you’ve associated that image with your company. Your prospects (as customers, colleagues, or employees) form their image of your company, your culture and your values based on the tools and images you use in your marketing and advertising campaigns.

If that image is not correct, you must work doubly hard to correct it. You must not only continue to build your positive brand image, you must live down the negative impression you’ve cultivated. It’s hard enough work telling the world how great you are. Don’t sabotage it by telling the world how bad you are.

The obvious reason we don’t use models at conferences is that it’s wrong for us. It works against our culture, our values, and the professionals (both women and men) that work here.  For the same reason, we don’t use models on our website. The photos that you appear are people who work at SRT, either now, or in the past, when the photos were taken. But, this is the part where some marketing professional usually says, “I agree, but it works. We’ll do it anyway.”  So let’s move on to why I believe it doesn’t even work.

Problem 2: The increased traffic does not indicate increased interest in your business. It indicates increased interest in models.

Suppose there are 75 people at a 1000 person conference who may be interested in what we do. Our goal, as a business, is to maximize the quality time someone spends talking with those 75 people. Nothing else really matters to the business as a whole.

One serious challenge is that you don’t know who those 75 people are. Standard marketing logic says that if you get the highest number of people stopping by your booth, you’ll get the highest number of possible prospects. That may be true in certain markets, and at certain conferences, but I don’t think it applies all the time.

Suppose we hired models to work at our booth. I have no doubt that we would have more traffic. There would be, however, two problems: First of all, a lot of that increased traffic would not be there because of what we do as a company. The additional visitors would be interested in the models. They are probably not in that 75 attendees I mentioned earlier that are actually good prospects. All the models have done is increase bad traffic and make it harder to spot and have real conversations with the real prospects in the crowd.

Problem 3: It drives away people actually interested in your business.

I’ve said nothing about the makeup of the 75 attendees actually interested in us. How many may be women that are turned off by a marketing strategy right out of “Mad Men”? How many, men or women, would be turned off by that image? How many might be interested in a deeper conversation about software development than they would be likely to have with a model?[1] Would they visit, or would they avoid the booth entirely? Real prospects may decide there’s too much traffic, and just ignore it altogether.

So what will you see at our booth?

We will demonstrate something interesting about us and our thoughts on software development. This last week at CodeMash, we demoed an original game built using the Microsoft Kinect. We did that because we believe there are interesting opportunities to use the Kinect in many applications; it’s important for us to demonstrate that we are already learning this. That’s a key part of the message: Our company stays at the forefront of technology trends, and is often even ahead of our markets. Our technical employees are given time to investigate these new ideas and build software that shows the result of these investigations.

In years past, we’ve shown mobile applications, cloud based applications, and a game controlled by the wii remotes. I don’t know what we’ll build next year. We’re still planning that.

Everyone at our booth works for SRT Solutions. Depending on the conference, they may have a more technical role (like at CodeMash), or a more business oriented role. It depends on the audience, and the conversations that will likely occur. Anyone you see at the our booth represents the company with their knowledge and their professionalism.

You’ll see people dressed pretty much like a normal work day. In fact, if anyone asks for guidance, we’ll say “dress the way you would to attend a customer meeting.” That’s consistent with our culture and our values. And, it’s the same advice regardless of the questioner’s gender.

Do I have a point?

Personally, I believe that the way you market yourself, or your company, is about more than simply generating a high number of leads. Your marketing creates an image of your company. If you’re successful, your marketing imparts that image to many different prospects: customers, partners, employees, and more. You don’t want to live down a marketing campaign that is at odds with your company culture. You’ll attract too many of the wrong prospects, and too few of the right ones. There’s the common phrase that says “half of all your marketing is wasted, you just don’t know which half.” If your marketing is at odds with your values, the sad fact is that all your marketing is wasted.

[1] This is not to say that models are not smart. I’m just saying they know less about software development, and our business, than our employees.

In our talk, Jon described how the C# compiler creates a mutable struct when it builds the state machine that handles async continuations. Jon discussed that the nested struct was faster than a nested class. Contrast that with code in Effective C#, where I showed the following code:

public class List<T> : IEnumerable<T>
{
    private class Enumerator<T> : IEnumerator<T>
    {
        // elided
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new Enumerator<T>();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new Enumerator<T>();
    }
}

Well, Cori asked, why didn’t I make the Enumerator<T> a struct (which is what the BCL does):

public class List<T> : IEnumerable<T>
{
    private struct Enumerator<T> : IEnumerator<T>
    {
        // elided
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new Enumerator<T>();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new Enumerator<T>();
    }
}

So, why didn’t I?

Well, as Eric Lippert points out, “mutable value types are evil.”  In general, you should avoid mutable structs. If your type requires mutation to work properly, you should use a reference type. Implementing IEnumerator requires mutation (keeping track of the current item), so you should use a reference (class) type. Unless you are really sure that you need a struct, you should use a class for any type that supports mutating operations.

Because of that, I chose to demonstrate with a class rather than a struct. I felt it would be too likely for readers to copy the code and use it in different situations where the special circumstances that are in play in both async state machines and the nested List iteration are no longer true. I chose to give up some performance in return for a more general idiom that would be correct in more situations.

Given that, let’s discuss why the mutable struct works in these two situations.

In the case of the nested Enumerator class, it’s because of one of the rules for converting a struct to an interface type. When a struct is converted to an interface, it isn’t actually unboxed. The box implements the interface, and adapts the methods defined on the interface by forwarding them to the struct in the box. The struct does not get unboxed and copied on each function call. See Section 11.3.5 of the C# spec for details. Read the following guidance carefully:

If your struct will always be accessed through an interface pointer, that struct can be safely mutable because it will never be unboxed.

The nested private Enumerator satisfies this requirement. It is a nested private type, so that other code cannot access it through the struct value. Client code can only access it through the interface reference, and therefore, the above rule always applies.

The nested structure that implements the state machine in an async scenario also follows a similar pattern, and therefore is safe.

OK, before you go just applying this rule to structs in your programs, read that guideline again carefully. Notice the strong ‘always’ and ‘never’. There can be no exceptions. In the case of the nested enumerator, this is enforced by the fact that GetEnumerator() returns the interface, not the struct. In the case of the nested struct in the async state machine, it’s enforced because it’s in compiler generated code.

You’re probably not so lucky. Chances are you work with other developers. Someday, someone will make some changes to your code so that one of those rules will be broken. Then, bugs will start to crop up.

Even if you are completely sure that those rules will never be violated, take care. Just because you can get away with something safely doesn’t mean you should turn away from normal guidance. In both these cases, the performance gains by changing from a class to a struct, can be significant. That significant performance gain coupled with the guaranteed safety does mean that its worth breaking the normal guidance.

In the case of the nested Enumerable, the performance gains come from the fact that this code will execute very often over the course of many programs.

In the case of the asyn methods, it’s because the team wants to optimize the ‘hot’ path for async methods. The reason is that you (and me) should prefer making a method async if there is a possibility that it will take enough time to warrant it. We shouldn’t worry that declaring a method async will cause an undo performance burden over its synchronous counterpart. With that in mind, the team is working very hard to optimize those code paths.

If you want to switch from a class to a struct, you should perform some measurements and make sure that the change will actually give you the increased performance you seek.

In the end, the same old advice often holds true: Make it work well. Then, once you’ve measured and determined that performance for a given location is critically important, make the changes necessary to achieve those goals. In my books, I wanted to try hard to write general guidance, and I avoided most performance based guidance. It seemed safer than trying to ensure that readers would remember all the specific rules for a particular optimization.

I have not yet figured out my entire schedule, but there’s a few things I plan to concentrate on.  I need to learn more about WinRT. I’ve had too little time to build samples and learn about it yet. I want to learn more about Scala, an exciting functional style language that runs on the JVM. Beyond those specific goals, I want to learn about techniques I can apply across any platform. I don’t believe I’ve learned as much as I can about modern software engineering techniques: testing, continuous improvement, advances in languages, frameworks, and libraries. I want to spend as much time as possible in sessions that are not platform specific, or language specific.

I am giving two different talks this year.  Early Friday afternoon, I have “C# Stunt Coding: I Dare You to Try This at Home” This is a really fun talk to give. I get to start by saying that all the techniques I’m explaining are for edge cases, and specific problems, so chances are you will rarely want to use them in your everyday coding activities. Of course, that means everyone will pay careful attention, and immediately try everything I show the very next day. There’s no avoiding it. Developers just think that way. That makes it more fun.

Spoiler Alert

Ok, not really.

The other talk I have is “Async From the Outside”, where I discuss how the new async programming model in C# 5 introduces new ways to to make async programming easier.  You may have noticed that the abstract for Async From the Outside references the talk “Async From the Inside”, given by Jon Skeet, author of the very popular and respected “C# In Depth”. If you look at the abstract for Async from the Inside, you’ll see it references Async From the Outside.

There’s a few more items you should notice about these two talks:

• They are in the same room
• The second (inside) immediately follows the first (outside)

You may be thinking that it would be better to mash these two talks together, giving attendees two hours of async inside and out.

Well, Jon and I thought the same thing. We’re working together on a single stream of content, with both of us working together for the duration of the two talks. We’ll discuss how to use a feature, how it’s implemented, and how to use it in your regular development activities.

Well CodeMash fans, this will be the first time Jon and I have met in person. We’ve emailed, chatted, skyped, google talked, and been on .NET Rocks together, but we’ve never yet met in person. I’m looking forward to it. Jon and I are working quite diligently to make sure we deliver quality content. 

Jon also has his own individual talk to give: C#’s Greatest Mistakes. I’m really looking forward to that one as well.  Jon has shared some of the content with me. He’s one of a very small set of people that can give a talk like this, and make it a great talk for people to learn, not a screed. It’s one of Jon’s best qualities: the skill to be critical, yet positive.

Jon has written a similar post on CodeMash.

Right now, we’ve got an immediate opening for a business development associate. (I know that most of my readers are developers, so please pass this on, if you know someone interested in joining us in this capacity).

Of course, we are always interested in talking to exceptional developers about our ongoing growth plans as well.

You can read more here.

I promise: the next posts will have the technical content most of my readers prefer.

Let’s start with the Forbes’ article “Now Every Company Is A Software Company” The deck quote ties it directly to Michigan, “Ford sells computers-on-wheels”. The thesis of the article is that no matter what business you think you are in, you are in the software business. I’ve been saying this for almost a decade. Are you developing innovations for healthcare? You need software. Are you in advanced manufacturing? You need software. Entertainment? Software runs that too. Marketing / Branding / presence? You better have a social media and internet strategy. That takes software.

Businesses have to be incredibly smart about creating software that provides true value for their business, and leveraging commercial software in other areas. Our customers don’t ask us to build everything from scratch. There’s no return on that investment. On the other hand, they can’t create the kind of innovations they need without some custom development. If all they do is use software that is commercially available, they can’t differentiate themselves from their competition.

From this perspective, I’m impressed with the emphasis on the software industry in Gov. Snyder’s talent address. Software requires less capital, and a high percentage of that capital goes to pay wages for developers. Software business investment provides a very quick and very high return to the overall economy.

Next, there’s an article in Forbes about the rise of Developeronomics. There’s a lot of hyperbole in this article regarding developers, money, and talent in general. It is well written, and it is a fun read. The core thesis though is very good: Good developers are valuable.  Really good developers are really, really, valuable.

This paragraph sums up the software developer scene well:

In the midst of a thoroughly gloomy labor market, the genuine desperation you see in the software talent wars is almost surreal. Almost every day, I see big companies, little companies, entrepreneurs, wannabe entrepreneurs and even venture capitalists join in the hunt. The talent hunters infest LinkedIn, troll Quora, and trawl Facebook and Google+. Cartoons of homeless-looking CEOs holding up signs that say “Looking for a technical co-founder” are doing the rounds. Heck, I am one of these talent hunters (any star iOS developers out there interested in working with me?).

That paragraph sums up the strategic importance of software developers. It’s important for companies, for local economies, for regional economies, and even for nations. It explains some of the importance of the ‘10x’ effect, coined by Fred Brooks: The best developers are an order of magnitude greater than the average developers. There’s also a ‘-10x’ effect, where the worst developers are capable of dragging down entire teams.

In addition, developers more and more now understand their economic value. They will explore the market, locally, regionally, nationally, and even world wide. They will attract their fair wage, or higher.

But of course, the best developers are interested in benefits beyond money when they pick a job. As the author points out, a developer’s skills have a relatively short shelf life. It’s career suicide to get stuck in an aging technology where career opportunities are slim.

Let’s tie this to Michigan’s talent initiatives.

There’s a serious disconnect between the developers currently seeking jobs, and the technical skills employers are seeking now. As a reader of my blog, I’m sure you’re familiar with many of the skills that are in demand: .NET, Java platform, mobile, web, tablet, cloud. The current applicant pool has a very different skillset: AS400, mainframe, COBOL, and so on. That’s the reason for several of the programs:  To address the shortage of developers, the state needs to update the skills of a generation of developers whose former employers did not stay current with modern software development tools and techniques. (As an aside, there is a corollary with business failure and the absence of a coherent software strategy. More on that in another blog post). There are two very important goals for this program. The first is to teach these developers the immediate skills they need to become employable in today’s software job market. The second, and far more important, goal is to reconnect these developers with the area software community. If they stay engaged, and take control of their own career, they will continue to update their skills, and continue to be relevant to the current job market. That will be the major win, to teach a much greater percentage of our software developers to stay relevant. The Forbes article discusses “The Lifecycle of Software Talent”, where developers grow more and more skills, but eventually becomes an expert in some ecosystem and never move on:

As a developer ages, and finds it harder and harder to switch technologies, at some point, he or she is considered hooked for the rest of their natural lives to some technology — Java or C++ or the Facebook API say — that they can be expected to grow old with. When a technology hits that point of maturity, talent that’s hooked to it starts getting devalued along with falling retention costs. The buffets become skimpier, compensation drops, churn is lowered, and the talent retires into the sunset with the technology. It’s quite poignant really, like a crew going down with a ship.

You have to fight that. The best recommendation (from the same article): “The really talented ones retain an evergreen ability to reinvent themselves around the latest, youngest technology layer, seemingly at will.” 

The software landscape in Michigan is the legacy of a generation of developers that did not do that, believing in life-long job security. The current situation, and the programs to address them, should serve as an example to developers, young and not-so-young, to follow that advice and continue to invest in relevant skills throughout their entire careers.  The more we grow a modern, talented software talent pool in Michigan, the more our region will prosper.

For my audience, the best feature is that Rumelt is an engineer by training. He explains strategy from an engineering and scientific perspective. He begins his discussion by going over examples where a mission, or a set of buzz-word heavy press releases substitutes for strategy. From that moment on, you know this is not the normal business book. He picks apart such empty direction with the precision of an engineer, or a dilbert cartoon.

That first part of the book is a quick read, and quite humorous. Its value is in preparing you for the second and third parts of the book. That’s where the real value is.

The second section “Sources of Power”, describes where you can find leverage, or power, that enables a well-thought out strategy to succeed. You’ll learn to recognize drivers that can be part of a great strategy. Most of all, you’ll learn the elements of any successful strategy. On almost every page, I found something that I could apply immediately, and I’ve already found myself thinking through his examples and applying them to our current environment.

The final section “Thinking like a Strategist” provides insight into how to use your brain to evaluate strategies, and to create your own good strategies. In addition to learning to recognize a good strategy, you’ll learn how to create and execute good strategy. You’ll finally learn how to benchmark results of executing a strategy. Most importantly, you’ll gain insight into when and how to consider modifying, or even replacing a strategy that is not giving the results you hoped for.

It’s not often that I read a business book, and walk away thinking “I can use this immediately”. This book gave me that feeling several times. I was constantly finding new ideas, new techniques and tools to help me running our business. It’s well worth the read.

That said, I’m super thrilled to have made the list for 2012.  I’ve actually got two talks, and I’m excited to deliver both of them.

The first is C# Stunt Coding: I dare you to try this at home. In this talk, I get to stretch the C# language in ways you don’t expect.  I’ll show techniques to do things you don’t think C# can do. Every technique will come with the warning that it’s one of those techniques that you should only apply in rare situations.  Knowing most C# developers and CodeMash attendees, that will only make you want to use them more.

The second is Async from the Outside. This talk will discuss how the async and await keywords will change the way you code in C#. I’ll discuss the async features, and go over coding practices you should adopt to make sure that you’re making the most use of these new tools.  You may have heard that async APIs are much more prominent in the WinRT library. That’s true, and that’s why many of the demos here will be designed for the Windows 8 Metro platform. People interested in the inner workings of the async details should attend Async from the Inside given by Jon Skeet.

Users: Windows 8 and Metro

I’ve tried to spend the last week using the //build/ tablet and metro almost exclusively. It helped that I was at a conference toward the end of the week, and I traveled with only the tablet.

Forcing yourself to live in the new UI for almost a full week was an eye-opening experience. After a short time, I stopped comparing Metro to the full desktop. I stopped wanting the desktop experience. It’s very efficient. It’s easy to use. I’m totally addicted to the instant on experience.

In short, I did everything I could in the Metro shell, and became a sad panda whenever I needed to use the classic desktop.

Users: Working with Desktop Apps

Working in the classic desktop using the //build/ machine is clearly a compatibility play. It works, It does what it’s supposed to do, which is to ensure your existing software investment works on tablet, but it does feel second-class. It’s not the same experience. The performance feels wrong. The crispness is missing. The ease of use is missing.

I found I liked the Metro UI so much better, and had gotten so accustomed to it that I found myself trying to manipulate my desktop as a touch screen once I returned home.

In fact, that’s the single biggest lesson as I close this section and move to the developer section:

I firmly believe that once Windows 8 is out, Metro apps will destroy classic desktop apps in the market. The only desktop apps that will survive in the long term will be those that don’t have Metro alternatives.

Of course, not every application is applicable to Metro. Let’s talk about developing software.

Developers: The future experience

Just like we don’t develop software for phone devices using a phone, We don’t develop for Metro using the Metro UI. You’ll use the desktop experience (and whatever your favorite IDE is) to build Metro apps.  This speaks to the difference between the developer tablet given at //build/ and the consumer tablets that I think will dominate the market when Windows 8 releases.

The developer tablet from //build/ is not the right price point to compete with competitive platforms. End users will buy hardware that is more streamlined for their use, at a lower price point. As you design and develop your applications remember that: Your users will likely have a more painful desktop experience with their tablet devices than you do. They’ll want to spend even more time in Metro.

That’s why I believe it makes sense for you (and I) as developers to spend as much time as possible in Metro. The more time you spend in native Metro apps, the more you’ll understand what makes a great Metro UI.

By the time Windows 8 becomes released, I hope to have Metro versions of every non-developer application I use. Unless I’m developing code, I want to be in the Metro UI. It will feel like an earlier time when we often used cross-compilers and the development hardware was not the same as the deployment hardware.

Developers: Your next Hardware

But hey, you’re a developer. You (like me) will spend long stretches of the day in Visual Studio creating applications. For this, I really like the //build/ hardware. I put it in the dock, hook up my external keyboard, mouse, and large-screen HDMI monitor, and get to work.

This sets the Windows 8 developer experience apart from many competitive platforms. On Windows 8, you can develop for the metro platform on a Metro device, as long as you plug in some accessories. The beauty of that is you may be able to travel lighter, with only one device.

I am hoping that I can continue to find what I’m calling a “developer class tablet” once Win8 is released. It would be a great experience to carry a smaller form factor device, and still be able to do all the developer work I need to do.