The Typical C# User?
My name is Rick Spencer, and I am a Usability Specialist on Visual Studio. Over the past couple of years a large portion of my job has been supporting the Visual C# team, which has been one of the most rewarding experiences of my professional career. I thought I’d start off my first few entries with some history, how did we go about designing Visual C# Whidbey?
One of the first things that I helped the team with was using user research to define the “typical” C# developer that we should have in mind when creating Whidbey. I helped the team conduct all kinds of research, from studies in our usability labs, to visiting users where they work. I sifted through all the user data and helped the team identify the common traits that we tended to see over and over in our users. In fact, this work folded into work that I did with the rest of the usability team to define all the users of our developer tools projects. Steven Clarke has written some interesting things about that effort.
In any case, here are some of the common traits we identified and designed for:
Early Adopters
This was kind of a catch-22 for us. Since the bulk of this research was done pre-Everett RTM, most of the developers we watched and interviewed had a lot of experience with beta version of Visual Studio .NET, and I mean the first version of Visual Studio .NET. As a result, we tended to see people who were looking for opportunities to work with the latest and greatest things, they wanted to be on the cutting edge. Since we were in the early adopter phase of the adoption cycle (I’m thinking of Crossing the Chasm by Moore) we know that we were looking at a self selecting group. We expect that we may see different traits in the post-chasm C# user, and I’m looking forward to doing that research after we’re out of this part of the Whidbey cycle. Who is the post-chasm C# developer?
Object Oriented
Across the board, the C# developers we met felt very natural with OO programming and concepts. This was very different then the other developer groups that we saw in the rest of the dev tools division, where there is a lot more variability in how comfortable developers are with OO and how effectively they can use OO practices. As a result, when we think about Visual C# features we think about how to let the developers leverage OO features of the .NET platform instead of try to walk them through them, or even hide them. In other words, Visual C# developers were pleased with the .NET platform because of it’s OO nature, not despite it.
Code Focused
When we talk about “code focused” this meant a couple of things to us. First, the users we watched were very persnickety about their code. For example, they would spend a lot of time formatting their code the way they wanted. They would write a block of code, and then go back and indent it the way they wanted. They would copy code from somewhere, and then format it in their editor before they even read it. There just seems to be a sense that the code itself can be beautiful, and code that was ugly, and here I mean was formatted in the wrong way, was fixed up.
The other part of being code focused has to do with the way they see the designers and other parts of the Visual Studio tools that were not code editors. For instance, the Windows Form designer. Many developers look at programming as designing a form, and then writing “code behind” that makes the form work. The form itself is the program, and the code is annotations that make the program do what they want. The Visual C# developers, however, tend to think of the Windows Form designer as a code generator. For example, we saw one developer use the form design and the sever explorer to bind to data. Then he went in and cut out all the generated data code and put it into it’s own class. He didn’t mind using the generated code, but the code was his, not the form’s. Furthermore, he couldn’t live with having the data code embedded in the UI code, he just had to factor it out or he wouldn’t have slept well that night.
As a result of these observations, the Visual C# team included added a set of code formatting features so that our users could have their code formatted the way they wanted, but didn’t have to keep stopping to fuss with it. By the way, a little tip if you’re using a Whidbey pre-release: there is a command called “Format Document” that will format all the code in the current code file. I use this all the time to keep my code pretty, but also, if the code comes out formatted funny, it usually means there is something wrong with my brace matching or something.
We also tried to design as many of the productivity features as possible to work from within the editor. Since the C# developers we comfortable in code, we didn’t want them to have to leave their code to modify it if possible.
Pragmatic
One of the key features that distinguished the Visual C# users from some of our other user groups, was that they thought long term about the code they were writing. They knew the code would be maintained by someone else, so they thought about how to write it in a maintainable manner. They thought about if the code they were writing would be performant under various important circumstances. They considered if their would be security concerns later on, and tended to plan for it. Many of our user groups address these issue only after the code is working and they have fulfilled their functional specifications, Visual C# users tended to think of it up front.
On the other hand, they also made sure that they shipped on time. For instance, if there was a possible perf issue with a part of their code, they didn’t necessarily address the issue until they fulfilled their functional spec and made sure it would actually be a problem.
We called the ability to make these trade-offs “pragmatic.” Other parts of being pragmatic included things like using a third party control, even if they knew they could do it better themselves, they were willing to settle, but deliver. Other developers we have seen simply must hand roll everything, because that is the only way to make sure that everything is done right.
Battle Scarred by C++
While by no means universal, a lot of the Visual C# developers came from a C++ background. However, many of them have bitter memories of suffering with bad pointers and memory allocation bugs, not to mention COM. Mentioning iunknown was enough to make some of them shudder. Working within a run time environment that alleviated these pains was a principle reason that they enjoyed .NET programming. Paired with a class library that made their application development much more productive, moving to .NET made programming much more fun and rewarding then C++ programming, and there was a lot less of the painful trouble shooting.
Interestingly, some C++ developers we talked to didn’t like the idea of working with a runtime. One of them told me that his code was just not symmetrical without the “deletes” to go with the “news”. For him, memory management was an essential part of programming, not a troublesome extra task. He felt that moving to .NET would also mean giving up control over things like performance. It was an interesting difference in personality.
Does This Ring True?
I’d love to hear about how these traits do and do not ring true to. Are you all Object Oriented, code focused, pragmatic developers who bear battle scars from C++ but who love to be on the cutting edge? Also, now that we are working on the third major version of Visual Studio .NET, is there a main stream C# programmer who is different then the typical programmer that we saw before?
